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.
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.