Re: z/OS and libc

John Goodyear wrote:
> It's been such a long time since I've poked at this, but running nm 
> against /usr/lib/libc.a supports the notion that it's just a dummy.
> 
>       nm -a libc.a
>       __lib__.o:
>       0 D @@DOPLNK
>       0 U @@XINIT@
>       0 D @STATIC
>       0 U CEESG003
>       0 U CEESTART
>       0 T __lib__very_unlikely_to_be_referenced_external_function
>       0 U printf
>       0 t private
> 
> There is no other .so or .dll form of libc that I've found so far. I try 
> to dust off some of the cobwebs and remember where the functions are 
> hiding.
> 
> Karl, It may help if you can you supply the names of some of the 
> functions you are having problems with.

So where does libc or posix emulation layer for Z/OS (USS????) live? Are 
1-5MB copies of it static linked into every single [posix] binary on 
Z/OS? That sounds inefficient.

Googling says libc is stored in the Z/OS native FS, not the emulated 
Unix FS.

https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.cbcux01/finauto.htm

"The C runtime library routine definitions for 32-bit programs are 
contained in the CELHS003 member of the data set CEE.SCEELIB"

A presentation that, from what I can understand very little.

https://share.confex.com/share/118/webprogram/Handout/Session10767/10767%20-%20zOS%20DLLs%20for%20Dummies.pdf

Sounds to me like Z/OS libc isn't an "ar" file that can be NM-ed, it 
isn't a dlopen linker file either. Its some kind of non-posix file that 
the Z/OS linker (runtime or compile time, or they are the same thing?). 
That PDF (and this page too 
https://www-01.ibm.com/support/knowledgecenter/SSGMGV_3.1.0/com.ibm.cics.ts31.doc/dfhe4/XPlink/dfhe4_overview.htm 
) is alluding that Z/OS shared libraries live in other address spaces or 
no address space at all (compile C to Java, a very big string emulates 
memory) and all function calls are RPC calls through a port/gate/sandbox 
(x86 interrupt 0x80/0x21/syscall ins).

The Z/OS shared libs are RPC calls concept reminds me of other OSes. On 
16 bit Windows and I think Perl on Symbian (PERL_GLOBAL_STRUCT), shared 
libraries behave more like services/daemons, not reusable "static 
libraries". In this Win16/Symbian behavior, a shlib can be loaded 
exactly once on the OS, all processes share the same shlib instance 
(memory protection be damned). Only 1 copy of the shlib's global vars 
can ever exist at any time on the PC/computer. bulk88 guesses to defeat 
the shlib is a daemon optimization, to make multiple instances of a 
shlib's global vars requires copying the shlib file to a unique disk 
name then loaded the "new" shlib with the dynamic linker.