1985 – SBSS Remote Processing Station

The Supply Connection

After my Training in Minneapolis for the Sperry UNIVAC 1100/60 and my return to Little Rock AFB in 1984, we setup a Remote Processing Station for Base Supply. Meanwhile I had orders for Soesterberg AFB, the Netherlands. I had been promoted to MSgt (E7) and would be the NCOIC / Manager of Computer Operations.

Soesterberg too, had converted to the Remote Processing Station and was up and running. Although the Supply’s Computer Operations Section of the Management and Standardization Branch itself was a bit of a mess and in need of some TLC. As NCOIC / Manager, of Computer Operations for the Standard Base Supply Systems (SBSS), my team quickly rectified the problems and we had a clean running operation.

The main focus to maintain computer availability to the user for on-line processing at 100% was taken a bit out of our hands, since we had no direct control of the mainframe. Still we did have responsibility to insure the integrity of the system. If problems arose due to our negligence, i.e. maintaining the primary and secondary data bases during crossover, we had the added responsibility to recover our system and insure the processing of all post transactions were processed before bringing the data base back online. (see Events below)

__________

The Remote Processing Station (RPS)

The Remote Processing Station (RPS) was the replacement for SBSS’s UNIVAC 1050-II.

The RPS functioned not only as a location for both input and output, and provided processing capability. In accordance with the requirements of the USAF Phase IV program, the SBSS was to be a mirror image of the processing capabilities and functions as we had before with the UNIVAC 1050-II.

The RPS allows Supply Systems personnel to enter data and operating commands to the S1100/60. The RPS consists of the UTS 4020 cluster controller, remote terminals UTS 20W, and the UTS 40 and peripheral devices. Location is within the Chief of Supply (COS) complex, in accordance with the then AFM 67-1, Vol II (Ph IV), Part Four.

The Workstations/Terminals, UTS 40, were located throughout the various branches of Base Supply. They connected and allowed to process their inputs and receive their output in a similar manner as before on the UNIVAC 1050-II, but now these terminals were directly to the S1100/60 and SBSS database. Since the mainframe was capable to accept large blocks of data using the high speed proprietary communications interface, each transmission would cause a single interrupt to the mainframe computer.

The terminals were connected to Terminal Multiplexors (TMUX), which encoded the signals from several devices, allowing the combined information to be sent over one line. The Supply TMUXs were connected to a Modem Nest and TMUX, which connected to the Distribution Communications Processor, the DCP 40, and then to the Sperry 1100/60 CPU. As you can tell the multiplexors prevented the need to have a separate line for each terminal to connect to the mainframe’s CPU .

These UTS 40 (universal terminal systems), used by users within the Supply Complex to input transactions to the Supply Database located on the 1100/60, were referred to as dumb terminals. Right before I retired in 1989, we began to receive Zenith Z-248, personal computers equipped with the proper programing software known as an emulator, which allowed these computers to communicate as terminals with the 1100/60 system.

Gang Concept.

Each Sperry 1100/60 computer data bases were divided into eight ‘gangs. (1-5, 2-6, 3-7, and 4-8). Each gang is like a separate complete data base. In practice, one gang is used for primary processing and another for secondary processing. Therefore, a single Sperry 1100/60 could in theory be set up to support four Standard Base Supply System (SBSS) data bases.

SBSS database used Gang 1 is used for Primary Processing (on line processing), and used Gang 5 for Secondary Processing (off line maintenance and report processing). The other six gangs were used by base agencies other than supply, i.e. Base Personnel Office, Maintenance, Transportation.

Scheduling of Reports and Listings

The purpose of scheduling reports and listings is to match computer use time with operational needs.

The scheduling of the SBSS reports and listings was the responsibility of the Computer Operations Section of the Management and Standardization Branch of Base Supply. Each USAF Base had mandatory and As Required Reports, which needed to be scheduled. The mandatory reports are detailed in the then AFM 67-1, Vol II, Part Four.  ‘R’ reports, As Required Reports, were reports which could be customized through their parameters to output reports specific to the needs of a particular branch or section within Base Supply in support of the Missions of the Base.

Each report had a particular purpose and is prefixed by letter, which described the scheduling processing. The prefixes and there meaning were D for Daily, M for Monthly, Q for Quarterly, S for Semi-annually, A for Annual, and R for As Required Reports. (There were other report using similar prefixes used by Major Commands (MAJCOMs), which had different meanings.)

All Required Reports must be supported by AFM 67-1, and As Required Reports by approved supplement to AFM 67-1, or by As Required Support form, AF Form 2011. Local programs should not be used if a HQ/SSC program can do the job.

Some As Required Reports were programmed by individuals in the SBSS Computer Operations using either Query Language Processor (QLP) or Supply System User Report Generator (SURGE) programming languages.

QLP was a query language and not as robust as SURGE, which was similar to basic programming applications of that time, i.e. Basic, Pascal, C, etc. QLP was easier to use especially for simple retrieval of data, where SURGE was used for more complex reporting. QLP could access both the primary and secondary gangs/data bases. Therefore it could be ran at anytime, and capable of providing up to the minute information. SURGE could only access the secondary, therefore current as the latest Gang 5 Secondary data base. Neither were capable of changing the data base.

Prior to the 1100/60 I used similar programming language we called Utility 008, which was replaced by SURGE. Now we would use either QLP or SURGE programming, when the As Required Report (AF form 2011), requested information is not available through existing AIr Force managed programs. I would review, deciding which language was best, and then assign the request to an individual within our Computer Operations to be completed ASAP.

Program Changes in the form of Release Sheets were sent out once a month, by HQ/SSC, in Gunter AFB, Alabama. These programs release sheets were sent to the Installation Processing Center (IPC), and were accompanied by Amendments to Supply Manual,  AFM 67-1. These program releases were modifications to old programs or entirely new software. The responsibility of the Supply Management and Standardizations Branch for distribution of this documentation and instructions for these program releases to each Branches within Base Supply. At Soesterberg AFB, this responsibility was assigned to me, the NCOIC of Computer Operations.

I would review the Release Sheets for each program that was to be changed, matching it to the Amendments to AFM 67-1, and its Chapter’s procedures that were to be changed. Making note of any changes in processes the branches and/or Computer Operations would need to make, including any QLP or SURGE Programs we had requirements for and running on a regular basis. A meeting was scheduled with all the Branches to review and discuss the impact of all changes. Not only the ones linked to QLP’s and SURGE programs, and also any other As Required Reports, but also to address any changes in their day to day operation of Base Supply.

Before I was NCOIC / Manager of Computer Operations I to performed the duties of Scheduler for Base Level Supply. The first time I performed these duties in an official capacity was at Little Rock AFB, Arkansas. I had a group of Punch Cards all organized by Report type and would match the daily requirements of AFM 67-1 and its Supplements along with the As Required Reports with them. Pulling the appropriate cards, I would verify them against the manual for appropriate parameters and then place them in a tray for the Computer Operator to use during off-line Processing each day. The most crucial times for scheduling and the need for absolute accuracy in scheduling of reports and their parameters , was at End of Month (EOM), End of Quarter (EOQ) and End of Year (EOY). Having just one data base to deal with there was no need for Crossover, just End of Day Processing (EOD). After which the Computer Data Base would be placed back on-line for users to process transactions.

These same Scheduling Requirements crossed over to the new system, which was handled not with punch cards but through Executive Control Level (ECL) Runstreams. The Swing Shift Operator was responsible for running each job as he progressed through the evening schedule after Crossover and Backup of the Gang’s DataBase.

Executive Control Language. This is the main programming language for the Sperry 1100/60 computer. Both QLP and SURGE can be accessed through it. ECL is a job control language that links the Sperry 1100/60 Operating System (OS) with applications programs.

 

Crossover.

Crossover” refers to the information transfer between Gang 1 and Gang 5.

During the duty day, Gang I is used for all on-line inputs.

At the end of the duty day, this information is transferred to Gang 5 with a backup.

Gang 5 then uses this information to produce the mandatory and optional reports for the next day.

Using Gang 5 to generate the reports frees Gang 1 for further on-line processing.

It would not be possible to generate reports while on-line in the same gang, since the information to write the reports would be continually changing. The crossover allows the data to be “frozen’ for report writing.

End of Day EOD) Processing.

EOD Processing starts with crossover and continues with processing of mandatory reports.

The purpose of EOD processing is to produce the audit-able and management listings / reports for the next duty day. Therefore, EOD processing is required each duty day.

Distribution of Reports

The Management and Standardization Branch, Computer Operations Section was responsible for distribution of Supply reports and listings. The distribution of the various reports was in accordance with AFM 67-1, Vol II, Part Two, which contain detailed descriptions of each report. Attached to each individual report’s description is a recommended distribution.

The RPS Evening Operator would insure each Report was printed in the appropriate number of copies using 1-Part, 2-Part, 3-Part, 4-Part, 5-Part and 6-Part Printing paper. He would the load the part-printing paper for each job, into the printer, start, and print the reports in accordance with the scheduled requirements. This unit with in the Computer Operations Section was called the Automated Data Processing Equipment (ADPE)  the distribution was handled by the Reports Distribution Unit within Computer Operations, previously called Punch Card Accounting Machine (PCAM).

At Soesterberg and also at my other bases some form of wall was built with cubby holes open on the Distribution side and with a clear plexiglas door on the other side for users to pick up their reports once they had been decollated, and the copy/part of the report had been placed in the appropriate cubby hole(s). Usually the number one or fist copy of a report would be distributed to the appropriate branch, section or unit by priority of need to know, as specified out by the then AFM 67-1 or specified by the AF form 2011.

Note: I was first a Computer Operator for the UNIVAC 1050-II mainframe, working various all shifts day, swing and graveyard shifts as required and on various different schedules, before I was a Scheduler, ADPE Supervisor, ADPE/PCAM Supervisor and Supervisor of Computer Operations. Ha, Logical progression huh?

__________

DOWNTIME AND POST-POST

The computer can go down (fail to operate) for physical or logical reasons. Physical downtime can be caused by power failure or damage, while logical downtime can be caused by crossover operation or overloaded use. Although nothing is wrong with the machine under logical downtime, the machine is still unusable to the users and system operators. Depending on the time involved Post-Post procedures may need to be activated.

During my time as Manager of Computer Operations we had no automated Post-Post, using a microcomputer method to replace manual Post-Post. We just had Manual Post-Post. Initially I was responsible to report the Downtime and the extend that it would or would not affect the functioning of Supply Operations to the Management and Procedures Officer and Chief of Supply usually in that order.

They both had their responsibilities to report to the LG Commander and to the rest of the Branches through out the Supply Complex, accordingly.

If it looked like we would be back online in a short amount of time, and the integrity of the Data Base was not at risk, it would be unnecessary to implement Post-Post Procedures. Other wise we would.

Although Post-Post was serious business, it was not the Branch Chiefs nor the Chief of Supply that were truly involved. It was specific individuals assigned by each Branch that did the work and under my supervision as to which transactions to process first.

Regardless if the mainframe was down or not, I would wait for it if need be and the RPS to be back online, before beginning reconciliation of the data base and the beginning of Post-Post Recovery. Either way, I would check with Base Level Computer Operations, who are responsible for the Sperry UNIVAC 1100/60, to get the exact time to the second the system went down, and the log tape which was active at the time. Therefore I would be able to recover if needed by going back to my last Integrated Recover Utility (IRU) dump. Using the last IRU, usually from the last crossover and then work my way forward through the audit trail tapes to get back to the second we stopped if needed and Post-Post began.

Post-Post Transactions were kept manually and in a very specific order, sometimes in groups. Stepping through the transactions as we went. Once completed we would run our Failsafe, Utility 027 program for record, take a dump and instructing BLAS to initialize the Workstations to bring the SBSS database back online.

Note : microcomputer method to replace manual post-post

Thought I would mention here that Supply did may not have what is being used for the current microcomputer to perform an automated recovery. Right before I retired in 1989, we received a Zenith Z-248, personal computers equipped not only with a UTS 40 emulator, which allowed these computers to communicate with the system, but with enough hardware and hard drive space to put the whole SBSS Data Base on it. We were able to run it, inputting transactions and processing the whole of Supply through this one PC, and did. Testing it under Base Level Exercise Conditions with all the inspectors throwing all they could at us under existing exercise and contingency plans. It worked well. I also reported our finding and experience to USAF Headquarters Europe. Maybe we were the forefathers of todays possibilities.

__________

Other Stuff of Interest

Pseudo-Reader. This is a software feature that can simulate an input device. For Supply, the input device simulated is a card reader. The old method for inputting data into the Sperry 1100/60 used punch cards. Under the new method, the pseudo-reader acts like a punch card reader, but allows the operator to enter the data in a flat file rather than on punch cards.

NO CARDS !!! By using the pseudo-Reader the way thanks to Procedures and Standardization and our Computer Operations Sections, we were the first in USAFE to completely do away with punch cards.

LOGMARS. – Logistics Marking and Reading Symbol (LOGMARS) refers to a bar code system used to identify items and their locations located in the warehouses, maintenance bench stock, base service store locations and the items themselves. This system is similar to the Universal Products Code (UPC) symbols found at supermarkets and commercial stores.

The first time encountered the LOGMARS bar code system was at Soesterberg. The Inventory Section and Warehouse units were having problems with the Bar Code Readers. These were really large units with Batteries equally as large. The problem was with them not being able to hold a charge. We found out and reported to USAFE Headquarters that the batteries had to be full used up and then recharged. If not then the battery would only recharge the amount which had been used and not the full battery. If I remember correctly they finally replaced all the batteries with ones which would insure a fully charged battery.

__________

Hope all who read this find it interesting and those who also were in my shoes find that it brings back memories.

Best

Mike

 

__________

References

http://www.dtic.mil/dtic/tr/fulltext/u2/a215165.pdf

__________

The Poppadillo Blog, is the blog page for the Texas Tortilla Factory website, and its stories have been written by Mike Vauthier, and Administratively Approved Authors.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

__________