Conference evms::y2k

58.0. "Thoughts on what we have done in the File system so far" by MOVIES::WHITAKER () Sat Feb 22 1997 07:01

Folks,

I'd like to share a couple of things about what we are doing in EDO to
investigate Y2K issues.

We have a fairly significant amount of code and a line-by-line review
is certainly not the most cost-effective way to cover any issues.
Therefore, like many other groups, we are using a known list of
date/time related cells/routines/structure fields and searching the
sources as an initial starting point. From then on we will review the
code paths that are highlighted.

I've put together a little search tool which takes the list of known
references and searches the sources. (I've sent it to Richard Bishop
just as an FYI for what he is doing).

A bunch of things came out of what we have done so far

An OpenVMS  facility typically has many references to shared data
structure types defined in starlet, lib or shrlib. To search a
facility, we need to find the external references.
For macro, its pretty simple, the listing has all the symbol
definitions in it. For Bliss, its a little more tricky, modules tend
to have things such as: LIBRARY 'SYS$LIBRARY:LIB'.
This makes finding the dependency list a little tricky. To fix this, I
used the /cross_reference qualifier on the compiler. Unfortunately,
this is not available on Alpha (ooops!). As it happens, most of our
code is common VAX and Alpha or as near as common that we can get a
valid listing file by compiling the Alpha sources on VAX.

Once we have the list of symbols, its a mechanical process to figure
out which .SDL files or other include/require files we need from
outside the facility.
We are then doing line-by-line reviews of the SDL files to find
time/date related fields and adding them to our search list.

My guess is, most folks will follow a similar mechanism. What we need
to have to avoid is duplication of effort searching common files.
I have 2 suggestions which align with what we have so far:

1) Keep a file in DOCD$ or somewhere public that has all currently
identified cells/routines/structure fields and keep it up-to-date.
It looks like this is almost there?

2) Also keep a list of modules from starlet/lib/shrlib that have been
checked. I noticed that some UCB and PCB symbols have appeared in the
list in the back of the user's guide. We need to avoid duplicating
searches.
    

Hi Karen,

>>Thanks for posting the reply in y2k regarding the lib/starlet 
>>stuff you've investigated.  I just want to check one assumption ...
>>have all these passed?

To clarify, we did a line-by-line review of the SDL files in the note
and found all date/time related fields without looking at what they
are used for or who they are used by.

We added these to our search list and found a bunch of hits in the
facility we were checking. From these hits it is reasonably easy to see
what the format of the field is in and whether the code we are investigating
has any year 2000 problems.

It is not possible to tell whether the field itself is "safe".
Consider the following scenario:

One module uses full 64 bit times to fill in a field. Another module, in a
completely different facility uses a 2 digit year based time and converts it
using some broken method, then puts the time in the same field.

For shared structures, a simple pass/fail is not possible before we
have investiated all the code across all the facilities that use the same
code.
This is troublesome, especially where different groups own pieces of code
that use shared fields. 

Suggestion:

We assume that the fields are "safe" where it is clear that the format is safe,
i.e. a 64 bit binary time or a string with a 4 digit year.
When we find a piece of code that uses such a field incorrectly, the code is
QARed as expected.
Once we have done the full pass, we need to look at all QARs where a shared field
is filled in using some bogus mechanism and assess whether to fix the code
that is broken OR look at all other uses of that field and document the impact
of the broken code.

/Chris