Re: IEC141I 013-A8: how to read VS data sets?

[Mike Shaw]

On 1/5/2017 7:28 PM, Jesse 1 Robinson wrote:

Pretty much I would say. Just want to point out that FBS and VBS are worlds 
apart. As discussed, the 'S' in VBS is 'spanned'. The 'S' in FBS means 
'standard' or some such. This guarantees that the file has no short blocks 
other than the very last one. A file written 'normally' is usually FBS whether 
labeled that way or not, but one written to multiple times via DISP=MOD is 
almost certain to have many short blocks, one for each time the file is closed 
and then reopened.

I doubt that modern processing really cares, but once upon a time FBS was more 
efficient than FB to read because I/O routines did not have to check for and 
handle a short block on every read.



I used VBS data sets in an Assembler application that processed health 
care claims under OS/MVS 21.8 back in 1978. 'S' meant spanned then and 
it means spanned now.


No magic is required to read and/or write VBS or VS records, just 
knowledge of what the possible values for the RDWs are.


Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

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

Re: IEC141I 013-A8: how to read VS data sets?

[J R]

I think the "wrinkle" is that a file mark need not be written if there is no 
room for it at end-of-extent.  ie. no point getting a new extent just for the 
file mark;  end-of-(last)extent is a valid EOF. 

Too bad "DASD Bill" (Fairchild) hasn't chimed in.  I'm sure he would cite the 
gospel on this.  I presume he may well be retired by now.  

Sent from my iPhone

> On Jan 6, 2017, at 11:08, Bill Woodger  wrote:
> 
> I, weakly, remember there was some apparent "wrinkle" with "end of data"

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

Re: IEC141I 013-A8: how to read VS data sets?

[Bill Woodger]

As part of my experimentation, the one record I wrote was for sure as small as 
80 bytes. That would seem to have been quite "favourable", and no, the 
remainder of the track was untouched by the data which was MODded to it.

I, weakly, remember there was some apparent "wrinkle" with "end of data" but 
assumed it was a "normal" thing, rather than anything specific to what I was 
doing. From memory, of four years ago, with no need of the detail since, when 
the track was full (could not contain another logical record) there was no "end 
of file" (file mark). Something like that. I could be wrong, having made the 
assumption (which seemed to be borne out by the experimentation), I didn't 
research it.

On Fri, 6 Jan 2017 15:41:53 +, J R  wrote:

>Sent from my iPhone
>
>> On Jan 6, 2017, at 10:27, Bill Woodger  wrote:
>> 
>> 1) short or coincidentally-full  block, unfilled track; 
>
>So, in the case of a favorable TRKBAL, the access method doesn't back up over 
>the file mark and write the first new block in its stead?  
>
>It would have to remove the file mark in either eventuality.  
>--
>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: IEC141I 013-A8: how to read VS data sets?

[Jesse 1 Robinson]

Thanks for the IPCS observation. I had never noticed that dynamic dump 
allocation creates FBS data sets. It makes a lot of sense. 

.
.
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 Tom Marchant
Sent: Friday, January 06, 2017 5:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IEC141I 013-A8: how to read VS data sets?

On Fri, 6 Jan 2017 01:20:19 -0600, Bill Woodger wrote:

>The S in FS is the same "standard" as the S in FBS.
>
>FS guarantees (by the person who coded it) that there is no partial 
>track within the file/data set, so that a record can be read directly 
>through the calculation of its position.

Correct. I usually think of it FBS as meaning only that there are no short 
blocks, but there are other requirements, including:
* Every track except the last contains the same number of blocks.  
* Every track except the last is filled as determined by the track
  capacity formula established for the device.

>As far as I know, it is simply that guarantee that is the difference, 
>so it can be acted upon. S meaning "this data set has not been MODded

Are you sure? I'm not sure, but I thought that MOD would start by filling up 
the last track.

BTW, IPCS requires FBS for dump data sets.

--
Tom Marchant


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

Re: IEC141I 013-A8: how to read VS data sets?

[J R]

Sent from my iPhone

> On Jan 6, 2017, at 10:27, Bill Woodger  wrote:
> 
> 1) short or coincidentally-full  block, unfilled track; 

So, in the case of a favorable TRKBAL, the access method doesn't back up over 
the file mark and write the first new block in its stead?  

It would have to remove the file mark in either eventuality.  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEC141I 013-A8: how to read VS data sets?

[Bill Woodger]

When DISP=MOD is used and there is existing data on the data set I think there 
are three possibilities (in likelihood order) with the existing data: 1) short 
or coincidentally-full  block, unfilled track; 2) short block, 
otherwise-coincidentally-filled track; 3) full block, filled track (double 
coincidence).

For 1), the first block written for "MODding" will be the first block on the 
"next" track, with the remainder of the final track of the previous content of 
the data set being "empty", screwing up a "seek" (there will obviously be a 
short block in one case, and a full one in the other).

For 2), the first block written for "MODding" will be the first block on the 
"next" track, and the previous block will be short, screwing up a "seek".

For 3), by the double coincidence, everything will be fine, and there will be 
no evidence from the content of the data set itself that it was ever MODded. 
"seek" works perfectly. May not, or may, on the next run.

It is unproblematic for "seek" if the final block is short, or the final track 
is short, or both. But, entirely problematic - at least potentially - for 
subsequent data (that which has been MODded) if there is any "gap" of any type 
(short block, short track), if there are embedded short blocks or unfilled 
tracks.

Whether the "seek" would work sometimes, fail all the time, or the programmer 
noted something but did not diagnose but coded-around, and probably other 
scenarios, will be down to the actual data and program.

For ordinary sequential reads, nothing with DISP=MOD is problematic (assuming 
that RECFM/LRECL are consistent with how later used).



On Fri, 6 Jan 2017 14:55:22 +, J R  wrote:

>Sent from my iPhone
>
>> On Jan 6, 2017, at 09:37, Bill Woodger  wrote:
>> 
>> "with the exception of the last block or track." 
>
>Are we not talking about the "last (used) track" in the case of MOD?  
>
>--
>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: IEC141I 013-A8: how to read VS data sets?

[J R]

Sent from my iPhone

> On Jan 6, 2017, at 09:37, Bill Woodger  wrote:
> 
> "with the exception of the last block or track." 

Are we not talking about the "last (used) track" in the case of MOD?  

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

Re: IEC141I 013-A8: how to read VS data sets?

[Bill Woodger]

All the documentation I read suggested that a latest incomplete track, when 
present, is not written to with DISP=MOD. My experiments bore this out.

It is possible that I misread everything and borked all the experiments. I can 
perhaps re-check at some point if this (MOD backfills empty space on a 
partially used track) is the predominant feeling.

Here is the JCL Reference:

"S
(1) For fixed-length records, indicates that the records are written as 
standard blocks, that is, no truncated blocks or unfilled tracks within the 
data set, with the exception of the last block or track."

If tracks were backfilled, that "or unfilled tracks" would be redundant.

No, I've nothing to back that up.

Whilst it may seem profligate with space, probably more determinant on why 
would be "how fast does it take to slap this data onto DASD, given that in 
99.% (or more) of slaps, the particular slap is not the first slap to a 
DISP=MOD with prior data.

On Fri, 6 Jan 2017 14:12:16 +, J R  wrote:

>MOD, I believe, does start by filling the last track;  but it would be sheer 
>luck if the erstwhile last block were a standard block.  Consequently, the 
>odds are stacked against the dataset remaining properly standard.  
>
>In any event, DISP=MOD with RECFM=FBS leaves the dataset labelled as RECFM=FB 
>to obviate behavior unexpected by subsequent users.  
>
>Sent from my iPhone
>
>> On Jan 6, 2017, at 08:13, Tom Marchant 
>> <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> Are you sure? I'm not sure, but I thought that MOD would start by 
>> filling up the last track.
>
>--
>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: IEC141I 013-A8: how to read VS data sets?

[J R]

MOD, I believe, does start by filling the last track;  but it would be sheer 
luck if the erstwhile last block were a standard block.  Consequently, the odds 
are stacked against the dataset remaining properly standard.  

In any event, DISP=MOD with RECFM=FBS leaves the dataset labelled as RECFM=FB 
to obviate behavior unexpected by subsequent users.  

Sent from my iPhone

> On Jan 6, 2017, at 08:13, Tom Marchant 
> <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Are you sure? I'm not sure, but I thought that MOD would start by 
> filling up the last track.

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

Re: IEC141I 013-A8: how to read VS data sets?

[Bill Woodger]

On Fri, 6 Jan 2017 07:12:52 -0600, Tom Marchant  
wrote:

[...]
>
>>As far as I know, it is simply that guarantee that is the difference, 
>>so it can be acted upon. S meaning "this data set has not been 
>>MODded
>
>Are you sure? I'm not sure, but I thought that MOD would start by 
>filling up the last track.
>

Unless it has changed with V2, I am sure, through reading the documentation and 
subsequent experimentation.

For instance, one experiment was OPEN, WRITE one record, CLOSE for DISP=NEW 
with TRK,1.

Run again with DISP=MOD. BANG!

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

Re: IEC141I 013-A8: how to read VS data sets?

[Tom Marchant]

On Thu, 5 Jan 2017 15:34:12 -0700, Paul Gilmartin wrote:

>VBS should have been the only RECFM anyone ever needed,
>thus the only one ever defined and supported.

Are you forgetting that in MVS, and in OS/360 before it, a program 
doesn't have to care what kind of device it is working with?

Certainly a program designed to read cards would not use VBS. 
Neither would a program that punches cards or writes to a printer.

The performance advantages of FBS for random access cannot 
be achieved with VBS.

These are just a few reasons why VBS isn't the only RECFM anyone 
would ever need.

-- 
Tom Marchant

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

Re: IEC141I 013-A8: how to read VS data sets?

[Tom Marchant]

On Fri, 6 Jan 2017 01:20:19 -0600, Bill Woodger wrote:

>The S in FS is the same "standard" as the S in FBS.
>
>FS guarantees (by the person who coded it) that there is no 
>partial track within the file/data set, so that a record can be 
>read directly through the calculation of its position.

Correct. I usually think of it FBS as meaning only that there are 
no short blocks, but there are other requirements, including:
* Every track except the last contains the same number of blocks.  
* Every track except the last is filled as determined by the track 
  capacity formula established for the device.

>As far as I know, it is simply that guarantee that is the difference, 
>so it can be acted upon. S meaning "this data set has not been 
>MODded

Are you sure? I'm not sure, but I thought that MOD would start by 
filling up the last track.

BTW, IPCS requires FBS for dump data sets.

-- 
Tom Marchant

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

Re: IEC141I 013-A8: how to read VS data sets?

[Robin Atwood]

Elardus-
The macro used is very similar to the one you have posted below. I have finally 
worked out how the code that
"works" avoids the abend: it opens the data set as RECFM=F and reads the max 
LRECL. Needless to say, the output 
received is not useful. I am changing the code to check for RECFM=VS and send 
an "unsupported format" error 
message.

Thanks to all who contributed to this thread.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: 06 January 2017 16:38
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEC141I 013-A8: how to read VS data sets?

Robin Atwood wrote:

>But my curiosity was piqued when I found that another of our products *could* 
>read the data set; I just cannot work out how!

If you can find out, could you post your macro used for that VS dataset? I'm 
just curious if you don't mind, please.

Something like this example I'm using for reading VBS (not VS) datasets (SMF in 
this case):

INVOERDCB   DSORG=PS,MACRF=(GM),DDNAME=INVOER,EODAD=EINDE

(I admit that above macro is not perfect or optimal or ideal, but it is 
*working* and fast+furious for both tape/disk)

Robin (and others too!), thanks for your posts in this thread. It was very 
educational to me.

Thanks again! 

Groete / Greetings
Elardus Engelbrecht

--
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: IEC141I 013-A8: how to read VS data sets?

[Elardus Engelbrecht]

Robin Atwood wrote:

>But my curiosity was piqued when I found that another of our products *could* 
>read the data set; I just cannot work out how!

If you can find out, could you post your macro used for that VS dataset? I'm 
just curious if you don't mind, please.

Something like this example I'm using for reading VBS (not VS) datasets (SMF in 
this case):

INVOERDCB   DSORG=PS,MACRF=(GM),DDNAME=INVOER,EODAD=EINDE

(I admit that above macro is not perfect or optimal or ideal, but it is 
*working* and fast+furious for both tape/disk)

Robin (and others too!), thanks for your posts in this thread. It was very 
educational to me.

Thanks again! 

Groete / Greetings
Elardus Engelbrecht

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

Re: IEC141I 013-A8: how to read VS data sets?

[Robin Atwood]

This is a vendor product and I am the developer. I got a bug report from some 
customer who tried to download  a
VS data set from the spool and the server got the abend. I have reproduced this 
by using IEBCOPY to unload a PDS 
and pointing SYSUT2 at SYSOUT. If I use the SDSF JOB DATA SET display and 
scroll to the right, I can see the data set is RECFM=VS, LRECL=23212. Since the 
message manual quite clearly states you cannot read a VS data set from SYSOUT 
using QSAM, I should close the bug as a permanent restriction. But my curiosity 
was piqued when I found that another of our products *could* read the data set; 
I just cannot work out how!

Thanks
Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: 06 January 2017 01:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEC141I 013-A8: how to read VS data sets?

Like Walt, I'm skeptical of the assertion that a spool data set is VS, where 
'S' means 'spanned'. Spanned records are extremely rare in MVS. The only use 
for them I've ever come across is MANx SMF, which I believe predates dirt. Most 
standard utilities fail when opened to V(B)S records. Only IFASMFDP can read 
SMF data, and the output from that is ordinary VB. 

SAPI should be able to handle any spool data set. OTOH I've never coded 
anything for SAPI; we use VPS (Levi, Ray, Shoup) to extract spool data and ship 
it to network printers. Likewise, SDSF or equivalent ISV product can handle 
spool data sets whether created as V or F. SDSF now has a Rexx interface that 
makes it very usable for processing spool files. 

FWIW it was once possible to utilize JES2 interfaces to read spool data sets 
directly. That ability evaporated a long, long time ago. 

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

Re: IEC141I 013-A8: how to read VS data sets?

[Bill Woodger]

The S in FS is the same "standard" as the S in FBS.

With an F which has been MODded there will, mostly, be an unfilled track (last 
record on from the previous output, empty remainder of track unless the record 
happens to be the last one which would fit on a track).

FS guarantees (by the person who coded it) that there is no partial track 
within the file/data set, so that a record can be read directly through the 
calculation of its position. As far as I know, it is simply that guarantee that 
is the difference, so it can be acted upon. S meaning "this data set has not 
been MODded, and if it has, it is my fault that something goes to pot at times".

As far as I know, the S in FS and FBS are not mandatory when writing, and 
everything works when it is specified for the data set used as input.

Although the "S" is a "performance thing", it is only so for "seek-type" usage 
(I'm sure there is a "calculate my physical record's location" Assemble macro). 
It otherwise makes no difference.

I think SAS has some stipulations about FBS for its libraries, or some of them.

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

Re: (External):Re: IEC141I 013-A8: how to read VS data sets?

[Jesse 1 Robinson]

From the trivia-I-happen-to-know drawer. Classic CA-1 (at least used to) use an 
unblocked RECFM=F data base so that records could be managed in the same way. 
So tape volser 123456 would be the 123,456th record in the data base. Made for 
a gigantic data base, but processing was very quick without having to manage an 
elaborate direct access method. 

That empties the drawer.

.
.
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 Bill Woodger
Sent: Thursday, January 05, 2017 5:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IEC141I 013-A8: how to read VS data sets?

Yet in modern times the S for F has its uses. If a C/C++ program is going to 
use a "seek" for a file, if the file is F/FB, then the file will be read from 
the start to satisfy the seek (because there may be those embedded short 
blocks), but if the file is FS/FBS (guarantee, by the person who put the S in 
the RECFM, to not have embedded short blocks) then the seek is able to 
calculate the position of he block containing the sought record, and then only 
have to read within the block.

I'm sure all C/C++ programmers who want to use seek on z/OS know that, since it 
is documented. Yeah. Right. (at risk of starting war) people who want to code 
seek to save a bit of thinking are exactly the ones who read the manuals.

What this means is "if you are using seek in a C/C++ program to access 
fixed-length records, ensure RECFM=FS/FBS. If you haven't done that, do it, and 
compare the resource usage.


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

Re: IEC141I 013-A8: how to read VS data sets?

[Jesse 1 Robinson]

I don't think 'FS' is meaningful. Not wrong, just pointless. If unblocked, all 
blocks contain exactly one record. 

.
.
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 J R
Sent: Thursday, January 05, 2017 5:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IEC141I 013-A8: how to read VS data sets?

What does RECFM=FS mean?  
How does it differ from RECFM=F?  

Sent from my iPhone

> On Jan 5, 2017, at 20:12, Bill Woodger <bill.wood...@gmail.com> wrote:
> 
> Yet in modern times the S for F has its uses. If a C/C++ program is going to 
> use a "seek" for a file, if the file is F/FB, then the file will be read from 
> the start to satisfy the seek (because there may be those embedded short 
> blocks), but if the file is FS/FBS (guarantee, by the person who put the S in 
> the RECFM, to not have embedded short blocks) then the seek is able to 
> calculate the position of he block containing the sought record, and then 
> only have to read within the block.
> 
> I'm sure all C/C++ programmers who want to use seek on z/OS know that, since 
> it is documented. Yeah. Right. (at risk of starting war) people who want to 
> code seek to save a bit of thinking are exactly the ones who read the manuals.
> 
> What this means is "if you are using seek in a C/C++ program to access 
> fixed-length records, ensure RECFM=FS/FBS. If you haven't done that, do it, 
> and compare the resource usage.


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

Re: IEC141I 013-A8: how to read VS data sets?

[J R]

What does RECFM=FS mean?  
How does it differ from RECFM=F?  

Sent from my iPhone

> On Jan 5, 2017, at 20:12, Bill Woodger  wrote:
> 
> Yet in modern times the S for F has its uses. If a C/C++ program is going to 
> use a "seek" for a file, if the file is F/FB, then the file will be read from 
> the start to satisfy the seek (because there may be those embedded short 
> blocks), but if the file is FS/FBS (guarantee, by the person who put the S in 
> the RECFM, to not have embedded short blocks) then the seek is able to 
> calculate the position of he block containing the sought record, and then 
> only have to read within the block.
> 
> I'm sure all C/C++ programmers who want to use seek on z/OS know that, since 
> it is documented. Yeah. Right. (at risk of starting war) people who want to 
> code seek to save a bit of thinking are exactly the ones who read the manuals.
> 
> What this means is "if you are using seek in a C/C++ program to access 
> fixed-length records, ensure RECFM=FS/FBS. If you haven't done that, do it, 
> and compare the resource usage.
> 
> --
> 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: IEC141I 013-A8: how to read VS data sets?

[Bill Woodger]

Yet in modern times the S for F has its uses. If a C/C++ program is going to 
use a "seek" for a file, if the file is F/FB, then the file will be read from 
the start to satisfy the seek (because there may be those embedded short 
blocks), but if the file is FS/FBS (guarantee, by the person who put the S in 
the RECFM, to not have embedded short blocks) then the seek is able to 
calculate the position of he block containing the sought record, and then only 
have to read within the block.

I'm sure all C/C++ programmers who want to use seek on z/OS know that, since it 
is documented. Yeah. Right. (at risk of starting war) people who want to code 
seek to save a bit of thinking are exactly the ones who read the manuals.

What this means is "if you are using seek in a C/C++ program to access 
fixed-length records, ensure RECFM=FS/FBS. If you haven't done that, do it, and 
compare the resource usage.

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

Re: IEC141I 013-A8: how to read VS data sets?

[Jesse 1 Robinson]

Pretty much I would say. Just want to point out that FBS and VBS are worlds 
apart. As discussed, the 'S' in VBS is 'spanned'. The 'S' in FBS means 
'standard' or some such. This guarantees that the file has no short blocks 
other than the very last one. A file written 'normally' is usually FBS whether 
labeled that way or not, but one written to multiple times via DISP=MOD is 
almost certain to have many short blocks, one for each time the file is closed 
and then reopened. 

I doubt that modern processing really cares, but once upon a time FBS was more 
efficient than FB to read because I/O routines did not have to check for and 
handle a short block on every read. 

.
.
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 Bill Woodger
Sent: Thursday, January 05, 2017 4:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IEC141I 013-A8: how to read VS data sets?

Paul,

For QSAM, there's F/FS/FB/FBS, U, V/VB, VS/VBS that you may see used in a 
business system (and business systems, in the main, are the reasons for having 
a Mainframe).

All have their specific "it's better in this case to do this". Of these, VS/VBS 
is the slowest way to read or write records, and the least likely that you will 
see, and the least "known" to programmers, in business systems.

"Slowest" means, for large numbers of records (the usual stuff of Mainframe 
business systems) "more expensive" and "running longer". Neither of these are 
good.

I've seen you suggest that things would be better with VS/VBS only: can you 
outline how, please?

QSAM has limits. You seem to be unable to accept that. It has the limits it 
has, not the limits that you think it should have. It ain't gonna change.

If for your "more and more mysterious" your point is "why didn't it abend, 
rather than apparently work, although work other than I wanted", then raise it 
with IBM. I'm not sure it will get a high priority, because mostly people will 
be expected to respect the limits.

Since you are very much at home with HFS, why don't you use that, and just 
pretend that it is giving you VS/VBS? Won't that make you happy, and leave 
everyone else choosing the most effective RECFM for the specific task (or not, 
as it has been known to happen)? 


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

Re: IEC141I 013-A8: how to read VS data sets?

[Bill Woodger]

Paul,

For QSAM, there's F/FS/FB/FBS, U, V/VB, VS/VBS that you may see used in a 
business system (and business systems, in the main, are the reasons for having 
a Mainframe).

All have their specific "it's better in this case to do this". Of these, VS/VBS 
is the slowest way to read or write records, and the least likely that you will 
see, and the least "known" to programmers, in business systems.

"Slowest" means, for large numbers of records (the usual stuff of Mainframe 
business systems) "more expensive" and "running longer". Neither of these are 
good.

I've seen you suggest that things would be better with VS/VBS only: can you 
outline how, please?

QSAM has limits. You seem to be unable to accept that. It has the limits it 
has, not the limits that you think it should have. It ain't gonna change.

If for your "more and more mysterious" your point is "why didn't it abend, 
rather than apparently work, although work other than I wanted", then raise it 
with IBM. I'm not sure it will get a high priority, because mostly people will 
be expected to respect the limits.

Since you are very much at home with HFS, why don't you use that, and just 
pretend that it is giving you VS/VBS? Won't that make you happy, and leave 
everyone else choosing the most effective RECFM for the specific task (or not, 
as it has been known to happen)?

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

Re: IEC141I 013-A8: how to read VS data sets?

[Paul Gilmartin]

On 2017-01-05, at 14:47, Jesse 1 Robinson wrote:
> 
> If a JES2 output segment is created with 'VS' attributes, that does not mean 
> that the data on spool actually consists of spanned records. The point of 
> spanning is to manage records that can exceed physical block size, e.g. 
> 32760. SMF can potentially do that because so many records can have unlimited 
> segments. What does physical block size even mean to JES? 
> 
However, the venerable access methods rely on halfword descriptors
both in the data and in control blocks.  So if the spool is to be
compatible with those access methods it must support their RECFMs,
even including VBS.

It's a pity.  VBS should have been the only RECFM anyone ever needed,
thus the only one ever defined and supported.  Everything could have
been the same.

Mysteriouser and mysteriouser:  I allocated a couple data sets each
with JCL and BPXWDYN.  Then, with EXECIO I wrote one record to one
member of each pair.  Magically, LRECL shrank to 32756.  I may have
discussed this behavior long ago in one of these fora.  I don't
remember the explanation, if any.

 DSLIST - Data Sets Matching User.TEMP.V*Row 1 of 4 
 Command ===>  Scroll ===> CSR  
 Command - Enter "/" to select action Dsorg  Recfm  Lrecl  Blksz
 ---
  User.TEMP.VBSDYN   VBS32760  0
  User.TEMP.VBSDYNWPSVBS32756  27998
  User.TEMP.VBSJCL   VBS32761  0
  User.TEMP.VBSJCLWPSVBS32756  27998
 * End of Data Set list 

--gil

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

Re: IEC141I 013-A8: how to read VS data sets?

[Lizette Koehler]

 
  http://www.redbooks.ibm.com/abstracts/sg247419.html
   SDSF REXX Redbook

Providing REXX programs with an API to access IBM z/OS System Display and
Search Facility (SDSF) functions gives you a powerful tool for accessing and
controlling JES resources. Although we chose REXX as the language for our
installation, you might choose other languages, such as C, COBOL, or
assembler.

 
 Lizette
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Elardus Engelbrecht
> > Sent: Thursday, January 05, 2017 1:50 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IEC141I 013-A8: how to read VS data sets?
> >
> > Jesse 1 Robinson wrote:
> >
> > >Most standard utilities fail when opened to V(B)S records.
> >
> > Please name them. Just so I can shock my amazed users when they
> > complain about reading VBS things...
> >
> >
> > >Only IFASMFDP can read SMF data, and the output from that is ordinary VB.
> >
> > Really? What about DFSORT and its friend ICETOOL? (S about
> > RACF Report Writer, because that thing is 'functionally stabilized' some
> centuries ago...
> > )
> >
> > I posted a ICETOOL JCL example in IBM-MAIN which reads raw SMF data type 89.
> >
> > Also look at thread 'Re: DFSORT - ICETOOL - Search for text and
> > replace with date' in Sept 2016 where I wrote that ICETOOL can read in raw
> SMF data.
> >
> > You can write any program reading VBS data. I wrote in IBM-MAIN about
> > analysing SMF 30 using a home grown Assembler program.
> >
> > Oh, zSecure can do that trick too and do that *fast*.
> >
> >
> > >SAPI should be able to handle any spool data set.
> >
> > Yip! This is where SAPI is useful!
> >
> >
> > >OTOH I've never coded anything for SAPI; we use VPS (Levi, Ray,
> > >Shoup) to
> > extract spool data and ship it to network printers.
> >
> > That is if you give VPS ALTER access to the spool contents. I don't
> > like it, but ...
> >
> >
> > >Likewise, SDSF or equivalent ISV product can handle spool data sets
> > >whether
> > created as V or F.
> >
> > As long you re-assemble exits for third party products to read the
> > spool data using the latest JES2 macros. For SDSF or other IBM spool
> > reading products like SMTP or cs-smtp, everything is ready for reading JES2
> spool.
> >
> >
> > >SDSF now has a Rexx interface that makes it very usable for
> > >processing spool
> > files.
> >
> > Hmmm, something for me to RTFM, it may comes in handy for some
> > nefarious spool grabbing... ;-D
> >
> >
> > >FWIW it was once possible to utilize JES2 interfaces to read spool
> > >data sets
> > directly. That ability evaporated a long, long time ago.
> >
> > Oh, yes. TSPRINT (now OMCPRINT) could do that. These JES2 changes gave
> > some third party vendors real grey hairs while trying to comply to new
> > JES2 interfaces and macros. For that, I'm gratefully glad I'm not part of
> "them"...
> > ;-)
> >
> > Groete / Greetings
> > Elardus Engelbrecht

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

Re: IEC141I 013-A8: how to read VS data sets?

[Lizette Koehler]

 http://www.redbooks.ibm.com/abstracts/sg247419.html 
  SDSF REXX Redbook

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> Sent: Thursday, January 05, 2017 1:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IEC141I 013-A8: how to read VS data sets?
> 
> Jesse 1 Robinson wrote:
> 
> >Most standard utilities fail when opened to V(B)S records.
> 
> Please name them. Just so I can shock my amazed users when they complain about
> reading VBS things...
> 
> 
> >Only IFASMFDP can read SMF data, and the output from that is ordinary VB.
> 
> Really? What about DFSORT and its friend ICETOOL? (S about RACF Report
> Writer, because that thing is 'functionally stabilized' some centuries ago...
> )
> 
> I posted a ICETOOL JCL example in IBM-MAIN which reads raw SMF data type 89.
> 
> Also look at thread 'Re: DFSORT - ICETOOL - Search for text and replace with
> date' in Sept 2016 where I wrote that ICETOOL can read in raw SMF data.
> 
> You can write any program reading VBS data. I wrote in IBM-MAIN about
> analysing SMF 30 using a home grown Assembler program.
> 
> Oh, zSecure can do that trick too and do that *fast*.
> 
> 
> >SAPI should be able to handle any spool data set.
> 
> Yip! This is where SAPI is useful!
> 
> 
> >OTOH I've never coded anything for SAPI; we use VPS (Levi, Ray, Shoup) to
> extract spool data and ship it to network printers.
> 
> That is if you give VPS ALTER access to the spool contents. I don't like it,
> but ...
> 
> 
> >Likewise, SDSF or equivalent ISV product can handle spool data sets whether
> created as V or F.
> 
> As long you re-assemble exits for third party products to read the spool data
> using the latest JES2 macros. For SDSF or other IBM spool reading products
> like SMTP or cs-smtp, everything is ready for reading JES2 spool.
> 
> 
> >SDSF now has a Rexx interface that makes it very usable for processing spool
> files.
> 
> Hmmm, something for me to RTFM, it may comes in handy for some nefarious spool
> grabbing... ;-D
> 
> 
> >FWIW it was once possible to utilize JES2 interfaces to read spool data sets
> directly. That ability evaporated a long, long time ago.
> 
> Oh, yes. TSPRINT (now OMCPRINT) could do that. These JES2 changes gave some
> third party vendors real grey hairs while trying to comply to new JES2
> interfaces and macros. For that, I'm gratefully glad I'm not part of "them"...
> ;-)
> 
> Groete / Greetings
> Elardus Engelbrecht

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

Re: IEC141I 013-A8: how to read VS data sets?

[Jesse 1 Robinson]

OK, I overstated my case. Did not think about SORT. Certainly ISPF cannot 
handle VBS. 

I've long operated on the ROT that you can't do much with SMF data until 
'something' converts it to VB, so I have not actually tried standards like 
IEBGENER or IDCAMS in many a moon. I am curious though as to why 'amazed users' 
would be interested in VBS data at all. Gil says that FORTRAN can handle VBS. I 
have never stared down a FORTRAN program in my career; not a likely denizen in 
business environments.

If a JES2 output segment is created with 'VS' attributes, that does not mean 
that the data on spool actually consists of spanned records. The point of 
spanning is to manage records that can exceed physical block size, e.g. 32760. 
SMF can potentially do that because so many records can have unlimited 
segments. What does physical block size even mean to JES? 

IIRC the progenitor of modern SDSF--the Interactive Spool Facility (ISF: get 
it?)--read data directly from spool using the available JES2 interface(s) that 
eventually disappeared. So did early versions of the venerable QUEUE command. 
Now SAPI is a fully defined, fully supported API. The SDSF/Rexx interface can 
be used to write output directly to a data set just as interactive XDC does. No 
additional programming required. 

.
.
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 Elardus Engelbrecht
Sent: Thursday, January 05, 2017 12:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IEC141I 013-A8: how to read VS data sets?

Jesse 1 Robinson wrote:

>Most standard utilities fail when opened to V(B)S records.

Please name them. Just so I can shock my amazed users when they complain about 
reading VBS things...


>Only IFASMFDP can read SMF data, and the output from that is ordinary VB.  

Really? What about DFSORT and its friend ICETOOL? (S about RACF Report 
Writer, because that thing is 'functionally stabilized' some centuries ago... )

I posted a ICETOOL JCL example in IBM-MAIN which reads raw SMF data type 89.

Also look at thread 'Re: DFSORT - ICETOOL - Search for text and replace with 
date' in Sept 2016 where I wrote that ICETOOL can read in raw SMF data.

You can write any program reading VBS data. I wrote in IBM-MAIN about analysing 
SMF 30 using a home grown Assembler program.

Oh, zSecure can do that trick too and do that *fast*.


>SAPI should be able to handle any spool data set. 

Yip! This is where SAPI is useful!


>OTOH I've never coded anything for SAPI; we use VPS (Levi, Ray, Shoup) to 
>extract spool data and ship it to network printers.

That is if you give VPS ALTER access to the spool contents. I don't like it, 
but ...


>Likewise, SDSF or equivalent ISV product can handle spool data sets whether 
>created as V or F. 

As long you re-assemble exits for third party products to read the spool data 
using the latest JES2 macros. For SDSF or other IBM spool reading products like 
SMTP or cs-smtp, everything is ready for reading JES2 spool.


>SDSF now has a Rexx interface that makes it very usable for processing spool 
>files.  

Hmmm, something for me to RTFM, it may comes in handy for some nefarious spool 
grabbing... ;-D

 
>FWIW it was once possible to utilize JES2 interfaces to read spool data sets 
>directly. That ability evaporated a long, long time ago.  

Oh, yes. TSPRINT (now OMCPRINT) could do that. These JES2 changes gave some 
third party vendors real grey hairs while trying to comply to new JES2 
interfaces and macros. For that, I'm gratefully glad I'm not part of "them"... 
;-)

Groete / Greetings
Elardus Engelbrecht


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

Re: IEC141I 013-A8: how to read VS data sets?

[Elardus Engelbrecht]

Jesse 1 Robinson wrote:

>Most standard utilities fail when opened to V(B)S records.

Please name them. Just so I can shock my amazed users when they complain about 
reading VBS things...


>Only IFASMFDP can read SMF data, and the output from that is ordinary VB.  

Really? What about DFSORT and its friend ICETOOL? (S about RACF Report 
Writer, because that thing is 'functionally stabilized' some centuries ago... )

I posted a ICETOOL JCL example in IBM-MAIN which reads raw SMF data type 89.

Also look at thread 'Re: DFSORT - ICETOOL - Search for text and replace with 
date' in Sept 2016 where I wrote that ICETOOL can read in raw SMF data.

You can write any program reading VBS data. I wrote in IBM-MAIN about analysing 
SMF 30 using a home grown Assembler program.

Oh, zSecure can do that trick too and do that *fast*.


>SAPI should be able to handle any spool data set. 

Yip! This is where SAPI is useful!


>OTOH I've never coded anything for SAPI; we use VPS (Levi, Ray, Shoup) to 
>extract spool data and ship it to network printers.

That is if you give VPS ALTER access to the spool contents. I don't like it, 
but ...


>Likewise, SDSF or equivalent ISV product can handle spool data sets whether 
>created as V or F. 

As long you re-assemble exits for third party products to read the spool data 
using the latest JES2 macros. For SDSF or other IBM spool reading products like 
SMTP or cs-smtp, everything is ready for reading JES2 spool.


>SDSF now has a Rexx interface that makes it very usable for processing spool 
>files.  

Hmmm, something for me to RTFM, it may comes in handy for some nefarious spool 
grabbing... ;-D

 
>FWIW it was once possible to utilize JES2 interfaces to read spool data sets 
>directly. That ability evaporated a long, long time ago.  

Oh, yes. TSPRINT (now OMCPRINT) could do that. These JES2 changes gave some 
third party vendors real grey hairs while trying to comply to new JES2 
interfaces and macros. For that, I'm gratefully glad I'm not part of "them"... 
;-)

Groete / Greetings
Elardus Engelbrecht
 

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

Re: IEC141I 013-A8: how to read VS data sets?

[Paul Gilmartin]

On Thu, 5 Jan 2017 13:50:25 -0500, Carmen Vitullo wrote:

>for my own sake I checked some sysout of my own and if you scroll over to the 
>right in the jes2 dataset view from ? you see jes2 dataset attributes, I see 
>RECFM V and U and VA and UA, no VS for any jes2 datasets 
> 
Ah, but did you allocate one?  When I do that BPXWDYN(), I see:

 SDSF JOB DATA SET DISPLAY - JOB LONGOUT5 (JOB05373)
 COMMAND INPUT ===>
 NP   DDNAME   StepName RecFM LRecL
  JESMSGLG JES2 UA  133
  JESJCL   JES2 V   132
  JESYSMSG JES2 VA  133
  SYSTSPRT SETUPVBA 133
  TESTO1   SETUPVBS   32748 

Experimenting further, JCL seems to impose a limit of LRECL=32761;
ISPF and BPXWDYN a limit of LRECL=32760.  I see no rationale for either of
those numbers -- the only one that would make sense is 32767, the max
signed halfword value.  Allocating with ISPF assigns halftrack BLKSIZE;
no information for JCL because I never wrote to it.

And when BPXWDYN successfully allocates with LRECL=32750, ISPF
Data Set Utility reports LRECL=32756.

>- Original Message -
>From: "Jesse 1 Robinson"
>Sent: Thursday, January 5, 2017 12:40:16 PM 
>Subject: Re: IEC141I 013-A8: how to read VS data sets? 
>
>Like Walt, I'm skeptical of the assertion that a spool data set is VS, where 
>'S' means 'spanned'. Spanned records are extremely rare in MVS. The only use 
>for them I've ever come across is MANx SMF, which I believe predates dirt. 
>Most standard utilities fail when opened to V(B)S records. Only IFASMFDP can 
>read SMF data, and the output from that is ordinary VB. 
>
I've been told that VBS was invented to support FORTRAN, so that FORTRAN
programs could move from tape to DASD.

And, for whatever reason, Rexx EXECIO has very lately been granted capability
for RECFM=VBS (and for RECFM=U).

--gil

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

Re: IEC141I 013-A8: how to read VS data sets?

[Carmen Vitullo]

for my own sake I checked some sysout of my own and if you scroll over to the 
right in the jes2 dataset view from ? you see jes2 dataset attributes, I see 
RECFM V and U and VA and UA, no VS for any jes2 datasets 
Carmen 

- Original Message -

From: "Jesse 1 Robinson" <jesse1.robin...@sce.com> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, January 5, 2017 12:40:16 PM 
Subject: Re: IEC141I 013-A8: how to read VS data sets? 

Like Walt, I'm skeptical of the assertion that a spool data set is VS, where 
'S' means 'spanned'. Spanned records are extremely rare in MVS. The only use 
for them I've ever come across is MANx SMF, which I believe predates dirt. Most 
standard utilities fail when opened to V(B)S records. Only IFASMFDP can read 
SMF data, and the output from that is ordinary VB. 

SAPI should be able to handle any spool data set. OTOH I've never coded 
anything for SAPI; we use VPS (Levi, Ray, Shoup) to extract spool data and ship 
it to network printers. Likewise, SDSF or equivalent ISV product can handle 
spool data sets whether created as V or F. SDSF now has a Rexx interface that 
makes it very usable for processing spool files. 

FWIW it was once possible to utilize JES2 interfaces to read spool data sets 
directly. That ability evaporated a long, long time ago. 

. 
. 
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 Walt Farrell 
Sent: Thursday, January 05, 2017 8:54 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: (External):Re: IEC141I 013-A8: how to read VS data sets? 

On Thu, 5 Jan 2017 21:13:48 +0700, Robin Atwood <abend...@gmail.com> wrote: 

>The JCL is not relevant, both applications are servers that use dynamic 
>allocation. They are using SAPI to read the JES spool. The >message is 
> 
>IEC141I 013-A8,IGG0199G,TAURISP3,TAURISP3,SYS2 
> 
>The spool data set is allocated to SYS2. I am really interested in advice 
>about reading VS data sets, what access method to use, >etc. 

What makes you think the data on spool is VS in format? That seems to me to be 
an unusual record format for someone to use writing spool data. Perhaps the 
error is that the program issuing the OPEN to try to read it is saying RECFM=VS 
when it's really just V? 

(Note, too, that there are two other potential program errors: specifying 
RECFM=D, or specifying both ANSI and Machine control characters. But all of 
these really seem to indicate an error in the program, and I'd say that the 
program author needs to examine the dump and figure it out.) 

-- 
Walt 


-- 
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: IEC141I 013-A8: how to read VS data sets?

[Jesse 1 Robinson]

Like Walt, I'm skeptical of the assertion that a spool data set is VS, where 
'S' means 'spanned'. Spanned records are extremely rare in MVS. The only use 
for them I've ever come across is MANx SMF, which I believe predates dirt. Most 
standard utilities fail when opened to V(B)S records. Only IFASMFDP can read 
SMF data, and the output from that is ordinary VB. 

SAPI should be able to handle any spool data set. OTOH I've never coded 
anything for SAPI; we use VPS (Levi, Ray, Shoup) to extract spool data and ship 
it to network printers. Likewise, SDSF or equivalent ISV product can handle 
spool data sets whether created as V or F. SDSF now has a Rexx interface that 
makes it very usable for processing spool files. 

FWIW it was once possible to utilize JES2 interfaces to read spool data sets 
directly. That ability evaporated a long, long time ago. 

.
.
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 Walt Farrell
Sent: Thursday, January 05, 2017 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IEC141I 013-A8: how to read VS data sets?

On Thu, 5 Jan 2017 21:13:48 +0700, Robin Atwood <abend...@gmail.com> wrote:

>The JCL is not relevant, both applications are servers that use dynamic 
>allocation. They are using SAPI to read the JES spool. The >message is
>
>IEC141I 013-A8,IGG0199G,TAURISP3,TAURISP3,SYS2
>
>The spool data set is allocated to SYS2. I am really interested in advice 
>about reading VS data sets, what access method to use, >etc.

What makes you think the data on spool is VS in format? That seems to me to be 
an unusual record format for someone to use writing spool data. Perhaps the 
error is that the program issuing the OPEN to try to read it is saying RECFM=VS 
when it's really just V?

(Note, too, that there are two other potential program errors: specifying 
RECFM=D, or specifying both ANSI and Machine control characters. But all of 
these really seem to indicate an error in the program, and I'd say that the 
program author needs to examine the dump and figure it out.)

--
Walt


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

Re: IEC141I 013-A8: how to read VS data sets?

[Walt Farrell]

On Thu, 5 Jan 2017 21:13:48 +0700, Robin Atwood  wrote:

>The JCL is not relevant, both applications are servers that use dynamic 
>allocation. They are using SAPI to read the JES spool. The >message is
>
>IEC141I 013-A8,IGG0199G,TAURISP3,TAURISP3,SYS2
>
>The spool data set is allocated to SYS2. I am really interested in advice 
>about reading VS data sets, what access method to use, >etc.

What makes you think the data on spool is VS in format? That seems to me to be 
an unusual record format for someone to use writing spool data. Perhaps the 
error is that the program issuing the OPEN to try to read it is saying RECFM=VS 
when it's really just V?

(Note, too, that there are two other potential program errors: specifying 
RECFM=D, or specifying both ANSI and Machine control characters. But all of 
these really seem to indicate an error in the program, and I'd say that the 
program author needs to examine the dump and figure it out.)

-- 
Walt

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

Re: IEC141I 013-A8: how to read VS data sets?

[Lizette Koehler]

Is this homegrown or vendor product like Mobius, VPS or other like product?

There is no obvious reason, short of reading a dump, to know what one job works 
and one job does not.

If vendor product, then I would contact the vendor.

Otherwise I would contact IBM - probably JES2

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Robin Atwood
> Sent: Thursday, January 05, 2017 7:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IEC141I 013-A8: how to read VS data sets?
> 
> The JCL is not relevant, both applications are servers that use dynamic
> allocation. They are using SAPI to read the JES spool. The message is
> 
> IEC141I 013-A8,IGG0199G,TAURISP3,TAURISP3,SYS2
> 
> The spool data set is allocated to SYS2. I am really interested in advice
> about reading VS data sets, what access method to use, etc.
> 
> Thanks
> Robin
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: 05 January 2017 19:47
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IEC141I 013-A8: how to read VS data sets?
> 
> Robin,
> Please delete any part of the email you did a REPLY to that does not pertain
> to your question.  It tends to confuse the issue.
> 
> Next, I am not clear on Reading a VS on JES2 Spool.  JES2 Spool has its own
> unique process for creating SYSOUT.  So if you could explain further that
> could help.
> 
> If you are asking about a job that abended when trying to Read a VS dataset
> and got an S013-A8, then that is a different question.
> 
> When I look up your abend code
> 
> An incorrect record format was requested for a SYSIN, SYSOUT, or subsystem
> data set with BSAM or QSAM or for a z/OS UNIX directory with BPAM. One of the
> following conditions was detected:
> 
> RECFM=D was specified.
> Variable spanned records (VS or VBS) were requested for input.
> Both ANSI and machine control characters were specified.
> 
> Please show the  JCL from the job that runs good and the job that fails.  You
> can change the dataset name and I think we only need the JCL to see the way it
> is coded.
> 
> Again, you would read SYSOUT On JES2 not a VS dataset on JES2.  Unless your
> application is trying to run a JES2 SSI function to read SYSOUT.
> 
> Please provide further details.
> 
> And if you could post the complete IEC141 I message, that would also be
> helpful.  Again just change the dataset name.
> 
> Lizette
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Robin Atwood
> > Sent: Thursday, January 05, 2017 5:31 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: IEC141I 013-A8: how to read VS data sets?
> >
> > One of our apps abends if trying to read a VS data set on the JES2
> > spool. The message manual tells me this is because it is not allowed
> > to read VS SYSOUT using QSAM. Yet we have another application which does
> exactly that.
> > Furthermore, after one day of staring at the code I cannot see any
> > functional difference between the two routines:
> > both use identical DCB/DCBEs. SDSF can read the data set of course,
> > but I expect it has some internal interface. So I searched on what is
> > the correct way to read VS data sets and found virtually nothing.
> > Anybody got any experience of this?
> >
> > Thanks
> > Robin

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

Re: IEC141I 013-A8: how to read VS data sets?

[Robin Atwood]

The JCL is not relevant, both applications are servers that use dynamic 
allocation. They are using SAPI to read the JES spool. The message is

IEC141I 013-A8,IGG0199G,TAURISP3,TAURISP3,SYS2

The spool data set is allocated to SYS2. I am really interested in advice 
about reading VS data sets, what access method to use, etc.

Thanks
Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: 05 January 2017 19:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEC141I 013-A8: how to read VS data sets?

Robin,
Please delete any part of the email you did a REPLY to that does not pertain to 
your question.  It tends to confuse the issue.

Next, I am not clear on Reading a VS on JES2 Spool.  JES2 Spool has its own 
unique process for creating SYSOUT.  So if you could explain further that could 
help.

If you are asking about a job that abended when trying to Read a VS dataset and 
got an S013-A8, then that is a different question.

When I look up your abend code

An incorrect record format was requested for a SYSIN, SYSOUT, or subsystem data 
set with BSAM or QSAM or for a z/OS UNIX directory with BPAM. One of the 
following conditions was detected:

RECFM=D was specified.
Variable spanned records (VS or VBS) were requested for input.
Both ANSI and machine control characters were specified.

Please show the  JCL from the job that runs good and the job that fails.  You 
can change the dataset name and I think we only need the JCL to see the way it 
is coded.

Again, you would read SYSOUT On JES2 not a VS dataset on JES2.  Unless your 
application is trying to run a JES2 SSI function to read SYSOUT.  

Please provide further details.

And if you could post the complete IEC141 I message, that would also be 
helpful.  Again just change the dataset name.

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Robin Atwood
> Sent: Thursday, January 05, 2017 5:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IEC141I 013-A8: how to read VS data sets?
> 
> One of our apps abends if trying to read a VS data set on the JES2 
> spool. The message manual tells me this is because it is not allowed 
> to read VS SYSOUT using QSAM. Yet we have another application which does 
> exactly that.
> Furthermore, after one day of staring at the code I cannot see any 
> functional difference between the two routines:
> both use identical DCB/DCBEs. SDSF can read the data set of course, 
> but I expect it has some internal interface. So I searched on what is 
> the correct way to read VS data sets and found virtually nothing. 
> Anybody got any experience of this?
> 
> Thanks
> Robin
> 

--
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: IEC141I 013-A8: how to read VS data sets?

[Lizette Koehler]

Robin,
Please delete any part of the email you did a REPLY to that does not pertain to 
your question.  It tends to confuse the issue.

Next, I am not clear on Reading a VS on JES2 Spool.  JES2 Spool has its own 
unique process for creating SYSOUT.  So if you could explain further that could 
help.

If you are asking about a job that abended when trying to Read a VS dataset and 
got an S013-A8, then that is a different question.

When I look up your abend code

An incorrect record format was requested for a SYSIN, SYSOUT, or subsystem data 
set with BSAM or QSAM or for a z/OS UNIX directory with BPAM. One of the 
following conditions was detected:

RECFM=D was specified.
Variable spanned records (VS or VBS) were requested for input.
Both ANSI and machine control characters were specified.

Please show the  JCL from the job that runs good and the job that fails.  You 
can change the dataset name and I think we only need the JCL to see the way it 
is coded.

Again, you would read SYSOUT On JES2 not a VS dataset on JES2.  Unless your 
application is trying to run a JES2 SSI function to read SYSOUT.  

Please provide further details.

And if you could post the complete IEC141 I message, that would also be 
helpful.  Again just change the dataset name.

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Robin Atwood
> Sent: Thursday, January 05, 2017 5:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IEC141I 013-A8: how to read VS data sets?
> 
> One of our apps abends if trying to read a VS data set on the JES2 spool. The
> message manual tells me this is because it is not allowed to read VS SYSOUT
> using QSAM. Yet we have another application which does exactly that.
> Furthermore, after one day of staring at the code I cannot see any functional
> difference between the two routines:
> both use identical DCB/DCBEs. SDSF can read the data set of course, but I
> expect it has some internal interface. So I searched on what is the correct
> way to read VS data sets and found virtually nothing. Anybody got any
> experience of this?
> 
> Thanks
> Robin
> 

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

IEC141I 013-A8: how to read VS data sets?

[Robin Atwood]

One of our apps abends if trying to read a VS data set on the JES2 spool. The 
message manual tells me this is 
because it is not allowed to read VS SYSOUT using QSAM. Yet we have another 
application which does exactly that.
Furthermore, after one day of staring at the code I cannot see any functional 
difference between the two routines: 
both use identical DCB/DCBEs. SDSF can read the data set of course, but I 
expect it has some internal interface. So I 
searched on what is the correct way to read VS data sets and found virtually 
nothing. Anybody got any experience 
of this?

Thanks
Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: 05 January 2017 17:59
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Delete NVR entries where ENQ shows from LLA/XCFAS

Lucas Rosalen wrote:

>You could do the right way, which means removing these datasets from LLA and 
>LNKLST.

Agreed! 

>Or you could recklessly use BYPASSNQ program, which can be found in CBT 
>file #749

Hehehe, 'recklessly'? That AC(1) program is a frontend to screen SVCs and then 
misuse "SYSNOENQ" before calling deletion programs like IEHPROGM or IDCAMS.

My storage admins will not like that program at all. So, I can't try that out 
to see if a certain special RACF profile will block this program or not.

Groete / Greetings
Elardus Engelbrecht

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