Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Seymour J Metz]

XDAP is basically EXCP with some housekeeping for DASD.



-- 
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on behalf of 
Attila Fogarasi 
Sent: Sunday, November 12, 2023 5:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

Don't forget about XDAP ... that still works, as an alternative to using
access methods :) Of course XDAP is 24-bit only (for the most part).

On Sun, Nov 12, 2023 at 8:11 PM Martin Trübner <
047eec287bd9-dmarc-requ...@listserv.ua.edu> wrote:

> I wrote code that did it and it saved considerable time.
>
>
> Here is the setting/requirments
>
>
> the processing programs can not be changed.
>
> the program skips records till the first correct record is read- then
> does one after the other till out of range or EOF.
>
> The file is FBS (created under VSE which does not support DISP=MOD)
>
> The file needs a full 3390 mod 27 (or bigger)
>
>
> Solution: a POST-OPEN Vendor exit which manipulated the DTFSD such that
> the next (first) read is way into the file.
>
>
> Problem I ran into: multiextent-files (there is no way to tell the
> op-sys to open the n-th extent of a sequential file during above
> mentioned exit). This was no real restrictiooon since the file had its
> own disk anyway - so creating it with singe extent on a disk was easy.
>
>
> Martin
>
> --
> 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: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Jon Perryman]

On Sat, 11 Nov 2023 18:43:18 -0600, Michael Oujesky  
wrote:

>Does seek() actually do a direct access?  Or read, but skip the
>records from the start of the file?

seek() only reads the physical record containing the byte position. This is 
also true on Unix where physical records are called sectors.

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Attila Fogarasi]

Don't forget about XDAP ... that still works, as an alternative to using
access methods :) Of course XDAP is 24-bit only (for the most part).

On Sun, Nov 12, 2023 at 8:11 PM Martin Trübner <
047eec287bd9-dmarc-requ...@listserv.ua.edu> wrote:

> I wrote code that did it and it saved considerable time.
>
>
> Here is the setting/requirments
>
>
> the processing programs can not be changed.
>
> the program skips records till the first correct record is read- then
> does one after the other till out of range or EOF.
>
> The file is FBS (created under VSE which does not support DISP=MOD)
>
> The file needs a full 3390 mod 27 (or bigger)
>
>
> Solution: a POST-OPEN Vendor exit which manipulated the DTFSD such that
> the next (first) read is way into the file.
>
>
> Problem I ran into: multiextent-files (there is no way to tell the
> op-sys to open the n-th extent of a sequential file during above
> mentioned exit). This was no real restrictiooon since the file had its
> own disk anyway - so creating it with singe extent on a disk was easy.
>
>
> Martin
>
> --
> 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: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Martin Trübner]

I wrote code that did it and it saved considerable time.


Here is the setting/requirments


the processing programs can not be changed.

the program skips records till the first correct record is read- then 
does one after the other till out of range or EOF.


The file is FBS (created under VSE which does not support DISP=MOD)

The file needs a full 3390 mod 27 (or bigger)


Solution: a POST-OPEN Vendor exit which manipulated the DTFSD such that 
the next (first) read is way into the file.



Problem I ran into: multiextent-files (there is no way to tell the 
op-sys to open the n-th extent of a sequential file during above 
mentioned exit). This was no real restrictiooon since the file had its 
own disk anyway - so creating it with singe extent on a disk was easy.



Martin

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Seymour J Metz]

ObTRUNCEvery time someone says "I don't believe in theories", another theory 
dies.




-- 
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on behalf of 
Joel C. Ewing 
Sent: Saturday, November 11, 2023 11:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

On 11/11/23 21:03, Ed Jaffe wrote:
> On 11/11/2023 6:40 PM, Paul Gilmartin wrote:
>> On Sun, 12 Nov 2023 02:16:07 +, Seymour J Metz wrote:
>>
>>> Solves what problem? Unix doesn't have records, so you have to
>>> impose your own record structure and tell seek the byte offset.
>>>
>> He said FB.  That makes the calc simple.
>
> FB allows short blocks. FBS would be needed to do true skip-sequential.

But of course short blocks, other than the last block, will not be
present with RECFM=FB sequential datasets that are created by the usual
means with a single OPEN-CLOSE sequence -- internal short blocks only
happen when the dataset is created as multiple segments with subsequent
OPENs appending to existing records by opening the dataset with
DISP=MOD, as each CLOSE has the potential to create a short block.   So
in those contexts where you know from the way the dataset was created
that the "allowed" embedded short blocks cannot actually be present,
RECFM=FB works also.  If you wanted to verify whether a specific
FB-created dataset contained internal short blocks, i believe you could
run any utility that would read the entire dataset using JCL to override
the dataset RECFM with RECFM=FBS, and you should get some error
indication like IEB174I if internal short blocks are found.

 JC Ewing


--
Joel C. Ewing

--
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: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Joel C. Ewing]

On 11/11/23 21:03, Ed Jaffe wrote:

On 11/11/2023 6:40 PM, Paul Gilmartin wrote:

On Sun, 12 Nov 2023 02:16:07 +, Seymour J Metz wrote:

Solves what problem? Unix doesn't have records, so you have to 
impose your own record structure and tell seek the byte offset.



He said FB.  That makes the calc simple.


FB allows short blocks. FBS would be needed to do true skip-sequential.


But of course short blocks, other than the last block, will not be 
present with RECFM=FB sequential datasets that are created by the usual 
means with a single OPEN-CLOSE sequence -- internal short blocks only 
happen when the dataset is created as multiple segments with subsequent 
OPENs appending to existing records by opening the dataset with 
DISP=MOD, as each CLOSE has the potential to create a short block.   So 
in those contexts where you know from the way the dataset was created 
that the "allowed" embedded short blocks cannot actually be present, 
RECFM=FB works also.  If you wanted to verify whether a specific 
FB-created dataset contained internal short blocks, i believe you could 
run any utility that would read the entire dataset using JCL to override 
the dataset RECFM with RECFM=FBS, and you should get some error 
indication like IEB174I if internal short blocks are found.


    JC Ewing


--
Joel C. Ewing

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Paul Gilmartin]

On Sat, 11 Nov 2023 19:03:01 -0800, Ed Jaffe wrote:

>On 11/11/2023 6:40 PM, Paul Gilmartin wrote:
>> On Sun, 12 Nov 2023 02:16:07 +, Seymour J Metz wrote:
>>
>>> Solves what problem? Unix doesn't have records, so you have to impose your 
>>> own record structure and tell seek the byte offset.
>>>
>> He said FB.  That makes the calc simple.
>
>FB allows short blocks. FBS would be needed to do true skip-sequential.
>
He said "Unix".  In UNIX there are no short blocks, even if the file has been
appended repeatedly.

(I was focusing on the "F", not the "B".  QSAM/BSAM write to a UNIX file
loses the block boundaries.)

-- 
gil

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Ed Jaffe]

On 11/11/2023 6:40 PM, Paul Gilmartin wrote:

On Sun, 12 Nov 2023 02:16:07 +, Seymour J Metz wrote:


Solves what problem? Unix doesn't have records, so you have to impose your own 
record structure and tell seek the byte offset.


He said FB.  That makes the calc simple.


FB allows short blocks. FBS would be needed to do true skip-sequential.

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Paul Gilmartin]

On Sun, 12 Nov 2023 02:16:07 +, Seymour J Metz wrote:

>Solves what problem? Unix doesn't have records, so you have to impose your own 
>record structure and tell seek the byte offset.
> 
He said FB.  That makes the calc simple.

>On 11/11/23 06:59:07, David S. wrote:
>> To help resolve a question posted to a LinkedIn group I manage:
>> http://www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
>> ... I'd like to find out if there's any way to achieve *true*
>> Skip-Sequential processing with a Fixed Block Sequential File with a fairly
>> short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?

-- 
gil

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Seymour J Metz]

Solves what problem? Unix doesn't have records, so you have to impose your own 
record structure and tell seek the byte offset.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, November 11, 2023 5:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

On 11/11/23 06:59:07, David S. wrote:
> To help resolve a question posted to a LinkedIn group I manage:
> http://www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
> ... I'd like to find out if there's any way to achieve *true*
> Skip-Sequential processing with a Fixed Block Sequential File with a fairly
> short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?
> For example: Begin sequential processing at record number 100, *without*
> having to read the first 99 records.
>
>
This feels like a job for DSFS.
<https://www.ibm.com/docs/en/zos/3.1.0?topic=zos-data-set-file-system-dsfs>

UNIX readily solves the problem with seek() and DSFS is supposed
to mimic a UNIX file with the content of a Classic data set.

Where's the User's Guide for DSFS?

Is the skip count fixed, or is it dynamic, varying up or down
with successive executions of your program?

--
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: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Paul Gilmartin]

On Sat, 11 Nov 2023 18:43:18 -0600, Michael Oujesky wrote:

>Does seek() actually do a direct access?  Or read, but skip the
>records from the start of the file?
> 


It doesn't say it reads.  IBM's documentation policy is to document what they do
and not do what they don't say they do.

Dies POINT "read, but skip the records from the start of the file?"  Does the
Services Ref contain an affirmative denial?

-- 
gil

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Michael Oujesky]

Does seek() actually do a direct access?  Or read, but skip the 
records from the start of the file?


Michael

At 04:21 PM 11/11/2023, Paul Gilmartin wrote:

On 11/11/23 06:59:07, David S. wrote:

UNIX readily solves the problem with seek() and DSFS is supposed
to mimic a UNIX file with the content of a Classic data set.

Where's the User's Guide for DSFS?

Is the skip count fixed, or is it dynamic, varying up or down
with successive executions of your program?

--
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: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Michael Oujesky]

I forgt to ask what the BLKSIZE is and why yhe need to skip reading 
just the first 99 records?


Michaet

At 09:34 AM 11/11/2023, Michael Oujesky wrote:

Just a thought as I have not done it, but use BDAM to access the file?

Michael

At 07:59 AM 11/11/2023, David S. wrote:


To help resolve a question posted to a LinkedIn group I manage:
www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
... I'd like to find out if there's any way to achieve *true*
Skip-Sequential processing with a Fixed Block Sequential File with a fairly
short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?
For example: Begin sequential processing at record number 100, *without*
having to read the first 99 records.
Note: We already know certain VSAM formats can do this, but the file in
question is a DSORG=PS *Sequential* file, *not* VSAM. This is a rock-solid
requirement and cannot be changed. We also already know how certain
utilities such as SORT and REXX can *mimic* skip-sequential functionality
by *discarding* unwanted records until the specified record number is
reached. This is a likewise rock-solid requirement. Sequential processing
*must* begin at specified starting point and there can be *no* reading of
any records prior to that point.
My gut feeling is it *cannot* be done - at least not with RECFM=FB.  It
*might* be possible with RECFM=F, but efficiency would then be so
compromised it would  probably outweigh any advantage from *true*
skip-sequential processing.

--
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: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Mike Schwab]

You can add KEYLEN with the length of the key (default 0)
https://www.ibm.com/docs/en/zos/2.1.0?topic=kp-syntax-4
and KEYOFF with the offset of the Key (default 0).

Copies the high key value from the block into the key field of CKD then you
can add skip sequential processing to Cobol, PL/I, ASM, or other languages
that support keyed access programs, and full read and write programs won't
be affected (beyond changing allocation at creation).  You will be reading,
writing existing blocks so adding or deleting records will not be
possible.

The elapsed time break even point is probably 5 records per cylinder
average over reading all the data. All emulated 3390s read whole tracks at
once.

On Sat, Nov 11, 2023 at 9:35 AM Michael Oujesky 
wrote:

> Just a thought as I have not done it, but use BDAM to access the file?
>
> Michael
>
> At 07:59 AM 11/11/2023, David S. wrote:
>
> >To help resolve a question posted to a LinkedIn group I manage:
> >www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
> >... I'd like to find out if there's any way to achieve *true*
> >Skip-Sequential processing with a Fixed Block Sequential File with a
> fairly
> >short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?
> >For example: Begin sequential processing at record number 100, *without*
> >having to read the first 99 records.
> >Note: We already know certain VSAM formats can do this, but the file in
> >question is a DSORG=PS *Sequential* file, *not* VSAM. This is a rock-solid
> >requirement and cannot be changed. We also already know how certain
> >utilities such as SORT and REXX can *mimic* skip-sequential functionality
> >by *discarding* unwanted records until the specified record number is
> >reached. This is a likewise rock-solid requirement. Sequential processing
> >*must* begin at specified starting point and there can be *no* reading of
> >any records prior to that point.
> >My gut feeling is it *cannot* be done - at least not with RECFM=FB.  It
> >*might* be possible with RECFM=F, but efficiency would then be so
> >compromised it would  probably outweigh any advantage from *true*
> >skip-sequential processing.
> >
> >--
> >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: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Paul Gilmartin]

On 11/11/23 06:59:07, David S. wrote:
> To help resolve a question posted to a LinkedIn group I manage:
> www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
> ... I'd like to find out if there's any way to achieve *true*
> Skip-Sequential processing with a Fixed Block Sequential File with a fairly
> short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?
> For example: Begin sequential processing at record number 100, *without*
> having to read the first 99 records.
> 
> 
This feels like a job for DSFS.


UNIX readily solves the problem with seek() and DSFS is supposed
to mimic a UNIX file with the content of a Classic data set.

Where's the User's Guide for DSFS?

Is the skip count fixed, or is it dynamic, varying up or down
with successive executions of your program?

-- 
gil

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Michael Stein]

On Sat, Nov 11, 2023 at 08:59:07AM -0500, David S. wrote:
> ... I'd like to find out if there's any way to achieve *true*
> Skip-Sequential processing with a Fixed Block Sequential File with a fairly
> short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?

> question is a DSORG=PS *Sequential* file, *not* VSAM. This is a rock-solid
> requirement and cannot be changed. 

> Sequential processing *must* begin at specified starting point and
> there can be *no* reading of any records prior to that point.

I take this to mean that the support routines may read a few other records
or blocks but they should not be returned to the application program.

  (VSAM skip-sequential is going to read the whole CI which might include
  records before the one requested...)

> My gut feeling is it *cannot* be done - at least not with RECFM=FB. 

I'm assuming that the DSORG=PS RECFM=FB file is huge.  If the process
which creates the input file could be changed to make it FBS then previous
answers have covered what's necessary to calculate the correct block to
start the sequential reads via BSAM using point. 

If it is only FB and not FBS then it's a bit harder.  Perhaps it's 
been written DISP=MOD and thus is likely to have some short blocks.

Possible plans:

A. build an index of record number to position in the file and
   then use this to find where to start reading.

   If the index was kept around the huge file could be skip-seq read
   several times without rebuilding the index.  The index might be pretty
   small as it only needs to keep the record number for say each track
   or cylinder.

   The index could be built by reading the whole input file or the data
   transfer could be minimized by using EXCP with read count CCWs to
   collect block sizes and locations.  This might also minimize the real
   time as I'd expect that some "virtual disk" boxes might even be able
   to execute the read count CCWs without waiting for disk revolutions
   (and of course, not transfering the data, just the count fields).

B. guess where the record might be and adjust the guess as needed

   If the records have some identifying information in them so that the
   position in the file (record number) record number isn't really the
   only way to find the correct record, then it should be possible to
   guess a likely location and search the blocks around there.  If there
   are only few short blocks this might only involve reading a block or
   two more than the FBS case.

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Joel C. Ewing]

If the question is whether there is direct z/OS support for this for FB 
PS datasets, the answer is probably no, although if you get down to 
assembler coding, there are ways to get close.


It looks like you could potentially design and implement an I/O 
interface routine (in assembler) using BSAM access macros and POINT for 
positioning to a block by calculating what block and record within a 
block to start processing.  Under the covers this is similar to what 
VSAM does -- determine starting block and logically skip over unwanted 
records in the first block .  Since the smallest physical read is for a 
block, you obviously can't avoid the overhead of a physical read of 
unwanted records in the first and last needed blocks on 
skip-sequential.  With VSAM, if you allow too much buffer space, you can 
even waste resources reading unneeded blocks beyond the last block 
needed if only a few records are read at each read point.


Of course the nasty part is, I believe, all higher-level programming 
languages are going to want to access the dataset using QSAM access for 
buffered I/O, and POINT is not supported for QSAM access.  A solution 
likely requires Assembler code.  A BSAM READ only reads a single block; 
so by default there is no buffered read-ahead for following blocks and 
no overlap between processing and disk block reads, and at best you only 
get one block per disk revolution.  If you want decent performance 
reading multiple sequential blocks in a single disk rotation and 
overlapping processing & I/O, I'm pretty sure you have to do your own 
buffer management and queue up multiple read requests to initiate 
reading blocks before they are needed, and only check for I/O completion 
on a block when the block is needed.  I think if multiple BSAM READs are 
issued for sequential blocks in the same dataset, and their channel 
programs are waiting in the queue for the channel, that zOS may chain 
the channel programs of queued requests for the same dataset together so 
that multiple blocks can be read in one disk revolution.  If that's not 
the case with BSAM access, and if each skip-sequential read sequence 
will require multiple blocks, then getting down to the level of building 
channel programs may be required for efficiency, and an efficient 
solution becomes an order of magnitude more difficult.


So the longer answer is that it can be done, but unless you can find 
assembler-level code that already provides this capability, this looks 
like a lot of work just to avoid looking at a VSAM solution.  Perhaps 
someone has already written code to do this type of access efficiently 
for FB PS datasets (check the CBT utilities?).


I would think whatever process generates a FB PS dataset could almost as 
easily generate an ESDS dataset.  Or perhaps an ESDS copy of the dataset 
could be made.


This all presumes the FB PS dataset is created in such a way that the 
only potentially-short block is the last.  The mention of UNIX files is 
an interesting thought, but I have no idea how clever that support may 
be on doing buffered reads of subsequent blocks to maximize I/O 
performance.  ESDS skip-sequential should by default pre-read following 
blocks based on number of buffers specified, which you can control.in 
the JCL


   JC Ewing

On 11/11/23 07:59, David S. wrote:

To help resolve a question posted to a LinkedIn group I manage:
www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
... I'd like to find out if there's any way to achieve *true*
Skip-Sequential processing with a Fixed Block Sequential File with a fairly
short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?
For example: Begin sequential processing at record number 100, *without*
having to read the first 99 records.
Note: We already know certain VSAM formats can do this, but the file in
question is a DSORG=PS *Sequential* file, *not* VSAM. This is a rock-solid
requirement and cannot be changed. We also already know how certain
utilities such as SORT and REXX can *mimic* skip-sequential functionality
by *discarding* unwanted records until the specified record number is
reached. This is a likewise rock-solid requirement. Sequential processing
*must* begin at specified starting point and there can be *no* reading of
any records prior to that point.
My gut feeling is it *cannot* be done - at least not with RECFM=FB.  It
*might* be possible with RECFM=F, but efficiency would then be so
compromised it would  probably outweigh any advantage from *true*
skip-sequential processing.



--
Joel C. Ewing

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Walt Farrell]

On Sat, 11 Nov 2023 08:59:07 -0500, David S.  wrote:

>To help resolve a question posted to a LinkedIn group I manage:
>www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
>... I'd like to find out if there's any way to achieve *true*
>Skip-Sequential processing with a Fixed Block Sequential File with a fairly
>short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?
>For example: Begin sequential processing at record number 100, *without*
>having to read the first 99 records.

As another user mentioned, you can't really read portions of blocks, so 
whatever block contains record number 100 would need to be read, which might 
give you some extraneous data transfer.

The real issue is your RECFM=FB. With FBS it would be possible, as with FBS you 
know that all blocks up to the final one are the same size, and that would 
allow you to calculate the block you needed. But with FB you could have short 
blocks in the middle, making it impossible to calculate where record 100 is 
located.

Another issue, I suppose, is what language you're writing in, as I believe only 
some access methods would allow you to position the file based on a block 
number.

-- 
Walt

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Paul Gilmartin]

On Sat, 11 Nov 2023 08:59:07 -0500, David S. wrote:
>...
. Sequential processing
>*must* begin at specified starting point and there can be *no* reading of
>any records prior to that point.
>
That sounds absurd.  So if a block contains 10 records, you want to
be able to read the last 5 with "*no* reading of" the first 5!?
DASD don't work that way.

>My gut feeling is it *cannot* be done - at least not with RECFM=FB.  It
>*might* be possible with RECFM=F, but efficiency would then be so
>compromised it would  probably outweigh any advantage from *true*
>skip-sequential processing.

How about UNIX files with RECFM=FB,FILEDATA=BINARY and using
seek()?  (But that still reads entire blocks into a buffer.)

-- 
gil

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Michael Oujesky]

Just a thought as I have not done it, but use BDAM to access the file?

Michael

At 07:59 AM 11/11/2023, David S. wrote:


To help resolve a question posted to a LinkedIn group I manage:
www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
... I'd like to find out if there's any way to achieve *true*
Skip-Sequential processing with a Fixed Block Sequential File with a fairly
short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?
For example: Begin sequential processing at record number 100, *without*
having to read the first 99 records.
Note: We already know certain VSAM formats can do this, but the file in
question is a DSORG=PS *Sequential* file, *not* VSAM. This is a rock-solid
requirement and cannot be changed. We also already know how certain
utilities such as SORT and REXX can *mimic* skip-sequential functionality
by *discarding* unwanted records until the specified record number is
reached. This is a likewise rock-solid requirement. Sequential processing
*must* begin at specified starting point and there can be *no* reading of
any records prior to that point.
My gut feeling is it *cannot* be done - at least not with RECFM=FB.  It
*might* be possible with RECFM=F, but efficiency would then be so
compromised it would  probably outweigh any advantage from *true*
skip-sequential processing.

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

Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[David S.]

To help resolve a question posted to a LinkedIn group I manage:
www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
... I'd like to find out if there's any way to achieve *true*
Skip-Sequential processing with a Fixed Block Sequential File with a fairly
short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?
For example: Begin sequential processing at record number 100, *without*
having to read the first 99 records.
Note: We already know certain VSAM formats can do this, but the file in
question is a DSORG=PS *Sequential* file, *not* VSAM. This is a rock-solid
requirement and cannot be changed. We also already know how certain
utilities such as SORT and REXX can *mimic* skip-sequential functionality
by *discarding* unwanted records until the specified record number is
reached. This is a likewise rock-solid requirement. Sequential processing
*must* begin at specified starting point and there can be *no* reading of
any records prior to that point.
My gut feeling is it *cannot* be done - at least not with RECFM=FB.  It
*might* be possible with RECFM=F, but efficiency would then be so
compromised it would  probably outweigh any advantage from *true*
skip-sequential processing.

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