PL/I in the LE/370 Environment 
Author Message
 PL/I in the LE/370 Environment

We've got a bunch of old PL/I 2.3 (and possibly release 5) apps running
under CICS using the PL/I Shared Library. Now that we're moving to OS/390
Release 2 (and LE/370), it appears we may be heading for troubled waters.

Is anyone out there running PL/I under CICS in the LE/370 environment?

If so, do you use the PL/I Shared Library? Do you also have Cobol for MVS
or C/C++ for MVS running in the same region?

Did you have to relink all your old PL/I Shared Library transactions? Which
transient libraries do you use: the PL/I transient libraries or LE/370?



Tue, 02 May 2000 03:00:00 GMT  
 PL/I in the LE/370 Environment

We have COBOL main programs running under CICS v4r1, staticly linked with
PL/I. We use an intermediate PL/I routine with PROC(...) OPTIONS(MAIN COBOL)
rather than trying to added ENTRY OPTIONS(COBOL) lines to the subroutines.
This isn't particularly new, we have COBOL subroutines around that I wrote
in 1977 that are used by PL/I main programs. Interlanguage stuff has always
worked as documented, at least if you turned off COBOL and PL/I error
handling to avoid conflicts.(had some screwball error handler abends in DB2
contention/rollback/requeue situations in IMS/TM with COBOL subroutines and
COBOL abend handling active).

This was all compiled and bound using LE/370 compilers and libraries,
and runs under the LE/370 runtime libraries.

For trying to migrate old stuff IBM supplies a canned BIND routine and a
special compatibility static library. I  don't have it in front of me, but
my recollection is that it had a series of binder REPLACE commands naming
every possible PL/I, COBOL, etc. static library module. These were then
resolved by Automatic Call resolution, using the compatibility library.

The biggest headache we got was the mandatory TRAP(ON) runtime parm.

One possibility was that our transactions could get left in a partial update
state. Ie. IBM's announcement that "in the event of an ABEND you can now
get control and fully resolve it" put shivers up my spine. I'm not smart
enough to write a routine that can fully resolve all possible errors. If
there is any kind of unexpected situation I want control to pass to IBM
TP and DBMS backout routines(we use DB2 and IMS DBCTL, for update).

The TRAP(ON) also generated a performance problem, since every PL/I "main"
program with NOSTAE,NOSPIE in it's PLIXOPT(or the COBOL analog IGZUOPT?)
generated SYSOUT lines reporting that User specified options had been
overriden by the mandatory TRAP(ON). This got resolved earlier in the year
when IBM provided maintenance restricting TRAP(ON) to IBM code. We also
had to apply maintenance to IMS to resolve abend handling conflicts.

Quote:

> We've got a bunch of old PL/I 2.3 (and possibly release 5) apps running
> under CICS using the PL/I Shared Library. Now that we're moving to OS/390
> Release 2 (and LE/370), it appears we may be heading for troubled waters.

> Is anyone out there running PL/I under CICS in the LE/370 environment?

> If so, do you use the PL/I Shared Library? Do you also have Cobol for MVS
> or C/C++ for MVS running in the same region?

> Did you have to relink all your old PL/I Shared Library transactions? Which
> transient libraries do you use: the PL/I transient libraries or LE/370?

--
UCE often makes this account useless for e-mail. Any mail you send may

are up. Shields are currently up.


Tue, 02 May 2000 03:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. PL/I in the LE/370 Environment

2. PL/I in the LE/370 Environment

3. LE/370 : ILC between Cobol and PL/1

4. Multi-tasking with LE/370

5. LE/370

6. LE/370 using relink

7. LE/370 INTERNAL ABEND. ABCODE = 4088 REASON = 00000063

8. Behaviour of FREE() changed in LE/370?

9. Can LE/370 Routines be called by REXX ?

10. COBOL LE/370 upgrade

11. LIBKEEP in LE/370?

12. COBOL LE/370 Date Routines

 

 
Powered by phpBB® Forum Software