Advanced Revelation (Arev) Year 2000 (Y2K) Compliance - free software offer

See below for free software offer

Many users of the Advanced Revelation (AREV) 4GL environment assume that because the AREV development environment is Year 2000 compliant, applications written in this language will also be compliant. This is not necessarily the case as many AREV sites may find out on 1st January 2000.

Financial Solutions Limited ([email protected]) has completed several Year 2000 audits involving Advanced Revelation applications. Problems found range from the minor ("19":YY on reports) through to the more serious. To assist others with Arev Y2K work, a list of the type of problems found, plus a list of ?trigger? values to search for, are listed below. This ?trigger? list also includes contributions from other AREV users. Any contributions you may have to this list will be appreciated and this item plus any new examples submitted will be re-posted at regular intervals, published on a Web Page or sent to you personally if you send us your email address.

Due to the large amount of AREV code that we have been required to check, Financial Solutions Limited has developed a comprehensive AREV Y2K Scan program to automate a significant percentage of the task and to ensure that the work is carried out systematically. This will be formally marketed at some time in the future as time permits - currently our schedule is very busy.

The generic SCAN process involves scanning all source code in windows, data dictionaries and program source. Data dictionary items are detected and used as scan triggers as well as literal values (see below for a list of these). Each item ?triggered? (dictionary item, program source file or window) is prioritized based on individual trigger weightings and the number of ?hits? on each item. The printed/displayed results for each item includes which triggers were found, the lines of code triggered plus a specified number of lines (1 to 9 or All) surrounding each triggered line to aid result checking. We plan to offer our scanning service on-line - clients will be able to email us their Arev applications, our scan program will then be applied and a Y2K assessment and/or scan results are then emailed back.. Larger applications may need to be sent via CDROM or diskette. If required, the outsourcing of any Y2K fixes required can also be outsourced to our team of on-line and local Arev sub-contractors. We will p

ost further details when we have this service up and running.

We would like to share with other AREV users some of the knowledge we have gained over the past few months with our Arev Year 2000 assessment work.

AREV Y2K PROBLEM EXAMPLES

*1. Leap Year Incorrect determination of a leap year. The Year 2000 is a leap year. A leap year is determined, in most cases, by checking if the year is evenly divisible by four - if so then the year is assumed to be a leap year. This will give the correct result for the Year 2000. However, for the years 1900 or 2100 this does not work and therefore, some calculations have had additional accuracy added by determining whether the year is the first year of a century i.e. divisible by 100 - if so then it is assumed that this is NOT a leap year - WRONG - 2000 is a leap year!. The first year in a century is a leap where it is evenly divisible by 400 - some programs fail to make this extra check. You are particularly vulnerable to this problem if your application holds and calculates with dates pre-1900. The correct Arev code to determine a leap year is as follows: LEAP_YEAR=N" IF MOD(YEAR,4)=0 THEN IF MOD(YEAR,100) NE 0 OR MOD(YEAR,400)=0 THEN LEAP_YEAR=Y" END *2. Index formats

To save space, indexes which are formed as symbolic fields may use the YY format. This can cause problems with sorting, selecting and any reconstructing of the year back to the YYYY format.

*3. Accounting months It is not uncommon for systems to use the YYMM format to name, index or reference accounting months - calculations, sorting and selection can be affected. *4. Hard Coded 19

Hardcoded ?19? on output reports and in particular pre-printed forms. The instance we found was a relatively minor problem but in some cases, using a hardcoded ?19? can cause problems of a more serious nature.

*5. Adding to a Year One instance found was where ?1? was added to YY which was subsequently used to build a DDMMYY value (Note: we use the English format for date). This value was ICONV?ed to get the same day next year. This works with 97, 98 BUT what about 99 and up? The result returns three digits when added to 99 ( result: 100) and 1 digit for 00 (result: 1) - neither suitable for slotting into the YY position without further massaging. *6. DATE()

The DATE() function accesses the hardware date (BIOS, CMOS etc.). If the hardware is not Year 2000 compliant, data could be scrambled and/or lost on any of the critical Y2K dates. Compliance of hardware is a very complex issue (I am still waiting for an authoritative/definitive answer on hardware compliance issues) and needs to be taken into account if you haven?t already done so. To prevent users continuing with a faulty date it may be a good idea to put in place a check for a ?reasonable? date of some sort each time a user logs on to Arev. Our company will develop a date check routine in the near future (this should be a reasonably simple procedure) - we will make the source code freely available. The logon date routine will pick up any Y2K compliance hardware failure that checks have either failed to detect or users have failed to do anything about.

*7. DOS filenaming Traditionally DOS filenames have had a limitation of 11 characters - 8 for the prefix, 3 for the suffix. Often the date is required to be incorporated into the DOS filename of data files imported and exported. Sometimes the YY form of the year is used when creating this date and this may be a problem when sorting, selecting and/or archiving these files. Other ?odd? problems could also arise when processing such files. *8. External Interfaces

Where an Arev application receives in a YY date format or exports YY date formats to external systems, it is recommended to check that the points of interface within those systems have also been detected and checked. A checklist of all points of interface containing YY dates would be useful to those working on the external systems? Y2K issues.

*9. Customers and Suppliers The viability of your computer system relies on critical Customers and Suppliers also being Y2K compliant. If a company loses crucial customers or depends on suppliers which may no longer be able to supply, your company?s computer system is no longer viable. It is therefore in your interest to give every assistance possible in ensuring that suppliers and customers are Y2K compliant, especially where they interact with or use your company?s computer systems. AREV Y2K TRIGGER VALUES It is useful to allocate a weighting to each trigger found, so that any scan results can be prioritised according to how likely it is that the item contains a Y2K exception. Triggers we have used are as follows: (1) Dictionary Field Name Scan Trigger Values Fields relating to dates need to be located so that these can be used as triggers when scanning code. *AGE* ANNIV BTH BIRTH CALEN *CEASE DATE DATES DEATH DECEASED *DTE *DAY *DAYS HOLS HOLID MDY *MNTH MONTH *MM MM* *MTH *MTD *TERM* YEAR YY YR YTD YRLY -Where applicable, also include these same values with full-stops instead of (or as well as) the underscores. -Where the relevant file is opened within the source code, the field position number should be scanned for. -Also include dictionary items with an ICONV or OCONV pattern that relates to date conversions. (2) Source Code Scan Trigger Values "19 19" "28" "29" *365* *366* 99*99*99 9*9*99 @USER0 @USER1 @USER2 @USER3 @USER4 *AGE* ANNIV BIRTH BTH CALEND CENTURY *CEASE *DAY* DTE DATE() *DAYS* *DATE* *DATES* *DATE$* *DATES$* *DATED "D* "D2* "D2" "D4* "D4" "D*E "DE" "DF" "DG" "DH" "DI" "DJ" *DDD* DECEASE DEATH *DEAD DMY DDMMYY DDMM DD*MM DOB *DT* *DTE* DURATION *DY* END EXPIRE ELAPSED *FEB* FEBRUARY *GMT* GREGOR *HOL* *HOLS *HOLID LEAP LYD LYTD *MDY* *MM* MM*YY MMYY MM*DD MMDD MONTH *MTH *MM* *MMYY MNTH MTD PERIOD *TERM* TERM* WEEK *WK* WKLY *WW* YEAR YMD YR* YRLY YTD* YY* YYMM Note: An * in the trigger values listed above indicates a non-alphanumeric character match is required. Before using these triggers to scan the source code, the code needs to be adjusted as follows: - convert lower case to upper case - convert single quotes to double quotes - other ?massaging? as necessary to ensure all triggers are detected and mis-hits are reduced - i.e. swap out values that give mis-hits e.g. "L#19" - either skip comments or adjust trigger weightings for triggers found in comments accordingly The following triggers were also found useful in locating points of interface with external interfaces and in checking that DOS file names were Year 2000 compliant. OSWRITE OSBWRITE OSREAD OSBREAD OSOPEN Note: In most instances, scanning for any time related triggers will be overkill. * FREE SYSTEM CROSS-REFERENCING SOFTWARE * Software tools have been developed in-house to assist our Y2K work , this includes a very comprehensive AREV cross-reference program which will create a TREE file consisting of all programs, windows, popups, datafiles etc. A treetop or treetops are able to be specified (i.e. the main menu(s) and/or other odd programs, windows etc. - i.e. the MAIN menu) and this provides for all logic paths to each item to be detected and listed - i.e. an item can be tracked from the main menu through any subroutine, window or ?include? file. Menu items ?kicked off? as parameters into ?security? routines are also handled. The detection of these logic paths greatly assists in testing changed systems and eliminates the Y2K checking of items which have become redundant. Our TREE program is freely available to anyone who would like a copy, however there is a charge of $US200 for the version which will work with applications with over 1000 items in the TREE. See below for the email address. This software will also process G2B RDES files but must be run under Arev. The TREE routine can be re-run any number of times, either clearing the TREE file first or re-creating it from scratch. Items included and cross-referenced on the TREE file are data files, windows, ?include? files, dictionary items (only those ?named? in source code or those calling or called by other items occur in the TREE file), popups, and menus. R/LIST, QUERY & FORM statements are not analysed. Note: Window items include ALL processes (including compile & run code) and all window and field register. The TREE file structure is as follows: Field 1 - Items called by this item - blank if a File item Field 2 - Items that call this item - blank if a File item Field 3 - Files written/updated by this item. Includes files used updated by Window items and files used within R/BASIC WRITE statements. If this item is a File, then this field will contain all items that write/update to this file Field 4 - Files accessed by this item. Same as for Field 3 but also includes files XLATEd, READ, and OPENed as well as POPUP files, Window Verifiles etc. If this item is a File, then this field will contain all items that access this file Field 6 - The filename(s) of the file(s) containing the Object code for this item if it is a R/BASIC routine. Filed 7 - The location of the where this item is cataloged to in the VOC file if it is a R/BASIC routine Field 8 - The filename of the file where this item is located. If the item is a File, then contains the volume name(s) where the file is located. If an R/BASIC routine, then contains the filename(s) of where the source code is located. Field 9 - Same as Field 2 but only contains those tree items that have been verified as being called from a specified ?treetop? - i.e. if this field is blank then no verified path has been detected to the item and it is therefore likely to be redundant. This also includes ?file? items, allowing redundant files to be detected. Field 10 - the date and time that the item was created on the TREE file Field 11 - the date and time that the item was last updated on the TREE file The TREE file can be listed to show any exceptions encountered - i.e. object code that has no associated source, filenames & fieldnames & other items that are unable to be deciphered by the TREE program (due to the use of variable names - a large percentage of these are able to be resolved by the scan program, however), items detected in a verified path that cannot be found etc. These exceptions will highlight any files that were not specified to be processed - the TREE process can then be re-run with these files. **

If you have any queries relating to the above, would like a copy of the TREE software, have information to add re Y2K problem examples or have an interest in the AREV Y2K SCAN application (either as a potential user, Arev teleworker or software marketer)

please email Peter Davies at [email protected].

I have noticed that General Revelation (G2B) does incorrect screen date translations in that a year 2000 date is converted to the internal format of 0 AD. (ONLY GREV, NOT AREV!)

  The way to test this is to do an ICONV of the date 01/01/00 for the D2/ format.  It will always return the internal date of -718796.  Which is perfect if you are keeping a database of Greecian tax forms. The obvious way around this is to use the D4/ conversion which correctly returns the internal date of 11689 for the date 01/01/2000.

1. BUT -

While this works when you are doing an ICONV from TCL or inside a program, it DOES NOT work in a screen created by SCR. The screen will convert the D4/ date of 01/01/2000 to -718796. I don't know if this has something to do with prompter or the verb that does the screen data conversions, but I'd really like to know a way around this problem!! (Or all our G2B databases will need to be converted by 12/31/99)

RTP26 in G2b has a bug that converts the years 2000-2009 to the years 00-09 when ICONV uses a 2-digit format. We have a version of RTP26 that was corrected for this problem (several years ago, under RTIs Advantage Gold program). The non-disclosure we had to sign for this correction has expired, so we are free to distribute it. If you would like a copy, e-mail to [email protected]

A hidden date problem can exist in Julian dates. I have not run across a reference to them any of my readings on Y2K. Julian Dates are common in the US Military and we use them extensively in our business. A julian date takes the form YDDD or YYDDD where 7033 or 97033 represents 2/2/97 or the 33th day of the 7th year.

The more popular form of this YDDD is a problem every 10 years.

You said,

The correct Arev code to determine a leap year is as follows:

LEAP_YEAR=N"

IF MOD(YEAR,4)=0 THEN

IF MOD(YEAR,100) NE 0 OR MOD(YEAR,400)=0 THEN LEAP_YEAR=Y"

END

Since Arev determines leap years correctly, I prefer the more straightforward:

LEAP_YEAR=ICONV(YEAR:'/02/29','DJ')

Result is used as a boolean value.

Hi Peter:

I have about 20 corporate clients left using our AREV 3.11 application (tracks internal training and development) About half are conducting in-house testing.

I am interested in your free software offer. Could you please send me more information and how you feel it could help their testing and our testing for Y2K compliance. Thanks

Mike O'Beirne

Director, HRD Products

Radnor-Wallace

Port Washington, NY

email: [email protected]

phone: 516.767.2131

Please tell Jocelyn that we're still interested for SENL…

[email protected]

Sprezzatura Ltd

World Leaders in all things RevSoft

I would love to obtain a copy of the Y2K Scan Software

Will email you direct

I am interested in your free software offer. Could you please send me more information in regards.

Thanks.

[email protected]

View this thread on the forum...