Re: Here we go again

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,

Re: Here we go again

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

Re: Here we go again

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

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

Re: Here we go again

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 govern

Re: Here we go again

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:

Re: Here we go again

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

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

Re: Here we go again

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

Re: Here we go again;

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

Re: Here we go again;

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

Re: Here we go again; Memory Lane

.EDU] On > Behalf Of Pierre Fichaud > Sent: Thursday, April 23, 2020 3:57 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Here we go again; > > [ External - This message originated Externally. Use proper judgement and > caution with attachments, links, or responses. ] > >

Re: Here we go again;

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

Re: Here we go again; Memory Lane

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

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.

Re: Here we go again;

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

Re: Here we go again;

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

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

Re: Here we go again;

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

Re: Here we go again;

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

Re: Here we go again;

(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

Re: Here we go again;

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

Re: Here we go again;

@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

Re: Here we go again;

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

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

Re: Here we go again

[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

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

and INDEX's can save large amounts of wall clock time and CPU time. -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Thursday, April 23, 2020 7:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: Here we go again; [External Email. Exercise caution when

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

AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: Here we go again; [External Email. Exercise caution when clicking links or opening attachments.] Adam, Believe me or not, but I (my folks) saved a lot of space by changing BLKSIZE to correct one, means SDB. It was not only JCL, but also

Re: Here we go again;

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%

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

Adam, Believe me or not, but I (my folks) saved a lot of space by changing BLKSIZE to correct one, means SDB. It was not only JCL, but also COBOL. What is "a lot of space"? It was enough free space on our huge 500GB DASD box to NOT PURCHASE ANOTHER BOX. Multiply it x2, because we used PPRC. We

Re: Here we go again;

[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, Ap

Re: Here we go again;

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:

Re: Here we go again;

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

Re: Here we go again

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.

Re: Here we go again

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

Re: Here we go again

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,

Re: Here we go again;

] Sent: Wednesday, April 22, 2020 10:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Here we go again; On Thu, 23 Apr 2020 12:07:13 +1000, Wayne Bickerdike wrote: >Something like this: > >DO I = 1 TO 5000 >WRITER ENTER DATASET NAME ==> >READ >IF = ' ' THEN EXIT >ELSE D

Re: Here we go again;

@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

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

Re: Here we go again;

On Thu, 23 Apr 2020 12:07:13 +1000, Wayne Bickerdike wrote: >Something like this: > >DO I = 1 TO 5000 >WRITER ENTER DATASET NAME ==> >READ >IF = ' ' THEN EXIT >ELSE DELETE >END > >( breaks the CLIST with a IKJ56545I message produced. > Ah! The invention of code injection. I prefer Rexx's

Re: Here we go again;

Something like this: DO I = 1 TO 5000 WRITER ENTER DATASET NAME ==> READ IF = ' ' THEN EXIT ELSE DELETE END ( breaks the CLIST with a IKJ56545I message produced. On Thu, Apr 23, 2020 at 11:55 AM Wayne Bickerdike wrote: > > *Lennie Dymoke-Bradshaw lenni...@rsmpartners.com > via >

Re: Here we go again;

*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

Re: Here we go again;

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

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

t: Wednesday, April 22, 2020 4:24 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [External] Re: Here we go again; > > > > > > So you agree that poor Blocksizes give rise to poor disk usage? > As to space allocations, I’m sorry but for as many problems as you’

Re: Here we go again;

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

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

as cheaper the STOPX37. I'm not cheaper today. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gerhard adam > Sent: Wednesday, April 22, 2020 3:44 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [External] Re: Here we go again; > > > >

Re: Here we go again;

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

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

BLKSIZES, Etc. In that era, I was cheaper the STOPX37. I'm not cheaper today. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gerhard adam > Sent: Wednesday, April 22, 2020 3:44 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [External] Re

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

.com] Sent: Wednesday, April 22, 2020 3:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: Here we go again; Agreed. Another thing to remember was that we were dealing with disk volumes measured in kilobytes or megabytes instead of terabytes. In addition, the site I cut my teeth

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

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

Re: Here we go again;

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

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

@LISTSERV.UA.EDU] on behalf of David Spiegel [dspiegel...@hotmail.com] Sent: Wednesday, April 22, 2020 3:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: Here we go again; The 3200 Maximum Blocksize used to be a Linkage Editor restriction. Also, better JCL does not pay dividends for any

Re: Here we go again;

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

Re: Here we go again;

@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

Re: Here we go again;

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

Re: Here we go again;

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

Re: Here we go again;

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

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

MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: Here we go again; Sorry, but “several models of 3380”? If  3380k held almost 2GB per module and you saved one byte per record, then you saved the one byte over 2 billion records to save just one 3380K’s worth of data.  Forgive me

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

On Behalf Of Gerhard adam Sent: Wednesday, April 22, 2020 2:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: Here we go again; Why did you have to go to the programmers to make sure they were using proper block sizes if this were common practice

Re: Here we go again;

AIN@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 > > ch

Re: Here we go again;

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

Re: Here we go again;

>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

Re: Here we go again;

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 a

Re: Here we go again;

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

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

I may be mistaken, but I get the impression you think you're disagreeing with Mr Pommier and maybe Mills. If that's what you meant to do, I don't think you've succeeded yet. They're saying that saving DASD space was often important; you're saying that some programmers at some companies were

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

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 scrut

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

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 p

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

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

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

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

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

, 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

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

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

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

@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

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

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

Re: Here we go again;

quot; 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- >>&g

Re: Here we go again

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

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

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

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

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

Re: Here we go again

[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

Re: Here we go again;

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

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

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

Re: Here we go again

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

Re: Here we go again

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

Re: Here we go again

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

Re: Here we go again;

] 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

Re: Here we go again;

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

Re: Here we go again;

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

Re: Here we go again;

-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

Re: Here we go again;

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

Re: Here we go again;

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

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

Re: Here we go again

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

Re: Here we go again

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

Re: Here we go again;

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

Re: Here we go again;

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

Re: Here we go again;

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.

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

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

Re: Here we go again

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

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:

Re: Here we go again

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

  1   2   >