failure.
Thanks again for all who responded.
Dave
-Original Message-
From: David Kreiss
Sent: Friday, July 11, 2008 4:09 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: RE: Preventing LOGREC Recording in a Recovery Routine
Just to follow up. I established a FRR in the case of holding the local
We have a non space switching PC we use to ensure we have the required
access to a specifiable piece of storage (much like a TPROT
instruction). If we take a S0C4, our recovery routine sets appropriate
retry info in the SDWA and returns resulting in the PC getting control
where if sets a return
David,
Have you looked at the code expansion of the SETRP RECORD=NO macro?
There should be doc on the RECORD= parameter of the SETRP macro in the
IBM manuals. If I remember correctly the RECORD= parameter is the one
you want. The macro expansion should show what updates to the SDWA are
Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ray Overby
Sent: Friday, July 11, 2008 10:19 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Preventing LOGREC Recording in a Recovery Routine
David,
Have you looked at the code expansion of the SETRP RECORD=NO macro?
There should be doc
PROTECTED]
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@BAMA.UA.EDU
Sent: Friday, July 11, 2008 12:23 PM
Subject: Re: Preventing LOGREC Recording in a Recovery Routine
Ray,
Yes, we looked at the SETRP RECORD=NO and all it does is turn off the
SDWARCRD bit in SDWAACF2. We checked to ensure
: Preventing LOGREC Recording in a Recovery Routine
David,
Have you looked at the code expansion of the SETRP RECORD=NO macro?
There should be doc on the RECORD= parameter of the SETRP macro in the
IBM manuals. If I remember correctly the RECORD= parameter is the one
you want. The macro expansion should
: David Kreiss [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@BAMA.UA.EDU
Sent: Friday, July 11, 2008 12:23 PM
Subject: Re: Preventing LOGREC Recording in a Recovery Routine
Ray,
Yes, we looked at the SETRP RECORD=NO and all it does is turn off the
SDWARCRD bit in SDWAACF2
: Friday, July 11, 2008 12:43 PM
Subject: Re: Preventing LOGREC Recording in a Recovery Routine
Dave,
SDWAACF2,SDWAFREE is set prior to returning with R15 set to SDWARETY.
Here is some more info. Only the failing PC invocations in the EOT exit
are causing LOGREC records. It seems Ray's comment
David Kreiss wrote:
Here is some more info. Only the failing PC invocations in the EOT exit
are causing LOGREC records. It seems Ray's comment may be the clue. I
suspect there is another level of recovery established by the system for
EOT exits which is turning on and/or ignoring our
, 2008 11:09 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Preventing LOGREC Recording in a Recovery Routine
David Kreiss wrote:
Here is some more info. Only the failing PC invocations in the EOT
exit
are causing LOGREC records. It seems Ray's comment may be the clue.
I
suspect there is another
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/11/2008
05:48:51 PM:
Ed,
After some experimentation we have certainly isolated the failure to
honor the don't record to LOGREC to when this PC takes its S0C4 in the
EOT exit. I created a slip dump of a non-EOT exit S0C4 in the
: Preventing LOGREC Recording in a Recovery Routine
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/11/2008
05:48:51 PM:
Ed,
After some experimentation we have certainly isolated the failure to
honor the don't record to LOGREC to when this PC takes its S0C4 in the
EOT exit. I
Just to follow up. I established a FRR in the case of holding the local
lock and the recording of LOGREC was honored. I ran 5 successive tests
and there were no LOGREC records. Normally we hit 22 per run. Thanks
to Ed Jaffe, Dave Cole and especially Jim Mulder for their assistance.
Dave
13 matches
Mail list logo
