1. I did not get any message other than the message in the OP -- specifically, no S013. I'm not intentionally leaving anything out of the story. As I look at the code now, the input DCB OPEN exit provides a maximum size BUFL if it is still zero at the time the exit is drive -- that code was no doubt inserted to work around some other DFSMS obscurity -- so that plug of DCBBUFL may be masking the S013.
2. By "working until recently" I did not mean to imply that this particular specific situation changed. I meant that the subroutine was tested and generally working in a wide variety of circumstances -- that it was not new code -- and that apparently due to other changes in a product that is undergoing ongoing development, the subroutine was now encountering this situation. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of (IBM Mainframe Discussion List) Sent: Monday, January 22, 2007 7:49 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: What is "command reject" trying to tell me? In a message dated 1/22/2007 7:30:12 A.M. Central Standard Time, usenet5678 @ YAHOO.COM writes: >I'm not sure what to make of this. My understanding is that if you OPEN >a BSAM or QSAM DCB for INPUT and the F1-DSCB has BLKSIZE=0, >you get an S013-34 abend. ... >Gilbert Saint-Flour The OP said he had an Assembler subroutine that does GETs with QSAM on a RECFM=FB DCB and that the code had been working until recently. IBM's doc [1] says "An error occurred during the processing of an OPEN macro." We don't know the LRECL or OPEN options other than input. Quite a few causes are listed, of which the following seem possible given only the OP's facts: (1) "The following combination was specified: QSAM, MACRF=GD or PD, and a RECFM value that is not VS, VBS, DS, or DBS." (2) "An OPEN macro instruction was issued for a data set with BLKSIZE and BUFL equal to 0. The system determined that it had to obtain buffers but was unable to do so." (3) "The following combination was specified: QSAM, LRECL=0, and a RECFM value that is not V or VB." (4) "The following combination was specified: QSAM and BLKSIZE=0. No nonzero BLKSIZE value was available from any source and the system could not determine one." I described in a previous post that the command reject was caused by the Locate Record's transfer length factor's being zero, and then speculated that this was caused by a zero blocksize. With the large number of options available with QSAM DASD I/O, and since the OP did not say he had gotten a S013-34, I think we can conclude that either (1) there are some combinations of operands that include BLKSIZE=0 that will not cause a S013-34 and will allow QSAM to try to do an I/O with an invalid transfer length factor in the Locate Record parameters or (2) there is something else that the OP did not tell us. ---------------------------------------------------------------------- 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
