ASM370 - BPAM NCP=2 PURGE

Author

BPAM NCP=2 PURGE

Gilbert Saint-Flour

2004-03-19, 8:28 pm

Hello:

I am trying to fix an old bug (over 10 years) in one of my programs which
reads PDS members with NCP=2. I use the technique suggested in the DFP
Using Datasets manual, namely:

FIND DCB2,MEMBER,D
READ DECB1,SF,DCB2
READ DECB2,SF,DCB2
LOOP EQU *
CHECK DECB1
. . . process 1st buffer
READ DECB1
CHECK DECB2
. . . process 2nd buffer
READ DECB2
B LOOP
. . .
DCB2 DCB DSORG=PO,NCP=2,MACRF=R

This works fine as long as the program exits the loop via EODAD or SYNAD.
The problem arises when the program reads multiple members and decides to
exit the loop before EODAD or SYNAD to, in effect, "flush" the rest of the
member, leaving an outstanding READ which has not been CHECKed. The
program could, of course, issue a CHECK against the next DECB to wait for
completion, but I'd like to avoid that, for obvious performance reasons
(waiting may take a while and the data is of no interest to the program).

If I don't CHECK the last DECB, the program eventually hangs on a CHECK
macro when it tries to process other members. How long the program takes
to hang seems timing-dependent and doesn't occur all the time (or in the
same CHECK) in the real world, although I can recreate the problem
reliably on my P/390 when nothing else runs on it.

Issuing PURGE, even when it returns R15=0, seems to have some effect (I'd
be hard-pressed to say exactly what), but doesn't really solve the
problem:

XC NPPL,NPPL Clear NPPL
MVI NPPLOPT1,NPPLNPPL NPPL format
OI NPPLOPT1,NPPLDS purge one data set
OI NPPLOPT1,NPPLPOST post ECBs
MVC NPPLDSID+1(3),DCBDEBA COPY 24-BIT DEB ADDRESS TO NPPL
MVI NPPLCC,X'7F' COMP CODE
PURGE NPPL PURGE OUTSTANDING REQUESTS

Issuing TCLOSE doesn't seem to make any difference either.

I tried to look at the ICQE, the SAMB, the IOBs to see if I could trick my
way through a work-around, to no avail. My gut feeling is that FIND and
PURGE aren't enough to tell BPAM that it should reset the SAMB/ICQE/IOBs,
etc, the way it does when it hits CE/DE.

The problem has occured for over 10 years when NCP>1. When it happens,
people cancel the program and restart it after adding NCP=1 on the DD
statement. I tried to fix the problem ten years ago, but gave up.
I spent the last 4 days trying to fix it to no avail.

The program needs NCP>1 for performance, and be able to stop reading
certain members at any time. Can anyone help ? I haven't tried
MULTACC/MULTDSN yet. Could they help?

Thanks.

Gilbert Saint-Flour
http://gsf-soft.com/

Greg Price

2004-03-19, 8:28 pm

Gilbert,

I'll take a guess and say that you observe a hang
when you reuse a DECB that has not been CHECKed and
the triggered I/O has not completed. I'll say that
with the same program logic if the I/O completed
before you could reuse the DECB then no hang occurs.

This would fit in with your observations of timing
dependence.

I don't know what you should do.

What I would do is issue a CHECK for any DECB for
which I've issued an I/O macro and just wait it out.
In fact, I think I've seen code (not written by me)
which issues a WAIT macro for all outstanding DECBs
for which the data being transferred (if any) is no
longer of interest.

I suppose the advantage of the WAIT macro is that it
verifies that the event has completed but will not
trigger entry into any DCB-related exit routine.

IIRC the ECB is at the start of the DECB, but verify
that before you code up the WAIT logic (if you do).

Considering code complexity vs. potential time saved
I would not be interested in exploring I/O purge logic.
However, if you think that would be lots of fun, don't
let me discourage you. :)

Cheers,
Greg

Binyamin Dissen

2004-03-19, 8:28 pm

On Wed, 14 Jan 2004 16:27:06 +1100 Greg Price <grogon@groginon.com> wrote:

:>I'll take a guess and say that you observe a hang
:>when you reuse a DECB that has not been CHECKed and
:>the triggered I/O has not completed. I'll say that
:>with the same program logic if the I/O completed
:>before you could reuse the DECB then no hang occurs.

:>This would fit in with your observations of timing
:>dependence.

:>I don't know what you should do.

:>What I would do is issue a CHECK for any DECB for
:>which I've issued an I/O macro and just wait it out.
:>In fact, I think I've seen code (not written by me)
:>which issues a WAIT macro for all outstanding DECBs
:>for which the data being transferred (if any) is no
:>longer of interest.

:>I suppose the advantage of the WAIT macro is that it
:>verifies that the event has completed but will not
:>trigger entry into any DCB-related exit routine.

The bigger advantage of the WAIT macro is if you have several pending events
you can get control whenever any of them complete.

CHECK is limited to a single DECB.

:>IIRC the ECB is at the start of the DECB, but verify
:>that before you code up the WAIT logic (if you do).

:>Considering code complexity vs. potential time saved
:>I would not be interested in exploring I/O purge logic.
:>However, if you think that would be lots of fun, don't
:>let me discourage you. :)

--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

Sven Pran

2004-03-19, 8:28 pm

I have a problem understanding why your code has been designed the
way it is. (And I seriously believe that your "problem" is simply a result
of the design! You do not seem to cater for channel end or device end
interrupts that may occur after you close the "connection" to the dataset).

As far as I can see you are reading one or more members in partitioned
datasets and each member is read sequentially but not necessarily to its
end. So why not implement the standard LIOCS logic for such operations?

Open:
locate the member (sequential file) to be read and initiate control blocks
Start reading the first record into one of the two I/O buffers (READ)
return to caller

Get:
if the read operation is still in progress wait for this to complete
(CHECK)
(and handle any exception that may be signalled)
start reading the next record into the other I/O buffer
return to caller with the address of the just completed buffer

Close:
if a read operation is in progress wait for this to complete
finish up control blocks
return to caller.

I cannot see any advantage in initiating a read for the second record
before the caller begins processing the first and so on. On the contrary
there is for instance a significant possibility that the channel in certain
cases may reorder the channel programs queue and in fact retrieve
the second record before the first because of hardware conditions
invisible to you.

But I may be wrong - after all it is some fifteen or twenty years since
I was writing channel programs myself.

regards Sven

"Gilbert Saint-Flour" <usenet5678@yahoo.com> wrote in message
news:pan.2004.01.13.17.06.09.150878@yahoo.com...
> Hello:
>
> I am trying to fix an old bug (over 10 years) in one of my programs which
> reads PDS members with NCP=2. I use the technique suggested in the DFP
> Using Datasets manual, namely:
>
> FIND DCB2,MEMBER,D
> READ DECB1,SF,DCB2
> READ DECB2,SF,DCB2
> LOOP EQU *
> CHECK DECB1
> . . . process 1st buffer
> READ DECB1
> CHECK DECB2
> . . . process 2nd buffer
> READ DECB2
> B LOOP
> . . .
> DCB2 DCB DSORG=PO,NCP=2,MACRF=R
>
> This works fine as long as the program exits the loop via EODAD or SYNAD.
> The problem arises when the program reads multiple members and decides to
> exit the loop before EODAD or SYNAD to, in effect, "flush" the rest of the
> member, leaving an outstanding READ which has not been CHECKed. The
> program could, of course, issue a CHECK against the next DECB to wait for
> completion, but I'd like to avoid that, for obvious performance reasons
> (waiting may take a while and the data is of no interest to the program).
>
> If I don't CHECK the last DECB, the program eventually hangs on a CHECK
> macro when it tries to process other members. How long the program takes
> to hang seems timing-dependent and doesn't occur all the time (or in the
> same CHECK) in the real world, although I can recreate the problem
> reliably on my P/390 when nothing else runs on it.
>
> Issuing PURGE, even when it returns R15=0, seems to have some effect (I'd
> be hard-pressed to say exactly what), but doesn't really solve the
> problem:
>
> XC NPPL,NPPL Clear NPPL
> MVI NPPLOPT1,NPPLNPPL NPPL format
> OI NPPLOPT1,NPPLDS purge one data set
> OI NPPLOPT1,NPPLPOST post ECBs
> MVC NPPLDSID+1(3),DCBDEBA COPY 24-BIT DEB ADDRESS TO NPPL
> MVI NPPLCC,X'7F' COMP CODE
> PURGE NPPL PURGE OUTSTANDING REQUESTS
>
> Issuing TCLOSE doesn't seem to make any difference either.
>
> I tried to look at the ICQE, the SAMB, the IOBs to see if I could trick my
> way through a work-around, to no avail. My gut feeling is that FIND and
> PURGE aren't enough to tell BPAM that it should reset the SAMB/ICQE/IOBs,
> etc, the way it does when it hits CE/DE.
>
> The problem has occured for over 10 years when NCP>1. When it happens,
> people cancel the program and restart it after adding NCP=1 on the DD
> statement. I tried to fix the problem ten years ago, but gave up.
> I spent the last 4 days trying to fix it to no avail.
>
> The program needs NCP>1 for performance, and be able to stop reading
> certain members at any time. Can anyone help ? I haven't tried
> MULTACC/MULTDSN yet. Could they help?
>
> Thanks.
>
> Gilbert Saint-Flour
> http://gsf-soft.com/
>
>

Robert Bonomi

2004-03-19, 8:28 pm

In article <pan.2004.01.13.17.06.09.150878@yahoo.com>,
Gilbert Saint-Flour <usenet5678@yahoo.com> wrote:
>Hello:
>
>I am trying to fix an old bug (over 10 years) in one of my programs which
>reads PDS members with NCP=2. I use the technique suggested in the DFP
>Using Datasets manual, namely:
>
> FIND DCB2,MEMBER,D
> READ DECB1,SF,DCB2
> READ DECB2,SF,DCB2
>LOOP EQU *
> CHECK DECB1
> . . . process 1st buffer
> READ DECB1
> CHECK DECB2
> . . . process 2nd buffer
> READ DECB2
> B LOOP
> . . .
>DCB2 DCB DSORG=PO,NCP=2,MACRF=R
>
>This works fine as long as the program exits the loop via EODAD or SYNAD.
>The problem arises when the program reads multiple members and decides to
>exit the loop before EODAD or SYNAD to, in effect, "flush" the rest of the
>member, leaving an outstanding READ which has not been CHECKed. The
>program could, of course, issue a CHECK against the next DECB to wait for
>completion, but I'd like to avoid that, for obvious performance reasons
>(waiting may take a while and the data is of no interest to the program).
>
>If I don't CHECK the last DECB, the program eventually hangs on a CHECK
>macro when it tries to process other members. How long the program takes
>to hang seems timing-dependent and doesn't occur all the time (or in the
>same CHECK) in the real world, although I can recreate the problem
>reliably on my P/390 when nothing else runs on it.

Criminently! The causation (UnCHECKed DECB) is identified, the remedy (CHECK
the unCHECKed DECB)is identified, and the 'obvious' fix hasn't been implemented
in TEN YEARS.

FIND DCB2,MEMBER,D
READ DECB1,SF,DCB2[color=darkred]
READ DECB2,SF,DCB2[color=darkred]
LOOP EQU *[color=darkred]
CHECK DECB1
. . . process 1st buffer
READ DECB1[color=darkred]
CHECK DECB2
. . . process 2nd buffer
READ DECB2[color=darkred]
B LOOP

{{ loop exit }}[color=darkred]
| READ DECB1
| [clear 'flag1']
| [if 'flag2' set]
| READ DECB2
| [clear 'flag2']

This is *ELEMENTARY* 'housekeeping' logic for asynchronous operations

Sven Pran

2004-03-19, 8:28 pm

If I remember anything at all from my IOCS programming you probably
mean CHECK - not READ in your sample code at loop exit?

regards Sven

"Robert Bonomi" wrote
.............
> Criminently! The causation (UnCHECKed DECB) is identified, the remedy
(CHECK
> the unCHECKed DECB)is identified, and the 'obvious' fix hasn't been
implemented
> in TEN YEARS.
>
> FIND DCB2,MEMBER,D
> READ DECB1,SF,DCB2
> READ DECB2,SF,DCB2
> LOOP EQU *
> CHECK DECB1
> . . . process 1st buffer
> READ DECB1
> CHECK DECB2
> . . . process 2nd buffer
> READ DECB2
> B LOOP
>
> {{ loop exit }}
> | READ DECB1 <------------- CHECK (I suppose)???
> | [clear 'flag1']
> | [if 'flag2' set]
> | READ DECB2 <------------- CHECK (I suppose)???
> | [clear 'flag2']
>
>
> This is *ELEMENTARY* 'housekeeping' logic for asynchronous operations
>

Robert Bonomi

2004-03-19, 8:28 pm

In article <TQeNb.1302$hd.27458@news2.e.nsc.no>,
Sven Pran <no.direct@mail.please> wrote:
>If I remember anything at all from my IOCS programming you probably
>mean CHECK - not READ in your sample code at loop exit?

Spoilsport! By deliberately putting an 'obvious' bug in the illustration, it
forces somebody trying to use it to _understand_ what they're actually doing.

*grin*

That said, the 'feature' got into this illustration because I cut-and-pasted
the _wrong_ line. And you are absolutely correct, that is what I .meant_.

One of the nice things about writing code for _people_ to read, instead of
computers -- "Do what I meant, not what I said" *does* work most of the time!

Thanks for the catch.

>
>regards Sven
>
>"Robert Bonomi" wrote
>............
>(CHECK
>implemented
>
>

Gilbert Saint-Flour

2004-03-19, 8:28 pm

On Wed, 14 Jan 2004 16:55:19 +0100, Sven Pran wrote:

> I have a problem understanding why your code has been designed the way
> it is.

For performance reasons.

> (And I seriously believe that your "problem" is simply a result of the
> design! You do not seem to cater for channel end or device end
> interrupts that may occur after you close the "connection" to the
> dataset).

I do not take care of CE/DE directly, you're right, and that's probably my
problem and I started this thread to find some help to solve it. When I
issue PURGE then FIND, SAM could take the hint and take care of CE/DE for
me - apparently, it doesn't.

> As far as I can see you are reading one or more members in partitioned
> datasets and each member is read sequentially but not necessarily to its
> end. So why not implement the standard LIOCS logic for such operations?

Again, for performance.

My example only showed NCP=2 for simplicity. In the real world of
my programs, NCP is calculated from the BLKSIZE to not exceed the old
SAM-E constants (NCP=30,BUFF=240K) that are hard-coded in the SAMB. As a
result, the NCP value varies between 8 and 30.

On my ADCD system, SYS1.MACLIB is defined with BLKSIZE=6160, which results
on the program using NCP=30. If I'm only interested in processing one or
two blocks for each member on the average, not issuing CHECKs for dropped
READs results in significant savings in elapsed and connect times.

Another reason for trying to find a solution, of course, is the challenge.

Gilbert Saint-Flour
http://gsf-soft.com/

Gilbert Saint-Flour

2004-03-19, 8:28 pm

On Wed, 14 Jan 2004 18:17:37 +0100, Sven Pran wrote:
[color=darkred]

Thanks, but this is not helping, perhaps because I didn't make myself
perfectly clear: I'm looking for a way to AVOID issuing the extra CHECKs.

Gilbert Saint-Flour
http://gsf-soft.com/

glen herrmannsfeldt

2004-03-19, 8:28 pm

Gilbert Saint-Flour wrote:

> On Wed, 14 Jan 2004 16:55:19 +0100, Sven Pran wrote:

(snip)

> Again, for performance.

> My example only showed NCP=2 for simplicity. In the real world of
> my programs, NCP is calculated from the BLKSIZE to not exceed the old
> SAM-E constants (NCP=30,BUFF=240K) that are hard-coded in the SAMB. As a
> result, the NCP value varies between 8 and 30.

(snip)

> Another reason for trying to find a solution, of course, is the challenge.

So performance, and not necessarily size.

Can you do a multiple WAIT for all the ECB's, and then CHECK each
one after it completes? That is, have multiple sets of NCP
buffers, so you can start the next before the previous ones are
finished. I don't know how far ahead you could get,
but that might require significantly more buffers.

It does seem like there should be a way to tell it that you
are done with one.

-- glen

Sven Pran

2004-03-19, 8:28 pm

"Gilbert Saint-Flour" <usenet5678@yahoo.com> wrote in message
news:pan.2004.01.14.20.37.34.619235@yahoo.com...
> On Wed, 14 Jan 2004 16:55:19 +0100, Sven Pran wrote:
>
>
> For performance reasons.
>
>
> I do not take care of CE/DE directly, you're right, and that's probably my
> problem and I started this thread to find some help to solve it. When I
> issue PURGE then FIND, SAM could take the hint and take care of CE/DE for
> me - apparently, it doesn't.
>
>
> Again, for performance.
>
> My example only showed NCP=2 for simplicity. In the real world of
> my programs, NCP is calculated from the BLKSIZE to not exceed the old
> SAM-E constants (NCP=30,BUFF=240K) that are hard-coded in the SAMB. As a
> result, the NCP value varies between 8 and 30.
>
> On my ADCD system, SYS1.MACLIB is defined with BLKSIZE=6160, which results
> on the program using NCP=30. If I'm only interested in processing one or
> two blocks for each member on the average, not issuing CHECKs for dropped
> READs results in significant savings in elapsed and connect times.
>
> Another reason for trying to find a solution, of course, is the challenge.

Have you verified that you get an improvement in performance by coding this
way
instead of using standard sequential LIOCS logic?

You may be surprised, and you may doubt me, but when processing a dataset
(like a member in a PDS) sequentially there is only one way to improve
performance
beyond the LIOCS coding I described and that is by having all the records
preloaded
in memory so that you avoid disk accesses entirely when processing data.

The point is that because a disk device is unable to process more than one
channel
program at the same time there is nothing to save by issuing another READ
for the
same device while another READ is still pending. This holds true even when
you have
several different access paths to the same device because the device only
has one set
of head assemblies.

So sorry pal, I don't think I buy your reasoning!

regards Sven

Sven Pran

2004-03-19, 8:28 pm

Xref: kermit comp.lang.asm370:8104

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:VaiNb.52555$sv6.127618@attbi_s52...
> Gilbert Saint-Flour wrote:
>
>
> (snip)
>
>
a[color=darkred]
>
> (snip)
>
challenge.[color=darkred]
>
> So performance, and not necessarily size.
>
> Can you do a multiple WAIT for all the ECB's, and then CHECK each
> one after it completes? That is, have multiple sets of NCP
> buffers, so you can start the next before the previous ones are
> finished. I don't know how far ahead you could get,
> but that might require significantly more buffers.
>
> It does seem like there should be a way to tell it that you
> are done with one.

He can, but that will not help him.

A typical application where you wait on multiple ECB's is TSO where you
do not know which ECB will fire next (it depends upon which user presses
an attention or interrupt key on his terminal), but when an ECB fires you
process the interrupt for that ECB and then return to your multiple wait.

Sven

Sven Pran

2004-03-19, 8:28 pm

"Gilbert Saint-Flour" <usenet5678@yahoo.com> wrote in message
news:pan.2004.01.14.20.44.53.29119@yahoo.com...
> On Wed, 14 Jan 2004 18:17:37 +0100, Sven Pran wrote:
>
>
> Thanks, but this is not helping, perhaps because I didn't make myself
> perfectly clear: I'm looking for a way to AVOID issuing the extra CHECKs.
>
> Gilbert Saint-Flour

Any asyncronously Started IO requires completion with for instance CHECK.

A fundamental rule when programming is to avoid testing a program until it
works,
any program should be tested until it works in compliance with the rules for
the
operating system!

Sven

Peter H.

2004-03-19, 8:28 pm

[color=darkred]
The point is that because a disk device is unable to process more than one
channel program at the same time there is nothing to save by issuing another
READ for the same device while another READ is still pending.[color=darkred]

The access method, probably through its startio appendage, but certainly
coordinated with its channel end appendage, is supposed to concatenate the
multiple channel programs, if possible. Otherwise, these will execute
sequentially and independently.

Steve Webb

2004-03-19, 8:28 pm

"Sven Pran" <no.direct@mail.please> wrote:

(snip)
>
>The point is that because a disk device is unable to process more than one
>channel
>program at the same time there is nothing to save by issuing another READ
>for the
>same device while another READ is still pending. This holds true even when
>you have
>several different access paths to the same device because the device only
>has one set
>of head assemblies.
>

I believe that there is something to be saved. When the second READ is
issued, the I/O will be queued since it's unlikely that the first READ
will have completed. At best the device will be processing the first
READ, at worst the device will be processing some other job's request
and the first READ's request will already be queued.

The point is that the second request is queued as soon as possible,
therefore minimising the time during which other jobs can get their
own I/O request on the queue and holding up 'our' request. As you
know, on busy disks being used by many users simultaneously, IOSqueue
time can be a significant part of the response time, if performance is
important we need to minimise it as much as possible.

Just my two bit's worth, Steve

glen herrmannsfeldt

2004-03-19, 8:28 pm

Steve Webb wrote:

(snip)

> I believe that there is something to be saved. When the second READ is
> issued, the I/O will be queued since it's unlikely that the first READ
> will have completed. At best the device will be processing the first
> READ, at worst the device will be processing some other job's request
> and the first READ's request will already be queued.

> The point is that the second request is queued as soon as possible,
> therefore minimising the time during which other jobs can get their
> own I/O request on the queue and holding up 'our' request. As you
> know, on busy disks being used by many users simultaneously, IOSqueue
> time can be a significant part of the response time, if performance is
> important we need to minimise it as much as possible.

I would think either doing CHECK for the previous reads, or ignoring
them would then have the same result, that the READ stays in the queue.

There is also the question of how to get old READs out of the queue,
when the result is no longer needed.

-- glen

Peter H.

2004-03-19, 8:28 pm

[color=darkred]
There is also the question of how to get old READs out of the queue,
when the result is no longer needed.[color=darkred]

PURGE.

Sven Pran

2004-03-19, 8:28 pm

"Steve Webb" <steve@webbsfamily.freeserve.co.uk> wrote in message
news:6v6g00161la0nnvj9lbloitps6394po9lj@
4ax.com...
> "Sven Pran" <no.direct@mail.please> wrote:
>
> (snip)
one[color=darkred]
when[color=darkred]
>
> I believe that there is something to be saved. When the second READ is
> issued, the I/O will be queued since it's unlikely that the first READ
> will have completed. At best the device will be processing the first
> READ, at worst the device will be processing some other job's request
> and the first READ's request will already be queued.
>
> The point is that the second request is queued as soon as possible,
> therefore minimising the time during which other jobs can get their
> own I/O request on the queue and holding up 'our' request. As you
> know, on busy disks being used by many users simultaneously, IOSqueue
> time can be a significant part of the response time, if performance is
> important we need to minimise it as much as possible.
>
> Just my two bit's worth, Steve
>
Quite relevant and correct.

What you "forget" is that the time saved for "our" job by making record two
available in this manner is right away lost while waiting for record three,
and
so on. The other I/O requests not making it into the queue in front of our
record two request will most certainly make it before record three etc.

What will indeed save time is writing the channel programs using multiple
read
CCW's so that you can retrieve all records on a track with just one CCW
string,
but the effect of this is minimized once you have block sizes greater than
say
one fourth of the track size. (I worked with this kind of channel
programming
some fifteen to twenty years ago, but after we started using VSAM techniques
it was no longer worth the effort!)

Sven

Peter H.

2004-03-19, 8:28 pm

[color=darkred]
What will indeed save time is writing the channel programs using multiple read
CCW's so that you can retrieve all records on a track with just one CCW string
....[color=darkred]

A general purpose channel program string to do this is ...

Search ID=1
TIC *-8
R-CKD Record 1
R-CKD Record 2
....
R-CKD Record 255
NOP

.... and this will read every record on a track in one revolution, with a half
revolution of latency for the first record read.

If you want to read additional tracks, change the NOP to a TIC to an additional
channel program string for such additional tracks.

With proper design of a DIE for program-controlled interruptions, you only need
two or three such strings to read every record on a drive.

Steve Webb

2004-03-19, 8:28 pm

"Sven Pran" <no.direct@mail.please> wrote:

>
>"Steve Webb" <steve@webbsfamily.freeserve.co.uk> wrote in message
> news:6v6g00161la0nnvj9lbloitps6394po9lj@
4ax.com...
>one
>when
>Quite relevant and correct.
>
>What you "forget" is that the time saved for "our" job by making record two
>available in this manner is right away lost while waiting for record three,
>and
>so on. The other I/O requests not making it into the queue in front of our
>record two request will most certainly make it before record three etc.
>
>What will indeed save time is writing the channel programs using multiple
>read
>CCW's so that you can retrieve all records on a track with just one CCW
>string,
>but the effect of this is minimized once you have block sizes greater than
>say
>one fourth of the track size. (I worked with this kind of channel
>programming
>some fifteen to twenty years ago, but after we started using VSAM techniques
>it was no longer worth the effort!)
>
>Sven
>
I know that there's nothing that our program can do to affect the rate
at which other jobs access the device we're using, but we can minimise
that effect by making sure we get reads queued as soon as possible.
The time savings might be small, but if performance is important we
might as well try our best. Actually, didn't the original author say
that he might issue as many as 30 READs before the first CHECK ? That
would almost certainly put at least 29 IOBs on the logical channel
queue straight away, 30 if the device is already busy.

Regards, Steve

Steve Webb

2004-03-19, 8:28 pm

peterh5322@aol.comminch (Peter H.) wrote:

>
>What will indeed save time is writing the channel programs using multiple read
>CCW's so that you can retrieve all records on a track with just one CCW string
>...
>
>A general purpose channel program string to do this is ...
>
>Search ID=1
>TIC *-8
>R-CKD Record 1
>R-CKD Record 2
>...
>R-CKD Record 255
>NOP
>
>... and this will read every record on a track in one revolution, with a half
>revolution of latency for the first record read.
>
>If you want to read additional tracks, change the NOP to a TIC to an additional
>channel program string for such additional tracks.
>
>With proper design of a DIE for program-controlled interruptions, you only need
>two or three such strings to read every record on a drive.

The problem with full track reads is that this is a PDS we're dealing
with and that involves all sorts of messy track formats. There'll be
any number of full size blocks, short blocks and end-of-file counts.
If the controller will handle it, I guess Read Track is the best CCW
to use in the circumstances. Along with some cacheing and coding to
prevent rereading a track for a subsequent member's data if said
member's data has already been read.

Regards, Steve

glen herrmannsfeldt

2004-03-19, 8:28 pm

Steve Webb wrote:

(snip)

> The problem with full track reads is that this is a PDS we're dealing
> with and that involves all sorts of messy track formats. There'll be
> any number of full size blocks, short blocks and end-of-file counts.
> If the controller will handle it, I guess Read Track is the best CCW
> to use in the circumstances. Along with some cacheing and coding to
> prevent rereading a track for a subsequent member's data if said
> member's data has already been read.

It should be possible to do that, though it sounds more like EXCP
to me.

In any case, he should sort the directory so that the members can
be accessed in disk address order, but he probably already does that.

What does happen if you issue 30 READs for a two block PDS member?

At what point is it figured out that many of those are after EOF?
(I forget if the number of blocks is in the directory, as that would
make it much easier.)

-- glen

Peter H.

2004-03-19, 8:28 pm

[color=darkred]
The problem with full track reads is that this is a PDS we're dealing with and
that involves all sorts of messy track formats. There'll be any number of full
size blocks, short blocks and end-of-file counts.[color=darkred]

No problem at all, either for the infamous "Squish" program (Bell Labs; to
de-frag an entire S/370 volume in one pass) or for FDR.

FDR sued Bell Labs for its use of this particular channel program, but, as with
everything Bell Labs invents, a lab book existed which proved that Bell
engineers had invented the method before FDR ever thought of it.

[color=darkred]
If the controller will handle it, I guess Read Track is the best CCW to use in
the circumstances.[color=darkred]

Not necessary. Nor is this a good solution.

The 256 R-CKD CCW string is the general case, NOT Read Track.

Sure, you're going to have a lot of fix-ups with short blocks, but only the
actual end-of-member is going to cause a UNEX.

The Fixup is in the DIE.

Peter H.

2004-03-19, 8:28 pm

[color=darkred]
What does happen if you issue 30 READs for a two block PDS member?[color=darkred]

CE-DE-UNEX after the file mark, which would be the third block of this member.

Binyamin Dissen

2004-03-19, 8:28 pm

On 20 Jan 2004 18:05:52 GMT peterh5322@aol.comminch (Peter H.) wrote:

:>What does happen if you issue 30 READs for a two block PDS member?

:>CE-DE-UNEX after the file mark, which would be the third block of this member.

And no need to CHECK the remaining DECB's.

--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

Peter H.

2004-03-19, 8:28 pm

>CE-DE-UNEX after the file mark, which would be the third block of this member.

And no need to CHECK the remaining DECB's.[color=darkred]

I don't do READs/WRITEs or GETs/PUTs for high-performance applications, I do
EXCPs (occasionally) or STARTIOs (usually).

glen herrmannsfeldt

2004-03-19, 8:28 pm

Binyamin Dissen wrote:

> On 20 Jan 2004 18:05:52 GMT peterh5322@aol.comminch (Peter H.) wrote:
>
> :>What does happen if you issue 30 READs for a two block PDS member?
>
> :>CE-DE-UNEX after the file mark, which would be the third block of this member.
>
> And no need to CHECK the remaining DECB's.

But what does it look like at the CCW level.

Do the 30 READs generate 30 channel programs, each set to read one
block of the member?

Then the READs are automatically canceled when EOF is detected
on the third one?

Otherwise, the READs would be left there to read blocks of
subsequent members that weren't supposed to be READ.

-- glen

Binyamin Dissen

2004-03-19, 8:28 pm

On Wed, 21 Jan 2004 09:28:58 GMT glen herrmannsfeldt <gah@ugcs.caltech.edu>
wrote:

:>Binyamin Dissen wrote:

:>> On 20 Jan 2004 18:05:52 GMT peterh5322@aol.comminch (Peter H.) wrote:

:>> :>What does happen if you issue 30 READs for a two block PDS member?

:>> :>CE-DE-UNEX after the file mark, which would be the third block of this member.

:>> And no need to CHECK the remaining DECB's.

:>But what does it look like at the CCW level.

:>Do the 30 READs generate 30 channel programs, each set to read one
:>block of the member?

From one to three (in this case), depending on scheduling. The control program
may combine them.

:>Then the READs are automatically canceled when EOF is detected
:>on the third one?

Yes. BSAM will not process the other pending READs.

:>Otherwise, the READs would be left there to read blocks of
:>subsequent members that weren't supposed to be READ.

They are not processed.

--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

Sven Pran

2004-03-19, 8:28 pm

"Peter H." <peterh5322@aol.comminch> wrote in message
news:20040120130552.17062.00000443@mb-m03.aol.com...
>
> What does happen if you issue 30 READs for a two block PDS member?
>
> CE-DE-UNEX after the file mark, which would be the third block of this
member.
>

If you try a trick like that you must also have code to cater for the
possibility of physical
records being present on the track after an EOF marker. Such records will be
read
without any exception.

Yes, I know this shouldn't happen but it has been known to occur, and while
it will not
affect "standard" LIOCS coding at all it may certainly upset "smart" PIOCS
coding.

Incidentally, a channel program trying to read a non-existent block will
take at least
one full revolution of the disk, on the average one and a half. And then you
will get the
unit and channel exceptions which must be handled.

Sven

Peter H.

2004-03-19, 8:28 pm

[color=darkred]
Incidentally, a channel program trying to read a non existent block will take
at least one full revolution of the disk, on the average one and a half. And
then you will get the unit and channel exceptions which must be handled.[color=darkred]

Of course, because the Search ID Equal command will not be satisfied, and that
takes at least one revolution to determine.

At least the controller is smart enough to terminate the command after one
rev.

Sven Pran

2004-03-19, 8:28 pm

"Peter H." <peterh5322@aol.comminch> wrote in message
news:20040121132108.11422.00000402@mb-m05.aol.com...
>
> Incidentally, a channel program trying to read a non existent block will
take
> at least one full revolution of the disk, on the average one and a half.
And
> then you will get the unit and channel exceptions which must be handled.
>
> Of course, because the Search ID Equal command will not be satisfied, and
that
> takes at least one revolution to determine.
>
> At least the controller is smart enough to terminate the command after
one
> rev.

According to architecture an unsatisfied search command is signalled when
the home address marker is sensed a second time without a search hit.

Sven

David Bond

2004-03-19, 8:28 pm

Does anyone use real DASD anymore where the concept of a "revolution"
matters? I know it doesn't on an RVA and I would hazard a guess that it is
an obsolete concept on everything else too. I know that the RVA and similar
devices have to emulate "revolutions", but that is just for compatibility
sake. In reality an entire track image is read into memory if it isn't
already there. There is no rotational delay in searching memory. The
underlying disk format has no relationship to the CKD track images.

Besides, BSAM will use Locate Record, not Search ID Equal on ECKD. Isn't
everything ECKD now?

David Bond - Tachyon Software LLC - http://www.tachyonsoft.com

"Peter H." wrote ...
> Of course, because the Search ID Equal command will not be satisfied, and
that
> takes at least one revolution to determine.

Peter H.

2004-03-19, 8:28 pm

[color=darkred]
Besides, BSAM will use Locate Record, not Search ID Equal on ECKD. Isn't
everything ECKD now?[color=darkred]

Sure, on a 3990 or equivalent, but someone experienced enough to write channel
programs of this type also knows that S

/S-F-M/TIC/Search-Id-Eq (pre-ECKD) is
an implicit feature of Def-Ext/Loc-Rec (ECKD; and is more or less directly
translatable).

Sponsored Links