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:[email protected]] On Behalf 
Of Joseph Reichman
Sent: Friday, February 03, 2017 3:34 PM
To: [email protected]
Subject: Re: BSAM vs QSAM

Thanks so much for the tip

> On Feb 3, 2017, at 2:42 PM, Farley, Peter x23353 
> <[email protected]> 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:[email protected]] 
> On Behalf Of Joseph Reichman
> Sent: Friday, February 03, 2017 2:27 PM
> To: [email protected]
> 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. 
>> <[email protected]> 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: [email protected]
>> 
>> www.syncsort.com
>> 
>> CONNECTING BIG IRON TO BIG DATA
>> 
>> 
>> -----Original Message-----
>> From: IBM Mainframe Discussion List [mailto:[email protected]] 
>> On Behalf Of Joseph Reichman
>> Sent: Friday, February 3, 2017 1:51 PM
>> To: [email protected]
>> 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 [email protected] with the message: INFO IBM-MAIN

Reply via email to