Simple question on the Y2K issue 
Author Message
 Simple question on the Y2K issue

I was wondering if anyone had considered a simpler solution for the Y2K
problem. It occured to me that a simple solution might be found in looking
at alternatives to base 10 math (like hexadecimal.) Lets call the problem
a need for Y2K math. In this math the 2-digit year numbers run 00-99 for 1900's
and run #0-#9 (#=a to z) for other centuries. Years 2000-2099 could be stored
in 2-digits as a0-a9, b0-b9, ..., j0-j9 for example. Though not a perfect
solution this could easily get around the problem for a few years.

Of course, this still requires modifications to code. However the biggest
change would now reside on the compiler writers rather than the application
developers.  The main requirement for the application folks would be to insure
that the stored Y2K variable are entered, and output correctly. The compilers
would be responsible for performing the correct Y2K math.

Just a thought,
-----------------------------------------------------------------------
David P. Bartlett                       Mgr. ATS, Operations

UNLV Box 454016                         Office: SCS-214
4505 S. Maryland Pkwy.                  Office phone: (702) 895-4545
Las Vegas, NV. 89154-4016               Fax: (702) 895-3791



Fri, 09 Jun 2000 03:00:00 GMT  
 Simple question on the Y2K issue

...<snip>...

Quote:

>That's not a thought, that's a stray synaptic firing.

>>-----------------------------------------------------------------------
>>David P. Bartlett Mgr. ATS, Operations

>>UNLV Box 454016 Office: SCS-214
>>4505 S. Maryland Pkwy. Office phone: (702) 895-4545
>>Las Vegas, NV. 89154-4016 Fax: (702) 895-3791

...<snip>...

Cory? Be nice to the computer operator! Do you have any idea how painful it
can be NOT to get your compile listing out of the computer room for over 48
hours???



Fri, 09 Jun 2000 03:00:00 GMT  
 Simple question on the Y2K issue

Quote:

> I was wondering if anyone had considered a simpler solution for the Y2K
> problem. It occured to me that a simple solution might be found in looking
> at alternatives to base 10 math (like hexadecimal.) Lets call the problem
> a need for Y2K math. In this math the 2-digit year numbers run 00-99 for 1900's
> and run #0-#9 (#=a to z) for other centuries. Years 2000-2099 could be stored
> in 2-digits as a0-a9, b0-b9, ..., j0-j9 for example. Though not a perfect
> solution this could easily get around the problem for a few years.

Actually, it's not the "difficulty" of the fixes; it's the QUANTITY.
Most of the "fixes" are simple:  "Expand the year field by two bytes."
"OK, we have two Billion records in the database right now; we need
another four gigabytes of DASD *right now* just to hold the converted
database *right now*."  "How long will it take to convert our two
Billion records?"  "Oh, and we have 12,000 programs that read, update,
etc. those two Billion records -- how many of them will need to be
modified, recompiled and tested?  How long will that take?"  "Oops,
forgot about the 3,200 'ancillary' files, archives, etc. that relate in
some way to the main database -- how many records are in those files?
How many programs manipulate THOSE files?"  "And what about the data
that we exchange on tape or electronically over the networks (plural)
with our suppliers, customers, business partners, regulatory agencies,
etc.  Will our modifications be compatible with all of theirs?  Will we
need to code another 'layer' of data translation, possibly customized
uniquely for each of our 'net partners'?"

"OK -- how about just storing the dates internally in hexadecimal?"
"Sure, but our 12,000 programs will *definitely* have to be checked, and
many if not most modified to convert between hex and decimal -- but we
wouldn't need the 4Gb additional DASD right now."  "How long will it
take to check and/or change and test our 12,000 programs for
hex-to-dec-and-back conversion?"  "And don't forget the
'data-compatibility' I mentioned earlier."

Quote:
> Of course, this still requires modifications to code. However the biggest
> change would now reside on the compiler writers rather than the application
> developers.  The main requirement for the application folks would be to insure
> that the stored Y2K variable are entered, and output correctly. The compilers
> would be responsible for performing the correct Y2K math.

(Actually, it's the "run-time libraries" that provide those routines;
the compilers merely translate source code into machine 'executable'
code.)

Add to my previous comments:  "How many compiler writers are there?  How
long will it take them to modify the run-time libraries to recognize one
field as a 'date' field and another as a 'dollar amount' field?  What
changes would we have to impose on the source-code crankers so that the
compiler would generate the correct calls to the correct routines at the
correct times, *infallibly*?"  "How long will it take the source-coders
to modify *EVERY SINGLE PROGRAM* to incorporate the new 'syntax' <the
correct word escapes me>, compile them, and test them?"

Quote:
> Just a thought,

Please don't interpret my comments as "raining on your parade".  The y2k
problem is simple; most of the proposed fixes are simple.  It's the
*SIZE* and *PERVASIVENESS* of the problem that is the *real* problem,
and there appears to be no "quick" way to shrink it.  We need "brute
force" and "time", and we have neither.

Assume, for illustration, that it takes one minute of "wall-clock time"
to compile a single program.  That means it would take at least 12,000
minutes for my hypothetical entity above just to recompile their suite
of programs.  There are 1,440 minutes in a day.  That means more than a
week, running 24*7, just to compile the programs.

Now, let's assume that all the compiles complete successfully on the
first attempt. (Um, did I mention that my hypothetical occurs in
Utopia?)  Let's convert the database.  Our computer has enough
"horsepower" to complete 100,000 I/Os per minute with our conversion
program, and we have two Billion records to convert.  That conversion
will take no less than 20,000 minutes, or just under two weeks (again,
running 24*7).  Three weeks (+/- a few hours) running 24*7, machine
dedicated to nothing but compiles and conversion (remember, this is
Utopia), just to get ready to run the first test.  We can only hope
against hope that we made *ALL* the necessary programming changes
*CORRECTLY*, the *FIRST TIME*.  How many tests will we need to run
before we can state with the requisite confidence that "we've
succeeded"?  How long will those tests take?

And we haven't even begun to consider the "ancillary" programs and
files.  We haven't even begun to consider the "data compatibility" with
our "net partners".

By the way, this *ISN'T* the personnel and payroll system.  This is the
system that will determine whether the entity continues to exist.  If it
fails, we won't need personnel OR payroll.

And this is just *ONE* entity.

      -jc-



Fri, 09 Jun 2000 03:00:00 GMT  
 Simple question on the Y2K issue

Quote:

> I was wondering if anyone had considered a simpler solution for the Y2K
> problem. It occured to me that a simple solution might be found in looking
> at alternatives to base 10 math (like hexadecimal.) Lets call the problem
> a need for Y2K math. In this math the 2-digit year numbers run 00-99 for 1900's
> and run #0-#9 (#=a to z) for other centuries. Years 2000-2099 could be stored
> in 2-digits as a0-a9, b0-b9, ..., j0-j9 for example. Though not a perfect
> solution this could easily get around the problem for a few years.

> Of course, this still requires modifications to code. However the biggest
> change would now reside on the compiler writers rather than the application
> developers.  The main requirement for the application folks would be to insure
> that the stored Y2K variable are entered, and output correctly. The compilers
> would be responsible for performing the correct Y2K math.

Must be time for the monthly "just try this representation query"
again.  This has been dealt with before in many similar forms.  There
are a number of implicit assumptions in the "simple" scheme above:
(1) expansion of existing fields is more complex than changing the field
encoding - not true in general.  Locating all the date-related fields
and coordinating consistent changes in all the programs and applications
touching those fields, especially in external files, tends to be the
difficult part of the problem, requiring human intelligence even when
"tools" are available.  Unless a more complex encoding can be
automatically handled, simpler is better.  Imagine the maintenance
headache facing a team trying to perform year 2050 remediation on an
application relying on your scheme (and what they will say about the
stupid lack of foresight of their predecessors).
(2) existing year encodings have bits sitting around unused just waiting
for a clever new encoding scheme to utilize them - not necessarily--
year might be in characters, but if space was a consideration before,
more likely already packed or even in binary, limiting what can be done;
and using non-standard representations may have performance implications
as well.
(3) changes in language standards can be developed and reliable
compilers for those new standards implemented in time to be of use --
don't hold your breath (and if it's not part of a language standard, you
don't want to touch it for mission critical applications or you've
really painted yourself in a corner).
(4) there is some simple language extension which might enable a
compiler to consistently decide when the encoded form of the field
should be used vs. when the encoded field should be expanded into a
displayable form or a computational form -- I doubt it; consider
problems posed by REDEFINE of group item containing a year, directing
such a group item to a file to be printed vs. to a data file for
retention, passing such a year element as a parameter to an
independently compiled program unit, etc.

If you look through the archives for this usegroup (or do enough
remediation on real code), I'm sure you will find many other reasons why
this scheme is not nearly as simple as it sounds.  If you already have
to go through the overhead of analyzing an application system, locating,
and changing date field definitions, in many cases just going to a
4-digit year is the simplest fix, and one that won't have to be fixed
again in the next 50 years.  If space on external files is a serious
consideration, then one might want to explore alternative encodings
(e.g., a 24-bit representation of Lilian date would take same space as
an unsigned packed yy mm dd value, but be valid past year 9999).  I
don't think it's realistic to expect much help from a compiler in
determining when such alternative encodings *should* be used, and that's
the hard part.
--

Consulting Systems Programmer



Fri, 09 Jun 2000 03:00:00 GMT  
 Simple question on the Y2K issue

Quote:

> Assume, for illustration, that it takes one minute of "wall-clock time"
> to compile a single program.  That means it would take at least 12,000
> minutes for my hypothetical entity above just to recompile their suite
> of programs.  There are 1,440 minutes in a day.  That means more than a
> week, running 24*7, just to compile the programs.

In my expereince, a company with 12,000 programs has adequate capacity
to run more than one compile at a time.  They may have multiple
computers just for development.
--

L  |/  

v  | \  1-818-985-3259                       Please reply without spam
e    |\
Y    |/ Panic in the Year Zero Zero:  http://members.aol.com/PanicYr00
o    |\
u    |/ Have you solved http://members.aol.com/PanicYr00/Sequence.html


Fri, 09 Jun 2000 03:00:00 GMT  
 Simple question on the Y2K issue


Quote:
>I was wondering if anyone had considered a simpler solution for the Y2K
>problem. It occured to me that a simple solution might be found in looking
>at alternatives to base 10 math (like hexadecimal.) Lets call the problem
>a need for Y2K math. In this math the 2-digit year numbers run 00-99 for 1900's
>and run #0-#9 (#=a to z) for other centuries. Years 2000-2099 could be stored
>in 2-digits as a0-a9, b0-b9, ..., j0-j9 for example. Though not a perfect
>solution this could easily get around the problem for a few years.

>Of course, this still requires modifications to code. However the biggest
>change would now reside on the compiler writers rather than the application
>developers.  The main requirement for the application folks would be to insure
>that the stored Y2K variable are entered, and output correctly. The compilers
>would be responsible for performing the correct Y2K math.

>Just a thought,

That's not a thought, that's a stray synaptic firing.

Quote:
>-----------------------------------------------------------------------
>David P. Bartlett                   Mgr. ATS, Operations

>UNLV Box 454016                             Office: SCS-214
>4505 S. Maryland Pkwy.                      Office phone: (702) 895-4545
>Las Vegas, NV. 89154-4016           Fax: (702) 895-3791

Dave, others, with a sense of humor, have posted that solution but they did
it on April 1st.  You're the first person I've seen who has written this
and it hasn't obviously been a joke.

Cory Hamasaki  But then, maybe you'll respond with "gotcha!"



Sat, 10 Jun 2000 03:00:00 GMT  
 Simple question on the Y2K issue

: >
: > I was wondering if anyone had considered a simpler solution for the Y2K
: > problem. It occured to me that a simple solution might be found in looking
: > at alternatives to base 10 math (like hexadecimal.) Lets call the problem
: > a need for Y2K math. In this math the 2-digit year numbers run 00-99 for 1900's
: > and run #0-#9 (#=a to z) for other centuries. Years 2000-2099 could be stored
: > in 2-digits as a0-a9, b0-b9, ..., j0-j9 for example. Though not a perfect
: > solution this could easily get around the problem for a few years.

We are currently implementing a variation on this idea.  Our major
application stores dates in three-byte zoneless packed YYMMDD format
(today would be X'971223').  Because it's not feasible to chnage all of
the existing data in the time available, we're shifting to a "CYMMDD"
format, where X'A0' follows X'99' and means 2000, X'B0' is 2010, and so on.
Using this method, no existing data need be changed, dates will continue
to sort correctly, and the worst result of failing to convert one of the
many programs which use these records is that the dates will be displayed
or printed oddly.  The solution is only good for 60 years, but that will
give us enough time to develop a more permanent solution.

: Actually, it's not the "difficulty" of the fixes; it's the QUANTITY.
: Most of the "fixes" are simple:  "Expand the year field by two bytes."
: "OK, we have two Billion records in the database right now; we need
: another four gigabytes of DASD *right now* just to hold the converted
: database *right now*."

Precisely why we can't convert our data.  That two billion figure is no
exaggeration, and we have to have 70-some million of those records
available for online access for all but 2-4 hours per week.  That puts a
pretty severe constraint on any conversion plans.

: "How long will it take to convert our two
: Billion records?"  "Oh, and we have 12,000 programs that read, update,
: etc. those two Billion records -- how many of them will need to be
: modified, recompiled and tested?  How long will that take?"  "Oops,
: forgot about the 3,200 'ancillary' files, archives, etc. that relate in
: some way to the main database -- how many records are in those files?
: How many programs manipulate THOSE files?"  "And what about the data
: that we exchange on tape or electronically over the networks (plural)
: with our suppliers, customers, business partners, regulatory agencies,
: etc.  Will our modifications be compatible with all of theirs?  Will we
: need to code another 'layer' of data translation, possibly customized
: uniquely for each of our 'net partners'?"

Fortunately, our data format is strictly internal.  Whatever comes in or
goes out is converted to a communications format.

: "OK -- how about just storing the dates internally in hexadecimal?"
: "Sure, but our 12,000 programs will *definitely* have to be checked, and
: many if not most modified to convert between hex and decimal -- but we
: wouldn't need the 4Gb additional DASD right now."  "How long will it
: take to check and/or change and test our 12,000 programs for
: hex-to-dec-and-back conversion?"  "And don't forget the
: 'data-compatibility' I mentioned earlier."

Another factor which makes this work for us is that our dates are already
store in hexadecimal, so that no language can handle them as an intrinsic
data type.  The number of routines which actually manipulate these dates
is a very small percentage of our total software inventory.

: > Of course, this still requires modifications to code. However the biggest
: > change would now reside on the compiler writers rather than the application
: > developers.  The main requirement for the application folks would be to insure
: > that the stored Y2K variable are entered, and output correctly. The compilers
: > would be responsible for performing the correct Y2K math.

: (Actually, it's the "run-time libraries" that provide those routines;
: the compilers merely translate source code into machine 'executable'
: code.)

Fortunately again, there's no compiler or run-time library involvement in
our situation.  If there had been, that in itself would probably have made
this approach infeasible.

So what't my point here?  Simply that the whole Y2k issue is situation
dependent.  What works for one organization, or one application within an
organization, may be totally inappropriate for another, and conversely, a
proposed solution which appears hopelessly inadaquate in one situation
may be tailor-made for another.

--





Sat, 10 Jun 2000 03:00:00 GMT  
 Simple question on the Y2K issue

If you wanted to do that, just convert the 2 digits to unsigned COMP data. FF would serve
as 255, so technically 1900 + 255 would max out at 2155. Problem is, it's not
just a matter of 'displaying' the data. Any computational functions would
have to be re-written anyway so as not to truncate the 100's place holder. Plus,
if programs were written expecting to only use the last 2 digits, the '19' could
possibly be hard coded in -old- programs.

 Speaking of Y2K, has anyone used the Exchange product in Y2K testing? Is it any
good?

Quote:
> I was wondering if anyone had considered a simpler solution for the Y2K
> problem. It occured to me that a simple solution might be found in looking
> at alternatives to base 10 math (like hexadecimal.) Lets call the problem
> a need for Y2K math. In this math the 2-digit year numbers run 00-99 for 1900's
> and run #0-#9 (#=a to z) for other centuries. Years 2000-2099 could be stored
> in 2-digits as a0-a9, b0-b9, ..., j0-j9 for example. Though not a perfect
> solution this could easily get around the problem for a few years.

> Of course, this still requires modifications to code. However the biggest
> change would now reside on the compiler writers rather than the application
> developers.  The main requirement for the application folks would be to insure
> that the stored Y2K variable are entered, and output correctly. The compilers
> would be responsible for performing the correct Y2K math.

> Just a thought,
> -----------------------------------------------------------------------
> David P. Bartlett                  Mgr. ATS, Operations

> UNLV Box 454016                            Office: SCS-214
> 4505 S. Maryland Pkwy.                     Office phone: (702) 895-4545
> Las Vegas, NV. 89154-4016          Fax: (702) 895-3791

------------------------------------------------------------------
              Hungry for NEWSGROUPS??? USE feedME.ORG            
         Read and Post to 30,000 groups through feedME.ORG        
     FREE  FREE  FREE  http://www.feedME.ORG  FREE  FREE  FREE    
------------------------------------------------------------------


Sat, 10 Jun 2000 03:00:00 GMT  
 Simple question on the Y2K issue

Quote:


>...<snip>...

>>That's not a thought, that's a stray synaptic firing.

>>>-----------------------------------------------------------------------
>>>David P. Bartlett Mgr. ATS, Operations

>>>UNLV Box 454016 Office: SCS-214
>>>4505 S. Maryland Pkwy. Office phone: (702) 895-4545
>>>Las Vegas, NV. 89154-4016 Fax: (702) 895-3791

>...<snip>...

>Cory? Be nice to the computer operator! Do you have any idea how painful it
>can be NOT to get your compile listing out of the computer room for over 48
>hours???

Good point.  I remember someone needing an outside tape to be used in
a batch run.  They taped a banana to it.  Operations was NOT amused
8-)

Tim Oxler
TEO Computer Technologies Inc.
http://www.i1.net/~troxler
http://users.aol.com/TEOcorp



Sat, 10 Jun 2000 03:00:00 GMT  
 Simple question on the Y2K issue

Quote:

> We are currently implementing a variation on this idea.  Our major
> application stores dates in three-byte zoneless packed YYMMDD format
> (today would be X'971223').  Because it's not feasible to chnage all of
> the existing data in the time available, we're shifting to a "CYMMDD"
> format, where X'A0' follows X'99' and means 2000, X'B0' is 2010, and so on.

I am wondering how you define a 3-byte packed field to contain more than
5 digits, when a half-byte is reserved for a sign. Even when defined
unsigned, the right-most half-byte would contain a X'F'. In the Cobol
I've used (68,74, & some 85), you would need 4 bytes to accomplish the
storage of 6 to 7 digits plus sign.  What version are you using and what
platform is it run on ??

Bob Berman



Sat, 10 Jun 2000 03:00:00 GMT  
 Simple question on the Y2K issue



Quote:

>That's not a thought, that's a stray synaptic firing.

Yow! Cory, leave a *little* flesh on the poor guy please! :^)

Another one for the 'nice try, no cigar' pile.......

Cheers

Nigel
--
Nigel Eaton
21st Century Programmers Do It With 4 Digits



Sun, 11 Jun 2000 03:00:00 GMT  
 Simple question on the Y2K issue



:> We are currently implementing a variation on this idea.  Our major
:> application stores dates in three-byte zoneless packed YYMMDD format
:> (today would be X'971223').  Because it's not feasible to chnage all of
:> the existing data in the time available, we're shifting to a "CYMMDD"
:> format, where X'A0' follows X'99' and means 2000, X'B0' is 2010, and so on.

: I am wondering how you define a 3-byte packed field to contain more than
: 5 digits, when a half-byte is reserved for a sign. Even when defined
: unsigned, the right-most half-byte would contain a X'F'. In the Cobol
: I've used (68,74, & some 85), you would need 4 bytes to accomplish the
: storage of 6 to 7 digits plus sign.  What version are you using and what
: platform is it run on ??

Pay attention: He told you:
"...in three-byte zoneless packed YYMMDD format
 (today would be X'971223')"
You could also call it unzoned decimal.


data such as that?"

Assembler  -- on the 360/370/390's....

An experienced Assembler geek that is good at PL/1 , or COBOL ,
could work with data such as this in a high-level language.

I know  -- cuz I've Been There many times.
I have a whooooooole steamer trunk full of t-shirts.

Jonesy
MainFrame IBM Assembler since 1966



Sun, 11 Jun 2000 03:00:00 GMT  
 Simple question on the Y2K issue


Quote:


>>That's not a thought, that's a stray synaptic firing.

>Yow! Cory, leave a *little* flesh on the poor guy please! :^)

>Another one for the 'nice try, no cigar' pile.......

>Cheers

>Nigel
>--
>Nigel Eaton
>21st Century Programmers Do It With 4 Digits

Was I out of line?  Seriously, sometimes I get carried away.

blame it on geezerhood.

Cory Hamasaki  



Sun, 11 Jun 2000 03:00:00 GMT  
 Simple question on the Y2K issue

Quote:

[snippagissmus]

> Was I out of line?  Seriously, sometimes I get carried away.

Or *should* be, by nice, white-coated men.

Quote:

> blame it on geezerhood.

... or stray synaptic firings; maybe they all got 'downsized'.

DD



Sun, 11 Jun 2000 03:00:00 GMT  
 Simple question on the Y2K issue

Quote:

>I wrote an on this article for FOCUS, their user's group magazine, in
>1985.  I've had the distinct pleasure in the last few years, when the
>CEO has pulled me into his office and said 'what are you doing about
>the year 2000 problem?', of tossing the magazine on his desk and
>saying 'I fixed it in 1985'. <g>

It does feel good doesn't it!

(I was hired in 1991 or so by a municipal government software
development house to get them going on a new platform, the IBM AS/400.
At that time I decreed all new software would have the century code
built in and all screens and reports would display the date in
CCYY/MM/DD format.  Thus my town office is in fine shape.

Gee, I should have asked for 5% of all software sales in 1998 and
1999!)

OTOH I've mostly been a PCWN and Access clicker since then. But I'm
working on my local newspapers.

Tony

----
Message posted to newsgroup and emailed.
Tony Toews, Independent Computer Consultant
The Year 2000 crisis: Will my parents or your grand parents still be receiving
their pension in January, 2000?  See www.granite.ab.ca/year2000 for more info.
Microsoft Access Hints, Tips & Accounting Systems at www.granite.ab.ca/accsmstr.htm



Mon, 12 Jun 2000 03:00:00 GMT  
 
 [ 29 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Question in french (a simple question, very simple)

2. Clarion 2.1 Y2K Issue patchy2k.exe no work!!

3. Y2K Issues in CDD for DOS

4. Y2K testing issues with Report Writer

5. Any Y2K issues for CPD v2.1

6. Y2k issue

7. Need Urgent Help- Y2K issue

8. New Y2k Issue

9. Y2k Issue

10. Thanks - Y2K PROGRAM CHECKER Issues

11. Y2K Issues

12. OT: OS/390 Y2K issue

 

 
Powered by phpBB® Forum Software