I have successfully proved to myself with an independent test program that
there is either an undocumented side effect or an actual bug in the CEEPIPI
(term) call which deletes any non-LE HLL load module which is attempted to be
registered with the CEEPIPI (add_entry) call, but does NOT delete non-LE
assembler modules registered with (add_entry).
Even if the program issues the LOAD macro for the non-LE module following the
failed (add_entry) call (RC=12, non-LE module cannot be added to pre-init
table), the storage at the address returned by the LOAD macro is demonstrably
freed before the older COBOL initialization module IGZERRE is called.
This is a skeleton of the program logic:
Initialize non-LE program with normal R13 save area and base registers
Extract program name to be called from PARM or default to name TESTUSER if no
PARM
CEEPIPI (init_sub)
CEEPIPI (add_entry) for program to be called
Success: Go to CALL logic
Failure: LOAD the program and save the EP address, mark as
non-LE in flag
CALL logic: If non-LE-flag is OFF then go call using CEEPIPI (call_sub)
Else CEEPIPI (term)
(** WORKAROUND FOR PROBLEM goes here - re-LOAD the
program and save the EP again **)
LOAD and Call the older IGZERRE program to initialize
COBOL environment
Load saved program EP and BALR 14,15 to program
Go to EOJ logic
CEEPIPI (call_sub)
EOJ logic
If the WORKAROUND logic is not executed then a S0C1 abend happens when the BALR
14,15 to the called program is done, because the storage at the saved EP
address is not the program any more after the CEEPIPI (term) call.
Note that this is not a problem for non-LE assembler called programs, they are
NOT removed from storage. Only HLL programs (VS COBOL II V1R3.1 in the case I
tested). Assembler programs stay loaded where originally loaded.
I think I have to engage my system guys to take this to IBM for resolution.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Farley, Peter x23353
Sent: Monday, March 20, 2017 5:42 PM
To: [email protected]
Subject: Re: LE Pre-initialization again - catch-22 situation
Further investigation and some additional coding has shown that the problem I
have is that the (term) call to CEEPIPI apparently DELETE's all LOADed modules
whether they were loaded by LE functions or by user code following the
(init_sub) and (add_entry) calls. Displaying the storage at the loaded program
address before and after the (term) call, the program is clearly present before
the (term) call and clearly deleted from memory following the (term) call.
This is not a documented effect of the (term) operation. Do I have an APARABLE
LE bug here or just an RFC for a documentation change and then code a
workaround for the undocumented result? (i.e., re-LOAD the requested module
after the (term) call).
Peter
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Farley, Peter x23353
Sent: Monday, March 20, 2017 2:58 PM
To: [email protected]
Subject: LE Pre-initialization again - catch-22 situation
I have been experimenting with dynamic mixing of LE pre-initialization and
non-le initialization in the same assembler main program, and I do know that
they cannot be both used at the same time; you can only do one or the other at
a time. So I tried to set things up so that if I found the module to be called
was non-LE I would terminate the LE (init_sub) environment with a (term) call
and then call IGZERRE to set up for a non-LE call.
I have encountered a catch-22 situation - in order to find out if a module to
be called later is LE or non-LE, I have to set up the pre-initialization
environment first and do an (add_entry) call. If RC = 12 (X'0C') from
(add_entry) it is a non-le subroutine and I need to use the older IGZERRE
initialization routine.
Even when I terminate the pre-initialization environment using the (term) call,
when I invoke IGZERRE following the (term) call I get a S0C1 abend in CEEPIRA.
What am I missing here? Can I not use IGZERRE after setting up and then
terminating the pre-initialization environment?
The issue I am trying to solve is that we have some old utility COBOL
subroutines called from assembler main programs that were compiled with VS
COBOL II V1.2, and that version of COBOL does NOT generate an LE-enabled
executable program. You must use IGZERRE to set up to call such subroutines.
Re-compiling the old VS COBOL II V1.2 subroutines with an LE-generating
compiler is obviously a better option, but I need to provide for downward
compatibility before that conversion can be scheduled.
I could just LOAD the subroutine first and manually examine it to determine if
it is VS COBOL II V1.2 or earlier (the eye-catcher "C2 1.2.0" near the
beginning of the program allows that fairly easily), and then DELETE the module
if it is actually an LE mocule, but that seems inefficient for future use when
it gets converted to a later COBOL version. (I try not to be perfectionist
about efficiency, but sometimes I can't help myself.)
TIA for any assistance or RTFM you can provide.
Peter
--
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
