IBM Mainframe Forum

We are currently using fileaid to copy an entire pds to a sequential file for processing in another step. All the sequential file will have after the fileaid is the text contained in the all the pds members.
Fileaid will no longer be available to us later this year so we are converting all fileaid to something else.
99.9% of the jobs are done but i have one that i'm stumped on:
Pds i/p is PO , FB , lrecl=485, blk=27645

I've tried IEBGENER & IEBCOPY & IEBPTPCH, nothing works.
gener gives me the following which doesn't make sense, maybe because the dd points to pds without a member name:
DATA SET UTILITY - GENERATE
IEB351I I/O ERROR ,XX15168S,IEBGENER,3A06,D,SYSUT1 ,READ ,WRNG.LEN.RECORD,00001D7C000E00,BSAM
IEBPTPCH doesn't like the fact that the o/p is not 80 or 132.
IEBCOPY unloads the dataset but puts it as recfm=VS which is not usable to the app.

There has to be a way to do this & it's making me nUtZ.
Thanks,
John

Hello and welcome to the forum,

How many members are in the pds?

dick scherrer wrote:Hello and welcome to the forum,

How many members are in the pds?

Thanks.
There are currently 80 members but it's variable day to day & the PDS member names can also change from day to day.

John

For IEBGENER you will have to specify the members via SYSIN. If the list of members varies then you will need something to get the list of current members and generate your SYSIN for you.
IEBPTPCH has various ways of presenting the output but if none of these are to taste then the output can be processed by a Rexx program or DFSORT to extract the 80 bytes in question.

Hello,

What should be the lrecl of the combined output?

As the number of members is small you could generate a concatenation of all of the membernames as the input dataset to a sort/copy step and define the combined output file large enough to hold them.

I believe Johng's analysis of the IEBGENER SYSPRINT output is correct. I'm pretty sure this is what you get if you try to read the directory using the DCB attributes of the members. Dick Scherrer's question about the number of members in the data set is an obvious precursor for a size analysis, though it's less obvious is whether the member names are fixed or change all the time.

It would not be difficult for an experienced Assembler programmer to write a small (roughly 160 lines) Assembler program to do a custom unload of the PDS to a sequential data set. If there are not too many members one could write a CLIST or Rexx EXEC to generate IEBGENER JCL to perform the dirty deed, though by the time you're done the CLIST or Rexx exec would be similar in size to the Assembler program.

All the pds members are 485 bytes so the o/p would have a lrecl of 485. The name(s) of the members can be different every day along with the number of members.
Assembler? Ahhhhh, the good old days. If there's no canned way I can do that, it will be fun.
Thanks,
John

Hello,

One easy way to get what you want is to create a list of all of the member names and then generate the input DD concatenation from the member list. Your sort product can be used to copy the concatenated input to a single output.

I ended up creating the pds member list using sas and a cobol pgm to read each member 1 at a time using dynamic allocation and writing the contents of each to a single o/p.

Dick, i'm assuming that i would need to submit to the internal reader using your suggestion of building the input concatenation. We can't use the IRDR here. If my assumption is wrong please let me know.

Thx all.
John

If you have SAS, you could do it all in SAS -- SAS can read the PDS and then each member, outputting everything to a sequential file. Googling sas pds read returns 41,100 hits and the SAS papers give explicit directions on how to do this.