I am not familiar with CICS linkage but could you have the same physical module but with two entry points, one for CICS and one for batch?
If whatever (rather odd IMHO) political or managerial constraints you are operating under will not allow two different entry points, you *might* be able to figure out a way to have a single named entry point but a very early test that let you have two different sets of logic, one for batch and one for CICS. OTOH converting to LE should not be terribly difficult AFAIR. What is there to do OTHER than the entry/exit linkage? Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of John McKown Sent: Tuesday, June 25, 2013 6:16 AM To: [email protected] Subject: z/OS subroutine in assembler, used in both batch & CICS , making re-entrant IMO, this is a rather involved problem. background: This is in CICS/TS 4.1, z/OS 1.12. We have a few highly used assembler subroutines which are statically linked into both CICS and batch COBOL programs. These programs are very old (20+ years). They use an "in line" save area, and so they are not RENT. We are having a problem with some other program (nobody can figure out which one) in which that program sometimes overlays a CICS application program. Some time thereafter, when this overlaid program is invoked, it abends (surprise, suprise!). We are running RENTPGM=PROTECT. However, none of our programs are linked as RENT and so they are not protected. We use CA-Endevor to do all our compiles. The Endevor person changed the Endevor setup to have the RENT parm in all CICS/COBOL links. Unfortunately, this resulted in programs which use this assembler subroutine abending ASRA (S0C4-4) when the subroutine tried to modify its save area (in the CSECT). I don't know why the binder requires the RENT parameter to mark a program object as RENT if all the input CSECTs are COBOL which is compiled with the RENT compiler option. Maybe somebody could explain? Nobody here really understands CA-Endevor. Bottom line: I need to change the assembler program to be RENT. And it still needs to be callable by both CICS and COBOL programs. And I cannot have a batch version vs. a CICS version. So I really do need it to truly be RENT. So I have some questions. 1) Can I use a BAKR instruction in CICS successfully. This would put the caller's registers in the z/OS stack. Since the program runs on the QR TCB and does not do any CICS work, there should not be any concern about a CICS task switch causing the program stack to be modified. 2) Convert the assembler code to be LE compliant. I think that the LE prologue is the same for both CICS and batch. I am familiar with writing LE enabled assembler main routines. 3) Convert the assembler to COBOL. This would be a royal PITA to code and I am concerned about the CPU impact. This is highly used code. And, apologies to Tom Ross, the COBOL code generation seems to be designed to stress test the entire instruction set. 4) What about not using a save area at all? It might be poor design, but what about using the high full word of each register as a save area for the lower full word? I don't think that CICS or COBOL uses the full 64 bit registers. I think that the start up code could "save" each register with a RLLG Rn,Rn,32 to rotate bits 32-64 into 0-31 before using bits 32-64 for other purposes. Then "restore" the register(s) with the exact same instruction to rotate the bits in 0-31 back into bits 32-64. I _assume_ that bits 0-31 at entry are not important and need not be saved/restored. 5) What about using the access registers as a save area? I could do a series of SAR Rx,Rx at the front of the code and then EAR Rx,Rx instructions at the end. I don't think that the Access Registers are used in CICS application code and I doubt their values are assumed to be anything specific in CICS management routines. I.e. they should be available without saving. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
