Finally cracked the code on the IRIS system clock! So now we can make it work a lot better. In fact, the latest download system now shows the current date in 2017.
There were always a few quirks with the IRIS clock that never got resolved to my knowledge. For starters:
- IRIS 7.5 had a fixed creation date of 1-1-1980.
- IRIS dates require 2 binary words. The first word is the number of hours since 1-1-1980. The second word is the number of tenth-seconds in the current hour. At the system level, in the INFO table, this time is maintained by the 10hz task.
- This means the clock will only run for 65535 hours from the system creation date, or about 7 and 1/3 years. After that it just stops somewhere around May 3, 1987. That was actually an improvement over IRIS 4.3 (the 1st version I worked on) which did a TRAP #0.
- Given that our IRIS system was running in late 1986, that did not give us much more time before the clock became completely useless.
- On any given day, if you typed the date incorrectly when booting the system, IRIS might time stamp any files that were referenced with that incorrect date, and things would look weird. For example, after re-entering the system date correctly, LIBR might show that it had been 64000 hours since the file was used. That was because subtracting the file date was greater than the system date, and the difference was actually a negative number.
- After a certain number of hours, the LIBR and QUERY information about the file date was fairly useless. What does it mean that the file has not been time used for 1317 hours? Does anyone know off the top of their head how many weeks or months that is?
- All months had 31 days. Did you know that? It makes for easier conversions. But you can actually set the date to Feb 31. And a file used on April 30 was suddenly 48 hours old on May 1. A minor issue to deal with in exchange for simple algorithms.
- Bugs in CALL 99 and the internal conversion from ASCII to binary permit illegal dates to be entered without any errors. Using the format “YYYY, MM, DD, HH, MM, SS, TT” it will allow up to “33” for a day of the month, and up to “14” for the month code. Using the “MMM DD, YYYY HH:MM:SS” format, it hardly validates anything — it just converts each value to hours and adds them together. Of course when you display it back it shows January for month 13 and a following month for days that are too large.
Fixing the Base Date
The first thing to fix was the base date, which is buried in a couple of discsubs that convert between binary hours and readable ASCII dates. (Beyond doing the conversion, the System Base Date does not have much meaning). By changing the constants, a new base date of 1-1-2016 can be setup. That makes the date relevant, and gives us until May of 2023 before it needs to be fixed again. (Details are in the download info).
Improving the LIBR Display
By patching LIBR, it is possible to make it display something like “02-14-17 13:14” for the “Last Used” date instead of “1433” for “HSLA” (hours since last accessed). This is more what we are used to seeing in modern systems.
Resetting File Dates
Since IRIS was running in 1986, every time stamp on the files was up around 58,000+ hours since base date. Setting the base date to 2016 made everything look like it was last used in 2022, which is weird. So I wrote a little program TIME.RESET which turns all the files back to January 2016.
For those files that you want to show current use, I made a tiny utility called TOUCH (after the similar Unix utility) which sets a file’s LDAT (last access date) to the current system time.
With all the above changes, we can now use LIBR to show recently used files and limit the display to what has actually been used. For example:
# LIBR <4
will list all files that have been accessed in the last 4 hours.
While someone might want to create a more accurate algorithm or do better validation, that has not been done yet. For now, these new updates are available in the latest C114 drive download.