Re: Here we go again

[Wayne Bickerdike]

He lost me when he jumped on the Harley Davidson. The COBOL of motorcycles.

For reliability and performance, you would pick Yamaha, followed by Honda.

Flame on, yankees.

On Tue, Apr 21, 2020 at 5:17 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> Unemployment checks are being held up by a coding language almost nobody
> knows - The Verge
>
> https://www.theverge.com/2020/4/14/21219561/coronavirus-pandemic-unemployment-systems-cobol-legacy-software-infrastructure
>
> -- gil
>
> --
> 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

[scott Ford]

Say the least they didn’t mention cheap companies outsource to make a buck
or the pi...poor managers who don’t have a clue about design or
implementation or performance.



On Mon, Apr 20, 2020 at 10:11 PM Wayne Bickerdike  wrote:

> He lost me when he jumped on the Harley Davidson. The COBOL of motorcycles.
>
> For reliability and performance, you would pick Yamaha, followed by Honda.
>
> Flame on, yankees.
>
> On Tue, Apr 21, 2020 at 5:17 AM Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Unemployment checks are being held up by a coding language almost nobody
> > knows - The Verge
> >
> >
> https://www.theverge.com/2020/4/14/21219561/coronavirus-pandemic-unemployment-systems-cobol-legacy-software-infrastructure
> >
> > -- gil
> >
> > --
> > 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
>
-- 
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

[Bob Bridges]

"A survey by The Verge found that at least 12 states still use COBOL in some 
capacity in their unemployment systems."  Sounds to me like they contacted 
exactly 12 states, then.

And I think I mentioned this before, and maybe someone pointed out I'd 
misunderstood but I don't remember:  The problem is apparently the "online 
unemployment form...was overloaded and he’d need to file again".  But the 
on-line application system would not have been written in COBOL, and if it was 
overloaded by too many people trying to use it at once it wouldn't be because 
of the language it's written in...would it?

---
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 Paul Gilmartin
Sent: Monday, April 20, 2020 15:17

Unemployment checks are being held up by a coding language almost nobody knows 
- The Verge

https://www.theverge.com/2020/4/14/21219561/coronavirus-pandemic-unemployment-systems-cobol-legacy-software-infrastructure

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

I would have thought that if you understand record i/o, possibly SQL
(although if it's such an ancient system, it will be flat files). All you
need after that is the ability to use the COMPUTE statement.

Although it seems that the good old fashioned systems analyst who
understood payroll has gone from the IT world.



On Tue, Apr 21, 2020 at 12:22 PM scott Ford  wrote:

> Say the least they didn’t mention cheap companies outsource to make a buck
> or the pi...poor managers who don’t have a clue about design or
> implementation or performance.
>
>
>
> On Mon, Apr 20, 2020 at 10:11 PM Wayne Bickerdike 
> wrote:
>
> > He lost me when he jumped on the Harley Davidson. The COBOL of
> motorcycles.
> >
> > For reliability and performance, you would pick Yamaha, followed by
> Honda.
> >
> > Flame on, yankees.
> >
> > On Tue, Apr 21, 2020 at 5:17 AM Paul Gilmartin <
> > 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > Unemployment checks are being held up by a coding language almost
> nobody
> > > knows - The Verge
> > >
> > >
> >
> https://www.theverge.com/2020/4/14/21219561/coronavirus-pandemic-unemployment-systems-cobol-legacy-software-infrastructure
> > >
> > > -- gil
> > >
> > > --
> > > 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
> >
> --
> 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
>


-- 
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 20/04/2020 à 21:17, Paul Gilmartin a écrit :
> Unemployment checks are being held up by a coding language almost nobody 
> knows - The Verge
> 
> https://www.theverge.com/2020/4/14/21219561/coronavirus-pandemic-unemployment-systems-cobol-legacy-software-infrastructure
> 
> -- gil

I'm not sure we can consider "The Verge" as being decent journalism.
It sounds to me like it's filled of undocumented clickbait trolling.

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

[Seymour J Metz]

My guess is that they needed to update the online application to support the 
new legislation, that it is written in COBOL for CICS, that they negligently 
failed to require, or even allow, adequate documentation and that they're too 
cheap to maintain adequate staffing. There are other possibilities, but they 
all boil down to poor management or inadequate funding and have nothing to do 
with the choice of language. IMHO a decent programmer could quickly pick up 
enough COBOL, JavaScript or whatever to do a quick fix, even if the code wasn't 
as clean or efficient as he could have written with more experience. Overcoming 
a lack of good documentation, however, is something else. "Remember that after 
Heracles cleaned the Augean stables, he killed the man who asked him to do it." 
= Robert Townsend in "Up The Organization"

As you noted, overloading is an unrelated issue.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Monday, April 20, 2020 11:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again

"A survey by The Verge found that at least 12 states still use COBOL in some 
capacity in their unemployment systems."  Sounds to me like they contacted 
exactly 12 states, then.

And I think I mentioned this before, and maybe someone pointed out I'd 
misunderstood but I don't remember:  The problem is apparently the "online 
unemployment form...was overloaded and he’d need to file again".  But the 
on-line application system would not have been written in COBOL, and if it was 
overloaded by too many people trying to use it at once it wouldn't be because 
of the language it's written in...would it?

---
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 Paul Gilmartin
Sent: Monday, April 20, 2020 15:17

Unemployment checks are being held up by a coding language almost nobody knows 
- The Verge

https://secure-web.cisco.com/1ajZ8A8DWU_JeD8KKd47ZrMuG9LvAYBY3K4gbnNpr9imW-LKdPxhQUXn7CNONrMGOt7OXFNMjPa7Gj1I6EMxcqPmz3C2FkQ_bkVUtqvAtDiN024eyZTZBnkL5oGYDO-y7NPw4nBkoJWgZzf0rVjKYeuvJ3u6qlN8-eXl2c0jQDwUrW1ztLLwaOVlrHOI8PEPu5z724ZxcToE13cqXLb3U1bYIkDg2PcTb0QhjjizdZKf2dBDlLSBJUaB8mD7iEEB6A1wXWdD-5EcLOgG23_fXWOgsF4TLtLYDCq_vtpcFGKk7dtTmNHCkpH6ShtWkHJleorm5LtndIibPnA7Ry4uR_MMjkQHVmSi47nCM8OJhd1XWyrGkaOYyzqwzwuUUglKj8NS_SbFINKvu9nASvdPmUCovJ9FENRNBdmmi5zQchvloRrE___usno_jaUeMMm3zK2HzVLV6KQuUFv_Yw2QjvA/https%3A%2F%2Fwww.theverge.com%2F2020%2F4%2F14%2F21219561%2Fcoronavirus-pandemic-unemployment-systems-cobol-legacy-software-infrastructure

--
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 01:45:25 -0700, in bit.listserv.ibm-main
sme...@gmu.edu (Seymour J Metz) wrote:

>My guess is that they needed to update the online application to support the 
>new legislation, that it is written in COBOL for CICS, that they negligently 
>failed to require, or even allow, adequate documentation and that they're too 
>cheap to maintain adequate staffing. There are other possibilities, but they 
>all boil down to poor management or inadequate funding and have nothing to do 
>with the choice of language. IMHO a decent programmer could quickly pick up 
>enough COBOL, JavaScript or whatever to do a quick fix, even if the code 
>wasn't as clean or efficient as he could have written with more experience. 
>Overcoming a lack of good documentation, however, is something else. "Remember 
>that after Heracles cleaned the Augean stables, he killed the man who asked 
>him to do it." = Robert Townsend in "Up The Organization"

At this point they need to bring back people who know the system.  I'm
a retired DOS 360 COBOL payroll and marketing programmer, retired MVT,
MVS, HASP, JES3 and JES2 systems programmer with submissions on the
MICHMODS, JES3 and CBT tapes, applications technical support for LE
upgrade and Y2K at an installation who developed in COBOL the date
routine which I am 99% certain was faster than the COBOL functions and
I still keep up with both the z systems via ibm-main and COBOL via
comp.lang.cobol as well as downloading selected manuals.  My specialty
is debugging, modifying and improving existing code.  In a crisis
situation these skills would be useful only if I understood the system
that was to be changed. 

Clark Morris   
>
>As you noted, overloading is an unrelated issue.

--
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 Tue, 21 Apr 2020 08:45:14 +, Seymour J Metz wrote:

>My guess is that they needed to update the online application to support the 
>new legislation, 
>...
Meanwhile, how close is the 9-digit SSN space to saturation?

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

[Seymour J Metz]

> At this point they need to bring back people who know the system.

Quite likely, but, absent good documentation, that would be true whether it 
were written in Ada, BLISS, COBOL, DIBOL, ESPOL, FLOW-MATIC, GOM, Haskell, 
Icon, Java, Kotlin, Lua, Mesa,  Napier88, occam, PL/I, QtScript, Raku, 
Smalltalk, Tcl. Umple, Vyper, Wolfram Language, XL, Yoix or ZPL. The basic 
problem is that they didn't have adequate documentation, contingency planning 
or staffing. But, let's admit it, the language used is always a convenient 
scapegoat.

Which is not to say that COBOL doesn't have flaws, just that it's being used as 
a whipping boy for somebody else's failings.


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

[Default] On 21 Apr 2020 01:45:25 -0700, in bit.listserv.ibm-main
sme...@gmu.edu (Seymour J Metz) wrote:

>My guess is that they needed to update the online application to support the 
>new legislation, that it is written in COBOL for CICS, that they negligently 
>failed to require, or even allow, adequate documentation and that they're too 
>cheap to maintain adequate staffing. There are other possibilities, but they 
>all boil down to poor management or inadequate funding and have nothing to do 
>with the choice of language. IMHO a decent programmer could quickly pick up 
>enough COBOL, JavaScript or whatever to do a quick fix, even if the code 
>wasn't as clean or efficient as he could have written with more experience. 
>Overcoming a lack of good documentation, however, is something else. "Remember 
>that after Heracles cleaned the Augean stables, he killed the man who asked 
>him to do it." = Robert Townsend in "Up The Organization"

At this point they need to bring back people who know the system.  I'm
a retired DOS 360 COBOL payroll and marketing programmer, retired MVT,
MVS, HASP, JES3 and JES2 systems programmer with submissions on the
MICHMODS, JES3 and CBT tapes, applications technical support for LE
upgrade and Y2K at an installation who developed in COBOL the date
routine which I am 99% certain was faster than the COBOL functions and
I still keep up with both the z systems via ibm-main and COBOL via
comp.lang.cobol as well as downloading selected manuals.  My specialty
is debugging, modifying and improving existing code.  In a crisis
situation these skills would be useful only if I understood the system
that was to be changed.

Clark Morris
>
>As you noted, overloading is an unrelated issue.

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

[Joe Monk]

9 digits = 999,999,999. There afe only 350,000,000 in the USA.

Joe

On Tue, Apr 21, 2020 at 10:08 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 21 Apr 2020 08:45:14 +, Seymour J Metz wrote:
>
> >My guess is that they needed to update the online application to support
> the new legislation,
> >...
> Meanwhile, how close is the 9-digit SSN space to saturation?
>
> -- 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

[Charles Mills]

Right! Your car is out of gas, and so you complain "This darned Chevrolet
doesn't run."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Tuesday, April 21, 2020 8:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again

> At this point they need to bring back people who know the system.

Quite likely, but, absent good documentation, that would be true whether it
were written in Ada, BLISS, COBOL, DIBOL, ESPOL, FLOW-MATIC, GOM, Haskell,
Icon, Java, Kotlin, Lua, Mesa,  Napier88, occam, PL/I, QtScript, Raku,
Smalltalk, Tcl. Umple, Vyper, Wolfram Language, XL, Yoix or ZPL. The basic
problem is that they didn't have adequate documentation, contingency
planning or staffing. But, let's admit it, the language used is always a
convenient scapegoat.

Which is not to say that COBOL doesn't have flaws, just that it's being used
as a whipping boy for somebody else's failings.

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

[Farley, Peter x23353]

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.

I don't think SSN's are ever re-used, are they?  Besides use by identity 
thieves of course.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Joe 
Monk
Sent: Tuesday, April 21, 2020 1:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Here we go again

EXTERNAL EMAIL

9 digits = 999,999,999. There afe only 350,000,000 in the USA.

Joe

On Tue, Apr 21, 2020 at 10:08 AM Paul Gilmartin < 
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 21 Apr 2020 08:45:14 +, Seymour J Metz wrote:
>
> >My guess is that they needed to update the online application to 
> >support
> the new legislation,
> >...
> Meanwhile, how close is the 9-digit SSN space to saturation?
>
> -- gil
--

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


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

Re: Here we go again

[Mike Schwab]

https://en.wikipedia.org/wiki/Social_Security_number#Exhaustion_and_re-use
450 million issued and 5.5 million issued a year.

On Tue, Apr 21, 2020 at 5:03 PM Joe Monk  wrote:
>
> 9 digits = 999,999,999. There afe only 350,000,000 in the USA.
>
> Joe
>
> On Tue, Apr 21, 2020 at 10:08 AM Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > On Tue, 21 Apr 2020 08:45:14 +, Seymour J Metz wrote:
> >
> > >My guess is that they needed to update the online application to support
> > the new legislation,
> > >...
> > Meanwhile, how close is the 9-digit SSN space to saturation?
> >
> > -- 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



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

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

Re: Here we go again

[Mark Jacobs]

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.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

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

‐‐‐ Original Message ‐‐‐
On Tuesday, April 21, 2020 1:02 PM, Joe Monk  wrote:

> 9 digits = 999,999,999. There afe only 350,000,000 in the USA.
>
> Joe
>
> On Tue, Apr 21, 2020 at 10:08 AM Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > On Tue, 21 Apr 2020 08:45:14 +, Seymour J Metz wrote:
> >
> > > My guess is that they needed to update the online application to support
> > > the new legislation,
> > > ...
> > > Meanwhile, how close is the 9-digit SSN space to saturation?
> >
> > -- 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

[retired mainframer]

In addition to SSNs, the same set of numbers is used for EINs (employers), 
ITINs (non-residents), and ATINs (adoptees in process).  There may be others 
but those are the ones I see as a (currently idle) AARP volunteer tax preparer.

Some numbers are also reserved, such as 111-00- for the spouse's unknown 
SSN when the filing status is Married Filing Separate.

In view of the fact the SSNs assigned to people no longer living are still 
being used for employment and tax fraud, reusing numbers would really muddy the 
waters.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Joe Monk
> Sent: Tuesday, April 21, 2020 10:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Here we go again
> 
> 9 digits = 999,999,999. There afe only 350,000,000 in the USA.
> 
> Joe
> 
> On Tue, Apr 21, 2020 at 10:08 AM Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > On Tue, 21 Apr 2020 08:45:14 +, Seymour J Metz wrote:
> >
> > >My guess is that they needed to update the online application to support
> > the new legislation,
> > >...
> > Meanwhile, how close is the 9-digit SSN space to saturation?
> >
> > -- 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

[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

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

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

[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

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

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

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

[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

[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

[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

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

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

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

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

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

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

[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

[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

[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

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

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

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

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 di

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 

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;

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

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

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 t

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;

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

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

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

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

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 

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 &

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: 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 &STR( 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;

[Wayne Bickerdike]

Something like this:

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


&STR(  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 &STR( 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;

[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 &DS
>IF &DS = ' ' THEN EXIT
>ELSE DELETE &DS
>END
>
>&STR(  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;

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

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

[Seymour J Metz]

EXIT leaves the CLIST.

IF &NRSTR(&DS) 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 &DS
>IF &DS = ' ' THEN EXIT
>ELSE DELETE &DS
>END
>
>&STR(  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

[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

[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

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

[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 &NRSTR(&DS) 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 &DS
> >IF &DS = ' ' THEN EXIT
> >ELSE DELETE &DS
> >END
> >
> >&STR(  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;

[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 &NRSTR(&DS) 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 &DS
IF &DS = ' ' THEN EXIT
ELSE DELETE &DS
END

&STR(  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;

[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 &NRSTR(&DS) 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 &DS
> >IF &DS = ' ' THEN EXIT
> >ELSE DELETE &DS
> >END
> >
> >&STR(  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;

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

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

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

[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~smetz3&data=02%7C01%7C%7C7343764574a748ceaa7808d7e79c42af%7C84df9e7fe9f640afb435%7C1%7C0%7C637232530624151412&sdata=O4UDTjodAoUB7pOFbMMf5Z8uwwixQnB6dSNu9XF0hpY%3D&reserved=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]

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~smetz3&data=02%7C01%7C%7C7343764574a748ceaa7808d7e79c42af%7C84df9e7fe9f640afb435%7C1%7C0%7C637232530624151412&sdata=O4UDTjodAoUB7pOFbMMf5Z8uwwixQnB6dSNu9XF0hpY%3D&reserved=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]

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~smetz3&data=02%7C01%7C%7C46dd520a166449a9cd0508d7e7a01440%7C84df9e7fe9f640afb435%7C1%7C0%7C637232547029007963&sdata=6Tc%2BdMoQWcieXngCXVB9X6a8A5Osis8Sul4WX4yQtXs%3D&reserved=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~smetz3&data=02%7C01%7C%7C46dd520a166449a9cd0508d7e7a01440%7C84df9e7fe9f640afb435%7C1%7C0%7C637232547029007963&sdata=6Tc%2BdMoQWcieXngCXVB9X6a8A5Osis8Sul4WX4yQtXs%3D&reserved=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;

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

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

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

[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~smetz3&data=02%7C01%7C%7C46dd520a166449a9cd0508d7e7a01440%7C84df9e7fe9f640afb435%7C1%7C0%7C637232547029007963&sdata=6Tc%2BdMoQWcieXngCXVB9X6a8A5Osis8Sul4WX4yQtXs%3D&reserved=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~smetz3&data=02%7C01%7C%7C46dd520a166449a9cd0508d7e7a01440%7C84df9e7fe9f640afb435%7C1%7C0%7C637232547029007963&sdata=6Tc%2BdMoQWcieXngCXVB9X6a8A5Osis8Sul4WX4yQtXs%3D&reserved=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;

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

?

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;

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

[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

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

[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

[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

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

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,

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

[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

[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

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

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

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

[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~smetz3&data=02%7C01%7C%7Cfe4606446a024ce1ef3f08d7e6f42b0f%7C84df9e7fe9f640afb435%7C1%7C0%7C637231808688902735&sdata=GUKRdPCZgletvLmWTX8AsrOEwexm2Ictr2aFQRNdU%2B0%3D&reserved=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;

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

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]

  
  
  

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