Here's the initial summary:

1. I need to put _start, or something like _start into an XL.
Merely "REVEALRL"ing _start and adding it to the XL
doesn't quite do it. Why not?

2.What are the arguments, (both explicit and implicit) to
_open_std_file?
Is this the only call required to initialize stdio?

Here's the more detailed story.

We currently have a large collection of libraries of c code in our
XL. Much of this code is shared between NM c applications, CM c
applications, and CM SPL applications. A good portion of it uses
stdio functionality, signal handling, errno, ,...  you know normal
c stuff. Our error reporting subsytem relies heavily on stdio and
signal handling, and is used heavily by programs written in SPL, through

NM switch stubs. It all runs under straight MPE/iX, no POSIX.

Up until now, we had been using the CCS c compiler and libraries
for mpe. For non-technical reasons, we decided to move to the HP
c/iX compiler and libraries. When asked, HP told us that, yes, we
could put our c code in an XL and call it from SPL, using their product.

Now that we've bought the darn thing and we're actually trying to do it,

their story seems to have changed somewhat.

With the CCS libraries I had to provide "export stubs" for global data,
and NM switch stubs had to call an initialization function. With the HP
libraries I can just use the "shared globals" version of the library.
This is nice.
It's the initialization of those globals that's proving difficult.While
it's no big
deal for NM c programs to be linked to LIBCSHR.LIB.SYS and call _start,
that's not really possible for CM SPL programs.

Some exploration into LIBCSHR.LIB.SYS revealed that _start calls
a number of other supporting functions:
    ARITRAP  : This one I can figure out. There's some documentation
available.
    U_INIT_TRAPS : Gee. I gues it's more trap handling stuff. I'll
probably use our own anyway,
                                 so I'm not really concerned about this.

    __exit : This one should be fairly standard.
    _close : I'll bet it closes stdio files.
    _dup : Hmmmm... I dunno.
    _init_x11_globals : probably just for X11.We probably don't need
that, but one never knows...
    _open_std_file : This is the one that I suspect initializes stuff
for stdio. We definitely need this.
                             How do I use it???!!!??
   _parse_info_string  : I think I know what this one does. I'm pretty
sure none of our XL code
                                   will need it.
   main : This one is fairly well documented.
   __ANSI_MODE  : This one is just data. I don't have any idea if I
would need to set it
                                  or not, and if so, what would I set it
to?

At this point, it seems like a peek at the source for _start would be in
order. I've tried exploring
these issues with the HP support folks, and they've been very helpful,
but now they're starting to
talk about proceeding further only on a time and materials basis, which
probably means  they're
losing patience. Apparently the large chunk of change we've laid out for
the compiler and support
are not enough for a ticket to the truly supported c user's club. When
we did this with CCS, Dave
Bosky was able to explain it to me quite easily and was very forthcoming
with whatever I needed
to know. Oh well,.... (whine off)

So. That's my sad story. Any assistance with this stuff would be greatly
appreciated.

Thanx

Scott Herman
Dept. of Lab Medicine
Yale New Haven Hospital
New Haven Ct. 06511
[log in to unmask]