Message-ID: <33D4FC15.6339@target.net>
Date: Tue, 22 Jul 1997 14:29:41 -0400
From: John Leipold <monicus@target.net>
X-Mailer: Mozilla 3.01 (WinNT; I)
MIME-Version: 1.0
Subject: Re: .. YEAR2000 help -- storage bunkum - it **WAS** stupidity
References: <01bc819c$88c93420$0b3ba8c2@default> <**empire-0207971352220001@d61.cia.com.au> <33BB036D.50EE@magna.com.au> <33BCBB45.5B60@cabot.co.uk> <33D1F009.758@sasib.co.uk>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Newsgroups: alt.computer.consultants,alt.computer.consultants.ads,aus.computers,aus.computers.ibm-pc,aus.computers.mac,aus.computers.sun,bermuda.computer.society,comp.data.administration,comp.os.minix,comp.sys.dec,microsoft.public.snaserver.administration,uk.consultants
Path: euryale.cc.adfa.oz.au!news.mel.connect.com.au!munnari.OZ.AU!uunet!in1.uu.net!194.87.0.28!demos!demos3!demos2!uppssnewspub03.moswest.msn.net!uppssnewspub04.moswest.msn.net
Lines: 153
Xref: euryale.cc.adfa.oz.au alt.computer.consultants:44091 aus.computers:18141 aus.computers.ibm-pc:31264 aus.computers.mac:26496 aus.computers.sun:3061 comp.data.administration:692 comp.os.minix:28747 comp.sys.dec:48114 uk.consultants:5382

Mark Holcroft wrote:
> 
> The problem WAS short sighted programmers, and unimaginatively
> short-sighted at that!  The specification of the machines is
> not the issue, nor does it feature as mitigating circumstance.
> Neither is lack of storage space an excuse.  It is entirely true
> that the problem was then, and is now, to do with shortsightedness
> and lack of imagination.  All problems are not necessarily solved
> by a direct, literal translation from the problem domain into the
> solution domain ( %^} ), and application of standard variable
> types (which is why Pascal (inc UCSD Pascal :) ) has record types).
> 
> The problem IS to do with lazy/stupid/unimaginative programmers/system

Now let's not forget the management, who really deserve the blame if
anyone...

> designers because you can use 2 digits for your year, and still allow
> for a range of years much in excess of 100; the real problem is not
> with number representations, but with application programs using
> 99 or 9/9/99 as "infinity"; and other "magic" years, which will
> cause problems quite separate from owing your bank 97 years of
> compound interest because your account was opened in 97 and its now 00.
> 
> And just in case you don't believe me:
> '______________________________________________________________________
> ' QBasic demonstration that storage claims for Y2k bug are bunkum!

Forget COBOL, we got some QBasic.  Woo Hoo!

> ' Enter real years to get Y2k representation, ie. 1900 - 00; 2000 - A0
> ' Enter y2k representation to get real years, ie. 00 - 1900; A0 - 2000
> 
> ' Allows 2char representation of years 1640 thru 2259, inclusive
> ' with 00 = 1900, 99 = 1999 { for compatibility with legacy systems :) }
> ' range can be extended by using symbols,
> ' i.e. prepend prehistory$="!$%" to range, append posthistory$="{}[]"
> 
> '(C)July 20,1997 Mark Holcroft (mwh@sasib.co.uk) for all your Y2K needs!
> '______________________________________________________________________
> 
>     CLS
> 
>     lower$ = "abcdefghijklmnopqrstuvwxyz"
>     UPPER$ = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
>     numer$ = "0123456789"
>     Range$ = lower$ + numer$ + UPPER$
>     yr1900 = INSTR(Range$, "0")
> 
>     DO
> 
>        INPUT "Year : ", a$
> 
>     IF a$ = "" THEN EXIT DO
> 
>        PRINT "Y2000: ";
> 
>        IF LEN(a$) = 2 THEN
> 
>           decade = INSTR(Range$, MID$(a$, 1, 1)) ' **ERRCHK, ie. =
> 0
>           offset = VAL(MID$(a$, 2, 1))
>           yr = 1900 + ((decade - yr1900) * 10) + offset
>           PRINT MID$(STR$(yr), 2)
> 
>        ELSE
> 
>           yr = VAL(a$) - 1900 ' ***ERRCHK! ie. < -260 or > 356
> 
>           a = INT(yr / 10)
>           b = yr - (a * 10)
>           PRINT MID$(Range$, a + yr1900, 1); MID$(STR$(b), 2)
> 
>        END IF
> 
>     LOOP
> '______________________________________________________________________
> 
> This allows 2char representations of years 1640 - 2259 inclusive
> and can be used as functions to translate stored year into an integer
> then year operations (i.e. what year is it in 30yrs), then translate
> integer to y2k representation for storage.  Only application code needs
> to be altered now, your data files do not need to be scanned for what

"Only application code needs to be altered..."  Isn't that what Y2K
programmers are doing now?

> appears to be date (which is itself an unreliable and potentially
> dangerous operation in addition to your Y2k problems !!! Do not try at
> home!).  Your newly Y2k applications do not need vast additional
> storage, and demonstrates storage requirements are a recent attempt
> to dodge the flak for Y2k problem.
> 
> And re-hiring old "experienced" Cobol programmers to solve the millenium

Hiring any COBOL programmers is a huge problem here.  If you know any
that are unemployed, we can use 'em, and that's without Y2K work...

> problem is an example of Christ-like compassion and forgiveness - it's
> like rehiring the builders who made your house using structural members
> that have a useful, stress bearing life of only 10 years to replace
> the walls that are now becoming unsafe....  well, at least they can
> truly say "well, at least we understand what the problem is!  Hey, we
> CAUSED IT!"
> 
> IF they got it so wrong in the first place, what will they manage to
> do the second time they are let loose on safety critical systems?
> 
> > Enough rambling. We have expertise in Pascal and run the Pascal 2000
> > Resource Centre. See http://www.cabot.co.uk for more details on our
> > consultancy and programming services for Pascal code.
> 
> Ah, Yr 2000 consultancy.... I get it now!  { You are feeling very

Even without Y2k, consultancy is booming.  Ah, but yes, I'm sure there
are a few fools out there that will turn down a job for sake of landing
a Y2K gig.

Just a clue; consultants don't care about the job, just whether it pays.

> Sleepy ... very Sleee-eepy!!! When I click my fingers, you will
> awake, and you will believe that the Y2k problem was a proper
> engineering solution to the problems caused by the fact that we were
> all running our corporate executive systems on ZX81s and we didn't
> have enough storage space or processor speed!!! You WILL employ us
> to solve the problem we caused in the first place!!!! Awake nowCLICK! }
> Wahay!!! We're in the Money, we're in the money, I think our
> office is looking drab so we'll need a monet!  (SORRY!)

Hmmm, this should mean that I can make more knowing COBOL than
Powerbuilder.  Now I wonder why this isn't true.  False premis, false
conclusion.
> 
> And since everyone else is at it, I will accept y2k projects!!!
> No fee too large!  Some fees too small!

Well, if you got the solutions, put your money (or foot) where your
mouth is.  Sell it.  There are lot of companies and IS managers who
haven't even PO'ed their Y2K work.  If you get an MVS house to bite, not
only will you make some IS manager look good, but make yourself some
cash.

Anyone can rant.
