Re: Here we go again

[Dale R. Smith]

On Wed, 29 Apr 2020 20:48:23 -0500, Paul Gilmartin  wrote:

>On Wed, 29 Apr 2020 17:08:40 -0700, Charles Mills wrote:
>
>>PP 5740-CB1 RELEASE 2.4 IBM OS/VS COBOL JULY  1, 1982  19.03.21 DATE APR 
>>29,1920   
>> 
>Go to SR.  IBM took an APAR for me on a similar error in an IEBCOPY page
>header, but a hundred million times smaller.
>
>1982?
>
>-- gil

Don't bother!  :-)>

OS/VS COBOL hasn't been supported since 1994!  It was replaced by VS COBOL II, 
which eventually became Enterprise COBOL.

-- 
Dale R. Smith

--
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, 29 Apr 2020 17:08:40 -0700, Charles Mills wrote:

>PP 5740-CB1 RELEASE 2.4 IBM OS/VS COBOL JULY  1, 1982  19.03.21 DATE APR 
>29,1920   
> 
Go to SR.  IBM took an APAR for me on a similar error in an IEBCOPY page
header, but a hundred million times smaller.

1982?

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

PP 5740-CB1 RELEASE 2.4 IBM OS/VS COBOL JULY  1, 1982  19.03.21 DATE APR 
29,1920   

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rupert Reynolds
Sent: Wednesday, April 29, 2020 4:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again

On Wed, 22 Apr 2020, 19:29 Seymour J Metz,  wrote:

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

And thus was born the "Year 19100 bug" :-)

Rupert

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

[Rupert Reynolds]

On Wed, 22 Apr 2020, 19:29 Seymour J Metz,  wrote:

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

And thus was born the "Year 19100 bug" :-)

Rupert

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

Half the population of Australia didn't know what a recession is. They are
learnnig fast.

Now hearing "let's manufacture stuff". The robots will love that.

State owned steel company I worked at : 4,000,000 tons of off spec steel
with 8,000 employees.
Korean Steel company : 20,000,000 tons of quality with 800 employees.

There could be a shortage of horseshoes and farriers coming up.

On Wed, Apr 29, 2020 at 9:24 AM scott Ford  wrote:

> Seymour,
>
> Maybe I am too old school
>
> On Tue, Apr 28, 2020 at 5:24 PM Seymour J Metz  wrote:
>
> > ObKoheleth Why do people keep talking about 20-20 hindsight for issues
> > that had been discussed decades earlier?
> >
> >
> > --
> > 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: Tuesday, April 28, 2020 4:38 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Here we go again
> >
> > All:
> >
> > Trying to get the government to take action on something of the nature
> you
> > all are talking about takes time unfortunately.
> > Hindsight is 20/20 ...thats the problem i see with Cobol - Unemployment.
> > Lets get it done which is fine but no plan thats a big issue
> >
> > On Fri, Apr 24, 2020 at 5:39 AM R.S. 
> > wrote:
> >
> > > W dniu 22.04.2020 o 19:54, Pew, Curtis G pisze:
> > > > 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.
> > > >
> > >
> > > To complement: Y2K had a deadline. The date of implementation could not
> > > be changed.
> > > As someone described, there is approx 80 years to exhaust SSN space.
> So,
> > > let's assume:
> > > 5 years of doing nothing
> > > 5 years for designing the change and discussion
> > > 10 years for implementation the change
> > > another 5 years to help them who didn't do it yet
> > > another 5 years for them who still didn't do it.
> > > and there is still 50 years of buffer.
> > >
> > > My idea how to change SSN: simply add alpha character. Your existing
> SSN
> > > would become A 123-456-789. Of course an SSN without the prefix has the
> > > letter A by default.
> > > Then next SSNs would have B prefix. Then (how many years later?) C,
> then
> > > D...
> > > Not enough? Then start with two-letter prefix: AA, AB, AC...
> > >
> > >
> > >
> > > My €0.02
> > >
> > > --
> > > 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,
> > >
> >
> http://secure-web.cisco.com/17WTc2JX3gV0di7AdD_yIDCpkBfHqx-VjRS5ohRkN-KC_Tu9MY6uFmxTG99S_h2kOXOpR4RQVEOoC1K-7ztD9Jgs93AjUgoHG-6IoF4C6ZK23ZaXxXF-7qXw92hl9z8yzo4SKQs8987qntNnO08D-0xJTp24QOP8njwDIVYx1ZJG9rSK4ZP4KjYUrfF8pLuzTckPT8Chlkli_FC1PWwxuXdNGhv26psa1yE9acQvHTYjEQKiAuH8W8ogKBMHRWtO_nnRD38WGOYD-4_S6cioQPOb0jJZfwzi_nbkzv0cz6MxuMETS2MkSa61UnW7HcZhQCsmGkSFQ_OEfFZHce8L3UZpUyE_IG6Tuds0KkTKAFAkPlzTKXlyCm_Bqy1JWrZnj5CT-waiXJelygWhZ37nEBF30hWgHFCXs6S9bcRH2ggIVarGXmhrY9ifxQsU8-7n6/http%3A%2F%2Fwww.mBank.pl
> ,
> > e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy
> > > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237,
> NIP:
>

Re: Here we go again

[scott Ford]

Seymour,

Maybe I am too old school

On Tue, Apr 28, 2020 at 5:24 PM Seymour J Metz  wrote:

> ObKoheleth Why do people keep talking about 20-20 hindsight for issues
> that had been discussed decades earlier?
>
>
> --
> 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: Tuesday, April 28, 2020 4:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again
>
> All:
>
> Trying to get the government to take action on something of the nature you
> all are talking about takes time unfortunately.
> Hindsight is 20/20 ...thats the problem i see with Cobol - Unemployment.
> Lets get it done which is fine but no plan thats a big issue
>
> On Fri, Apr 24, 2020 at 5:39 AM R.S. 
> wrote:
>
> > W dniu 22.04.2020 o 19:54, Pew, Curtis G pisze:
> > > 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.
> > >
> >
> > To complement: Y2K had a deadline. The date of implementation could not
> > be changed.
> > As someone described, there is approx 80 years to exhaust SSN space. So,
> > let's assume:
> > 5 years of doing nothing
> > 5 years for designing the change and discussion
> > 10 years for implementation the change
> > another 5 years to help them who didn't do it yet
> > another 5 years for them who still didn't do it.
> > and there is still 50 years of buffer.
> >
> > My idea how to change SSN: simply add alpha character. Your existing SSN
> > would become A 123-456-789. Of course an SSN without the prefix has the
> > letter A by default.
> > Then next SSNs would have B prefix. Then (how many years later?) C, then
> > D...
> > Not enough? Then start with two-letter prefix: AA, AB, AC...
> >
> >
> >
> > My €0.02
> >
> > --
> > 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,
> >
> http://secure-web.cisco.com/17WTc2JX3gV0di7AdD_yIDCpkBfHqx-VjRS5ohRkN-KC_Tu9MY6uFmxTG99S_h2kOXOpR4RQVEOoC1K-7ztD9Jgs93AjUgoHG-6IoF4C6ZK23ZaXxXF-7qXw92hl9z8yzo4SKQs8987qntNnO08D-0xJTp24QOP8njwDIVYx1ZJG9rSK4ZP4KjYUrfF8pLuzTckPT8Chlkli_FC1PWwxuXdNGhv26psa1yE9acQvHTYjEQKiAuH8W8ogKBMHRWtO_nnRD38WGOYD-4_S6cioQPOb0jJZfwzi_nbkzv0cz6MxuMETS2MkSa61UnW7HcZhQCsmGkSFQ_OEfFZHce8L3UZpUyE_IG6Tuds0KkTKAFAkPlzTKXlyCm_Bqy1JWrZnj5CT-waiXJelygWhZ37nEBF30hWgHFCXs6S9bcRH2ggIVarGXmhrY9ifxQsU8-7n6/http%3A%2F%2Fwww.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,
> http://secure-web.cisco.com/17WTc2JX3gV0di7AdD_yIDCpkBfHqx-VjRS5ohRkN-KC_Tu9MY6uFmxTG99S_h2kOXOpR4RQVEOoC1K-7ztD9Jgs93AjUgoHG-6IoF4C6ZK23ZaXxXF-7

Re: Here we go again

[Seymour J Metz]

ObKoheleth Why do people keep talking about 20-20 hindsight for issues that had 
been discussed decades earlier?


--
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: Tuesday, April 28, 2020 4:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again

All:

Trying to get the government to take action on something of the nature you
all are talking about takes time unfortunately.
Hindsight is 20/20 ...thats the problem i see with Cobol - Unemployment.
Lets get it done which is fine but no plan thats a big issue

On Fri, Apr 24, 2020 at 5:39 AM R.S.  wrote:

> W dniu 22.04.2020 o 19:54, Pew, Curtis G pisze:
> > 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.
> >
>
> To complement: Y2K had a deadline. The date of implementation could not
> be changed.
> As someone described, there is approx 80 years to exhaust SSN space. So,
> let's assume:
> 5 years of doing nothing
> 5 years for designing the change and discussion
> 10 years for implementation the change
> another 5 years to help them who didn't do it yet
> another 5 years for them who still didn't do it.
> and there is still 50 years of buffer.
>
> My idea how to change SSN: simply add alpha character. Your existing SSN
> would become A 123-456-789. Of course an SSN without the prefix has the
> letter A by default.
> Then next SSNs would have B prefix. Then (how many years later?) C, then
> D...
> Not enough? Then start with two-letter prefix: AA, AB, AC...
>
>
>
> My €0.02
>
> --
> 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,
> http://secure-web.cisco.com/17WTc2JX3gV0di7AdD_yIDCpkBfHqx-VjRS5ohRkN-KC_Tu9MY6uFmxTG99S_h2kOXOpR4RQVEOoC1K-7ztD9Jgs93AjUgoHG-6IoF4C6ZK23ZaXxXF-7qXw92hl9z8yzo4SKQs8987qntNnO08D-0xJTp24QOP8njwDIVYx1ZJG9rSK4ZP4KjYUrfF8pLuzTckPT8Chlkli_FC1PWwxuXdNGhv26psa1yE9acQvHTYjEQKiAuH8W8ogKBMHRWtO_nnRD38WGOYD-4_S6cioQPOb0jJZfwzi_nbkzv0cz6MxuMETS2MkSa61UnW7HcZhQCsmGkSFQ_OEfFZHce8L3UZpUyE_IG6Tuds0KkTKAFAkPlzTKXlyCm_Bqy1JWrZnj5CT-waiXJelygWhZ37nEBF30hWgHFCXs6S9bcRH2ggIVarGXmhrY9ifxQsU8-7n6/http%3A%2F%2Fwww.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,http://secure-web.cisco.com/17WTc2JX3gV0di7AdD_yIDCpkBfHqx-VjRS5ohRkN-KC_Tu9MY6uFmxTG99S_h2kOXOpR4RQVEOoC1K-7ztD9Jgs93AjUgoHG-6IoF4C6ZK23ZaXxXF-7qXw92hl9z8yzo4SKQs8987qntNnO08D-0xJTp24QOP8njwDIVYx1ZJG9rSK4ZP4KjYUrfF8pLuzTckPT8Chlkli_FC1PWwxuXdNGhv26psa1yE9acQvHTYjEQKiAuH8W8ogKBMHRWtO_nnRD38WGOYD-4_S6cioQPOb0jJZfwzi_nbkzv0cz6MxuMETS2MkSa61UnW7HcZhQCsmGkSFQ_OEfFZHce8L3UZpUyE_IG6Tuds0KkTKAFAkPlzTKXlyCm_Bqy1JWrZnj5CT-waiXJelygWhZ37nEBF30hWgHFCXs6S9bcRH2ggIVarGXmhrY9ifxQsU8-7n6/http%3A%2F%2Fwww.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
> 

Re: Here we go again

[scott Ford]

All:

Trying to get the government to take action on something of the nature you
all are talking about takes time unfortunately.
Hindsight is 20/20 ...thats the problem i see with Cobol - Unemployment.
Lets get it done which is fine but no plan thats a big issue

On Fri, Apr 24, 2020 at 5:39 AM R.S.  wrote:

> W dniu 22.04.2020 o 19:54, Pew, Curtis G pisze:
> > 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.
> >
>
> To complement: Y2K had a deadline. The date of implementation could not
> be changed.
> As someone described, there is approx 80 years to exhaust SSN space. So,
> let's assume:
> 5 years of doing nothing
> 5 years for designing the change and discussion
> 10 years for implementation the change
> another 5 years to help them who didn't do it yet
> another 5 years for them who still didn't do it.
> and there is still 50 years of buffer.
>
> My idea how to change SSN: simply add alpha character. Your existing SSN
> would become A 123-456-789. Of course an SSN without the prefix has the
> letter A by default.
> Then next SSNs would have B prefix. Then (how many years later?) C, then
> D...
> Not enough? Then start with two-letter prefix: AA, AB, AC...
>
>
>
> My €0.02
>
> --
> 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
>


-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

[R.S.]

W dniu 22.04.2020 o 19:54, Pew, Curtis G pisze:

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.



To complement: Y2K had a deadline. The date of implementation could not 
be changed.
As someone described, there is approx 80 years to exhaust SSN space. So, 
let's assume:

5 years of doing nothing
5 years for designing the change and discussion
10 years for implementation the change
another 5 years to help them who didn't do it yet
another 5 years for them who still didn't do it.
and there is still 50 years of buffer.

My idea how to change SSN: simply add alpha character. Your existing SSN 
would become A 123-456-789. Of course an SSN without the prefix has the 
letter A by default.
Then next SSNs would have B prefix. Then (how many years later?) C, then 
D...

Not enough? Then start with two-letter prefix: AA, AB, AC...



My €0.02

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

[Seymour J Metz]

ObTheElements And there may be many others but the haven't been discovard.

> byte sizes: 6, 8, 12 bits

byte sizes: 6, 8, 9, 12, 18 bits

In addition, the IBM 7030 could address to the bit level with byte size from 
1-8 and both CDC 3600/3800 and DEC PDP-6/PDP-10 had special instruction with 
variable byte sizes up to a word.

> word size: 16, 18, 22, 24, 32, 36, 48, 60, 64

word size: 8, 12, 16, 18, 22, 24, 25, 30, 32, 36, 48, 60, 64

> address size: 16, 18, 22, 24, 31, 32, ...

address size: 12, 15, 16, 18, 22, 24, 31, 32, ... (binary), 

3 digits with zone bits extending, 4 digits, 4 digits with zone bits extending, 
5 digits zoned for index registers

> number format: 2's complement, 1's complement, sign/magnitude

number format: 2's complement, 1's complement, sign/magnitude (binary),

decimal with 2-valued sign, decimal with three-valued sign, ternary (rare)



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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bernd Oppolzer [bernd.oppol...@t-online.de]
Sent: Thursday, April 23, 2020 6:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

 From today's point of view some people think that 8 bit bytes and 32
bit words have existed forever.

In contrast:

byte sizes: 6, 8, 12 bits
word size: 16, 18, 22, 24, 32, 36, 48, 60, 64
address size: 16, 18, 22, 24, 31, 32, ...
number format: 2's complement, 1's complement, sign/magnitude

from the late 1960s until mid of the 1980s, we had a machine in Germany
with
48 bits word size - in fact: 48 + 2 tag bits (visible to the programmer)
+ 2 parity bits
24 bits instruction and address size (halfwords addressable, words have
even addresses)
bytes of 6, 8 or 12 bits (words can have 8, 6 or 4 bytes) - 12 bit bytes
used by Fortran (INTEGER*4) - in fact 8 bits and 4 zeros
some special instructions can address 8 bit bytes ("Oktadenadressen") -
8 bit bytes used by COBOL, Pascal etc.
and: 1's complement

other languages on that machine: PL/1, ALGOL, BCPL
and the machine had a very powerful time-sharing dialog system (for
developers)
some 50 machines of this type have been built, one costed about 20
millions Deutsche Marks
used by universities, research institutes, some government agencies and
the German army

http://secure-web.cisco.com/1lQolVNWjcYS8XwP7VcCWePm_L1XGHYXHyrHVmNDaYxSkX9CdBOZ_UecGUAsFm90a-8kmj13CkjyHpPjdzoy_whR8llRYhC6RkaHTPCu0Gv_fUVdtxKTta8YXaF4CE8MKa267JK4Jugh65fPNd9LV0hkIn8-U8DorFkLrmf1fjIHT-4O2zTJERXK3wQwiq-iG3zNNENbNI9NVtCtB2UqruKGY5Lcvxk9vluGX-m2ue2NpSV4iMhkfwdCUlbdKka7yKkUPHuK5oJKKsjLuwWYJGFxTINcmmoVeUhbszAOhxIoXJs7DQk4agCV4g40hRzJjjXcnAJC1pcmJq1t0mNph87A-OHd-geLtfE3IoeTPPPg4v4kVwMaTpq2bzilpKc93vWMQhi2MdknzkWQv9sl6aaCFDN-6h1rM15cm38MyRrqiUWZg3Ge2A5XSOsC6HxQ3/http%3A%2F%2Fwww.vaxman.de%2Fhistoric_computers%2Ftelefunken%2Ftr440%2Ftr440.html
https://secure-web.cisco.com/1FKOjaqiwbtskc9RnVC0xTy-s_hB6VbYqx1qTuNj-henTFBSVsgdM1QzVUa35ZU0JNMcnqQFSitJox_C24pAkYWWy74BAVeHjY8PlGTxdMncu1zdcOGHEJ2TFYIwBySY3UMNduY2StT7MXy_QRjgwjLpWP3K3q342YEzk_RD1TaZNCU2p6iS_xOYCEyvmmkjdXSasJ4Ag6agx8rV4DtcTygRdOxsywiD_C-ymMy9JkdY3vCV7M3tIjpOQG_vereINJFvvoaz6XBaaQavStIsDVaTpd-ictoZfFL_qgWDBhdev_-2-dTyEZhI7koo-LvpDPm-S1uR3PpXpeSwDRnEVqOoQfJmBBU-BZzSfTtckcsOWOZfyUFuG3HPhTtroApk-2DNMPkuLrZpAO9sYd0agvHWE2Cf7E26dpUGsjdYqLb-In3KAKX321g8MCZHh0lHe/https%3A%2F%2Fde.wikipedia.org%2Fwiki%2FTR_440

Kind regards

Bernd


Am 23.04.2020 um 23:33 schrieb Seymour J Metz:
> ?
>
> Byte addressing on the 1106 was direct, specified in the j field of the 
> instruction. Indirect addressing only used the right 22 bits of the indirect 
> address word. At least on the 1106 you had a choice of byte sizes.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Pierre Fichaud [pr...@videotron.ca]
> Sent: Thursday, April 23, 2020 3:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again;
>
> I remember one summer working on a Univac-1106 in assembler.
> Ones complement, 36 bit-words.
> Indirect addressing to a byte.
> I wasn't crazy about it having come from the IBM world and direct byte
> addressability.
>
> But it was a job.
>
> Pierre.
>
> --
> 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

Re: Here we go again;

[Bernd Oppolzer]

From today's point of view some people think that 8 bit bytes and 32 
bit words have existed forever.


In contrast:

byte sizes: 6, 8, 12 bits
word size: 16, 18, 22, 24, 32, 36, 48, 60, 64
address size: 16, 18, 22, 24, 31, 32, ...
number format: 2's complement, 1's complement, sign/magnitude

from the late 1960s until mid of the 1980s, we had a machine in Germany 
with
48 bits word size - in fact: 48 + 2 tag bits (visible to the programmer) 
+ 2 parity bits
24 bits instruction and address size (halfwords addressable, words have 
even addresses)
bytes of 6, 8 or 12 bits (words can have 8, 6 or 4 bytes) - 12 bit bytes 
used by Fortran (INTEGER*4) - in fact 8 bits and 4 zeros
some special instructions can address 8 bit bytes ("Oktadenadressen") - 
8 bit bytes used by COBOL, Pascal etc.

and: 1's complement

other languages on that machine: PL/1, ALGOL, BCPL
and the machine had a very powerful time-sharing dialog system (for 
developers)
some 50 machines of this type have been built, one costed about 20 
millions Deutsche Marks
used by universities, research institutes, some government agencies and 
the German army


http://www.vaxman.de/historic_computers/telefunken/tr440/tr440.html
https://de.wikipedia.org/wiki/TR_440

Kind regards

Bernd


Am 23.04.2020 um 23:33 schrieb Seymour J Metz:

?

Byte addressing on the 1106 was direct, specified in the j field of the 
instruction. Indirect addressing only used the right 22 bits of the indirect 
address word. At least on the 1106 you had a choice of byte sizes.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Pierre Fichaud [pr...@videotron.ca]
Sent: Thursday, April 23, 2020 3:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

I remember one summer working on a Univac-1106 in assembler.
Ones complement, 36 bit-words.
Indirect addressing to a byte.
I wasn't crazy about it having come from the IBM world and direct byte
addressability.

But it was a job.

Pierre.

--
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; Memory Lane

[Joe Monk]

You might like this website: https://mrxhist.org

Joe

On Thu, Apr 23, 2020 at 3:48 PM Christopher Y. Blaicher <
cblaic...@syncsort.com> wrote:

> At one point I worked on a Memorex 1380 (for Memorex).  It was a
> programmable telecommunications front end like the IBM 3705.
> I wrote SDLC code for it.  It had its own assembler.  It was a fun
> machine, but so long ago I can't remember much.
>
> Chris Blaicher
> Technical Architect
> Syncsort, Inc.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Pierre Fichaud
> Sent: Thursday, April 23, 2020 3:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again;
>
> [ External - This message originated Externally.  Use proper judgement and
> caution with attachments, links, or responses. ]
>
> I remember one summer working on a Univac-1106 in assembler.
> Ones complement, 36 bit-words.
> Indirect addressing to a byte.
> I wasn't crazy about it having come from the IBM world and direct byte
> addressability.
>
> But it was a job.
>
> Pierre.
>
> --
> 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;

[Seymour J Metz]

?

Byte addressing on the 1106 was direct, specified in the j field of the 
instruction. Indirect addressing only used the right 22 bits of the indirect 
address word. At least on the 1106 you had a choice of byte sizes.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Pierre Fichaud [pr...@videotron.ca]
Sent: Thursday, April 23, 2020 3:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

I remember one summer working on a Univac-1106 in assembler.
Ones complement, 36 bit-words.
Indirect addressing to a byte.
I wasn't crazy about it having come from the IBM world and direct byte
addressability.

But it was a job.

Pierre.

--
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; Memory Lane

[Christopher Y. Blaicher]

At one point I worked on a Memorex 1380 (for Memorex).  It was a programmable 
telecommunications front end like the IBM 3705.
I wrote SDLC code for it.  It had its own assembler.  It was a fun machine, but 
so long ago I can't remember much.

Chris Blaicher
Technical Architect
Syncsort, Inc.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pierre Fichaud
Sent: Thursday, April 23, 2020 3:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

[ External - This message originated Externally.  Use proper judgement and 
caution with attachments, links, or responses. ]

I remember one summer working on a Univac-1106 in assembler.
Ones complement, 36 bit-words.
Indirect addressing to a byte.
I wasn't crazy about it having come from the IBM world and direct byte 
addressability.

But it was a job.

Pierre.

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

[Pierre Fichaud]

I remember one summer working on a Univac-1106 in assembler.
Ones complement, 36 bit-words.
Indirect addressing to a byte.
I wasn't crazy about it having come from the IBM world and direct byte 
addressability.


But it was a job.

Pierre.

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

Where did you think I picked up the phrase? I've also used it for a 4Kx4K 
monitor back when they cost as much as a house.


--
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: Thursday, April 23, 2020 12:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

Hi R'Shmuel,
You said: "...  I had lust in my heart ..."
This is reminiscent of a former US president.

Regards,
David

On 2020-04-23 12:04, Seymour J Metz wrote:
> CDC until STAR-100 and UNIVAC until 360 compatible line. There were some 
> smaller companies that used it, but I can't remember who they were. My 
> hands-on experience with 1s' complement was with the CDC 6400 and the UNIVAC 
> 1230, although I had lust in my heart for the CDC 3600..
>
>
> --
> Shmuel (Seymour J.) Metz
> https://eur04.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7C46dd520a166449a9cd0508d7e7a01440%7C84df9e7fe9f640afb435%7C1%7C0%7C637232547029007963sdata=6Tc%2BdMoQWcieXngCXVB9X6a8A5Osis8Sul4WX4yQtXs%3Dreserved=0
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> David Spiegel [dspiegel...@hotmail.com]
> Sent: Thursday, April 23, 2020 11:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again;
>
> 1s' complement as in ... CDC?
> (I used to program FORTRAN on CDC and had to deal with "Negative Zeroes".)
>
> On 2020-04-23 11:37, Seymour J Metz wrote:
>> Real programmers use ones' complement ;-)
>>
>> I don't know of any machine that uses a ten's complement representation, but 
>> the idea is appealing.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> https://eur04.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7C46dd520a166449a9cd0508d7e7a01440%7C84df9e7fe9f640afb435%7C1%7C0%7C637232547029007963sdata=6Tc%2BdMoQWcieXngCXVB9X6a8A5Osis8Sul4WX4yQtXs%3Dreserved=0
>>
>> 
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>> Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
>> Sent: Thursday, April 23, 2020 10:21 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Here we go again;
>>
>> On Thu, 23 Apr 2020 13:50:48 +0200, R.S. wrote:
>>> It wasn't single byte per record in single table! It was (it *IS*)
>>> element of some culture - to avoid dummy characters.
>>> How many? It depends. For well constructed record the room for savings
>>> is zero or close to zero.
>>> For PFCSK ever date contains separators (2020-04-22 14:55:12), fields
>>> are separated by blank etc.
>>>
>> I once wondered in these lists why, while F-type values wisely use
>> 2's complement, P-type values are sign magnitude where 10's
>> complement would provide 5 times the range in the same storage
>> and avoid the need for a possible recomplement after subtraction.
>>
>> The response seems to be that 10's complement representation of
>> negative values is unintuitive.  That strikes me as PFCSK-think.
>>
>> Of course, there's the argument about reading dumps.
>>
>> -- 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
>> .
> --
> 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;

[Seymour J Metz]

I meant that CDC stopped being exclusively 1s' complement with the STAR-100 
(which they later spun off, alas.)

Why should I breathe a sigh of relief? I hate lust in my heart for the 3600 and 
would have been perfectly happy to see the Cyber line remain viable.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
William Donzelli [wdonze...@gmail.com]
Sent: Thursday, April 23, 2020 12:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

> CDC until STAR-100

Well, actually CDC until the bitter end. Cyber 180s, introduced in the
early 1980s could do both.

The bitter end was last year, so you IBM guys can finally breathe a
sigh of relief with that bit of competition off the table.

--
Will

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

[William Donzelli]

> CDC until STAR-100

Well, actually CDC until the bitter end. Cyber 180s, introduced in the
early 1980s could do both.

The bitter end was last year, so you IBM guys can finally breathe a
sigh of relief with that bit of competition off the table.

--
Will

--
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 11:43:53 -0400, David Spiegel wrote:

>1s' complement as in ... CDC?
>(I used to program FORTRAN on CDC and had to deal with "Negative Zeroes".)
>
Also needs to be dealt with in sign-magnitude.

And sign-magnitude has a symmetric range, which numerical analysts
care about somehow.  Or maybe it's the symmetric rounding.

My FORTRAN colleagues moving from 7090 or CDC  to 360 were dismayed
that there was no way to identify a blank numeric field which the older
systems had read in as  "Negative Zero".


>On 2020-04-23 11:37, Seymour J Metz wrote:
>> Real programmers use ones' complement ;-)
>>
>> I don't know of any machine that uses a ten's complement representation, but 
>> the idea is appealing.


On Thu, 23 Apr 2020 10:07:50 -0500, Tom Marchant  
wrote:
>
>From Architecture of the IBM System/360, by Amdahl, Blaauw, and 
>Brooks. Published in the IBM Journal, April, 1964.
>
>
>The established commercial rounding convention made
>the use of complement notation awkward for decimal
>data; therefore, absolute-value-plus-sign is used here.
>
>
Thanks.  GAAP strikes again.

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

[David Spiegel]

Hi R'Shmuel,
You said: "...  I had lust in my heart ..."
This is reminiscent of a former US president.

Regards,
David

On 2020-04-23 12:04, Seymour J Metz wrote:

CDC until STAR-100 and UNIVAC until 360 compatible line. There were some 
smaller companies that used it, but I can't remember who they were. My hands-on 
experience with 1s' complement was with the CDC 6400 and the UNIVAC 1230, 
although I had lust in my heart for the CDC 3600..


--
Shmuel (Seymour J.) Metz
https://eur04.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7C46dd520a166449a9cd0508d7e7a01440%7C84df9e7fe9f640afb435%7C1%7C0%7C637232547029007963sdata=6Tc%2BdMoQWcieXngCXVB9X6a8A5Osis8Sul4WX4yQtXs%3Dreserved=0


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Spiegel [dspiegel...@hotmail.com]
Sent: Thursday, April 23, 2020 11:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

1s' complement as in ... CDC?
(I used to program FORTRAN on CDC and had to deal with "Negative Zeroes".)

On 2020-04-23 11:37, Seymour J Metz wrote:

Real programmers use ones' complement ;-)

I don't know of any machine that uses a ten's complement representation, but 
the idea is appealing.


--
Shmuel (Seymour J.) Metz
https://eur04.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7C46dd520a166449a9cd0508d7e7a01440%7C84df9e7fe9f640afb435%7C1%7C0%7C637232547029007963sdata=6Tc%2BdMoQWcieXngCXVB9X6a8A5Osis8Sul4WX4yQtXs%3Dreserved=0


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

On Thu, 23 Apr 2020 13:50:48 +0200, R.S. wrote:

It wasn't single byte per record in single table! It was (it *IS*)
element of some culture - to avoid dummy characters.
How many? It depends. For well constructed record the room for savings
is zero or close to zero.
For PFCSK ever date contains separators (2020-04-22 14:55:12), fields
are separated by blank etc.


I once wondered in these lists why, while F-type values wisely use
2's complement, P-type values are sign magnitude where 10's
complement would provide 5 times the range in the same storage
and avoid the need for a possible recomplement after subtraction.

The response seems to be that 10's complement representation of
negative values is unintuitive.  That strikes me as PFCSK-think.

Of course, there's the argument about reading dumps.

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

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

[Seymour J Metz]

CDC until STAR-100 and UNIVAC until 360 compatible line. There were some 
smaller companies that used it, but I can't remember who they were. My hands-on 
experience with 1s' complement was with the CDC 6400 and the UNIVAC 1230, 
although I had lust in my heart for the CDC 3600..


--
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: Thursday, April 23, 2020 11:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

1s' complement as in ... CDC?
(I used to program FORTRAN on CDC and had to deal with "Negative Zeroes".)

On 2020-04-23 11:37, Seymour J Metz wrote:
> Real programmers use ones' complement ;-)
>
> I don't know of any machine that uses a ten's complement representation, but 
> the idea is appealing.
>
>
> --
> Shmuel (Seymour J.) Metz
> https://nam10.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7C7343764574a748ceaa7808d7e79c42af%7C84df9e7fe9f640afb435%7C1%7C0%7C637232530624151412sdata=O4UDTjodAoUB7pOFbMMf5Z8uwwixQnB6dSNu9XF0hpY%3Dreserved=0
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
> Sent: Thursday, April 23, 2020 10:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again;
>
> On Thu, 23 Apr 2020 13:50:48 +0200, R.S. wrote:
>> It wasn't single byte per record in single table! It was (it *IS*)
>> element of some culture - to avoid dummy characters.
>> How many? It depends. For well constructed record the room for savings
>> is zero or close to zero.
>> For PFCSK ever date contains separators (2020-04-22 14:55:12), fields
>> are separated by blank etc.
>>
> I once wondered in these lists why, while F-type values wisely use
> 2's complement, P-type values are sign magnitude where 10's
> complement would provide 5 times the range in the same storage
> and avoid the need for a possible recomplement after subtraction.
>
> The response seems to be that 10's complement representation of
> negative values is unintuitive.  That strikes me as PFCSK-think.
>
> Of course, there's the argument about reading dumps.
>
> -- 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
> .

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

1s' complement as in ... CDC?
(I used to program FORTRAN on CDC and had to deal with "Negative Zeroes".)

On 2020-04-23 11:37, Seymour J Metz wrote:

Real programmers use ones' complement ;-)

I don't know of any machine that uses a ten's complement representation, but 
the idea is appealing.


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


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

On Thu, 23 Apr 2020 13:50:48 +0200, R.S. wrote:

It wasn't single byte per record in single table! It was (it *IS*)
element of some culture - to avoid dummy characters.
How many? It depends. For well constructed record the room for savings
is zero or close to zero.
For PFCSK ever date contains separators (2020-04-22 14:55:12), fields
are separated by blank etc.


I once wondered in these lists why, while F-type values wisely use
2's complement, P-type values are sign magnitude where 10's
complement would provide 5 times the range in the same storage
and avoid the need for a possible recomplement after subtraction.

The response seems to be that 10's complement representation of
negative values is unintuitive.  That strikes me as PFCSK-think.

Of course, there's the argument about reading dumps.

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


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

Real programmers use ones' complement ;-)

I don't know of any machine that uses a ten's complement representation, but 
the idea is appealing.


--
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: Thursday, April 23, 2020 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

On Thu, 23 Apr 2020 13:50:48 +0200, R.S. wrote:
>
>It wasn't single byte per record in single table! It was (it *IS*)
>element of some culture - to avoid dummy characters.
>How many? It depends. For well constructed record the room for savings
>is zero or close to zero.
>For PFCSK ever date contains separators (2020-04-22 14:55:12), fields
>are separated by blank etc.
>
I once wondered in these lists why, while F-type values wisely use
2's complement, P-type values are sign magnitude where 10's
complement would provide 5 times the range in the same storage
and avoid the need for a possible recomplement after subtraction.

The response seems to be that 10's complement representation of
negative values is unintuitive.  That strikes me as PFCSK-think.

Of course, there's the argument about reading dumps.

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

[Tom Marchant]

On Thu, 23 Apr 2020 09:21:16 -0500, Paul Gilmartin wrote:

>I once wondered in these lists why, while F-type values wisely use
>2's complement, P-type values are sign magnitude where 10's
>complement would provide 5 times the range in the same storage
>and avoid the need for a possible recomplement after subtraction.

From Architecture of the IBM System/360, by Amdahl, Blaauw, and 
Brooks. Published in the IBM Journal, April, 1964.


The established commercial rounding convention made
the use of complement notation awkward for decimal
data; therefore, absolute-value-plus-sign is used here.


-- 
Tom Marchant

--
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 13:50:48 +0200, R.S. wrote:
>
>It wasn't single byte per record in single table! It was (it *IS*)
>element of some culture - to avoid dummy characters.
>How many? It depends. For well constructed record the room for savings
>is zero or close to zero.
>For PFCSK ever date contains separators (2020-04-22 14:55:12), fields
>are separated by blank etc.
>
I once wondered in these lists why, while F-type values wisely use
2's complement, P-type values are sign magnitude where 10's
complement would provide 5 times the range in the same storage
and avoid the need for a possible recomplement after subtraction.

The response seems to be that 10's complement representation of
negative values is unintuitive.  That strikes me as PFCSK-think.

Of course, there's the argument about reading dumps.

-- 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 20:44:43 -0700, in bit.listserv.ibm-main
g...@gabegold.com (Gabe Goldberg) wrote:

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

One of the disquieting things for me at SHARE Y2K sessions was all the
money banks and insurance companies were spending on Y2K.

Clark Morris
>
>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.)

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

[PINION, RICHARD W.]

Some other things I have observed.  Sequentially searching large arrays
for each input record, when the input data set contained 100,000's of 
records.  Use of DISPLAY DECIMAL or COMP-3 subscripts instead of INDEX's
or at the very least using a COMP subscript.  

Switching to SEARCH ALL and INDEX's can save large amounts of wall clock
time and CPU time.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Thursday, April 23, 2020 7:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: Here we go again;

[External Email. Exercise caution when clicking links or opening attachments.]

Adam,
Believe me or not, but I (my folks) saved a lot of space by changing BLKSIZE to 
correct one, means SDB. It was not only JCL, but also COBOL.
What is "a lot of space"? It was enough free space on our huge 500GB DASD box 
to NOT PURCHASE ANOTHER BOX. Multiply it x2, because we used PPRC.
We also saved a lot of space by elimination of redundant jobs and datasets. 
However the main goal was to make batch time shorter.
Few years later we saved a lot of space by using extended format PS and 
compression - for selected datasets.
Few years ago we saved a lot of space by using zEDC almost everywhere.

Optimization is still valid, even today. It was extremely valid 30 or years ago 
due to DASD capacity and prices.
We did it, we do it, we will do it.

--
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
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

[PINION, RICHARD W.]

Fully agree with all of that.  In addition, proper blocking will reduce CPU and 
DASD connect time.  The worst offenders, are the ones who hard code block
size in the COBOL programs.  Case in point, application program specified a
block size equal to record length, writing to tape.  The job ran for several
hours each week.  Coding BLOCK CONTAINS 0 in the program, and using
SDB, the job ran in less than one hour.  Not to mention, the savings in the
number of tapes used (VTS).

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Thursday, April 23, 2020 7:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: Here we go again;

[External Email. Exercise caution when clicking links or opening attachments.]

Adam,
Believe me or not, but I (my folks) saved a lot of space by changing BLKSIZE to 
correct one, means SDB. It was not only JCL, but also COBOL.
What is "a lot of space"? It was enough free space on our huge 500GB DASD box 
to NOT PURCHASE ANOTHER BOX. Multiply it x2, because we used PPRC.
We also saved a lot of space by elimination of redundant jobs and datasets. 
However the main goal was to make batch time shorter.
Few years later we saved a lot of space by using extended format PS and 
compression - for selected datasets.
Few years ago we saved a lot of space by using zEDC almost everywhere.

Optimization is still valid, even today. It was extremely valid 30 or years ago 
due to DASD capacity and prices.
We did it, we do it, we will do it.

--
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
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

[R.S.]

W dniu 22.04.2020 o 22:04, Phil Smith III pisze:

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


It wasn't single byte per record in single table! It was (it *IS*) 
element of some culture - to avoid dummy characters.
How many? It depends. For well constructed record the room for savings 
is zero or close to zero.
For PFCSK ever date contains separators (2020-04-22 14:55:12), fields 
are separated by blank etc.
It can be few bytes per EVERY RECORD IN almost EVERY TABLE. The example 
above - at least 5 bytes in date, let's assume also 6 bytes for field 
separation, 4 another junk and LRECL=400. We have 400 vs 385. 3.75% Is 
it huge difference? For current storage prices (2M assumed) it will be 
$37,500.

This is the cost of 5 minutes thinking.
Add improper blocksize, redundant datasets, lack of compression, poor 
migration policy, etc.


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

[R.S.]

Adam,
Believe me or not, but I (my folks) saved a lot of space by changing 
BLKSIZE to correct one, means SDB. It was not only JCL, but also COBOL.
What is "a lot of space"? It was enough free space on our huge 500GB 
DASD box to NOT PURCHASE ANOTHER BOX. Multiply it x2, because we used PPRC.
We also saved a lot of space by elimination of redundant jobs and 
datasets. However the main goal was to make batch time shorter.
Few years later we saved a lot of space by using extended format PS and 
compression - for selected datasets.

Few years ago we saved a lot of space by using zEDC almost everywhere.

Optimization is still valid, even today. It was extremely valid 30 or 
years ago due to DASD capacity and prices.

We did it, we do it, we will do it.

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

[Seymour J Metz]

WTF? How is answering Gil's questions about CLIST dissecting your code? Would 
you have answered RYFM?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Wayne Bickerdike [wayn...@gmail.com]
Sent: Thursday, April 23, 2020 3:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again;

Wow, code an example and it gets totally dissected. I'll  write the next
"you beaut line of code" and you guys can QA it. Is that how Oracle got so
big?



On Thu, Apr 23, 2020 at 1:27 PM Seymour J Metz  wrote:

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


--
Wayne V. Bickerdike

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

Fair play Wayne! At least you can still remember CLIST! I recently had 
to convert some CLIST code to REXX and it was about as much fun as a 
holiday in the Sahara!


On 2020-04-23 3:24 PM, Wayne Bickerdike wrote:

Wow, code an example and it gets totally dissected. I'll  write the next
"you beaut line of code" and you guys can QA it. Is that how Oracle got so
big?



On Thu, Apr 23, 2020 at 1:27 PM Seymour J Metz  wrote:


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





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

Wow, code an example and it gets totally dissected. I'll  write the next
"you beaut line of code" and you guys can QA it. Is that how Oracle got so
big?



On Thu, Apr 23, 2020 at 1:27 PM Seymour J Metz  wrote:

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


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

[Raphaël Jacquot]

Le 23/04/2020 à 07:22, Michael Phillips a écrit :
> 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... :)

That was supposed to fit in 3 bytes I suppose ?

in which case, the even better solution was to count a number of days
since some epoch.
100k days is almost 274 years

if you go to binary numbers, 2^24 days, that's 45k years

Raphaël

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

[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: 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: 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: 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.
> >
> &g

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 avai

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

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

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

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 acti

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  

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

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 Smit

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

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






---

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 reci

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

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

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!

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 form

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 un

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 

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 n

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 sam

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

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

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

Re: Here we go again

[Tony Thigpen]

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

Re: Here we go again

[Timothy Sipples]

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