GoTo MVS Home

GoTo Glossary

GoTo Contact


Welcome to MVS Class I - Session 1 - Part 2!

Return to Part 1

ell, so much for the future and RAM. Let's get down to the nitty-gritty. The next VG gives a quick overview of the X5 format by simply showing you a couple of X5 lines. We will get into a much more detailed discussion on X5 in Session 3 of Class I but for starters, think about the problem the designers had when told that they must be able to tell TRP what to do and they only have 72 columns of an 80 column card to do it in. Knowing a little about X5 and how it is used, I'd say that these original designers first came up with a categorization of the input types needed for the program. I haven't said it yet but I will say it now, MVS uses an Event driven process. Everything is done in and around events whether it be I/O or MECO(2). And, of course, there are exceptions to the rule 'cause someone came up with a way to make things happen at non-event times using tables and then it was brought back into the fold by saying that those times were really "internal" events. Cheeee!

Besides events, two other forms of input data were defined, parameters which kept a constant value with respect to time and those that changed with respect to time. Those that are fixed over a given time period were called GENERAL inputs and those that change with respect to time were called (guess what!) TABLES. Tables, of course, would require many input values while GENERAL data inputs would normally consist of a single value for a single parameter. Event information would not necessarily be a single input but it could be defined by fixed number of parameters. The result was three basic input formats:


This resulted in a series of "codes" to be placed on the input line to tell MVS what the line stood for. Also, since general data inputs would normally be small in number of characters, it was decided that each line of input could contain up to three general inputs but the whole 72 characters wouild be needed for event criteria and tables and with the definite need for one or more lines of input. So, you will be learning about CARD CODES (whoops! ... did I say "card"??) and FIELD CODES along with RELATIVE ADDRESSES. This will be covered in more detail in the Class I, Session 3. The example below shows two lines of general input containing three parameters each followed by the beginning of a tabular entry.

Data organization was another inportant feature of the input requirements. Like inputs should be kept together and the Modular design provided just the right organization for these data. Thus, when you see the input data presented by MVS as output, it will be organized first into the three categories, EVENT CRITERIA, GENERAL DATA and TABULAR DATA. Event criteria is presented by criteria value. In the GENERAL DATA and TABULAR DATA sections, all of the data will be organized first by events, then by module and then alphabetically.

MVS has a variety of output capabilities. In problem 1, you will meet the BUCKET and be introduced to the STANDARD BLOCK PRINT, something that is very seldom used in today's implementation(s) of the program. Part of the purpose of Problem ! is to have you meet these forms of output under less than stressful conditionis with a minimum of inputs and output requirements.

At first glance, the user doesn't like the standard block print because it is only values, no variable names. To be honest, second glance doesn't help any. When I first started using MVS, the standard block print was all we had and soon, everyone associated with the program had memorized it. It was OK but often provided more information that we really wanted. During a RUNOFF comparison between MATEC and MVS in the early 1970's, Dick Donald of ESL, a friend (now retired from Signal Science) and the primary author of MATEC pointed out that he had two different forms of output, a short and sweet one with only a few parameters of interest (such as time, latitude, longitude, range, altitude, etc.) and a larger one containing about 10 rows of parameter names and values.

I was devistated because I couldn't produce such a usable form of output. Why, MVS's output looked stupid compared with the svelt and neat form of MATEC. (This scared me a little because, without it being said openly, MATEC was being considered as an MVS replacement because of "ease of use" and I wanted to keep MVS.) While Dick was still visiting FTD, I dug into the MVS documentation and phoned Marty at Aerospace. What could I do to fix this? "Why, Jim," Marty casually rolled off, "Aren't you familier with the special print tables?" Gaaaaa! There it was, right in the documentation. Not only could I reproduce Dick's MATEC output, I could present them both at the same time! ... and in separate print files if I wanted. Never doubt the great one again!

In the next VG, the listing print displayed in the background uses the special print table and this particular example is using the standard 12 line format which I designed (shortly after Dick's departure back to California) for the Milestone Data Base (MSDB). You'll learn more about the MSDBas you get into the use of predefined models. For now it is sufficient to say that when using a program that can do practically anything in the simulation-reconstruction world and that each thing can be done in many different ways, then it behooves one to set standards and practices. That's what the MSDB is all about.

This VG is also here to demonstrate the variety of MVS outputs that are available to the user and in a variety of forms both within the standard output and in special files in both ASCII text and in binary form.

The next VG illustrates some of the more exotic forms of output. No, MVS does not currently prepare nicely formated data plots (although Marty is working on it). The thing to remember here is that MVS in all of it's forms is still just a "batch" program and is not interactive in any way. Any interaction you may have seen in the operation of the program has been in the form of a control shell in which MVS plays the role of the engine. In this type of operation, the control shell (such as the one that Scott Lutz is writing) would interact with the user to build the input data set (still called an input deck by many, even those who have never seen an IBM card!). Then the shell would execute MVS and wait till it finishes. Finally, the shell would interact with any and all of the MVS products to turn them into pretty pictures and help the user restart a new and updated run if desired.

Output varies greatly in appearance depending what you are doing. A simulation will provide time varying values along with event headers and other special outputs. An example of this was seen two VG's ago when I discussed the special print used in the MSDB. One of the things I did not mention is that output can also be controlled through the use of a series of "flags" which can turn output on and off depending upon what the user wants to see and when the user wants to see it. You will learn more about these flags during the input discussions.

Postflight Reconstruction output is also very interesting in that it provides the user with everything but the kitchen sink, everything that an analyst needs to understand his/her weighted least squares run. The next VG illustrates some of this output and lists most of it. Long before the ability to make a quick plot of data and display it on the screen of a monitor and even long before the average analyst had one or two computer monitors on their desk, we had to analyze our output strictly from printed listings. To do this, the MVS designers gave us the printer plot, a use of printer controls that allows the printing of plotting characters at distances along the printed line proportional to the size of the data residuals. This is illustrated in the VG below at the bottom and it is still used by MVS analysts even though some of the shells built around the MVS program now provide real plots of the residuals.

We will cover each of these outputs as they become meaningful to you as a user. For now, suffice it to say that for every part of a weighted least squares solution, the residuals, the covariance matrix, the estimation parameters, for every part there is some MVS output that exploits the informaiton. MVS is one of the best representations of this information that I have seen during my career.

So, what is out there to help the analyst know and understand MVS. Over the years and in the face of adversity (the MVS nay-sayers) we, the supporters and users, have developed a series of publications to help the new user understand and use this tool. During the late 60's when I began to use the program, the most we had for documentation was a handbook of programmer/user notes which were more programmer than user. As we built up the usage of the program, it was selected as the analytic tool of choice for a brand new sensor system. Up to this point, Aerospace had a small contract with FTD for MVS support under which I was the COTR and Marty was the prime doer. Under this contracting mechanism we slowly developed better TRAKM documentation as we added a variety of sensor models and data modeling capabilities to the program.

Under the new sensor program, it was decided that the MVS (along with it's many sub forms at the time such as Baby MVS) would be redeveloped (but not necessarily rewritten), would be done under configuration management principles, and would be renamed the Trajectory Reconstruction Program (TRP) for this project. To this end, Aerospace was contracted by the government to produce a series of products called (in the contractor-ese of those days) Milestones in the true sense of the word, a series of goals to meet. Under the contracting rules, Milestone 1 was the requirements documentation or in more modern terms, the A-Specification. Milestone 2 was the B-Spec, 3 the C-Spec, 4 the Test Plan, 5 and 6 Testing results and finally Milestone 7, the User's manual. Of these, we have lost contact (at least I have) with Milestones 1, 4, 5 and 6 because of their classified nature.

MVS & TRP Documentation

ecause of the informative content of the Milestones 2 and 3, we have in later years combined them into what we now call the Milestone 2/3 report. As a result of this, the current MVS and TRP program documentation provided to a user consists of both the Mileston 2/3 Report and the Milestone 7 Usage Guide. You may have seen the pretty blue covers with the now infamous name of GeoDynamics on the cover (above).

In 1979, Air Force came back to Geodynamics for the development of an MVS and TRP training program. We decided to call it the Certified Analysts Training or CAT because the goal was to provide this training to new analysts who were left in holding areas with nothing to do. It was to be a self-directed course and Air Force also wanted an interactive version. When I took over this development, my first task at Geo, most of the funds had been spent on the development of the interactive presentation program and only four lessons had been started (1, 2, 4 and 6) with only one completed (Lesson 1). Unfortunately, the team of engineers working the project had little knowledge of MVS although they were giving it a good college try. Hence, the construction of the CATIP (CAT Interactive Program) got most of their attention. The approach was to simply write some preliminaries (math, physics & orbital mechanics) and then to tackle the "modularized" program one module at a time.

Since I was a zealous user of the program hot from 10 years of analytic development at FTD, the approach of just talking about the mechanics of each module left me cold. This left me in a quandry. I could not for the life of me move forward from the point where I was handed the project. It just didn't work. So I did what I do on most problems, I piddled (Marty's word!). I drew pictures of missiles. I found odd jobs like becoming an expert in the word processor of the times, RUNOFF. I learned about the Geo computer built by Pr1me Computing (eventually becoming, as a side job, the sys admin.). I worked off site at customer sites where they were using MVS. But, in the concious world, I avoided CAT like the plague. There was a big 8-ball in front of me and I couldn't even see around it. But one thing I have learned over the years ... my piddle time is very productive unconciously.

Suddenly it dawned on me that I needed a better lesson plan. I needed to bound the problem, to introduce the students to MVS and prepare them for their adventure. Since Lesson 1 had already been written, I decided that a Lesson ZER0 was needed (how appropriate considering Aerospace's social and technilogical ZER0 Law of the 60's!). Once the class outline was developed it was a matter of getting the stuff written and I had some pretty good people at Geo to help me. My design was analytical not an index of modules. It leads the student through a progression of learning steps always with the goal of making them analysts not memorizers. My favorite writing in this set of lessons is Lesson 5, Sensor Data where I quote Oscar Kempthorne and get absorbed into the scientific method.

MVS & TRP Analyst Training (MAT)

The result of this effort has stood the test of time but the original people it was written for did not benefit from the update (shown above and renamed MAT) which was published in September of 1983 for another customer. This version has been technically edited and most of the small typos have been fixed. It also ignores the online version (CATIP) and publishes the "exams" from CATIP at the end of each lesson with the answers in the back of the book. If an HTML version of this publication with good graphics were to be made, it should be the MAT version that is used, not CAT.

The Milestone 7 - Usage Guide will be, for most analysts, the MVS Bible and for the serious analyst, should probably be read cover to cover. It is normally provided in a 3 inch 3-ring binder with a pretty blue cover and if your copy does not have the BIG (3/8") holes, that's the first thing you should do because you will be turrning a lot of pages and the bigger holes work best. A better publication would be to use indestructable paper or plastic!

Although the MS-7 is an important document, it does have publication errors in it and it has not been updated for all users for years. If something does not work like the documentation says it should, my approach was to run a series of test to determine what is really happening and then making notes in the MS-7 to that effect. Feedback to Me or Marty is always welcome and anytime there is a question, feel free to feed it back to me through the e-mail system. Current efforts are to put both the Milestone 7 and 2/3 online. Marty has already started that project and most of MS-7 has already been typed into a word processor. Formatting and final editing is still required (to my knowledge). My hope is to publish it in PDF format with interactive index and glossary capabilities. HTML is also a possibility.

The most used sections of the MS-7 are the Mechanics of Input andModule Input/Output Variable Definitions sections. In this course, some reading assignments will be given in these sections.

I'm going to end this session with a simple request. Due to time constraints, I going to ask that you, the student, simply read through the remaining VG's and feel free to send me any questions you might have. I will probably add more words at a later date but to be honest, this lesson has exhausted me and I need to get this online ASAP.

Thanks for reviewing this lesson. Always feel free to contact me about MVS/TRP at my email addresses provided using the Contact link below. If you feel that you or your organization would like to continue in learning about MVS/TRP, arrangements can be made for the formal MVS Ops Center introductory seminar and advanced classes. - JEB 2 September 2001

GoTo MVS Home

GoTo Glossary

GoTo Contact