Re: Here we go again

[Michael Phillips]

The truly "fun" part about Y2K was that IBM solved the problem in the early 60s 
with just 6 digits. CFO-64 was a life insurance application they wrote in 
Autocoder that was my first encounter with what EDS-ers called "mo-year" code. 
Dates were stored as a 4 digit number of months since some epoch (sorry, I 
don't remember the actual epoch month/year...) and a 2 digit day of the month. 
Some how or another EDS "acquired" the source and ported it to BAL as LMS. IBM 
wasn't actually worried with Y2K then, they were just taking care of policies 
for folks born before 1900!

With 9,999 available months, that code was fine for well beyond Y2K, which by 
the way, is actually still 28 years away... :)

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

Re: Here we go again

[Gabe Goldberg]

When I joined Mitre Corporation in 1971, my first TIAA-CREF end-of-year 
retirement statement predicted benefits I'd receive starting February 1, 
2012. I suspect they'd been calculating/storing/displaying 21st century 
dates long before they needed one for me. Banks, insurance companies, 
investment organizations, etc. handled this routinely because they had 
to; no tradeoff was available for them between data storage and 
now/later handling far-off dates. Others could/did ignore Y2K because 
their business didn't depend on handling it. For a while.


Seymour J Metz  said

We had well over 20 years of warning on Y2K; management preferred to 
ignore it. Apres moi le deluge (the balloon won't go up before I retire.)


--
Gabriel Goldberg, Computers and Publishing, Inc.   g...@gabegold.com
3401 Silver Maple Place, Falls Church, VA 22042   (703) 204-0433
LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0

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

Re: RCF: z/OS Version 2 Release 4 MVS JCL Reference, SA23-1385-40

[Seymour J Metz]

I did; the copy to the list was an FYI, since the question was raised here.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Peter Relson [rel...@us.ibm.com]
Sent: Wednesday, April 22, 2020 11:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RCF: z/OS Version 2 Release 4 MVS JCL Reference, SA23-1385-40

For z/OS doc updates, please send to mhvr...@us.ibm.com.

Peter Relson
z/OS Core Technology Design


--
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: Here we go again;

[Seymour J Metz]

EXIT leaves the CLIST.

IF () THEN EXIT

DO WHILE 1 = 1


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, April 22, 2020 10:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

On Thu, 23 Apr 2020 12:07:13 +1000, Wayne Bickerdike wrote:

>Something like this:
>
>DO I = 1 TO 5000
>WRITER ENTER DATASET NAME ==>
>READ 
>IF  = ' ' THEN EXIT
>ELSE DELETE 
>END
>
>(  breaks the CLIST with a IKJ56545I message produced.
>
Ah!  The invention of code injection.

I prefer Rexx's convention of not re-interpreting expressions.
Doesn't CLIST have a setting to limit that?

What does EXIT do?  Presumably not exit to READY prompt?

Why compare to one blank rather than empty string?

Is there no DO FOREVER?

-- 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: RCF: z/OS Version 2 Release 4 MVS JCL Reference, SA23-1385-40

[Peter Relson]

For z/OS doc updates, please send to mhvr...@us.ibm.com.

Peter Relson
z/OS Core Technology Design


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

Re: Here we go again;

[Seymour J Metz]

A slowly varying window.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Clark Morris [cfmt...@uniserve.com]
Sent: Wednesday, April 22, 2020 11:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

[Default] On 22 Apr 2020 14:55:28 -0700, in bit.listserv.ibm-main
sme...@gmu.edu (Seymour J Metz) wrote:

>There is no on saving on forms, printer lines, punched cards, data entry 
>screens or data entry key strokes. You input two digits, store four digits and 
>print two digits.

While on output truncation always works, by what rule does a program
expand the input date?  should a fixed window be used? a variable
window based on the current date? some other rule?

Clark Morris

--
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: Here we go again;

[Clark Morris]

[Default] On 22 Apr 2020 14:55:28 -0700, in bit.listserv.ibm-main
sme...@gmu.edu (Seymour J Metz) wrote:

>There is no on saving on forms, printer lines, punched cards, data entry 
>screens or data entry key strokes. You input two digits, store four digits and 
>print two digits. 

While on output truncation always works, by what rule does a program
expand the input date?  should a fixed window be used? a variable
window based on the current date? some other rule?

Clark Morris 

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

Re: IARST64 problem

[Peter Relson]

The example as posted would not even assemble with default assembly 
options, so this is a bit confusing.
I refer to the lower case operands such as "yes" for sysstate amode64=yes.
Maybe there's use of some assembly COMPAT option?

There are also possibilities that the switch from amode 31 to amode 64 was 
not preceded by making sure to zero the high halves of all relevant 
registers (whatever those registers might be).

It was suggested that the "LA" should be "L". No it should not. The 
documentation is clear that if specifying a register, the register 
contains the address of the fullword data (the size), it does not contain 
the size itself.

I don't know about BPX4RED, but if x'8000' is passed in register 1 to the 
service, as is the intent, it will get x'8000' bytes. It will not get 
x'2000' bytes. I also don't know what specifically IPCS is or is not 
showing.

You might try the simple approach of referencing each 4K of storage and 
see if you blow up before you reach offset x'8000'. You likely won't.

SSRV 1000 (IARST64) and 1001 (IARCP64) are, incorrectly, missing from the 
doc. I'll report that.

Peter Relson
z/OS Core Technology Design


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

Re: Here we go again;

[Paul Gilmartin]

On Thu, 23 Apr 2020 12:07:13 +1000, Wayne Bickerdike wrote:

>Something like this:
>
>DO I = 1 TO 5000
>WRITER ENTER DATASET NAME ==>
>READ 
>IF  = ' ' THEN EXIT
>ELSE DELETE 
>END
>
>(  breaks the CLIST with a IKJ56545I message produced.
> 
Ah!  The invention of code injection.

I prefer Rexx's convention of not re-interpreting expressions.
Doesn't CLIST have a setting to limit that?

What does EXIT do?  Presumably not exit to READY prompt?

Why compare to one blank rather than empty string?

Is there no DO FOREVER?

-- gil

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

Re: Here we go again;

[Wayne Bickerdike]

Something like this:

DO I = 1 TO 5000
WRITER ENTER DATASET NAME ==>
READ 
IF  = ' ' THEN EXIT
ELSE DELETE 
END


(  breaks the CLIST with a IKJ56545I message produced.



On Thu, Apr 23, 2020 at 11:55 AM Wayne Bickerdike  wrote:

>
> *Lennie Dymoke-Bradshaw lenni...@rsmpartners.com
>  via
>  ua.edu
>  *
> *9:19 AM (2 hours ago)*
> *to IBM-MAIN*
> *How did you delete the files if you were not allowed to logon? *Asked..
>
> You were in the LOGON PROCEDURE. It ran a CLIST that listed all your
> personal dataset allocations. At that point you could delete datasets. So
> although you were in the TSO environment, you couldn't do much.
>
> Somebody actually worked out a way to break the CLIST. I guess it was a
> WRITE command that received a response. If you typed in ( the CLIST
> would break. Then you could go SPF (before the days of ISPF).
>
> I should try it, for posterity, now that you asked.
>
>
>
> On Thu, Apr 23, 2020 at 9:49 AM Bob Bridges  wrote:
>
>> I think Mr Morris is right.  I'm reminded of an update I had to handle
>> during the '80s.  Volvo had bought White Motors, and I went to work for
>> Volvo-White Truck (now Volvo Truck North America) in 1982.  As some of you
>> know, those tractor rigs cost about as much as a house, and some time in
>> the '80s the base price of some models (before options) rose above $100 000
>> for the first time.  That meant an extra byte in a packed-decimal field
>> that in many programs was part of a larger REPEAT-6 array.
>>
>> I worked my way through about 150 programs, finding the ones that had to
>> be changed, enlarging the field and in many cases moving the entire array
>> to different places in various records as I found room.  I don't remember
>> how many programs, two or three score at least.  At the very end I
>> encountered a data-input form (this was before on-line data entry) that
>> involved three 80-byte cards - and every card had every single byte
>> filled.  There was no room on any of the forms for an additional byte.
>>
>> The new on-line data-entry system was expected to be ready in about six
>> months.  Do I create a new form for just that?  The Marketing manager said
>> no.  So I wrote a DYL-280II program, checked it thrice, and for the next
>> six months, whenever a change to a base price had to go into production,
>> Jack walked down to my desk, we put the change in the program, checked it
>> three times, squinched our eyes tight and pushed the button.  Happened four
>> or five times in that six months, and it scared me every time, but it never
>> blew up on us.  That was before change control, of course; we could never
>> do that now.
>>
>> Anyway, I understand your point, Gil, but in the light of that experience
>> I have to say that the input form ~is~ storage, in some way - or at least
>> it isn't merely presentation.
>>
>> ---
>> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>>
>> /* There are only two kinds of people in the end: those who say to God
>> "Thy will be done", and those to whom God says, in the end, "THY will be
>> done".  -from _The Great Divorce_ by C S Lewis */
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Paul Gilmartin
>> Sent: Wednesday, April 22, 2020 17:12
>>
>> But that concerns presentation, not storage.  You could as well store
>> TOD clock values and let the output formatting routine display
>> 4, 2, or even single digit years.
>>
>> --- On Wed, 22 Apr 2020 17:35:01 -0300, Clark Morris wrote:
>> >In reviewing this discussion, I suddenly realized that the saving by
>> >using 2 digit years was not just disk and tape space but also on
>> >forms, printer lines, punched cards, data entry screens and data entry
>> >key strokes.  I know that in many cases I was scrambling for space on
>> >print lines.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
> --
> Wayne V. Bickerdike
>
>

-- 
Wayne V. Bickerdike

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

Re: Here we go again;

[Wayne Bickerdike]

*Lennie Dymoke-Bradshaw lenni...@rsmpartners.com
 via
 ua.edu
 *
*9:19 AM (2 hours ago)*
*to IBM-MAIN*
*How did you delete the files if you were not allowed to logon? *Asked..

You were in the LOGON PROCEDURE. It ran a CLIST that listed all your
personal dataset allocations. At that point you could delete datasets. So
although you were in the TSO environment, you couldn't do much.

Somebody actually worked out a way to break the CLIST. I guess it was a
WRITE command that received a response. If you typed in ( the CLIST
would break. Then you could go SPF (before the days of ISPF).

I should try it, for posterity, now that you asked.



On Thu, Apr 23, 2020 at 9:49 AM Bob Bridges  wrote:

> I think Mr Morris is right.  I'm reminded of an update I had to handle
> during the '80s.  Volvo had bought White Motors, and I went to work for
> Volvo-White Truck (now Volvo Truck North America) in 1982.  As some of you
> know, those tractor rigs cost about as much as a house, and some time in
> the '80s the base price of some models (before options) rose above $100 000
> for the first time.  That meant an extra byte in a packed-decimal field
> that in many programs was part of a larger REPEAT-6 array.
>
> I worked my way through about 150 programs, finding the ones that had to
> be changed, enlarging the field and in many cases moving the entire array
> to different places in various records as I found room.  I don't remember
> how many programs, two or three score at least.  At the very end I
> encountered a data-input form (this was before on-line data entry) that
> involved three 80-byte cards - and every card had every single byte
> filled.  There was no room on any of the forms for an additional byte.
>
> The new on-line data-entry system was expected to be ready in about six
> months.  Do I create a new form for just that?  The Marketing manager said
> no.  So I wrote a DYL-280II program, checked it thrice, and for the next
> six months, whenever a change to a base price had to go into production,
> Jack walked down to my desk, we put the change in the program, checked it
> three times, squinched our eyes tight and pushed the button.  Happened four
> or five times in that six months, and it scared me every time, but it never
> blew up on us.  That was before change control, of course; we could never
> do that now.
>
> Anyway, I understand your point, Gil, but in the light of that experience
> I have to say that the input form ~is~ storage, in some way - or at least
> it isn't merely presentation.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* There are only two kinds of people in the end: those who say to God
> "Thy will be done", and those to whom God says, in the end, "THY will be
> done".  -from _The Great Divorce_ by C S Lewis */
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Wednesday, April 22, 2020 17:12
>
> But that concerns presentation, not storage.  You could as well store
> TOD clock values and let the output formatting routine display
> 4, 2, or even single digit years.
>
> --- On Wed, 22 Apr 2020 17:35:01 -0300, Clark Morris wrote:
> >In reviewing this discussion, I suddenly realized that the saving by
> >using 2 digit years was not just disk and tape space but also on
> >forms, printer lines, punched cards, data entry screens and data entry
> >key strokes.  I know that in many cases I was scrambling for space on
> >print lines.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

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

Re: Here we go again;

[Bob Bridges]

I think Mr Morris is right.  I'm reminded of an update I had to handle during 
the '80s.  Volvo had bought White Motors, and I went to work for Volvo-White 
Truck (now Volvo Truck North America) in 1982.  As some of you know, those 
tractor rigs cost about as much as a house, and some time in the '80s the base 
price of some models (before options) rose above $100 000 for the first time.  
That meant an extra byte in a packed-decimal field that in many programs was 
part of a larger REPEAT-6 array.

I worked my way through about 150 programs, finding the ones that had to be 
changed, enlarging the field and in many cases moving the entire array to 
different places in various records as I found room.  I don't remember how many 
programs, two or three score at least.  At the very end I encountered a 
data-input form (this was before on-line data entry) that involved three 
80-byte cards - and every card had every single byte filled.  There was no room 
on any of the forms for an additional byte.

The new on-line data-entry system was expected to be ready in about six months. 
 Do I create a new form for just that?  The Marketing manager said no.  So I 
wrote a DYL-280II program, checked it thrice, and for the next six months, 
whenever a change to a base price had to go into production, Jack walked down 
to my desk, we put the change in the program, checked it three times, squinched 
our eyes tight and pushed the button.  Happened four or five times in that six 
months, and it scared me every time, but it never blew up on us.  That was 
before change control, of course; we could never do that now.

Anyway, I understand your point, Gil, but in the light of that experience I 
have to say that the input form ~is~ storage, in some way - or at least it 
isn't merely presentation.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* There are only two kinds of people in the end: those who say to God "Thy 
will be done", and those to whom God says, in the end, "THY will be done".  
-from _The Great Divorce_ by C S Lewis */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, April 22, 2020 17:12

But that concerns presentation, not storage.  You could as well store
TOD clock values and let the output formatting routine display
4, 2, or even single digit years.

--- On Wed, 22 Apr 2020 17:35:01 -0300, Clark Morris wrote:
>In reviewing this discussion, I suddenly realized that the saving by
>using 2 digit years was not just disk and tape space but also on
>forms, printer lines, punched cards, data entry screens and data entry
>key strokes.  I know that in many cases I was scrambling for space on
>print lines. 

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

Re: [External] Re: Here we go again;

[Gibney, Dave]

I agree that it lead to problems. They were not insurmountable, just required 
some routine care. This started with an argument that the extra bytes required 
for dates were insignificant compared to BLKSIZE waste, In my experience, both 
would have been significant, had we not routinely paid attention. Perhaps other 
shops failed to pay attention to one, or the other, or both. I can't say. 
Sometime in the next 12 to 24 months, I will retire from here after around 40 
years.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gerhard adam
> Sent: Wednesday, April 22, 2020 4:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [External] Re: Here we go again;
> 
> 
> 
> 
> 
>   So you agree that poor Blocksizes give rise to poor disk usage?
> As to space allocations, I’m sorry but for as many problems as you’re
> describing the staff couldn’t have been that serious. If management was as
> serious as being claimed there would have been no problem.  Yet I find that
> few people understand blocking.  They invariably get it wrong with load
> modules, VSAM, ISAM (in the old days) and BDAM.  Come to think of it, this
> only applies to sequential files. As for incompetent programmers?   Spare me
> the exaggerations.  Even today, few people understand it and most get it
> wrong when assuming that half-track blocking is optimum when other than
> sequential files are considered
> 
> 
> 
>   Get Outlook for iOS
> 
> 
> 
> 
> 
> 
> On Wed, Apr 22, 2020 at 4:11 PM -0700, "Gibney, Dave" 
> wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Full volumes due to excessive space wasted due to crap blksizes had
> everything to do with x37 abends. I am sorry that your experience included
> so many incompetent programmers.  Mine did care, and my management
> cared more. Before SDB, it was a periodic take for me to review and clean
> DASD, fix BLKSIZES, Etc. In that era, I was cheaper the STOPX37. I'm not
> cheaper today.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf Of Gerhard adam
> > Sent: Wednesday, April 22, 2020 3:44 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [External] Re: Here we go again;
> >
> >
> >
> >
> >
> > X37 abends have nothing to do with block sizes Furthermore the
> > role of secondary space allocations was so bad among programmers that
> > many installations installed a vendor product called STOPX37 because
> > it was easier then actual planning and calculating space.
> >
> >
> >
> > Get Outlook for iOS
> >
> >
> >
> >
> >
> >
> > On Wed, Apr 22, 2020 at 3:35 PM -0700, "Seymour J Metz"
> >  wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Kilobytes? Not unless you started on a 305 or 650. Even on the 650 it
> > was
> > 6,000,000 digits. The disks on the 1401 and 7000 series were somewhat
> > larger, even before the 1301, and the 2311 larger still. Only the 1130
> > was close to the 650's mere megabyte.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> >
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg
> > BY0HMszNaDT!5_-I8aqsL8R5a9A-
> > Z5U0vXKBJCfgDQPHsOlqGSGWCHFohipMYPShrUZqJpXBag$
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> > behalf of Pommier, Rex [rpomm...@sfgmembers.com]
> > Sent: Wednesday, April 22, 2020 3:07 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [External] Re: Here we go again;
> >
> > Agreed.  Another thing to remember was that we were dealing with disk
> > volumes measured in kilobytes or megabytes instead of terabytes.  In
> > addition, the site I cut my teeth on had all removable disk packs that
> > got rotated onto the drives for processing of each application.  Every
> > byte saved per record gave us the better chance of fitting the entire
> > set of datasets on a single disk set so we could process it.
> >
> > Rex
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
> > Sent: Wednesday, April 22, 2020 12:32 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [External] Re: Here we go again;
> >
> > Faulty logic there. A byte here and byte there and pretty soon you
> > have to buy ANOTHER unit of DASD. It costs the same empty or full, but
> > if it gets nearly full you have to pay for another.
> >
> > Charles
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> > On Behalf Of Gerhard adam
> > Sent: Wednesday, April 22, 2020 10:06 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Here we go again;
> >
> >
> >
> >
> >
> > The notion of “savings” was marketing nonsense.  The DASD was
> > paid for regardless of whether it held a production database or
> > someone’s golf handicap.
> > It cost the same whether it was empty or full.  The notion of “saving”
> > was nonsense and even under the best of circumstances could only be
> > deferred expenses
> >
> > 

Re: Here we go again;

[Seymour J Metz]

Presumably he used his trusty 129 terminal. Did you say 024? La, la, la, I 
can't hear you!

If you know what it is, that's one thing, but if you've used one, ...


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Lennie Dymoke-Bradshaw [lenni...@rsmpartners.com]
Sent: Wednesday, April 22, 2020 7:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

How did you delete the files if you were not allowed to logon?

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
Web:  
http://secure-web.cisco.com/18tBviL-OkjzraA7hV3_wo0zZVW2NN_DCxRJZEtFgxL_wHj4X641s0XEXyvzSNP4a03x19UZYR6_Jx7nhDHamIxu7XMQbXvlSC3Vh8f-3S5r5Kw9FtN9APVWYjlWztchLnQk0Y6_942Pkjo28WNhQIfhRnqZ3zPF4acEIP1C78m5QsdYdoeL4dI4Di7daFI59CI8pXwdr9c25KiotDloJya1ybyCH537Z1aHvBg0YPOH6lqrQ4TVV0gvcJyQogJ4f661KUlMOgdVJg2h-9e0G7RN5pEMjcf9WNiBUmxYxHs5_zPSRtyBtXT0g3w3hynTkytpziiHr6sSYVu7pQu8Y4bvGnWsV8ghlds1uwb0DDXz-xHka3OPvRNKBrkNlpSC3oUM3_peFXjq395FpSUn1gaF9n8PECvw6HYL_RGqdCNrn9twFLL1jHW1AGbx7reCR/http%3A%2F%2Fwww.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Wayne Bickerdike
Sent: 22 April 2020 21:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Here we go again;

We had constraints at IBM when I worked there in 1978. The TSO logon procedure 
checked your personal space allocation. If you had more then 150 tracks 
allocated you had to delete some files to log on. At the time we were limited 
to 30 minutes a session to allow other programmers to get some "time sharing". 
Space saving isn't  wasted effort. I had to fit applications on Z80 kit onto 2 
110k floppy disks. As a kid, we sliced up a MARS bar.

On Thu, Apr 23, 2020, 06:00 scott Ford  wrote:

> David,
>
> I laugh at these comments/observations. Early days 70-80s System
> Programmers like myself helped programmers determine blocksize and
> dataset location, etc.  and then DBAs were born or made and then the
> system optimized.
>
> Evolution
>
> Scott
>
> On Wed, Apr 22, 2020 at 3:44 PM Seymour J Metz  wrote:
>
> > My first computer had a 2,000 word drum, a 60 word core memory, a
> > 600,000 word disk drive and two tape drives. I may have been a tad
> > more
> constrained
> > than you were when you started. I agree with Mr. Adam; people would
> > have saved far more DASD space with intelligent choice of block size
> > than the miniscule amount they saved by truncating the year.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> > behalf of Joel C. Ewing [jcew...@acm.org]
> > Sent: Wednesday, April 22, 2020 3:12 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Here we go again;
> >
> > Should we presume you didn't work on mainframes prior to the advent
> > of cheap memory and cheap RAID DASD in TB chunks?
> >
> > Even after advent of 3380,  3390, and even native 3390-3, drives our
> > company didn't lease DASD drives without doing cost analysis.  In
> > late 1970's and early 1980's we were on 3330's and later 3350's,
> > where physical constraints were also an issue -- when I started as
> > SysProg in 1978, the computer room was maxed out space-wise at 29
> > 3330 drives, or only 2.9GB total DASD space.  We didn't have DASD
> > sitting around that wasn't 95% or more utilized.  Batch jobs
> > typically got one dedicated
> > 3330 DASD work volume that they could allocate only for the duration
> > of the job stream, staging data from/to tape as necessary to fit and
> > to preserve for next  job-stream run.  It wasn't until 1995 and
> > beyond, that it finally made economic sense for us to acquire DASD
> > capacity a year or two before we might actually be able to justify a need.
> >
> > Our company believed in investing more money in people to retain
> > good IT personnel rather than throwing money at hardware.  That
> > mind-set was one of the reasons why of the  50 some-odd companies in
> > that line of business in 1950, of the 3 still in business in 2000, one was 
> > ours.
> >
> > Saving one or two bytes per date field in that kind of environment
> > was not "marketing nonsense".  By performance tuning and efficient
> > application design we consistently delayed the need for a DASD or
> > processor upgrades, resulting in *considerable* monetary savings
> > over decades.  You don't "waste" DASD or memory space just because
> > it's available at the time without first considering the long-term
> > impact on future upgrades.  A "good" programmer/analyst was trained
> > to err on the side of conserving resources.
> >
> > You can't judge decisions of the past without first understanding
> > the cost, physical space, memory, and I/O configuration constraints
> > under which those decisions were 

Re: [External] Re: Here we go again;

[Gerhard adam]

  
  
  

So you agree that poor Blocksizes give rise to poor disk usage?
As to space allocations, I’m sorry but for as many problems as you’re 
describing the staff couldn’t have been that serious.  
If management was as serious as being claimed there would have been no problem. 
 Yet I find that few people understand blocking.  They invariably get it wrong 
with load modules, VSAM, ISAM (in the old days) and BDAM.  Come to think of it, 
this only applies to sequential files.  
As for incompetent programmers?   Spare me the exaggerations.  Even today, few 
people understand it and most get it wrong when assuming that half-track 
blocking is optimum when other than sequential files are considered 



Get Outlook for iOS

  




On Wed, Apr 22, 2020 at 4:11 PM -0700, "Gibney, Dave"  wrote:










Full volumes due to excessive space wasted due to crap blksizes had everything 
to do with x37 abends. I am sorry that your experience included so many 
incompetent programmers.  Mine did care, and my management cared more. Before 
SDB, it was a periodic take for me to review and clean DASD, fix BLKSIZES, Etc. 
In that era, I was cheaper the STOPX37. I'm not cheaper today.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gerhard adam
> Sent: Wednesday, April 22, 2020 3:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [External] Re: Here we go again;
> 
> 
> 
> 
> 
>   X37 abends have nothing to do with block sizes Furthermore the role
> of secondary space allocations was so bad among programmers that many
> installations installed a vendor product called STOPX37 because it was easier
> then actual planning and calculating space.
> 
> 
> 
>   Get Outlook for iOS
> 
> 
> 
> 
> 
> 
> On Wed, Apr 22, 2020 at 3:35 PM -0700, "Seymour J Metz"
>  wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kilobytes? Not unless you started on a 305 or 650. Even on the 650 it was
> 6,000,000 digits. The disks on the 1401 and 7000 series were somewhat larger,
> even before the 1301, and the 2311 larger still. Only the 1130 was close to 
> the
> 650's mere megabyte.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg
> BY0HMszNaDT!5_-I8aqsL8R5a9A-
> Z5U0vXKBJCfgDQPHsOlqGSGWCHFohipMYPShrUZqJpXBag$
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Pommier, Rex [rpomm...@sfgmembers.com]
> Sent: Wednesday, April 22, 2020 3:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [External] Re: Here we go again;
> 
> Agreed.  Another thing to remember was that we were dealing with disk
> volumes measured in kilobytes or megabytes instead of terabytes.  In
> addition, the site I cut my teeth on had all removable disk packs that got
> rotated onto the drives for processing of each application.  Every byte saved
> per record gave us the better chance of fitting the entire set of datasets on 
> a
> single disk set so we could process it.
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
> Sent: Wednesday, April 22, 2020 12:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: Here we go again;
> 
> Faulty logic there. A byte here and byte there and pretty soon you have to
> buy ANOTHER unit of DASD. It costs the same empty or full, but if it gets
> nearly full you have to pay for another.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Gerhard adam
> Sent: Wednesday, April 22, 2020 10:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again;
> 
> 
> 
> 
> 
> The notion of “savings” was marketing nonsense.  The DASD was paid for
> regardless of whether it held a production database or someone’s golf
> handicap.
> It cost the same whether it was empty or full.  The notion of “saving” was
> nonsense and even under the best of circumstances could only be deferred
> expenses
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> The information contained in this message is confidential, protected from
> disclosure and may be legally privileged.  If the reader of this message is 
> not
> the intended recipient or an employee or agent responsible for delivering
> this message to the intended recipient, you are hereby notified that any
> disclosure, distribution, copying, or any action taken or action omitted in
> reliance on it, is strictly prohibited and may be unlawful.  If you have 
> received
> this communication in error, please notify us immediately by replying to this
> message and destroy the material in its entirety, whether in electronic or
> hard copy format.  Thank you.
> 
> 
> 

Re: Here we go again;

[Lennie Dymoke-Bradshaw]

How did you delete the files if you were not allowed to logon?

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd  
Web:  www.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Wayne Bickerdike
Sent: 22 April 2020 21:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Here we go again;

We had constraints at IBM when I worked there in 1978. The TSO logon procedure 
checked your personal space allocation. If you had more then 150 tracks 
allocated you had to delete some files to log on. At the time we were limited 
to 30 minutes a session to allow other programmers to get some "time sharing". 
Space saving isn't  wasted effort. I had to fit applications on Z80 kit onto 2 
110k floppy disks. As a kid, we sliced up a MARS bar.

On Thu, Apr 23, 2020, 06:00 scott Ford  wrote:

> David,
>
> I laugh at these comments/observations. Early days 70-80s System 
> Programmers like myself helped programmers determine blocksize and 
> dataset location, etc.  and then DBAs were born or made and then the 
> system optimized.
>
> Evolution
>
> Scott
>
> On Wed, Apr 22, 2020 at 3:44 PM Seymour J Metz  wrote:
>
> > My first computer had a 2,000 word drum, a 60 word core memory, a 
> > 600,000 word disk drive and two tape drives. I may have been a tad 
> > more
> constrained
> > than you were when you started. I agree with Mr. Adam; people would 
> > have saved far more DASD space with intelligent choice of block size 
> > than the miniscule amount they saved by truncating the year.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
> > behalf of Joel C. Ewing [jcew...@acm.org]
> > Sent: Wednesday, April 22, 2020 3:12 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Here we go again;
> >
> > Should we presume you didn't work on mainframes prior to the advent 
> > of cheap memory and cheap RAID DASD in TB chunks?
> >
> > Even after advent of 3380,  3390, and even native 3390-3, drives our 
> > company didn't lease DASD drives without doing cost analysis.  In 
> > late 1970's and early 1980's we were on 3330's and later 3350's, 
> > where physical constraints were also an issue -- when I started as 
> > SysProg in 1978, the computer room was maxed out space-wise at 29 
> > 3330 drives, or only 2.9GB total DASD space.  We didn't have DASD 
> > sitting around that wasn't 95% or more utilized.  Batch jobs 
> > typically got one dedicated
> > 3330 DASD work volume that they could allocate only for the duration 
> > of the job stream, staging data from/to tape as necessary to fit and 
> > to preserve for next  job-stream run.  It wasn't until 1995 and 
> > beyond, that it finally made economic sense for us to acquire DASD 
> > capacity a year or two before we might actually be able to justify a need.
> >
> > Our company believed in investing more money in people to retain 
> > good IT personnel rather than throwing money at hardware.  That 
> > mind-set was one of the reasons why of the  50 some-odd companies in 
> > that line of business in 1950, of the 3 still in business in 2000, one was 
> > ours.
> >
> > Saving one or two bytes per date field in that kind of environment 
> > was not "marketing nonsense".  By performance tuning and efficient 
> > application design we consistently delayed the need for a DASD or 
> > processor upgrades, resulting in *considerable* monetary savings 
> > over decades.  You don't "waste" DASD or memory space just because 
> > it's available at the time without first considering the long-term 
> > impact on future upgrades.  A "good" programmer/analyst was trained 
> > to err on the side of conserving resources.
> >
> > You can't judge decisions of the past without first understanding 
> > the cost, physical space, memory, and I/O configuration constraints 
> > under which those decisions were made.  Unlike now where where easy 
> > incremental upgrades are possible, back then every upgrade, assuming 
> > one was possible,  involved a substantial cost increase.
> > JC Ewing
> >
> > On 4/22/20 12:05 PM, Gerhard adam wrote:
> > >
> > >
> > >
> > >
> > >   The notion of “savings” was marketing nonsense.  The DASD 
> > > was
> paid
> > for regardless of whether it held a production database or someone’s 
> > golf handicap.
> > > It cost the same whether it was empty or full.  The notion of “saving”
> > was nonsense and even under the best of circumstances could only be 
> > deferred expenses
> > >
> > >
> > >
> > >   Get Outlook for iOS
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel" <
> > dspiegel...@hotmail.com> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > It was also the physical size of the dataset.
> > >
> > > On 2020-04-22 12:55, Gibney, 

Re: [External] Re: Here we go again;

[Gibney, Dave]

Full volumes due to excessive space wasted due to crap blksizes had everything 
to do with x37 abends. I am sorry that your experience included so many 
incompetent programmers.  Mine did care, and my management cared more. Before 
SDB, it was a periodic take for me to review and clean DASD, fix BLKSIZES, Etc. 
In that era, I was cheaper the STOPX37. I'm not cheaper today.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gerhard adam
> Sent: Wednesday, April 22, 2020 3:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [External] Re: Here we go again;
> 
> 
> 
> 
> 
>   X37 abends have nothing to do with block sizes Furthermore the role
> of secondary space allocations was so bad among programmers that many
> installations installed a vendor product called STOPX37 because it was easier
> then actual planning and calculating space.
> 
> 
> 
>   Get Outlook for iOS
> 
> 
> 
> 
> 
> 
> On Wed, Apr 22, 2020 at 3:35 PM -0700, "Seymour J Metz"
>  wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kilobytes? Not unless you started on a 305 or 650. Even on the 650 it was
> 6,000,000 digits. The disks on the 1401 and 7000 series were somewhat larger,
> even before the 1301, and the 2311 larger still. Only the 1130 was close to 
> the
> 650's mere megabyte.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg
> BY0HMszNaDT!5_-I8aqsL8R5a9A-
> Z5U0vXKBJCfgDQPHsOlqGSGWCHFohipMYPShrUZqJpXBag$
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Pommier, Rex [rpomm...@sfgmembers.com]
> Sent: Wednesday, April 22, 2020 3:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [External] Re: Here we go again;
> 
> Agreed.  Another thing to remember was that we were dealing with disk
> volumes measured in kilobytes or megabytes instead of terabytes.  In
> addition, the site I cut my teeth on had all removable disk packs that got
> rotated onto the drives for processing of each application.  Every byte saved
> per record gave us the better chance of fitting the entire set of datasets on 
> a
> single disk set so we could process it.
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
> Sent: Wednesday, April 22, 2020 12:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: Here we go again;
> 
> Faulty logic there. A byte here and byte there and pretty soon you have to
> buy ANOTHER unit of DASD. It costs the same empty or full, but if it gets
> nearly full you have to pay for another.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Gerhard adam
> Sent: Wednesday, April 22, 2020 10:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again;
> 
> 
> 
> 
> 
> The notion of “savings” was marketing nonsense.  The DASD was paid for
> regardless of whether it held a production database or someone’s golf
> handicap.
> It cost the same whether it was empty or full.  The notion of “saving” was
> nonsense and even under the best of circumstances could only be deferred
> expenses
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> The information contained in this message is confidential, protected from
> disclosure and may be legally privileged.  If the reader of this message is 
> not
> the intended recipient or an employee or agent responsible for delivering
> this message to the intended recipient, you are hereby notified that any
> disclosure, distribution, copying, or any action taken or action omitted in
> reliance on it, is strictly prohibited and may be unlawful.  If you have 
> received
> this communication in error, please notify us immediately by replying to this
> message and destroy the material in its entirety, whether in electronic or
> hard copy format.  Thank you.
> 
> 
> --
> 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
> 
> 
> 
> 
> 
> 
> --
> 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] Re: Here we go again;

[Gerhard adam]

  
  
  

X37 abends have nothing to do with block sizes 
Furthermore the role of secondary space allocations was so bad among 
programmers that many installations installed a vendor product called STOPX37 
because it was easier then actual planning and calculating space.



Get Outlook for iOS

  




On Wed, Apr 22, 2020 at 3:35 PM -0700, "Seymour J Metz"  wrote:










Kilobytes? Not unless you started on a 305 or 650. Even on the 650 it was 
6,000,000 digits. The disks on the 1401 and 7000 series were somewhat larger, 
even before the 1301, and the 2311 larger still. Only the 1130 was close to the 
650's mere megabyte.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Pommier, Rex [rpomm...@sfgmembers.com]
Sent: Wednesday, April 22, 2020 3:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: Here we go again;

Agreed.  Another thing to remember was that we were dealing with disk volumes 
measured in kilobytes or megabytes instead of terabytes.  In addition, the site 
I cut my teeth on had all removable disk packs that got rotated onto the drives 
for processing of each application.  Every byte saved per record gave us the 
better chance of fitting the entire set of datasets on a single disk set so we 
could process it.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
Sent: Wednesday, April 22, 2020 12:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Here we go again;

Faulty logic there. A byte here and byte there and pretty soon you have to buy 
ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly 
full you have to pay for another.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard adam
Sent: Wednesday, April 22, 2020 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;





The notion of “savings” was marketing nonsense.  The DASD was paid for 
regardless of whether it held a production database or someone’s golf handicap.
It cost the same whether it was empty or full.  The notion of “saving” was 
nonsense and even under the best of circumstances could only be deferred 
expenses

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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






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

Re: Question on dynamic concatenation

[Seymour J Metz]

I would guess the DSAB, but I'd have to chase through the data areas to be sure.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Harminc [t...@harminc.net]
Sent: Wednesday, April 22, 2020 2:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on dynamic concatenation

On Wed, 22 Apr 2020 at 14:33, Seymour J Metz  wrote:
>
> It's the answer to your question: the manual is correct but fails to connect 
> the dots. The dynamic concatenation *does* remove the
> association of the other ddnames, but it does not delete the record that 
> there had previously been such an association, so when
> you deconcatenate it is able to reestablish the association. If, instead, you 
> deallocate, then there is no longer a record of the
> previous allocation.

So is that record of the previous allocation kept in some
private/undocumented place by allocation, or do TIOT entries remain in
place (perhaps flagged somehow) and provide all the necessary info?

Tony H.

--
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] Re: Here we go again;

[Seymour J Metz]

Kilobytes? Not unless you started on a 305 or 650. Even on the 650 it was 
6,000,000 digits. The disks on the 1401 and 7000 series were somewhat larger, 
even before the 1301, and the 2311 larger still. Only the 1130 was close to the 
650's mere megabyte.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Pommier, Rex [rpomm...@sfgmembers.com]
Sent: Wednesday, April 22, 2020 3:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: Here we go again;

Agreed.  Another thing to remember was that we were dealing with disk volumes 
measured in kilobytes or megabytes instead of terabytes.  In addition, the site 
I cut my teeth on had all removable disk packs that got rotated onto the drives 
for processing of each application.  Every byte saved per record gave us the 
better chance of fitting the entire set of datasets on a single disk set so we 
could process it.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Wednesday, April 22, 2020 12:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Here we go again;

Faulty logic there. A byte here and byte there and pretty soon you have to buy 
ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly 
full you have to pay for another.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard adam
Sent: Wednesday, April 22, 2020 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;





The notion of “savings” was marketing nonsense.  The DASD was paid for 
regardless of whether it held a production database or someone’s golf handicap.
It cost the same whether it was empty or full.  The notion of “saving” was 
nonsense and even under the best of circumstances could only be deferred 
expenses

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
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: Here we go again;

[Gibney, Dave]

  We were small, even then. Bu, it was in the programmers interest to avoid x#7 
abends. And, for a time, I had authority o make the required JCL changes for 
SPACE and BLKSIZE myself. Mos programmers would approve the change if they 
didn't need to do it themselves. 
  On of the Adabas files I did 8 digit and the DBA insited on fullword vs. 
packed had something like 8 or 10 date fields. If I remember correctly, some of 
those were in periodic groups of potentially 40 or 50 per record. 

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Seymour J Metz
> Sent: Wednesday, April 22, 2020 3:05 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again;
> 
> Maybe at your shop people were more on the ball, or you had the authority
> to force them to listen, but in the shops I know of every man had his own
> fiefdom and did things his way. It's not the techies who call the shots, with
> few exceptions.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg
> BY0HMszNaDT!9YcE6wIyzskPUXdoKFo237FSi0w6UDz6RplYVBhp5h_mk7wgAI
> D06JMnJb0r0w$
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of scott Ford [idfli...@gmail.com]
> Sent: Wednesday, April 22, 2020 3:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again;
> 
> David,
> 
> I laugh at these comments/observations. Early days 70-80s System
> Programmers like myself helped programmers determine blocksize and
> dataset location, etc.  and then DBAs were born or made and then the
> system optimized.
> 
> Evolution
> 
> Scott
> 
> On Wed, Apr 22, 2020 at 3:44 PM Seymour J Metz 
> wrote:
> 
> > My first computer had a 2,000 word drum, a 60 word core memory, a
> > 600,000 word disk drive and two tape drives. I may have been a tad
> > more constrained than you were when you started. I agree with Mr.
> > Adam; people would have saved far more DASD space with intelligent
> > choice of block size than the miniscule amount they saved by truncating the
> year.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> >
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg
> BY
> >
> 0HMszNaDT!9YcE6wIyzskPUXdoKFo237FSi0w6UDz6RplYVBhp5h_mk7wgAID0
> 6JMnJb0r
> > 0w$
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> > behalf of Joel C. Ewing [jcew...@acm.org]
> > Sent: Wednesday, April 22, 2020 3:12 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Here we go again;
> >
> > Should we presume you didn't work on mainframes prior to the advent of
> > cheap memory and cheap RAID DASD in TB chunks?
> >
> > Even after advent of 3380,  3390, and even native 3390-3, drives our
> > company didn't lease DASD drives without doing cost analysis.  In late
> > 1970's and early 1980's we were on 3330's and later 3350's, where
> > physical constraints were also an issue -- when I started as SysProg
> > in 1978, the computer room was maxed out space-wise at 29 3330 drives,
> > or only 2.9GB total DASD space.  We didn't have DASD sitting around
> > that wasn't 95% or more utilized.  Batch jobs typically got one
> > dedicated
> > 3330 DASD work volume that they could allocate only for the duration
> > of the job stream, staging data from/to tape as necessary to fit and
> > to preserve for next  job-stream run.  It wasn't until 1995 and
> > beyond, that it finally made economic sense for us to acquire DASD
> > capacity a year or two before we might actually be able to justify a need.
> >
> > Our company believed in investing more money in people to retain good
> > IT personnel rather than throwing money at hardware.  That mind-set
> > was one of the reasons why of the  50 some-odd companies in that line
> > of business in 1950, of the 3 still in business in 2000, one was ours.
> >
> > Saving one or two bytes per date field in that kind of environment was
> > not "marketing nonsense".  By performance tuning and efficient
> > application design we consistently delayed the need for a DASD or
> > processor upgrades, resulting in *considerable* monetary savings over
> > decades.  You don't "waste" DASD or memory space just because it's
> > available at the time without first considering the long-term impact
> > on future upgrades.  A "good" programmer/analyst was trained to err on
> > the side of conserving resources.
> >
> > You can't judge decisions of the past without first understanding the
> > cost, physical space, memory, and I/O configuration constraints under
> > which those decisions were made.  Unlike now where where easy
> > incremental upgrades are possible, back then every upgrade, assuming
> > one was possible,  involved a substantial cost increase.
> > JC Ewing
> >
> > On 4/22/20 12:05 PM, Gerhard adam wrote:
> > >
> > >
> > >
> > >
> > >   The notion of "savings" was marketing nonsense.  The DASD was
> > > paid
> > for 

Re: [External] Re: Here we go again;

[Seymour J Metz]

Yes, in the OS/360 era and the early MVS days the Link Editor imposed a 
restriction on *SYSLIN*, but that doesn't explain the hard wired block sizes 
for things other than object decks. Nor does it justify leaving the procedures 
that way after the restriction was lifted. 

If nobody cares about space wasted by a poor choice of block size, why would 
they care about a much smaller amount of space consumed to avoid the need for 
future changes?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Spiegel [dspiegel...@hotmail.com]
Sent: Wednesday, April 22, 2020 3:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: Here we go again;

The 3200 Maximum Blocksize used to be a Linkage Editor restriction.
Also, better JCL does not pay dividends for any software vendor. As long
as the old stuff works, nobody cares that it has been around since 2314s
and 2319s.

On 2020-04-22 15:34, Seymour J Metz wrote:
> Well, I used a DCB exit to select a block size if none was provided. OTOH, I 
> kept seeing IBM procedures with 3200 long after that was too small.
>
>
> --
> Shmuel (Seymour J.) Metz
> https://eur05.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7Cfe4606446a024ce1ef3f08d7e6f42b0f%7C84df9e7fe9f640afb435%7C1%7C0%7C637231808688902735sdata=GUKRdPCZgletvLmWTX8AsrOEwexm2Ictr2aFQRNdU%2B0%3Dreserved=0
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Gerhard adam [gada...@charter.net]
> Sent: Wednesday, April 22, 2020 3:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [External] Re: Here we go again;
>
>  ... and so goes the mythology.  The truth is that programmers 
> routinely used lousy block sizes and wastes tremendous amounts of space.  JCL 
> sizes were rarely scrutinized nor was data set usage.  It was entirely 
> possible for test data to exist for weeks or months beyond its usefulness
> This isn’t to say that money was obviousness spent and even wasted, but few 
> installations took managing their DASD seriously.  They would worry about 
> saving a byte by packing a date while wasting 100 tracks due to poor blocking.
> This is why nothing really happened until System Determined Blocksize, and 
> the Storage Administrator tools became available.
> People certainly wrung their hands but rarely did anything about it
>
>
>
>  Get Outlook for iOS
>
>
>
>
>
>
> On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex" 
>  wrote:
>
>
>
>
>
>
>
>
>
>
> Agreed.  Another thing to remember was that we were dealing with disk volumes 
> measured in kilobytes or megabytes instead of terabytes.  In addition, the 
> site I cut my teeth on had all removable disk packs that got rotated onto the 
> drives for processing of each application.  Every byte saved per record gave 
> us the better chance of fitting the entire set of datasets on a single disk 
> set so we could process it.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
> Sent: Wednesday, April 22, 2020 12:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: Here we go again;
>
> Faulty logic there. A byte here and byte there and pretty soon you have to 
> buy ANOTHER unit of DASD. It costs the same empty or full, but if it gets 
> nearly full you have to pay for another.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Gerhard adam
> Sent: Wednesday, April 22, 2020 10:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again;
>
>
>
>
>
>  The notion of “savings” was marketing nonsense.  The DASD was paid 
> for regardless of whether it held a production database or someone’s golf 
> handicap.
> It cost the same whether it was empty or full.  The notion of “saving” was 
> nonsense and even under the best of circumstances could only be deferred 
> expenses
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> The information contained in this message is confidential, protected from 
> disclosure and may be legally privileged.  If the reader of this message is 
> not the intended recipient or an employee or agent responsible for delivering 
> this message to the intended recipient, you are hereby notified that any 
> disclosure, distribution, copying, or any action taken or action omitted in 
> reliance on it, is strictly prohibited and may be unlawful.  If you have 
> received this communication in error, please notify us immediately by 
> replying to this message and destroy the material in its entirety, whether in 
> electronic or hard copy format.  Thank 

Re: Here we go again;

[Seymour J Metz]

Maybe at your shop people were more on the ball, or you had the authority to 
force them to listen, but in the shops I know of every man had his own fiefdom 
and did things his way. It's not the techies who call the shots, with few 
exceptions.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
scott Ford [idfli...@gmail.com]
Sent: Wednesday, April 22, 2020 3:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

David,

I laugh at these comments/observations. Early days 70-80s System
Programmers like myself helped programmers determine blocksize and dataset
location, etc.  and then DBAs were born or made and then the system
optimized.

Evolution

Scott

On Wed, Apr 22, 2020 at 3:44 PM Seymour J Metz  wrote:

> My first computer had a 2,000 word drum, a 60 word core memory, a 600,000
> word disk drive and two tape drives. I may have been a tad more constrained
> than you were when you started. I agree with Mr. Adam; people would have
> saved far more DASD space with intelligent choice of block size than the
> miniscule amount they saved by truncating the year.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Joel C. Ewing [jcew...@acm.org]
> Sent: Wednesday, April 22, 2020 3:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again;
>
> Should we presume you didn't work on mainframes prior to the advent of
> cheap memory and cheap RAID DASD in TB chunks?
>
> Even after advent of 3380,  3390, and even native 3390-3, drives our
> company didn't lease DASD drives without doing cost analysis.  In late
> 1970's and early 1980's we were on 3330's and later 3350's, where
> physical constraints were also an issue -- when I started as SysProg in
> 1978, the computer room was maxed out space-wise at 29 3330 drives, or
> only 2.9GB total DASD space.  We didn't have DASD sitting around that
> wasn't 95% or more utilized.  Batch jobs typically got one dedicated
> 3330 DASD work volume that they could allocate only for the duration of
> the job stream, staging data from/to tape as necessary to fit and to
> preserve for next  job-stream run.  It wasn't until 1995 and beyond,
> that it finally made economic sense for us to acquire DASD capacity a
> year or two before we might actually be able to justify a need.
>
> Our company believed in investing more money in people to retain good IT
> personnel rather than throwing money at hardware.  That mind-set was one
> of the reasons why of the  50 some-odd companies in that line of
> business in 1950, of the 3 still in business in 2000, one was ours.
>
> Saving one or two bytes per date field in that kind of environment was
> not "marketing nonsense".  By performance tuning and efficient
> application design we consistently delayed the need for a DASD or
> processor upgrades, resulting in *considerable* monetary savings over
> decades.  You don't "waste" DASD or memory space just because it's
> available at the time without first considering the long-term impact on
> future upgrades.  A "good" programmer/analyst was trained to err on the
> side of conserving resources.
>
> You can't judge decisions of the past without first understanding the
> cost, physical space, memory, and I/O configuration constraints under
> which those decisions were made.  Unlike now where where easy
> incremental upgrades are possible, back then every upgrade, assuming one
> was possible,  involved a substantial cost increase.
> JC Ewing
>
> On 4/22/20 12:05 PM, Gerhard adam wrote:
> >
> >
> >
> >
> >   The notion of “savings” was marketing nonsense.  The DASD was paid
> for regardless of whether it held a production database or someone’s golf
> handicap.
> > It cost the same whether it was empty or full.  The notion of “saving”
> was nonsense and even under the best of circumstances could only be
> deferred expenses
> >
> >
> >
> >   Get Outlook for iOS
> >
> >
> >
> >
> >
> >
> > On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel" <
> dspiegel...@hotmail.com> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > It was also the physical size of the dataset.
> >
> > On 2020-04-22 12:55, Gibney, Dave wrote:
> >> In the 80's a byte of DASD savings could be thousands of dollars.
> >>
> >>> -Original Message-
> >>> From: IBM Mainframe Discussion List  On
> >>> Behalf Of Phil Smith III
> >>> Sent: Wednesday, April 22, 2020 9:12 AM
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: Re: Here we go again;
> >>>
> >>> As others have suggested, many companies do still have SSNs stored as
> >>> packed decimal. So sure, a namespace expansion is possible, but it's a
> bigger
> >>> change than one might think, however it's done. I've even seen at
> least one
> >>> company who stored them as binary! I sure 

Re: Here we go again;

[Seymour J Metz]

Never attribute to a lapse of memory what can be explained by never having 
known.

No, it doesn't matter how many times you tried to tell them.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Gerhard adam [gada...@charter.net]
Sent: Wednesday, April 22, 2020 4:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

There also seems to be a lapse in memory regarding the reference cards 
provided by IBM for the various model DASD is where one could look up the 
record size and view the table for the recommended Blocksize.
In addition these cards also provided the detailed calculations/equations to 
determine these values without looking them up



Get Outlook for iOS






On Wed, Apr 22, 2020 at 1:00 PM -0700, "scott Ford"  wrote:










David,

I laugh at these comments/observations. Early days 70-80s System
Programmers like myself helped programmers determine blocksize and dataset
location, etc.  and then DBAs were born or made and then the system
optimized.

Evolution

Scott

On Wed, Apr 22, 2020 at 3:44 PM Seymour J Metz  wrote:

> My first computer had a 2,000 word drum, a 60 word core memory, a 600,000
> word disk drive and two tape drives. I may have been a tad more constrained
> than you were when you started. I agree with Mr. Adam; people would have
> saved far more DASD space with intelligent choice of block size than the
> miniscule amount they saved by truncating the year.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Joel C. Ewing [jcew...@acm.org]
> Sent: Wednesday, April 22, 2020 3:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again;
>
> Should we presume you didn't work on mainframes prior to the advent of
> cheap memory and cheap RAID DASD in TB chunks?
>
> Even after advent of 3380,  3390, and even native 3390-3, drives our
> company didn't lease DASD drives without doing cost analysis.  In late
> 1970's and early 1980's we were on 3330's and later 3350's, where
> physical constraints were also an issue -- when I started as SysProg in
> 1978, the computer room was maxed out space-wise at 29 3330 drives, or
> only 2.9GB total DASD space.  We didn't have DASD sitting around that
> wasn't 95% or more utilized.  Batch jobs typically got one dedicated
> 3330 DASD work volume that they could allocate only for the duration of
> the job stream, staging data from/to tape as necessary to fit and to
> preserve for next  job-stream run.  It wasn't until 1995 and beyond,
> that it finally made economic sense for us to acquire DASD capacity a
> year or two before we might actually be able to justify a need.
>
> Our company believed in investing more money in people to retain good IT
> personnel rather than throwing money at hardware.  That mind-set was one
> of the reasons why of the  50 some-odd companies in that line of
> business in 1950, of the 3 still in business in 2000, one was ours.
>
> Saving one or two bytes per date field in that kind of environment was
> not "marketing nonsense".  By performance tuning and efficient
> application design we consistently delayed the need for a DASD or
> processor upgrades, resulting in *considerable* monetary savings over
> decades.  You don't "waste" DASD or memory space just because it's
> available at the time without first considering the long-term impact on
> future upgrades.  A "good" programmer/analyst was trained to err on the
> side of conserving resources.
>
> You can't judge decisions of the past without first understanding the
> cost, physical space, memory, and I/O configuration constraints under
> which those decisions were made.  Unlike now where where easy
> incremental upgrades are possible, back then every upgrade, assuming one
> was possible,  involved a substantial cost increase.
> JC Ewing
>
> On 4/22/20 12:05 PM, Gerhard adam wrote:
> >
> >
> >
> >
> >   The notion of “savings” was marketing nonsense.  The DASD was paid
> for regardless of whether it held a production database or someone’s golf
> handicap.
> > It cost the same whether it was empty or full.  The notion of “saving”
> was nonsense and even under the best of circumstances could only be
> deferred expenses
> >
> >
> >
> >   Get Outlook for iOS
> >
> >
> >
> >
> >
> >
> > On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel" <
> dspiegel...@hotmail.com> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > It was also the physical size of the dataset.
> >
> > On 2020-04-22 12:55, Gibney, Dave wrote:
> >> In the 80's a byte of DASD savings could be thousands of dollars.
> >>
> >>> -Original Message-
> >>> From: IBM Mainframe Discussion List  On
> >>> Behalf Of Phil Smith III
> >>> Sent: Wednesday, April 22, 2020 9:12 AM
> >>> To: 

Re: Here we go again;

[Seymour J Metz]

There is no on saving on forms, printer lines, punched cards, data entry 
screens or data entry key strokes. You input two digits, store four digits and 
print two digits.  


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Clark Morris [cfmt...@uniserve.com]
Sent: Wednesday, April 22, 2020 4:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

[Default] On 22 Apr 2020 12:44:41 -0700, in bit.listserv.ibm-main
sme...@gmu.edu (Seymour J Metz) wrote:

>My first computer had a 2,000 word drum, a 60 word core memory, a 600,000 word 
>disk drive and two tape drives. I may have been a tad more constrained than 
>you were when you started. I agree with Mr. Adam; people would have saved far 
>more DASD space with intelligent choice of block size than the miniscule 
>amount they saved by truncating the year.

In reviewing this discussion, I suddenly realized that the saving by
using 2 digit years was not just disk and tape space but also on
forms, printer lines, punched cards, data entry screens and data entry
key strokes.  I know that in many cases I was scrambling for space on
print lines.

Clark Morris
>
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>Joel C. Ewing [jcew...@acm.org]
>Sent: Wednesday, April 22, 2020 3:12 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Here we go again;
>
>Should we presume you didn't work on mainframes prior to the advent of
>cheap memory and cheap RAID DASD in TB chunks?
>
>Even after advent of 3380,  3390, and even native 3390-3, drives our
>company didn't lease DASD drives without doing cost analysis.  In late
>1970's and early 1980's we were on 3330's and later 3350's, where
>physical constraints were also an issue -- when I started as SysProg in
>1978, the computer room was maxed out space-wise at 29 3330 drives, or
>only 2.9GB total DASD space.  We didn't have DASD sitting around that
>wasn't 95% or more utilized.  Batch jobs typically got one dedicated
>3330 DASD work volume that they could allocate only for the duration of
>the job stream, staging data from/to tape as necessary to fit and to
>preserve for next  job-stream run.  It wasn't until 1995 and beyond,
>that it finally made economic sense for us to acquire DASD capacity a
>year or two before we might actually be able to justify a need.
>
>Our company believed in investing more money in people to retain good IT
>personnel rather than throwing money at hardware.  That mind-set was one
>of the reasons why of the  50 some-odd companies in that line of
>business in 1950, of the 3 still in business in 2000, one was ours.
>
>Saving one or two bytes per date field in that kind of environment was
>not "marketing nonsense".  By performance tuning and efficient
>application design we consistently delayed the need for a DASD or
>processor upgrades, resulting in *considerable* monetary savings over
>decades.  You don't "waste" DASD or memory space just because it's
>available at the time without first considering the long-term impact on
>future upgrades.  A "good" programmer/analyst was trained to err on the
>side of conserving resources.
>
>You can't judge decisions of the past without first understanding the
>cost, physical space, memory, and I/O configuration constraints under
>which those decisions were made.  Unlike now where where easy
>incremental upgrades are possible, back then every upgrade, assuming one
>was possible,  involved a substantial cost increase.
>JC Ewing
>
>On 4/22/20 12:05 PM, Gerhard adam wrote:
>>
>>
>>
>>
>>   The notion of “savings” was marketing nonsense.  The DASD was paid for 
>> regardless of whether it held a production database or someone’s golf 
>> handicap.
>> It cost the same whether it was empty or full.  The notion of “saving” was 
>> nonsense and even under the best of circumstances could only be deferred 
>> expenses
>>
>>
>>
>>   Get Outlook for iOS
>>
>>
>>
>>
>>
>>
>> On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel" 
>>  wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> It was also the physical size of the dataset.
>>
>> On 2020-04-22 12:55, Gibney, Dave wrote:
>>> In the 80's a byte of DASD savings could be thousands of dollars.
>>>
 -Original Message-
 From: IBM Mainframe Discussion List  On
 Behalf Of Phil Smith III
 Sent: Wednesday, April 22, 2020 9:12 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Here we go again;

 As others have suggested, many companies do still have SSNs stored as
 packed decimal. So sure, a namespace expansion is possible, but it's a 
 bigger
 change than one might think, however it's done. I've even seen at least one
 company who stored them as binary! I sure hope someone got a big bonus
 for saving that byte...

Re: Here we go again;

[Paul Gilmartin]

On Wed, 22 Apr 2020 17:35:01 -0300, Clark Morris wrote:
>
>In reviewing this discussion, I suddenly realized that the saving by
>using 2 digit years was not just disk and tape space but also on
>forms, printer lines, punched cards, data entry screens and data entry
>key strokes.  I know that in many cases I was scrambling for space on
>print lines. 
> 
But that concerns presentation, not storage.  You could as well store
TOD clock values and let the output formatting routine display
4, 2, or even single digit years.

Circa 1997, I visited a cemetery where some (spouses') dates were
pre-engraved such as 1920-19__.

Circa 1951, I watched someone write a check where the date was
preprinted 195_.

-- gil

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

Re: Here we go again;

[Clark Morris]

[Default] On 22 Apr 2020 12:44:41 -0700, in bit.listserv.ibm-main
sme...@gmu.edu (Seymour J Metz) wrote:

>My first computer had a 2,000 word drum, a 60 word core memory, a 600,000 word 
>disk drive and two tape drives. I may have been a tad more constrained than 
>you were when you started. I agree with Mr. Adam; people would have saved far 
>more DASD space with intelligent choice of block size than the miniscule 
>amount they saved by truncating the year.

In reviewing this discussion, I suddenly realized that the saving by
using 2 digit years was not just disk and tape space but also on
forms, printer lines, punched cards, data entry screens and data entry
key strokes.  I know that in many cases I was scrambling for space on
print lines. 

Clark Morris
>
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>Joel C. Ewing [jcew...@acm.org]
>Sent: Wednesday, April 22, 2020 3:12 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Here we go again;
>
>Should we presume you didn't work on mainframes prior to the advent of
>cheap memory and cheap RAID DASD in TB chunks?
>
>Even after advent of 3380,  3390, and even native 3390-3, drives our
>company didn't lease DASD drives without doing cost analysis.  In late
>1970's and early 1980's we were on 3330's and later 3350's, where
>physical constraints were also an issue -- when I started as SysProg in
>1978, the computer room was maxed out space-wise at 29 3330 drives, or
>only 2.9GB total DASD space.  We didn't have DASD sitting around that
>wasn't 95% or more utilized.  Batch jobs typically got one dedicated
>3330 DASD work volume that they could allocate only for the duration of
>the job stream, staging data from/to tape as necessary to fit and to
>preserve for next  job-stream run.  It wasn't until 1995 and beyond,
>that it finally made economic sense for us to acquire DASD capacity a
>year or two before we might actually be able to justify a need.
>
>Our company believed in investing more money in people to retain good IT
>personnel rather than throwing money at hardware.  That mind-set was one
>of the reasons why of the  50 some-odd companies in that line of
>business in 1950, of the 3 still in business in 2000, one was ours.
>
>Saving one or two bytes per date field in that kind of environment was
>not "marketing nonsense".  By performance tuning and efficient
>application design we consistently delayed the need for a DASD or
>processor upgrades, resulting in *considerable* monetary savings over
>decades.  You don't "waste" DASD or memory space just because it's
>available at the time without first considering the long-term impact on
>future upgrades.  A "good" programmer/analyst was trained to err on the
>side of conserving resources.
>
>You can't judge decisions of the past without first understanding the
>cost, physical space, memory, and I/O configuration constraints under
>which those decisions were made.  Unlike now where where easy
>incremental upgrades are possible, back then every upgrade, assuming one
>was possible,  involved a substantial cost increase.
>JC Ewing
>
>On 4/22/20 12:05 PM, Gerhard adam wrote:
>>
>>
>>
>>
>>   The notion of “savings” was marketing nonsense.  The DASD was paid for 
>> regardless of whether it held a production database or someone’s golf 
>> handicap.
>> It cost the same whether it was empty or full.  The notion of “saving” was 
>> nonsense and even under the best of circumstances could only be deferred 
>> expenses
>>
>>
>>
>>   Get Outlook for iOS
>>
>>
>>
>>
>>
>>
>> On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel" 
>>  wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> It was also the physical size of the dataset.
>>
>> On 2020-04-22 12:55, Gibney, Dave wrote:
>>> In the 80's a byte of DASD savings could be thousands of dollars.
>>>
 -Original Message-
 From: IBM Mainframe Discussion List  On
 Behalf Of Phil Smith III
 Sent: Wednesday, April 22, 2020 9:12 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Here we go again;

 As others have suggested, many companies do still have SSNs stored as
 packed decimal. So sure, a namespace expansion is possible, but it's a 
 bigger
 change than one might think, however it's done. I've even seen at least one
 company who stored them as binary! I sure hope someone got a big bonus
 for saving that byte...





 Peter Farley wrote:

> There are also many non-human entities like corporations that use the
 same SSN value space.



> There are a LOT of those . . . and they spring up and fade away at a rate 
> far
 higher than human births and deaths.



 They use the same namespace--that is, if your SSN is 123-45-6789, an estate
 or business could also have that number. Since they're uses for different
 

Re: [External] Re: Here we go again;

[Pommier, Rex]

Not sure what "several models of 3380" has to do with me.  We had 3380-D drives 
and the room was full of them so we didn't have room to add more.  Once we did 
start replacing them, we went to the 9343 subsystem and bought lots of floor 
space back.  Also, my comment was for my pre-3380 days when the drives were 
10-25 MB per volume and I didn't say we only saved 1 byte per track.  My words 
were "every byte saved per record".  

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gerhard adam
Sent: Wednesday, April 22, 2020 2:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: Here we go again;

  
  
  

Sorry, but “several models of 3380”? If  3380k held almost 2GB per 
module and you saved one byte per record, then you saved the one byte over 2 
billion records to save just one 3380K’s worth of data.  Forgive me for being 
skeptical



Get Outlook for iOS

  




On Wed, Apr 22, 2020 at 12:34 PM -0700, "Pommier, Rex" 
 wrote:










Sorry, we'll have to agree to disagree.  It wasn't mythology at my places of 
business.  When I was in application development, disk and other resource 
efficiency was of paramount concern and when I moved into systems programming I 
got to be the one going to the developers and making sure they didn't use bad 
blocking.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Gerhard adam
Sent: Wednesday, April 22, 2020 2:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: Here we go again;

  
  
  

... and so goes the mythology.  The truth is that programmers routinely 
used lousy block sizes and wastes tremendous amounts of space.  JCL sizes were 
rarely scrutinized nor was data set usage.  It was entirely possible for test 
data to exist for weeks or months beyond its usefulness This isn’t to say that 
money was obviousness spent and even wasted, but few installations took 
managing their DASD seriously.  They would worry about saving a byte by packing 
a date while wasting 100 tracks due to poor blocking.
This is why nothing really happened until System Determined Blocksize, and the 
Storage Administrator tools became available. People certainly wrung their 
hands but rarely did anything about it 



Get Outlook for iOS

  




On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex"  wrote:










Agreed.  Another thing to remember was that we were dealing with disk volumes 
measured in kilobytes or megabytes instead of terabytes.  In addition, the site 
I cut my teeth on had all removable disk packs that got rotated onto the drives 
for processing of each application.  Every byte saved per record gave us the 
better chance of fitting the entire set of datasets on a single disk set so we 
could process it.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
Sent: Wednesday, April 22, 2020 12:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Here we go again;

Faulty logic there. A byte here and byte there and pretty soon you have to buy 
ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly 
full you have to pay for another.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard adam
Sent: Wednesday, April 22, 2020 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

  
  
  

The notion of “savings” was marketing nonsense.  The DASD was paid for 
regardless of whether it held a production database or someone’s golf handicap.
It cost the same whether it was empty or full.  The notion of “saving” was 
nonsense and even under the best of circumstances could only be deferred 
expenses 

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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






--
For IBM-MAIN 

Re: Linkage editor question: renaming duplicate entry points

[Phil Smith III]

Thanks to all who replied; CHANGE was indeed what I needed!

 


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

Re: [External] Re: Here we go again;

[Pommier, Rex]

Because just like anything else, they occasionally forgot.  We had a product 
(from CA maybe) that would check for bad block sizes that got run on a 
scheduled basis to find the problems and when it did, I got to get them 
corrected.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gerhard adam
Sent: Wednesday, April 22, 2020 2:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: Here we go again;

  
  
  

Why did you have to go to the programmers to make sure they were using 
proper block sizes if this were common practice?



Get Outlook for iOS

  




On Wed, Apr 22, 2020 at 12:34 PM -0700, "Pommier, Rex" 
 wrote:










Sorry, we'll have to agree to disagree.  It wasn't mythology at my places of 
business.  When I was in application development, disk and other resource 
efficiency was of paramount concern and when I moved into systems programming I 
got to be the one going to the developers and making sure they didn't use bad 
blocking.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Gerhard adam
Sent: Wednesday, April 22, 2020 2:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: Here we go again;

  
  
  

... and so goes the mythology.  The truth is that programmers routinely 
used lousy block sizes and wastes tremendous amounts of space.  JCL sizes were 
rarely scrutinized nor was data set usage.  It was entirely possible for test 
data to exist for weeks or months beyond its usefulness This isn’t to say that 
money was obviousness spent and even wasted, but few installations took 
managing their DASD seriously.  They would worry about saving a byte by packing 
a date while wasting 100 tracks due to poor blocking.
This is why nothing really happened until System Determined Blocksize, and the 
Storage Administrator tools became available. People certainly wrung their 
hands but rarely did anything about it 



Get Outlook for iOS

  




On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex"  wrote:










Agreed.  Another thing to remember was that we were dealing with disk volumes 
measured in kilobytes or megabytes instead of terabytes.  In addition, the site 
I cut my teeth on had all removable disk packs that got rotated onto the drives 
for processing of each application.  Every byte saved per record gave us the 
better chance of fitting the entire set of datasets on a single disk set so we 
could process it.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
Sent: Wednesday, April 22, 2020 12:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Here we go again;

Faulty logic there. A byte here and byte there and pretty soon you have to buy 
ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly 
full you have to pay for another.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard adam
Sent: Wednesday, April 22, 2020 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

  
  
  

The notion of “savings” was marketing nonsense.  The DASD was paid for 
regardless of whether it held a production database or someone’s golf handicap.
It cost the same whether it was empty or full.  The notion of “saving” was 
nonsense and even under the best of circumstances could only be deferred 
expenses 

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or 

Re: Here we go again;

[Wayne Bickerdike]

We had constraints at IBM when I worked there in 1978. The TSO logon
procedure checked your personal space allocation. If you had more then 150
tracks allocated you had to delete some files to log on. At the time we
were limited to 30 minutes a session to allow other programmers to get some
"time sharing". Space saving isn't  wasted effort. I had to fit
applications on Z80 kit onto 2 110k floppy disks. As a kid, we sliced up a
MARS bar.

On Thu, Apr 23, 2020, 06:00 scott Ford  wrote:

> David,
>
> I laugh at these comments/observations. Early days 70-80s System
> Programmers like myself helped programmers determine blocksize and dataset
> location, etc.  and then DBAs were born or made and then the system
> optimized.
>
> Evolution
>
> Scott
>
> On Wed, Apr 22, 2020 at 3:44 PM Seymour J Metz  wrote:
>
> > My first computer had a 2,000 word drum, a 60 word core memory, a 600,000
> > word disk drive and two tape drives. I may have been a tad more
> constrained
> > than you were when you started. I agree with Mr. Adam; people would have
> > saved far more DASD space with intelligent choice of block size than the
> > miniscule amount they saved by truncating the year.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> > of Joel C. Ewing [jcew...@acm.org]
> > Sent: Wednesday, April 22, 2020 3:12 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Here we go again;
> >
> > Should we presume you didn't work on mainframes prior to the advent of
> > cheap memory and cheap RAID DASD in TB chunks?
> >
> > Even after advent of 3380,  3390, and even native 3390-3, drives our
> > company didn't lease DASD drives without doing cost analysis.  In late
> > 1970's and early 1980's we were on 3330's and later 3350's, where
> > physical constraints were also an issue -- when I started as SysProg in
> > 1978, the computer room was maxed out space-wise at 29 3330 drives, or
> > only 2.9GB total DASD space.  We didn't have DASD sitting around that
> > wasn't 95% or more utilized.  Batch jobs typically got one dedicated
> > 3330 DASD work volume that they could allocate only for the duration of
> > the job stream, staging data from/to tape as necessary to fit and to
> > preserve for next  job-stream run.  It wasn't until 1995 and beyond,
> > that it finally made economic sense for us to acquire DASD capacity a
> > year or two before we might actually be able to justify a need.
> >
> > Our company believed in investing more money in people to retain good IT
> > personnel rather than throwing money at hardware.  That mind-set was one
> > of the reasons why of the  50 some-odd companies in that line of
> > business in 1950, of the 3 still in business in 2000, one was ours.
> >
> > Saving one or two bytes per date field in that kind of environment was
> > not "marketing nonsense".  By performance tuning and efficient
> > application design we consistently delayed the need for a DASD or
> > processor upgrades, resulting in *considerable* monetary savings over
> > decades.  You don't "waste" DASD or memory space just because it's
> > available at the time without first considering the long-term impact on
> > future upgrades.  A "good" programmer/analyst was trained to err on the
> > side of conserving resources.
> >
> > You can't judge decisions of the past without first understanding the
> > cost, physical space, memory, and I/O configuration constraints under
> > which those decisions were made.  Unlike now where where easy
> > incremental upgrades are possible, back then every upgrade, assuming one
> > was possible,  involved a substantial cost increase.
> > JC Ewing
> >
> > On 4/22/20 12:05 PM, Gerhard adam wrote:
> > >
> > >
> > >
> > >
> > >   The notion of “savings” was marketing nonsense.  The DASD was
> paid
> > for regardless of whether it held a production database or someone’s golf
> > handicap.
> > > It cost the same whether it was empty or full.  The notion of “saving”
> > was nonsense and even under the best of circumstances could only be
> > deferred expenses
> > >
> > >
> > >
> > >   Get Outlook for iOS
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel" <
> > dspiegel...@hotmail.com> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > It was also the physical size of the dataset.
> > >
> > > On 2020-04-22 12:55, Gibney, Dave wrote:
> > >> In the 80's a byte of DASD savings could be thousands of dollars.
> > >>
> > >>> -Original Message-
> > >>> From: IBM Mainframe Discussion List  On
> > >>> Behalf Of Phil Smith III
> > >>> Sent: Wednesday, April 22, 2020 9:12 AM
> > >>> To: IBM-MAIN@LISTSERV.UA.EDU
> > >>> Subject: Re: Here we go again;
> > >>>
> > >>> As others have suggested, many companies do still have SSNs stored as
> > >>> packed decimal. So sure, a namespace expansion is 

Re: Here we go again;

[Gerhard adam]

  
  
  

There also seems to be a lapse in memory regarding the reference cards 
provided by IBM for the various model DASD is where one could look up the 
record size and view the table for the recommended Blocksize.
In addition these cards also provided the detailed calculations/equations to 
determine these values without looking them up



Get Outlook for iOS

  




On Wed, Apr 22, 2020 at 1:00 PM -0700, "scott Ford"  wrote:










David,

I laugh at these comments/observations. Early days 70-80s System
Programmers like myself helped programmers determine blocksize and dataset
location, etc.  and then DBAs were born or made and then the system
optimized.

Evolution

Scott

On Wed, Apr 22, 2020 at 3:44 PM Seymour J Metz  wrote:

> My first computer had a 2,000 word drum, a 60 word core memory, a 600,000
> word disk drive and two tape drives. I may have been a tad more constrained
> than you were when you started. I agree with Mr. Adam; people would have
> saved far more DASD space with intelligent choice of block size than the
> miniscule amount they saved by truncating the year.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Joel C. Ewing [jcew...@acm.org]
> Sent: Wednesday, April 22, 2020 3:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again;
>
> Should we presume you didn't work on mainframes prior to the advent of
> cheap memory and cheap RAID DASD in TB chunks?
>
> Even after advent of 3380,  3390, and even native 3390-3, drives our
> company didn't lease DASD drives without doing cost analysis.  In late
> 1970's and early 1980's we were on 3330's and later 3350's, where
> physical constraints were also an issue -- when I started as SysProg in
> 1978, the computer room was maxed out space-wise at 29 3330 drives, or
> only 2.9GB total DASD space.  We didn't have DASD sitting around that
> wasn't 95% or more utilized.  Batch jobs typically got one dedicated
> 3330 DASD work volume that they could allocate only for the duration of
> the job stream, staging data from/to tape as necessary to fit and to
> preserve for next  job-stream run.  It wasn't until 1995 and beyond,
> that it finally made economic sense for us to acquire DASD capacity a
> year or two before we might actually be able to justify a need.
>
> Our company believed in investing more money in people to retain good IT
> personnel rather than throwing money at hardware.  That mind-set was one
> of the reasons why of the  50 some-odd companies in that line of
> business in 1950, of the 3 still in business in 2000, one was ours.
>
> Saving one or two bytes per date field in that kind of environment was
> not "marketing nonsense".  By performance tuning and efficient
> application design we consistently delayed the need for a DASD or
> processor upgrades, resulting in *considerable* monetary savings over
> decades.  You don't "waste" DASD or memory space just because it's
> available at the time without first considering the long-term impact on
> future upgrades.  A "good" programmer/analyst was trained to err on the
> side of conserving resources.
>
> You can't judge decisions of the past without first understanding the
> cost, physical space, memory, and I/O configuration constraints under
> which those decisions were made.  Unlike now where where easy
> incremental upgrades are possible, back then every upgrade, assuming one
> was possible,  involved a substantial cost increase.
> JC Ewing
>
> On 4/22/20 12:05 PM, Gerhard adam wrote:
> >
> >
> >
> >
> >   The notion of “savings” was marketing nonsense.  The DASD was paid
> for regardless of whether it held a production database or someone’s golf
> handicap.
> > It cost the same whether it was empty or full.  The notion of “saving”
> was nonsense and even under the best of circumstances could only be
> deferred expenses
> >
> >
> >
> >   Get Outlook for iOS
> >
> >
> >
> >
> >
> >
> > On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel" <
> dspiegel...@hotmail.com> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > It was also the physical size of the dataset.
> >
> > On 2020-04-22 12:55, Gibney, Dave wrote:
> >> In the 80's a byte of DASD savings could be thousands of dollars.
> >>
> >>> -Original Message-
> >>> From: IBM Mainframe Discussion List  On
> >>> Behalf Of Phil Smith III
> >>> Sent: Wednesday, April 22, 2020 9:12 AM
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: Re: Here we go again;
> >>>
> >>> As others have suggested, many companies do still have SSNs stored as
> >>> packed decimal. So sure, a namespace expansion is possible, but it's a
> bigger
> >>> change than one might think, however it's done. I've even seen at
> least one
> >>> company who stored them as binary! I sure hope someone got a big bonus
> >>> for saving that byte...
> >>>
> >>>
> 

Re: Memory-Lane Monday: System Zzzzz | Computerworld Shark Tank

[Phil Smith III]

This happened to me many years ago. I got a call early (8am? Early for me at 
the time, I was like 22!) about a technical problem with something I'd written. 
We discussed it, I proposed a workaround, they tried it, it worked. Then my 
colleague asked, "When will you be in to fix it right?"

 

That stumped me; I honestly could not do the math to figure out how long it 
would take me to get dressed and drive five miles. After ten seconds or so, he 
said "I guess we'll see you when we see you" and hung up.


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

Re: Here we go again;

[Phil Smith III]

>I sure hope someone got a big bonus for saving that byte...

 

Oy. Did not mean to cause a firestorm over this. Sure, it can add up; but a big 
database back then was what, 10M rows? So saving one byte was 10MB, not 
nothing, but still only 5% of a 3330. At some point, the cost of folks' time 
and the extra CPU involved also becomes significant. And dealing with it now is 
going to cost even more. So my comment was meant just to be rueful, as in, "It 
might have made sense at the time, and now we're really sorry; c'est la guerre."


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

Re: Here we go again;

[scott Ford]

David,

I laugh at these comments/observations. Early days 70-80s System
Programmers like myself helped programmers determine blocksize and dataset
location, etc.  and then DBAs were born or made and then the system
optimized.

Evolution

Scott

On Wed, Apr 22, 2020 at 3:44 PM Seymour J Metz  wrote:

> My first computer had a 2,000 word drum, a 60 word core memory, a 600,000
> word disk drive and two tape drives. I may have been a tad more constrained
> than you were when you started. I agree with Mr. Adam; people would have
> saved far more DASD space with intelligent choice of block size than the
> miniscule amount they saved by truncating the year.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Joel C. Ewing [jcew...@acm.org]
> Sent: Wednesday, April 22, 2020 3:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again;
>
> Should we presume you didn't work on mainframes prior to the advent of
> cheap memory and cheap RAID DASD in TB chunks?
>
> Even after advent of 3380,  3390, and even native 3390-3, drives our
> company didn't lease DASD drives without doing cost analysis.  In late
> 1970's and early 1980's we were on 3330's and later 3350's, where
> physical constraints were also an issue -- when I started as SysProg in
> 1978, the computer room was maxed out space-wise at 29 3330 drives, or
> only 2.9GB total DASD space.  We didn't have DASD sitting around that
> wasn't 95% or more utilized.  Batch jobs typically got one dedicated
> 3330 DASD work volume that they could allocate only for the duration of
> the job stream, staging data from/to tape as necessary to fit and to
> preserve for next  job-stream run.  It wasn't until 1995 and beyond,
> that it finally made economic sense for us to acquire DASD capacity a
> year or two before we might actually be able to justify a need.
>
> Our company believed in investing more money in people to retain good IT
> personnel rather than throwing money at hardware.  That mind-set was one
> of the reasons why of the  50 some-odd companies in that line of
> business in 1950, of the 3 still in business in 2000, one was ours.
>
> Saving one or two bytes per date field in that kind of environment was
> not "marketing nonsense".  By performance tuning and efficient
> application design we consistently delayed the need for a DASD or
> processor upgrades, resulting in *considerable* monetary savings over
> decades.  You don't "waste" DASD or memory space just because it's
> available at the time without first considering the long-term impact on
> future upgrades.  A "good" programmer/analyst was trained to err on the
> side of conserving resources.
>
> You can't judge decisions of the past without first understanding the
> cost, physical space, memory, and I/O configuration constraints under
> which those decisions were made.  Unlike now where where easy
> incremental upgrades are possible, back then every upgrade, assuming one
> was possible,  involved a substantial cost increase.
> JC Ewing
>
> On 4/22/20 12:05 PM, Gerhard adam wrote:
> >
> >
> >
> >
> >   The notion of “savings” was marketing nonsense.  The DASD was paid
> for regardless of whether it held a production database or someone’s golf
> handicap.
> > It cost the same whether it was empty or full.  The notion of “saving”
> was nonsense and even under the best of circumstances could only be
> deferred expenses
> >
> >
> >
> >   Get Outlook for iOS
> >
> >
> >
> >
> >
> >
> > On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel" <
> dspiegel...@hotmail.com> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > It was also the physical size of the dataset.
> >
> > On 2020-04-22 12:55, Gibney, Dave wrote:
> >> In the 80's a byte of DASD savings could be thousands of dollars.
> >>
> >>> -Original Message-
> >>> From: IBM Mainframe Discussion List  On
> >>> Behalf Of Phil Smith III
> >>> Sent: Wednesday, April 22, 2020 9:12 AM
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: Re: Here we go again;
> >>>
> >>> As others have suggested, many companies do still have SSNs stored as
> >>> packed decimal. So sure, a namespace expansion is possible, but it's a
> bigger
> >>> change than one might think, however it's done. I've even seen at
> least one
> >>> company who stored them as binary! I sure hope someone got a big bonus
> >>> for saving that byte...
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Peter Farley wrote:
> >>>
>  There are also many non-human entities like corporations that use the
> >>> same SSN value space.
> >>>
> >>>
> >>>
>  There are a LOT of those . . . and they spring up and fade away at a
> rate far
> >>> higher than human births and deaths.
> >>>
> >>>
> >>>
> >>> They use the same namespace--that is, if your SSN is 123-45-6789, an
> estate
> >>> or business could also have that number. Since they're uses for
> different

Re: Here we go again;

[Seymour J Metz]

My first computer had a 2,000 word drum, a 60 word core memory, a 600,000 word 
disk drive and two tape drives. I may have been a tad more constrained than you 
were when you started. I agree with Mr. Adam; people would have saved far more 
DASD space with intelligent choice of block size than the miniscule amount they 
saved by truncating the year.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Joel C. Ewing [jcew...@acm.org]
Sent: Wednesday, April 22, 2020 3:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

Should we presume you didn't work on mainframes prior to the advent of
cheap memory and cheap RAID DASD in TB chunks?

Even after advent of 3380,  3390, and even native 3390-3, drives our
company didn't lease DASD drives without doing cost analysis.  In late
1970's and early 1980's we were on 3330's and later 3350's, where
physical constraints were also an issue -- when I started as SysProg in
1978, the computer room was maxed out space-wise at 29 3330 drives, or
only 2.9GB total DASD space.  We didn't have DASD sitting around that
wasn't 95% or more utilized.  Batch jobs typically got one dedicated
3330 DASD work volume that they could allocate only for the duration of
the job stream, staging data from/to tape as necessary to fit and to
preserve for next  job-stream run.  It wasn't until 1995 and beyond,
that it finally made economic sense for us to acquire DASD capacity a
year or two before we might actually be able to justify a need.

Our company believed in investing more money in people to retain good IT
personnel rather than throwing money at hardware.  That mind-set was one
of the reasons why of the  50 some-odd companies in that line of
business in 1950, of the 3 still in business in 2000, one was ours.

Saving one or two bytes per date field in that kind of environment was
not "marketing nonsense".  By performance tuning and efficient
application design we consistently delayed the need for a DASD or
processor upgrades, resulting in *considerable* monetary savings over
decades.  You don't "waste" DASD or memory space just because it's
available at the time without first considering the long-term impact on
future upgrades.  A "good" programmer/analyst was trained to err on the
side of conserving resources.

You can't judge decisions of the past without first understanding the
cost, physical space, memory, and I/O configuration constraints under
which those decisions were made.  Unlike now where where easy
incremental upgrades are possible, back then every upgrade, assuming one
was possible,  involved a substantial cost increase.
JC Ewing

On 4/22/20 12:05 PM, Gerhard adam wrote:
>
>
>
>
>   The notion of “savings” was marketing nonsense.  The DASD was paid for 
> regardless of whether it held a production database or someone’s golf 
> handicap.
> It cost the same whether it was empty or full.  The notion of “saving” was 
> nonsense and even under the best of circumstances could only be deferred 
> expenses
>
>
>
>   Get Outlook for iOS
>
>
>
>
>
>
> On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel" 
>  wrote:
>
>
>
>
>
>
>
>
>
>
> It was also the physical size of the dataset.
>
> On 2020-04-22 12:55, Gibney, Dave wrote:
>> In the 80's a byte of DASD savings could be thousands of dollars.
>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List  On
>>> Behalf Of Phil Smith III
>>> Sent: Wednesday, April 22, 2020 9:12 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Here we go again;
>>>
>>> As others have suggested, many companies do still have SSNs stored as
>>> packed decimal. So sure, a namespace expansion is possible, but it's a 
>>> bigger
>>> change than one might think, however it's done. I've even seen at least one
>>> company who stored them as binary! I sure hope someone got a big bonus
>>> for saving that byte...
>>>
>>>
>>>
>>>
>>>
>>> Peter Farley wrote:
>>>
 There are also many non-human entities like corporations that use the
>>> same SSN value space.
>>>
>>>
>>>
 There are a LOT of those . . . and they spring up and fade away at a rate 
 far
>>> higher than human births and deaths.
>>>
>>>
>>>
>>> They use the same namespace--that is, if your SSN is 123-45-6789, an estate
>>> or business could also have that number. Since they're uses for different
>>> things, it's more that they happened (!) to choose the same format than that
>>> they're "the same". (And actually they're theoretically formatted 
>>> differently:
>>> an EIN is xx-xxx vs. the SSN xxx-xx-, not that most folks store them
>>> with the hyphens.)
>>>
>>>
>>>
>>> ...phsiii
>>>
>>>
>>> ...


--
Joel C. Ewing

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

Re: [External] Re: Here we go again;

[Bob Bridges]

I may be mistaken, but I get the impression you think you're disagreeing with 
Mr Pommier and maybe Mills.  If that's what you meant to do, I don't think 
you've succeeded yet.  They're saying that saving DASD space was often 
important; you're saying that some programmers at some companies were either 
wasteful of it, either carelessly or ignorantly.  Judging from my own 
experience, I think both are true.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* I am pretty sure that, if you will be quite honest, you will admit that a 
good rousing sneeze, one that tears open your collar and throws your hair into 
your eyes, is really one of life's sensational pleasures.  -Robert Benchley */


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard adam
Sent: Wednesday, April 22, 2020 15:20

... and so goes the mythology.  The truth is that programmers routinely used 
lousy block sizes and wastes tremendous amounts of space.  JCL sizes were 
rarely scrutinized nor was data set usage.  It was entirely possible for test 
data to exist for weeks or months beyond its usefulness

This isn’t to say that money was obviousness spent and even wasted, but few 
installations took managing their DASD seriously.  They would worry about 
saving a byte by packing a date while wasting 100 tracks due to poor blocking.

This is why nothing really happened until System Determined Blocksize, and the 
Storage Administrator tools became available.  

People certainly wrung their hands but rarely did anything about it 

--- On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex" 
 wrote:
Agreed.  Another thing to remember was that we were dealing with disk volumes 
measured in kilobytes or megabytes instead of terabytes.  In addition, the site 
I cut my teeth on had all removable disk packs that got rotated onto the drives 
for processing of each application.  Every byte saved per record gave us the 
better chance of fitting the entire set of datasets on a single disk set so we 
could process it.  

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
Sent: Wednesday, April 22, 2020 12:32 PM

Faulty logic there. A byte here and byte there and pretty soon you have to buy 
ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly 
full you have to pay for another.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard adam
Sent: Wednesday, April 22, 2020 10:06 AM

The notion of “savings” was marketing nonsense.  The DASD was paid for 
regardless of whether it held a production database or someone’s golf handicap. 
 It cost the same whether it was empty or full.  The notion of “saving” was 
nonsense and even under the best of circumstances could only be deferred 
expenses 

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

Re: [External] Re: Here we go again;

[David Spiegel]

Because, one programmer produces JCL and shares it with his/her 
colleagues for the next 50 years.

Have you ever worked in a real company?

On 2020-04-22 15:41, Gerhard adam wrote:
   
   
   
 
 	Why did you have to go to the programmers to make sure they were using proper block sizes if this were common practice?




Get Outlook for iOS
 
   





On Wed, Apr 22, 2020 at 12:34 PM -0700, "Pommier, Rex" 
 wrote:










Sorry, we'll have to agree to disagree.  It wasn't mythology at my places of 
business.  When I was in application development, disk and other resource 
efficiency was of paramount concern and when I moved into systems programming I 
got to be the one going to the developers and making sure they didn't use bad 
blocking.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Gerhard adam
Sent: Wednesday, April 22, 2020 2:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: Here we go again;

   
   
   
 
 	... and so goes the mythology.  The truth is that programmers routinely used lousy block sizes and wastes tremendous amounts of space.  JCL sizes were rarely scrutinized nor was data set usage.  It was entirely possible for test data to exist for weeks or months beyond its usefulness This isn’t to say that money was obviousness spent and even wasted, but few installations took managing their DASD seriously.  They would worry about saving a byte by packing a date while wasting 100 tracks due to poor blocking.

This is why nothing really happened until System Determined Blocksize, and the 
Storage Administrator tools became available. People certainly wrung their 
hands but rarely did anything about it



Get Outlook for iOS
 
   





On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex"  wrote:










Agreed.  Another thing to remember was that we were dealing with disk volumes 
measured in kilobytes or megabytes instead of terabytes.  In addition, the site 
I cut my teeth on had all removable disk packs that got rotated onto the drives 
for processing of each application.  Every byte saved per record gave us the 
better chance of fitting the entire set of datasets on a single disk set so we 
could process it.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
Sent: Wednesday, April 22, 2020 12:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Here we go again;

Faulty logic there. A byte here and byte there and pretty soon you have to buy 
ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly 
full you have to pay for another.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard adam
Sent: Wednesday, April 22, 2020 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

   
   
   
 
 	The notion of “savings” was marketing nonsense.  The DASD was paid for regardless of whether it held a production database or someone’s golf handicap.

It cost the same whether it was empty or full.  The notion of “saving” was 
nonsense and even under the best of circumstances could only be deferred 
expenses

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have 

Re: [External] Re: Here we go again;

[Gerhard adam]

  
  
  

Why did you have to go to the programmers to make sure they were using 
proper block sizes if this were common practice?



Get Outlook for iOS

  




On Wed, Apr 22, 2020 at 12:34 PM -0700, "Pommier, Rex" 
 wrote:










Sorry, we'll have to agree to disagree.  It wasn't mythology at my places of 
business.  When I was in application development, disk and other resource 
efficiency was of paramount concern and when I moved into systems programming I 
got to be the one going to the developers and making sure they didn't use bad 
blocking.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Gerhard adam
Sent: Wednesday, April 22, 2020 2:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: Here we go again;

  
  
  

... and so goes the mythology.  The truth is that programmers routinely 
used lousy block sizes and wastes tremendous amounts of space.  JCL sizes were 
rarely scrutinized nor was data set usage.  It was entirely possible for test 
data to exist for weeks or months beyond its usefulness This isn’t to say that 
money was obviousness spent and even wasted, but few installations took 
managing their DASD seriously.  They would worry about saving a byte by packing 
a date while wasting 100 tracks due to poor blocking.
This is why nothing really happened until System Determined Blocksize, and the 
Storage Administrator tools became available. People certainly wrung their 
hands but rarely did anything about it 



Get Outlook for iOS

  




On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex"  wrote:










Agreed.  Another thing to remember was that we were dealing with disk volumes 
measured in kilobytes or megabytes instead of terabytes.  In addition, the site 
I cut my teeth on had all removable disk packs that got rotated onto the drives 
for processing of each application.  Every byte saved per record gave us the 
better chance of fitting the entire set of datasets on a single disk set so we 
could process it.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
Sent: Wednesday, April 22, 2020 12:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Here we go again;

Faulty logic there. A byte here and byte there and pretty soon you have to buy 
ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly 
full you have to pay for another.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard adam
Sent: Wednesday, April 22, 2020 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

  
  
  

The notion of “savings” was marketing nonsense.  The DASD was paid for 
regardless of whether it held a production database or someone’s golf handicap.
It cost the same whether it was empty or full.  The notion of “saving” was 
nonsense and even under the best of circumstances could only be deferred 
expenses 

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  

Re: [External] Re: Here we go again;

[David Spiegel]

I'll bet that you never used the VTOC program (CBT File 112) to scan 
your DASD for underutilization, bad blocking, uncataloged datasets, 
phantom catalog entries etc.


On 2020-04-22 15:20, Gerhard adam wrote:
   
   
   
 
 	... and so goes the mythology.  The truth is that programmers routinely used lousy block sizes and wastes tremendous amounts of space.  JCL sizes were rarely scrutinized nor was data set usage.  It was entirely possible for test data to exist for weeks or months beyond its usefulness

This isn’t to say that money was obviousness spent and even wasted, but few 
installations took managing their DASD seriously.  They would worry about 
saving a byte by packing a date while wasting 100 tracks due to poor blocking.
This is why nothing really happened until System Determined Blocksize, and the 
Storage Administrator tools became available.
People certainly wrung their hands but rarely did anything about it



Get Outlook for iOS
 
   





On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex" 
 wrote:










Agreed.  Another thing to remember was that we were dealing with disk volumes 
measured in kilobytes or megabytes instead of terabytes.  In addition, the site 
I cut my teeth on had all removable disk packs that got rotated onto the drives 
for processing of each application.  Every byte saved per record gave us the 
better chance of fitting the entire set of datasets on a single disk set so we 
could process it.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
Sent: Wednesday, April 22, 2020 12:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Here we go again;

Faulty logic there. A byte here and byte there and pretty soon you have to buy 
ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly 
full you have to pay for another.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard adam
Sent: Wednesday, April 22, 2020 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

   
   
   
 
 	The notion of “savings” was marketing nonsense.  The DASD was paid for regardless of whether it held a production database or someone’s golf handicap.

It cost the same whether it was empty or full.  The notion of “saving” was 
nonsense and even under the best of circumstances could only be deferred 
expenses

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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


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

Re: [External] Re: Here we go again;

[Gerhard adam]

  
  
  

Sorry, but “several models of 3380”? If  3380k held almost 2GB per 
module and you saved one byte per record, then you saved the one byte over 2 
billion records to save just one 3380K’s worth of data.  Forgive me for being 
skeptical



Get Outlook for iOS

  




On Wed, Apr 22, 2020 at 12:34 PM -0700, "Pommier, Rex" 
 wrote:










Sorry, we'll have to agree to disagree.  It wasn't mythology at my places of 
business.  When I was in application development, disk and other resource 
efficiency was of paramount concern and when I moved into systems programming I 
got to be the one going to the developers and making sure they didn't use bad 
blocking.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Gerhard adam
Sent: Wednesday, April 22, 2020 2:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: Here we go again;

  
  
  

... and so goes the mythology.  The truth is that programmers routinely 
used lousy block sizes and wastes tremendous amounts of space.  JCL sizes were 
rarely scrutinized nor was data set usage.  It was entirely possible for test 
data to exist for weeks or months beyond its usefulness This isn’t to say that 
money was obviousness spent and even wasted, but few installations took 
managing their DASD seriously.  They would worry about saving a byte by packing 
a date while wasting 100 tracks due to poor blocking.
This is why nothing really happened until System Determined Blocksize, and the 
Storage Administrator tools became available. People certainly wrung their 
hands but rarely did anything about it 



Get Outlook for iOS

  




On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex"  wrote:










Agreed.  Another thing to remember was that we were dealing with disk volumes 
measured in kilobytes or megabytes instead of terabytes.  In addition, the site 
I cut my teeth on had all removable disk packs that got rotated onto the drives 
for processing of each application.  Every byte saved per record gave us the 
better chance of fitting the entire set of datasets on a single disk set so we 
could process it.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
Sent: Wednesday, April 22, 2020 12:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Here we go again;

Faulty logic there. A byte here and byte there and pretty soon you have to buy 
ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly 
full you have to pay for another.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard adam
Sent: Wednesday, April 22, 2020 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

  
  
  

The notion of “savings” was marketing nonsense.  The DASD was paid for 
regardless of whether it held a production database or someone’s golf handicap.
It cost the same whether it was empty or full.  The notion of “saving” was 
nonsense and even under the best of circumstances could only be deferred 
expenses 

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by 

Re: [External] Re: Here we go again;

[David Spiegel]

The 3200 Maximum Blocksize used to be a Linkage Editor restriction.
Also, better JCL does not pay dividends for any software vendor. As long 
as the old stuff works, nobody cares that it has been around since 2314s 
and 2319s.


On 2020-04-22 15:34, Seymour J Metz wrote:

Well, I used a DCB exit to select a block size if none was provided. OTOH, I 
kept seeing IBM procedures with 3200 long after that was too small.


--
Shmuel (Seymour J.) Metz
https://eur05.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7Cfe4606446a024ce1ef3f08d7e6f42b0f%7C84df9e7fe9f640afb435%7C1%7C0%7C637231808688902735sdata=GUKRdPCZgletvLmWTX8AsrOEwexm2Ictr2aFQRNdU%2B0%3Dreserved=0


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Gerhard adam [gada...@charter.net]
Sent: Wednesday, April 22, 2020 3:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: Here we go again;

 ... and so goes the mythology.  The truth is that programmers 
routinely used lousy block sizes and wastes tremendous amounts of space.  JCL 
sizes were rarely scrutinized nor was data set usage.  It was entirely possible 
for test data to exist for weeks or months beyond its usefulness
This isn’t to say that money was obviousness spent and even wasted, but few 
installations took managing their DASD seriously.  They would worry about 
saving a byte by packing a date while wasting 100 tracks due to poor blocking.
This is why nothing really happened until System Determined Blocksize, and the 
Storage Administrator tools became available.
People certainly wrung their hands but rarely did anything about it



 Get Outlook for iOS






On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex" 
 wrote:










Agreed.  Another thing to remember was that we were dealing with disk volumes 
measured in kilobytes or megabytes instead of terabytes.  In addition, the site 
I cut my teeth on had all removable disk packs that got rotated onto the drives 
for processing of each application.  Every byte saved per record gave us the 
better chance of fitting the entire set of datasets on a single disk set so we 
could process it.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
Sent: Wednesday, April 22, 2020 12:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Here we go again;

Faulty logic there. A byte here and byte there and pretty soon you have to buy 
ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly 
full you have to pay for another.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard adam
Sent: Wednesday, April 22, 2020 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;





 The notion of “savings” was marketing nonsense.  The DASD was paid for 
regardless of whether it held a production database or someone’s golf handicap.
It cost the same whether it was empty or full.  The notion of “saving” was 
nonsense and even under the best of circumstances could only be deferred 
expenses

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

--
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] Re: Here we go again;

[Pommier, Rex]

Sorry, we'll have to agree to disagree.  It wasn't mythology at my places of 
business.  When I was in application development, disk and other resource 
efficiency was of paramount concern and when I moved into systems programming I 
got to be the one going to the developers and making sure they didn't use bad 
blocking.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gerhard adam
Sent: Wednesday, April 22, 2020 2:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: Here we go again;

  
  
  

... and so goes the mythology.  The truth is that programmers routinely 
used lousy block sizes and wastes tremendous amounts of space.  JCL sizes were 
rarely scrutinized nor was data set usage.  It was entirely possible for test 
data to exist for weeks or months beyond its usefulness This isn’t to say that 
money was obviousness spent and even wasted, but few installations took 
managing their DASD seriously.  They would worry about saving a byte by packing 
a date while wasting 100 tracks due to poor blocking.
This is why nothing really happened until System Determined Blocksize, and the 
Storage Administrator tools became available. People certainly wrung their 
hands but rarely did anything about it 



Get Outlook for iOS

  




On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex" 
 wrote:










Agreed.  Another thing to remember was that we were dealing with disk volumes 
measured in kilobytes or megabytes instead of terabytes.  In addition, the site 
I cut my teeth on had all removable disk packs that got rotated onto the drives 
for processing of each application.  Every byte saved per record gave us the 
better chance of fitting the entire set of datasets on a single disk set so we 
could process it.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
Sent: Wednesday, April 22, 2020 12:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Here we go again;

Faulty logic there. A byte here and byte there and pretty soon you have to buy 
ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly 
full you have to pay for another.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard adam
Sent: Wednesday, April 22, 2020 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

  
  
  

The notion of “savings” was marketing nonsense.  The DASD was paid for 
regardless of whether it held a production database or someone’s golf handicap.
It cost the same whether it was empty or full.  The notion of “saving” was 
nonsense and even under the best of circumstances could only be deferred 
expenses 

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

Re: [External] Re: Here we go again;

[Seymour J Metz]

Well, I used a DCB exit to select a block size if none was provided. OTOH, I 
kept seeing IBM procedures with 3200 long after that was too small.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Gerhard adam [gada...@charter.net]
Sent: Wednesday, April 22, 2020 3:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: Here we go again;

... and so goes the mythology.  The truth is that programmers routinely 
used lousy block sizes and wastes tremendous amounts of space.  JCL sizes were 
rarely scrutinized nor was data set usage.  It was entirely possible for test 
data to exist for weeks or months beyond its usefulness
This isn’t to say that money was obviousness spent and even wasted, but few 
installations took managing their DASD seriously.  They would worry about 
saving a byte by packing a date while wasting 100 tracks due to poor blocking.
This is why nothing really happened until System Determined Blocksize, and the 
Storage Administrator tools became available.
People certainly wrung their hands but rarely did anything about it



Get Outlook for iOS






On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex" 
 wrote:










Agreed.  Another thing to remember was that we were dealing with disk volumes 
measured in kilobytes or megabytes instead of terabytes.  In addition, the site 
I cut my teeth on had all removable disk packs that got rotated onto the drives 
for processing of each application.  Every byte saved per record gave us the 
better chance of fitting the entire set of datasets on a single disk set so we 
could process it.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
Sent: Wednesday, April 22, 2020 12:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Here we go again;

Faulty logic there. A byte here and byte there and pretty soon you have to buy 
ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly 
full you have to pay for another.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard adam
Sent: Wednesday, April 22, 2020 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;





The notion of “savings” was marketing nonsense.  The DASD was paid for 
regardless of whether it held a production database or someone’s golf handicap.
It cost the same whether it was empty or full.  The notion of “saving” was 
nonsense and even under the best of circumstances could only be deferred 
expenses

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

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

Re: [External] Re: Here we go again;

[Gibney, Dave]

Conceding that to be your experience, in the 80's and early 90's, I routinely 
did these tasks. 
  I was also writing Y2K compliant COBOL  code. I wanted to use packed decimal 
in the Adabas file. Our DBA did the calculation. The byte saved by using binary 
fullwords (a 1 byte savings) translated in to needing several more 3380  disks.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gerhard adam
> Sent: Wednesday, April 22, 2020 12:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [External] Re: Here we go again;
> 
> 
> 
> 
> 
>   ... and so goes the mythology.  The truth is that programmers
> routinely used lousy block sizes and wastes tremendous amounts of
> space.  JCL sizes were rarely scrutinized nor was data set usage.  It was
> entirely possible for test data to exist for weeks or months beyond its
> usefulness This isn’t to say that money was obviousness spent and even
> wasted, but few installations took managing their DASD seriously.  They
> would worry about saving a byte by packing a date while wasting 100 tracks
> due to poor blocking.
> This is why nothing really happened until System Determined Blocksize, and
> the Storage Administrator tools became available. People certainly wrung
> their hands but rarely did anything about it
> 
> 
> 
>   Get Outlook for iOS
> 
> 
> 
> 
> 
> 
> On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex"
>  wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Agreed.  Another thing to remember was that we were dealing with disk
> volumes measured in kilobytes or megabytes instead of terabytes.  In
> addition, the site I cut my teeth on had all removable disk packs that got
> rotated onto the drives for processing of each application.  Every byte saved
> per record gave us the better chance of fitting the entire set of datasets on 
> a
> single disk set so we could process it.
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
> Sent: Wednesday, April 22, 2020 12:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: Here we go again;
> 
> Faulty logic there. A byte here and byte there and pretty soon you have to
> buy ANOTHER unit of DASD. It costs the same empty or full, but if it gets
> nearly full you have to pay for another.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Gerhard adam
> Sent: Wednesday, April 22, 2020 10:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again;
> 
> 
> 
> 
> 
>   The notion of “savings” was marketing nonsense.  The DASD was paid
> for regardless of whether it held a production database or someone’s golf
> handicap.
> It cost the same whether it was empty or full.  The notion of “saving” was
> nonsense and even under the best of circumstances could only be deferred
> expenses
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> The information contained in this message is confidential, protected from
> disclosure and may be legally privileged.  If the reader of this message is 
> not
> the intended recipient or an employee or agent responsible for delivering
> this message to the intended recipient, you are hereby notified that any
> disclosure, distribution, copying, or any action taken or action omitted in
> reliance on it, is strictly prohibited and may be unlawful.  If you have 
> received
> this communication in error, please notify us immediately by replying to this
> message and destroy the material in its entirety, whether in electronic or
> hard copy format.  Thank you.
> 
> 
> --
> 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

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

Re: Here we go again;

[Gerhard adam]

  
  
  

The truth is that everyone has such fond memories of their efforts yet 
most were surprised when System Determined Blocksize was actually introduced.  
They have forgotten the TSO CLISTS that were often written so that programmers 
would specify more efficient block sizes.
Even today, the average IT person has a poor understanding of blocking and gets 
confused when load libraries are involved (don’t understand RECFM=U)



Get Outlook for iOS

  




On Wed, Apr 22, 2020 at 12:15 PM -0700, "Joel C. Ewing"  wrote:










Should we presume you didn't work on mainframes prior to the advent of
cheap memory and cheap RAID DASD in TB chunks? 

Even after advent of 3380,  3390, and even native 3390-3, drives our
company didn't lease DASD drives without doing cost analysis.  In late
1970's and early 1980's we were on 3330's and later 3350's, where
physical constraints were also an issue -- when I started as SysProg in
1978, the computer room was maxed out space-wise at 29 3330 drives, or
only 2.9GB total DASD space.  We didn't have DASD sitting around that
wasn't 95% or more utilized.  Batch jobs typically got one dedicated
3330 DASD work volume that they could allocate only for the duration of
the job stream, staging data from/to tape as necessary to fit and to
preserve for next  job-stream run.  It wasn't until 1995 and beyond,
that it finally made economic sense for us to acquire DASD capacity a
year or two before we might actually be able to justify a need. 

Our company believed in investing more money in people to retain good IT
personnel rather than throwing money at hardware.  That mind-set was one
of the reasons why of the  50 some-odd companies in that line of
business in 1950, of the 3 still in business in 2000, one was ours.

Saving one or two bytes per date field in that kind of environment was
not "marketing nonsense".  By performance tuning and efficient
application design we consistently delayed the need for a DASD or
processor upgrades, resulting in *considerable* monetary savings over
decades.  You don't "waste" DASD or memory space just because it's
available at the time without first considering the long-term impact on
future upgrades.  A "good" programmer/analyst was trained to err on the
side of conserving resources.

You can't judge decisions of the past without first understanding the
cost, physical space, memory, and I/O configuration constraints under
which those decisions were made.  Unlike now where where easy
incremental upgrades are possible, back then every upgrade, assuming one
was possible,  involved a substantial cost increase.
    JC Ewing

On 4/22/20 12:05 PM, Gerhard adam wrote:
>   
>   
>   
> 
>   The notion of “savings” was marketing nonsense.  The DASD was paid for 
> regardless of whether it held a production database or someone’s golf 
> handicap.
> It cost the same whether it was empty or full.  The notion of “saving” was 
> nonsense and even under the best of circumstances could only be deferred 
> expenses 
>   
>   
>
>   Get Outlook for iOS
> 
>   
>
>
>
>
> On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel"  wrote:
>
>
>
>
>
>
>
>
>
>
> It was also the physical size of the dataset.
>
> On 2020-04-22 12:55, Gibney, Dave wrote:
>> In the 80's a byte of DASD savings could be thousands of dollars.
>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List  On
>>> Behalf Of Phil Smith III
>>> Sent: Wednesday, April 22, 2020 9:12 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Here we go again;
>>>
>>> As others have suggested, many companies do still have SSNs stored as
>>> packed decimal. So sure, a namespace expansion is possible, but it's a 
>>> bigger
>>> change than one might think, however it's done. I've even seen at least one
>>> company who stored them as binary! I sure hope someone got a big bonus
>>> for saving that byte...
>>>
>>>
>>>
>>>
>>>
>>> Peter Farley wrote:
>>>
 There are also many non-human entities like corporations that use the
>>> same SSN value space.
>>>
>>>
>>>
 There are a LOT of those . . . and they spring up and fade away at a rate 
 far
>>> higher than human births and deaths.
>>>
>>>
>>>
>>> They use the same namespace--that is, if your SSN is 123-45-6789, an estate
>>> or business could also have that number. Since they're uses for different
>>> things, it's more that they happened (!) to choose the same format than that
>>> they're "the same". (And actually they're theoretically formatted 
>>> differently:
>>> an EIN is xx-xxx vs. the SSN xxx-xx-, not that most folks store them
>>> with the hyphens.)
>>>
>>>
>>>
>>> ...phsiii
>>>
>>>
>>> ...


-- 
Joel C. Ewing

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

Re: Here we go again

[Seymour J Metz]

> Sicut erat in principio, et nunc, et semper, et in saecula saeculorum.

Plus ça change, plus c'esl la même chose is shorter. But, yes, I can't quarrel 
with your cynicism.

> [It did.  But Boss prevailed.]

Why am I not surprised? But that's the sort of thing for which it's wise to 
maintain off-site documentation in case someone tries to claim that it was your 
decision. Such things may disappear from the files.



--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, April 22, 2020 12:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again

On Wed, 22 Apr 2020 16:29:32 +, Seymour J Metz wrote:

>We had well over 20 years of warning on Y2K; management preferred to ignore 
>it. Apres moi le deluge (the balloon won't go up before I retire.)
>
Sicut erat in principio, et nunc, et semper, et in saecula saeculorum.

As I recall a design meeting, circa 1980:

gil>  We should store the year as 4 digits.
Boss> But the system DATE function only returns 2.
gil>  We can front-end it, prefixing "19".  When DATE gets better,
  we can demolish the scaffold.
Boss> Too much effort to code (and document), and waste of storage.
  Our product isn't designed to last so long.

[It did.  But Boss prevailed.]

-- 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] Re: Here we go again;

[scott Ford]

This stuff has circled back, from where we tried to save on dads bytes,
program bytes ( remember Assembler half words ) and other techniques to
save storage.
Now the same situation is occurring on AWS..

Scott

On Wed, Apr 22, 2020 at 3:20 PM Gerhard adam  wrote:

>
>
>
>
> ... and so goes the mythology.  The truth is that programmers
> routinely used lousy block sizes and wastes tremendous amounts of space.
> JCL sizes were rarely scrutinized nor was data set usage.  It was entirely
> possible for test data to exist for weeks or months beyond its usefulness
> This isn’t to say that money was obviousness spent and even wasted, but
> few installations took managing their DASD seriously.  They would worry
> about saving a byte by packing a date while wasting 100 tracks due to poor
> blocking.
> This is why nothing really happened until System Determined Blocksize, and
> the Storage Administrator tools became available.
> People certainly wrung their hands but rarely did anything about it
>
>
>
> Get Outlook for iOS
>
>
>
>
>
>
> On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex" <
> rpomm...@sfgmembers.com> wrote:
>
>
>
>
>
>
>
>
>
>
> Agreed.  Another thing to remember was that we were dealing with disk
> volumes measured in kilobytes or megabytes instead of terabytes.  In
> addition, the site I cut my teeth on had all removable disk packs that got
> rotated onto the drives for processing of each application.  Every byte
> saved per record gave us the better chance of fitting the entire set of
> datasets on a single disk set so we could process it.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
> Sent: Wednesday, April 22, 2020 12:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: Here we go again;
>
> Faulty logic there. A byte here and byte there and pretty soon you have to
> buy ANOTHER unit of DASD. It costs the same empty or full, but if it gets
> nearly full you have to pay for another.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gerhard adam
> Sent: Wednesday, April 22, 2020 10:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again;
>
>
>
>
>
> The notion of “savings” was marketing nonsense.  The DASD was paid
> for regardless of whether it held a production database or someone’s golf
> handicap.
> It cost the same whether it was empty or full.  The notion of “saving” was
> nonsense and even under the best of circumstances could only be deferred
> expenses
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> The information contained in this message is confidential, protected from
> disclosure and may be legally privileged.  If the reader of this message is
> not the intended recipient or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby notified
> that any disclosure, distribution, copying, or any action taken or action
> omitted in reliance on it, is strictly prohibited and may be unlawful.  If
> you have received this communication in error, please notify us immediately
> by replying to this message and destroy the material in its entirety,
> whether in electronic or hard copy format.  Thank you.
>
>
> --
> 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
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: [External] Re: Here we go again;

[Gerhard adam]

  
  
  

... and so goes the mythology.  The truth is that programmers routinely 
used lousy block sizes and wastes tremendous amounts of space.  JCL sizes were 
rarely scrutinized nor was data set usage.  It was entirely possible for test 
data to exist for weeks or months beyond its usefulness
This isn’t to say that money was obviousness spent and even wasted, but few 
installations took managing their DASD seriously.  They would worry about 
saving a byte by packing a date while wasting 100 tracks due to poor blocking.
This is why nothing really happened until System Determined Blocksize, and the 
Storage Administrator tools became available.  
People certainly wrung their hands but rarely did anything about it 



Get Outlook for iOS

  




On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex" 
 wrote:










Agreed.  Another thing to remember was that we were dealing with disk volumes 
measured in kilobytes or megabytes instead of terabytes.  In addition, the site 
I cut my teeth on had all removable disk packs that got rotated onto the drives 
for processing of each application.  Every byte saved per record gave us the 
better chance of fitting the entire set of datasets on a single disk set so we 
could process it.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
Sent: Wednesday, April 22, 2020 12:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Here we go again;

Faulty logic there. A byte here and byte there and pretty soon you have to buy 
ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly 
full you have to pay for another.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard adam
Sent: Wednesday, April 22, 2020 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

  
  
  

The notion of “savings” was marketing nonsense.  The DASD was paid for 
regardless of whether it held a production database or someone’s golf handicap.
It cost the same whether it was empty or full.  The notion of “saving” was 
nonsense and even under the best of circumstances could only be deferred 
expenses 

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
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: Here we go again

[Clark Morris]

[Default] On 21 Apr 2020 22:43:34 -0700, in bit.listserv.ibm-main
sipp...@sg.ibm.com (Timothy Sipples) wrote:

>Mark Jacobs wrote:
>>The Social Security Administration does not reuse Social Security
>>numbers. It has issued over 450 million since the start of the
>>program, and at a use rate of about 5.5 million per year. It says
>>it has enough to last several generations without reuse or changing
>>the number of digits.
>
>The Social Security Administration could easily give 20 years of advance 
>warning before expanding their number space if they wish. They've got 
>several options before that far distant future, such as:
>
>1. Allowing capital letters except those that can be confused with numeric 
>digits. That'd likely mean excluding B, D, F, G, I, L, O, Q, S, T, U, Y, 
>and Z if they want to be maximally cautious. That still leaves 13 letters 
>available, or 14 if they want to include the symbol representing the 
>artist formerly known as Prince. :-) They'll also probably have some 
>placement exclusions to avoid spelling out any words. Even with these 
>restrictions, the character space is vast.

The fun would come for programs like the now retired payroll programs
I wrote that stored social security numbers as packed decimal.

Clark Morris
>
>2. Alternatively, and in an overlapping period, some brand new digital 
>identity scheme.
>
>- - - - - - - - - -
>Timothy Sipples
>I.T. Architect Executive
>Digital Asset & Other Industry Solutions
>IBM Z & LinuxONE
>- - - - - - - - - -
>E-Mail: sipp...@sg.ibm.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: Here we go again;

[Joel C. Ewing]

Should we presume you didn't work on mainframes prior to the advent of
cheap memory and cheap RAID DASD in TB chunks? 

Even after advent of 3380,  3390, and even native 3390-3, drives our
company didn't lease DASD drives without doing cost analysis.  In late
1970's and early 1980's we were on 3330's and later 3350's, where
physical constraints were also an issue -- when I started as SysProg in
1978, the computer room was maxed out space-wise at 29 3330 drives, or
only 2.9GB total DASD space.  We didn't have DASD sitting around that
wasn't 95% or more utilized.  Batch jobs typically got one dedicated
3330 DASD work volume that they could allocate only for the duration of
the job stream, staging data from/to tape as necessary to fit and to
preserve for next  job-stream run.  It wasn't until 1995 and beyond,
that it finally made economic sense for us to acquire DASD capacity a
year or two before we might actually be able to justify a need. 

Our company believed in investing more money in people to retain good IT
personnel rather than throwing money at hardware.  That mind-set was one
of the reasons why of the  50 some-odd companies in that line of
business in 1950, of the 3 still in business in 2000, one was ours.

Saving one or two bytes per date field in that kind of environment was
not "marketing nonsense".  By performance tuning and efficient
application design we consistently delayed the need for a DASD or
processor upgrades, resulting in *considerable* monetary savings over
decades.  You don't "waste" DASD or memory space just because it's
available at the time without first considering the long-term impact on
future upgrades.  A "good" programmer/analyst was trained to err on the
side of conserving resources.

You can't judge decisions of the past without first understanding the
cost, physical space, memory, and I/O configuration constraints under
which those decisions were made.  Unlike now where where easy
incremental upgrades are possible, back then every upgrade, assuming one
was possible,  involved a substantial cost increase.
    JC Ewing

On 4/22/20 12:05 PM, Gerhard adam wrote:
>   
>   
>   
> 
>   The notion of “savings” was marketing nonsense.  The DASD was paid for 
> regardless of whether it held a production database or someone’s golf 
> handicap.
> It cost the same whether it was empty or full.  The notion of “saving” was 
> nonsense and even under the best of circumstances could only be deferred 
> expenses 
>   
>   
>
>   Get Outlook for iOS
> 
>   
>
>
>
>
> On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel" 
>  wrote:
>
>
>
>
>
>
>
>
>
>
> It was also the physical size of the dataset.
>
> On 2020-04-22 12:55, Gibney, Dave wrote:
>> In the 80's a byte of DASD savings could be thousands of dollars.
>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List  On
>>> Behalf Of Phil Smith III
>>> Sent: Wednesday, April 22, 2020 9:12 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Here we go again;
>>>
>>> As others have suggested, many companies do still have SSNs stored as
>>> packed decimal. So sure, a namespace expansion is possible, but it's a 
>>> bigger
>>> change than one might think, however it's done. I've even seen at least one
>>> company who stored them as binary! I sure hope someone got a big bonus
>>> for saving that byte...
>>>
>>>
>>>
>>>
>>>
>>> Peter Farley wrote:
>>>
 There are also many non-human entities like corporations that use the
>>> same SSN value space.
>>>
>>>
>>>
 There are a LOT of those . . . and they spring up and fade away at a rate 
 far
>>> higher than human births and deaths.
>>>
>>>
>>>
>>> They use the same namespace--that is, if your SSN is 123-45-6789, an estate
>>> or business could also have that number. Since they're uses for different
>>> things, it's more that they happened (!) to choose the same format than that
>>> they're "the same". (And actually they're theoretically formatted 
>>> differently:
>>> an EIN is xx-xxx vs. the SSN xxx-xx-, not that most folks store them
>>> with the hyphens.)
>>>
>>>
>>>
>>> ...phsiii
>>>
>>>
>>> ...


-- 
Joel C. Ewing

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

Re: [External] Re: Here we go again;

[Pommier, Rex]

Agreed.  Another thing to remember was that we were dealing with disk volumes 
measured in kilobytes or megabytes instead of terabytes.  In addition, the site 
I cut my teeth on had all removable disk packs that got rotated onto the drives 
for processing of each application.  Every byte saved per record gave us the 
better chance of fitting the entire set of datasets on a single disk set so we 
could process it.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Wednesday, April 22, 2020 12:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Here we go again;

Faulty logic there. A byte here and byte there and pretty soon you have to buy 
ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly 
full you have to pay for another.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard adam
Sent: Wednesday, April 22, 2020 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

  
  
  

The notion of “savings” was marketing nonsense.  The DASD was paid for 
regardless of whether it held a production database or someone’s golf handicap.
It cost the same whether it was empty or full.  The notion of “saving” was 
nonsense and even under the best of circumstances could only be deferred 
expenses 

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

Re: Three years ago, IBM ordered staff to work in central hubs. Now its new CEO ponders mid-pandemic: Is there a better way of doing things? • The Register

[Dana Mitchell]

On Wed, 22 Apr 2020 12:07:58 -0400, zMan  wrote:

>And yet...the POK build floor is empty. Somebody is cookin' the books.
>

If the build floor is truly empty will they be able to get new hardware shipped 
in time for customers hoping for replacements to allow migrating off z/OS 2.2 
before EOS  in September?

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

Re: Question on dynamic concatenation

[Tony Harminc]

On Wed, 22 Apr 2020 at 14:33, Seymour J Metz  wrote:
>
> It's the answer to your question: the manual is correct but fails to connect 
> the dots. The dynamic concatenation *does* remove the
> association of the other ddnames, but it does not delete the record that 
> there had previously been such an association, so when
> you deconcatenate it is able to reestablish the association. If, instead, you 
> deallocate, then there is no longer a record of the
> previous allocation.

So is that record of the previous allocation kept in some
private/undocumented place by allocation, or do TIOT entries remain in
place (perhaps flagged somehow) and provide all the necessary info?

Tony H.

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

Re: IBM z ISA assembler & emulator.

[Mike Schwab]

Sorry, you replied to Mike Schwab, not John.

On Wed, Apr 22, 2020 at 11:16 AM Knutson, Samuel
 wrote:
>
> Hi John,
>
> z390 Portable Mainframe Assembler and Emulator
> http://z390.org/
>
> VisibleZ can help you visualize exactly what the mainframe is doing as an 
> assembler program executes
> http://csc.columbusstate.edu/woolbright/vzHomepage.htm
>
> Both are similar and provide excellent learning environments and are 
> self-contained.
>
> Best Regards, Sam
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> John McKown
> Sent: Wednesday, April 22, 2020 6:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IBM z ISA assembler & emulator.
>
> Does anyone know if there is anything like this (below) for the z ISA? It is 
> a basic assembler, no macros, where you code MIPS assembler into a text file, 
> then load it into the emulator. The code is compiled. You are then in a 
> "debugger" in which you can run the code, or single step. It's quite nice for 
> learning the basics of the ISA.
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fspimsimulator.sourceforge.net%2Fdata=02%7C01%7CSamuel.Knutson%40COMPUWARE.COM%7Cb776bb1e03c84c3d68ac08d7e6ab8263%7C893e9ba31b7844d8aca9105fab957fed%7C0%7C0%7C637231496618406891sdata=c4zm5PjAAjwB9vEIIyc2yuAbf6HXoEqv0c4MMSq4w6U%3Dreserved=0
>
> [quote]
>
> *Spim* is a self-contained simulator that runs MIPS32 programs. It reads and 
> executes assembly language programs written for this processor. *Spim* also 
> provides a simple debugger and minimal set of operating system services.
> *Spim* does not execute binary (compiled) programs.
>
> *Spim* implements almost the entire MIPS32 assembler-extended instruction 
> set. (It omits most floating point comparisons and rounding modes and the 
> memory system page tables.) The MIPS architecture has several variants that 
> differ in various ways (e.g., the MIPS64 architecture supports 64-bit 
> integers and addresses), which means that *Spim* will not run programs for 
> all MIPS processors.
>
> *Spim* comes with complete source code and documentation.
>
> *Spim* implements both a terminal and windows interfaces. On Microsoft 
> Windows, Linux, and Mac OS X, the *spim* program offers a simple terminal 
> interface and the *QtSpim* program provides the windowing interface. The 
> older programs *xspim* and *PCSpim* 
> 
>  provide native window interfaces for these systems as well.
>
> [/quote]
>
>
> --
> People in sleeping bags are the soft tacos of the bear world.
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> The contents of this e-mail are intended for the named addressee only. It 
> contains information that may be confidential. Unless you are the named 
> addressee or an authorized designee, you may not copy or use it, or disclose 
> it to anyone else. If you received it in error please notify us immediately 
> and then destroy it
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Question on dynamic concatenation

[Seymour J Metz]

It's the answer to your question: the manual is correct but fails to connect 
the dots. The dynamic concatenation *does* remove the association of the other 
ddnames, but it does not delete the record that there had previously been such 
an association, so when you deconcatenate it is able to reestablish the 
association. If, instead, you deallocate, then there is no longer a record of 
the previous allocation.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Wednesday, April 22, 2020 2:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on dynamic concatenation

Is that supposed to be an answer to my questions or is it intended to be a
related FYI?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Wednesday, April 22, 2020 11:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on dynamic concatenation

Dynamic deconcatenation logically disconnects the members of a dynamically
concatenated group. You
identify the concatenated group to be deconcatenated by specifying the
ddname of the group.
When a concatenated group is dynamically deconcatenated, the ddnames that
were associated with the
data sets before they were concatenated are restored unless this would
result in duplicate ddnames. This
situation could arise if a dynamic allocation with the ddname to be restored
occurred after a dynamic
concatenation. In this case, the deconcatenation request fails.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Charles Mills [charl...@mcn.org]
Sent: Wednesday, April 22, 2020 1:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question on dynamic concatenation

I could solve this by experimentation but it would take a bunch of work. I
am hoping someone here knows the answer.

Under dynamic concatenation
(https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r
4.ieaa800/concat.htm) it says "The name associated with the concatenated
group is the ddname that was specified first; the other ddnames are no
longer associated with any data set."

I wanted to confirm that second part: if I concatenate DD BAR to DD FOO,
then DD BAR is no longer allocated, right?

Here's what makes me wonder (and wonder about an RCF): in the next section,
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4
.ieaa800/permcat.htm, it says "A group with the permanently concatenated
attribute has the following characteristics: ... Except for the first data
set in the concatenation, the data sets in the concatenation are no longer
associated with their original ddnames."

Is that "no longer associated" only true for permanent concatenations, or is
that sentence here redundant (and therefore confusing)?

--
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: Here we go again

[Seymour J Metz]

True, but as an amusing side note there were Y2K bugs that were not worth 
fixing, like displaying the year as 100 instead of 00. Unfortunately, most were 
not like that.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Wednesday, April 22, 2020 12:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again

It's nowhere near as bad as Y2K. Y2K potentially affected just about
everything. Everything with a date calculation. Everything that accepted or
printed a date.

Far fewer programs process SSN's. Anecdotally, from personal experience, I
cannot tell you how many programs I have written that involved a date that
might have been affected by the Y2K issue. But I do believe I have never
written or worked on a program that processed SSN's.

It would be big, but not as big as Y2K. It would only affect the US and the
few non-US systems that process SSN's. Y2K was global.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Tony Thigpen
Sent: Wednesday, April 22, 2020 2:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again

Expanding the SSN or changing it to alpha-numeric would be another Y2K.
While the private sector might get it done, there is no way that the
government sector could get it done in 20 years with all the red-tape
they have to go though.

Tony Thigpen

Timothy Sipples wrote on 4/22/20 1:43 AM:
> Mark Jacobs wrote:
>> The Social Security Administration does not reuse Social Security
>> numbers. It has issued over 450 million since the start of the
>> program, and at a use rate of about 5.5 million per year. It says
>> it has enough to last several generations without reuse or changing
>> the number of digits.
>
> The Social Security Administration could easily give 20 years of advance
> warning before expanding their number space if they wish. They've got
> several options before that far distant future, such as:
>
> 1. Allowing capital letters except those that can be confused with numeric
> digits. That'd likely mean excluding B, D, F, G, I, L, O, Q, S, T, U, Y,
> and Z if they want to be maximally cautious. That still leaves 13 letters
> available, or 14 if they want to include the symbol representing the
> artist formerly known as Prince. :-) They'll also probably have some
> placement exclusions to avoid spelling out any words. Even with these
> restrictions, the character space is vast.
>
> 2. Alternatively, and in an overlapping period, some brand new digital
> identity scheme.
>
> - - - - - - - - - -
> Timothy Sipples
> I.T. Architect Executive
> Digital Asset & Other Industry Solutions
> IBM Z & LinuxONE
> - - - - - - - - - -
> E-Mail: sipp...@sg.ibm.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

--
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: Question on dynamic concatenation

[Charles Mills]

Is that supposed to be an answer to my questions or is it intended to be a
related FYI?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Wednesday, April 22, 2020 11:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on dynamic concatenation

Dynamic deconcatenation logically disconnects the members of a dynamically
concatenated group. You
identify the concatenated group to be deconcatenated by specifying the
ddname of the group.
When a concatenated group is dynamically deconcatenated, the ddnames that
were associated with the
data sets before they were concatenated are restored unless this would
result in duplicate ddnames. This
situation could arise if a dynamic allocation with the ddname to be restored
occurred after a dynamic
concatenation. In this case, the deconcatenation request fails.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Charles Mills [charl...@mcn.org]
Sent: Wednesday, April 22, 2020 1:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question on dynamic concatenation

I could solve this by experimentation but it would take a bunch of work. I
am hoping someone here knows the answer.

Under dynamic concatenation
(https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r
4.ieaa800/concat.htm) it says "The name associated with the concatenated
group is the ddname that was specified first; the other ddnames are no
longer associated with any data set."

I wanted to confirm that second part: if I concatenate DD BAR to DD FOO,
then DD BAR is no longer allocated, right?

Here's what makes me wonder (and wonder about an RCF): in the next section,
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4
.ieaa800/permcat.htm, it says "A group with the permanently concatenated
attribute has the following characteristics: ... Except for the first data
set in the concatenation, the data sets in the concatenation are no longer
associated with their original ddnames."

Is that "no longer associated" only true for permanent concatenations, or is
that sentence here redundant (and therefore confusing)?

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

Re: Question on dynamic concatenation

[Seymour J Metz]

Dynamic deconcatenation logically disconnects the members of a dynamically 
concatenated group. You
identify the concatenated group to be deconcatenated by specifying the ddname 
of the group.
When a concatenated group is dynamically deconcatenated, the ddnames that were 
associated with the
data sets before they were concatenated are restored unless this would result 
in duplicate ddnames. This
situation could arise if a dynamic allocation with the ddname to be restored 
occurred after a dynamic
concatenation. In this case, the deconcatenation request fails.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Wednesday, April 22, 2020 1:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question on dynamic concatenation

I could solve this by experimentation but it would take a bunch of work. I
am hoping someone here knows the answer.

Under dynamic concatenation
(https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r
4.ieaa800/concat.htm) it says "The name associated with the concatenated
group is the ddname that was specified first; the other ddnames are no
longer associated with any data set."

I wanted to confirm that second part: if I concatenate DD BAR to DD FOO,
then DD BAR is no longer allocated, right?

Here's what makes me wonder (and wonder about an RCF): in the next section,
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4
.ieaa800/permcat.htm, it says "A group with the permanently concatenated
attribute has the following characteristics: ... Except for the first data
set in the concatenation, the data sets in the concatenation are no longer
associated with their original ddnames."

Is that "no longer associated" only true for permanent concatenations, or is
that sentence here redundant (and therefore confusing)?

Charles

--
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: Here we go again

[Bob Bridges]

Yeah, I have to side with Mr Metz on this one.  I remember thinking, back in
the '80s and early '90s, "I'm a terrible procrastinator.  But you don't get
to be the CEO of a big corporation like , or the head of IT, by
not allocating your time wisely.  I'm sure they have this under control and
will start work on it when they need to".  I really did think that.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* I am pretty sure that, if you will be quite honest, you will admit that a
good rousing sneeze, one that tears open your collar and throws your hair
into your eyes, is really one of life's sensational pleasures.  -Robert
Benchley */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Wednesday, April 22, 2020 12:30

We had well over 20 years of warning on Y2K; management preferred to ignore
it. Apres moi le deluge (the balloon won't go up before I retire.)


From: IBM Mainframe Discussion List on behalf of Paul Gilmartin
Sent: Wednesday, April 22, 2020 12:14 PM

Something similar should have been done for Y2K to avoid the last-minute
scramble.

>--- On Wed, 22 Apr 2020 13:43:03 +0800, Timothy Sipples wrote:
>>The Social Security Administration could easily give 20 years of advance
>>warning before expanding their number space if they wish. They've got
>>several options before that far distant future, such as:>

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

Question on dynamic concatenation

[Charles Mills]

I could solve this by experimentation but it would take a bunch of work. I
am hoping someone here knows the answer.

Under dynamic concatenation
(https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r
4.ieaa800/concat.htm) it says "The name associated with the concatenated
group is the ddname that was specified first; the other ddnames are no
longer associated with any data set."

I wanted to confirm that second part: if I concatenate DD BAR to DD FOO,
then DD BAR is no longer allocated, right?

Here's what makes me wonder (and wonder about an RCF): in the next section,
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4
.ieaa800/permcat.htm, it says "A group with the permanently concatenated
attribute has the following characteristics: ... Except for the first data
set in the concatenation, the data sets in the concatenation are no longer
associated with their original ddnames."

Is that "no longer associated" only true for permanent concatenations, or is
that sentence here redundant (and therefore confusing)?

Charles

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

Re: Here we go again

[Pew, Curtis G]

On Apr 22, 2020, at 11:40 AM, Charles Mills  wrote:
> 
> It's nowhere near as bad as Y2K. Y2K potentially affected just about
> everything. Everything with a date calculation. Everything that accepted or
> printed a date.
> 

That’s an important point. Dates are often used in calculations. SSNs mostly 
just used as keys and stored. For Y2K we had to fix code that was doing date 
arithmetic, but you wouldn’t have that if they expanded SSNs.


-- 
Pew, Curtis G
curtis@austin.utexas.edu






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

Re: ESTBYTES Quandary

[Lizette Koehler]

I would open a DEFECT case with IBM L2 JES2.  It should terminate any job (not 
STC) that exceeds your requirements.

I had an issue with an STC was getting a S722 abend but it was not exceeding 
the limits hard coded in JES2.  IBM has published a fix for STCs getting S722 
abends.

This might be another case where there is a code issue in JES2

OA58119

Lizette
‐‐‐ Original Message ‐‐‐
On Wednesday, April 22, 2020 11:13 AM, Joe Monk  wrote:

> JES2 limits do not apply to STCs.
>
> https://groups.google.com/forum/#!msg/bit.listserv.ibm-main/1YPjynrHqB
> o/EN7BpmG6AQAJ
>
> Joe
>
> On Wed, Apr 22, 2020 at 7:58 AM Mark Jacobs < 
> 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
>
> > We've been trying to enforce limits on how much spool space a single 
> > job can use before it's canceled. We don't have any automation 
> > products, nor
> > JES2 exits. The method that we're trying to use is ESYBYTES with OPT=1.
> > On one system we've set it to this value, $HASP845 ESTBYTE 
> > NUM=478848,INT=9,OPT=1. We're still seeing jobs, in this case an 
> > STC exceeding that limit without being canceled.
> > -- JES2 JOB STATISTICS --
> > 20 APR 2020 JOB EXECUTION DATE
> > 2 CARDS READ
> > 9,777,572 SYSOUT PRINT RECORDS
> > 0 SYSOUT PUNCH RECORDS
> > 832,896 SYSOUT SPOOL KBYTES
> > 2,970.04 MINUTES EXECUTION TIME
> > There are no overrides of the system defined limits on the EXEC card.
> > I'm at a loss on where to look further.
> > Mark Jacobs
> > Sent from ProtonMail, Swiss-based encrypted email.
> > GPG Public Key -
> > https://api.protonmail.ch/pks/lookup?op=get=markjacobs@proton
> > mail.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

--
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: Here we go again;

[Charles Mills]

Faulty logic there. A byte here and byte there and pretty soon you have to buy 
ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly 
full you have to pay for another.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard adam
Sent: Wednesday, April 22, 2020 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

  
  
  

The notion of “savings” was marketing nonsense.  The DASD was paid for 
regardless of whether it held a production database or someone’s golf handicap.
It cost the same whether it was empty or full.  The notion of “saving” was 
nonsense and even under the best of circumstances could only be deferred 
expenses 

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

Re: Here we go again;

[Gibney, Dave]

We purchased less DASD

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gerhard adam
> Sent: Wednesday, April 22, 2020 10:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again;
> 
> 
> 
> 
> 
>   The notion of “savings” was marketing nonsense.  The DASD was paid
> for regardless of whether it held a production database or someone’s golf
> handicap.
> It cost the same whether it was empty or full.  The notion of “saving” was
> nonsense and even under the best of circumstances could only be deferred
> expenses
> 
> 
> 
>   Get Outlook for iOS
> 
> 
> 
> 
> 
> 
> On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel"
>  wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> It was also the physical size of the dataset.
> 
> On 2020-04-22 12:55, Gibney, Dave wrote:
> > In the 80's a byte of DASD savings could be thousands of dollars.
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On Behalf Of Phil Smith III
> >> Sent: Wednesday, April 22, 2020 9:12 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: Here we go again;
> >>
> >> As others have suggested, many companies do still have SSNs stored as
> >> packed decimal. So sure, a namespace expansion is possible, but it's
> >> a bigger change than one might think, however it's done. I've even
> >> seen at least one company who stored them as binary! I sure hope
> >> someone got a big bonus for saving that byte...
> >>
> >>
> >>
> >>
> >>
> >> Peter Farley wrote:
> >>
> >>> There are also many non-human entities like corporations that use
> >>> the
> >> same SSN value space.
> >>
> >>
> >>
> >>> There are a LOT of those . . . and they spring up and fade away at a
> >>> rate far
> >> higher than human births and deaths.
> >>
> >>
> >>
> >> They use the same namespace--that is, if your SSN is 123-45-6789, an
> >> estate or business could also have that number. Since they're uses
> >> for different things, it's more that they happened (!) to choose the
> >> same format than that they're "the same". (And actually they're
> theoretically formatted differently:
> >> an EIN is xx-xxx vs. the SSN xxx-xx-, not that most folks
> >> store them with the hyphens.)
> >>
> >>
> >>
> >> ...phsiii
> >>
> >>
> >> -
> >> - 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 .
> 
> --
> 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

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

Re: UPDTE - CBT tape 496

[Greg Price]

On 2020-04-22 11:06 PM, Robert Prins wrote:
UPDTE still works, but for whatever reason, membernames in the resulting 
PDS are screwed up with what seem to be (part of) the initial RDW and in 
case the filename on windows was only 2 characters, the first two 
characters of the next record. The member data itself is correct.


CBT file 496 does not seem to contain anything relevant.

The UPDTE program from CBT file 93 processes IEBUPDTE-like input with 
less strict DCB restrictions.


The parsing logic of the NAME= parameter does not consider the case of 
when the record ends before the 8 characters of the member are loaded. 
It does look for a delimiter in the form of a blank or a comma.


Since text transfers typically discard trailing blanks, I suggest that 
one way to circumvent the problem would be to alter the REXX to place a 
comma after the member name.  In fact, you could probably place any 
character sufficiently far away so that it is a comment but would be a 
placeholder to ensure that at least 1 blank followed the member name.


Cheers,
Greg

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

Re: ESTBYTES Quandary

[Mark Jacobs]

TIL. Thanks.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Wednesday, April 22, 2020 11:13 AM, Joe Monk  wrote:

> JES2 limits do not apply to STCs.
>
> https://groups.google.com/forum/#!msg/bit.listserv.ibm-main/1YPjynrHqBo/EN7BpmG6AQAJ
>
> Joe
>
> On Wed, Apr 22, 2020 at 7:58 AM Mark Jacobs <
> 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
>
> > We've been trying to enforce limits on how much spool space a single job
> > can use before it's canceled. We don't have any automation products, nor
> > JES2 exits. The method that we're trying to use is ESYBYTES with OPT=1.
> > On one system we've set it to this value, $HASP845 ESTBYTE
> > NUM=478848,INT=9,OPT=1. We're still seeing jobs, in this case an STC
> > exceeding that limit without being canceled.
> > -- JES2 JOB STATISTICS --
> > 20 APR 2020 JOB EXECUTION DATE
> > 2 CARDS READ
> > 9,777,572 SYSOUT PRINT RECORDS
> > 0 SYSOUT PUNCH RECORDS
> > 832,896 SYSOUT SPOOL KBYTES
> > 2,970.04 MINUTES EXECUTION TIME
> > There are no overrides of the system defined limits on the EXEC card.
> > I'm at a loss on where to look further.
> > Mark Jacobs
> > Sent from ProtonMail, Swiss-based encrypted
> > email.
> > GPG Public Key -
> > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.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

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

Re: Here we go again;

[Gerhard adam]

  
  
  

The notion of “savings” was marketing nonsense.  The DASD was paid for 
regardless of whether it held a production database or someone’s golf handicap.
It cost the same whether it was empty or full.  The notion of “saving” was 
nonsense and even under the best of circumstances could only be deferred 
expenses 



Get Outlook for iOS

  




On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel" 
 wrote:










It was also the physical size of the dataset.

On 2020-04-22 12:55, Gibney, Dave wrote:
> In the 80's a byte of DASD savings could be thousands of dollars.
>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On
>> Behalf Of Phil Smith III
>> Sent: Wednesday, April 22, 2020 9:12 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Here we go again;
>>
>> As others have suggested, many companies do still have SSNs stored as
>> packed decimal. So sure, a namespace expansion is possible, but it's a bigger
>> change than one might think, however it's done. I've even seen at least one
>> company who stored them as binary! I sure hope someone got a big bonus
>> for saving that byte...
>>
>>
>>
>>
>>
>> Peter Farley wrote:
>>
>>> There are also many non-human entities like corporations that use the
>> same SSN value space.
>>
>>
>>
>>> There are a LOT of those . . . and they spring up and fade away at a rate 
>>> far
>> higher than human births and deaths.
>>
>>
>>
>> They use the same namespace--that is, if your SSN is 123-45-6789, an estate
>> or business could also have that number. Since they're uses for different
>> things, it's more that they happened (!) to choose the same format than that
>> they're "the same". (And actually they're theoretically formatted 
>> differently:
>> an EIN is xx-xxx vs. the SSN xxx-xx-, not that most folks store them
>> with the hyphens.)
>>
>>
>>
>> ...phsiii
>>
>>
>> --
>> 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
> .

--
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: Here we go again;

[David Spiegel]

It was also the physical size of the dataset.

On 2020-04-22 12:55, Gibney, Dave wrote:

In the 80's a byte of DASD savings could be thousands of dollars.


-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of Phil Smith III
Sent: Wednesday, April 22, 2020 9:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

As others have suggested, many companies do still have SSNs stored as
packed decimal. So sure, a namespace expansion is possible, but it's a bigger
change than one might think, however it's done. I've even seen at least one
company who stored them as binary! I sure hope someone got a big bonus
for saving that byte...





Peter Farley wrote:


There are also many non-human entities like corporations that use the

same SSN value space.




There are a LOT of those . . . and they spring up and fade away at a rate far

higher than human births and deaths.



They use the same namespace--that is, if your SSN is 123-45-6789, an estate
or business could also have that number. Since they're uses for different
things, it's more that they happened (!) to choose the same format than that
they're "the same". (And actually they're theoretically formatted differently:
an EIN is xx-xxx vs. the SSN xxx-xx-, not that most folks store them
with the hyphens.)



...phsiii


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


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

Re: Here we go again;

[Gibney, Dave]

In the 80's a byte of DASD savings could be thousands of dollars.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Phil Smith III
> Sent: Wednesday, April 22, 2020 9:12 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again;
> 
> As others have suggested, many companies do still have SSNs stored as
> packed decimal. So sure, a namespace expansion is possible, but it's a bigger
> change than one might think, however it's done. I've even seen at least one
> company who stored them as binary! I sure hope someone got a big bonus
> for saving that byte...
> 
> 
> 
> 
> 
> Peter Farley wrote:
> 
> >There are also many non-human entities like corporations that use the
> same SSN value space.
> 
> 
> 
> >There are a LOT of those . . . and they spring up and fade away at a rate far
> higher than human births and deaths.
> 
> 
> 
> They use the same namespace--that is, if your SSN is 123-45-6789, an estate
> or business could also have that number. Since they're uses for different
> things, it's more that they happened (!) to choose the same format than that
> they're "the same". (And actually they're theoretically formatted differently:
> an EIN is xx-xxx vs. the SSN xxx-xx-, not that most folks store them
> with the hyphens.)
> 
> 
> 
> ...phsiii
> 
> 
> --
> 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: Here we go again;

[scott Ford]

Guys,

Hadn’t heard of that, Microfocus Cobol yes for sure, some of the other
through the ages.

Scott

On Wed, Apr 22, 2020 at 12:27 PM Allan Staller 
wrote:

> I worked at Pru in the  early 70's.
> From the last I heard in the mid-80's, I believe Pru-Cobol is long since
> defunct.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Billy Ashton
> Sent: Wednesday, April 22, 2020 11:22 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again;
>
> [CAUTION: This Email is from outside the Organization. Do not click links
> or open attachments unless you trust the sender.]
>
> I also remember some years ago that Prudential had their own version of
> COBOL that allowed them to pack character (maybe just alpha?) fields, so
> they could probably add an alpha to the SSN numbering scheme without issue.
> I don't know if they still use it, and really hurt my brain trying to
> figure out how to pack alpha values.
>
> Billy
>
> -- Original Message --
> From: "Phil Smith III" 
> To: IBM-MAIN@listserv.ua.edu
> Sent: 4/22/2020 12:11:41 PM
> Subject: Re: Here we go again;
>
> >As others have suggested, many companies do still have SSNs stored as
> packed decimal. So sure, a namespace expansion is possible, but it's a
> bigger change than one might think, however it's done. I've even seen at
> least one company who stored them as binary! I sure hope someone got a big
> bonus for saving that byte...
> >
> >
> >
> >
> >
> >Peter Farley wrote:
> >
> >>There are also many non-human entities like corporations that use the
> same SSN value space.
> >
> >
> >
> >>There are a LOT of those . . . and they spring up and fade away at a
> rate far higher than human births and deaths.
> >
> >
> >
> >They use the same namespace--that is, if your SSN is 123-45-6789, an
> >estate or business could also have that number. Since they're uses for
> >different things, it's more that they happened (!) to choose the same
> >format than that they're "the same". (And actually they're
> >theoretically formatted differently: an EIN is xx-xxx vs. the SSN
> >xxx-xx-, not that most folks store them with the hyphens.)
> >
> >
> >
> >...phsiii
> >
> >
> >--
> >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
> ::DISCLAIMER::
> 
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. E-mail transmission is not
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or may contain
> viruses in transmission. The e mail and its contents (with or without
> referred errors) shall therefore not attach any liability on the originator
> or HCL or its affiliates. Views or opinions, if any, presented in this
> email are solely those of the author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification, distribution and / or
> publication of this message without the prior written consent of authorized
> representative of HCL is strictly prohibited. If you have received this
> email in error please delete it and notify the sender immediately. Before
> opening any email and/or attachments, please check them for viruses and
> other defects.
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: IBM z ISA assembler & emulator.

[Mike Schwab]

Assist?   https://twitter.com/ddiamond/status/1252643918375727105?s=20
 Its included in Turnkey 3 and 4-, I believe.

On Wed, Apr 22, 2020 at 10:54 AM John McKown
 wrote:
>
> Does anyone know if there is anything like this (below) for the z ISA? It
> is a basic assembler, no macros, where you code MIPS assembler into a text
> file, then load it into the emulator. The code is compiled. You are then in
> a "debugger" in which you can run the code, or single step. It's quite nice
> for learning the basics of the ISA.
>
> http://spimsimulator.sourceforge.net/
>
> [quote]
>
> *Spim* is a self-contained simulator that runs MIPS32 programs. It reads
> and executes assembly language programs written for this processor. *Spim* 
> also
> provides a simple debugger and minimal set of operating system services.
> *Spim* does not execute binary (compiled) programs.
>
> *Spim* implements almost the entire MIPS32 assembler-extended instruction
> set. (It omits most floating point comparisons and rounding modes and the
> memory system page tables.) The MIPS architecture has several variants that
> differ in various ways (e.g., the MIPS64 architecture supports 64-bit
> integers and addresses), which means that *Spim* will not run programs for
> all MIPS processors.
>
> *Spim* comes with complete source code and documentation.
>
> *Spim* implements both a terminal and windows interfaces. On Microsoft
> Windows, Linux, and Mac OS X, the *spim* program offers a simple terminal
> interface and the *QtSpim* program provides the windowing interface. The older
> programs *xspim* and *PCSpim*
>  provide native window
> interfaces for these systems as well.
>
> [/quote]
>
>
> --
> People in sleeping bags are the soft tacos of the bear world.
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Here we go again

[Paul Gilmartin]

On Wed, 22 Apr 2020 16:29:32 +, Seymour J Metz wrote:

>We had well over 20 years of warning on Y2K; management preferred to ignore 
>it. Apres moi le deluge (the balloon won't go up before I retire.)
> 
Sicut erat in principio, et nunc, et semper, et in saecula saeculorum.

As I recall a design meeting, circa 1980:

gil>  We should store the year as 4 digits.
Boss> But the system DATE function only returns 2.
gil>  We can front-end it, prefixing "19".  When DATE gets better,
  we can demolish the scaffold.
Boss> Too much effort to code (and document), and waste of storage.
  Our product isn't designed to last so long.

[It did.  But Boss prevailed.]

-- gil

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

Re: Here we go again

[Charles Mills]

It's nowhere near as bad as Y2K. Y2K potentially affected just about
everything. Everything with a date calculation. Everything that accepted or
printed a date.

Far fewer programs process SSN's. Anecdotally, from personal experience, I
cannot tell you how many programs I have written that involved a date that
might have been affected by the Y2K issue. But I do believe I have never
written or worked on a program that processed SSN's.

It would be big, but not as big as Y2K. It would only affect the US and the
few non-US systems that process SSN's. Y2K was global.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Tony Thigpen
Sent: Wednesday, April 22, 2020 2:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again

Expanding the SSN or changing it to alpha-numeric would be another Y2K. 
While the private sector might get it done, there is no way that the 
government sector could get it done in 20 years with all the red-tape 
they have to go though.

Tony Thigpen

Timothy Sipples wrote on 4/22/20 1:43 AM:
> Mark Jacobs wrote:
>> The Social Security Administration does not reuse Social Security
>> numbers. It has issued over 450 million since the start of the
>> program, and at a use rate of about 5.5 million per year. It says
>> it has enough to last several generations without reuse or changing
>> the number of digits.
> 
> The Social Security Administration could easily give 20 years of advance
> warning before expanding their number space if they wish. They've got
> several options before that far distant future, such as:
> 
> 1. Allowing capital letters except those that can be confused with numeric
> digits. That'd likely mean excluding B, D, F, G, I, L, O, Q, S, T, U, Y,
> and Z if they want to be maximally cautious. That still leaves 13 letters
> available, or 14 if they want to include the symbol representing the
> artist formerly known as Prince. :-) They'll also probably have some
> placement exclusions to avoid spelling out any words. Even with these
> restrictions, the character space is vast.
> 
> 2. Alternatively, and in an overlapping period, some brand new digital
> identity scheme.
> 
> - - - - - - - - - -
> Timothy Sipples
> I.T. Architect Executive
> Digital Asset & Other Industry Solutions
> IBM Z & LinuxONE
> - - - - - - - - - -
> E-Mail: sipp...@sg.ibm.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

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

Re: TSO Pipes (and BatchPipes)

[Lionel B Dyck]

Ray - thank you - so the CMS Pipes is 20 years newer than the TSO Pipes (at 
least the BatchPipes version).


Lionel B. Dyck <
Website: https://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ray 
Pearce
Sent: Wednesday, April 22, 2020 11:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO Pipes (and BatchPipes)

On CMS I get
FPLINX086I CMS Pipelines, 5741-A07 1.0112 (Version.Release/Mod) - Generated 8 
Sep 2016 at 15:22:22

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hobart Spitz
Sent: 22 April 2020 17:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO Pipes (and BatchPipes)

If there are any z/VMers subscribed, it would be interesting to also compare 
the PIPE Q output under CMS.

Thanks.

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data in move mode or 
locate mode?
IBM has been looking for an HLL for program products; REXX is that language.


On Wed, Apr 22, 2020 at 10:57 AM Lionel B Dyck  wrote:

> I don't have access to TSO Pipes other than what is included with 
> BatchPipes but it seems that it is a tad dated - it is actually old 
> enough to drink:
>
>
>
> BPW00086I BatchPipes/MVS BatchPipeWorks, 5655-065/SCPSP 1.0109
> (Version.Release/Mod) - Generated 12 Oct 1996 at 13:59:00
>
>
>
> If someone has the non-BP version of TSO Pipes it would be interesting 
> to see the results of the PIPES Q command showing the date.
>
>
>
> For those of you who would like to encourage IBM to release TSO Pipes 
> as part of the z/OS base please go to this URL and vote 
> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe
> <
> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=
> 47699
> > _ID=47699  (note the current vote is 188 which places it at the  
> > top
> in
> the z/OS area).
>
>
>
> Having TSO Pipes as a native part of the z/OS distribution would help 
> everyone as software developers would then be free to use it when 
> developing applications, products, and tools knowing that every site 
> has it available.
>
>
>
>
>
> Lionel B. Dyck <
> Website:   https://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is 
> what you are, reputation merely what others think you are." - John 
> Wooden
>
>
>
>
> --
> 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

--
This e-mail message has been scanned and cleared by Google Message Security and 
the UNICOM Global security systems. This message is for the named person's use 
only. If you receive this message in error, please delete it and notify the 
sender. 

--
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: Here we go again

[Seymour J Metz]

We had well over 20 years of warning on Y2K; management preferred to ignore it. 
Apres moi le deluge (the balloon won't go up before I retire.)


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, April 22, 2020 12:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again

On Wed, 22 Apr 2020 10:34:34 -0500, Tom Marchant wrote:

>On Wed, 22 Apr 2020 13:43:03 +0800, Timothy Sipples wrote:
>
>>The Social Security Administration could easily give 20 years of advance
>
Something similar should have been done for Y2K to avoid the last-minute 
scramble.

>>warning before expanding their number space if they wish. They've got
>>several options before that far distant future, such as:
>>
>>1. Allowing capital letters except those that can be confused with numeric
>>digits.
>
>If they are going to give warning so that computer systems can be changed,
>this is not an interim option. Many years ago, I worked as an application
>programmer on systems where SSN was stored in packed decimal. I'm sure
>that others did the same, or stored them in a fullword.
>
>These would have to be changed if letters are allowed.
>
Two separate issues are coding and data storage space.

-- 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: TSO Pipes (and BatchPipes)

[Ray Pearce]

On CMS I get
FPLINX086I CMS Pipelines, 5741-A07 1.0112 (Version.Release/Mod) - Generated 8 
Sep 2016 at 15:22:22

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hobart Spitz
Sent: 22 April 2020 17:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO Pipes (and BatchPipes)

If there are any z/VMers subscribed, it would be interesting to also
compare the PIPE Q output under CMS.

Thanks.

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data in move mode
or locate mode?
IBM has been looking for an HLL for program products; REXX is that language.


On Wed, Apr 22, 2020 at 10:57 AM Lionel B Dyck  wrote:

> I don't have access to TSO Pipes other than what is included with
> BatchPipes
> but it seems that it is a tad dated - it is actually old enough to drink:
>
>
>
> BPW00086I BatchPipes/MVS BatchPipeWorks, 5655-065/SCPSP 1.0109
> (Version.Release/Mod) - Generated 12 Oct 1996 at 13:59:00
>
>
>
> If someone has the non-BP version of TSO Pipes it would be interesting to
> see the results of the PIPES Q command showing the date.
>
>
>
> For those of you who would like to encourage IBM to release TSO Pipes as
> part of the z/OS base please go to this URL and vote
> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe
> <
> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=47699
> > _ID=47699  (note the current vote is 188 which places it at the  top
> in
> the z/OS area).
>
>
>
> Having TSO Pipes as a native part of the z/OS distribution would help
> everyone as software developers would then be free to use it when
> developing
> applications, products, and tools knowing that every site has it available.
>
>
>
>
>
> Lionel B. Dyck <
> Website:   https://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are." - John Wooden
>
>
>
>
> --
> 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

-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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

Re: z/OS 2.3 systems show OPI=YES

[Michael Babcock]

My Zelden IPLINFO shows OPI=YES and set by IEASYSD0.  Do a D PARMLIB and
ensure you are pulling the correct IEASYS00 member and have coded OPI=NO.

My D IPLINFO shows the same as yours with respect to (OP) being shown and
we don’t prompt either (M1 coded in Load parm).

On Wed, Apr 22, 2020 at 11:06 AM Carmen Vitullo  wrote:

> I'm working an audit issue which has been identified as a system exposure.
> I have in a shared parmlib IEASYS00 member OPI=NO, my IPLPARMS are set as
> 220100M1, but the D IPLINFO shows
>
>  SYSTEM IPLED AT 23.20.28 ON 04/01/2020
>  RELEASE z/OS 02.03.00LICENSE = z/OS
>  USED LOAD00 IN SYS1.IPLPARM ON 02201
>  ARCHLVL = 2   MTLSHARE = N
>  IEASYM LIST = (00,L)
>  IEASYS LIST = (00,SA,20) (OP)
> Marks IPLINFO rexx shows
>
>  OPI=YES,   Default
> SYSP=(00,SA,20),   Operator
> we are setting OPI=NO
> and are not prompting or setting SYSP parameters via an operator request.
> I have an open PMR with IBM but I wonder if anyone else sees the same
> displays ?
> thanks
> Carmen
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead

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

Re: Here we go again;

[Allan Staller]

I worked at Pru in the  early 70's.
From the last I heard in the mid-80's, I believe Pru-Cobol is long since 
defunct.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Billy Ashton
Sent: Wednesday, April 22, 2020 11:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

[CAUTION: This Email is from outside the Organization. Do not click links or 
open attachments unless you trust the sender.]

I also remember some years ago that Prudential had their own version of COBOL 
that allowed them to pack character (maybe just alpha?) fields, so they could 
probably add an alpha to the SSN numbering scheme without issue. I don't know 
if they still use it, and really hurt my brain trying to figure out how to pack 
alpha values.

Billy

-- Original Message --
From: "Phil Smith III" 
To: IBM-MAIN@listserv.ua.edu
Sent: 4/22/2020 12:11:41 PM
Subject: Re: Here we go again;

>As others have suggested, many companies do still have SSNs stored as packed 
>decimal. So sure, a namespace expansion is possible, but it's a bigger change 
>than one might think, however it's done. I've even seen at least one company 
>who stored them as binary! I sure hope someone got a big bonus for saving that 
>byte...
>
>
>
>
>
>Peter Farley wrote:
>
>>There are also many non-human entities like corporations that use the same 
>>SSN value space.
>
>
>
>>There are a LOT of those . . . and they spring up and fade away at a rate far 
>>higher than human births and deaths.
>
>
>
>They use the same namespace--that is, if your SSN is 123-45-6789, an
>estate or business could also have that number. Since they're uses for
>different things, it's more that they happened (!) to choose the same
>format than that they're "the same". (And actually they're
>theoretically formatted differently: an EIN is xx-xxx vs. the SSN
>xxx-xx-, not that most folks store them with the hyphens.)
>
>
>
>...phsiii
>
>
>--
>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
::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


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

Re: Here we go again;

[Billy Ashton]

I also remember some years ago that Prudential had their own version of 
COBOL that allowed them to pack character (maybe just alpha?) fields, so 
they could probably add an alpha to the SSN numbering scheme without 
issue. I don't know if they still use it, and really hurt my brain 
trying to figure out how to pack alpha values.


Billy

-- Original Message --
From: "Phil Smith III" 
To: IBM-MAIN@listserv.ua.edu
Sent: 4/22/2020 12:11:41 PM
Subject: Re: Here we go again;


As others have suggested, many companies do still have SSNs stored as packed 
decimal. So sure, a namespace expansion is possible, but it's a bigger change 
than one might think, however it's done. I've even seen at least one company 
who stored them as binary! I sure hope someone got a big bonus for saving that 
byte...





Peter Farley wrote:


There are also many non-human entities like corporations that use the same SSN 
value space.





There are a LOT of those . . . and they spring up and fade away at a rate far 
higher than human births and deaths.




They use the same namespace--that is, if your SSN is 123-45-6789, an estate or business 
could also have that number. Since they're uses for different things, it's more that they 
happened (!) to choose the same format than that they're "the same". (And 
actually they're theoretically formatted differently: an EIN is xx-xxx vs. the SSN 
xxx-xx-, not that most folks store them with the hyphens.)



...phsiii


--
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: Here we go again;

[scott Ford]

Phil,

My father was a FE for Unisys and said new boss is like a broom , “new
broom makes a clean sweep”, new boss re-arranges “their” way...

Scott

On Wed, Apr 22, 2020 at 12:12 PM Phil Smith III  wrote:

> As others have suggested, many companies do still have SSNs stored as
> packed decimal. So sure, a namespace expansion is possible, but it's a
> bigger change than one might think, however it's done. I've even seen at
> least one company who stored them as binary! I sure hope someone got a big
> bonus for saving that byte...
>
>
>
>
>
> Peter Farley wrote:
>
> >There are also many non-human entities like corporations that use the
> same SSN value space.
>
>
>
> >There are a LOT of those . . . and they spring up and fade away at a rate
> far higher than human births and deaths.
>
>
>
> They use the same namespace--that is, if your SSN is 123-45-6789, an
> estate or business could also have that number. Since they're uses for
> different things, it's more that they happened (!) to choose the same
> format than that they're "the same". (And actually they're theoretically
> formatted differently: an EIN is xx-xxx vs. the SSN xxx-xx-, not
> that most folks store them with the hyphens.)
>
>
>
> ...phsiii
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

zOSMF

[Steve Beaver]

Well I ended up with 2 problems

I had to copy over the Liberty zFS to my LPAR
And I had to pull a zOSMF zFS down from IBM

I mounted them both and low and behold ANG1 and AVR1 came up

Still fighting a HTTPS problem but I am miles further.

Thank you all for your kind assistance

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

Re: Here we go again

[Paul Gilmartin]

On Wed, 22 Apr 2020 10:34:34 -0500, Tom Marchant wrote:

>On Wed, 22 Apr 2020 13:43:03 +0800, Timothy Sipples wrote:
>
>>The Social Security Administration could easily give 20 years of advance 
>
Something similar should have been done for Y2K to avoid the last-minute 
scramble.

>>warning before expanding their number space if they wish. They've got 
>>several options before that far distant future, such as:
>>
>>1. Allowing capital letters except those that can be confused with numeric 
>>digits.
>
>If they are going to give warning so that computer systems can be changed, 
>this is not an interim option. Many years ago, I worked as an application 
>programmer on systems where SSN was stored in packed decimal. I'm sure 
>that others did the same, or stored them in a fullword.
>
>These would have to be changed if letters are allowed.
> 
Two separate issues are coding and data storage space.

-- gil

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

Re: Here we go again;

[Phil Smith III]

As others have suggested, many companies do still have SSNs stored as packed 
decimal. So sure, a namespace expansion is possible, but it's a bigger change 
than one might think, however it's done. I've even seen at least one company 
who stored them as binary! I sure hope someone got a big bonus for saving that 
byte...

 

 

Peter Farley wrote:

>There are also many non-human entities like corporations that use the same SSN 
>value space.

 

>There are a LOT of those . . . and they spring up and fade away at a rate far 
>higher than human births and deaths.

 

They use the same namespace--that is, if your SSN is 123-45-6789, an estate or 
business could also have that number. Since they're uses for different things, 
it's more that they happened (!) to choose the same format than that they're 
"the same". (And actually they're theoretically formatted differently: an EIN 
is xx-xxx vs. the SSN xxx-xx-, not that most folks store them with the 
hyphens.)

 

...phsiii


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

Re: Three years ago, IBM ordered staff to work in central hubs. Now its new CEO ponders mid-pandemic: Is there a better way of doing things? • The Register

[zMan]

And yet...the POK build floor is empty. Somebody is cookin' the books.

On Tue, Apr 21, 2020 at 8:03 AM Mark Regan  wrote:

> From the article:
>
> "Systems revenue saw $1.4bn in revenue, up 3 per cent thanks to the IBM Z
> mainframe line."
>
> https://www.theregister.co.uk/2020/04/21/ibm_q1_fy2020_coronavirus/
>
> Regards,
>
> *Mark T. Regan, K8MTR*
> CTO1 USNR-Retired, 1969-1991
> Nationwide Insurance, Retired, 1986-2017
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

z/OS 2.3 systems show OPI=YES

[Carmen Vitullo]

I'm working an audit issue which has been identified as a system exposure. I 
have in a shared parmlib IEASYS00 member OPI=NO, my IPLPARMS are set as 
220100M1, but the D IPLINFO shows 

 SYSTEM IPLED AT 23.20.28 ON 04/01/2020 
 RELEASE z/OS 02.03.00LICENSE = z/OS
 USED LOAD00 IN SYS1.IPLPARM ON 02201   
 ARCHLVL = 2   MTLSHARE = N 
 IEASYM LIST = (00,L)   
 IEASYS LIST = (00,SA,20) (OP)  
Marks IPLINFO rexx shows 

 OPI=YES,   Default 
SYSP=(00,SA,20),   Operator  
we are setting OPI=NO
and are not prompting or setting SYSP parameters via an operator request.
I have an open PMR with IBM but I wonder if anyone else sees the same displays ?
thanks
Carmen 
   

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

Re: TSO Pipes (and BatchPipes)

[Hobart Spitz]

If there are any z/VMers subscribed, it would be interesting to also
compare the PIPE Q output under CMS.

Thanks.

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data in move mode
or locate mode?
IBM has been looking for an HLL for program products; REXX is that language.


On Wed, Apr 22, 2020 at 10:57 AM Lionel B Dyck  wrote:

> I don't have access to TSO Pipes other than what is included with
> BatchPipes
> but it seems that it is a tad dated - it is actually old enough to drink:
>
>
>
> BPW00086I BatchPipes/MVS BatchPipeWorks, 5655-065/SCPSP 1.0109
> (Version.Release/Mod) - Generated 12 Oct 1996 at 13:59:00
>
>
>
> If someone has the non-BP version of TSO Pipes it would be interesting to
> see the results of the PIPES Q command showing the date.
>
>
>
> For those of you who would like to encourage IBM to release TSO Pipes as
> part of the z/OS base please go to this URL and vote
> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe
> <
> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=47699
> > _ID=47699  (note the current vote is 188 which places it at the  top
> in
> the z/OS area).
>
>
>
> Having TSO Pipes as a native part of the z/OS distribution would help
> everyone as software developers would then be free to use it when
> developing
> applications, products, and tools knowing that every site has it available.
>
>
>
>
>
> Lionel B. Dyck <
> Website:   https://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are." - John Wooden
>
>
>
>
> --
> 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: TSO Pipes (and BatchPipes)

[Jack J. Woehr]

On 4/22/20 9:56 AM, Lionel B Dyck wrote:

it is actually old enough to drink:


It's not that long until MVS itself is old enough to collect social 
security ...


--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: JES2 SPOOLDEF TGSIZE recommendation sought

[Pommier, Rex]

Am I understanding this correctly?  BUFSIZE is 3992 at your sites, so a TGSIZE 
of 30 says that JES2 will build each track group big enough to hold 30 buffers 
of 3992 bytes or 119760 bytes.  How many 3390 tracks are required to hold this? 
 I just checked ours, and we're set at a TGSIZE of 33 which I think happened 
before my time.  Looking at the 3390 reference summary, my guess is that 
whoever set it figured that since the JES2 BUFSIZE is 3992, that the actual 
blocks are 3992 bytes, therefore 11 can fit on a track, so 3 tracks would 
equate to a TGSIZE of 33 for best utilization.  I'm thinking that is probably 
an incorrect calculation and my setting is wasting space.  Thoughts?

Thanks,
Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Wednesday, April 22, 2020 6:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: JES2 SPOOLDEF TGSIZE recommendation sought

Yea, just getting my coffee too...  Looks like TGSIZE is easy enough to make 
larger, no so much to make smallerI guess if you are going to change, then 
make the change before you add the new volumes.   Once formatted, it doesn't 
change?

TGSIZE=nnn|30
Specifies the number (1-255) of JES2 buffers to be contained in a track group. 
JES2 uses this value to determine the number of tracks in a track group on each 
spool device. This is the default value for the number of track groups for each 
new spool volume added to the complex. Because the number of tracks in a track 
group will vary based on the track capacity of the device, the resultant value 
is rounded to the minimum integral number of tracks that can contain the 
specified number of buffers.
If you specify TGSIZE=, it must contain a value from 1 to 255. Regardless of 
the value specified, the minimum resulting track group size is one track and 
the maximum is the smaller of 255 and the number of tracks in the first extent 
of the SYS1.HASPACE data set with the least number of tracks.

Note: If you do not specify TGSIZE= as the same value on all members of the 
complex, JES2 might not use the value specified here for a new spool volume.
Performance Considerations: Attempt to tailor the value of TGSIZE to fit the 
majority of the jobs in your system. SMF type 26 records can be used to assist 
your choice of a value for this parameter.

Small values for TGSIZE= can cause an excessive number of track group 
allocations per job thus increasing processor overhead. For example, an IEFBR14 
job requires 13 spool buffers for control blocks and JCL data sets; therefore, 
set the value of TGSIZE= greater than 13. Large values for TGSIZE= can waste 
spool space and unnecessarily increase seek time.

Modification: Minimum action to modify is $T SPOOLDEF to increase and a JES2 
cold start to decrease.

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Richards, Robert B.
Sent: Wednesday, April 22, 2020 7:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 SPOOLDEF TGSIZE recommendation sought

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Dave, 

At your request! I should have provided it before...now where is that 2nd cup 
of coffee?

Bob
 
SPOOLDEF  BUFSIZE=3992,DSNAME=SYS1.HASPACE,DSNMASK=,
  FENCE=(ACTIVE=NO,VOLUMES=1),GCRATE=NORMAL,
  LASTSVAL=(2007.287,19:42:13),LARGEDS=ALLOWED, 
  SPOOLNUM=64,TGSIZE=24,TGSPACE=(MAX=2443200,   
  DEFINED=1900575,ACTIVE=1900575,   
  PERCENT=32.1218,FREE=1290076,WARN=80),
  TRKCELL=3,VOLUME=JESS 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Wednesday, April 22, 2020 6:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 SPOOLDEF TGSIZE recommendation sought

It would be helpful if you could post the output of a $DSPOOLDEF command.  We 
run with mod-54's with no issues.  Just make sure you code LARGEDS=ALLOWED

$SPOOLDEF   
SPOOLDEF  BUFSIZE=3992,DSNAME=SYS1.HASPACE,DSNMASK=,   
  FENCE=(ACTIVE=NO,VOLUMES=1),GCRATE=NORMAL,   
  LASTSVAL=(2007.294,12:08:34),LARGEDS=ALLOWED,
  SPOOLNUM=96,TGSIZE=30,TGSPACE=(MAX=2524640,  
  DEFINED=1202032,ACTIVE=1202032,  
  PERCENT=49.1162,FREE=611639,WARN=80),
  TRKCELL=3,VOLUME=JESD
_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris 

TSO Pipes (and BatchPipes)

[Lionel B Dyck]

I don't have access to TSO Pipes other than what is included with BatchPipes
but it seems that it is a tad dated - it is actually old enough to drink:

 

BPW00086I BatchPipes/MVS BatchPipeWorks, 5655-065/SCPSP 1.0109
(Version.Release/Mod) - Generated 12 Oct 1996 at 13:59:00

 

If someone has the non-BP version of TSO Pipes it would be interesting to
see the results of the PIPES Q command showing the date.

 

For those of you who would like to encourage IBM to release TSO Pipes as
part of the z/OS base please go to this URL and vote
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe
 _ID=47699  (note the current vote is 188 which places it at the  top in
the z/OS area).

 

Having TSO Pipes as a native part of the z/OS distribution would help
everyone as software developers would then be free to use it when developing
applications, products, and tools knowing that every site has it available.

 

 

Lionel B. Dyck <
Website:   https://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what
you are, reputation merely what others think you are." - John Wooden

 


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

Re: Here we go again

[Tom Marchant]

On Wed, 22 Apr 2020 13:43:03 +0800, Timothy Sipples wrote:

>The Social Security Administration could easily give 20 years of advance 
>warning before expanding their number space if they wish. They've got 
>several options before that far distant future, such as:
>
>1. Allowing capital letters except those that can be confused with numeric 
>digits.

If they are going to give warning so that computer systems can be changed, 
this is not an interim option. Many years ago, I worked as an application 
programmer on systems where SSN was stored in packed decimal. I'm sure 
that others did the same, or stored them in a fullword.

These would have to be changed if letters are allowed.

-- 
Tom Marchant

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

RCF: z/OS Version 2 Release 4 MVS JCL Reference, SA23-1385-40

[Seymour J Metz]

z/OS Version 2 Release 4 MVS JCL Reference, SA23-1385-40

The example on pages 94-95 of z/OS Version 2 Release 4 MVS JCL Reference, 
SA23-1385-40, is unclear. I might guess that the Converter makes the RECFM V or 
VB when it sees two lines of differing length, but nowhere can I find a 
statement to substantiate that. The text needs an explanation of how the LRECL 
is determined for instream datasets, and the text in the second data line 
should refer back to that explanation.



--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

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

Re: ESTBYTES Quandary

[Joe Monk]

JES2 limits do not apply to STCs.

https://groups.google.com/forum/#!msg/bit.listserv.ibm-main/1YPjynrHqBo/EN7BpmG6AQAJ

Joe

On Wed, Apr 22, 2020 at 7:58 AM Mark Jacobs <
0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:

> We've been trying to enforce limits on how much spool space a single job
> can use before it's canceled. We don't have any automation products, nor
> JES2 exits. The method that we're trying to use is ESYBYTES with OPT=1.
>
> On one system we've set it to this value, $HASP845 ESTBYTE
> NUM=478848,INT=9,OPT=1. We're still seeing jobs, in this case an STC
> exceeding that limit without being canceled.
>
> -- JES2 JOB STATISTICS --
>   20 APR 2020 JOB EXECUTION DATE
> 2 CARDS READ
> 9,777,572 SYSOUT PRINT RECORDS
> 0 SYSOUT PUNCH RECORDS
>   832,896 SYSOUT SPOOL KBYTES
>  2,970.04 MINUTES EXECUTION TIME
>
> There are no overrides of the system defined limits on the EXEC card.
>
> I'm at a loss on where to look further.
>
> Mark Jacobs
>
> Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted
> email.
>
> GPG Public Key -
> https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.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: UPDTE - CBT tape 496

[Seymour J Metz]

Caveat - I don't do windoze.

If you send me the Rexx and HLASM code I'll take a look at it. Are you using 
OOREXX or Regina?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robert Prins [robert.ah.pr...@gmail.com]
Sent: Wednesday, April 22, 2020 12:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: UPDTE - CBT tape 496

I've been using this for quite a while to upload data from Windows to z/OS,
merging in one case nearly 2,000 files into the required IEBUPDTE format, making
the transfer rather a lot easier. It always worked, uploading the data to a
VB/259/27998 dataset, but until now, Windows filenames have always been in the
old 8.3 format, where the 8 was really 8!

I've just now set up a bit more Windows code to do the same for other data, and
I've run into a problem, as the filenames are still in an 8.3 format, but the
name may be from 2 to 8 characters. And before you ask, the REXX exec that
creates the file on Windows upper-cases filenames, strips off the extension and
translates invalid characters, such as '-' & '_' into something that's valid in
a PDS member name.

UPDTE still works, but for whatever reason, membernames in the resulting PDS are
screwed up with what seem to be (part of) the initial RDW and in case the
filename on windows was only 2 characters, the first two characters of the next
record. The member data itself is correct.

I'd be grateful is anyone who knows more of assembler could have a book at this
and if possible, correct it.

Thanks,

Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com
The hitchhiking grandfather @ 
https://secure-web.cisco.com/1TzUo11Do-C5LKxloUuUT9p9zJvDVTV1xdi3jNDZMb28RfIQJdYMKVocEQStROwILnRFEwmCbwxsm1yXpj_MiUpHSjAxV44XG84SsDq-4P-aTgpzVc8Vntdq3oNdZTwBywCRXZalukWQBn-oOcGPDNgmbp_yMEFftTUbNBK0Uq_HH7YXL0VwDr5zOTaAOniH5N1K2bYuPbqRkz3DkmDez74nS9q9lKZQxGZjh78XK69ijv8tmhkg3EyhPt06fQi4Gw9DVGKfF9rmTG3ioW-EKWcZKhrutSKv4Uzv8K_3swXL_lFZUlqQ72G2oTN1GsLcFdR-PR-sQLoEanIAssb93C61C8JSqjHU10nnmKS6gwhEaA3sGVT2yhnTw18ZedWx3Wj96Vr67DQyyHs5TJThK8Te4BaAbfue5Fq6C2kdZ2Yf07vNel9tNnpkUBzpWcFSi/https%3A%2F%2Fprino.neocities.org%2Findez.html
Some useful(?) REXX @ 
https://secure-web.cisco.com/1bTJqtThLxh62QS6giMVoo7Kv6yWEUAePuvmhIS5AJr4eLxRPfVFnMQbLhY0uKeTA7OcmpYmtGJofWZCi3ok7C15J1orI7O6PeWdhqA8Hra9TBeiSC7kbCgz84ugSjqcE8S3MXN0TptmRiW5XghcADfhLj3VYDABsQBe6rkX7dRJQAZNbYL7usORMfQ_7Q1EoqkXzcKg2qSyNtEcRr_axAQTlHpAoGaMi1xiyqswIwIfuwG20b4neGdYzMqOzN4N9Q7qLsZntNhxL1NtsrJOa66NiaLq9W9kAcl_87O_pOnxIkjzgdxE43xFmSG9z05LqMCSjX-UfMiZD1-QUlt3VTTMglk5WV_lkIH5OOD9VGRPLOHU_nnlY5-HIXArIaieQsmV9o99s-A6h50qzqhsB2xI6BXzrBMG4n32YEWWoIBAv4ZsLZsvpZQlfJlAjZivz/https%3A%2F%2Fprino.neocities.org%2FzOS%2FzOS-Tools.html

--
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: UPDTE - CBT tape 496

[Robert Prins]

On 2020-04-22 14:06, Robert Prins wrote:
I've been using this for quite a while to upload data from Windows to z/OS, 
merging in one case nearly 2,000 files into the required IEBUPDTE format, making 
the transfer rather a lot easier. It always worked, uploading the data to a 
VB/259/27998 dataset, but until now, Windows filenames have always been in the 
old 8.3 format, where the 8 was really 8!


I've just now set up a bit more Windows code to do the same for other data, and 
I've run into a problem, as the filenames are still in an 8.3 format, but the 
name may be from 2 to 8 characters. And before you ask, the REXX exec that 
creates the file on Windows upper-cases filenames, strips off the extension and 
translates invalid characters, such as '-' & '_' into something that's valid in 
a PDS member name.


UPDTE still works, but for whatever reason, membernames in the resulting PDS are 
screwed up with what seem to be (part of) the initial RDW and in case the 
filename on windows was only 2 characters, the first two characters of the next 
record. The member data itself is correct.


I'd be grateful is anyone who knows more of assembler could have a book at this 
and if possible, correct it.


Additional: If I edit the uploaded-to-z/OS file, expand the filenames to 8 
characters using '¬' signs, save it, set "PRESERVE ON" and change the '¬' signs 
back to blanks, and save again, everything is OK.


Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com
The hitchhiking grandfather @ https://prino.neocities.org/indez.html
Some useful(?) REXX @ https://prino.neocities.org/zOS/zOS-Tools.html

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

UPDTE - CBT tape 496

[Robert Prins]

I've been using this for quite a while to upload data from Windows to z/OS, 
merging in one case nearly 2,000 files into the required IEBUPDTE format, making 
the transfer rather a lot easier. It always worked, uploading the data to a 
VB/259/27998 dataset, but until now, Windows filenames have always been in the 
old 8.3 format, where the 8 was really 8!


I've just now set up a bit more Windows code to do the same for other data, and 
I've run into a problem, as the filenames are still in an 8.3 format, but the 
name may be from 2 to 8 characters. And before you ask, the REXX exec that 
creates the file on Windows upper-cases filenames, strips off the extension and 
translates invalid characters, such as '-' & '_' into something that's valid in 
a PDS member name.


UPDTE still works, but for whatever reason, membernames in the resulting PDS are 
screwed up with what seem to be (part of) the initial RDW and in case the 
filename on windows was only 2 characters, the first two characters of the next 
record. The member data itself is correct.


I'd be grateful is anyone who knows more of assembler could have a book at this 
and if possible, correct it.


Thanks,

Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com
The hitchhiking grandfather @ https://prino.neocities.org/indez.html
Some useful(?) REXX @ https://prino.neocities.org/zOS/zOS-Tools.html

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

ESTBYTES Quandary

[Mark Jacobs]

We've been trying to enforce limits on how much spool space a single job can 
use before it's canceled. We don't have any automation products, nor JES2 
exits. The method that we're trying to use is ESYBYTES with OPT=1.

On one system we've set it to this value, $HASP845 ESTBYTE  
NUM=478848,INT=9,OPT=1. We're still seeing jobs, in this case an STC 
exceeding that limit without being canceled.

-- JES2 JOB STATISTICS --
  20 APR 2020 JOB EXECUTION DATE
2 CARDS READ
9,777,572 SYSOUT PRINT RECORDS
0 SYSOUT PUNCH RECORDS
  832,896 SYSOUT SPOOL KBYTES
 2,970.04 MINUTES EXECUTION TIME

There are no overrides of the system defined limits on the EXEC card.

I'm at a loss on where to look further.

Mark Jacobs

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

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

Re: JES2 SPOOLDEF TGSIZE recommendation sought [EXTERNAL]

[R.S.]

W dniu 22.04.2020 o 13:04, Feller, Paul pisze:

In two of our JES2 environments we use MOD-27s and in one other we use MOD-54s. 
 All three environments use TGSIZE=36.  I don't recall when it changed to 
TGSIZE=36, but it has been that way for years.  We have not seen any issues 
with either size volumes.  As Dave mentioned don't forget to set 
LARGEDS=ALLOWED.


Out of curiosity: Does anybody use EAV for spool? Any problems? 
Observations?


(I use mod-27 and mod-54 with TGSIZE=36)

--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Re: S0C4 in IARV64 GETSTOR storage (was ...IAVR64...)

[Joseph Reichman]

Apologies late last nite the high order bit 
Was on did a Load address on the base register to turn it off 

Thanks


On Apr 22, 2020, at 7:38 AM, Peter Relson  wrote:
> 
> 
>> 
>> The address was valid 
> 
> Wanna bet?
> 
> "Valid" includes "obtained successfully and not released yet" and "OK to 
> reference in your PSW key".
> One or the other is not the case.
> 
> AGAIN, where is your evidence? 
> 
> Peter Relson
> z/OS Core Technology Design
> 
> 
> --
> 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: S0C4 in IARV64 GETSTOR storage (was ...IAVR64...)

[Peter Relson]

>The address was valid 

Wanna bet?

"Valid" includes "obtained successfully and not released yet" and "OK to 
reference in your PSW key".
One or the other is not the case.

AGAIN, where is your evidence? 

Peter Relson
z/OS Core Technology Design


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