Re: [EXTERNAL] LRECL=255 vs LRECL=259

[Edward Gould]

> 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

[Paul Gilmartin]

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

[Edward Gould]

> 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

[Mick Graley]

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

[Bill Godfrey]

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: LRECL=255 vs LRECL=259

[scott Ford]

Ed,
Lrecl=255 here

Scott

On Tuesday, November 15, 2016, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

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

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

[Paul Gilmartin]

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

[Edward Gould]

> 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: Old MF shops - was - RE: LRECL=255 vs LRECL=259

[Ed Jaffe]

On 11/15/2016 2:23 PM, Lester, Bob wrote:

HI Ed,

 One more, then I'll go back to lurking

 Was SPAC related to SPIZ?  I seem to remember that SPIZ was Security 
Pacific (something), but then it gets cloudy...


I know of no SPIZ.

When I started there, it was Security Pacific National Bank (SPNB). Then 
they spun off their IT services into a separate entity called Security 
Pacific Automation Corp (SPAC) which serviced SPNB with aspirations to 
possibly service third parties as well.


A couple/few years later they were absorbed by Bank of America (BofA) 
and that was that...


--
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: Old MF shops - was - RE: LRECL=255 vs LRECL=259

[Jesse 1 Robinson]

SPAC was Security Pacific Automation Company, a wholly owned subsidiary of the 
parent corporation. When U.S. banking was (partially) deregulated in the 80s, 
SPAC was set up to contain all of IT, including people, hardware, and software. 
SPAC was then allowed to compete for outside business along the lines of a 
service bureau. In a similar vein, banking business units were allowed to look 
outside for service if they weren't happy with SPAC offerings. 

I don't remember 'SPIZ', but it's plausible that such a unit existed. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lester, Bob
Sent: Tuesday, November 15, 2016 2:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Old MF shops - was - RE: LRECL=255 vs LRECL=259

HI Ed,

One more, then I'll go back to lurking

Was SPAC related to SPIZ?  I seem to remember that SPIZ was Security 
Pacific (something), but then it gets cloudy...

Thanks!
BobL

-Original Message-
From: Lester, Bob
Sent: Tuesday, November 15, 2016 3:12 PM
To: 'IBM Mainframe Discussion List' <IBM-MAIN@LISTSERV.UA.EDU>
Subject: RE: Old MF shops - was - RE: LRECL=255 vs LRECL=259 [ EXTERNAL ]

Hi Ed,

Dang fat fingers!  That should be BofB, or more formally, FNBofB.

Thanks!
BobL

-Original Message-
From: Lester, Bob
Sent: Tuesday, November 15, 2016 3:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Old MF shops - was - RE: LRECL=255 vs LRECL=259 [ EXTERNAL ]

HI Ed,

Does BofA predate BoB?

Sorry, I realize it's not Friday yet, but

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, November 15, 2016 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LRECL=255 vs LRECL=259 [ EXTERNAL ]

On 11/15/2016 11:51 AM, Jesse 1 Robinson wrote:
> Ed, you and I shared some of that life at Security Pacific Bank. Too late to 
> check on SPAC now, but my recollection from before I met you until today, I 
> have always used/encountered LRECL 255.

SPAC is one of the places I remember using LRECL=259, but as you say it can't 
be checked now. BofA cannibalized and then decommissioned those systems long 
ago...

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 


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

Re: Old MF shops - was - RE: LRECL=255 vs LRECL=259

[Lester, Bob]

HI Ed,

One more, then I'll go back to lurking

Was SPAC related to SPIZ?  I seem to remember that SPIZ was Security 
Pacific (something), but then it gets cloudy...

Thanks!
BobL

-Original Message-
From: Lester, Bob 
Sent: Tuesday, November 15, 2016 3:12 PM
To: 'IBM Mainframe Discussion List' <IBM-MAIN@LISTSERV.UA.EDU>
Subject: RE: Old MF shops - was - RE: LRECL=255 vs LRECL=259 [ EXTERNAL ]

Hi Ed,

Dang fat fingers!  That should be BofB, or more formally, FNBofB.

Thanks!
BobL

-Original Message-
From: Lester, Bob 
Sent: Tuesday, November 15, 2016 3:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Old MF shops - was - RE: LRECL=255 vs LRECL=259 [ EXTERNAL ]

HI Ed,

Does BofA predate BoB?

Sorry, I realize it's not Friday yet, but

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, November 15, 2016 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LRECL=255 vs LRECL=259 [ EXTERNAL ]

On 11/15/2016 11:51 AM, Jesse 1 Robinson wrote:
> Ed, you and I shared some of that life at Security Pacific Bank. Too late to 
> check on SPAC now, but my recollection from before I met you until today, I 
> have always used/encountered LRECL 255.

SPAC is one of the places I remember using LRECL=259, but as you say it can't 
be checked now. BofA cannibalized and then decommissioned those systems long 
ago...

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.phoenixsoftware.com_=CwICaQ=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k=1KMMjoSvFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4=jd9f-0qwkZdGAlNqQsyWuO89ZG9lEzhspx2X-sl1va0=pjROUYXKYMAly0x3r2CPygo1uXzKc5JusL4u3gw4iAY=
 

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

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications.


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

Re: Old MF shops - was - RE: LRECL=255 vs LRECL=259

[Lester, Bob]

Hi Ed,

Dang fat fingers!  That should be BofB, or more formally, FNBofB.

Thanks!
BobL

-Original Message-
From: Lester, Bob 
Sent: Tuesday, November 15, 2016 3:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Old MF shops - was - RE: LRECL=255 vs LRECL=259 [ EXTERNAL ]

HI Ed,

Does BofA predate BoB?

Sorry, I realize it's not Friday yet, but

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, November 15, 2016 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LRECL=255 vs LRECL=259 [ EXTERNAL ]

On 11/15/2016 11:51 AM, Jesse 1 Robinson wrote:
> Ed, you and I shared some of that life at Security Pacific Bank. Too late to 
> check on SPAC now, but my recollection from before I met you until today, I 
> have always used/encountered LRECL 255.

SPAC is one of the places I remember using LRECL=259, but as you say it can't 
be checked now. BofA cannibalized and then decommissioned those systems long 
ago...

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.phoenixsoftware.com_=CwICaQ=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k=1KMMjoSvFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4=jd9f-0qwkZdGAlNqQsyWuO89ZG9lEzhspx2X-sl1va0=pjROUYXKYMAly0x3r2CPygo1uXzKc5JusL4u3gw4iAY=
 

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

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications.


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

Old MF shops - was - RE: LRECL=255 vs LRECL=259

[Lester, Bob]

HI Ed,

Does BofA predate BoB?

Sorry, I realize it's not Friday yet, but

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, November 15, 2016 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LRECL=255 vs LRECL=259 [ EXTERNAL ]

On 11/15/2016 11:51 AM, Jesse 1 Robinson wrote:
> Ed, you and I shared some of that life at Security Pacific Bank. Too late to 
> check on SPAC now, but my recollection from before I met you until today, I 
> have always used/encountered LRECL 255.

SPAC is one of the places I remember using LRECL=259, but as you say it can't 
be checked now. BofA cannibalized and then decommissioned those systems long 
ago...

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.phoenixsoftware.com_=CwICaQ=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k=1KMMjoSvFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4=jd9f-0qwkZdGAlNqQsyWuO89ZG9lEzhspx2X-sl1va0=pjROUYXKYMAly0x3r2CPygo1uXzKc5JusL4u3gw4iAY=
 

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

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications.


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

Re: LRECL=255 vs LRECL=259

[Ed Jaffe]

On 11/15/2016 11:51 AM, Jesse 1 Robinson wrote:

Ed, you and I shared some of that life at Security Pacific Bank. Too late to 
check on SPAC now, but my recollection from before I met you until today, I 
have always used/encountered LRECL 255.


SPAC is one of the places I remember using LRECL=259, but as you say it 
can't be checked now. BofA cannibalized and then decommissioned those 
systems long ago...


--
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: LRECL=255 vs LRECL=259

[Farley, Peter x23353]

I'll chime in on this.  I regularly use LRECL=259 for private PDS's when they 
need to be VB specifically to get 255 on any line, or to receive JES and other 
report listings where I don’t know the incoming LRECL a priori.

LRECL=255 is probably OK for any of my actual usage, I just prefer 259.

If I were a vendor, I would probably "go along to get along" and use 255 if 
that's what the client(s) want.  Not enough difference to take a firm stand on 
it one way or the other.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, November 15, 2016 2:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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...

-- 


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: LRECL=255 vs LRECL=259

[Jesse 1 Robinson]

Ed, you and I shared some of that life at Security Pacific Bank. Too late to 
check on SPAC now, but my recollection from before I met you until today, I 
have always used/encountered LRECL 255. I know that limits record data to 251, 
but is there something special in having 4 extra bytes? It's just a custom that 
seems to prevail in most shops that have standardized on VB. 

The big divide is whether to use FB or VB. Since those cannot be concatenated, 
it's a huge and generally irrevocable choice. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, November 15, 2016 11:00 AM
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

Re: LRECL=255 vs LRECL=259

[Gord Tomlin]

I've never seen LRECL=259 in my life...well, until now!

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

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

Re: LRECL=255 vs LRECL=259

[Paul Gilmartin]

On Tue, 15 Nov 2016 14:11:55 -0500, Tony Harminc wrote:
>
>But does it matter much? Concatenating or copying between VB 255 and
>VB 259 should "just work" in almost all cases, whereas trying to mix &
>match either of those with FB 80 is trouble.
>
In JCL, I use DISP=NEW,LRECL=222,BLKSIZE=SDB.  Ergonomic; least
hand motion.  If I needed more, I'd use 333.

ISPF used to have the 255 limit.  No longer AFAIK.  Old phobias
die hard.

And UNIX files are wonderful.  Whatever attributes you specify
in the DCB, the access method makes them look that way.  It
should have ever been thus so you could mix FB and VB simply
by overriding the DCB in JCL.

-- gil

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

Re: LRECL=255 vs LRECL=259

[Paul Gilmartin]

On Tue, 15 Nov 2016 10:59:43 -0800, Ed Jaffe wrote:
>
>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.
>
Why limit them at all?  Why not "whatever they want?"

It should matter little.  Nowadays (at last!) in a concatenation the largest
value prevails (or is that only for BLKSIZE?)

And if you need a larger member in a PDS, just copy it in with overriding
LRECL which sticks in the DSCB.

What was R.S. trying to tell me?  That at least it's not an undocumented
limitation?  I see nothing relevant in SG24-6106 (but what keywords?)

One of these days, I need to RFE for support of UNIX files in SYSEXEC
concatenation.  It works, sort of, but since it's unsupported an SR
is pointless.

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

[Ed Jaffe]

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

[Dyck, Lionel B. (TRA)]

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

Re: LRECL=255 vs LRECL=259

[Richards, Robert B.]

Put me in the 255 camp. I've never seen a 259 LRECL

I not sure if I ever got close to using 251/255 anyway, even indenting by two 
for all Do/End, Select/When, If/Else statements and four or five levels of 
nesting! :-)

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, November 15, 2016 2:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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

Re: LRECL=255 vs LRECL=259

[Tony Harminc]

On 15 November 2016 at 13:59, Ed Jaffe  wrote:
> 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.

My 40ish years of anecdotal evidence suggests 255.

But does it matter much? Concatenating or copying between VB 255 and
VB 259 should "just work" in almost all cases, whereas trying to mix &
match either of those with FB 80 is trouble.

Tony H.

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

Re: LRECL=255 vs LRECL=259

[Roach, Dennis]

I have only seen fb80 and vb255. Never saw vb259.

Dennis Roach, CISSP, PMP
AIG
IAM Access Administration – Infrastructure | Identity & Access Management

2929 Allen Parkway, America Building, 3rd Floor | Houston, TX 77019
Phone:  713-831-8799

dennis.ro...@aig.com | www.aig.com 


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

LRECL=255 vs LRECL=259

[Ed Jaffe]

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