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 cou
Bruce Black wrote:
>>
>>
>> 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
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
In <[EMAIL PROTECTED]>, on 06/01/2005
at 07:57 AM, Bill Fairchild <[EMAIL PROTECTED]> said:
>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.
Most messages contain words with their plain En
In <[EMAIL PROTECTED]>, on
06/01/2005
at 10:00 PM, Greg Price <[EMAIL PROTECTED]> said:
>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
>
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
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 residua
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
In a message dated 5/27/2005 7:27:55 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
the channel programs for DASD do not in general rely on the residual counts
and do not in general stop on short blocks.
Shmuel, you are right about the channel programs. I had forgotten that
SAM-E
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 no
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 disjointe
]
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
--- 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 ---
Unfortunatel
ibly 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 re
hem 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 wou
ck. 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
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 RE
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
In <[EMAIL PROTECTED]>, on
05/24/2005
at 06:53 AM, James Cotter <[EMAIL PROTECTED]> said:
>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
On Tue, 2005-05-24 at 06:53 +0100, James Cotter wrote:
> if a member doesn't completely fill a block, how do you determine this
> is in the program
>From some old code I have endlessly rotating in an old library:
*
* CALCULATE SIZE OF
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 part
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.
You are working with BSAM and addressing one of the fundamentals of BSAM:
you must do your own deblocking and prepare to be returned a short block
and, not only for the last block but also for intermediate blocks.
Check the BSAM manuals/chapters.
Kees.
"James Cotter" <[EMAIL PROTECTED]> wrote i
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.
James
Binyamin Dissen <[EMAIL PROTECTED]> wrote:
On Tue, 24 May 2005 06:53:00 +0100 James Cotter
wro
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
Hi
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
d
26 matches
Mail list logo
