In a message dated 5/25/2005 9:53:33 P.M. Central Daylight Time, [EMAIL PROTECTED] writes:
>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. 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." Regardless of the access method involved, the residual count only applies to the last CCW that started being executed by the control unit. See Principles of Operation, subject residual count. In the latest z/Architecture version, see Subchannel-Status Word, where the residual count is called "Count" or "Count Field". The book says "Bit positions 16-31 of word 2 [of the Subchannel-Status Word] contain the residual count. The count is to be used in conjunction with the original count specified in the last CCW...". The residual count is not developed and stored until the channel program ends, whether normally or abnormally. Here the phrase "last CCW" does not mean the last CCW in the channel program as built by the user. It means the last CCW that was executed, and there may well be many more CCWs chained after this point that never executed. The channel does not know or care whether the block has been defined in z/OS's metadata as being FBS or FB. The channel only knows on a read command that the CCW wanted to read 800 bytes, e.g., and the control unit only supplied 720, because the block on the track, whether FBS, FB, U, VBS, or whatever has a count field that says only 720 bytes exist for that record's data field. What the channel does next depends on whether the CCW has the suppress length indication flag bit on. 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. If the SLI flag is off, the channel program is interrupted and a residual count of 80 is stored in the SCSW in this hypothetical case. This is the only way that software knows how many bytes are read on a short block, and software cannot know in the general case where a short block might appear. In specific cases, however, such as for spanned or standard length blocks written by standard IBM access methods, a short block is only created and expected at the end of the file. There is a read track command (X'DE' command code) that generates a pseudo-count field of 8 bytes of X'FF' to indicate where the track data ended, but this is not the CCW command code built by BPAM or BSAM to read one block. 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. 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." The example I gave above is a PDS member that is not created by standard IBM access methods. 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. 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, and a residual count of 80 will be stored in the SCSW to alert software that a short block was read. 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. A spanned record format causes standard access methods to assume that all blocks are the same length, whether FS, FBS, VS, or VBS. When such a file or PDS member is created, all blocks will have the same length except possibly the last one before the EOF 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
