OS/32 & Series 3200 SIG #6
by Stuart Baker
At Interchange'96 a decision was made, based upon input from the members present, that the Interchange users group should continue as an independent organization completely separate from Concurrent Computer Corporation.
This monumental decision was influenced by a series of events that preceded the user survey. Prior to the annual meeting, Concurrent had already killed the interc BBS and had made it clear that no hardware of any kind would be made available for demonstrations purposes at the meeting! Also, even though the meeting was held in Ft. Lauderdale near Concurrent's new corporate headquarters, very little manpower support was forthcoming. As if this weren't enough, Concurrent delivered an ultimatum to the Executive Committee the evening preceding the opening of the annual conference -- all 'third party' vendors should be banned from participating or Concurrent would not participate. The Executive Committee made it clear that participation by third parties was an integral part of Interchange as defined by its Constitution and by-laws and that no changes were going to be made.
Since Interchange is now completely independent, this article starts out with my feelings about the directions of Concurrent under its new management. Frankly, I was shocked and very disappointed with the opening of Interchange'96. The keynote address by Courtney (Corky) Siegel was more of a tirade than anything else. I really hate to see Concurrent fall into the hands of someone with his short sighted "make a buck quick" philosophy. Corky basically said that Interchange in its current format was history, and that he would personally make sure it would cease to exist. He also said that Concurrent would sponsor its own users group, one that did not welcome third party participants. Every person that stood up to ask Corky a question was cross examined to determine if he or she was a friend (end user or customer) or an enemy (third party affiliate).
I have been working on the Concurrent platform since 1970 and have seen many cases where third party vendors have provided much needed support. Their hardware and software solutions have helped both Concurrent and their customers. In many cases, third party solutions have brought Concurrent new customers that would have gone elsewhere in their quest to solve their problems. In the case of LIMS users, third parties have helped existing customers stay on the OS/32 platform by providing the support they needed when Concurrent could not provide it. Admittedly, some third parties have brought competition; but competition is healthy, and the end result is usually better products and lower prices for all. I think that Corky's attitude toward third party vendors is totally unreasonable. It is not possible for Concurrent to completely support the wide variety of platforms that exist as a result of the merger of three separate companies. Third party vendors are badly needed to fill the many diverse needs of the user community. Interchange is the ideal tool for uniting users with the solutions they need.
Enough about Corky, let's talk about Interchange'96. We had a lot of good presentations. I would like to personally thank the speakers that I introduced at the conference. Lee Brueni of Concurrent did a presentation on the year 2000, a very timely topic (more on Lee's presentation follows). Paul Kingsley of the Orange County Sheriff's Dept Crime Lab described the method they use to connect a 60 PC Windows for Workgroup network to their OS/32 based LIMS system (all compliments paid to yours truly were unsolicited). Finally, David Vednor of Macrolink discussed their new 3200 Series Ethernet controller. Thanks to all of you for fine presentations.
As mentioned earlier, Lee Brueni gave a presentation on the year 2000, a subject of interest to anyone planning on using their OS/32 machine 3 years from now. Lee's article provides a lot of pertinent information about various OS/32 revisions. Anyone that is not running OS/32 R09-02 or above will be very interested in what Lee has to say.
For those of you that use Stuart Baker Software's products, you can be assured that all of our OS/32 and PC based products handle the year 2000 correctly. Obviously, if you are using a PC, it must be running an operating system like Windows95 or Windows98 that correctly handles the year 2000. The main difference between our implementation and OS/32's is that we chose 1980 instead of 1970 for our wrap point. This handling of the year 2000 is present in all of our products regardless of revision. Now on to Lee's article:
The Year 2000 -- by Lee Brueni
As one approaches the year 2000, more and more concerns are being raised about OS/32's ability to handle the year 2000. In looking at this issue one must break OS/32's handling of the year 2000 into three categories. The first is the OS/32 operating system itself, second are the utilities such as BACKUP, FASTBACK, etc. that are part of the OS/32 object package, and finally customer applications.
For customers wanting a simple and reliable solution using a R09-02 or later OS and utilities is the answer. Of course the customer will have to identify and modify any applications of their own which compare two dates or display a four digit year.
If the customer is using a OS older than R08-03, the only option is to upgrade. Not doing so will result in corrupted dates for any files created or accessed on or after 1 January 2000. Because of the nature of how these dates are corrupted, a user of the system may not be aware of the problem for some time.
If the customer is using a R08-03 or R09-01 OS and for what ever reason feels they do not want to upgrade to a R09-02 or R10-01 OS, an option does exist for them. The OS/32 R08-03 release is the first OS which supports the year 2000. There is one problem, the utilities in R08-03 and R09-01 do not support the year 2000. These customers must be willing to take the additional risks posed by mixing and matching different revisions of utilities and the OS. In the R09-02 release of OS/32 the following utilities were modified to handle the year 2000 and beyond; ACCT, BACKUP, FASTBACK, FASTCOPY, FASTCHEK, ERROR, OBJECT32, LINK, and AUDIT32. These were the only utilities in the OS/32 object package found to compare two dates or display a four digit year. Except for the AUDIT32 program, the other eight R09-02 utilities should be able to run on a R08-03 or R09-01 OS. Of course the customer will still have to identify and modify any applications of their own which compare two dates or display a four digit year.
As mentioned above, the customer will have to identify applications they developed which compare two dates or display a four digit year. The general assumption made when OS/32 Development changed the utilities listed above for the R09-02 release was a year greater than 70 would be treated as in the 1900's, a year less than or equal to 70 would be treated as in the 2000's. Let one assume the variable "year" contains the two digit year in binary, then the general algorithm used follows:
This provides a valid range of years from 1971 through 2070. The OS/32 Development group chose 70 because the model 7/32 first came out in 1974.
Having a understanding of how OS/32 maintains the current date will aid one in knowing which applications need to be changed plus how to change them. For this reason a more detailed discussion of OS/32's calendar maintenance follows. If one is not interested in the details one can skip the following discussion.
Calendar maintenance within the OS/32 operating system is handled by the routine TIM.DAY in the module EXTI. The TIM.DAY routine is part of the Line Frequency Clocks (LFC) Event Service Routine (ESR). This routine maintains the number of seconds from midnight, the current day, month, and year within the System Pointer Table (SPT). The year is maintained as a binary halfword in the field SPT.YEAR. With the release of OS/32 R08-03 the handling of the year 2000 is handled correctly. OS/32 only maintains the last two digits of the year in SPT.YEAR, for example the year 1996 is represented as 96 in SPT.YEAR. The correction included in the OS/32 R08-03 release insured SPT.YEAR would update from 99 to 00. OS/32 releases prior to R08-03 would update the two digit year from 99 to 100. This correction was resolved by SCR 13167 in March 1988.
The interface from an application to OS/32 is through an SVC. The only SVC which returns the current date is SVC 2 code 9. It returns the date as a ASCII string in the form mm/dd/yy or dd/mm/yy. Note: only the last two digits of the year are returned. Even though in a OS prior to R08-03 SPT.YEAR would contain 100 for the year 2000, the SVC 2 code 9 will only format the ASCII string 00. This is true for OS releases from R04-01 through R08-02. For OS releases from R08-03 through R10-01 SPT.YEAR would contain 00 for the year 2000. The SET TIME command only allows one to enter a number from 00 through 99 for the year, this is true for OS releases from R04-01 through R10-01. Therefore SPT.YEAR would contain a binary 0 if one entered a SET TIME command in the year 2000.
Another issue is the auto clock feature of a 3280/3283/3285/3298 system where the OS gets the current date and time from CDS upon boot. There is a problem in the R08-01 and R08-02 releases if one boots the OS between January 1 and February 28 of a leap year. The OS does not know that February 29 exists and therefore updates the date to March 1. This problem was fixed by SCR 13167 which is included in the R08-03 release. OS releases prior to R08-01 do not support the 3280 class machines.
CDS does have its own problems with years past 1999 and leap years, but as luck has it CDS's problems cancel one another. If one has the CDS date and time set properly before the year 2000, CDS will increment from 31 December 1999 to 1 January 2000 properly. In addition it will treat the year 2000 as a leap year as it should. The problem one will have with CDS is when one sets the CDS date and time after 1 January 2000. In this case CDS will set the year to 1900 instead of 2000. CDS will treat 1900 as a leap year even though it is not, but in this case 1900 is really 2000 which is a leap year. These two errors cancel themselves out. When the OS requests the date and time from CDS, CDS returns the four digit year of which the OS only uses the last two digits. Therefore OS/32 does not care if CDS has its year set to 1900 or 2000.
The only function within OS/32 that actually compares one date with another date is the DISPLAY FILES command when using the CTIME, ATIME, or MTIME options. These options to the DISPLAY FILES command were first added to the OS with the R09-02 release and do correctly compare two dates.
Within the realm of files and file management the date and time created, modified, and last assigned is maintained for each file within its directory entry in a format known as a directory format. The DATE.DIR routine in module FMUT relies on the calendar maintenance routine in EXTI to maintain a correct day, month, and year. Prior to the R08-03 release the year was not maintained correctly, therefore one can expect to have problems with file dates if one tries to use a R08-02 or earlier OS in the year 2000 and beyond.
The final area of concern one would have is with the timer services provided by OS/32. These are provided by SVC 2 code 10, SVC 2 code 11, and SVC 2 code 23. All these SVCs deal with a time interval, therefore what day, month, or year it is does not matter. All time intervals are in seconds from midnight or milliseconds from now.
Back to the Present
Well, that about does it for this issue. If you have any questions, you can reach me by email, phone or Fax. Please keep in touch -- even if you don't see an immediate need for any OS/32 services.
This SBSW.COM page has been optimized for printing.