Re: How recover from unrecoverable DCB ABEND?
In my meagre experience, abends such as EOV which are normally recoverable in QSAM I/O (which I guess means GET and/or PUT, oh and PUTX of course but that should be unlikely given that PUTX is an update-in-place of a successfully read record) become unrecoverable when the same condition is encountered under the auspices of OPEN or CLOSE. So, given the comment that the problem may well have occurred while attempting to fetch the first block, I'd say that in this case the problem was encountered under the OPEN SVRB. If you find that a SYNAD exit can handle the situation, then well and good. But I think it was said that a SYNAD exit was employed to no avail. To me, the suggestion of an ESTAE with a RETRY made the most sense, in terms of attempting to recover from the abend with some degree of grace, but I don't know the details of how RETRY from an ESTAE works when the abend occurs in an RB invoked from the PRB which issued the ESTAE. It's almost like run-of-the-mill I/O hassles which can normally be handled and recovered from become unrecoverable when they occur when a complicated RB structure including non-problem state RBs such as SVRBs exists. Hey - (slaps hand on forehead) - maybe that's why the DCB Abend Exit is given flags to indicate an unrecoverable abend... So, in summary, given that SVRBs are running with a determination to abend the current task, I think only mighty strong ESTAE magic with more sophistication than is usual can forestall the event. Probably not the news you wanted to hear... Sorry.:( Cheers, Greg -- 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
Re: How recover from unrecoverable DCB ABEND?
NOT in the OPEN. During a GET. Sorry if I sound impatient. This is about the third or fourth time I have said during a GET in this thread. Thanks for your advice. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Greg Price Sent: Saturday, December 09, 2006 4:43 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How recover from unrecoverable DCB ABEND? In my meagre experience, abends such as EOV which are normally recoverable in QSAM I/O (which I guess means GET and/or PUT, oh and PUTX of course but that should be unlikely given that PUTX is an update-in-place of a successfully read record) become unrecoverable when the same condition is encountered under the auspices of OPEN or CLOSE. So, given the comment that the problem may well have occurred while attempting to fetch the first block, I'd say that in this case the problem was encountered under the OPEN SVRB. If you find that a SYNAD exit can handle the situation, then well and good. But I think it was said that a SYNAD exit was employed to no avail. To me, the suggestion of an ESTAE with a RETRY made the most sense, in terms of attempting to recover from the abend with some degree of grace, but I don't know the details of how RETRY from an ESTAE works when the abend occurs in an RB invoked from the PRB which issued the ESTAE. It's almost like run-of-the-mill I/O hassles which can normally be handled and recovered from become unrecoverable when they occur when a complicated RB structure including non-problem state RBs such as SVRBs exists. Hey - (slaps hand on forehead) - maybe that's why the DCB Abend Exit is given flags to indicate an unrecoverable abend... So, in summary, given that SVRBs are running with a determination to abend the current task, I think only mighty strong ESTAE magic with more sophistication than is usual can forestall the event. -- 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
Re: How recover from unrecoverable DCB ABEND?
And I think you may be right. Further investigation reveals that BOTH the SYNAD and the ABEND exits are being driven, in that order. They share some common code, so that fact was a little obscured in the dump. Seeing as how the SYNAD exit can legally just branch somewhere in the main line (and the ABEND exit apparently cannot), I think the answer is to have the SYNAD do that rather than returning to its caller (QSAM). I come from the school of thought that says subroutines ought to return to their callers, not branch somewhere else, so I have resisted that approach. The SYNAD routine will have to do this under all circumstances, because I don't know how it will recognize the case if I return to QSAM it will trigger a DCB ABEND that will be unrecoverable. It's going to take some work, making sure we branch to the right place for the circumstances that triggered it and getting the registers and save areas sorted out, buy hey! that's what assembler programming is all about, right? Recovering with an ESTAE would be difficult because this is just a minor subroutine that is part of a product written primarily in higher-level language. It seems a shame to set up and tear down an ESTAE in some cases around individual GETs. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Black Sent: Friday, December 08, 2006 3:53 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How recover from unrecoverable DCB ABEND? I think that SYNAD will meet your need -- 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
How recover from unrecoverable DCB ABEND?
Well, I got no replies to my first stab at this question. I've done some more testing. Let me try pruning the question down and see what happens. I've got an assembler subroutine that does QSAM I/O. One of its features is a DCB ABEND exit, the purpose of which is to allow for graceful termination in the event of an I/O error. For ABEND S002-04 (reading an FB dataset as VB -- not an implausible user error), the option byte at the address in R1 + 3 is x'80' -- in other words, there are NO acceptable options: not okay to recover, not okay to ignore, not okay to delay. What IS the recommended action in this case? What should the DCB ABEND exit do so that the program could wind things down gracefully? Returning from the ABEND exit to the address in R14 results in an ugly ending. Among other things, due to how other routines over which I have no immediate control do things, I end up with a (misleading) SC03 on an unrelated DCB that gets FREEMAINed without closing. Branching out of the DCB ABEND exit back into the mainline does not appear to be permissible -- DFSMS Using Data Sets says Most exit routines described in this chapter must return to their caller. The only two exceptions are the end-of-data and error analysis [I guess they mean SYNAD] routines. Is anyone doing so successfully? Any other suggestions? Charles Mills -- 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
Re: How recover from unrecoverable DCB ABEND?
Well, I got no replies to my first stab at this question. I've done some more testing. Let me try pruning the question down and see what happens. Check the manual. It says the abend exit is only valid during OPEN,CLOSE, and EOV. -- 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
Re: How recover from unrecoverable DCB ABEND?
1. Au contraire, I don't think it says that. 2. In any event, DFSMS is calling it when it is calling it, and that's during a GET. I'm getting the ABEND exit invoked for an S002-04 condition, which is clearly a read-type situation. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Day Sent: Friday, December 08, 2006 10:14 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How recover from unrecoverable DCB ABEND? Well, I got no replies to my first stab at this question. I've done some more testing. Let me try pruning the question down and see what happens. Check the manual. It says the abend exit is only valid during OPEN,CLOSE, and EOV. -- 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
Re: How recover from unrecoverable DCB ABEND?
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D430/3.12.6?SHELF=DGT2BK41DT=20040624112123 1. Au contraire, I don't think it says that. 1.6 manual. - Original Message - From: Charles Mills [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Friday, December 08, 2006 12:18 PM Subject: Re: How recover from unrecoverable DCB ABEND? 1. Au contraire, I don't think it says that. 2. In any event, DFSMS is calling it when it is calling it, and that's during a GET. I'm getting the ABEND exit invoked for an S002-04 condition, which is clearly a read-type situation. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Day Sent: Friday, December 08, 2006 10:14 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How recover from unrecoverable DCB ABEND? Well, I got no replies to my first stab at this question. I've done some more testing. Let me try pruning the question down and see what happens. Check the manual. It says the abend exit is only valid during OPEN,CLOSE, and EOV. -- 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
Re: How recover from unrecoverable DCB ABEND?
An EOV would, for an input file of course, be driven by a GET. On Fri, 8 Dec 2006 14:08:49 -0600, David Day wrote: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D430/3.12.6? SHELF=DGT2BK41DT=20040624112123 1. Au contraire, I don't think it says that. 1.6 manual. - Original Message - From: Charles Mills To: IBM-MAIN@BAMA.UA.EDU Sent: Friday, December 08, 2006 12:18 PM Subject: Re: How recover from unrecoverable DCB ABEND? 1. Au contraire, I don't think it says that. 2. In any event, DFSMS is calling it when it is calling it, and that's during a GET. I'm getting the ABEND exit invoked for an S002-04 condition, which is clearly a read-type situation. -- Tom Schmidt Madison, WI -- 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
Re: How recover from unrecoverable DCB ABEND?
1. Au contraire, I don't think it says that. It seems pretty clear to me: The DCB ABEND exit is provided to give you some options regarding the action you want the system to take when a condition occurs that may result in abnormal termination of your task. This exit can be taken any time an abend condition occurs during the process of opening, closing, or handling an end-of-volume condition for a DCB associated with your task. The exit is taken only for determinate errors that the system can associate with the DCB. 2. In any event, DFSMS is calling it when it is calling it, and that's during a GET. I don't think so I'm getting the ABEND exit invoked for an S002-04 condition, which is clearly a read-type situation. All the ABENDs listed in the doc are for OPEN x13, CLOSE x14, or EOV x37. I don't think that a s002 would invoke it. Have you considered a SYNAD exit if you goal is to shutdown gracefully after an I/O error? It ONLY includes errors reading or writiing data blocks, not O/C/E errors like the ABEND exit. Actually you might need both to recover from label errors as well as data errors. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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
Re: How recover from unrecoverable DCB ABEND?
I've got an assembler subroutine that does QSAM I/O. One of its features is a DCB ABEND exit, the purpose of which is to allow for graceful termination in the event of an I/O error. For ABEND S002-04 (reading an FB dataset as VB -- not an implausible user error), the option byte at the address in R1 + 3 is x'80' -- in other words, there are NO acceptable options: not okay to recover, not okay to ignore, not okay to delay. The above is from the original post. This does not sound to me as if it is a successful execution of QSAM GET to drive the EOV. I guess I just read it wrong. - Original Message - From: Tom Schmidt [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Friday, December 08, 2006 2:16 PM Subject: Re: How recover from unrecoverable DCB ABEND? An EOV would, for an input file of course, be driven by a GET. -- 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
Re: How recover from unrecoverable DCB ABEND?
Well, I see that it says This exit can be taken any time an abend condition occurs during the process of opening, closing, or handling an end-of-volume condition for a DCB associated with your task. But 1. It does NOT say it cannot be driven at other times. 2. The ABEN exit clearly IS being driven during a GET. No question about that. Read the description of S002-04. But I don't want this thread to deteriorate into a debate about what the manual does or does not say. I'd like some wise guidance with my problem, which is what is it reasonable to do when QSAM says you have no options? How do you provide for an orderly and non-misleading termination? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Day Sent: Friday, December 08, 2006 12:09 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How recover from unrecoverable DCB ABEND? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D430/3.12.6?S HELF=DGT2BK41DT=20040624112123 1. Au contraire, I don't think it says that. -- 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
Re: How recover from unrecoverable DCB ABEND?
It would but that's not what's happening. It's a GET (of the first block, probably). Read the description of S002-04. Clearly an error that would happen during a GET. And that's when it is happening. Even if we posit that it's happening during an OPEN or a CLOSE, my original question still remains: The QSAM bits say no return option is acceptable. What might one do to provide for an orderly termination, including the closing of other open datasets? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Schmidt Sent: Friday, December 08, 2006 12:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How recover from unrecoverable DCB ABEND? An EOV would, for an input file of course, be driven by a GET. -- 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
Re: How recover from unrecoverable DCB ABEND?
Bruce, thanks. My reading of the manual is that Figure 164. Conditions for Which Recovery Can Be Attempted (is that what you are referring to? Apologies if I misunderstood) is not an exhaustive list of DCB ABEND conditions, but rather a list of ABENDs for which recovery (attempting to bypass the error and permit an OPEN or CLOSE to continue to a useful conclusion) may be attempted. In any event, in my program, it's clearly happening for an S002-04, which is a GET error, not an OPEN or CLOSE error. I also have a SYNAD exit in the program. Both exits work correctly for their respective conditions, generally. For ABEND S002-04 the option byte at the address in R1 + 3 is x'80' -- in other words, there are NO acceptable options: not okay to recover, not okay to ignore, not okay to delay. My question is well then, what SHOULD I do in this situation to provide for a graceful termination, including the closing of other unrelated DCBs? I'm not a QSAM newbie. I've been writing assembler QSAM I/O since 1969, and DCB exits since (guessing) 1985. My question is not gee, how about this DCB ABEND thing? but rather the specific question above. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Black Sent: Friday, December 08, 2006 12:41 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How recover from unrecoverable DCB ABEND? 1. Au contraire, I don't think it says that. It seems pretty clear to me: The DCB ABEND exit is provided to give you some options regarding the action you want the system to take when a condition occurs that may result in abnormal termination of your task. This exit can be taken any time an abend condition occurs during the process of opening, closing, or handling an end-of-volume condition for a DCB associated with your task. The exit is taken only for determinate errors that the system can associate with the DCB. 2. In any event, DFSMS is calling it when it is calling it, and that's during a GET. I don't think so I'm getting the ABEND exit invoked for an S002-04 condition, which is clearly a read-type situation. All the ABENDs listed in the doc are for OPEN x13, CLOSE x14, or EOV x37. I don't think that a s002 would invoke it. Have you considered a SYNAD exit if you goal is to shutdown gracefully after an I/O error? It ONLY includes errors reading or writiing data blocks, not O/C/E errors like the ABEND exit. Actually you might need both to recover from label errors as well as data errors. -- 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
Re: How recover from unrecoverable DCB ABEND?
On Fri, 8 Dec 2006 14:46:13 -0600, David Day retorted: I've got an assembler subroutine that does QSAM I/O. One of its features is a DCB ABEND exit, the purpose of which is to allow for graceful termination in the event of an I/O error. For ABEND S002-04 (reading an FB dataset as VB -- not an implausible user error), the option byte at the address in R1 + 3 is x'80' -- in other words, there are NO acceptable options: not okay to recover, not okay to ignore, not okay to delay. The above is from the original post. This does not sound to me as if it is a successful execution of QSAM GET to drive the EOV. I guess I just read it wrong. While the Using Data Sets publication certainly says what you said (in your earlier post), the Messages manual for IEC036I 002-04 says that the user's DCB ABEND Exit routine is taken if one is provided. -- Tom Schmidt Madison, WI -- 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
Re: How recover from unrecoverable DCB ABEND?
Charles Mills wrote: Well, I see that it says This exit can be taken any time an abend condition occurs during the process of opening, closing, or handling an end-of-volume condition for a DCB associated with your task. My guess is that this is a subtle attempt to inform the reader not to rely on register contents in the exit. About eight years ago I was assigned to do maintenance on an existing commercial product, and kept getting weird 0Cx abends on some tests. The program had DCB and SYNAD exits, in which the original coder assumed that the base registers were the same in the exits as in the code requesting the I/O. That's true (by poor design?) in general, but not when a problem occurs during O/C/EOV processing, causing the exit to be taken with O/C/EOV registers. Gerhard Postpischil Bradford, VT -- 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
Re: How recover from unrecoverable DCB ABEND?
And indeed it is! Now what do I do? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Schmidt Sent: Friday, December 08, 2006 1:19 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How recover from unrecoverable DCB ABEND? While the Using Data Sets publication certainly says what you said (in your earlier post), the Messages manual for IEC036I 002-04 says that the user's DCB ABEND Exit routine is taken if one is provided. -- 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
Re: How recover from unrecoverable DCB ABEND?
On Fri, 8 Dec 2006 13:45:12 -0800, Charles Mills wrote: And indeed it is! Now what do I do? Well, what would you LIKE to do? (You can't ignore it, you can't recover and you can't delay... in the DCB ABEND routine.) Have you tried specifying a SYNAD exit for that DCB yet? -- Tom Schmidt Madison, WI -- 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
Re: How recover from unrecoverable DCB ABEND?
Yes. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Schmidt Sent: Friday, December 08, 2006 2:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How recover from unrecoverable DCB ABEND? On Fri, 8 Dec 2006 13:45:12 -0800, Charles Mills wrote: And indeed it is! Now what do I do? Well, what would you LIKE to do? (You can't ignore it, you can't recover and you can't delay... in the DCB ABEND routine.) Have you tried specifying a SYNAD exit for that DCB yet? -- 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
Re: How recover from unrecoverable DCB ABEND?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills Sent: Friday, December 08, 2006 4:38 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How recover from unrecoverable DCB ABEND? Yes. Charles snip Off the top of my head, you may have to use your DCB ABEND exit to set a flag or two. The return and allow the code to ABEND. Meanwhile, you will need to have an ESTAE that will recognize the ABEND and RETRY at the address you decide on. You can then cleanly shutdown anything you need to, including doing CLOSE processing. Later, Steve Thompson -- 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
Re: How recover from unrecoverable DCB ABEND?
Yes but why would want a program that is given an input file with the wrong RECFM to do anything but abend? Aren't abends the polite way to say to the job submitter thou hast fubared? IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 12/08/2006 06:03:27 PM: Off the top of my head, you may have to use your DCB ABEND exit to set a flag or two. The return and allow the code to ABEND. Meanwhile, you will need to have an ESTAE that will recognize the ABEND and RETRY at the address you decide on. You can then cleanly shutdown anything you need to, including doing CLOSE processing. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- 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
Re: How recover from unrecoverable DCB ABEND?
Golly, as I did say in the OP, yes, I would like to end, and soon, but (1) with a little more grace and my message and (2) with a chance to close other DCBs, thereby avoiding a misleading SC03 on an unrelated DCB. Customers are intolerant of vendor programs ABENDing, in my experience. You ABEND, they call you up and say this piece of cr*p is blowing up again. You get calls from management about your program is blowing up. You put out a message and end with an RC 16, they read the message (much of the time) and try to fix the problem, or at worst call up and ask why they are getting the error and how to avoid it. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kirk Talman Sent: Friday, December 08, 2006 3:09 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How recover from unrecoverable DCB ABEND? Yes but why would want a program that is given an input file with the wrong RECFM to do anything but abend? Aren't abends the polite way to say to the job submitter thou hast fubared? -- 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
Re: How recover from unrecoverable DCB ABEND?
I think that SYNAD will meet your need -- Bruce Black Senior Software Developer Innovation Data Processing -- 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
