Re: Reading a PDS (why couldn't you have just said Read Count?)
In a recent note, Greg Price said: Date: Sat, 4 Jun 2005 15:22:48 +1000 I agree about the WRITE. With READ if the BDW indicates a length larger than DCBBLKSI the a WRONG LENGTH RECORD error condition is raised. If the BDW length does not exceed DCBBLKSI then the residual count is set to be consistent with the BDW length. So, if BDW exceeds DCBBLKSI-RBC, but does not exceed DCBBLKSI, the RBC is adjusted, and the programmer is given core trash as the remainder of the physical record to process? And if BDW is less than DCBBLKSI-RBC, adjusting the RBC has the effect of quietly discarding the unexpected bytes? If it had been my design, I would have chosen to err on the side of caution, and raised WRONG LENGTH RECORD error in all those cases. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Reading a PDS (why couldn't you have just said Read Count?)
What about the (unlikely) case where someone writes a VB data set to DASD and uses the wrong data length? Or would SAM catch the error before you saw it? With SAM I don't believe a bad length is possible. QSAM contructs the blocks from the records provided and controls the BDW and the write length. BSAM I believe uses the BDW to determine the write length. So in either case, the record length in the disk count field will match the BDW length (short of a bug in SAM, of course). With EXCP, you can of course write anything you like, so you can create the error. I am not sure what SAM would do on reading -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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
Re: Reading a PDS (why couldn't you have just said Read Count?)
In [EMAIL PROTECTED], on 05/28/2005 at 09:46 PM, Bill Fairchild [EMAIL PROTECTED] said: Shmuel, you are right about the channel programs. I had forgotten that SAM-E changed the CCWs of SAM The complexity actually goes back farther. OS/360 used Search Previous for quite a while before Search Direct (OPTCD=Z) came along, and with search previous you read the count area of the current record before you read the data area. The SAM channel programs for DASD are like the old Adventure game; a maze of twisty options, all different. All of them ultimately involve reading the count area. I used GTF to trace BPAM READs of a two-block PDS member containing a short FB block and an EOF block. There's another complexity; the first READ after a POINT is slightly different. I suspect that having no Read Count in front of the Read Data in this chain indicates that the next record is expected to be an EOF, since the previous record was short. I doubt it; run the trace with three blocks and three READ macros and see what you get. The phrase residual count applies only to the last CCW executed in a chain. Data lengths of blocks read prior to the end of the chain are not fake residual counts. By fake residual count I meant a value stacsed in the CSW of an ICN or IOB by the access method rather than being copied from a real CSW. There is no such thing as a fake residual count, What would you call a value calculated from the BLKSIZE and the count area and plugged into the CSW field of an IOB? That sure sounds like a fake residual length to me. unless it is somewhere in an IBM lab, along with their channel subsystem that can handle CCWs with virtual addresses pointing to paged out data, You're right; ECPS:VSE is a figment of my imagination. When a chain ends, for whatever reason and with or without SLI on the last CCW, the residual count is determined by the channel subsystem in most cases as: CCW byte count of the last CCW being executed minus the number of bytes successfully transferred by the last CCW. It is stored in the IRB, from which software can transfer it into some place the application can find it, such as perhaps the DCBBLKSI field. Software can transfer lots of things from lots of places, not just from the IRB. WTF? It's an old idiom meaning don't try to teach somebody something that they've known for years. Without a Read Count command it would be a very bad idea, We're talking about SAM, which for DASD does use a Read Count CCW. No, you didn't explain how they do it. I said that you should look at the actual CCW chain. Given your background, it did not occur to me that you should need assistance in reading it. I believe that what you may have meant, but didn't say, was that I didn't explain which CCWs I was describing for my chain to read my hypothetical string of full and short blocks. You made a general statement: If a channel program has 8 or more read CCWs that all attempt to read 800 bytes and they all have the SLI flag on, the channel program will read all 7 of these blocks in (yes, the EOF record is also a DASD block) and the final status of the I/O will be unit exception (because of the EOF block/record) with a residual count of 800 (because 0 bytes were read when 800 were expected). There will be no indication from the I/O operation that short blocks were read on blocks # 3 and 6, and the only reason the channel program stopped is because the EOF record's being read caused a Unit Exception condition. You didn't write that the specific channel program you were thinking of had that limitation. If I were using only Read Data CCWs, Then it wouldn't have anything to do with SAM and it wouldn't have anything to do with what could be done with other channel programs. Perhaps you meant to say that my unexplained CCW chain You didn't say that *your* unexplained CCW chain had that limitation; you made a universal claim, and a claim that is false for SAM to boot. I have been working with CCW chains, Residual Counts, and IRBs for decades. That's why I was shocked when you made such an elementary error. My error was in not knowing exactly what CCWs are generated by the access methods. No, your error was in making a general statement when that wasn't warranted; it would have been wrong even had SAM used your channel programs rather than the ones that it does use. You don't trust the IBM documentation? Sure I do; after I verify it. Which is what I did for the SAM channel programs more than three decades ago. I, on the other hand, have been looking at the CCW chains in SAM for decades. Then why weren't you aware that they make heavy use of Read Count? The GTF showed only one Read Data CCW and at least one Read Count CCW in each chain generated by a READ macro. That makes more than one read CCW. Now use a high value for DCBNCP and issue multiple READ macros before you do a CHECK and
Re: Reading a PDS (why couldn't you have just said Read Count?)
In a message dated 6/1/2005 5:57:21 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: There is no such thing as a fake residual count, What would you call a value calculated from the BLKSIZE and the count area and plugged into the CSW field of an IOB? That sure sounds like a fake residual length to me. You're the one with all the documentation that you trust after verifying. I hope you'll let me stop guessing and tell me what IBM's books call it. I would call it a block size, since it is the size of the block. OTOH, the PoOps gives a precise definition of residual count, which has meaning for all device types and not just DASD, which has blocks of data, a concept not relevant for some other device types. When a 2-byte number from whatever source is moved into the field DCBBLKSI, what should we call it then? Fake block size? I, on the other hand, have been looking at the CCW chains in SAM for decades. Then why weren't you aware that they make heavy use of Read Count? I explained that, but you weren't paying attention. I said I had forgotten. I don't always remember everything forever once I become aware of it. The GTF showed only one Read Data CCW and at least one Read Count CCW in each chain generated by a READ macro. That makes more than one read CCW. Now use a high value for DCBNCP and issue multiple READ macros before you do a CHECK and observe what happens. I'm sorry, but further experiments are not very interesting, now that I know what my main mistake(s) was(were). It appears that you already know what happens. Perhaps you could simply reveal the answer, along with my requested explanation for why you did not use the secret words Read Data CCW much earlier, which would have short-circuited most of these posts. That was, after all, my main point in my last email. In fact, I even put it in the subject line so you would be sure to see it. Weren't you paying attention? Bill Fairchild -- 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
Re: Reading a PDS (why couldn't you have just said Read Count?)
Shmuel Metz , Seymour J. wrote: There is no such thing as a fake residual count, What would you call a value calculated from the BLKSIZE and the count area and plugged into the CSW field of an IOB? That sure sounds like a fake residual length to me. For example, with variable-length records the residual count in the IOB for BSAM/BPAM is DCBBLKSI minus the length in the BDW, even if the BDW length indicator is zapped to be smaller than the actual length of the block. I was going to report whenever the BDW indicated the wrong length when compared to the length ascertained from the residual count in a program once, but then found out that such an inconsistency was not really possible. Cheers, Greg P. -- 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
Re: Reading a PDS
Gerhard or others, Looking for a clarification. Am I to understand that IEBGENER and such will read blocks after a short block in a RECFM=FBS file? By definition the short block should signal a logical EOF. Chris Blaicher -Original Message- From: Gerhard [mailto:[EMAIL PROTECTED] Sent: Thursday, May 26, 2005 10:09 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Reading a PDS --- Bill Fairchild wrote: It is possible to have block lengths like the following in a PDS member containing FB data with blocksize 800 and LRECL 80: 800, 800, 720, 800, 800, 80, EOF. You would not find such a case in an file or PDS member with RECFM=FBS. --- end of quote --- Unfortunately that isn't correct. It's physically possible to create a sequential FBS data set with a short block, and later on add more data with DISP=MOD, making the data set unreadable. None of the systems I've worked tested for this or failed it. Gerhard Postpischil Bradford, VT -- 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
Re: Reading a PDS
In [EMAIL PROTECTED], on 05/26/2005 at 12:57 PM, Bill Fairchild [EMAIL PROTECTED] said: Shmuel (Seymour), you remove too much of the previous post's context and end up commenting on only one sentence, in which case your comments must always appear to be correct or sometimes disjointed if the previous reference is invisible. Here is what I said in my previous sentence that you left out of this one: Note that in the case of chained scheduling (DCBOPTCD=C) the residual count will only apply to the last block read. My comment is correct for what you wrote; the channel programs for DASD do not in general rely on the residual counts and do not in general stop on short blocks. Regardless of the access method involved, the residual count only applies to the last CCW that started being executed by the control unit. With SLI it applies to none of them. The fake residual counts inserted by the access method are not limited to the last block. See Principles of Operation, PoOps will not tell me what channel programs SAM constructs nor what processing SAM does after the I/O completes. Please don't teach your grandmother to suck eggs. If the SLI flag is on, the channel program will continue and the next block will be read. This is usually a very bad idea. Tell that to IBM: they've been doing it for decades, with correct results. This is the only way that software knows how many bytes are read on a short block, No it isn't, as I've already explained. Look at the CCW chains in storage and you will see how it works. and software cannot know in the general case My comment didn't refer to the general case, it referred to a specific case. For DASD the software knows how long the read was unless something is seriously wrong with the control unit. As I said in my penultimate earlier post, which you also omitted from your reply, Since this is a short block, if the member were created by standard IBM access methods we would expect the very next sequential block in the PDS to be an EOF block, but it might not be if the member was not created by standard IBM access methods. That is also incorrect; the TRUNC macro is standard. If a channel program has 8 or more read CCWs If the channel program is broken then I wouldn't expect it to give the correct results. IBM has code to read multiple blocks and correctly determine the lengths, and I've already explained how they do it. It's not rocket science. There will be no indication from the I/O operation that short blocks were read on blocks # 3 and 6, Then you didn't construct the correct CCW chain. There is an indication in the3 CCW chains that I described. If, however, a channel program has no SLI flags on in any of the read commands, then the channel program will stop when the 3rd block is read, That also depends on what is in the channel programs; there's more than one read opcode. The only way to know for sure what a channel program will do is to see the channel program, look at the byte count and flag bits on each CCW, and know what is on the track. You don't trust the IBM documentation? A spanned record format causes standard access methods to assume that all blocks are the same length, WTF? You've been around long enought to know the difference between spanned (VBS) and standard (FBS). Spanned is not and never has been fixed length. You may be referring to using the MULTACC keyword with DCBE. No, I'm referring to support much older than that, introduced in SAM-E and incorporated into DF/DS, then into DFP. It's around two decades old. It is not clear to me how this works, Obviously. I, on the other hand, have been looking at the CCW chains in SAM for decades. I've tried explaining how it works, but you haven't been paying attention. The Devil is in the details; look at the CCW chains that IBM actually uses, not what you're assuming that they use or that they should use. The same book, in the BSAM/BPAM READ macro description, says that the READ macro is to Read a Block, not read one or more blocks. Your point? What do you think happens when you issue multiple READ macros? I would expect a GTF trace of this case to show that there is only one read CCW in each channel program, however many such channel programs may have been started at the same time. That's the problem; YOU'RE RELYING ON YOUR EXPECTATIONS INSTEAD OF ACTUALLY LOOKING AT THE CHANNEL PROGRAMS. The Using Data Sets book has the section 3.6.7 Determining the Length of a Block when Reading with BSAM, BPAM, or BDAM which should answer the original poster's question adequately. If he reads it *carefully*. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive
Re: Reading a PDS
In [EMAIL PROTECTED], on 05/27/2005 at 09:32 AM, Blaicher, Chris [EMAIL PROTECTED] said: Looking for a clarification. Am I to understand that IEBGENER and such will read blocks after a short block in a RECFM=FBS file? By definition the short block should signal a logical EOF. I'm not sure whether IBM guaranties an EOF for a short block in an FBS data set, but they certainly state that it is an error and may lead to incorrect results. Forget about EOF; consider a program that uses BSAM to process such a data set with POINT, with a TTR calculation based on the fixed block size. Or consider what happens to the RPS calculation even if you have the correct TTR. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Reading a PDS
record. When read back in, the channel program will not have SLI flags on so that a short block can be detected. An FB block will not necessarily be full size (if, e.g., you do a TRUNC when creating it). You can transfer more than one block per I/O request in reading a PDS member (as chained scheduling would do), but you can't use BSAM to do it. Sure you can, and the documentation discusses how to do it. See if you can find an old copy of SAM-E logic, or read the discussion of DASD chained scheduling in SAM Logic for OS/VS2 R3.8 (MVS). You may be referring to using the MULTACC keyword with DCBE. See z/OS V1R6.0 DFSMS Macro Instructions for Data Sets. It is not clear to me how this works, but it appears that several READ macros, each of which transfers only one block, are queued up somehow until some threshold causes the access method to start all the I/Os at once. The same book, in the BSAM/BPAM READ macro description, says that the READ macro is to Read a Block, not read one or more blocks. I would expect a GTF trace of this case to show that there is only one read CCW in each channel program, however many such channel programs may have been started at the same time. The Using Data Sets book has the section 3.6.7 Determining the Length of a Block when Reading with BSAM, BPAM, or BDAM which should answer the original poster's question adequately. Bill Fairchild -- 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
Re: Reading a PDS
In a message dated 5/24/2005 10:11:26 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: In my previous post, I said to take the block size and subtract the residual count to determine how many bytes were read in. This is the only way to do it, No. You can get it from DCBLRECL for RECFM=U. Could be true. I don't know much about RECFM=U. At any rate, the access method subtracts the residual count from the max possible size to know what to store into DCBLRECL if RECFM=U. So this technique may not be the only way to do it, but it does work in all cases. Note that in the case of chained scheduling (DCBOPTCD=C) the residual count will only apply to the last block read. If N blocks are being read and one of them is short, the short block will cause the channel program to stop and the residual count will apply to the short block. All previous blocks are thus known to be full. The original poster, however, said he was using BSAM, which means no chained scheduling and only one block is read per I/O request. So the residual count method still works in this case. You can transfer more than one block per I/O request in reading a PDS member (as chained scheduling would do), but you can't use BSAM to do it. You would have to use QSAM or perhaps EXCP. Bill Fairchild -- 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
Re: Reading a PDS
In [EMAIL PROTECTED], on 05/25/2005 at 06:43 AM, Bill Fairchild [EMAIL PROTECTED] said: Could be true. I don't know much about RECFM=U. At any rate, the access method subtracts the residual count from the max possible size to know what to store into DCBLRECL if RECFM=U. That used to be the case way back when, except for OPTCD=C, but it stopped being the case with SAM-E. Now the actual length is extracted from the count area. A lot of processing takes place under the covers to make that transparent. If N blocks are being read and one of them is short, the short block will cause the channel program to stop and the residual count will apply to the short block. Perhaps for RECFM=FBS; certainly not for RECFM=FB. You can transfer more than one block per I/O request in reading a PDS member (as chained scheduling would do), but you can't use BSAM to do it. Sure you can, and the documentation discusses how to do it. See if you can find an old copy of SAM-E logic, or read the discussion of DASD chained scheduling in SAM Logic for OS/VS2 R3.8 (MVS). -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Reading a PDS
On Tue, 24 May 2005 06:53:00 +0100 James Cotter [EMAIL PROTECTED] wrote: :I'm reading a member from a FB LRECL 80 library having first located it via BLDL and FIND. I am issuing READ macros and I'm getting the EODAD routine entered, as expected, when I get to the end of the member. :What I would like to know is, if a member doesn't completely fill a block, how do you determine this is in the program - or rather, how do you determine the actual end of the member within the partially filled block?? :I have looked in the SMF Macro and Using Data Sets manuals but I can't see anything that explains this. You have to subtract the residual count from the IOB (which is pointed to by the DECB). It should be in the using data sets manual. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
Re: Reading a PDS
On Tue, 24 May 2005 07:52:32 +0100 James Cotter [EMAIL PROTECTED] wrote: :Thanks Binyamin. However, I have looked again at the z/OS v1.4 DFSMS using data sets' manual and I can't see this mentioned anywhere. I find this quite strange for something so fundamental. Look in using data sets. 3.6.7 Determining the Length of a Block when Reading with BSAM, BPAM, or BDAM :Binyamin Dissen [EMAIL PROTECTED] wrote: :On Tue, 24 May 2005 06:53:00 +0100 James Cotter :wrote: : ::I'm reading a member from a FB LRECL 80 library having first located it via BLDL and FIND. I am issuing READ macros and I'm getting the EODAD routine entered, as expected, when I get to the end of the member. : ::What I would like to know is, if a member doesn't completely fill a block, how do you determine this is in the program - or rather, how do you determine the actual end of the member within the partially filled block?? : ::I have looked in the SMF Macro and Using Data Sets manuals but I can't see anything that explains this. : :You have to subtract the residual count from the IOB (which is pointed to by :the DECB). : :It should be in the using data sets manual. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
Re: Reading a PDS
In a message dated 5/24/2005 12:53:43 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: What I would like to know is, if a member doesn't completely fill a block, how do you determine this is in the program - or rather, how do you determine the actual end of the member within the partially filled block?? The access method builds a CCW (Channel Command Word) to read one block with the maximum block size (aka record size) in the CCW's byte count. If it builds Format 0 CCWs, the byte count is in bytes 6-7 of the read CCW, else bytes 2-3 for a Format 1 CCW. When the I/O channel program runs, the DASD control unit attempts to read BLOCKSIZE number of bytes from the disk for that block (aka record). If exactly BLOCKSIZE bytes are contained in that block, then the residual count will be 0. If fewer than BLOCKSIZE bytes are in that block, which could occur anywhere within the member (except for the EOF block at the end), then the residual count will not be 0. In all cases, take BLOCKSIZE and subtract the residual count to determine how many bytes were read. The residual count is stored in the IOB after the I/O ends in the field IOBCSW+5 and BLOCKSIZE is in the DCB. For some reason IBM did not give the residual count field a name in the IOB DSECT. The comment simply says last two bytes of IOBCSW. The last two bytes of the CSW contain the residual count (see Principles of Operations). Expand the DCB DSECT and you should be able to find the blocksize field from the comment block size. You will know when an EOF block has been read because the Unit Exception bit (IOBUSB7) will be on in IOBUSTAT. It will not be on otherwise. The IOB is mapped with SYS1.MACLIB(IEZIOB) and the DCB with SYS1.MACLIB(DCB). I may have a field name or two wrong in the above, as it has been many years since I used an IOB, but the logic is correct: find the block size and subtract the residual count; and look for unit exception to indicate EOF. Bill Fairchild -- 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
Re: Reading a PDS
In [EMAIL PROTECTED], on 05/24/2005 at 01:20 PM, Bill Fairchild [EMAIL PROTECTED] said: In my previous post, I said to take the block size and subtract the residual count to determine how many bytes were read in. This is the only way to do it, No. You can get it from DCBLRECL for RECFM=U. Note also that there are restrictions[1] on using the residual count. [1] Though not, IMHO, onerous. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
