SIPGEN - Creating the TPF System
Part I in a series of articles on building a new system from the ground up
by Alan Sadowsky
Almost all of us have had the luxury of working for a company that has already had an operational, production TPF system in place. A much smaller number of us have either worked at a shop, or been directly involved at that shop, in the installation of a new release of TPF. Finally, there are just a handful of us that have gone to work for a company that was installing TPF for the very first time.
The point I'm trying to make is that out of the estimated 6000-7000 TPF technicians in the world, there are probably less than 200 that have ever generated a TPF system from scratch. What this means in real terms can be summed up in two statements. Number one; People with TPF system generation experience are a rare commodity. And number two; What a great topic for an article!
SIPGEN, or SIP stands for System Initialization Process, and is the method utilized to create a TPF system from scratch. All right, that's the second time I've used that expression. So what exactly do I mean? When a customer first purchases a TPF license, IBM delivers a large box of computer tapes to the customer, and an even larger box of TPF technical product documentation. Often times the customer has been observed standing in front of these boxes scratching his or her head as if to say; "Now what?"
Well that's one question we're going to try to answer in this and subsequent articles. SIP is not some mystical ceremony passed down from the Druids of Stonehenge. On the contrary, the Druids originated in White Plains, New York, and have since relocated to Danbury, Connecticut. But seriously folks, the procedures and the methodology behind SIP are practical and fairly simple to utilize. The key to successfully generating a TPF system lies in the knowledge and experience of understanding the nature of the system, the elements which define the physical and logical configuration of the system, and most important of all, what you expect the system to do for you. Define and refine your requirements, and the SIP effort is notably easier.
Before we jump into the basics, there is one other point that has to be made. SIP is not just a one-time thing. Consider it a beginning. Consider it the first step in a learning process that will span the entire life of the TPE system. It is true that there may be times when a new release of TPF, or a SPE (Small Program Enhancement) from the Development Lab in Danbury will require a SIP in order to install the new code. But what I hope to accomplish in these articles, and what I hope the reader grasps, is the incredible opportunity to learn what TPF is really all about.
Borrowing from IBM... "An operational system is a combination of the TPF system, applications programs, and people. People assign purpose to the system, and use the system. The creation of an operational system depends upon three interrelated concepts.
Let's take these concepts one at a time, so everyone has a clear picture of what's taking place.
This first step is without a doubt the most important. It is in this phase that the TPF system programmers actually design the operating system. Gathering the necessary information from the communications and network area, the applications area, and the user community, the systems programmer can begin to define the TPF operating system in preparation for the initialization phase.
So what exactly are we talking about here? Some of the things the systems programmer must know are:
Using these pieces of information as input, the systems programmer can then begin the process of calculating some of the additional information that will determine what is "fed" to the SIPGEN input deck in the next phase. Some of these calculations are:
So what does the systems programmer end up with for all of his/her time and trouble? Actually, quite a bit. In the hardware arena, decisions can now be made regarding the processor type and size, the number and type(s) of DASD that will be required for the system, the number of tape drives required for the system, the number of control units required, the number of processor channels required, and the types of communications devices that will be utilized.
In the Applications arena, the systems programmer now has access to the data record types and formats, and the ability to define the physical and logical file layout of the data base.
In the Systems arena, things such as device utilization, message rate capacity, physical allocation of devices, input and output message types and formats, and communication protocols can be determined.
Now I know that some of this stuff just isn't sinking in too well with some of you, but be patient. If you stick with me for another issue or two, I Promise that the little light will come on, and the true meaning of life will have revealed itself to you. While I don't mean to discount the importance of the design and definition effort, any additional discussion on the matter is best left for a later time when we have a few more concepts under our belts, and a better understanding of the overall picture. Trust me. We will revisit design and definition again, because it is honestly the foundation of your entire TPF system. (It is not unusual for a team of TPF systems programmers to spend six months or more in the design and definition of a new TPF system.)
The initialization process serves to create the TPF systems tables and configuration dependent system software. The process itself is broken up into two separate parts affectionately referred to a STP Stage I and SIP Stage II.
SIP Stage I is basically an Assembler Language program made up of some 35-40 macros. The TPF systems programmer modifies the parameters of each of these macros to specify the desired values for the system being generated. When all of the macros have been updated, the Stage I input deck is assembled.
SIP provides a set of diagnostics to analyze and in some cases correct parameters coded in the Stage I macros. SIP also provides a System Generation Report at the end of the Stage I process. This SIP Report provides the TPF systems programmer with a detailed breakdown, by macro, of the input parameters provided and used during the Stage I process. Additionally, SIP creates the procedures to assemble off-line programs, the control program, and all real-time modules.
The creation of system configuration dependent macros (such as SYSEQC, LINEQ, and SYCON) is also accomplished by SIP. Throw in the creation of the source code for the general file and online keypoints, the source code for the tape label programs, the message router program tables, the PARS list, the JCL and job stream to format the Loader General File and the online modules, the JCL to create the Loader General File itself, and even the Multiple Data Base Facility (MDBF) and Loosely-Coupled support, and you begin to appreciate the power and complexity of SIP.
The not-so-obvious question one might ask at this point is; "So what am I supposed to do with all of this wondrous Stage I output?" Not a problem! The last thing SIP Stage I does is create SIP Stage II. SIP Stage II is the actual system generation job stream in 80-column card image format. It is this Stage II job stream that the user executes to actually create the TPF system.
And that my friends is the proverbial cliffhanger. My next article will pick up with the specifics of the Stage II process, and we'll start to take a good look at some of the SIP macros.