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 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
