I've been a long time away from the entrails of the storage management system, so this may be worth even less than the price you paid for it.
If SMS, and if DSORG=PS, then at allocation time, SMS will put a valid EOF marker at the beginning of the newly allocated DASD extent. Without knowing that the dataset is supposed to be physical sequential, SMS does nothing to the newly allocated DASD extent - because the space may be custom-formatted by the requestor using EXCP instead of a known access method. RECFM, BLKSIZE, and LRECL might mean something to your dataset, but mean nothing to the "semi-hysterical access method" I just dreamed up - so there's no reason to populate those fields for my "SHAM" file. And I want no EOF marker anywhere in my DASD extent (CA-DATACOM doesn't like them, either IIRC). Tom -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Charles Mills <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List <[email protected]> 01/16/2007 11:48 AM Please respond to IBM Mainframe Discussion List <[email protected]> To [email protected] cc Subject Re: What is "command reject" trying to tell me? > So, if you do things "the new way" with SMS, you would have gotten > the result you were desiring. The ball is in your court. I don't think so. The dataset IS SMS-managed, IIRC. The problem is not the lack of an EOF record, the problem is that QSAM sets itself up for failure by building a CCW with a length of zero (and so fails before ever reading or not reading an EOF record). The problem is not that the dataset has no data in it, but rather that it has never been opened for output and closed by a problem program. There is no RECFM etc. in the JCL because there should not have to be. The JCL is built by an automated process that rightly, IMHO, leaves decisions about RECFM, etc. up to the creating program -- a program that in the instant case did not create the dataset at all, for good reasons of its own. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Thursday, January 11, 2007 11:32 AM To: [email protected] Subject: Re: What is "command reject" trying to tell me? <snip> Now, if you were to create your dataset with a proper LRECL, BLKSIZE, DSORG, in the JCL and it had been SMS managed, allocation would have written an EOF marker at the beginning of the dataset and you would have gotten an immediate EOF when you tried to read it. So, if you do things "the new way" with SMS, you would have gotten the result you were desiring. The ball is in your court. ---------------------------------------------------------------------- ---------------------------------------------------------------------- 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
