OS/32 & Series 3200 SIG #1
by Stuart Baker
At Interchange 94 I was approached by several Executive Committee members relative to taking on the job of OS/32 SIG chair. Since it has been 10 years since I retired from the Executive Committee, I thought it was about time to become directly involved again, so I accepted their invitation. I want to personally thank Jon Brunson for doing an excellent job as OS/32 SIG chair. I don't have all of Jon's MPS experience, but I will do my best to continue his good work.
OS/32 has reliably served users of 3200 based machines for a long time, and I look forward to many more years of useful service. There are still many applications that require the real-time response that can only be delivered by a proprietary system like OS/32. The high MUX and DMA bandwidth of 3200 Series machines allow them to handle a large number of disks and users with ease.
When running in a single processor environment, OS/32 has been rock stable for many years. It has been so long since I saw a system crash, I would probably have to consult the manual to remember how to take a panic dump. The advent of the MPS systems brought with it some rough times, but my understanding is that the R09-02 version of OS/32 (with some of the R09-02.1 fixes applied) is once again a stable environment. I personally know of one user that has been running this combination nonstop for seven months. They are running a Micro 5 with an APU and two IOPs with about 500 terminals and a multitude of SCSI disks.
Before I get too carried away, I probably should introduce myself.
I have known many of you for years, but for those of you who are new to Interchange, let me start with some background. I became an Interchange member in 1971 and was elected to the Executive Committee in 1976. I served on the Executive Committee from 1976 through 1984 and was president from 1980 through 1981. After almost 10 years on the Executive Committee I decided to let others have a chance, and I have not actively sought reelection. However, I have remained active in Interchange, submitting articles for almost every newsletter and attending every annual meeting -- and some of those meetings have been memorable.
In particular, I remember the time at Interchange 90 when our guest speaker, Cliff Stoll, was discovered sleeping under the registration table. Cliff, for those of you who may not have heard of him, is a former OS/32 user who later made headlines when he tracked, via computer, and then nailed an international computer spy. His book, The Cuckoo's Egg, is the first true story about international computer espionage. Apparently, when he arrived the Ritz Carlton had misplaced his registration and they did not have a room for him. I personally think the real reason for the "lost" reservation was that his casual dress code did not meet with their standards. Anyway, Cliff was ready to call it quits and go home. Those of us who saw his presentation are very glad that Ellen MacDonald straightened out his reservation problem and persuaded Cliff to stay. It was the most supercharged, energetic presentation I have ever seen! Cliff was literally climbing the walls. Yes, I mean literally. At one point I saw him when his feet were on the wall, almost head high.
Fond memories aside, my experience with the Concurrent hardware platform dates back to 1970 when I started working on an Interdata Model 4. At that time I was employed at North Island Naval Air Rework Facility in San Diego. I worked at North Island until 1986, doing software development on a Model 4, 7/32, 8/83 and finally a 3254. I formed Stuart Baker Software as a part time business in 1979, supporting the OS/32 community with custom drivers and telecommunications software. In 1986 I left North Island to devote full time to my own company. Since leaving North Island I have continued to develop software for OS/32 systems on an in-house 3212 currently running OS/32 R09-02.
I started writing standalone (no operating system) assembly language programs using paper tape on the Model 4. Since I came from a hardware background, I must admit I also made a few changes to some of the early wire wrap interfaces. These changes were necessitated when the programs I was developing could not perform all of the functions defined in the interface manuals. Since the interface cards were still being produced using wire wrap, modifications were simple to implement and test. Once the changes were checked out, I submitted them to Interdata for implementation in future interfaces.
When the 7/32 was introduced we quickly made the transition, but it was a painful process converting 75,000 lines of 16 bit assembly language to CAL (Common Assembly Language - 16/32 bit). The 7/32 came with revision R00-00 of OS/32 (I believe it was still in BETA test). R00-00 was not a stable operating system -- it crashed several times a day! Fortunately, updates followed quickly and they reduced the crash frequency to about once a week, a welcome change. The R00-00 version of OS/32 was a multitasking operating system, but it did not contain MTM, so it took a lot of work to make it multi-user. The advent of MTM (I don't recall the revision) made life a lot easier for everyone. I have worked with every revision of OS/32 since, and have been a BETA site for many of the OS revisions. The transition from the 7/32 to the 8/32 and later to the 3254 went very smoothly because of Concurrent's commitment to task image portability.
Over the years I have added many features to OS/32 and its utilities. Concurrent has always accepted input from its users and has incorporated many user submitted enhancements into its products. It has been nice working with a company that does not suffer from the NIH (Not Invented Here) syndrome, even though most user contributions simply appear, uncredited, as enhancements in a future revision of OS/32 or its utilities. Because of the anonymous nature of the contributions, most of the time only the author has the warm feeling that his work was appreciated. The one contribution to OS/32 that I did receive recognition for was the BIOC (Built In Operator Control) driver. The BIOC driver was available through the Interchange library and was being used by so many users that Concurrent decided to make it a standard part of OS/32 by popular demand. It became a standard part of OS/32 starting with R06-01.
Enough history, lets get back to the present. I have not received my copy of the last newsletter, so I don't have Jon Brunson's last article to use as a starting point. If you look through the list of processors I have worked with, you will notice that I have not been fortunate enough to have worked with an MPS system. Also, since my system is a 3212, it is not capable of running the next revision of OS/32. That situation puts me in the same boat with many OS/32 users. Concurrent has had an excellent track record when it comes to software portability. I hope that portability continues into the future. For example, my OS/32 products use the same task image to run on every version of OS/32 from R06-02.4 up. Not very many companies can even come close to equaling that degree of portability.
There was a lot of discussion at Interchange 94 about the future of the long term maintenance release (R09-02) of OS/32. As you all know, OS/32 R10-01 will only run on 3280 class (S-bus machines) computers and above. While Concurrent is continuing development of R10-01, many of the enhancements listed for that OS would run fine on non 3280 class machines. At the time of the Interchange presentations there were no plans to make the new features available to users of OS/32 R09-02. Since maintenance contract costs are not changing, owners of pre S-bus machines are feeling short changed. I will stay on top of this topic because it affects a lot of users.
One possible solution is that owners of non S-bus machines should receive the new revisions of OS/32 under their maintenance contract. Even though they will not be able to run the new OS, they could utilize many of the new utilities. Obviously this would require users to be very well informed about which utilities will or will not function on the R09-02 version of the OS. In addition, trying to maintain a complete set of documentation will become a real challenge. It would be much simpler for the users if Concurrent chose to add the applicable updates to a maintenance release of OS/32 R09-02.
If the updates are not added to R09-02, it would help if Concurrent added OS revision level checks to those utilities that will not function with older version of OS/32. This would greatly simplify the process of determining which utilities will work on an older version of OS/32. I doubt if Concurrent will devote much time simplifying the process because it would dilute development efforts aimed at enhancing the performance of their top of the line OS/32 systems. This is a real marketing dilemma: increase old hardware platforms' longevity by adding new features to their OS, or abandon updates to older systems in favor of making the new models look more appealing. I will be supplying more information on this subject in the future.
That about does it for this issue. If you have any questions you can reach me by phone, Fax or the BBS. Please keep in touch.
This SBSW.COM page has been optimized for printing.