I have double checked the routines. I don't like running without a save area, but in this case, it is not absolutely needed. So I will propose a slight modification to eliminate it. Turns out I can't use the BAKR because the routine has a deliberate S0C3 abend encoded in it. This is poor design, but is a way to cause a "return" which cannot be ignored. And is "compatible" with both batch and CICS. I couldn't return an RC to indicate "bad input parameters" because the code originally did not pass an RC and so none of the code which uses it checks. The original designer assumed that it was unbreakable and would never get incorrect input information. After multiple CICS overlays and outages, I had to test the input data for validity and take some action. So I chose a S0C3.
Oh, why would I even consider converting it to COBOL? So that our COBOL only programmers could be tasked with maintenance. Not that it is ever touched very much. The political constraints with making "disruptive" changes is the amount of "weeping, wailing, and gnashing of teeth" by our programming staff. Who are overworked and often pressure to get something running which works "most of the time" and get on with the backlog of requests. Oh, the S0C4 was from setting up a save area for the program. And back chaining it to the caller's supplied save area. This is not needed. I did it mainly for debugging so that the SYSUDUMP in would have it in the save area trace. But we don't much use those any more, We use AbendAid for all debugging. So I will use the caller's supplied save area and just no set up one for my code since it is not needed. Thanks for helping me think this through. Sometime it just helps to have somebody to talk to and have them point out my poor assumptions. Which, in this case, were left over from the original code from 20+ years ago. On Tue, Jun 25, 2013 at 8:28 AM, Charles Mills <[email protected]> wrote: > 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 > -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
