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

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

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

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

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

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;

ued 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

Re: Here we go again;

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 address

Re: Here we go again; Memory Lane

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

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

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

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;

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

Re: Here we go again;

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 un

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 someho

Re: Here we go again;

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

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 David Spiegel [dspiegel...@hotmail.com] Sent: Thursday, April 23, 2020 11:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Here w

Re: Here we go again;

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

Re: Here we go again;

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 i

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 recomplement

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 contain

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 calculating/s

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

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

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

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 a

Re: Here we go again;

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

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,

Re: Here we go again;

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 NAM

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

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 epoc

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

Re: Here we go again;

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

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

Re: Here we go again;

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 >

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;

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

Re: Here we go again;

rame 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

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

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

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

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

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

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

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

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

Re: Here we go again;

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

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

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

Re: Here we go again;

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

Re: Here we go again;

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

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 man

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 mainf

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

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

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;

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

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 an

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 af

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 wit

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 ei

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

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

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

'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

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

ould 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

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

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

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

ay, 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 se

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

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

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;

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

Re: Here we go again;

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 dol

Re: Here we go again

TSERV.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; m

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

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

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 abo

Re: Here we go again;

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

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 s

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 mos

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;

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;

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

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 aga

Re: Here we go again;

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

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 desig

Re: Here we go again

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

Re: Here we go again

-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

Re: Here we go again;

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

Re: Here we go again;

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

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

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 f

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 exc

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

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 o

  1   2   >