> -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills > Sent: Thursday, January 11, 2007 1:22 PM > To: [email protected] > Subject: Re: What is "command reject" trying to tell me? > > > Thanks for your thorough answer. I think the full answer is that I am > reading a file that has been created but not written into, > and so yes, the > DSCB-1 may well say BLKSIZE=0. > > You know, to return to an earlier thread, I would call this a > user-hostile > approach on MVS's part. Why would not a designer interested > in producing > user-accessible software, a system that would not have a > reputation for > being hostile, why would he not put a bit in the DSCB-1 that > said whether or > not the file had ever been opened and closed for output? And > if the flag > were not set, have open input put out a readable message that > said "you > can't open for input a file that has never been written"? Or > at least to not > attempt the impossible, reading a block length of zero, but > instead to put > out a "you can't read a block size of zero" message? > > When a programmer has to have more skill than I to figure out > that he is > simply trying to read a file that effectively does not exist, > it's no wonder > this platform has a reputation with management as being > expensive to develop > for. (I'm not bragging; you can flame me for the above if you > want, but the > fact is, I have 40 years of on and off experience with down and dirty > assembler programming. A stupid, easy-to-commit error should > not require the > ability to decode CCW's and make inferential leaps to solve it.) > > Charles
Well, in the past, I have "recovered" an accidently deleted file by reallocating it in the exact track used via the ABSTR keyword in the DD. If allocate did put in a flag that OPEN used to deny access to the dataset until it was "written to", then my (very old time) recovery would not have worked. That may be why it was done. Now, a return code from OPEN that indicated the file was "uninitialized" but still allowed I/O would have been nice. But IBM couldn't think of everything back in the 70s when this all started up. A lot of the "silliness" that we put up with is due to design decisions made long, long ago in a different era with different constraints. 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. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. ---------------------------------------------------------------------- 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
