Year 2000 
Author Message
 Year 2000

How is everyone handling the Year 2000 problem ?

This is how I am doing it but I am interested in anyone else's plans:

Change all dates from PIC 9(6) to PIC 9(8) and writing file
conversions for each file.

Make no changes to screen input/display but if a year is entered > 77
then it has 19 stuck on the front else 20.

In an ideal world, all dates which appeared in the key of a file
would have been PIC 9(6) COMP in which case it could have stayed the same.

Paul



Sat, 13 Nov 1999 03:00:00 GMT  
 Year 2000

Quote:

> How is everyone handling the Year 2000 problem ?

> This is how I am doing it but I am interested in anyone else's plans:

> Change all dates from PIC 9(6) to PIC 9(8) and writing file
> conversions for each file.

> Make no changes to screen input/display but if a year is entered > 77
> then it has 19 stuck on the front else 20.

> In an ideal world, all dates which appeared in the key of a file
> would have been PIC 9(6) COMP in which case it could have stayed the same.

> Paul

That's similar to what we're doing. The shop is primarily a VSAM shop
with some DL/I files. CICS is the monitor.

File conversion - expanding the dates was fairly simple except for 4
master files. Over the years, several file conversions had occurred,
the data had never been cleaned-up- spaces and low-values in numeric
fields. We edited every numeric field (dates and non-dates) and if
non-numeric, we tossed in all zeros (at client's request). We let
the client make all such decisions. It paid off during unit and
system testing.

Programs - we do not touch date fields on neither maps nor reports -
except in the case of hard-coded century date fields. Every program
that had a leap year routine in it was wrong as well as the date-edit
subroutine. Within each application. the date passed in the commarea
was different - some packed some not packed. Within each programs
there was liable to be packed and unpacked dates. STRICTLY GRUNT WORK.
However, try it with one newbie Coboler and 1 newbie on-line person!

Anyway, we'll make it; 5 weeks to go.

Richard Jackson
Houston, Texas
(The new taxes died in the legislature - Gov. Shrub has egg on his face)



Sat, 13 Nov 1999 03:00:00 GMT  
 Year 2000

Quote:


> > How is everyone handling the Year 2000 problem ?

> > This is how I am doing it but I am interested in anyone else's plans:

> > Change all dates from PIC 9(6) to PIC 9(8) and writing file
> > conversions for each file.

> > Make no changes to screen input/display but if a year is entered > 77
> > then it has 19 stuck on the front else 20.

> > In an ideal world, all dates which appeared in the key of a file
> > would have been PIC 9(6) COMP in which case it could have stayed the same.

> > Paul

> That's similar to what we're doing. The shop is primarily a VSAM shop
> with some DL/I files. CICS is the monitor.

> File conversion - expanding the dates was fairly simple except for 4
> master files. Over the years, several file conversions had occurred,
> the data had never been cleaned-up- spaces and low-values in numeric
> fields. We edited every numeric field (dates and non-dates) and if
> non-numeric, we tossed in all zeros (at client's request). We let
> the client make all such decisions. It paid off during unit and
> system testing.

> Programs - we do not touch date fields on neither maps nor reports -
> except in the case of hard-coded century date fields. Every program
> that had a leap year routine in it was wrong as well as the date-edit
> subroutine. Within each application. the date passed in the commarea
> was different - some packed some not packed. Within each programs
> there was liable to be packed and unpacked dates. STRICTLY GRUNT WORK.
> However, try it with one newbie Coboler and 1 newbie on-line person!

> Anyway, we'll make it; 5 weeks to go.

> Richard Jackson
> Houston, Texas
> (The new taxes died in the legislature - Gov. Shrub has egg on his face)

        I read about one interesting case where a customer account number was
being derived from a transaction date.  This stopped working when
converted to a four-digit year.  It was not the fixing that was
difficult, but the finding...

JR



Sat, 13 Nov 1999 03:00:00 GMT  
 Year 2000

I thought I would throw in my 2 cents worth on how the year 2000 is being
handled in the insurance industry.  We pretty much convert every file
(with any type of date)  and every program that touches them because, of
course, you can have 100+ year old homes, and believe it or not.......
cars dating back to the original invention (I didn't know these even still
existed!).... Most of the dates I have run into have been julian or
relative, relative of course being easier to handle (although it is
amazing how many of these need some type of conversion because many
situations require date comparisons... i.e. relative converted then
compared to a julian)  It is certainly a mess developing and testing many
different systems and how they communicate to each other, but the company
I am with has started far ahead of time, and is on pace to be done a year
before the year 2000 even gets here.  This y2k project has gone on for
about 2 1/2 years, and will take at least another 1 1/2 years to finish.
The testing is certainly the most time consuming part. (not counting the
analysis of course)  If any company needs changes like the company I'm
with and has yet to start y2000 changes, they might as well close up
shop.......... anyone working for companies that are way behind and not on
pace?  Just being nosy........and putting in my 2 cents. :)



Sun, 14 Nov 1999 03:00:00 GMT  
 Year 2000

Quote:

> How is everyone handling the Year 2000 problem ?

> This is how I am doing it but I am interested in anyone else's plans:

> Change all dates from PIC 9(6) to PIC 9(8) and writing file
> conversions for each file.

At my shop we are not converting files unless absolutely necessary (date is
part of a VSAM key).  Most of our dates have very short time horizons, less
than a year.  Historical data for billing purposes never has a date more
seven years in the past.  Credit card expiration dates should never be more
than 10 years in the future.  The problem with file conversions is multiple
systems have to be converted at the same time, because they use the same
file.  This is difficult when you run 24X7 and no down time is allowed.

We use windowing logic for date compares.  Standardized routines have been
developed to minimize the risk of coding errors.  Our standard window is 1950
to 2049.  If our time horizons were longer, I would expect us to do more date
field expansion, and less interpretation through windowing.  I believe
interpretation through windowing is relatively easier to implement (where
it's appropriate) because components can be implementated with fewer
consequences to other systems.

Utility date routines were tested and modified.  Some of them have been in
used for years and did not handle leap years correctly outside the range of
1968 to 2000.  All the existing routines only supported 2-digit years with a
window of 1900-1999.  The most critical routines were modified for the new
standard window, and an additional routine requiring 4-digit years was also
built.  

One problem I had was a critical routine used to determine if a bank in any
part of the world was open.  I needed to adjust for GMT and DST.  For the
USA, our Daylight Savings Time table ran out at the end of 2000.  I had to
look up the rule in an almanac and extend the table until 2010.  Of course,
Congress can change the law on DST anytime...

We are still waiting on our Tech Services department to install a release of
SyncSort that will support windowing of 2-digit years in utility sorts.

Taking inventory was a fairly large effort.  But as someone else pointed out,
most of the work will be in testing.  Testing will find what analysis will
not find.  You need good test procedures and LOTS of dedicated resources for
testing.  Those resources include additional CPU & DASD capacity as well as
warm bodies.

Quote:

> Make no changes to screen input/display but if a year is entered > 77
> then it has 19 stuck on the front else 20.

As I said before, we're using a standard window of 1950-2049.  Dates in
reports and screens will not change unless we get a user request.  Our first
priority is to keep our systems running.

Another issue that came up in analysis is end-user ad hoc Excel and Access
applications.  We will warn end-user areas about potential problems, but
they have to fix their applications themselves.  We don't have the manpower.

Quote:

> In an ideal world, all dates which appeared in the key of a file
> would have been PIC 9(6) COMP in which case it could have stayed the same.

> Paul

While it would have been nice if those file dates had been allocated for
4-digit years, I am certain that 2-digit years will continue to be used for
data entry forever.  We don't write '19' on our checks.  It's been
pre-printed for our convenience.  I have also seen online systems where the
productivity of data entry personnel was measured in keystrokes!

I think we'll be ready.  I won't say we won't have any problems, but we are
working very hard and management has put a lot of money into this project.

Arnold Trembley
Software Engineer I (just a job title, still a programmer)
MasterCard International
St. Louis, Missouri



Sun, 14 Nov 1999 03:00:00 GMT  
 Year 2000

Quote:

> I thought I would throw in my 2 cents worth on how the year 2000 is
> being
> handled in the insurance industry.  We pretty much convert every file
> (with any type of date)  and every program that touches them because,
> of
> course, you can have 100+ year old homes, .....

How does your current system deal with homes built in 1897, or people
born before 1900 ?

Bill



Sun, 14 Nov 1999 03:00:00 GMT  
 Year 2000



Quote:
> How is everyone handling the Year 2000 problem ?

> This is how I am doing it but I am interested in anyone else's plans:

> Change all dates from PIC 9(6) to PIC 9(8) and writing file
> conversions for each file.

> Make no changes to screen input/display but if a year is entered > 77
> then it has 19 stuck on the front else 20.

> In an ideal world, all dates which appeared in the key of a file
> would have been PIC 9(6) COMP in which case it could have stayed the
same.

Almost the same.  We are converting only when the dates are in key fields
or are sorted upon.  All other applications are changed to internally
create 8 digit compare fields and use a similar method to stuff century
before each compare.


Sun, 14 Nov 1999 03:00:00 GMT  
 Year 2000


Quote:
>anyone working for companies that are way behind and not on
> pace?  Just being nosy........and putting in my 2 cents. :)

Yes.  Our president, who had a mainframe background is in serious denial
about the scope of the problem here.  We (the entire staff) brings up the
issue constantly.  In early 96 I got permission to work on it in my slack
time, and I got 1 small sub system fixed, but we have 3000 programs yet to
even examine.  We are about 1/3 RPG. 1/3 ASM and 1/3 COBOL.  We are in
serious trouble, and I'm job hunting.  It hurts though.  I've put 14 years
into this company.  I like the people, the work and I believe in our
product.  Sad.  Very very sad.


Sun, 14 Nov 1999 03:00:00 GMT  
 Year 2000



Quote:

[snip]
> We use windowing logic for date compares.  

I do have a question about this. alot of mainframes, 3090, AS/400,
Unisys etc. can be accessed by ODBC complaint drivers. So how does
the accounting manager using Excel know that the spreadsheet they
have been using doesn't work anymore?

[snip]

Quote:
> While it would have been nice if those file dates had been allocated for
> 4-digit years, I am certain that 2-digit years will continue to be used
for
> data entry forever.  We don't write '19' on our checks.  It's been
> pre-printed for our convenience.  I have also seen online systems where
the
> productivity of data entry personnel was measured in keystrokes!

> I think we'll be ready.  I won't say we won't have any problems, but we
are
> working very hard and management has put a lot of money into this
project.

> Arnold Trembley
> Software Engineer I (just a job title, still a programmer)
> MasterCard International
> St. Louis, Missouri



Sun, 14 Nov 1999 03:00:00 GMT  
 Year 2000

Quote:




> [snip]
> > We use windowing logic for date compares.
> I do have a question about this. alot of mainframes, 3090, AS/400,
> Unisys etc. can be accessed by ODBC complaint drivers. So how does
> the accounting manager using Excel know that the spreadsheet they
> have been using doesn't work anymore?

Maybe someone will write an Excel add-in that scans for 2-digit date
formats. Seems there's a market for this sort of thing.

Just a note:
in Windows(both 3.1 and win95), the user can set the default date format
to either 2 or 4 digits on the control panel. Most users' machines are
set for 2-digit dates. Much PC software looks at those default settings
before storing data to external formats.

Quote:

> [snip]
> > While it would have been nice if those file dates had been allocated for
> > 4-digit years, I am certain that 2-digit years will continue to be used
> for
> > data entry forever.  We don't write '19' on our checks.  It's been
> > pre-printed for our convenience.  I have also seen online systems where
> the
> > productivity of data entry personnel was measured in keystrokes!

> > I think we'll be ready.  I won't say we won't have any problems, but we
> are
> > working very hard and management has put a lot of money into this
> project.

> > Arnold Trembley
> > Software Engineer I (just a job title, still a programmer)
> > MasterCard International
> > St. Louis, Missouri



Mon, 15 Nov 1999 03:00:00 GMT  
 Year 2000

Quote:

> We are still waiting on our Tech Services department to install a release of
> SyncSort that will support windowing of 2-digit years in utility sorts.

In case you get tired of waiting for the new release of SyncSort to be
installed, as I did, there is a way to sort 2-digit years with the old
version (assuming you can window dates). Use the ALT SEQ command. We
have no dates in my system prior to 1980, so I changed the sort sequence
for the first digit of a two digit year to be:

        8 9 0 1 2 3 4 5 6 7

Just map 8 and 9 to the two positions before 0. Then sort the rest of
the date as you normally would. A similiar method also works for packed
dates but the mapping gets a little more complicated.

Mark



Mon, 15 Nov 1999 03:00:00 GMT  
 Year 2000

Good question :)  Currently these "old" dates are handled via relative
dates, which can then go through one of many different conversion routines
to get the correct year (or assign a rating to it, etc.)  The big problem
is that many different systems all need to communicate with each other
(and the other systems use greg or julian dates), and now because the
other systems have all changed, so too must the
"relative dates" system.  Everything is now being converted to be on the
same scale, i.e. all gregorian, etc....  I'm sure this probably sounds
confusing, but it is difficult one to explain without actually seeing how
the system works.  :)  



Tue, 16 Nov 1999 03:00:00 GMT  
 Year 2000



Quote:


> >anyone working for companies that are way behind and not on
> > pace?  Just being nosy........and putting in my 2 cents. :)

> Yes.  Our president, who had a mainframe background is in serious denial
> about the scope of the problem here.  

I'll ante up on this .... I have a contract with a company that has
diligently been using eight position dates since the early 1980's in their
databases .... Just a few little wrinkles to think about, i.e. how do the
COB74 based program "bridge" the date (is the "19" a hard coded value?) ...
Need to get to VSE/ESA 2.2 for the OS to be fully Y2K compatible .... The
application development package hasn't been upgraded since 1989 and until
such time it is not Y2K compliant ... The point being even though the dates
appear already in compliance, each application should still be looked at to
insure that they are indeed ready for the change of century.


Tue, 16 Nov 1999 03:00:00 GMT  
 Year 2000

This is a multi-part message in MIME format.
--------------DCA8B781C9C5C10E163AA23B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Quote:


> > How is everyone handling the Year 2000 problem ?

> > This is how I am doing it but I am interested in anyone else's
> plans:

> > Change all dates from PIC 9(6) to PIC 9(8) and writing file
> > conversions for each file.

> ...  Credit card expiration dates should never be more
> than 10 years in the future.

I'm currently on contract to a charge card outfit and, in the UK, the
Y2K project is well in hand though, as a temporary measure, cards are
now issued with a two-year expiry rather than the standard three-year
term.  I assume that Arnold's outfit have also had Y2K catch up with
them faster, I assume, than most other industry sectors.  I'm not sure
about the US but I know that all plastic issuers in the UK have agreed
coordinated Y2K standards and implementations.

Quote:
> We are still waiting on our Tech Services department to install a
> release of
> SyncSort that will support windowing of 2-digit years in utility
> sorts.

Surely a simple exit routine (or set of exit routines) would help here
- at least it could spread the workload a bit onto the ops analysts...

Quote:
> Taking inventory was a fairly large effort.  But as someone else
> pointed out,
> most of the work will be in testing.

The analysis was a hell of a tedious job, and I'm only too glad that I
haven't had to do it.  But now comes the testing and it is entailing a
complete rebuild of all systems in Test to ensure that everything is
covered.  It is a mammoth task and there is plenty of work available
on this.

Quote:
> Another issue that came up in analysis is end-user ad hoc Excel and
> Access
> applications.  We will warn end-user areas about potential problems,
> but
> they have to fix their applications themselves.  We don't have the
> manpower.

I don't know the position in my shop about this but I suspect that
it's the same as yours.  If users want to engage in programming, they
should expect to support it themselves.

Quote:
> I think we'll be ready.  I won't say we won't have any problems, but
> we are
> working very hard and management has put a lot of money into this
> project.

I think we will also be ready.  I think the card expiry date had a lot
to do with prompting the business into treating this with the spirit
of urgency it deserves.  From talking to friends in the programming
game over here, it seems that some companies have not had the needed
kick up the managerial backside for them to closely focus on what's
needed.  However, most do seem to be on top of the problem, if they
can only get the resource to do the job - and I guess that's a global
problem.

Charles

--------------DCA8B781C9C5C10E163AA23B
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Charles Hankel
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Charles Hankel
n:              Hankel;Charles
org:            Freedom Bird Ltd
adr:            38 Borough Way;;;Wallasey;Merseyside;L44 6QU;United Kingdom

title:          Director
tel;work:       0151-639 9839
tel;fax:        0151-200 1957
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
end:            vcard

--------------DCA8B781C9C5C10E163AA23B--



Wed, 17 Nov 1999 03:00:00 GMT  
 Year 2000

...

Quote:
> Make no changes to screen input/display but if a year is entered > 77
> then it has 19 stuck on the front else 20.

Would highly recommend instead using a sliding 100-year window based on
current year (4-digit of course) rather than using a fixed window (one
starting at 1977 in your example above), which is guaranteed to break in
the next century.  You never know how long clone fragments of the code
you write today may persist in future versions of applications--it only
takes minimal additional effort to use a sliding window and avoid having
your name cursed by programmers of the 2070's.
--



Fri, 19 Nov 1999 03:00:00 GMT  
 
 [ 16 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Is year 2000 a leap year??

2. Extensive cobol year 2000 methodology by TOPIC-2000

3. Cobol year 2000 solutions by TOPIC 2000

4. Year 2000 Newsgroup

5. OS/390 Release 2 Year 2000 discussion

6. Year 2000 IBM Asm370 Booming Job Market

7. Sr. Programmer/Analysts for Year 2000 project

8. Sr. Programmer/Analysts for Year 2000 project

9. Year 2000 course available

10. Year 2000 issues panel at TOT Conference

11. The Year 2000 and Commercial APL

 

 
Powered by phpBB® Forum Software