HP1000/RTE

Overview

As mentioned in the referring article, the main concern with RTE-6 is the routine FTIME. Unfortunately, even though FTIME was fixed back at 5.0 (5000) for RTE-A, the fix was not incorporated into RTE-6 until the 6.2 release. Since many of these older systems are still in operation today, albeit with limited technical expertise, we decided to provide a more detailed look at the problems in a typical Pre 6.2 system and make some suggestions as how to fix them.

First, be assured that the basic time keeping mechanism in all RTE systems is the same and is independent of months, days or years (see How time is managed in RTE-A for the details). This means that even RTE-2 will roll over to the year 2000 with no adverse consequences (although setting or displaying the time may be a problem).

Also note that versions of RTE-6 prior to 5010 (5.1) should be upgraded if you want to be able to set the time via the CI TM command. This was due to a problem in SETTM, which is used by CI, of not being able to set the date beyond the year 1999. The system (and FMGR) TM command does not have this problem.

FTIME

Programs that use FTIME will be of the most concern. Here are the programs that ship with RTE-6 which use FTIME.

DRREL
EDIT
FC
FMGR
LOADR
LUPRN
MACRO
MLLDR
PSAVE
RT6GN
SGMTR
WRITT

Some of these programs are rarely used any longer and all but two can be re-linked online with the newer version of FTIME (See the SR030064 patch). Two programs (FMGR and LOADR) however, must be generated into the system and fixing them is problematic. Before jumping into a re-generation, however, you might want to know the consequences of not updating these particular programs. LOADR only uses FTIME to print the time in the "load map" when the program is loaded. Its erroneous year field in the load map in no way affects the integrity of the load.
FMGR only uses FTIME for the somewhat esoteric "SM" command which sends a message to another user. It is only used to timestamp the message. If you can live with these two problems you may be able to avoid a re-gen.

Using the corrected FTIME, then, it is possible to re-link the other programs by just adding a LI,%FTIME (assuming you downloaded the patch) in the appropriate place of the link/loadr command files of those programs that call the routine. One additional caution here, the "LI" command should cause the linker to search this file first before the system libraries but you should check the load maps to be sure the correct version of FTIME was used. You can also force load the module with the RE,%FTIME command but this could have adverse affects on segmented programs.

An even easier way to remedy this problem, and guarantee that all linking of future programs automatically gets the new FTIME is to run LINDX on the system and specify the FTIME module as an additional library to search before searching the system library. Some examples of this are given in the *DOSNP FMGR command file supplied with RTE-6. For example,

lindx,system,snap.6::2,/libraries/%ftime,
/libraries/$fmp6.lib,/libraries/$fnewf.lib

This brings me to the final and most complete solution which does not require any of the above messy options, nor does it require a re-gen of the system. In fact, it works for LINK, LOADR, and MLLDR with no re-LINDXing of the system and no changes to any LINK/LOADR command files. So why did I not tell you about this in the first place? Well, the above methods, although not as clean, are all workable with standard HP software. This last method requires getting a utility from Interex's RTE CSL (Contributed Software Library) which can replace, on-line, modules in the system library. The utility is INSTL (from the 2625 CSL, contribution # K028. You also will need library routines found in contribution # K024 from the same CSL revision. After replacing FTIME all subsequent LINKs and LOADs will use the new routine. For more information in obtaining the CSL check the member services web page at Interex.

Edit/1000

EDIT/1000 is harder to deal with due to the fact that it is so intimate with the OS and file system. It has changed in every major revision since 5.0. Edit also has two date concerns. First, it calls FTIME to get and format the time for the TI command. This is easily resolved by updating FTIME routine with one of the above procedures. More importantly, the Edit timestamp code is intrinsic to Edit and requires getting an updated module specific to the revision of OS you are on. We have not developed all these various versions of Edit with this fix but you can contact the Response Center for the current list and if available we will send it to you. If the version you need is not available and you have an HP 1000 support contract we will create a corrected version of Edit for your version of the OS. If you are not on support, expect to pay for the time and materials to develop it for you.

Pascal routines

Two PASCAL routines, PAS.TIMESTAMP and PAS.TIMESTRING, are not used in any HP supplied RTE-6 programs but if your application code does call these routines we suggest you search the latest PASCAL libraries to selectively link/load these modules. The module (PAS.TIME) is quite self contained and can be used with 6.0 - 6.2 versions of the OS. It will most likely work with versions previous to 6.0 but we have not tested it.