IBM Mainframe Forum

I need to load a PDS with DCB=(RECFM=VB,LRECL=255). IEBUPDTE abends on 013-20 on the SYSIN (also DCB=(RECFM=VB,LRECL=255)).

I tried to reallocate the PDS and convert the input file (using SORT VTOF) into DCB=(RECFM=FB,LRECL=255). IEBUPDTE abended with the same result.

How do I load such a library... what utility should i use, or, alternatively, what am I doing wrong?
Thanks
ZA

I would look at the requirements of IEBUPDTE - it is designed for 80 byte PDSes. Why not try IEBGENER?

Thanks
It seems to be complicated and rigid method, but I will give it a try. I have Variable length records and the IEBGENER forces me to give one-size-fits-all, but I guess I have to live with that (if it will work at all)
ZA

It is almost tempting to just write a simple Rexx program that would mimic the './ ADD NAME=' functionality of IEBUPDTE. If such program is not available on CBTTAPE, I might just do it myself.
ZA

If the input data / file is on DASD, and you have access to TSO/ISPF, you can use option 3.3, that will copy variable length records.

I have many members and do not wish to do it manually. However, there is a program PDSLOAD on CBTTAPE file093. If that one does not support VB, I will just write my Rexx and contribute it to CBTTAPE
Thanks
ZA

zatlas1 wrote:It is almost tempting to just write a simple Rexx program that would mimic the './ ADD NAME=' functionality of IEBUPDTE. If such program is not available on CBTTAPE, I might just do it myself.
ZA

Such a Rexx script would be very slow, in part because Rexx itself is slow, and also because each output member would be allocated by something like a TSO ALLOCATE command like

ALLOCATE DATASET(dsn(member)) OLD FILE(xxx) REUSE

Hi Steve
You are obviously absolutely correct, it IS VERY SLOW and I knew that in advance. Nevertheless, I wrote it and it worked for me (I have only 41 members and that might grow to around 50, no more). However, Sam Golob of the CBTTAPE (www.cbttape.org) claims that PDSLOAD or its sister UPDTE (file093 on the CBT tape) should support VB and I might give it a try some time.

BTW, an interesting anecdote about Rexx speed. On a previos project, I used some Rexx process on Linux (downloaded and used the ooRexx for Linux) to loop on massive directories. On a directory of 19000 files it worked for about 20 minutes. OK, so I moved it to the "production" platform, an AIX machine, with ooRexx for AIX. It took 4 (FOUR) hours. Since Linux was not an option and my files originated from the mainframe anyway, I moved it to the mainframe, eliminated allocate/open/close/free on the output side (wrote a huge sequential file with './ ADD NAME=whatever before every member) but could not eliminate that same allocate/open/close/free for each and every input member as Steve had indicated above. It took a tolerable time of about an hour. So as usual, our good ol' mainframe beats any st____ng Unix, any time, despite the arcane file system. The only question is HOW DO THEY DO IT in Linux?!?
ZA

OS/360 PDS directory processing is very slow, compared to Unix style directory processing. I suspect if you had a program execution analyzer such as Strobe watching the big IEBUPDTE run I'm almost certain 90% of the time would be in STOW. Long time followers of this forum know I generally detest PDSE, but it would probably beat PDS for this run, though the CPU cost would most likely be higher, and the target dataset would most likely be bigger.

OS/360 PDS directory depends on what I think was the worst design decision in System/360 hardware: keyed searching in DASD hardware, and also the second worst decision; the use of ity bity (256 byte) physical data records in DASD. Given the cost structures in hardware at the time - a byte of central storage in those days cost on the order of $20 in 2012 currency - the ity bity DASD records probably made more sense than it appears now.

I'm not familiar with the CBT PDSLOAD utility. About 18 months ago I wrote a program I called PDSLOAD, so I'm not about to acquire the CBT program myself - my requirements were different than what I suspect the nominal requirements of the CBT PDSLOAD are - and I don't want to clutter up my program collection with a second PDSLOAD.

Hello,

Have you tried to copy members into this "non-standard" pds using your sort product?