Re: [EXTERNAL] LRECL=255 vs LRECL=259
> On Nov 16, 2016, at 12:28 PM, Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > On Wed, 16 Nov 2016 11:12:53 -0600, Edward Gould wrote: >> >> I think smp (NOTE without the e) was the problem a long time ago. >> There was a gotcha in that IEBUPDTE does *NOT* support VB records. >> IBM needed to support VB but their utilities did NOT. >> IBM then forced the issue of changing clists to FB. BUT by then everyone was >> using VB. >> Even today there is no IBM system utility that supports VB, and IBM >> continues to send out FB clists. >> > How is this still a thing!? > > What's a "utility"? IEBGENER and IEBCOPY and Rexx support VB. I'd > substitute "not all" for "no”. IBM won’t re-open the code for IEBUPDTE its stabilized. Plus it was never designed for VB records. IBM didn’t want to reship the entire member (IEBCOPY) . This was design issue (architect) of IBM’s This has been an issue since day 1 of SMP. IBM its in your corner. > > I'll try to deconstruct this. 255 was the largest record that could be > extracted from > a buffer with the IC; BCTR; EX; MVC cliche. IC can't handle more than 255 and > LH is undesirable because the RDW might be unaligned, resulting in a > specification > exception. 3120 is probably optimum for some model DASD. > > To Ed J. I'll suggest Postel's law. Deal with anything the user presents you > in > an existing data set up to 32756. For a new data set if it's your choice, > 255. > 3120? SDB? TSO has been stabalized and won’t (can’t) fix it . Yell at IBM. > > Puzzle: What's the smallest BLKSIZE that SDB will select for a blocked data > set on a 3390? I have an empirical answer, but someone else might find > a smaller one. > >> There could be a solution that IBM would support VB/FB concatenation. >> > To me, it would be a boon if Rexx supported PDS/UNIX concatenation. > It usually works, but since it's "unsupported" I can't seek relief in the > instances when it doesn't. It's a nuisance to copy EXECs back and > forth when I use them in both environments. > >> There are several obstacles to doing this and IBM doesn’t (IMO) want to >> spend the time to do so. >> > BSAM/QSAM can treat a UNIX file as either VB or FB according to the > allocation options. > > And SMP/E (but not IEBUPDTE) can deal with VB with GIMDTS. > > And IBM is offering me a fixtest for a problem I reported for the SDSF > Rexx interface's failing for a SYSIN with RECFM=VB,LRECL=32753. > > -- 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: [EXTERNAL] LRECL=255 vs LRECL=259
On Wed, 16 Nov 2016 11:12:53 -0600, Edward Gould wrote: > >I think smp (NOTE without the e) was the problem a long time ago. >There was a gotcha in that IEBUPDTE does *NOT* support VB records. >IBM needed to support VB but their utilities did NOT. >IBM then forced the issue of changing clists to FB. BUT by then everyone was >using VB. >Even today there is no IBM system utility that supports VB, and IBM continues >to send out FB clists. > How is this still a thing!? What's a "utility"? IEBGENER and IEBCOPY and Rexx support VB. I'd substitute "not all" for "no". I'll try to deconstruct this. 255 was the largest record that could be extracted from a buffer with the IC; BCTR; EX; MVC cliche. IC can't handle more than 255 and LH is undesirable because the RDW might be unaligned, resulting in a specification exception. 3120 is probably optimum for some model DASD. To Ed J. I'll suggest Postel's law. Deal with anything the user presents you in an existing data set up to 32756. For a new data set if it's your choice, 255. 3120? SDB? Puzzle: What's the smallest BLKSIZE that SDB will select for a blocked data set on a 3390? I have an empirical answer, but someone else might find a smaller one. >There could be a solution that IBM would support VB/FB concatenation. > To me, it would be a boon if Rexx supported PDS/UNIX concatenation. It usually works, but since it's "unsupported" I can't seek relief in the instances when it doesn't. It's a nuisance to copy EXECs back and forth when I use them in both environments. >There are several obstacles to doing this and IBM doesn’t (IMO) want to spend >the time to do so. > BSAM/QSAM can treat a UNIX file as either VB or FB according to the allocation options. And SMP/E (but not IEBUPDTE) can deal with VB with GIMDTS. And IBM is offering me a fixtest for a problem I reported for the SDSF Rexx interface's failing for a SYSIN with RECFM=VB,LRECL=32753. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] LRECL=255 vs LRECL=259
> On Nov 16, 2016, at 10:12 AM, Mick Graley wrote: > > I think Ed might be right here on the SYSGEN option history, however TSO > EDIT doesn't seem to support it fully these days. > I have access to 5 very different systems each with different heritage. > Two of them are >30 years old and will date back to the SYSGEN days, one of > them I'm not sure of it's age, but the other two are much younger. > All of them use an FB 80 SYSPROC concatenation except for one of the older > systems which uses a VB 255 SYSPROC concatenation. > TSO EDIT creates a VB,255,3120 data set for type CLIST on all the systems > except for the older FB 80 system, which creates a corrupt FB,80,3120 data > set. I'm guessing that the original SYSGEN option of FB was copied across > for this system, but it doesn't look like TSO EDIT fully supports it as > it's obviously still using variable length edit buffers, but writing full > FB 80 byte records to the new PDS with the line numbers at the beginning of > the record rather than in columns 72-80. Here is a transcript of a TSO > session on the older FB system to demonstrate this: > > READY > listds temp.clist > IKJ58503I DATA SET xx.TEMP.CLIST NOT IN CATALOG > READY > e temp(hello) cl > IKJ52320I DATA SET OR MEMBER NOT FOUND, ASSUMED TO BE NEW > INPUT > 00010 proc 0 > 00020 write hello mick > 00030 end > 00040 > E > l > 00010 PROC 0 > 00020 WRITE HELLO MICK > 00030 END > IKJ52500I END OF DATA > end save —_SNIP I think smp (NOTE without the e) was the problem a long time ago. There was a gotcha in that IEBUPDTE does *NOT* support VB records. IBM needed to support VB but their utilities did NOT. IBM then forced the issue of changing clists to FB. BUT by then everyone was using VB. Even today there is no IBM system utility that supports VB, and IBM continues to send out FB clists. There could be a solution that IBM would support VB/FB concatenation. There are several obstacles to doing this and IBM doesn’t (IMO) want to spend the time to do so. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] LRECL=255 vs LRECL=259
I think Ed might be right here on the SYSGEN option history, however TSO EDIT doesn't seem to support it fully these days. I have access to 5 very different systems each with different heritage. Two of them are >30 years old and will date back to the SYSGEN days, one of them I'm not sure of it's age, but the other two are much younger. All of them use an FB 80 SYSPROC concatenation except for one of the older systems which uses a VB 255 SYSPROC concatenation. TSO EDIT creates a VB,255,3120 data set for type CLIST on all the systems except for the older FB 80 system, which creates a corrupt FB,80,3120 data set. I'm guessing that the original SYSGEN option of FB was copied across for this system, but it doesn't look like TSO EDIT fully supports it as it's obviously still using variable length edit buffers, but writing full FB 80 byte records to the new PDS with the line numbers at the beginning of the record rather than in columns 72-80. Here is a transcript of a TSO session on the older FB system to demonstrate this: READY listds temp.clist IKJ58503I DATA SET xx.TEMP.CLIST NOT IN CATALOG READY e temp(hello) cl IKJ52320I DATA SET OR MEMBER NOT FOUND, ASSUMED TO BE NEW INPUT 00010 proc 0 00020 write hello mick 00030 end 00040 E l 00010 PROC 0 00020 WRITE HELLO MICK 00030 END IKJ52500I END OF DATA end save READY listds temp.clist xx.TEMP.CLIST --RECFM-LRECL-BLKSIZE-DSORG FB803120PO --VOLUMES-- vv READY print inda(temp.clist(hello)) char RECORD SEQUENCE NUMBER - 1 0010PROC 05...IBMOSVS2 ..&&..QS . RECORD SEQUENCE NUMBER - 2 0020WRITE HELLO MICK..IBMOSVS2 ..&&..QS . RECORD SEQUENCE NUMBER - 3 0030ENDTE HELLO MICK..IBMOSVS2 ..&&..QS . IDC0005I NUMBER OF RECORDS PROCESSED WAS 3 READY exec temp.clist(hello) 0010PROC 05 -È-- IBMOSVS2ØØ -- ° - & Ø& - -QS - IKJ56545I THIS STATEMENT HAS AN INVALID SYMBOLIC VARIABLE READY Same member shown in ISPF/PDF browse: 0010PROC 05..È. ..IBMOSVS2 ...ØØ°&...Ø&..QS. 0020WRITE HELLO MICK..IBMOSVS2 ...ØØ°&...Ø&..QS. 0030ENDTE HELLO MICK..IBMOSVS2 ...ØØ°&...Ø&..QS. As you would expect, editing a new member in an existing FB 80 CLIST data set works fine and puts the line numbers in the right place. Interesting stuff! Cheers, Mick. On 16 November 2016 at 04:38, Edward Gould wrote: > > On Nov 15, 2016, at 1:16 PM, Dyck, Lionel B. (TRA) > wrote: > > > > I'm in the 255 camp and just tried a simple experiment. > > > > From TSO issue the Edit command: E T(ABC) CL > > > > This opens the old editor on dataset t.clist member abc and after adding > a few records and saving I checked the dcb which was VB,255,3120 > > > > Not the ideal blksize but the lrecl is what I expected. > > > > hth > > > > Lionel: > > At least in mvs 3.8 there was a sysgen macro you could specify FB VB and > lrecl blksize etc. > Since system dissapeared I am not sure what the defaults are now days. > > Ed > > -- > 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: [EXTERNAL] LRECL=255 vs LRECL=259
On 2016-11-15 12:16, Dyck, Lionel B. wrote: > I'm in the 255 camp and just tried a simple experiment. > > From TSO issue the Edit command: E T(ABC) CL > > This opens the old editor on dataset t.clist member abc and after adding a > few records and saving I checked the dcb which was VB,255,3120 > > Not the ideal blksize but the lrecl is what I expected. > In old TSO EDIT (alias E), 255 is not only the default lrecl for clist data sets, it's the maximum. edit test1 clist new emode lrecl(256) IKJ52335I INVALID LINE VALUE FOR CLIST, USING 255+ IKJ52335I LINE SIZE FOR CLIST MAY NOT EXCEED 255 edit test1 data new emode lrecl(256) IKJ52335I INVALID LINE VALUE FOR DATA, USING 80+ IKJ52335I LINE SIZE FOR DATA MAY NOT EXCEED 255 if PDS member test2.clist(a) exists and the PDS is VB with lrecl 256, EDIT can't handle it. edit test2(a) clist IKJ52336I 256 INVALID LINE VALUE FOR CLIST DATA SET That might be the reason why, historically, clist data sets have used lrecl 255 and not 259, even though they work as 259. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] LRECL=255 vs LRECL=259
On 2016-11-15 12:16, Dyck, Lionel B. (TRA) wrote: > I'm in the 255 camp and just tried a simple experiment. > > From TSO issue the Edit command: E T(ABC) CL > > This opens the old editor on dataset t.clist member abc and after adding a > few records and saving I checked the dcb which was VB,255,3120 > > Not the ideal blksize but the lrecl is what I expected. > It really should use SDB. Please submit an RFE. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] LRECL=255 vs LRECL=259
> On Nov 15, 2016, at 1:16 PM, Dyck, Lionel B. (TRA) wrote: > > I'm in the 255 camp and just tried a simple experiment. > > From TSO issue the Edit command: E T(ABC) CL > > This opens the old editor on dataset t.clist member abc and after adding a > few records and saving I checked the dcb which was VB,255,3120 > > Not the ideal blksize but the lrecl is what I expected. > > hth > Lionel: At least in mvs 3.8 there was a sysgen macro you could specify FB VB and lrecl blksize etc. Since system dissapeared I am not sure what the defaults are now days. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] LRECL=255 vs LRECL=259
On 11/15/2016 11:16 AM, Dyck, Lionel B. (TRA) wrote: I'm in the 255 camp and just tried a simple experiment. From TSO issue the Edit command: E T(ABC) CL This opens the old editor on dataset t.clist member abc and after adding a few records and saving I checked the dcb which was VB,255,3120 Not the ideal blksize but the lrecl is what I expected. hth Thanks, Lionel! TSO EDIT allocating (by default) LRECL=255 is enough evidence to suggest to me that LRECL=255 is the way to go. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] LRECL=255 vs LRECL=259
I'm in the 255 camp and just tried a simple experiment. From TSO issue the Edit command: E T(ABC) CL This opens the old editor on dataset t.clist member abc and after adding a few records and saving I checked the dcb which was VB,255,3120 Not the ideal blksize but the lrecl is what I expected. hth -- Lionel B. Dyck (TRA Contractor) Mainframe Systems Programmer Enterprise Infrastructure Support (Station 200) (005OP6.3.10) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Tuesday, November 15, 2016 1:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] LRECL=255 vs LRECL=259 My whole life I have seen variable length CLIST/EXEC libraries allocated as RECFM=VB w/LRECL=259. Clearly, the intent was to allow up to 255-character source lines. At PSI, we provide the option for customers to allocate our CLIST/EXEC libraries either RECFM=FB w/LRECL=80 or RECFM=VB w/LRECL=259. One customer claims the industry-standard for RECFM=VB CLIST/EXEC libraries is LRECL=255 rather than LRECL=259. LRECL=255 would allow for only 251-character source lines, which seems rather strange to me. Of course, my personal observations and experiences provide nothing more than anecdotal evidence. Like a man with two watches being unsure of the time, I am now unsure if LRECL=259 is widespread practice or if I was observing only outliers. Any insight would be appreciated... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- 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
