Re: Bsam VS Qsam for VB records... RDW corruption

[Campbell Jay]

2 threads going here.
IBM is investigating.

IBM has a dump of the bad block.
Length is 31373.
BDW good in the buffer.
Bad when written.
Ongoing.

Jay Campbell
IBM OS Support Section

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of retired mainframer
Sent: Tuesday, July 19, 2016 7:44 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Bsam VS Qsam for VB records

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Reichman Joseph
> Sent: Tuesday, July 19, 2016 11:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Bsam VS Qsam for VB records
> 
> Thanks for all your help I really understand the problem thing is the 
> file is huge and I don’t know by what factor DFSMS blocked and if the 
> blocking is consistent meaning always by the same factor

Since you already posted that you have no data class active and a null SMS 
configuration, it is unlikely that DFSMS has any effect on block size.  If the 
data was written with QSAM, then QSAM performed the blocking (per the DCB 
parameters specified on the DD statement used to identify the output dataset) 
as well as constructing the RDWs and BDW.

You also posted that the problem was with the BDW and not the RDWs.  What do 
you think the problem is?  How did you determine that?  Can you post the first 
8 bytes of the block in question (BDW+RDW, no proprietary data)?

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[retired mainframer]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Reichman Joseph
> Sent: Tuesday, July 19, 2016 11:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Bsam VS Qsam for VB records
> 
> Thanks for all your help I really understand the problem thing is the file is 
> huge and I don’t
> know by what factor DFSMS blocked and if the blocking is consistent meaning 
> always by
> the same factor

Since you already posted that you have no data class active and a null SMS 
configuration, it is unlikely that DFSMS has any effect on block size.  If the 
data was written with QSAM, then QSAM performed the blocking (per the DCB 
parameters specified on the DD statement used to identify the output dataset) 
as well as constructing the RDWs and BDW.

You also posted that the problem was with the BDW and not the RDWs.  What do 
you think the problem is?  How did you determine that?  Can you post the first 
8 bytes of the block in question (BDW+RDW, no proprietary data)?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Charles Mills]

Easy to do by accident:

- a valid VB dataset
- open and write DISP=MOD,RECFM=FB (erroneous JCL or program with hard-coded 
DCB)
- open and read with explicit RECFM=VB in JCL or program
- crash and burn

Easy enough to do when hastily cobbling JCL together from different sources. 
You typically end up with EBCDIC characters where the RDW is supposed to be.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Tuesday, July 19, 2016 3:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Bsam VS Qsam for VB records

I previously acknowledged that the data looks OK.

No, it is not an attempt to "extend" a block. It is to write a lump of data 
which, once the "correction" has been done (else the data can't be read as a VB 
anyway) will appear to be a VB "block", but which will start with binary zeros. 
Someone had commented that they didn't know how a BDW with zero length could be 
created. It wasn't done in this case, but here's a way it could be done. Not by 
*really* writing a block with a zero BDW, but sticking in a lump of data which 
will later *look like* a block (very superficially) but will presumably cause 
something weird to ensue.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Bsam VS Qsam for VB records

[Bill Woodger]

I previously acknowledged that the data looks OK.

No, it is not an attempt to "extend" a block. It is to write a lump of data 
which, once the "correction" has been done (else the data can't be read as a VB 
anyway) will appear to be a VB "block", but which will start with binary zeros. 
Someone had commented that they didn't know how a BDW with zero length could be 
created. It wasn't done in this case, but here's a way it could be done. Not by 
*really* writing a block with a zero BDW, but sticking in a lump of data which 
will later *look like* a block (very superficially) but will presumably cause 
something weird to ensue.

Requires deliberation, or accidental use of wrong LRECL/RECFM (other than 
expected) with DISP=MOD and then the "fix" (correctl LRECL/RECFM) with DISP=MOD 
and add at least one more record). A variation of the "corrupt a loadlib by 
writing a source to it".

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Paul Gilmartin]

On Tue, 19 Jul 2016 16:14:20 -0500, Bill Woodger wrote:

>DISP=MOD does lead to a way to accidentally (or deliberately, as an exercise) 
>create a "zero" BDW. With RECFM=F/FB/U and some LRECL, specified on the DD, 
>write a lump of data with two bytes of binary zeros. Then with DISP=MOD again, 
>and the "normal" RECFM/LRECL, write a good record. Then try to read the data.
>
I don't believe DISP=MOD will ever extend an existing block if that's what
you were expecting; it will always start a new block.

Tricky to do accidentally, but sometimes you find someone who errs, and then 
tries to "correct" without realising the full consequences.
>
That sort of thing should always be done with a copy of the data.

But I believe the OP has explained that a dump of the disk file showed
that BDW was valid but corrupted on input by ?SAM.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Bsam VS Qsam for VB records

[Bill Woodger]

DISP=MOD does lead to a way to accidentally (or deliberately, as an exercise) 
create a "zero" BDW. With RECFM=F/FB/U and some LRECL, specified on the DD, 
write a lump of data with two bytes of binary zeros. Then with DISP=MOD again, 
and the "normal" RECFM/LRECL, write a good record. Then try to read the data. 
Tricky to do accidentally, but sometimes you find someone who errs, and then 
tries to "correct" without realising the full consequences.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Charles Mills]

Or perhaps not, given IBM's reply. And given that IBM is working on it, I would 
move on to other things and let IBM work on it.

The answer is still not BSAM programming or zapping.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, July 19, 2016 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

IMHO the problem here is probably one of misunderstanding or misapplication 
(Dr. Merrill's pointing out of a JCL oddity, for example) and any zapping or 
BSAM programming is likely to turn it into a real problem of corrupted data on 
disk.

The questions should be "how do we correct our error and read the data?" and 
not "how do we zap the data to make it fit our model of correct?"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Charles Mills]

IMHO the problem here is probably one of misunderstanding or misapplication 
(Dr. Merrill's pointing out of a JCL oddity, for example) and any zapping or 
BSAM programming is likely to turn it into a real problem of corrupted data on 
disk.

The questions should be "how do we correct our error and read the data?" and 
not "how do we zap the data to make it fit our model of correct?"

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Blaicher, Christopher Y.
Sent: Tuesday, July 19, 2016 12:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

The I/O ERROR message should have a CCHHR associated with it.  Using the CCHHR 
you can use AMASPZAP to dump that record or all the records on that track.  You 
can then examine the record in question and determine if the BDW is correct, 
BDW should equal the block length reported by AMASPZAP, or if an RDW is 
incorrect.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Tom Marchant]

On Tue, 19 Jul 2016 18:47:50 +, Reichman Joseph wrote:

>Thanks for all your help I really understand the problem thing is the file is 
>huge and I don't know by what factor DFSMS blocked and if the blocking is 
>consistent meaning always by the same factor

"Blocking factor" has little meaning for a VB file. The blocksize need not be a 
multiple of lrecl, and in most VB data sets the records are of varying lengths. 
As a consequence, the size of the blocks will usually be of varying lengths. If 
the data set was created with one block size and was subsequently written to 
(MOD) by a program that specified a different blocksize, the DSCB would have 
been updated to reflect the more recent blocksize, which may not be enough to 
read existing blocks on the data set.

This is largely guesswork and supposition, based upon minimal information 
provided.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Blaicher, Christopher Y.]

The I/O ERROR message should have a CCHHR associated with it.  Using the CCHHR 
you can use AMASPZAP to dump that record or all the records on that track.  You 
can then examine the record in question and determine if the BDW is correct, 
BDW should equal the block length reported by AMASPZAP, or if an RDW is 
incorrect.

The bigger question is what software created the file?  You are stuck trying to 
read it, but what created it badly?

Chris Blaicher
Technical Architect
Mainframe Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

www.syncsort.com





-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Reichman Joseph
Sent: Tuesday, July 19, 2016 2:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

Thanks for all your help I really understand the problem thing is the file is 
huge and I don’t know by what factor DFSMS blocked and if the blocking is 
consistent meaning always by the same factor

Joe Reichman
Joe Reichman

IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of John McKown
Sent: Tuesday, July 19, 2016 2:25 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Bsam VS Qsam for VB records

On Tue, Jul 19, 2016 at 1:20 PM, Farley, Peter x23353 < 
peter.far...@broadridge.com> wrote:

> I've been following the various attempts to help you fix your broken
> file with a block that has a zero BDW.  How that ever happened is a
> mystery you really ought to engage IBM to help solve, BUT . . .
>
> No one else seems to have suggested the "old time" solution to
> recovering the file data - does your shop license DITTO?  DITTO can
> access AND MODIFY disk blocks directly, without programming.  You can
> display blocks in the file until you get to the one you want and then
> update the BDW in that block based on the block length DITTO tells you it 
> read.
>
> If your shop does license DITTO the "disk modify" function is very
> likely security protected (or darn well ought to be, since it can
> really wreck things up if misused or abused), so you may need to
> interface with your security team to get appropriate authority.
>
> There is a "batch" interface to DITTO as well as TSO capability, so
> you could set it up as a batch job or try to accomplish it on the fly
> from TSO.  If it were me I would also try to make sure I have at least
> one safe volume backup of the disk containing that file in case things
> get messed up.  Caveat emptor.
>
> HTH
>
> Peter
>

​AMASPZAP can do the same thing. I don't know DITTO, so I'll guess it would be 
easier to use. Personally, I'd hate to use AMASPZAP to correct BDWs on disk. 
AMASPZAP can also print the data, in HEX.​



--
"Worry was nothing more than paying interest on a loan that a man may never 
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Reichman Joseph]

Thanks for all your help I really understand the problem thing is the file is 
huge and I don’t know by what factor DFSMS blocked and if the blocking is 
consistent meaning always by the same factor

Joe Reichman
Joe Reichman
 
IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of John McKown
Sent: Tuesday, July 19, 2016 2:25 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Bsam VS Qsam for VB records

On Tue, Jul 19, 2016 at 1:20 PM, Farley, Peter x23353 < 
peter.far...@broadridge.com> wrote:

> I've been following the various attempts to help you fix your broken 
> file with a block that has a zero BDW.  How that ever happened is a 
> mystery you really ought to engage IBM to help solve, BUT . . .
>
> No one else seems to have suggested the "old time" solution to 
> recovering the file data - does your shop license DITTO?  DITTO can 
> access AND MODIFY disk blocks directly, without programming.  You can 
> display blocks in the file until you get to the one you want and then 
> update the BDW in that block based on the block length DITTO tells you it 
> read.
>
> If your shop does license DITTO the "disk modify" function is very 
> likely security protected (or darn well ought to be, since it can 
> really wreck things up if misused or abused), so you may need to 
> interface with your security team to get appropriate authority.
>
> There is a "batch" interface to DITTO as well as TSO capability, so 
> you could set it up as a batch job or try to accomplish it on the fly 
> from TSO.  If it were me I would also try to make sure I have at least 
> one safe volume backup of the disk containing that file in case things 
> get messed up.  Caveat emptor.
>
> HTH
>
> Peter
>

​AMASPZAP can do the same thing. I don't know DITTO, so I'll guess it would be 
easier to use. Personally, I'd hate to use AMASPZAP to correct BDWs on disk. 
AMASPZAP can also print the data, in HEX.​



--
"Worry was nothing more than paying interest on a loan that a man may never 
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Tom Marchant]

On Tue, 19 Jul 2016 13:24:37 -0500, John McKown wrote:

>​AMASPZAP can do the same thing. I don't know DITTO, so I'll guess it would
>be easier to use. Personally, I'd hate to use AMASPZAP to correct BDWs on
>disk. AMASPZAP can also print the data, in HEX.​

I'm baffled by the notion that the BDWs on disk are wrong, and can be 
corrected. Didn't Joe say that all I/O to the file has been using QSAM? If that 
is true, the BDW is the length of the block and to change it will likely cause 
errors.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Paul Gilmartin]

On Tue, 19 Jul 2016 13:24:37 -0500, John McKown wrote:
>
>​AMASPZAP can do the same thing. I don't know DITTO, so I'll guess it would
>be easier to use. Personally, I'd hate to use AMASPZAP to correct BDWs on
>disk. AMASPZAP can also print the data, in HEX.​
> 
Rexx now deals with RECFM=U, at least as of 2.2.  Don't know about 2.1.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Bsam VS Qsam for VB records

[Bill Woodger]

If you have confirmed it is on the disk (I assume you mean the BDW and RDW look 
OK) then it is being clobbered in code. If something is not correct immediately 
after doing a correct read (so assumption you have coded that correctly) then 
it is something for IBM. More likely is a program error after the read and 
before you notice it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[John McKown]

On Tue, Jul 19, 2016 at 1:20 PM, Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> I've been following the various attempts to help you fix your broken file
> with a block that has a zero BDW.  How that ever happened is a mystery you
> really ought to engage IBM to help solve, BUT . . .
>
> No one else seems to have suggested the "old time" solution to recovering
> the file data - does your shop license DITTO?  DITTO can access AND MODIFY
> disk blocks directly, without programming.  You can display blocks in the
> file until you get to the one you want and then update the BDW in that
> block based on the block length DITTO tells you it read.
>
> If your shop does license DITTO the "disk modify" function is very likely
> security protected (or darn well ought to be, since it can really wreck
> things up if misused or abused), so you may need to interface with your
> security team to get appropriate authority.
>
> There is a "batch" interface to DITTO as well as TSO capability, so you
> could set it up as a batch job or try to accomplish it on the fly from
> TSO.  If it were me I would also try to make sure I have at least one safe
> volume backup of the disk containing that file in case things get messed
> up.  Caveat emptor.
>
> HTH
>
> Peter
>

​AMASPZAP can do the same thing. I don't know DITTO, so I'll guess it would
be easier to use. Personally, I'd hate to use AMASPZAP to correct BDWs on
disk. AMASPZAP can also print the data, in HEX.​



-- 
"Worry was nothing more than paying interest on a loan that a man may never
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Reichman Joseph]

I am in the process of running with RECFM=U (under TEST) I see that is shows 
both BDW and RDW

Joe Reichman
Joe Reichman
 
IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of Farley, Peter x23353
Sent: Tuesday, July 19, 2016 2:20 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Bsam VS Qsam for VB records

I've been following the various attempts to help you fix your broken file with 
a block that has a zero BDW.  How that ever happened is a mystery you really 
ought to engage IBM to help solve, BUT . . .

No one else seems to have suggested the "old time" solution to recovering the 
file data - does your shop license DITTO?  DITTO can access AND MODIFY disk 
blocks directly, without programming.  You can display blocks in the file until 
you get to the one you want and then update the BDW in that block based on the 
block length DITTO tells you it read.

If your shop does license DITTO the "disk modify" function is very likely 
security protected (or darn well ought to be, since it can really wreck things 
up if misused or abused), so you may need to interface with your security team 
to get appropriate authority.

There is a "batch" interface to DITTO as well as TSO capability, so you could 
set it up as a batch job or try to accomplish it on the fly from TSO.  If it 
were me I would also try to make sure I have at least one safe volume backup of 
the disk containing that file in case things get messed up.  Caveat emptor.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Reichman Joseph
Sent: Tuesday, July 19, 2016 1:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

The problem is not the RDW it’s the BDW with QSAM that’s somewhere inside DFSMS 
code it doesn't seem RECFM=U would reveal that 

Joe Reichman
Joe Reichman
 
IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of Bill Woodger
Sent: Tuesday, July 19, 2016 1:13 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Bsam VS Qsam for VB records

With RECFM=U, you get the entire physical record presented to you. It has no 
"length" as far as the system is concerned, it is just an amorphous lump of 
data. For VB-as-U the first four bytes are the RDW of what was the block, the 
next four bytes the RDW of the first record, and you can find the start of the 
next record (next RDW) though some simple maths (adding).


On Tuesday, 19 July 2016 17:15:53 UTC+2, Reichman Joseph  wrote:
> With RECFM=U there is 1 record per block and the BDW is RDW + 4 ?
> 
> Joe Reichman

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Farley, Peter x23353]

I've been following the various attempts to help you fix your broken file with 
a block that has a zero BDW.  How that ever happened is a mystery you really 
ought to engage IBM to help solve, BUT . . .

No one else seems to have suggested the "old time" solution to recovering the 
file data - does your shop license DITTO?  DITTO can access AND MODIFY disk 
blocks directly, without programming.  You can display blocks in the file until 
you get to the one you want and then update the BDW in that block based on the 
block length DITTO tells you it read.

If your shop does license DITTO the "disk modify" function is very likely 
security protected (or darn well ought to be, since it can really wreck things 
up if misused or abused), so you may need to interface with your security team 
to get appropriate authority.

There is a "batch" interface to DITTO as well as TSO capability, so you could 
set it up as a batch job or try to accomplish it on the fly from TSO.  If it 
were me I would also try to make sure I have at least one safe volume backup of 
the disk containing that file in case things get messed up.  Caveat emptor.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Reichman Joseph
Sent: Tuesday, July 19, 2016 1:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

The problem is not the RDW it’s the BDW with QSAM that’s somewhere inside DFSMS 
code it doesn't seem RECFM=U would reveal that 

Joe Reichman
Joe Reichman
 
IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of Bill Woodger
Sent: Tuesday, July 19, 2016 1:13 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Bsam VS Qsam for VB records

With RECFM=U, you get the entire physical record presented to you. It has no 
"length" as far as the system is concerned, it is just an amorphous lump of 
data. For VB-as-U the first four bytes are the RDW of what was the block, the 
next four bytes the RDW of the first record, and you can find the start of the 
next record (next RDW) though some simple maths (adding).


On Tuesday, 19 July 2016 17:15:53 UTC+2, Reichman Joseph  wrote:
> With RECFM=U there is 1 record per block and the BDW is RDW + 4 ?
> 
> Joe Reichman

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Charles Mills]

If you do not understand these things then writing a program with BSAM and/or 
RECFM=[something clever other than how the dataset was actually written] is not 
the way to do things -- except perhaps utterly as a learning exercise, not 
directly justified by an actual business requirement.

If you want to see what is actually on the disk there are utilities that will 
show you that. I would guess IDCAMS DUMP with RECFM=U would be a good start, 
although I do not recall that I have ever actually done that, so I might be 
missing something. People have also suggested CBT tools IIRC. 

Even if you want to write a BSAM program for your own education or amusement, I 
would start with an existing dump utility so you can see what you will read 
with BSAM.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, July 19, 2016 10:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

One more time: if it is on the disk then RECFM=U will "reveal" it. What you got 
on disk is what you will get with READ.

The BDW is not inside QSAM. It is (or is not) on the disk. QSAM *interprets* it.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Reichman Joseph
Sent: Tuesday, July 19, 2016 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

The problem is not the RDW it’s the BDW with QSAM that’s somewhere inside DFSMS 
code it doesn't seem RECFM=U would reveal that 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Charles Mills]

One more time: if it is on the disk then RECFM=U will "reveal" it. What you got 
on disk is what you will get with READ.

The BDW is not inside QSAM. It is (or is not) on the disk. QSAM *interprets* it.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Reichman Joseph
Sent: Tuesday, July 19, 2016 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

The problem is not the RDW it’s the BDW with QSAM that’s somewhere inside DFSMS 
code it doesn't seem RECFM=U would reveal that 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Reichman Joseph]

The problem is not the RDW it’s the BDW with QSAM that’s somewhere inside DFSMS 
code it doesn't seem RECFM=U would reveal that 

Joe Reichman
Joe Reichman
 
IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of Bill Woodger
Sent: Tuesday, July 19, 2016 1:13 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Bsam VS Qsam for VB records

With RECFM=U, you get the entire physical record presented to you. It has no 
"length" as far as the system is concerned, it is just an amorphous lump of 
data. For VB-as-U the first four bytes are the RDW of what was the block, the 
next four bytes the RDW of the first record, and you can find the start of the 
next record (next RDW) though some simple maths (adding).


On Tuesday, 19 July 2016 17:15:53 UTC+2, Reichman Joseph  wrote:
> With RECFM=U there is 1 record per block and the BDW is RDW + 4 ?
> 
> Joe Reichman

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Bsam VS Qsam for VB records

[Bill Woodger]

With RECFM=U, you get the entire physical record presented to you. It has no 
"length" as far as the system is concerned, it is just an amorphous lump of 
data. For VB-as-U the first four bytes are the RDW of what was the block, the 
next four bytes the RDW of the first record, and you can find the start of the 
next record (next RDW) though some simple maths (adding).


On Tuesday, 19 July 2016 17:15:53 UTC+2, Reichman Joseph  wrote:
> With RECFM=U there is 1 record per block and the BDW is RDW + 4 ?
> 
> Joe Reichman

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

FW: Bsam VS Qsam for VB records

[Barry Merrill]

The original post had as noted below, two slashes,
but the ListServer rejected with:

Your  message is  being returned  to you  unprocessed because  it looks  like a 
LISTSERV command, rather than material intended for distribution to the members 
of the IBM-MAIN list. Please note that LISTSERV commands must always be sent to 
the LISTSERV address. If it was indeed  a command you were attempting to issue, 
then send it again to lists...@listserv.ua.edu for execution. Otherwise, please 
accept our apologies  and try to rewrite the message  with a slightly different 
wording -  for instance, change  the first word of  the message, enclose  it in 
quotation marks, insert a line of dashes at the beginning of your message, etc.


 THIS-IS-SLASH-SLASH  EXEC SAS
 THIS-IS-SLASH-SLASH  DATAFILE DD DSN=WHATEVER,DISP=SHR
 THIS-IS-SLASH-SLASH  SYSIN DD *
  DATA _NULL_;
  INFILE DATAFILE RECFM=U BLKSIZE=32760;
  INPUT;
  LIST;
  IF _N_ GT 10 THEN STOP;

will print a nice hex dump of each of the first 10 block.

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, July 19, 2016 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

On Tue, Jul 19, 2016 at 10:15 AM, Reichman Joseph <joseph.reich...@irs.gov>
wrote:

> With RECFM=U there is 1 record per block and the BDW is RDW + 4 ?
>

​Technically speaking, with RECFM=U there is not a BDW. There is just a bunch 
of bytes with no access method imposed interpretation. You must determine the 
number of bytes actually read by taking the number of bytes you requested to be 
read (the BLKSIZE basically) and subtract the CCW residual count to determine 
the number of bytes actually read. Luckily, IBM supplies an example.
ref:
http://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.idad400/len99.htm
​



>
> Joe Reichman
> Joe Reichman
>
> IT Specialist
> Master Files Division
> New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex 
> M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350
> Cell (917) 748-9693
> TOD M - F  7:30 am  - 4:00 pm
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] 
> On Behalf Of John McKown
> Sent: Tuesday, July 19, 2016 10:57 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Bsam VS Qsam for VB records
>
> On Tue, Jul 19, 2016 at 9:54 AM, Pew, Curtis G < 
> curtis@austin.utexas.edu
> > wrote:
>
> > On Jul 19, 2016, at 9:39 AM, Reichman Joseph 
> > <joseph.reich...@irs.gov>
> > wrote:
> > >
> > > I am not thinking of moving this in production it may help me 
> > > track down
> > a problem
> >
> > If your motivation is to examine the physical blocks, why not read 
> > with QSAM specifying RECFM=U?
> >
>
> ​That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then 
> use QSAM and "have fun".​ Or not, as the case may be.
>
>
>
> >
> > --
> > Pew, Curtis G
> > curtis@austin.utexas.edu
> > ITS Systems/Core/Administrative Services
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send email to lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
> >
>
>
>
> --
> "Worry was nothing more than paying interest on a loan that a man may 
> never borrow"
>
> From: "Quest for the White Wind" by Alan Black
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
"Worry was nothing more than paying interest on a loan that a man may never 
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Charles Mills]

With RECFM=U what you see is what you get. You will receive whatever is on the 
disk in a physical block. (Let's skip what is really happening under the covers 
in modern DASD.) You will get whatever was written. If it is a well-formed 
block written by QSAM RECFM=VB, or written with BSAM or even EXCP by a 
competent programmer "emulating" well-formed RECFM=VB, then yes, you will get a 
BDW followed by one or more RDW+record, with BDW = sum of all RDWs plus 4. If 
something else was written you will get that.

>From QSAM's point of view, yes RECFM=U is one record per block, or, depending 
>on which explanation you choose, no records and only blocks.

Whether whoever wrote it viewed things differently is an unanswerable question. 
Whether they were that competent programmer is an unanswerable question. 
Whether you choose to view things differently is its own question. You might 
choose to "deblock" the data in any way you chose. You might write a "dump" 
program that dealt with the data one byte at a time, with no other structure.

It is still hard for me to picture the question to which BSAM is the answer. In 
1975, yes, I wrote a marvelous "database" system which used BSAM under the 
covers. In 2016 it's hard for me to picture.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Reichman Joseph
Sent: Tuesday, July 19, 2016 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

With RECFM=U there is 1 record per block and the BDW is RDW + 4 ?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[John McKown]

On Tue, Jul 19, 2016 at 10:15 AM, Reichman Joseph <joseph.reich...@irs.gov>
wrote:

> With RECFM=U there is 1 record per block and the BDW is RDW + 4 ?
>

​Technically speaking, with RECFM=U there is not a BDW. There is just a
bunch of bytes with no access method imposed interpretation. You must
determine the number of bytes actually read by taking the number of bytes
you requested to be read (the BLKSIZE basically) and subtract the CCW
residual count to determine the number of bytes actually read. Luckily, IBM
supplies an example.
ref:
http://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.idad400/len99.htm
​



>
> Joe Reichman
> Joe Reichman
>
> IT Specialist
> Master Files Division
> New Carrollton Federal Building, B7-182
> OS:CTO:AD:CP:I:IB
> Flex M,T,Th,F
> Home office (240) 863 - 3965
> Office (240) 613-4350
> Cell (917) 748-9693
> TOD M - F  7:30 am  - 4:00 pm
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On
> Behalf Of John McKown
> Sent: Tuesday, July 19, 2016 10:57 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Bsam VS Qsam for VB records
>
> On Tue, Jul 19, 2016 at 9:54 AM, Pew, Curtis G <
> curtis@austin.utexas.edu
> > wrote:
>
> > On Jul 19, 2016, at 9:39 AM, Reichman Joseph <joseph.reich...@irs.gov>
> > wrote:
> > >
> > > I am not thinking of moving this in production it may help me track
> > > down
> > a problem
> >
> > If your motivation is to examine the physical blocks, why not read
> > with QSAM specifying RECFM=U?
> >
>
> ​That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then use
> QSAM and "have fun".​ Or not, as the case may be.
>
>
>
> >
> > --
> > Pew, Curtis G
> > curtis@austin.utexas.edu
> > ITS Systems/Core/Administrative Services
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
> "Worry was nothing more than paying interest on a loan that a man may
> never borrow"
>
> From: "Quest for the White Wind" by Alan Black
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
"Worry was nothing more than paying interest on a loan that a man may never
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Jesse 1 Robinson]

There is at least one TSO ZAP command on the CBT tape. It's very useful for 
examining DASD data. You don't actually need to alter any data; just look at 
it. The command is highly agnostic and will read pretty much any block. It 
won't tell you how an RDW got broken, but it can show the results in 
full-screen mode. It requires no programming. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Reichman Joseph
Sent: Tuesday, July 19, 2016 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Bsam VS Qsam for VB records

With RECFM=U there is 1 record per block and the BDW is RDW + 4 ?

Joe Reichman
Joe Reichman
 
IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of John McKown
Sent: Tuesday, July 19, 2016 10:57 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Bsam VS Qsam for VB records

On Tue, Jul 19, 2016 at 9:54 AM, Pew, Curtis G <curtis@austin.utexas.edu
> wrote:

> On Jul 19, 2016, at 9:39 AM, Reichman Joseph <joseph.reich...@irs.gov>
> wrote:
> >
> > I am not thinking of moving this in production it may help me track 
> > down
> a problem
>
> If your motivation is to examine the physical blocks, why not read 
> with QSAM specifying RECFM=U?
>

​That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then use QSAM 
and "have fun".​ Or not, as the case may be.



>
> --
> Pew, Curtis G
> curtis@austin.utexas.edu
> ITS Systems/Core/Administrative Services


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Mike Schwab]

Nothing.  Data 1-LRECL, no RDW, no BDW.

On Tue, Jul 19, 2016 at 10:15 AM, Reichman Joseph
<joseph.reich...@irs.gov> wrote:
> With RECFM=U there is 1 record per block and the BDW is RDW + 4 ?
>
> Joe Reichman
> Joe Reichman
>
> IT Specialist
> Master Files Division
> New Carrollton Federal Building, B7-182
> OS:CTO:AD:CP:I:IB
> Flex M,T,Th,F
> Home office (240) 863 - 3965
> Office (240) 613-4350
> Cell (917) 748-9693
> TOD M - F  7:30 am  - 4:00 pm
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On 
> Behalf Of John McKown
> Sent: Tuesday, July 19, 2016 10:57 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Bsam VS Qsam for VB records
>
> On Tue, Jul 19, 2016 at 9:54 AM, Pew, Curtis G <curtis@austin.utexas.edu
>> wrote:
>
>> On Jul 19, 2016, at 9:39 AM, Reichman Joseph <joseph.reich...@irs.gov>
>> wrote:
>> >
>> > I am not thinking of moving this in production it may help me track
>> > down
>> a problem
>>
>> If your motivation is to examine the physical blocks, why not read
>> with QSAM specifying RECFM=U?
>>
>
> That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then use QSAM 
> and "have fun". Or not, as the case may be.
>
>
>
>>
>> --
>> Pew, Curtis G
>> curtis@austin.utexas.edu
>> ITS Systems/Core/Administrative Services
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions, send
>> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
>
> --
> "Worry was nothing more than paying interest on a loan that a man may never 
> borrow"
>
> From: "Quest for the White Wind" by Alan Black
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Reichman Joseph]

With RECFM=U there is 1 record per block and the BDW is RDW + 4 ?

Joe Reichman
Joe Reichman
 
IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of John McKown
Sent: Tuesday, July 19, 2016 10:57 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Bsam VS Qsam for VB records

On Tue, Jul 19, 2016 at 9:54 AM, Pew, Curtis G <curtis@austin.utexas.edu
> wrote:

> On Jul 19, 2016, at 9:39 AM, Reichman Joseph <joseph.reich...@irs.gov>
> wrote:
> >
> > I am not thinking of moving this in production it may help me track 
> > down
> a problem
>
> If your motivation is to examine the physical blocks, why not read 
> with QSAM specifying RECFM=U?
>

​That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then use QSAM 
and "have fun".​ Or not, as the case may be.



>
> --
> Pew, Curtis G
> curtis@austin.utexas.edu
> ITS Systems/Core/Administrative Services
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
"Worry was nothing more than paying interest on a loan that a man may never 
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[John McKown]

On Tue, Jul 19, 2016 at 9:32 AM, Reichman Joseph 
wrote:

> As Far as I can see all the I/O we do here is qsam  There was an issue
> here as Jay Campbell pointed out where writing a VB record had a valid RDW
> but the BDW was zeros. Using qsam I would have no idea what the BDW was as
> the system takes care
>
> of that. I am assuming if you use BSAM you decide the number of records
> that make up a block and each record is proceeded by a RDW and the block
> which you write has cumulative BDW.
>
> Am I on the right track ?
>

​Yes, you are; BDW == sum(individual RDWs) + 4.​



>
> Joe Reichman
>


-- 
"Worry was nothing more than paying interest on a loan that a man may never
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[John McKown]

On Tue, Jul 19, 2016 at 9:54 AM, Pew, Curtis G  wrote:

> On Jul 19, 2016, at 9:39 AM, Reichman Joseph 
> wrote:
> >
> > I am not thinking of moving this in production it may help me track down
> a problem
>
> If your motivation is to examine the physical blocks, why not read with
> QSAM specifying RECFM=U?
>

​That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then use
QSAM and "have fun".​ Or not, as the case may be.



>
> --
> Pew, Curtis G
> curtis@austin.utexas.edu
> ITS Systems/Core/Administrative Services
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
"Worry was nothing more than paying interest on a loan that a man may never
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Pew, Curtis G]

On Jul 19, 2016, at 9:39 AM, Reichman Joseph  wrote:
> 
> I am not thinking of moving this in production it may help me track down a 
> problem  

If your motivation is to examine the physical blocks, why not read with QSAM 
specifying RECFM=U?

-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Charles Mills]

Agreed 100% with @Kees and @John.

I would say "if you have to ask the question then you should not be using BSAM."

I did not read the RDW thread but consider that if your block descriptor word 
is mucked up when using QSAM all you have to do is open a problem with IBM. If 
your block descriptor is screwed up with BSAM -- well, get out the old 
debugging hat, and good luck!

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Tuesday, July 19, 2016 7:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

I wonder what application it is that justifies considering this. It is not the 
80's anymore. And even with QSAM you have the BUFNO parameter. 
If you really want to go down to the details, consider EXCP (I did, 35 years 
ago).

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: 19 July, 2016 16:24
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

IOW - unless you are very clever and you have a real need for I/O overlap 
performance, and you don't mind the maintenance programmer cussing you out, 
then I'd just go with QSAM.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Reichman Joseph]

I am not thinking of moving this in production it may help me track down a 
problem  

Joe Reichman
Joe Reichman
 
IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Tuesday, July 19, 2016 10:37 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Bsam VS Qsam for VB records

I wonder what application it is that justifies considering this. It is not the 
80's anymore. And even with QSAM you have the BUFNO parameter. 
If you really want to go down to the details, consider EXCP (I did, 35 years 
ago).

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: 19 July, 2016 16:24
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

IOW - unless you are very clever and you have a real need for I/O overlap 
performance, and you don't mind the maintenance programmer cussing you out, 
then I'd just go with QSAM.

--

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Reichman Joseph]

That’s what I meant 

Joe Reichman
Joe Reichman
 
IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Tuesday, July 19, 2016 10:39 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Bsam VS Qsam for VB records

Cumulative RDW's+4 (first beginners error).

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Reichman Joseph
Sent: 19 July, 2016 16:33
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

As Far as I can see all the I/O we do here is qsam  There was an issue here as 
Jay Campbell pointed out where writing a VB record had a valid RDW but the BDW 
was zeros. Using qsam I would have no idea what the BDW was as the system takes 
care

of that. I am assuming if you use BSAM you decide the number of records that 
make up a block and each record is proceeded by a RDW and the block which you 
write has cumulative BDW.

Am I on the right track ?   

Joe Reichman
Joe Reichman
 
IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of John McKown
Sent: Tuesday, July 19, 2016 10:24 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Bsam VS Qsam for VB records

On Tue, Jul 19, 2016 at 9:02 AM, Reichman Joseph <joseph.reich...@irs.gov>
wrote:

> Hi,
>
> Would anyone know the plus and or minus for using BSAM as opposed to 
> QSAM for VB records. It seems with BSAM there is more control e.g.
> specifying the BDW as well as the RDW. Wondering about performance.
>
> I am guessing if you know what you are doing BSAM would be faster. If 
> anyone could point me to examples using BSAM would appreciated. As I 
> have mainly used QSAM specifying the RDW
>
> Thanks
>
> Joe Reichman
>

​In general (VB or FB), QSAM is much easier to program. The access method just 
hands you individual records. But you pay for this in that you cannot do I/O 
overlap yourself. With BSAM, you do a READ. But the _block_ is not available to 
you (for certain sure) until you do a CHECK. But this allows you to test the 
I/O ECB and "do something else" if it has not been POST'd yet. A type of 
"useful polling" loop. Also, if you are reading multiple files, you can do a 
ECBLIST and wait for any one of the I/Os to complete instead of doing the I/O 
serially. Again performance. The problem is that _your code_ must de-block the 
​ individual records. For VB, you should probably determine the number of byte 
read in the block (they aren't necessarily all the same size, you
know) and check that the value in the BDW agrees with this number. And the code 
to do this is non-obvious because what you end up doing is knowing how many 
bytes you asked for and the I/O control block tells you the residual byte count 
- not the byte read but more like "you asked to read some bytes and there were 
​ were not enough in the block - the block was short by ? bytes). So the number 
of bytes read is the number of bytes you requested in the READ (not given back 
to you - you must remember) minus the "residual byte" count which is returned.

IOW - unless you are very clever and you have a real need for I/O overlap 
performance, and you don't mind the maintenance programmer cussing you out, 
then I'd just go with QSAM.

--
"Worry was nothing more than paying interest on a loan that a man may never 
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by 

Re: Bsam VS Qsam for VB records

[Vernooij, CP (ITOPT1) - KLM]

Cumulative RDW's+4 (first beginners error).

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Reichman Joseph
Sent: 19 July, 2016 16:33
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

As Far as I can see all the I/O we do here is qsam  There was an issue here as 
Jay Campbell pointed out where writing a VB record had a valid RDW but the BDW 
was zeros. Using qsam I would have no idea what the BDW was as the system takes 
care

of that. I am assuming if you use BSAM you decide the number of records that 
make up a block and each record is proceeded by a RDW and the block which you 
write has cumulative BDW.

Am I on the right track ?   

Joe Reichman
Joe Reichman
 
IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of John McKown
Sent: Tuesday, July 19, 2016 10:24 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Bsam VS Qsam for VB records

On Tue, Jul 19, 2016 at 9:02 AM, Reichman Joseph <joseph.reich...@irs.gov>
wrote:

> Hi,
>
> Would anyone know the plus and or minus for using BSAM as opposed to 
> QSAM for VB records. It seems with BSAM there is more control e.g. 
> specifying the BDW as well as the RDW. Wondering about performance.
>
> I am guessing if you know what you are doing BSAM would be faster. If 
> anyone could point me to examples using BSAM would appreciated. As I 
> have mainly used QSAM specifying the RDW
>
> Thanks
>
> Joe Reichman
>

​In general (VB or FB), QSAM is much easier to program. The access method just 
hands you individual records. But you pay for this in that you cannot do I/O 
overlap yourself. With BSAM, you do a READ. But the _block_ is not available to 
you (for certain sure) until you do a CHECK. But this allows you to test the 
I/O ECB and "do something else" if it has not been POST'd yet. A type of 
"useful polling" loop. Also, if you are reading multiple files, you can do a 
ECBLIST and wait for any one of the I/Os to complete instead of doing the I/O 
serially. Again performance. The problem is that _your code_ must de-block the 
​ individual records. For VB, you should probably determine the number of byte 
read in the block (they aren't necessarily all the same size, you
know) and check that the value in the BDW agrees with this number. And the code 
to do this is non-obvious because what you end up doing is knowing how many 
bytes you asked for and the I/O control block tells you the residual byte count 
- not the byte read but more like "you asked to read some bytes and there were 
​ were not enough in the block - the block was short by ? bytes). So the number 
of bytes read is the number of bytes you requested in the READ (not given back 
to you - you must remember) minus the "residual byte" count which is returned.

IOW - unless you are very clever and you have a real need for I/O overlap 
performance, and you don't mind the maintenance programmer cussing you out, 
then I'd just go with QSAM.

--
"Worry was nothing more than paying interest on a loan that a man may never 
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also kn

Re: Bsam VS Qsam for VB records

[Vernooij, CP (ITOPT1) - KLM]

I wonder what application it is that justifies considering this. It is not the 
80's anymore. And even with QSAM you have the BUFNO parameter. 
If you really want to go down to the details, consider EXCP (I did, 35 years 
ago).

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: 19 July, 2016 16:24
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

IOW - unless you are very clever and you have a real need for I/O overlap
performance, and you don't mind the maintenance programmer cussing you out,
then I'd just go with QSAM.

-- 

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Reichman Joseph]

As Far as I can see all the I/O we do here is qsam  There was an issue here as 
Jay Campbell pointed out where writing a VB record had a valid RDW but the BDW 
was zeros. Using qsam I would have no idea what the BDW was as the system takes 
care

of that. I am assuming if you use BSAM you decide the number of records that 
make up a block and each record is proceeded by a RDW and the block which you 
write has cumulative BDW.

Am I on the right track ?   

Joe Reichman
Joe Reichman
 
IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of John McKown
Sent: Tuesday, July 19, 2016 10:24 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Bsam VS Qsam for VB records

On Tue, Jul 19, 2016 at 9:02 AM, Reichman Joseph <joseph.reich...@irs.gov>
wrote:

> Hi,
>
> Would anyone know the plus and or minus for using BSAM as opposed to 
> QSAM for VB records. It seems with BSAM there is more control e.g. 
> specifying the BDW as well as the RDW. Wondering about performance.
>
> I am guessing if you know what you are doing BSAM would be faster. If 
> anyone could point me to examples using BSAM would appreciated. As I 
> have mainly used QSAM specifying the RDW
>
> Thanks
>
> Joe Reichman
>

​In general (VB or FB), QSAM is much easier to program. The access method just 
hands you individual records. But you pay for this in that you cannot do I/O 
overlap yourself. With BSAM, you do a READ. But the _block_ is not available to 
you (for certain sure) until you do a CHECK. But this allows you to test the 
I/O ECB and "do something else" if it has not been POST'd yet. A type of 
"useful polling" loop. Also, if you are reading multiple files, you can do a 
ECBLIST and wait for any one of the I/Os to complete instead of doing the I/O 
serially. Again performance. The problem is that _your code_ must de-block the 
​ individual records. For VB, you should probably determine the number of byte 
read in the block (they aren't necessarily all the same size, you
know) and check that the value in the BDW agrees with this number. And the code 
to do this is non-obvious because what you end up doing is knowing how many 
bytes you asked for and the I/O control block tells you the residual byte count 
- not the byte read but more like "you asked to read some bytes and there were 
​ were not enough in the block - the block was short by ? bytes). So the number 
of bytes read is the number of bytes you requested in the READ (not given back 
to you - you must remember) minus the "residual byte" count which is returned.

IOW - unless you are very clever and you have a real need for I/O overlap 
performance, and you don't mind the maintenance programmer cussing you out, 
then I'd just go with QSAM.

--
"Worry was nothing more than paying interest on a loan that a man may never 
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[John McKown]

On Tue, Jul 19, 2016 at 9:02 AM, Reichman Joseph 
wrote:

> Hi,
>
> Would anyone know the plus and or minus for using BSAM as opposed to QSAM
> for VB records. It seems with BSAM there is more control e.g. specifying
> the BDW as well as the RDW. Wondering about performance.
>
> I am guessing if you know what you are doing BSAM would be faster. If
> anyone could point me to examples using BSAM would appreciated. As I have
> mainly used QSAM specifying the RDW
>
> Thanks
>
> Joe Reichman
>

​In general (VB or FB), QSAM is much easier to program. The access method
just hands you individual records. But you pay for this in that you cannot
do I/O overlap yourself. With BSAM, you do a READ. But the _block_ is not
available to you (for certain sure) until you do a CHECK. But this allows
you to test the I/O ECB and "do something else" if it has not been POST'd
yet. A type of "useful polling" loop. Also, if you are reading multiple
files, you can do a ECBLIST and wait for any one of the I/Os to complete
instead of doing the I/O serially. Again performance. The problem is that
_your code_ must de-block the ​
individual records. For VB, you should probably determine the number of
byte read in the block (they aren't necessarily all the same size, you
know) and check that the value in the BDW agrees with this number. And the
code to do this is non-obvious because what you end up doing is knowing how
many bytes you asked for and the I/O control block tells you the residual
byte count - not the byte read but more like "you asked to read some bytes
and there were
​ were not enough in the block - the block was short by ? bytes). So the
number of bytes read is the number of bytes you requested in the READ (not
given back to you - you must remember) minus the "residual byte" count
which is returned.

IOW - unless you are very clever and you have a real need for I/O overlap
performance, and you don't mind the maintenance programmer cussing you out,
then I'd just go with QSAM.

-- 
"Worry was nothing more than paying interest on a loan that a man may never
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Bsam VS Qsam for VB records

[Reichman Joseph]

Hi,


Would anyone know the plus and or minus for using BSAM as opposed to QSAM for 
VB records. It seems with BSAM there is more control e.g. specifying the BDW as 
well as the RDW. Wondering about performance.

I am guessing if you know what you are doing BSAM would be faster. If anyone 
could point me to examples using BSAM would appreciated. As I have mainly used 
QSAM specifying the RDW

Thanks

Joe Reichman
Joe Reichman

IT Specialist
Master Files Division
New Carrollton Federal Building, B7-182
OS:CTO:AD:CP:I:IB
Flex M,T,Th,F
Home office (240) 863 - 3965
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN