IBM Mainframe Forum

Perhaps I am missing something obvious, or perhaps this is not exactly a "beginners" question, but here goes anyway. I have a routine that opens a file for output. The characteristics of the input file (or sometimes other factors) are to be used as a default for the output file (RECFM, LRECL, etc.) unless they are specified on the DCB in the JCL for the file, or if the file is already cataloged with these characteristics. I use RDJFCB to try to evaluate the File JCL, although some characteristics are apparently not available until the file is actually opened. One of the things I check is the indicator to see whether or not the file is already cataloged, which appears to be working properly. For the most part, what I have works well. My problem is coming from the use of a file assigned in a CLIST. The ALLOC command in the CLIST apparently catalogs the file, but not necessarily with characteristics for RECFM, etc. This means that my test to bypass assigning these characteristics for a cataloged file isn't quite working as I would like, because my assumption that a cataloged file will have these characteristics already is not necessarily true. When I try to open the file under this circumstance, I abend with a S013. Ideally, I would like to detect this error in the program, avoiding a system abend, and based on that failure recognize that I need to set these characteristics after all and try to open it again. I did define a SYNAD routine, but that seems not to get control in this instance. Any thoughts?

You have actually raised 3 issues here.

• Specifying data set attributes using the TSO ALLOCATE command.
• Using the JFCB
• "Trapping" S013 ABENDS

Specifying data set attributes using the TSO ALLOCATE command.

The BLOCK (used to specify data set average physical record size) and BLKSIZE (used to set the DCB block size) parameters conflict. Don't mix them if possible. The ALLOCATE command effectively stores the BLOCK parameter as a BLKSIZE. I don't really know, for sure, what happens if both are specified.

Using the JFCB

I'm not sure I understand your comment about using the JFCB to determine if a data set has been modified. For your purpose I would use the JFCB as the source for a data set name and volume serial to be used with the OBTAIN macro to get the format 1 DSCB for the data set, and then to check if the data set has been modified. Obviously this won't work for tape.

"Trapping" S013 ABENDS

You can't "trap" S013 ABENDs in a useful fashion. What you can do is use the DCB open exit to obtain the RECFM, LRECL and BLKSIZE after OPEN has merged the DCB, JFCB and data set label, and correct, if necessary, these parameters. Before system determined BLKSIZE I had elaborate exits to do the equivalent of system determined BLKSIZE. There is one problen with this approach: replacement values for the RECFM, LRECL and BLKSIZE are reversed merged into the JFCB, which isn't always desirable. If you are going to copy DCB attributes from another DCB, the open exit is a good place to do this. I would set the RECFM and LRECL before the OPEN, and use the open exit to deal with the BLKSIZE.

As Mr. Scherrer says, hope this helps.

I may not have been clear. The RDJCB only lets me know if the DCB values have been set in the JCL. And that seems to be working properly. The problem is that people are so accustomed to letting the utility assign the file characteristics in batch, that they get lazy. My immediate solution has been to specify the RECFM and LRECL in the ALLOC within the CLIST, which works very nicely. I was hoping, however, to try to support even this lazy usage, if possible. The reason I get the S013 is that when I open it, the system realizes that the LRECL is 0. But I cannot see that it is 0 until I try to open it. Because the result of this attempt is S013, my program never gets a chance to correct it.

OPEN takes the DCB OPEN exit before it decides to S013 the OPEN. I'm not certain if your use of RDJFCB is all that useful here.

The RDJCB macro is extremely useful when the utility is executing in regular batch mode, to detect any DCB values specified in the JCL. When being run in Foreground by a CLIST, it really isn't very useful because all it is telling me is that the file is cataloged.

I am not sure what you are referring to as the OPEN exit. What I was hoping for was a way for the utility to get control back instead of really getting the S013 abend, and evaluting on its own that the OPEN did not work. That would let me see that the LRECL was 0, in which case I would override it with values determined as appropriate defaults by the utilty and OPEN the file again, this time properly. Currently, I have no opportunity of accomplishing this.

jsavoye wrote:The RDJCB macro is extremely useful when the utility is executing in regular batch mode, to detect any DCB values specified in the JCL. ...

Or the RECFM, LRECL and BLKSIZE parameters of the TSO ALLOCATE command.

jsavoye wrote:... When being run in Foreground by a CLIST, it really isn't very useful because all it is telling me is that the file is cataloged. ...

Actually it isn't even telling you that because the ALLOCATE comand or its equivalents, such as ISPF panels, can access uncataloged data data sets.

jsavoye wrote:... I am not sure what you are referring to as the OPEN exit. What I was hoping for was a way for the utility to get control back instead of really getting the S013 abend, and evaluting on its own that the OPEN did not work. That would let me see that the LRECL was 0, in which case I would override it with values determined as appropriate defaults by the utilty and OPEN the file again, this time properly. Currently, I have no opportunity of accomplishing this.

This is the exact same OPEN exit discussed a couple of months ago in your topic about unlike concatenation.

Except that my problem only occurs when they dont' specify a RECFM, LRECL, etc. on the ALLOC in the CLIST. (If these are specified, there is no problem.) Any file designated by an ALLOC in CLIST is being flagged as cataloged as far as the control blocks are concerned. (Perhaps I am misinterpreting something here.)

Ultimately, I resolved my previous issue without resorting to any OPEN EXIT.

jsavoye wrote:Except that my problem only occurs when they dont' specify a RECFM, LRECL, etc. on the ALLOC in the CLIST. (If these are specified, there is no problem.) Any file designated by an ALLOC in CLIST is being flagged as cataloged as far as the control blocks are concerned. (Perhaps I am misinterpreting something here.)

Ultimately, I resolved my previous issue without resorting to any OPEN EXIT.

The DCB exit can fill in or correct anything in the DCB being opened. Remember the order of the merge.

• The DCB macro as specified in your program.
• Values specified in JCL if not already in the DCB.
• Values in the data set label if not already in the DCB.

The open exit sees these values after the merge is complete; any changes it makes overrides anything from the merge.

Sigh . . . It appears that I will have to revisit what I hoped I had avoided.

Now I remember why I abandoned this approach in my previous attempts. I still cannot get a DCB EXIT that is successfully invoked, let alone to do what I need it to do. Part of this is undoubtedly the extra complications of what the utility needs to do, but overall, I think this problem will just have to stay a problem.