PL1 Environment Problem with ALC 
Author Message
 PL1 Environment Problem with ALC

Does anyone know of a way to maintain the PL1 environment when the PL1
program is the third program in a calling chain.  I have an ALC calling an
ALC calling a PL1 and it appears that the PL1 environment is lost and must
be re-established every time which causes tremendous overhead.  The
3-program chain is mandatory as the middle program (ALC) is an interface
program to the PL1 module.  Any help would be greatly appreciated.

PS - this is my first post to a newsgroup so if I do something wrong or
leave something out, please be kind.



Fri, 26 Nov 1999 03:00:00 GMT  
 PL1 Environment Problem with ALC



Quote:
>Does anyone know of a way to maintain the PL1 environment when the PL1
>program is the third program in a calling chain.  I have an ALC calling an
>ALC calling a PL1 and it appears that the PL1 environment is lost and must
>be re-established every time which causes tremendous overhead.  The
>3-program chain is mandatory as the middle program (ALC) is an interface
>program to the PL1 module.  Any help would be greatly appreciated.

>PS - this is my first post to a newsgroup so if I do something wrong or
>leave something out, please be kind.

I do not know the answer to this question in PL/1 but have worked on
similar Assembler/COBOL problems.  In the COBOL environment the
problem is like this.  When your COBOL/PL/1 subroutine returns control
to the caller via Branch on Reg 14, COBOL thinks it is returning
control to the operating system and does all its end of run unit
activity.  When you call it again it thinks it is starting again for
the first time, so it does all of its start of run unit activity.

To solve this problem in COBOL you call some COBOL library routine
from the Assembler mainline.  This routine does all the address space
initialization that subsequent COBOL modules expect.  I have forgotten
the name of the module but it is well documented, probably not in the
Language Reference but more than likely in the PL/1 equivalent to the
Compiler Library and Programmers Guide.  I think you dont need to
pass it any parameters, as in it knows what to do.  Subsequent calls
to other COBOL modules detect that address space initialization has
occurred and so they behave like real subroutines.  

Memory fading here, but I cannot remember if you need to call and end
of job module.  For some reason, I think not.  

I think this problem can only occur in a batch environment.  I would
have checked the manual for you, but got lazy and also do not know
PL/1, so it would have been limited help.



Sat, 27 Nov 1999 03:00:00 GMT  
 PL1 Environment Problem with ALC

Your observation is correct.  If you have ASM calling ASM calling PL/I you
will loose the PL/I environment everytime you return from PL/I to ASM.

The simplest solution is to use a tiny PL/I component at the top of the
heap.    PL/I calls ASM calls ASM calls PL/I.  In this case the PL/I
environment will remain up for the life of the step.

There are two other more complex methods described in the PL/I V2R3
Programming Guide - Chapter 18.  This book is widely available, probably
on IBM's book server on the internet, and on numerous CD's.

If you are using PL/I for MVS and VM, this method should still work, the
more complex methods are documented in the LE/370 Programming Guide.
Rex Widmer
Builder of software archeology tools and other strange programs to help survive in a legacy based world.



Sat, 27 Nov 1999 03:00:00 GMT  
 PL1 Environment Problem with ALC

Having done PL/I -> ALC on a few occasions over the years, I have to agree
with Rex and Michaell.  There are also techniques, similar to those used
in CICS, to start a PL/I environment and keep it up, but I don't know much
about them.  What you do not want to do is start a PL/I environment
time after time after time, as you have observed.

--Steve Myers


Quote:
>Your observation is correct.  If you have ASM calling ASM calling PL/I you
>will loose the PL/I environment everytime you return from PL/I to ASM.

>The simplest solution is to use a tiny PL/I component at the top of the
>heap.    PL/I calls ASM calls ASM calls PL/I.  In this case the PL/I
>environment will remain up for the life of the step.

>There are two other more complex methods described in the PL/I V2R3
>Programming Guide - Chapter 18.  This book is widely available, probably
>on IBM's book server on the internet, and on numerous CD's.

>If you are using PL/I for MVS and VM, this method should still work, the
>more complex methods are documented in the LE/370 Programming Guide.
>Rex Widmer
>Builder of software archeology tools and other strange programs to help survive in a legacy based world.



Sat, 27 Nov 1999 03:00:00 GMT  
 PL1 Environment Problem with ALC

Quote:

> Does anyone know of a way to maintain the PL1 environment when the PL1
> program is the third program in a calling chain.  I have an ALC calling an
> ALC calling a PL1 and it appears that the PL1 environment is lost and must
> be re-established every time which causes tremendous overhead.  The
> 3-program chain is mandatory as the middle program (ALC) is an interface
> program to the PL1 module.  Any help would be greatly appreciated.

> PS - this is my first post to a newsgroup so if I do something wrong or
> leave something out, please be kind.

Brent... Are you compliing the PL/I module with a SUBROUTINE
form of header? As opposed to "PROC OPTION(MAIN);"

There is a well documented interface in the programmer's
guide that describes in excruciating detail how this MUST
be accomplished...

If you are, then RWidmer's suggestion describing a linkage
about PLI -> ASM -> ASM -> PLI would be the best bet...

Ciao,
Bill B.

(Just tried to go to http://ppdbooks.pok.ibm.com:80/
but it's real busy and hasn't responded in under a minute
so I can't give you a manual reference...)



Sat, 27 Nov 1999 03:00:00 GMT  
 PL1 Environment Problem with ALC

Quote:

> Does anyone know of a way to maintain the PL1 environment when the PL1
> program is the third program in a calling chain.  I have an ALC calling an

Just call any PL/I program from the mainline, even one that returns
immediately without doing anything.

The Pl/I environment is not associated with any particular PL/I program,
and is created the first time that a PL/I program is called. The environment
boundary includes the calling program, so you have to call some PL/I
routine from the mailine to avoid the overhead of setting up and tearing
down the environment if control percolates back up more than 1 level.

That was the simple answer. The complex answer is get LE/370.
--
notice: by sending advertising/solicitations to this account you will be
indicating your consent to paying me $70/hour for a minimum of 2 hours for
my time spent dealing with it        note MMFs/MLMs etc. get forwarded to



Sat, 27 Nov 1999 03:00:00 GMT  
 PL1 Environment Problem with ALC

I beleive that once the "active PL/I program count" goes to zero the
environment will be torn down.  Thus the solution of calling a dummy PL/I
program from the mainline will not acheive the desired result.  The "place
a PL/I program in the calling chain" solution DOES work.
Rex Widmer
Builder of software archeology tools and other strange programs to help survive in a legacy based world.



Mon, 29 Nov 1999 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. PL1 Environment Problem with ALC

2. PL1 environment and ALC modules

3. PL1 and Language Environment and C

4. PL1 for Linux / PL1 for Win95?

5. wanted: PL1 to C xlator or PL1 BNF

6. pl1 problem

7. ALC TRIVIA

8. Just One More ALC Trivia

9. More ALC trivia

10. Yet another ALC trivia

11. Still more ALC Trivia

12. More ALC Trivia

 

 
Powered by phpBB® Forum Software