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 observe what
happens.
--
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
