Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Dynamic calls: ASM -> COBOL -> ASM -> C

115 views
Skip to first unread message

Robert Ngan

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to
I am working on a current application, main routine is (non-LE) ASM which
dynamically calls 'COBOL for This 'n That' module, which statically calls
(non-LE) ASM or dynamic COBOL.

Every works fine at this point. Basically, the ASM routines issue MVS
LOAD followed by BALR to loaded COBOL routines.

All calls in the current system use OS linkage, i.e. R1 contains address
of list of addresses to the parameters.

Now I am trying to add C into this equation, but have a problem.

If I specify a mainline routine which is NOt called 'main' and
code '#pragma linkage(xxx,OS)' the C program does not initialize the C
runtime stuff within LE (LE is already active since COBOL is always
invoked before C, but it looks like LE is only initialized for COBOL
runtime).

If I specify 'main(...)' the C runtime environment gets initialized but C
forces standard C main() parameter conventions (i.e. argv and argc get
passed instead of the parameter list from the invoking ASM module).

How do I code the C routine such that it will initialize the C runtime
with the LE enclave if it has not already been initialized, AND have it
pass the parameters with OS linkage conventions?

--
Robert Ngan
CSC Financial Services Group


miller

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to
An idea is to make a load module for the function, define the entry
point with #pragma linkage(xxx,fetchable) and call this module
dynnamically.

Axel.

--
| Axel Miller | Voice: +49 (0)431-5353-129 |
| PPI Financial Systems GmbH | Fax: +49 (0)431-5353-111 |
| Deliusstrasse 10 | mailto:axel....@ppi.de |
| D-24114 Kiel | http://www.ppi.de |

S Comstock

unread,
Mar 11, 2000, 3:00:00 AM3/11/00
to
Robert Ngan writes...

First, in the LE world realize your C main cannot be a main: there is only one
main allowed per enclave, and that was established at the COBOL level since
your COBOL program is an LE-enabled compiler.

I would simply take out the pragma linkage. Try it that way first. I have not
really found a need for it anywhere.

If that doesn't work, then I would relink your COBOL program and do an INCLUDE
of module CEESG003. This CSECT, which does nothing, tells LE that the C runtime
environment should be initialized (there is a signature CSECT for each possible
LE runtime environment. This should ensure the C runtime is already established
by the time you get to your C program.

<commercial>
All this and more is covered in my course "Hot Catholic High School Girls In
Bondage". Whoops, no. Wrong title. The correct title is "Inter-Language
Communication in OS/390". Check out the outline on our web site (see my
signature).
</commercial>

Regards,


Steve Comstock
Telephone: 303-393-8716
www.trainersfriend.com
email: st...@trainersfriend.com
256-B S. Monaco Parkway
Denver, CO 80224
USA

Robert Ngan

unread,
Mar 14, 2000, 3:00:00 AM3/14/00
to
I have a "anchor" COBOL to hold onto the COBOL/LE enclave, so I coded up
a dummy C routine which the COBOL called, thereby initializing the C
runtime when the COBOL portion is initialized.

I tried your suggestion of using CEESG003 and that works great! So I'm
using that now (no need for the other crud my dummy C routine dragged
into the COBOL load module!)

However, in general If the first module in a LE enclave is language "X",
and we *MAY* be dynamically calling LE compliant modules in languages "Y"
or "Z", how do you do runtime initialization for the other languages?

I now know I can use the CEESG00n approach, but if language "Z" is
dynamically invokes in say 1% of transactions, how do I avoid the
overhead of initializing its runtime unless it is really needed?


In article <20000311124806...@ng-ci1.aol.com>,
scom...@aol.com says...
> Robert Ngan writes...
>
[snip]


> >
> >How do I code the C routine such that it will initialize the C runtime
> >with the LE enclave if it has not already been initialized, AND have it
> >pass the parameters with OS linkage conventions?
>
> First, in the LE world realize your C main cannot be a main: there is only one
> main allowed per enclave, and that was established at the COBOL level since
> your COBOL program is an LE-enabled compiler.
>
> I would simply take out the pragma linkage. Try it that way first. I have not
> really found a need for it anywhere.
>
> If that doesn't work, then I would relink your COBOL program and do an INCLUDE
> of module CEESG003. This CSECT, which does nothing, tells LE that the C runtime
> environment should be initialized (there is a signature CSECT for each possible
> LE runtime environment. This should ensure the C runtime is already established
> by the time you get to your C program.
>

[snip]
>
> Regards,
>
>
> Steve Comstock

Robert Ngan

unread,
Mar 14, 2000, 3:00:00 AM3/14/00
to
When all else fails, RTFM!

I think I found my solution in the CEE3ADDM routine documented in the LE
Vendor Interfaces manual. This allows me to dynamically all langauge
support to and existing enclave (I hope!, haven't actually had a chance
to try it yet).

Once I figured out that "members" were actually languages, the doc
actually became (somewhat) intelligible!

In article <MPG.13373f912...@news.gte.net>, rob...@gte.net
says...

0 new messages