The main problem with this solution (or any other solution) that checked something before I make the PC call is that the server could crash (or be brought down) between the check and the PC call.
Were I to implement something like the solution you describe, I would hope that I could either use the get name/token pair routine to check to make sure the server is up, or perhaps be able to check for existence of the servers ASCB or TCB, so that I didn't need to place anything into common storage. What I was hoping for was a solution where there was no chance of intermittent failure. The only way I know of to support that would be to be able to trap the ABEND. Is there really no way to issue an ESTAE type of recovery routine in C++ and return control to some function or something similar? Thanks! David Logan -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ray Overby Sent: Sunday, January 06, 2008 12:42 PM To: [email protected] Subject: Re: C++ recovery from (an otherwise) system abend David, To my knowledge IBM does not provide a way as part of setting up cross memory services to serialize the termination of a LX owning address space with the program(s) that may be trying to the use LX/PC routines. The LX owning application has to design a methodology to deal with this. Unless of course you create your XMS structure in the master scheduler address space in which case your LX owning address space would NEVER terminate. You could do this by making your LX owning application a z/OS subsystem and using a subsystem initialization exit. An approach you could have a switch (bit) available that can be tested by your assembler routine that would indicate whether you can issue the PC or not. If the bit is on you can issue the PC. If the bit is off then you must not issue the PC. This support would entail (at a very high level): - Adding a bit that indicates if the LX is usable or not. Typically the LX owning address space has a global cb to anchor the LX it has obtained. Hopefully you can add the bit to the same global cb. - Change the LX owning address space to set the bit to indicate its "LX is usable" once it has initialized and is ready for its PC routines to be invoked. - When LX owning address space terminates (normally or abnormally) you turn off the bit. - Optionally change the LX owning address space to "wait a bit" prior to terminating (normally or abnormally) after turning the bit off. This would allow any "in-flight" pc routine(s) to complete. Length of time to wait depends upon the PC routine. - Optionally change the PC routine to check the bit periodically during processing. If bit gets turned off then quickly exit the PC routine. - Change the routines that issue the PC call to check the bit prior to issuing the PC. If bit is on then issue the PC call. If the bit is off the don't issue the PC. Hope this helps. Ray Overby David Logan wrote: > Here is a question for the masses. I am calling a PC routine from C++. The > C++ and assembly code snippets are at the end. > > My question is this: When the address space that contains the XMS routine > goes down, my client app crashes with a S0D6(rsn 22). All fine and dandy, > but I want this to not happen. I was hoping the try/catch block would catch > it, but it doesn't. Does anyone know what recovery routine options I have to > trap this and recover? What I want to do is wait for the XMS address space > to come back, then continue. > > Thanks! > > David Logan > > The C++ code is: > try > { > rc=CallPC(data.lx_value, > 1, handle, block_number, dest_buffer, > data.data, workarea, &ecb, ascb); > } catch(...) > { > printf("DANGER!\n"); > rc = 0; > }; > > > The assembler code that is executed when CallPC is executed is: > CALLPCR CSECT > CALLPCR AMODE 31 > CALLPCR RMODE ANY > EDCPRLG > L 14,0(,1) > L 14,0(,14) LXVALUE IN R1 (PC VALUE) > LA 1,4(,1) POINT PARMLIST PAST LXVALUE > PC 0(14) > EDCEPIL > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
