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 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of (IBM Mainframe Discussion List) Sent: Thursday, January 11, 2007 5:10 AM To: [email protected] Subject: Re: What is "command reject" trying to tell me? Sense byte 0 (x'80') tells you that there was a command reject. Sense byte 7 (x'04') tells you the reason for the command reject in the right nibble. Reason 4 means invalid parameter, which is why the next error message displays all the parameters. Unfortunately, a lot of educated guesswork and practical experience is often necessary to divine which parameter is wrong and why it is wrong. There are about 100 different reasons why you might have an invalid parameter error (or maybe even a lot more than 100). It would be really nice if IBM would provide another byte or two somewhere else in the vast amount of sense data that they generate that tells the precise reason for the invalid parameter, but they don't. The first byte (x'86') of parameters means to orient to the data area of the record whose ID matches the contents of bytes 8-12 (x'00AC000000') and then read the number of records contained in byte 3 (x'04'). The exact manner in which those records will be read is to be determined by the read CCWs that come after the locate record (x'47') command; i.e., they could be read CKD, read data, or other kinds of read commands. The x'80' in byte 1 means that bytes 14-15 will contain a non-zero value that is how many bytes will be read on each of the 4 following read commands. Bytes 14-15 contain x'0000', which will cause a command reject all by itself (there might be another reason, though, but probaby not if the CCW chain is built by QSAM). From the 2105 (ESS) Command Reference book: "Transfer Length Factor: When byte 1, bit 0 is '0', bytes 14-15 must contain zeros; if bytes 14-15 are not zero, Locate Record is terminated with status that includes unit check (Command Reject, format X'04', Invalid Parameter)." Why do these bytes contain 0? Beats me. Perhaps you are trying to read a file whose Format 1 DSCB says the block size is 0, or maybe the F1 DSCB's values are being overridden with JCL that says //ddnamexyz DD DCB=BLKSIZE=0. Perhaps someone with more QSAM experience than I can explain the presence of the 0 in the transfer length factor field. ---------------------------------------------------------------------- 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
