Re: BSAM vs QSAM (and SORT).

[Charles Mills]

Well, I've never done any sort development and at the risk of creating yet
another nostalgia thread, I can tell you that I have seen a lot of tape
sorts run and they were a thing of beauty. At any one point in time the sort
program was reading half of the tape workfiles backwards. I guess that saved
rewind time (?).

I used to buy third shift time at a service bureau that had two machines (a
360/40 and a 360/50, perhaps). They had five banks of eight 2401's each: two
banks on each machine and one switchable. The operators would switch the
switchable bank to one machine and run these HUGE multi-hour tape sorts on
that machine. Absolutely a thing of beauty, a veritable ballet of spinning
tape reels, dancing vacuum columns, and flashing lights.

In fact, the third shift operators would turn off the datacenter lights, go
out on the fire escape and smoke a little something, and then come back and
sit for hours watching those flashing lights ...

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Blaicher, Christopher Y.
Sent: Monday, February 06, 2017 12:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BSAM vs QSAM (and SORT).

If you consider me one of the SORT experts, I have been involved with sort
development since the early 80's, and never once ran a tape sort.

--
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 (and SORT).

[R.S.]

W dniu 2017-02-06 o 19:55, Paul Gilmartin pisze:

On 2017-02-06, at 07:22, R.S. wrote:

It's worth to mention that performance of reverse processing dataset on real 
tape is worse than horrible.
And IMHO it's not argument for using virtual tapes but for not using datasets 
on tape for applications. Tapes are for backup and ML2.
  

I had understood that old-fashioned SORT with SORTWK on tape employed
read backwards very effectively.  [...]


SORTWK on tape? That's so 70's.
In my shop I'm trying to eliminate SORTWK at all. Memory is faster.
BTW: Read backward effectiveness depends on the tape hardware. We're not 
talking about reels, but about current T1D or TS11x0. Those drives 
are extremely fast when going forward, but not backward. It's like F1 
bolid on crowded parking lot.



--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


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

[Paul Gilmartin]

On Tue, 7 Feb 2017 07:04:38 +0200, Binyamin Dissen wrote:

>I wrote my own QPAM.
> 
According to hearsay, so have others.  This is evidence of a need which should
have resulted in an RFE.  If one was ever submitted, I wonder what became of it?

-- gil

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

[Binyamin Dissen]

I wrote my own QPAM.

On Mon, 6 Feb 2017 20:07:23 -0500 Steve Smith  wrote:

:>I've often wondered why there is no QPAM.  It seems to me that it should
:>hardly involve more than a bit of glue code to swap some fields around here
:>and there.
:>
:>sas
:>
:>On Mon, Feb 6, 2017 at 12:24 PM, Binyamin Dissen > wrote:
:>
:>> Also, reading a PDS member by member requires BPAM (which is really BSAM).
:>>
:>>

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
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 (and SORT).

[Joel C. Ewing]

Back in the days of uncompressed tape blocks (reel-to-reel, & early
3480) there was a nice one-to-one correspondence between a fixed point
on the tape within a block and all the bits in a byte in parallel tracks
on the tape, so it was actually relatively simple to pass the tape past
the heads in the reverse direction and read all the bytes within a block
in reverse order and all the blocks in reverse order at full read speed
with the tape continually moving in reverse.  Tape sorts made use of
that to eliminate the repeated several-minute rewind time each time
another pass over the tape data was required.

I never had to deal with  reverse-read I/O, but PofOp indicates that one
supplied the address of the high end of the buffer as the channel
program data address and the channel decremented rather than incremented
byte addresses while transferring bytes to memory, so that the bytes of
a block would be restored to correct order in memory but would be
high-justified rather than low-justified in the buffer for short blocks.
 So the channel hardware itself effectively reversed the order of bytes
as they were read in reverse order.

I believe once the physical tape blocks became compressed (3480C and
later) it became impossible to actually read the physical blocks with
the tape moving in reverse and extract the original bytes on the fly.
Read reverse on such drives would no doubt have been emulated by the
device by backspacing over blocks, reading physical blocks with a
forward read, extracting the bytes, figuring out what bytes to supply to
the channel in reverse order to be consistent with what read-reverse
should have produced, then backspacing again to get to preceding block
and repeating.  Reversing the tape direction repeatedly while reading an
entire tape in reverse would  totally kill performance on one of those
drives.

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

[Paul Gilmartin]

On Mon, 6 Feb 2017 20:07:23 -0500, Steve Smith wrote:

>I've often wondered why there is no QPAM.  It seems to me that it should
>hardly involve more than a bit of glue code to swap some fields around here
>and there.
> 
I could imagie QNOTE and QPOINT, dealing with a 6-byte token:
TTRZ + 16-bit offset within block.

-- gil

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

[Steve Smith]

I've often wondered why there is no QPAM.  It seems to me that it should
hardly involve more than a bit of glue code to swap some fields around here
and there.

sas

On Mon, Feb 6, 2017 at 12:24 PM, Binyamin Dissen  wrote:

> Also, reading a PDS member by member requires BPAM (which is really BSAM).
>
>
-- 
sas

--
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 (and SORT).

[Blaicher, Christopher Y.]

If you consider me one of the SORT experts, I have been involved with sort 
development since the early 80's, and never once ran a tape sort.

When I first worked for Liberty Mutual Insurance, we had a 7074 hypervisor 
running on a 360/65 and I saw a tape sort running there, but never wrote any 
code for it or the Syncsort version.

Chris Blaicher
Technical Architect
Mainframe Development
Syncsort Incorporated
2 Blue Hill Plaza #1563, Pearl River, NY 10965

P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

www.syncsort.com

CONNECTING BIG IRON TO BIG DATA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, February 6, 2017 1:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BSAM vs QSAM (and SORT).

On 2017-02-06, at 07:22, R.S. wrote:
>
> It's worth to mention that performance of reverse processing dataset on real 
> tape is worse than horrible.
> And IMHO it's not argument for using virtual tapes but for not using datasets 
> on tape for applications. Tapes are for backup and ML2.
>
I had understood that old-fashioned SORT with SORTWK on tape employed read 
backwards very effectively.  Perhaps the SORT expert will jump in:
https://en.wikipedia.org/wiki/Oscillating_merge_sort

It was spectacular to watch.  Are the data un-reversed by hardware, firmware, 
or software?


On 2017-02-06, at 10:24, Binyamin Dissen wrote:

> Also, reading a PDS member by member requires BPAM (which is really BSAM).
>
Which was our motivation, when I was in a small group supporting a FOSS 
compiler and runtime library, for implementing BPAM and BSAM but not QSAM.  
Once we had the BPAM interface, most of the interface could likewise be used 
for BSAM.

Ironically, not burdened by the extreme storage constraints of OS/360, our 
compiler eschewed most of BPAM.  At a COPY-type operation we simply opened 
another DCB, processed the member to the end, then popped back to the parent 
member; no NOTE or POINT involved.  Worked great on MVS; not at all on CMS "OS 
Emulation".

-- gil

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

OPEN INPUT file-name REVERSED was Re: BSAM vs QSAM

[Clark Morris]

[Default] On 6 Feb 2017 11:46:22 -0800, in bit.listserv.ibm-main
t...@harminc.net (Tony Harminc) wrote:

>On 6 February 2017 at 09:22, R.S.  wrote:
>
>> W dniu 2017-02-06 o 14:59, Ron Burr pisze:
>>
>>> As far as I know, reading a physical sequential (or partitioned dataset
>>> member) in reverse order can only be done using BSAM (via the BSP macro).
>>> Not that many applications require that mode of processing. But if one
>>> does, well then, that appears to be the only option. Mind you, there are
>>> some restrictions inherent in using BSP, as the manual explains.
>>> The COBOL manual states that you can process a QSAM tape dataset in
>>> reverse order by doing an OPEN REVERSED, but I suspect that the dataset
>>> will actually be processed using BSAM, not QSAM.
>>>
>>
>> It's worth to mention that performance of reverse processing dataset on
>> real tape is worse than horrible.
>> And IMHO it's not argument for using virtual tapes but for not using
>> datasets on tape for applications. Tapes are for backup and ML2.
>>
>
>Are you two perhaps mixing reading in "reverse order" of records with "read
>backward"? Read Backward is a CCW that (on old reel-to-reel tapes, at
>least) moves the tape backwards past the read head and transfers data into
>main storage in byte-by-byte decreasing address order. So the data ends up
>in normal order in storage, but if your app knows somehow that the tape is
>positioned at the end of the data, it doesn't have to rewind or backspace
>and then read forward.
>
>I have no idea if any modern real or virtual tape supports this, or if
>COBOL or even BSAM/QSAM ever did.

IBM 360/370/390/Enterprise COBOLs implement both CLOSE NO REWIND and
OPEN INPUT REVERSED for single reel files.  The read reversed was a
function used by tape sorts where the work files were on tape.

AIX COBOLs accept and ignore the REVERSED and NO REWIND statements.

Clark Morris
>
>Tony H.
>
>--
>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

[Tony Harminc]

On 6 February 2017 at 09:22, R.S.  wrote:

> W dniu 2017-02-06 o 14:59, Ron Burr pisze:
>
>> As far as I know, reading a physical sequential (or partitioned dataset
>> member) in reverse order can only be done using BSAM (via the BSP macro).
>> Not that many applications require that mode of processing. But if one
>> does, well then, that appears to be the only option. Mind you, there are
>> some restrictions inherent in using BSP, as the manual explains.
>> The COBOL manual states that you can process a QSAM tape dataset in
>> reverse order by doing an OPEN REVERSED, but I suspect that the dataset
>> will actually be processed using BSAM, not QSAM.
>>
>
> It's worth to mention that performance of reverse processing dataset on
> real tape is worse than horrible.
> And IMHO it's not argument for using virtual tapes but for not using
> datasets on tape for applications. Tapes are for backup and ML2.
>

Are you two perhaps mixing reading in "reverse order" of records with "read
backward"? Read Backward is a CCW that (on old reel-to-reel tapes, at
least) moves the tape backwards past the read head and transfers data into
main storage in byte-by-byte decreasing address order. So the data ends up
in normal order in storage, but if your app knows somehow that the tape is
positioned at the end of the data, it doesn't have to rewind or backspace
and then read forward.

I have no idea if any modern real or virtual tape supports this, or if
COBOL or even BSAM/QSAM ever did.

Tony H.

--
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 (and SORT).

[Paul Gilmartin]

On 2017-02-06, at 07:22, R.S. wrote:
> 
> It's worth to mention that performance of reverse processing dataset on real 
> tape is worse than horrible.
> And IMHO it's not argument for using virtual tapes but for not using datasets 
> on tape for applications. Tapes are for backup and ML2.
>  
I had understood that old-fashioned SORT with SORTWK on tape employed
read backwards very effectively.  Perhaps the SORT expert will jump in:
https://en.wikipedia.org/wiki/Oscillating_merge_sort

It was spectacular to watch.  Are the data un-reversed by hardware,
firmware, or software?


On 2017-02-06, at 10:24, Binyamin Dissen wrote:

> Also, reading a PDS member by member requires BPAM (which is really BSAM).
> 
Which was our motivation, when I was in a small group supporting a FOSS
compiler and runtime library, for implementing BPAM and BSAM but not
QSAM.  Once we had the BPAM interface, most of the interface could likewise
be used for BSAM.

Ironically, not burdened by the extreme storage constraints of OS/360, our
compiler eschewed most of BPAM.  At a COPY-type operation we simply opened
another DCB, processed the member to the end, then popped back to the parent
member; no NOTE or POINT involved.  Worked great on MVS; not at all on
CMS "OS Emulation".

-- gil

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

[Binyamin Dissen]

Also, reading a PDS member by member requires BPAM (which is really BSAM).

On Mon, 6 Feb 2017 07:59:24 -0600 Ron Burr  wrote:

:>As far as I know, reading a physical sequential (or partitioned dataset 
member) in reverse order can only be done using BSAM (via the BSP macro). Not 
that many applications require that mode of processing. But if one does, well 
then, that appears to be the only option. Mind you, there are some restrictions 
inherent in using BSP, as the manual explains.
:>The COBOL manual states that you can process a QSAM tape dataset in reverse 
order by doing an OPEN REVERSED, but I suspect that the dataset will actually 
be processed using BSAM, not QSAM.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

[R.S.]

W dniu 2017-02-06 o 14:59, Ron Burr pisze:

As far as I know, reading a physical sequential (or partitioned dataset member) 
in reverse order can only be done using BSAM (via the BSP macro). Not that many 
applications require that mode of processing. But if one does, well then, that 
appears to be the only option. Mind you, there are some restrictions inherent 
in using BSP, as the manual explains.
The COBOL manual states that you can process a QSAM tape dataset in reverse 
order by doing an OPEN REVERSED, but I suspect that the dataset will actually 
be processed using BSAM, not QSAM.


It's worth to mention that performance of reverse processing dataset on 
real tape is worse than horrible.
And IMHO it's not argument for using virtual tapes but for not using 
datasets on tape for applications. Tapes are for backup and ML2.


--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

[Ron Burr]

As far as I know, reading a physical sequential (or partitioned dataset member) 
in reverse order can only be done using BSAM (via the BSP macro). Not that many 
applications require that mode of processing. But if one does, well then, that 
appears to be the only option. Mind you, there are some restrictions inherent 
in using BSP, as the manual explains.
The COBOL manual states that you can process a QSAM tape dataset in reverse 
order by doing an OPEN REVERSED, but I suspect that the dataset will actually 
be processed using BSAM, not QSAM.

Ron Burr
GT Software

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

[David W Noon]

On Sat, 4 Feb 2017 13:24:41 -0500, Jim Mulder (d10j...@us.ibm.com) wrote
about "Re: BSAM vs QSAM" (in
<ofee80157a.02b94811-on002580bd.0064ecec-852580bd.00652...@notes.na.collabserv.com>):

>  I asked Wayne Rhoten.  His recollection is that SAMe GAed as a product 
> around 1978,
> and was integrated in the early 1980s. 

This gels with my experience.

In the early 1980s I was working as a GCOS systems programmer on
Honeywell/GE mainframes, with little contact with IBM boxes. When I
returned to the IBM fold (c. 1984) I found that SAM had been largely
re-architected and was much as we see it today (except it was still
24-bit). The revised SAM was definitely bundled with DFP/XA, but did not
become 31-bit code until MVS/XA SP 2.2.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

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

[Anne & Lynn Wheeler]

013a910fd252-dmarc-requ...@listserv.ua.edu (David W Noon) writes:
> All of the buffer fills and buffer flushes occur quite separately from
> the application program. The EXCP macro is a wonderful thing.

A big problem with the EXCP semantics ... it had applications (and/or
libraries running in application space) to build channel programs/CCWs
in the application space. EXCP then takes the passed channel program
pointer and initiates the I/O.

In the move to all virtual memory ... the big problem is that channel
programs (CCWs) execute with real addresses ... after virtual memory,
all the channel programs were being built with virtual addresses. The
original justification for moving everything to virtual memory was the
horrible MVT storage management (regions required to be four times
larger than typically used) ... typical 370/165 with 1mbyte memory ran
four regions. Moving to virtual memory could increase number of regions
by a factor of four with little or no paging, the increase level of
concurrent activity significantly increasing system throughput (as disks
were increasingly becoming system throughput bottleneck). Old post with
quotes from person directly involved
http://www.garlic.com/~lynn/2011d.html#73 Multiple Virtual Memory

The initial implementation VS2 release 1 (SVS) did a little bit of code
to have single 16mbyte virtual address space ... with MVT layed out as
if running in 16mbyte real machine. The majority of the code was in EXCP
having to create a copy of the passed channel programs, substituting
real addresses for the virtual addresses ... the code was borrowed by
taking CCWTRANS from (virtual machine) CP67.

The move to release 2, MVS involved (sort of) giving each application a
16mbyte virtual address space. However, the extensive MVT
pointer-passing convention required giving 8mbytes of each address space
half the 16mbyte for image of the MVS supervisor. Then because MVT
subsystems were moved to their own separate address spaces ... to enable
pointer passing convention between applications and subsystems, they had
to be stuffed into the "common segment" to support pointer passing API
convention. Starts out as single one mbyte segment, but because the
space needed is somewhat proportional to concurrent activity, number of
subsystems, etc ... it evolves to CSA ... larger systems with 4-6mbytes
CSA ... leaving 2-4mbytes for applications. Late in 3033 period, CSAs
were threatening to expand to 8mbytes ... leaving no available space in
16mbytes for application use.

Also from CP67, charlie had invented compare while working on CP67
fine-grain multiprocessor locking (compare chosen because CAS are
his initials). Initial attempts to get it included in 370 were rebuffed
because the POK favorite son operating system people said it wasn't
needed. 370 architecture people said to justify compare, needed
uses other than kernel locking. Thus were born the uses that still
appear in the appendex of principles of operation ... including
wait/post ECB

ECB
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.idas300/ecb.htm
wait/post
http://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa600/tasks.htm

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

[Jim Mulder]

> Is this still, as Ed recalls, part of a separately-priced SAMe feature?
 
 I asked Wayne Rhoten.  His recollection is that SAMe GAed as a product 
around 1978,
and was integrated in the early 1980s. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY





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

[David W Noon]

On Sat, 4 Feb 2017 02:06:16 +, Jesse 1 Robinson
(jesse1.robin...@sce.com) wrote about "Re: BSAM vs QSAM" (in
<by2pr0101mb080862ff8074b4fdc8c84877bf...@by2pr0101mb0808.prod.exchangelabs.com>):

> I'm bowled over by David Noon's post.

Pleased to be of service. ... :-)

> I did not know that QSAM allowed asynchronous I/O operations and have not 
> looked
> into coding requirements.

The operations are synchronous at the application level, but
asynchronous for the physical I/O transfers.

> At the same time I contend that system managed interleaving is not the same 
> thing.
> While it undoubtedly speeds up I/O for 'traditional' QSAM, the application 
> program
> remains in a WAIT during all the background happenings and cannot
independently
> fiddle with bits and bytes pending I/O completion.

The I/O transfers are behind an opaque API. They run asynchronously from
the program, but the program synchronizes every time it uses a QSAM API
(i.e. a GET or a PUT).

With a decent sized buffer pool, most GET requests return immediately
with the required record. The program only occasionally enters a
WAIT/CHECK condition.

Similarly, most PUT operations copy the data record from the work area
into the buffer pool and return to the program immediately. The buffer
will be queued for flushing when it becomes full.

All of the buffer fills and buffer flushes occur quite separately from
the application program. The EXCP macro is a wonderful thing.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

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

[Charles Mills]

> Anyway, if you have to ask whether to use QSAM or BSAM, the answer is always 
> QSAM.
EXACTLY! 
CharlesSent from a mobile; please excuse the brevity.
 Original message From: Steve Smith <sasd...@gmail.com> Date: 
2/4/17  9:29 AM  (GMT-08:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BSAM vs 
QSAM 
I haven't heard of SAME for years, my bet is it was integrated.  And why
would update have any effect on read-ahead?  QSAM fills all the buffers it
gets, and keeps them full.  It can and does keep track of where you are vs.
where it is quite easily.

Anyway, if you have to ask whether to use QSAM or BSAM, the answer is
always QSAM.  Getting better performance with BSAM requires both unusual
requirements, and considerable knowledge and skill; not to mention more
time, effort, complexity.

sas

On Sat, Feb 4, 2017 at 12:09 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> ...
> I suspect that if the programmer upens for Update the access method
> can't know whether to read-ahead.
>
> ...



> Is this still, as Ed recalls, part of a separately-priced SAMe feature?
>
> Thanks,
> gil
>
>
-- 
sas

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

[Steve Smith]

I haven't heard of SAME for years, my bet is it was integrated.  And why
would update have any effect on read-ahead?  QSAM fills all the buffers it
gets, and keeps them full.  It can and does keep track of where you are vs.
where it is quite easily.

Anyway, if you have to ask whether to use QSAM or BSAM, the answer is
always QSAM.  Getting better performance with BSAM requires both unusual
requirements, and considerable knowledge and skill; not to mention more
time, effort, complexity.

sas

On Sat, Feb 4, 2017 at 12:09 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> ...
> I suspect that if the programmer upens for Update the access method
> can't know whether to read-ahead.
>
> ...



> Is this still, as Ed recalls, part of a separately-priced SAMe feature?
>
> Thanks,
> gil
>
>
-- 
sas

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

[Edward Gould]

>> 
> Is this still, as Ed recalls, part of a separately-priced SAMe feature?
No it was integrated into the base (with XA?? its been a LONG time).
> 
> Thanks,
> gil
> 
> --
> 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

[Paul Gilmartin]

On Sat, 4 Feb 2017 01:49:13 -0500, Jim Mulder wrote:

>  There are no coding requirements for the application,  When you do 
>a QSAM OPEN for Input,  the first read-ahead I/Os are scheduled by OPEN,
>and the application program can proceed without waiting  after the OPEN at 
>least to the point of doing the first GET.  Subsequent read-ahead I/Os can 
>overlap with the  application program processing.
>
>  Similarly for QSAM output, the application program can be doing PUTs  into 
>buffers while output I/O is in progress for  previously  filled output buffers.
> 
I suspect that if the programmer upens for Update the access method
can't know whether to read-ahead.

>  The application program  has little control over this, other than some 
>DCB/DCBE parameters. 
> 
Is this still, as Ed recalls, part of a separately-priced SAMe feature?

Thanks,
gil

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

[Jim Mulder]

  There are no coding requirements for the application,  When you do 
a QSAM OPEN for Input,  the first read-ahead I/Os are scheduled by OPEN,
and the application program can proceed without waiting  after the OPEN at 

least to the point of doing the first GET.  Subsequent read-ahead I/Os can 

overlap with the  application program processing.

  Similarly for QSAM output, the application program can be doing PUTs 
into 
buffers while output I/O is in progress for  previously  filled output 
buffers.

  The application program  has little control over this, other than some 
DCB/DCBE parameters. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 
02/03/2017 09:06:16 PM:

> From: Jesse 1 Robinson <jesse1.robin...@sce.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 02/04/2017 01:38 AM
> Subject: Re: BSAM vs QSAM
> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> 
> I'm bowled over by David Noon's post. I did not know that QSAM 
> allowed asynchronous I/O operations and have not looked into coding 
> requirements. 
> 
> At the same time I contend that system managed interleaving is not 
> the same thing. While it undoubtedly speeds up I/O for 'traditional'
> QSAM, the application program remains in a WAIT during all the 
> background happenings and cannot independently fiddle with bits and 
> bytes pending I/O completion.



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

[Jesse 1 Robinson]

I'm bowled over by David Noon's post. I did not know that QSAM allowed 
asynchronous I/O operations and have not looked into coding requirements. 

At the same time I contend that system managed interleaving is not the same 
thing. While it undoubtedly speeds up I/O for 'traditional' QSAM, the 
application program remains in a WAIT during all the background happenings and 
cannot independently fiddle with bits and bytes pending I/O completion.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rob Schramm
Sent: Friday, February 03, 2017 5:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: BSAM vs QSAM

QSAM does I/O interleaving.  The exact amount of buffers required to trigger 
the behavior has varied somewhat over the years.  20 - 30 seems to be where it 
settled.  Haven't looked into it in years.

Rob Schramm

On Fri, Feb 3, 2017, 8:15 PM Edward Gould <edgould1...@comcast.net> wrote:

> > On Feb 3, 2017, at 6:27 PM, David W Noon <
> 013a910fd252-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > On Fri, 3 Feb 2017 16:54:57 -0600, Paul Gilmartin
> > (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: 
> > BSAM vs QSAM" (in 
> > <4092052368963851.wa.paulgboulderaim@listserv.ua.edu>):
> >
> >> On Fri, 3 Feb 2017 14:42:24 -0500, Farley, Peter x23353 wrote:
> >>>
> >>> OTOH you don't have to wait for completion of a READ or a WRITE.  
> >>> You
> can issue a WRITE at the end of a processing loop and then go back to 
> process the next record while the WRITE completes, and only CHECK the 
> WRITE when you are ready to issue the next WRITE.
> >>>
> >>> Similarly for READ's, issue another READ right after the start of
> processing for the prior record, then CHECK the second READ when you 
> come back to the top of the processing loop.
> >>>
> >> Does QSAM not overlap I/O with processing?  I had expected that on 
> >> the
> first GET
> >> QSAM would issue BUFNO READs; CHECK the first and return the record 
> >> for
> processing
> >> while the remaining BUFNO-1 READs proceeded.
> >
> > This is correct for QSAM in the last 35 years or so. Older versions 
> > of OS did not offer asynchronous transfers as far as the calling 
> > application is concerned, but modern QSAM uses the application API (i.e.
> > GET and PUT macros) as the point[s] when transfers are synchronized.
> > Between GETs and PUTs, I/O transfers continue in the background 
> > where possible.
>
> Some minor nit picking here. IBM sold as a seperate product call 
> SAMe.It provided It provided chained scheduling and 5 buffers for each 
> QSAM opened DCB.
> I don’t remember the monthly cost off hand (I think it was $35 BCBW).
> It provided really great benefits in shortened run time and reduced 
> CPU usage.
> Ed
> >
> > For most applications, there is no real benefit in using BSAM.
> >
> >> Another concern if you need to support BPAM is that BPAM and BSAM 
> >> can
> share more
> >> code than BPAM and QSAM.
> >
> > That's fairly marginal. Much of SAM/E is in the LPA.
> > --
> > Regards,
> >
> > Dave  [RLU #314465]
> > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
> > *-* david.w.n...@googlemail.com (David W Noon)
> > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

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

[Rob Schramm]

QSAM does I/O interleaving.  The exact amount of buffers required to
trigger the behavior has varied somewhat over the years.  20 - 30 seems to
be where it settled.  Haven't looked into it in years.

Rob Schramm

On Fri, Feb 3, 2017, 8:15 PM Edward Gould <edgould1...@comcast.net> wrote:

> > On Feb 3, 2017, at 6:27 PM, David W Noon <
> 013a910fd252-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > On Fri, 3 Feb 2017 16:54:57 -0600, Paul Gilmartin
> > (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: BSAM
> > vs QSAM" (in <4092052368963851.wa.paulgboulderaim@listserv.ua.edu>):
> >
> >> On Fri, 3 Feb 2017 14:42:24 -0500, Farley, Peter x23353 wrote:
> >>>
> >>> OTOH you don't have to wait for completion of a READ or a WRITE.  You
> can issue a WRITE at the end of a processing loop and then go back to
> process the next record while the WRITE completes, and only CHECK the WRITE
> when you are ready to issue the next WRITE.
> >>>
> >>> Similarly for READ's, issue another READ right after the start of
> processing for the prior record, then CHECK the second READ when you come
> back to the top of the processing loop.
> >>>
> >> Does QSAM not overlap I/O with processing?  I had expected that on the
> first GET
> >> QSAM would issue BUFNO READs; CHECK the first and return the record for
> processing
> >> while the remaining BUFNO-1 READs proceeded.
> >
> > This is correct for QSAM in the last 35 years or so. Older versions of
> > OS did not offer asynchronous transfers as far as the calling
> > application is concerned, but modern QSAM uses the application API (i.e.
> > GET and PUT macros) as the point[s] when transfers are synchronized.
> > Between GETs and PUTs, I/O transfers continue in the background where
> > possible.
>
> Some minor nit picking here. IBM sold as a seperate product call SAMe.It
> provided
> It provided chained scheduling and 5 buffers for each QSAM opened DCB.
> I don’t remember the monthly cost off hand (I think it was $35 BCBW).
> It provided really great benefits in shortened run time and reduced CPU
> usage.
> Ed
> >
> > For most applications, there is no real benefit in using BSAM.
> >
> >> Another concern if you need to support BPAM is that BPAM and BSAM can
> share more
> >> code than BPAM and QSAM.
> >
> > That's fairly marginal. Much of SAM/E is in the LPA.
> > --
> > Regards,
> >
> > Dave  [RLU #314465]
> > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> > david.w.n...@googlemail.com (David W Noon)
> > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> >
> >
> >
> > --
> > 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
>
-- 

Rob Schramm

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

[Edward Gould]

> On Feb 3, 2017, at 6:27 PM, David W Noon 
> <013a910fd252-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Fri, 3 Feb 2017 16:54:57 -0600, Paul Gilmartin
> (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: BSAM
> vs QSAM" (in <4092052368963851.wa.paulgboulderaim@listserv.ua.edu>):
> 
>> On Fri, 3 Feb 2017 14:42:24 -0500, Farley, Peter x23353 wrote:
>>> 
>>> OTOH you don't have to wait for completion of a READ or a WRITE.  You can 
>>> issue a WRITE at the end of a processing loop and then go back to process 
>>> the next record while the WRITE completes, and only CHECK the WRITE when 
>>> you are ready to issue the next WRITE.
>>> 
>>> Similarly for READ's, issue another READ right after the start of 
>>> processing for the prior record, then CHECK the second READ when you come 
>>> back to the top of the processing loop.
>>> 
>> Does QSAM not overlap I/O with processing?  I had expected that on the first 
>> GET
>> QSAM would issue BUFNO READs; CHECK the first and return the record for 
>> processing
>> while the remaining BUFNO-1 READs proceeded.
> 
> This is correct for QSAM in the last 35 years or so. Older versions of
> OS did not offer asynchronous transfers as far as the calling
> application is concerned, but modern QSAM uses the application API (i.e.
> GET and PUT macros) as the point[s] when transfers are synchronized.
> Between GETs and PUTs, I/O transfers continue in the background where
> possible.

Some minor nit picking here. IBM sold as a seperate product call SAMe.It 
provided
It provided chained scheduling and 5 buffers for each QSAM opened DCB.
I don’t remember the monthly cost off hand (I think it was $35 BCBW).
It provided really great benefits in shortened run time and reduced CPU usage.
Ed
> 
> For most applications, there is no real benefit in using BSAM.
> 
>> Another concern if you need to support BPAM is that BPAM and BSAM can share 
>> more
>> code than BPAM and QSAM.
> 
> That's fairly marginal. Much of SAM/E is in the LPA.
> -- 
> Regards,
> 
> Dave  [RLU #314465]
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> david.w.n...@googlemail.com (David W Noon)
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> 
> 
> 
> --
> 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

[Paul Gilmartin]

On Sat, 4 Feb 2017 00:27:38 +, David W Noon wrote:
>
>> Another concern if you need to support BPAM is that BPAM and BSAM can share 
>> more
>> code than BPAM and QSAM.
>
>That's fairly marginal. Much of SAM/E is in the LPA.
> 
I was thinking of source code, from the viewpoint of a developer of a
runtime function library.

-- gil

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

[David W Noon]

On Fri, 3 Feb 2017 16:54:57 -0600, Paul Gilmartin
(000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: BSAM
vs QSAM" (in <4092052368963851.wa.paulgboulderaim@listserv.ua.edu>):

> On Fri, 3 Feb 2017 14:42:24 -0500, Farley, Peter x23353 wrote:
>>
>> OTOH you don't have to wait for completion of a READ or a WRITE.  You can 
>> issue a WRITE at the end of a processing loop and then go back to process 
>> the next record while the WRITE completes, and only CHECK the WRITE when you 
>> are ready to issue the next WRITE.
>>
>> Similarly for READ's, issue another READ right after the start of processing 
>> for the prior record, then CHECK the second READ when you come back to the 
>> top of the processing loop.
>>
> Does QSAM not overlap I/O with processing?  I had expected that on the first 
> GET
> QSAM would issue BUFNO READs; CHECK the first and return the record for 
> processing
> while the remaining BUFNO-1 READs proceeded.

This is correct for QSAM in the last 35 years or so. Older versions of
OS did not offer asynchronous transfers as far as the calling
application is concerned, but modern QSAM uses the application API (i.e.
GET and PUT macros) as the point[s] when transfers are synchronized.
Between GETs and PUTs, I/O transfers continue in the background where
possible.

For most applications, there is no real benefit in using BSAM.

> Another concern if you need to support BPAM is that BPAM and BSAM can share 
> more
> code than BPAM and QSAM.

That's fairly marginal. Much of SAM/E is in the LPA.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

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

[Farley, Peter x23353]

Not sure if QSAM overlaps any I/O or not.  You would think so, but TFM has 
little to say about it that I found so far.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, February 03, 2017 5:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BSAM vs QSAM

On Fri, 3 Feb 2017 14:42:24 -0500, Farley, Peter x23353 wrote:
>
>OTOH you don't have to wait for completion of a READ or a WRITE.  You can 
>issue a WRITE at the end of a processing loop and then go back to process the 
>next record while the WRITE completes, and only CHECK the WRITE when you are 
>ready to issue the next WRITE.
>
>Similarly for READ's, issue another READ right after the start of processing 
>for the prior record, then CHECK the second READ when you come back to the top 
>of the processing loop.
> 
Does QSAM not overlap I/O with processing?  I had expected that on the first 
GET QSAM would issue BUFNO READs; CHECK the first and return the record for 
processing while the remaining BUFNO-1 READs proceeded.

Another concern if you need to support BPAM is that BPAM and BSAM can share 
more code than BPAM and QSAM.

--


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

[Jesse 1 Robinson]

From the application program's point of view, there is no overlap. Once a read 
or write is issued, the TCB WAITs until the I/O is complete. Of course the 
application can code for subtask processing to do I/O separately from 
calculation, but that's a whole nother level of escalation in program 
complexity. 

As I said before, other than POC, I can't imagine why anyone would sign on for 
this quagmire to save an ever diminishing thimbleful of performance. Once upon 
a time, machines were hugely expensive and people were a replaceable commodity. 
Now the proportions are reversed. Find something more useful (if not 
necessarily as fun) to do with your time. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, February 03, 2017 2:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: BSAM vs QSAM

On Fri, 3 Feb 2017 14:42:24 -0500, Farley, Peter x23353 wrote:
>
>OTOH you don't have to wait for completion of a READ or a WRITE.  You can 
>issue a WRITE at the end of a processing loop and then go back to process the 
>next record while the WRITE completes, and only CHECK the WRITE when you are 
>ready to issue the next WRITE.
>
>Similarly for READ's, issue another READ right after the start of processing 
>for the prior record, then CHECK the second READ when you come back to the top 
>of the processing loop.
> 
Does QSAM not overlap I/O with processing?  I had expected that on the first 
GET QSAM would issue BUFNO READs; CHECK the first and return the record for 
processing while the remaining BUFNO-1 READs proceeded.

Another concern if you need to support BPAM is that BPAM and BSAM can share 
more code than BPAM and QSAM.

-- gil


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

[Paul Gilmartin]

On Fri, 3 Feb 2017 14:42:24 -0500, Farley, Peter x23353 wrote:
>
>OTOH you don't have to wait for completion of a READ or a WRITE.  You can 
>issue a WRITE at the end of a processing loop and then go back to process the 
>next record while the WRITE completes, and only CHECK the WRITE when you are 
>ready to issue the next WRITE.
>
>Similarly for READ's, issue another READ right after the start of processing 
>for the prior record, then CHECK the second READ when you come back to the top 
>of the processing loop.
> 
Does QSAM not overlap I/O with processing?  I had expected that on the first GET
QSAM would issue BUFNO READs; CHECK the first and return the record for 
processing
while the remaining BUFNO-1 READs proceeded.

Another concern if you need to support BPAM is that BPAM and BSAM can share more
code than BPAM and QSAM.

-- gil

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

[Farley, Peter x23353]

You're welcome.

Beware that I used "record" in my note to mean "block".  The assumption being 
that you process all the records in a READ block or construct all the records 
in a WRITE block before issuing  the next READ or WRITE, respectively.

I remember one notably complex program I was exposed to decades ago that also 
started some predetermined number of new tasks based on the NCP value after 
OPEN to process each block read, posting each process task with the buffer 
address from the CHECKed READ of a block, which introduced yet another level of 
asynchronous processing.  I was so glad back then that I didn't ever have to 
maintain or debug that monster.  But boy did it fly fast!

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph Reichman
Sent: Friday, February 03, 2017 3:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BSAM vs QSAM

Thanks so much for the tip

> On Feb 3, 2017, at 2:42 PM, Farley, Peter x23353 
> <peter.far...@broadridge.com> wrote:
> 
> BSAM only gets you an entire block on a READ.  You have to extract each 
> varying record from the block with your own code.
> 
> On a WRITE you have to give it an entire block, BDW + one or more RDW + 
> record.  You have to construct the block yourself in your own code before you 
> issue the WRITE.
> 
> OTOH you don't have to wait for completion of a READ or a WRITE.  You can 
> issue a WRITE at the end of a processing loop and then go back to process the 
> next record while the WRITE completes, and only CHECK the WRITE when you are 
> ready to issue the next WRITE.
> 
> Similarly for READ's, issue another READ right after the start of processing 
> for the prior record, then CHECK the second READ when you come back to the 
> top of the processing loop.
> 
> Complicated, but it can provide improved (FSVO improved) elapsed time by 
> overlapping processing with I/O rather than processing synchronously.
> 
> HTH
> 
> Peter
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Joseph Reichman
> Sent: Friday, February 03, 2017 2:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: BSAM vs QSAM
> 
> I have huge VB files
> 
> Don't really understand what you mean by
> 
> Deblock after doing a READ then WAIT
> 
> Where an entire block is read subsequent READs Just point to the next 
> record
> 
>> On Feb 3, 2017, at 2:22 PM, Blaicher, Christopher Y. 
>> <cblaic...@syncsort.com> wrote:
>> 
>> There can be if you code for just what you expect.
>> 
>> QSAM does multi-buffer I/O for you, with BSAM you have to issue multiple 
>> WRITE or REAAD commands and do a WAIT, not to mention having to block or 
>> de-block the buffer, which can be a real pain for VBS files.
>> 
>> It really depends on how much you are processing and how often you are doing 
>> it to determine if the amount of time you are going to spend on developing 
>> it makes it worth it.
>> 
>> Using QSAM with GET LOCATE (as long as you aren't processing VBS files) and 
>> a reasonable BUFNO of 10 or more is going to get you close to most BSAM 
>> applications.  GET or PUT with the MOVE option is the easiest to code for.
>> 
>> Chris Blaicher
>> Technical Architect
>> Mainframe Development
>> Syncsort Incorporated
>> 2 Blue Hill Plaza #1563, Pearl River, NY 10965
>> 
>> P: 201-930-8234  |  M: 512-627-3803
>> E: cblaic...@syncsort.com
>> 
>> www.syncsort.com
>> 
>> CONNECTING BIG IRON TO BIG DATA
>> 
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On Behalf Of Joseph Reichman
>> Sent: Friday, February 3, 2017 1:51 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: BSAM vs QSAM
>> 
>> Hi
>> 
>> BSAM is a bit more complex than QSAM
>> 
>> Is there any performance improvement
>> 
>> Thanks
--

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

[Joseph Reichman]

Thanks so much for the tip



> On Feb 3, 2017, at 2:42 PM, Farley, Peter x23353 
> <peter.far...@broadridge.com> wrote:
> 
> BSAM only gets you an entire block on a READ.  You have to extract each 
> varying record from the block with your own code.
> 
> On a WRITE you have to give it an entire block, BDW + one or more RDW + 
> record.  You have to construct the block yourself in your own code before you 
> issue the WRITE.
> 
> OTOH you don't have to wait for completion of a READ or a WRITE.  You can 
> issue a WRITE at the end of a processing loop and then go back to process the 
> next record while the WRITE completes, and only CHECK the WRITE when you are 
> ready to issue the next WRITE.
> 
> Similarly for READ's, issue another READ right after the start of processing 
> for the prior record, then CHECK the second READ when you come back to the 
> top of the processing loop.
> 
> Complicated, but it can provide improved (FSVO improved) elapsed time by 
> overlapping processing with I/O rather than processing synchronously.
> 
> HTH
> 
> Peter
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Joseph Reichman
> Sent: Friday, February 03, 2017 2:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: BSAM vs QSAM
> 
> I have huge VB files 
> 
> Don't really understand what you mean by 
> 
> Deblock after doing a READ then WAIT
> 
> Where an entire block is read subsequent READs
> Just point to the next record 
> 
>> On Feb 3, 2017, at 2:22 PM, Blaicher, Christopher Y. 
>> <cblaic...@syncsort.com> wrote:
>> 
>> There can be if you code for just what you expect.
>> 
>> QSAM does multi-buffer I/O for you, with BSAM you have to issue multiple 
>> WRITE or REAAD commands and do a WAIT, not to mention having to block or 
>> de-block the buffer, which can be a real pain for VBS files.
>> 
>> It really depends on how much you are processing and how often you are doing 
>> it to determine if the amount of time you are going to spend on developing 
>> it makes it worth it.
>> 
>> Using QSAM with GET LOCATE (as long as you aren't processing VBS files) and 
>> a reasonable BUFNO of 10 or more is going to get you close to most BSAM 
>> applications.  GET or PUT with the MOVE option is the easiest to code for.
>> 
>> Chris Blaicher
>> Technical Architect
>> Mainframe Development
>> Syncsort Incorporated
>> 2 Blue Hill Plaza #1563, Pearl River, NY 10965
>> 
>> P: 201-930-8234  |  M: 512-627-3803
>> E: cblaic...@syncsort.com
>> 
>> www.syncsort.com
>> 
>> CONNECTING BIG IRON TO BIG DATA
>> 
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>> Behalf Of Joseph Reichman
>> Sent: Friday, February 3, 2017 1:51 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: BSAM vs QSAM
>> 
>> Hi
>> 
>> BSAM is a bit more complex than QSAM
>> 
>> Is there any performance improvement
>> 
>> Thanks
> --
> 
> 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

[Jesse 1 Robinson]

When reading the doc, be careful about the term 'record'. For a physical 
device, 'record' means 'block' because the device has no notion of logical 
structure. As already pointed out, BSAM read returns an entire block (as in 
BLKSIZE) and leaves the task of segmenting into logical records entirely up to 
you. Some doc might use 'record' for what we understand as 'block'. 

By contrast, QSAM fetches a block (as necessary) and returns to your program 
one logical record at a time. The downside of QSAM is that your program enters 
an implicit WAIT on each read or write. Why a modern application would want to 
undertake the complexity of BSAM--unless required as discussed earlier--would 
be hard to argue. 

BTW as a nascent application programmer, I was advised to use GET LOCATE and 
PUT MOVE for simplest coding. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Blaicher, Christopher Y.
Sent: Friday, February 03, 2017 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: BSAM vs QSAM

Careful on reusing that buffer before the ECB is posted in the write.  You 
could wind up overlaying what is in the middle of being written.  It is not 
safe to reuse the buffer before the ECB is posted.  You may get away with it 
most of the time, but if there is an error and the channel re-drives the I/O 
you may have laid new data in the buffer before the write is done.

Chris Blaicher
Technical Architect
Mainframe Development
Syncsort Incorporated
2 Blue Hill Plaza #1563, Pearl River, NY 10965

P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

www.syncsort.com

CONNECTING BIG IRON TO BIG DATA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Friday, February 3, 2017 2:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BSAM vs QSAM

BSAM only gets you an entire block on a READ.  You have to extract each varying 
record from the block with your own code.

On a WRITE you have to give it an entire block, BDW + one or more RDW + record. 
 You have to construct the block yourself in your own code before you issue the 
WRITE.

OTOH you don't have to wait for completion of a READ or a WRITE.  You can issue 
a WRITE at the end of a processing loop and then go back to process the next 
record while the WRITE completes, and only CHECK the WRITE when you are ready 
to issue the next WRITE.

Similarly for READ's, issue another READ right after the start of processing 
for the prior record, then CHECK the second READ when you come back to the top 
of the processing loop.

Complicated, but it can provide improved (FSVO improved) elapsed time by 
overlapping processing with I/O rather than processing synchronously.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph Reichman
Sent: Friday, February 03, 2017 2:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BSAM vs QSAM

I have huge VB files

Don't really understand what you mean by

Deblock after doing a READ then WAIT

Where an entire block is read subsequent READs Just point to the next record

> On Feb 3, 2017, at 2:22 PM, Blaicher, Christopher Y. <cblaic...@syncsort.com> 
> wrote:
>
> There can be if you code for just what you expect.
>
> QSAM does multi-buffer I/O for you, with BSAM you have to issue multiple 
> WRITE or REAAD commands and do a WAIT, not to mention having to block or 
> de-block the buffer, which can be a real pain for VBS files.
>
> It really depends on how much you are processing and how often you are doing 
> it to determine if the amount of time you are going to spend on developing it 
> makes it worth it.
>
> Using QSAM with GET LOCATE (as long as you aren't processing VBS files) and a 
> reasonable BUFNO of 10 or more is going to get you close to most BSAM 
> applications.  GET or PUT with the MOVE option is the easiest to code for.
>
> Chris Blaicher
> Technical Architect
> Mainframe Development
> Syncsort Incorporated
> 2 Blue Hill Plaza #1563, Pearl River, NY 10965
>
> P: 201-930-8234  |  M: 512-627-3803
> E: cblaic...@syncsort.com
>
> www.syncsort.com
>
> CONNECTING BIG IRON TO BIG DATA
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Joseph Reichman
> Sent: Friday, February 3, 2017 1:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: BSAM vs QSAM
>
> Hi
>
> BSAM is a bit more complex than QSAM
>
> Is there any performance improvement
>
> Thanks


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

[Farley, Peter x23353]

I was assuming distinct read and write buffers.  I have used LOCATE mode on 
READ's and WRITE's to avoid just that issue.  That's another potential speed-up 
using BSAM, using LOCATE mode means you don't have to move large blocks of data 
around (given how slow MVCL(E) operations are.

Obviously it all depends a great deal on the application needs.  YMMV.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Blaicher, Christopher Y.
Sent: Friday, February 03, 2017 2:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BSAM vs QSAM

Careful on reusing that buffer before the ECB is posted in the write.  You 
could wind up overlaying what is in the middle of being written.  It is not 
safe to reuse the buffer before the ECB is posted.  You may get away with it 
most of the time, but if there is an error and the channel re-drives the I/O 
you may have laid new data in the buffer before the write is done.

Chris Blaicher
Technical Architect
Mainframe Development
Syncsort Incorporated
2 Blue Hill Plaza #1563, Pearl River, NY 10965

P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

www.syncsort.com

CONNECTING BIG IRON TO BIG DATA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Friday, February 3, 2017 2:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BSAM vs QSAM

BSAM only gets you an entire block on a READ.  You have to extract each varying 
record from the block with your own code.

On a WRITE you have to give it an entire block, BDW + one or more RDW + record. 
 You have to construct the block yourself in your own code before you issue the 
WRITE.

OTOH you don't have to wait for completion of a READ or a WRITE.  You can issue 
a WRITE at the end of a processing loop and then go back to process the next 
record while the WRITE completes, and only CHECK the WRITE when you are ready 
to issue the next WRITE.

Similarly for READ's, issue another READ right after the start of processing 
for the prior record, then CHECK the second READ when you come back to the top 
of the processing loop.

Complicated, but it can provide improved (FSVO improved) elapsed time by 
overlapping processing with I/O rather than processing synchronously.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph Reichman
Sent: Friday, February 03, 2017 2:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BSAM vs QSAM

I have huge VB files

Don't really understand what you mean by

Deblock after doing a READ then WAIT

Where an entire block is read subsequent READs Just point to the next record

> On Feb 3, 2017, at 2:22 PM, Blaicher, Christopher Y. <cblaic...@syncsort.com> 
> wrote:
>
> There can be if you code for just what you expect.
>
> QSAM does multi-buffer I/O for you, with BSAM you have to issue multiple 
> WRITE or REAAD commands and do a WAIT, not to mention having to block or 
> de-block the buffer, which can be a real pain for VBS files.
>
> It really depends on how much you are processing and how often you are doing 
> it to determine if the amount of time you are going to spend on developing it 
> makes it worth it.
>
> Using QSAM with GET LOCATE (as long as you aren't processing VBS files) and a 
> reasonable BUFNO of 10 or more is going to get you close to most BSAM 
> applications.  GET or PUT with the MOVE option is the easiest to code for.
>
> Chris Blaicher
> Technical Architect
> Mainframe Development
> Syncsort Incorporated
> 2 Blue Hill Plaza #1563, Pearl River, NY 10965
>
> P: 201-930-8234  |  M: 512-627-3803
> E: cblaic...@syncsort.com
>
> www.syncsort.com
>
> CONNECTING BIG IRON TO BIG DATA
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Joseph Reichman
> Sent: Friday, February 3, 2017 1:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: BSAM vs QSAM
>
> Hi
>
> BSAM is a bit more complex than QSAM
>
> Is there any performance improvement
>
> Thanks
--

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

[Blaicher, Christopher Y.]

Careful on reusing that buffer before the ECB is posted in the write.  You 
could wind up overlaying what is in the middle of being written.  It is not 
safe to reuse the buffer before the ECB is posted.  You may get away with it 
most of the time, but if there is an error and the channel re-drives the I/O 
you may have laid new data in the buffer before the write is done.

Chris Blaicher
Technical Architect
Mainframe Development
Syncsort Incorporated
2 Blue Hill Plaza #1563, Pearl River, NY 10965

P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

www.syncsort.com

CONNECTING BIG IRON TO BIG DATA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Friday, February 3, 2017 2:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BSAM vs QSAM

BSAM only gets you an entire block on a READ.  You have to extract each varying 
record from the block with your own code.

On a WRITE you have to give it an entire block, BDW + one or more RDW + record. 
 You have to construct the block yourself in your own code before you issue the 
WRITE.

OTOH you don't have to wait for completion of a READ or a WRITE.  You can issue 
a WRITE at the end of a processing loop and then go back to process the next 
record while the WRITE completes, and only CHECK the WRITE when you are ready 
to issue the next WRITE.

Similarly for READ's, issue another READ right after the start of processing 
for the prior record, then CHECK the second READ when you come back to the top 
of the processing loop.

Complicated, but it can provide improved (FSVO improved) elapsed time by 
overlapping processing with I/O rather than processing synchronously.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph Reichman
Sent: Friday, February 03, 2017 2:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BSAM vs QSAM

I have huge VB files

Don't really understand what you mean by

Deblock after doing a READ then WAIT

Where an entire block is read subsequent READs Just point to the next record

> On Feb 3, 2017, at 2:22 PM, Blaicher, Christopher Y. <cblaic...@syncsort.com> 
> wrote:
>
> There can be if you code for just what you expect.
>
> QSAM does multi-buffer I/O for you, with BSAM you have to issue multiple 
> WRITE or REAAD commands and do a WAIT, not to mention having to block or 
> de-block the buffer, which can be a real pain for VBS files.
>
> It really depends on how much you are processing and how often you are doing 
> it to determine if the amount of time you are going to spend on developing it 
> makes it worth it.
>
> Using QSAM with GET LOCATE (as long as you aren't processing VBS files) and a 
> reasonable BUFNO of 10 or more is going to get you close to most BSAM 
> applications.  GET or PUT with the MOVE option is the easiest to code for.
>
> Chris Blaicher
> Technical Architect
> Mainframe Development
> Syncsort Incorporated
> 2 Blue Hill Plaza #1563, Pearl River, NY 10965
>
> P: 201-930-8234  |  M: 512-627-3803
> E: cblaic...@syncsort.com
>
> www.syncsort.com
>
> CONNECTING BIG IRON TO BIG DATA
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Joseph Reichman
> Sent: Friday, February 3, 2017 1:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: BSAM vs QSAM
>
> Hi
>
> BSAM is a bit more complex than QSAM
>
> Is there any performance improvement
>
> Thanks
--

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





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 i

Re: BSAM vs QSAM

[Blaicher, Christopher Y.]

If you issue a BSAM READ followed by a WAIT, and then deblock the buffer before 
doing the next READ, the system builds a channel program to read just the one 
block.
If on the other hand you issue 10 READ commands in a loop, each READ having its 
own DECB, the system will build a channel program to read the first block and 
then because the other 9 commands are presented before the first has finished, 
it will build a chained channel program to read the 9 in one physical I/O 
operation.  Now there is a fair amount of overhead for each I/O, and the time 
for each block is much less than that, so you wind up reading a lot faster.
You can build a very efficient BSAM process, but it is not for the faint of 
heart.
As I said, QSAM with a reasonably large BUFNO, like 20 or more, will get you 90 
to 95% of the way.

Chris Blaicher
Technical Architect
Mainframe Development
Syncsort Incorporated 
2 Blue Hill Plaza #1563, Pearl River, NY 10965

P: 201-930-8234  |  M: 512-627-3803    
E: cblaic...@syncsort.com

www.syncsort.com

CONNECTING BIG IRON TO BIG DATA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph Reichman
Sent: Friday, February 3, 2017 2:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BSAM vs QSAM

I have huge VB files 

Don't really understand what you mean by 

Deblock after doing a READ then WAIT

Where an entire block is read subsequent READs Just point to the next record 

> On Feb 3, 2017, at 2:22 PM, Blaicher, Christopher Y. <cblaic...@syncsort.com> 
> wrote:
> 
> There can be if you code for just what you expect.
> 
> QSAM does multi-buffer I/O for you, with BSAM you have to issue multiple 
> WRITE or REAAD commands and do a WAIT, not to mention having to block or 
> de-block the buffer, which can be a real pain for VBS files.
> 
> It really depends on how much you are processing and how often you are doing 
> it to determine if the amount of time you are going to spend on developing it 
> makes it worth it.
> 
> Using QSAM with GET LOCATE (as long as you aren't processing VBS files) and a 
> reasonable BUFNO of 10 or more is going to get you close to most BSAM 
> applications.  GET or PUT with the MOVE option is the easiest to code for.
> 
> Chris Blaicher
> Technical Architect
> Mainframe Development
> Syncsort Incorporated
> 2 Blue Hill Plaza #1563, Pearl River, NY 10965
> 
> P: 201-930-8234  |  M: 512-627-3803
> E: cblaic...@syncsort.com
> 
> www.syncsort.com
> 
> CONNECTING BIG IRON TO BIG DATA
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Joseph Reichman
> Sent: Friday, February 3, 2017 1:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: BSAM vs QSAM
> 
> Hi
> 
> BSAM is a bit more complex than QSAM
> 
> Is there any performance improvement
> 
> Thanks
> 
> --
> 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

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

[Farley, Peter x23353]

BSAM only gets you an entire block on a READ.  You have to extract each varying 
record from the block with your own code.

On a WRITE you have to give it an entire block, BDW + one or more RDW + record. 
 You have to construct the block yourself in your own code before you issue the 
WRITE.

OTOH you don't have to wait for completion of a READ or a WRITE.  You can issue 
a WRITE at the end of a processing loop and then go back to process the next 
record while the WRITE completes, and only CHECK the WRITE when you are ready 
to issue the next WRITE.

Similarly for READ's, issue another READ right after the start of processing 
for the prior record, then CHECK the second READ when you come back to the top 
of the processing loop.

Complicated, but it can provide improved (FSVO improved) elapsed time by 
overlapping processing with I/O rather than processing synchronously.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph Reichman
Sent: Friday, February 03, 2017 2:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BSAM vs QSAM

I have huge VB files 

Don't really understand what you mean by 

Deblock after doing a READ then WAIT

Where an entire block is read subsequent READs
Just point to the next record 

> On Feb 3, 2017, at 2:22 PM, Blaicher, Christopher Y. <cblaic...@syncsort.com> 
> wrote:
> 
> There can be if you code for just what you expect.
> 
> QSAM does multi-buffer I/O for you, with BSAM you have to issue multiple 
> WRITE or REAAD commands and do a WAIT, not to mention having to block or 
> de-block the buffer, which can be a real pain for VBS files.
> 
> It really depends on how much you are processing and how often you are doing 
> it to determine if the amount of time you are going to spend on developing it 
> makes it worth it.
> 
> Using QSAM with GET LOCATE (as long as you aren't processing VBS files) and a 
> reasonable BUFNO of 10 or more is going to get you close to most BSAM 
> applications.  GET or PUT with the MOVE option is the easiest to code for.
> 
> Chris Blaicher
> Technical Architect
> Mainframe Development
> Syncsort Incorporated
> 2 Blue Hill Plaza #1563, Pearl River, NY 10965
> 
> P: 201-930-8234  |  M: 512-627-3803
> E: cblaic...@syncsort.com
> 
> www.syncsort.com
> 
> CONNECTING BIG IRON TO BIG DATA
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Joseph Reichman
> Sent: Friday, February 3, 2017 1:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: BSAM vs QSAM
> 
> Hi
> 
> BSAM is a bit more complex than QSAM
> 
> Is there any performance improvement
> 
> Thanks
--

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

[retired mainframer]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joseph Reichman
> Sent: Friday, February 03, 2017 11:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: BSAM vs QSAM
> 
> I have huge VB files
> 
> Don't really understand what you mean by
> 
> Deblock after doing a READ then WAIT
> 
> Where an entire block is read subsequent READs
> Just point to the next record

When using BSAM, READs don't point anywhere.  A read simply loads the next
BLOCK into the buffer you specify.  If there is more than one record in the
block, it is your job to use the BDW and RDW  to determine if the next
record exists and where it is located within the block.  This process is
called deblocking.

If you issue a READ specifying the same buffer before you have processed all
the records in the block, those records are gone and you have a new set of
records in the buffer.  The READ did not care that you were not done with
the block.

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

[Joseph Reichman]

I have huge VB files 

Don't really understand what you mean by 

Deblock after doing a READ then WAIT

Where an entire block is read subsequent READs
Just point to the next record 

> On Feb 3, 2017, at 2:22 PM, Blaicher, Christopher Y. <cblaic...@syncsort.com> 
> wrote:
> 
> There can be if you code for just what you expect.
> 
> QSAM does multi-buffer I/O for you, with BSAM you have to issue multiple 
> WRITE or REAAD commands and do a WAIT, not to mention having to block or 
> de-block the buffer, which can be a real pain for VBS files.
> 
> It really depends on how much you are processing and how often you are doing 
> it to determine if the amount of time you are going to spend on developing it 
> makes it worth it.
> 
> Using QSAM with GET LOCATE (as long as you aren't processing VBS files) and a 
> reasonable BUFNO of 10 or more is going to get you close to most BSAM 
> applications.  GET or PUT with the MOVE option is the easiest to code for.
> 
> Chris Blaicher
> Technical Architect
> Mainframe Development
> Syncsort Incorporated
> 2 Blue Hill Plaza #1563, Pearl River, NY 10965
> 
> P: 201-930-8234  |  M: 512-627-3803
> E: cblaic...@syncsort.com
> 
> www.syncsort.com
> 
> CONNECTING BIG IRON TO BIG DATA
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Joseph Reichman
> Sent: Friday, February 3, 2017 1:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: BSAM vs QSAM
> 
> Hi
> 
> BSAM is a bit more complex than QSAM
> 
> Is there any performance improvement
> 
> Thanks
> 
> --
> 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

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

[Jesse 1 Robinson]

I would say that BSAM is a lot more complicated than QSAM. Whether the small 
performance advantage is worth extra debugging effort and disruption to 
production has to be factored in to the choice. In my personal view, it's 
almost never worth the extra hassle.

Note however that some very specific I/O situations require BSAM. One example 
that occupied a recent thread here is FBS ('standard') files, where a specific 
record can be assumed to occupy a certain spot in a specific block because 
there are no 'short' blocks before the last. This is logically similar to 
Direct Access DSORG. Very few applications have such a requirement.   

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph Reichman
Sent: Friday, February 03, 2017 10:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):BSAM vs QSAM

Hi

BSAM is a bit more complex than QSAM 

Is there any performance improvement

Thanks 


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

[Blaicher, Christopher Y.]

There can be if you code for just what you expect.

QSAM does multi-buffer I/O for you, with BSAM you have to issue multiple WRITE 
or REAAD commands and do a WAIT, not to mention having to block or de-block the 
buffer, which can be a real pain for VBS files.

It really depends on how much you are processing and how often you are doing it 
to determine if the amount of time you are going to spend on developing it 
makes it worth it.

Using QSAM with GET LOCATE (as long as you aren't processing VBS files) and a 
reasonable BUFNO of 10 or more is going to get you close to most BSAM 
applications.  GET or PUT with the MOVE option is the easiest to code for.

Chris Blaicher
Technical Architect
Mainframe Development
Syncsort Incorporated
2 Blue Hill Plaza #1563, Pearl River, NY 10965

P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

www.syncsort.com

CONNECTING BIG IRON TO BIG DATA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph Reichman
Sent: Friday, February 3, 2017 1:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: BSAM vs QSAM

Hi

BSAM is a bit more complex than QSAM

Is there any performance improvement

Thanks

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

BSAM vs QSAM

[Joseph Reichman]

Hi

BSAM is a bit more complex than QSAM 

Is there any performance improvement

Thanks 

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