Virtual Report Processing
The Mapper Story
By: Louis Schlueter
The Genesis of Report Processing
The environment that led to the invention of the concepts and the creation of Report Processing software was created in spite of and in opposition to the official policies of the parent corporation, Univac. The year was 1968. This environment and my preceding experience with hardware and software created a mindset that enabled the eventual concept inventions.
At that time, the computer industry had recently started using significant numbers of transistors to make computers instead of vacuum tubes. COBOL was still a relatively new computer programming language. The need for centralized information management departments for the control of computerized corporate information was just becoming recognized. The Data Processing departments were being formed. There were no Personal Computers. Even the use of display terminals was quite rare. Most programming of computers was done with punched cards. Most output was in the form of print listings. Computer operation was controlled with printer consoles.
I had been with Univac (then, Remington Rand Univac) for about 12 years. I joined the company as a test technician working on Univac File Computers. This was a short lived family of midsize computing power processors with less processing speed and memory than one of today's cheapest PC's even though it was the size of a small car. It was programmed with punched cards and plug boards and provided printed business information listings. They were state-of-the-art systems.I worked on these File Computers in the final test department as a hardware technician. This involved putting the computers through exercising programs to determine correct logical processing and to weed out marginal components and wiring errors. When failures occurred, logic patterns were traced on the printed circuit boards using oscilloscope displays to determine failing components such as transistors, capacitors, resistors or miswired paths. Failure causes were corrected and testing was continued. In this capacity, I did no programming. I only used diagnostic programs that were provided for that purpose.
As a technician I also worked on a variety of peripheral systems such as magnetic storage drums and magnetic tape collating systems. The tape systems consisted of four tape drives and a controller which were used to sort and organize data collected on magnetic tape reels. The controller would route the data as designated by a plugboard program to each of the four tape drives and then would route the data from one drive to another until the desired data collation or sort was achieved. With the advent of larger memory and storage systems the need for these collating systems soon disappeared.
I also worked on a number of different storage drum systems. This drum technology finally culminated in a system call the Univac Fastrand. This consisted of two large silver-coated magnetic drums that were 6 feet in length and 3 feet in diameter. These drums were mounted one above the other in a single 12 x 5 foot cabinet. A positioning bar with heads on both sides was mounted between the drums and driven by a large digitally controlled armature at one end. This system could store the then phenomenal amount of 100's of Megabytes of data. Today hard drives that can fit in your hand and are mounted in PC's can hold more data than the Fastrand drum system did.
This storage unit resembled a large, silver-coated clothes mangle. It was critical that the drums were wired to rotate in proper directions. To get this right it was recommended that you feed your tie in between the drums. If it would not catch and be pulled in, the drum rotation directions were correct. A bit of tech humor that effectively got the message of proper rotation wiring across.
I was promoted to System Engineer and headed the group of technicians who performed final test on these Fastrand systems. These first 12 years of my Univac computer experience were strictly hardware oriented.
I believe this hardware experience was extremely important because the processing power and memory capacities of these early systems were very limited. This created a design and use focus that aimed at application efficiency in terms of memory, storage management and data access. As we will see later, most of the key members of Report Processing system design team had similar hardware experience prior to becoming programmers. Therefore, system software design for hardware efficiency was always a key design concern.
Today's Year 2000 (Y2K) problem, which is an enormous international concern, was instigated by concern for the limited storage capacities of these early systems data storage systems. So concerned were application designers with saving storage space, that they routinely used only two digits to express year dates instead of four digits (99 i.e. 1999). The problem then occurs when the year 2000 arrives and all applications expressing year dates with only two digits will see 00 as the date. Obviously, any computations on year dates with two digits will be erroneous. The logic and date related data of all such applications will have to be corrected before the turn of the century to avoid processing faults, clearly a major challenge considering the millions of systems and programs using date related information.
In 1966, I examined my computer experience to date and concluded a transition to programming was in order. I had become somewhat bored by the process of the analysis of computer hardware logic and related trouble shooting. I had seen enough logic designs and traced their paths on oscilloscope displays enough to feel that in order to fully understand computing technology, I needed to learn to be a programmer.I also could see a trend to circuitry reduction due to rapidly improving computer chip technology. More and more logic was being incorporated in each new generation of chips and increasing numbers of chips were being included on circuit boards. These trends clearly would change the role of most technicians ultimately ultimately removing the need for logic analysis in favor of swapping boards or chips to resolve hardware problems.
I always recognized the value of my hardware experience because once I also had attained an understanding of programming I could effectively evaluate a system problem and understand both the hardware and software elements of it. It was also helpful in that I could more effectively know when a programmer was incorrectly blaming hardware for a problem and conversely when a hardware technician was erroneously pointing to the program as the cause of trouble.
So, in 1966, I transferred to the Diagnostic Program Development Group, which was part of the System Test Department. This group was responsible for designing the test and diagnostic programming used to test the hardware and systems in final test. These programs generated the shifting data patterns and procedures that exercised the equipment. They evaluated all possible logic conditions and performance efficiencies. The exercises set up complex computing examples using shifting, random data patterns and access speed measurements. These programs were run for hours effectively "burning in" the hardware components and proving logic accuracy, performance and reliability.
Needless to say, these diagnostic programs had to be very efficient in their design. To that end, they were written in Assembler language which is the next level above machine code, binary ones and zeros. Assembler languages are also used to write operating systems software and peripheral driver programs.
Computer programming languages are classified in terms of generations. The first generation being machine code, the binary ones and zeros actually processed in the arithmetic registers, storage systems and peripherals. Assembler languages are 2nd generation languages which are processed with assembler programs that generate computer executable machine code.
Assembler language requires very detailed code statements, essentially one for each processing and logic step. These highly detailed instructions enable very efficient control of system hardware and thus assembler programs are ideal for writing system control or diagnostic programs.
In 1968 the 3rd generation COBOL language was becoming well known and was being used for general business application development. Individual COBOL code statements could generate the equivalent of hundreds of assembler instructions. This made the programming much easier and more efficient for general application design. COBOL programs were compiled to create the executable elements of related machine code. Other examples of 3rd generation language that were emerging were the "C" and PASCAL languages.
I learned how to write code in the Assembler language and how to assemble such code into executable programs. In those days, this code was put on punched cards, which were read into computer files for submission to the assembly process. Input display terminals were not available yet. I also learned the procedures for installing programs and performing debug processes for eliminating coding errors. I spent about a year in this learning process and in writing diagnostic programs for a tape system that used punched paper tape as a means of data input.
Chapter 16
Implementing Report Processing Applications
Report Processing has enormous productivity potential and can provide real competitive advantages in improving operations when implemented in the most effective way. The users must be trusted to get the best results when they are allowed full creative expression and flexibility in using Report Processing capabilities. The control mechanisms exist to creat an illusion of infinite capability for users and yet retain needed system and security protections. To understand the nature of ideally implemented Report Processing services, let us examine their characteristics.
The most common type of application for which a Report Processing system is used is an application that can be described as unstructured. This application is processed with general-purpose Report Processing functions such as Search, Sort, Match, and Calculate. Such an application allows access to the original report data base for direct updating on the screen or by using Match and Search Update functions. The only disciplines involved in such an unstructured application are those that ensure form integrity for the data as well as a character-type (alpha, numeric) edit on input. No validation of input data such as checking for legitimate dates or item numbers is done in such unstructured applications. Base cleanliness is ensured by the fact that users live in the base on a day-to-day, minute-to-minute basis. They use the base in real control of their immediate operations. By utilitarian necessity, the base must reflect reality; therefore, it is kept correct through constant use and immediate correction and a persistent managerial insistence on accuracy.A further characteristic of the unstructured reporting application is that the up-to-date report "data" is turned into information as transient demand occurs by the execution of the general-purpose Report Processing functions such as Search, Sort, and Compute. In other words, as questions of operational control develop, they are answered by the execution of the appropriate Report Processing function or series of functions executed "on the fly." This is of course the only way that real, detailed, ground-floor control of operations can be obtained. This is a highly unstructured operational environment, and therefore, the only comptuer processing that can serve it is one that can be used in an unstructured manner. This is Free Enterprise computing of the highest order and utmost importance. It holds the greatest potential for broad-scale operational impact and productivity improvement.
Some of the unstructured reporting applications will have report generating (RUN) functions developed for use with them. This is frequently done where a repeating pattern of manually executed functional use occurs. Usually this is a pattern of data analysis. In such a case, the pattern of functional use is defined in the shorthand language of run language (RUN) design as a procedural list in a report data set. The report is then registered with a prescribed name. The call of this name can then cause the list of functions to be executed in the prescribed manner. However, most of the reporting applications will not use RUNs but will be processed by the execution of manually executed functions.
To gain an appreciation of what constitutes an unstructured report processing application, an examination of the typical life cycle of such an application would be instructive. It all begins as a gleam in the eye of someone in the operations area. Someone in the end-user environment becomes aware of Report Processing techniques and recognizes that his or her manual information processing would be greatly improved by using a computerized Report Processing system as an alternate method. Once such a service is generally in use in the area, such opportunities usually occur spontaneously and are primarily the result of word-of-mouth recommendation and pride of-ownership demonstration within the user community. Typically, this is the best form of propogation of Report Processing services. Need seeks invention, and a natural attraction to Report Processing usually generates the healthiest applications. A valuable stimulus to this environment is an abundant opportunity to see and learn about generalized Report Processing capabilities with the tutorial aids of the system. However, the end determination of need and appropriate design is left in the user's domain.
A user-supportive, Report Processing system-Coordination function can be of great benefit in seeing that Report Processing services are offered in the potentially most fertile areas of the operation. This is best done by a Coordinator with real operating environment experience. This proper exposure ensures the earliest productivity improvement in the most labor-and material-intensive areas, thus ensuring the earliest payoffs and most effective priorities of implementation.
Once the user has identified a potential concept of Report Processing, it is brought to the attention of the reporting system Coordinator. The Coordinator provides a sounding board for analyzing these embryonic concepts and is in a position to initially ensure that: The idea warrants real-time Report Processing services.
The information is not already existing in other bases. There are substantial benefits (savings) to be had from real-time processing of this information. The data-base organization plan is sound. All user-community concerns are taken into account. The system impacts are considered. The user is aware of proper rules of design and system use. Adequate security considerations and controls are applied.
If the proposed application seems generally well conceived, based on these initial evaluations, a user design and detailed plan definition is implemented. To accomplish this, a loosely edited, experimental, "free-form" report with blank field headers is made available for the user to design the layout or form of the reporting. A "Form-Design Guide" aids the user in entering form, edit, and header definitions.
The user-designer should enter the required form and edit definitions along with examples of representative data into the experimental report using CRT display input. It is imperative that this design work be done on the display. It is not accepted if submitted on paper. Only by seeing and using the proposed information in its final supporting media can an effective design be made. Data rolled, shifted, updated, and positioned on a CRT display has a greatly different feel and perspective than it has written or printed on paper. It is also recommended that the data be printed and examined in the form of a computer printout. Again, the appearance of the data in printed form can influence the design perspective.
The user-designer should discuss the application design with all who will be involved in its use. These users will often indicate other considerations, needed data elements, and use requirements and dimensions that make the design more complete. A key factor in the design work is that it must be done by the user community that is directly involved. It should not be done for them. Only users have the intimate operational knowledge needed to convert this knowledge to an effective design. Nonuser planners will dilute design effectiveness.
Not only do attempts to communicate such knowledge to other system designers or programmers confuse the process, they make it much more time consuming and expensive. The design process can easily be understood and is best done by members of the user community. The requirement bugs, so prevalent in conventional systems, are greatly reduced with the user design approach.
While the design process is in progress, a detailed plan for the proposed application is developed. This process is aided by the use of an "Application Definition Request" form. Elements of the application plan that must be defined are: Title and description of the application. A definition of the alternative method to Report Processing. Estimates of alternate system costs (this provides a basis for assessing potential savings in the proposed application). Estimates of historical-data requirements. Estimates of`update frequency and Report Processing use (this aids in assessing system impacts). Estimates of display-terminal/PC and special dial-up requirements. Definitions of any special security considerations. Estimates of the size of the proposed data in terms of lines of data and quantity of reports.
In determining the size of the proposed base, a key consideration is the flow of data into and out of the base. New items will be entered into the base, and they will be tracked there during processing. As they become closed transactions, they must be removed from the base and treated as historical information. Thus the true size of the base is that represented in the average number of items on-line that represent new items, items in process, and recently closed items. It is basic to the plan and essential to the health of the application that a flow of information into and out of the base be maintained. The life of any viable control-information system requires a flow of new transactions in and a removal of inactive (historical) data or the application will be saturated with old data and become inoperable. This is especially true in the case of real-time information processing. Only a base clean of deadwood will remain responsive and effective. Active data should not have to be processed with historical data. Once information becomes historical data, it must be separated from the active information.
Historical data can be usually quickly removed by use of a Search Update process, pulling the items on the basis of a closed-transaction code or perhaps on the basis of date reference and then, after copying them to a suitable record medium, deleting them. Usually printouts of such items are adequate. Other methods that can be used are cassette tape, magnetic tape, or diskette storage. If the historical data must be accessed frequently and the on-line storage space can be justified, the closed items can be searched out and moved to a type of reporting set up for historical reference purposes. The most common method is to allow the data to recede into the tape history that is automatically produced by the Report Processing system on a daily basis.
The plan definition is made by the users initially and finalized in a coordination review. This will ensure that proper historical, base size, and flow considerations are included. It will ensure that the concept is soundly conceived and that system resource and safety considerations are observed.
When the form definition on the experimental report is completed and has been reviewed by all the potential users, it is submitted to the system Coordinator for final approval and review. At this time, checks to ensure that form standards defined in the Form Design guide were observed in the form design. Standards such as date format, item definition, and coding systems standards are enforced. If all is in agreement, then production turn-on can proceed.
Form generation is the process that accomplishes what must typically be done by the programmer in the conventional program application. The process is simple, requiring only minutes to accomplish. It involves submitting the headers from the layout in the experimental report made by the user application designer as input to the Form Generation process. Edit choices and presentation formats are also entered. Once completed, the form of the reporting has been automatically locked in and will be protected during all input and Report Processing. The data-base definitions have been established, and all subsequent use will be backed up with recovery and history protection automatically.
This Form Generation process accomplishes in minutes what takes conventional structured programmers many months to accomplish. What has been accomplished is the turn-on of a real-time reporting application that will have fast response time and will be updated in real-time and will be randomly and concurrently accessed and processed. Such application programming is of the most sophisticated sort. This is not a simple batch-processed COBOL application.
The implications of this ability to implement true, real-time, transaction-oriented applications are far reaching and important. An enormous new dimension of computer service is opened, for only with such quick, simple application turn-on can the myriad real-control applications in all operations be computerized. The savings over conventional real-time programming methodologies are potentially enormous. Also, ease of implementation means ease of application modification. This is essential to meet the ever present forces of change engendered by new policies, needs, and expanded experience and visibilities provided by the new computer-processing capabilities. An evolutionary concept of real-time application development is supportable. The ability to implement applications quickly, learn from the implementation, and quickly enhance the application is possible.
Specifying in report processing application design is a much different process than is used in conventional programming methods. When the language used to create the computer application is so simple that the user can be the architect of his or her own systems, the requirements of translation are essentially nonexistent Therefore, the roles of system analyst, planner, and programmer are also unnecessary. If documentation is required at all, it is usually only required after design for procedural documenting purposes, the primary purpose of such documents being to provide data form and coding definitions and to ensure consistency and continuity in use during personnel transitionsThe simple specification requirements are attributable to the nature of Report Processing. In the application-design phase, the concept of the end requirement exists in the mind of the user-designer and evolves during design and use. Organization of the information within the simply conceived, report-structured database is a simple user process. The functional language of Report Processing is used in a design procedure that is essentially evolutionary. The user-architect does not have to predefine every question to be asked. As the questions occur, he or she selects from the repertoire of Report Processing functions the tools needed to derive the answer to the question at hand. By executing these functions in real-time to accomplish the task, he or she is actually programming the computer on the fly or in what is described as an "interactive mode" of operation.
When the language of processing is so simple that the end-user can directly make the computer perform his or her tasks, should this even be called "computer programming"? Or is it simply "using the computer"? The computer is, after all, a machine. It is just a powerful tool. When users can influence it directly, making it perform tasks under their immediate direction, is this not simply using computers? When they can define the logic paths immediately and evaluate each step as it is accomplished, making decisions based on results produced and choosing new paths of logic, causing the computer to follow the paths seen, is this not simply using computers? Why give it a scientific, professional mystique and call it `'programming"?
This question does have certain social significance. For instance, in operations where programmers are unionized, it is important to define what constitutes "programming" and what is simply "computer use". Where the language lines are drawn will have impact on existing or potential power structures. Must an end-user join a union simply because he or she is using a system in which every question to be posed, the logic of the solution, and form of presentation of the answer is not predefined and prestructured? Must he or she be in a union because he or she selects appropriate functions from a list and executes them to solve the informational requirements? If so, then users of hand calculators should also be considered "programmers."
The process of interactive problem solving is not a rigidly structured procedure. The minute-to-minute processing of real-control information is also not structured. It requires spontaneously devised logic derived on the basis of influences of the moment. Such procedures cannot be predefined. Preparation of specifications in advance of such problem solution is not only nonproductive but unnecessarily limiting. Once the functions of computer command are so simple and natural that they can be defined and executed by the end-user, the pseudoscientific aura that requires professional interpretation is gone. So goes the Programmer, the Systems Analyst, the Systems Planner, and so goes the Specification Specialist relative to Report Processing applications.
The evolution of a user into a MAPPER RUN Designer is much different than the typical development of a conventional programmer. A remarkable phenomenon among the users who have developed their functional expertise sufficiently to become Report Processing RUN designers is their strong insistence that they do not consider RUN design to be programming. They are very clearly opposed to the idea that when they design RUNs, they are acting as programmers. The reaction is remarkably consistent among users. It is evident among those who are not familiar with data processing at all as well as among those users who have had training in data processing and even some with programming experience in COBOL, Fortran, or BASIC languages.
They see their primary contribution to the solution of a problem as their operational expertise and their intimate knowledge of the input parameters of the problem to be solved. To them, the language of Reporting Processing seems to be "the way computers are supposed to be used." Once the language seems natural to use, the professional mystique of programming evaporates. All that remains is getting the job done and using the computer as just another tool for analyzing, computing, and information gathering.
It is worth noting that all Report Processing system users will not become RUN designers. It is a technique that appeals to the user who is motivated to obtain full benefit from Report Processing capabilities. Often a fascination develops to learn and use Report Processing techniques to the fullest. If this motivated user is also gifted with a degree of innovative talent and a somewhat logical mind, the person then possesses the potential for becoming a capable RUN designer, a Power User. Such motivation and talent does not appear in all users, but it is sufficiently abundant in the end-user community. Some users are smart enough to be motivated and challenged by fascinating logic. Some can also be ingeniously innovative. These characteristics are not restricted to the mind with a computer-science degree. One of the most exciting aspects of watching proper, user-oriented, free enterprise Report Processing implementation in a user-community is to see the multifaceted ingenuity and innovative adaption of computing power. This is especially noteworthy among the users who develop into RUN designers and become Power Users..
At first appearance, a control statement made in the RUN function language would appear to be somewhat heiroglyphic, even programmer like. However, it must be remembered that the user will be introduced to RUN design language training only after he or she has evolved to what can be called a "sophisticated user" of manually executed Report Processing functions.
Such a user will have been through the basic manual function training process. With a display, he or she will have interactively processed a demonstration database that was designed to illustrate most of the more popular general report processing capabilities. He or she will have used all the manually executable Report Processing functions available to general users. Besides learning what these functions can do, he or she will have been given an appreciation of the nature of the report-oriented database. He or she will also have been exposed to the options usable with the various functions and will have an appreciation of what information-processing powers can be derived from their use.
With this general functional training accomplished, the user becomes a production user, processing live data in a real production environment. Here he or she learns the realities of functional Report Prosessing. By actually adapting Report Processing functions to the solution of real-world production problems, he or she gains an intimate knowledge of capabilities of the functions he or she chooses and executes. By trial and sometimes by error, he or she learns what Report Processing functions and their options will do in production problem solving. Since these functions are the "instructions" of the RUN language, the user possesses an invaluable insight that ideally serves him or her in accomplishing effective RUN design.
The user is aided and reinforced in this learning process by the availability of self-grading, on-line examinations that are designed to identify any weaknesses he or she may have in his or her basic Report Processing training. He or she also has access to documented display-operating procedures that can be selectively referred to on-line as required. With the self-teaching tutorial aids, reinforcing exams and procedural references, a self-fulfilling learning environment is created in which each user can rise to a proficiency level according to his or her need, talent, and relative motivation. From this catalytic world of production users, those Power Users with RUN designer potential identify themselves.
If one looks at the language of RUN design from the normal perspective of a "sophisticated user" who knows his or her accessible data bases, the nature of the general Report Processing functions, their characteristics, strengths, and options, and the realities of general-purpose, realtime, Report Processing production, then the transition to an understanding of the RUN design language is not a mysterious step to heiroglyphic symantics. Instead, it seems to be a natural next step to more functional power and to a shorthand way of prescribing the same functions that are already so familiar. The RUN language is designed to support this transitional attitude.
The flow of the manually executed function is the same as the pattern of definition for the RUN control statement. Because of this similarity of pattern, it is easy to see how the user can easily learn this language, for it is indeed merely a shorthand way of prescribing the report processing functions they are so familiar with.
So it becomes more and more difficult to say what constitutes functional uses of computers and where true programming begins. One can understand how it is difficult and even incorrect for a user RUN designer to claim to be a programmer. It is possible to understand the users' insistence that they are not programmers when using the report generation design language. They do not consider themselves to be programmers when they manually cause the functions to be executed. So why should simply setting the same function up in a different way for execution cause them to suddenly be classified as programmer? Probably the most important reason to not call them programmers is that their real career is that associated with their work in the operation. They are simply users of computer power with new skills used in conjunction with their main profession.
The more advanced systems that support user designed computing, such as the Unisys MAPPER system, provide extremely powerful application development environments for end-users. Automatic code and screen generators are provided that make extensive, sophisticated, real-time, transactional RUN application development possible.
These systems also support Power Users in integrating their experience and data in applications such as Word Processor, Excell or Access with the Report Processing information power tools and reporting database. The user oriented PC applications gave users a sense of the power inherent in direct control of computing capabilities. These can be considered the first generation of User Designed Computing. Report Processing systems integrated with industry PC applications now provide the Next Generation for Power Users which offer enormous new potentials for productivity and operational efficiencies.
Coordination of RUN design and use is also done differently than in conventional application development.
A Report Processing system coordination that is too heavily influenced by a restrictive data-processing organization tends to reduce the potential effectiveness of a Report Processing service in a number of ways. RUN design and use is an area in which a restrictive data-processing management usually establishes the tightest restrictions and thereby does the greatest damage to the potential benefits of a Report Processing service. Much of data-processing management has great difficulty with the idea of letting users be RUN designers. Their initial reaction is that RUN design should be restricted to professional programmers. Of course, this does not mean that only programmers get into the application design act. The whole DP-approval cycle, analysis bureaucracy, planners, system analysts, and documenting specialists are also brought into the design process.
Often there is a great deal of empire protection behind this restrictive attitude toward RUN design. But frequently too there is simply a failure to understand that the RUN language is merely a form of shorthand for controlling the use of the Report Processing system's manually executable functions. The majority of user RUN designers do write RUN applications that are essentially functional sequences. Granted, there is much more than functional sequencing capability in RUN design, but most users accomplish most of their design with functional sequences. These are easily controlled and managed to assure effective use. The more talented, ingenious user RUN designers will use the full potential of the more intricate RUN design techniques. But there again, it is their innate talent that makes this design work that is well done. It is these user-designers who produce the most productive, exciting applications of RUN use. Due to the coordination controls available for the RUN design process, the design process is system safe and productive whether the users are superstar innovative talents or simply knowledgeable Report Processing system users.
A strange phenomenon in the real world of RUN design is the fact that professional programmers usually make poor RUN designers. At first, this seems remarkable when one considers the proven, trained, professional data-processing mind. It is difficult to define precisely why programmers generally do poor RUN design work. Probably, the lack of Report Processing user orientation and experience in the programmer is the key factor. The typical user-turned-RUN-designer, Power User, is a highly experienced user of the manually executable report processing functions. He or she knows what these functions do, their options, and real potentials. What is of utmost importance is the fact that he or she knows what they can do from actual use on his or her own report data. This implies not only operational experience with the RUN instruction repertoire (the Report Processing functions themselves) but also intimate database Report Processing experience. He or she knows how the functions perform in use with his or her own live database. He or she also enjoys the great advantage of knowing what the problem is that needs to be solved. He or she will solve only that problem neither doing more or less than is necessary.
Since the programmer usually is not a general-purpose, production user of the Report Processing system, he or she neither has the operational knowledge of functional use nor is he or she intimately database knowledgeable. The professional programmer's data-processing expertise is often more of a disadvantage than an advantage. In learning new concepts, people naturally try to relate newly encountered ideas to what they have previously experienced. In the case of the data-processing professional, he or she often tries to handle the report data base as he or she has always handled the file-record structured bases, namely, one record at a time. The Report Processing system's functions are designed to handle a set of records (an entire report) at one time. Report Processing as a concept is often a problem for the data-processing professional to grasp due to his or her file and record processing experience.
If the programmer's background is in COBOL batch processing, he or she typically tries to use the real-time, transaction-oriented Report Processing capabilities as a batch-processing language. Having little or no experience with transactional processing information in real-time, he or she designs report generators that process hundreds of thousands or even millions of records as one transaction. Such batch-oriented design is actually dangerously detrimental to the performance of the real-time report processing service.
The data-processing professional is used to processing files, not reports. Files tend to be big. Reports tend to be small, usually less than 500 lines in length. So a frequent error the data processing RUN designer makes is to put all the data into one report. This then is usually too large for suitable Report Processing. In real-time Report Processing, only one update is allowed in a report at one time. So by putting all the data in one report, simultaneous updating accessibility by many users is prohibited. In the report database, each report is an entry point for access. By breaking the base naturally into many small reports, the user not only creates the ability to support multiple, simultaneous updates, he or she has a base that is accessible at many points (the many reports individually). The data-processing designer, by lumping the data all into one report, limits updating, accessibility, and processing.
The data-processing designer is also by experience, a record, not a report, processor. To him or her, reports are the output from program executions, usually print listings, so when he or she faces a concept that processes reports, it is difficult to grasp. The user, however, clearly sees that his or her report is the final product of information and he or she clearly processes it, updates it, searches it, sorts it, and so on. The DP professional does his or her best to gain an understanding of Report Processing by using the tutorial cook books and demonstration data bases, but this is no substitute for the real-world user experience of production, real-time processing in the user-designed data base.
So the data-processing designer goes through the relatively sterile demonstration database learning process and assimilates enough of the basics to qualify for RUN design school. He or she learns by rote the shorthand language for writing RUN control statements. He or she is not really comfortable with Search, Sort, or Compute statements because he or she was not comfortable with the use of these functions in the demonstration, tutorial base environment. Nevertheless, he or she goes down through the RUN instruction (or function) list until encountering the Read Line, Write Line and IF logic capabilities. This he or she recognizes. His or her wealth of data-processing experience now comes to bear. He or she is home again and has found "read a record" (Read Line), "write a record" (Write Line), and with the logical IF, he or she proceeds to design RUNs that are horribly inefficient. He or she constructs the logic of Report Processing functions such as Search, Match, and Compute using Read Line, Write Line, and IF logic and ignores as much as possible the less familiar but efficient and powerful functions already available and assembled in machine executable code.
On the other hand, the non-data-processing-oriented Report Processing system Power User turned RUN designer reverts to his or her base of experience and favors Report Processing functions in design choices. The choices are good because he or she intimately knows their power in execution of his or her own data. The use of Read Line and Write Line occurs only when he or she cannot do the job with standard Report Processing functions. Since the report processing system is internally ideally geared to the execution of Report Processing functions, these runs are simple in design and efficient in use.
In either case, be the RUN designer a programming professional, a talented user, or simply a user who has done his or her homework and is now doing RUN design, the tools are available for complete, system-safe control of the design process and production use of the RUNs.
The process of control begins with user qualification to be a RUN designer. RUN design is a unique functional capability that can be turned on or off for a given user. So, once a candidate for RUN design has learned the characteristics of basic Report Processing functions, their options and all the related powers they possess, they must prove this expertise by passing online proficiency exams with very high grades. Given this basic proof of general, functional knowledge, the potential RUN designer then usually attends a RUN design class that includes workshop solutions of example problems. With this schooling completed, the functional capability of RUN design is registered by the system Coordinator for this user. The short hand statements that define and control the functions to be executed in a given RUN are called control statements. They are entered as report data in a report data set. The report, which then describes the control statements or procedure to be executed, is registered and given a name that can be called to execute the report generation.
When the RUN control report is registered, a number of control characteristics are defined: A RUN name is registered. This is the name that is entered to cause the RUN to execute. The RUN can be optionally set to run at only a given display station or selected stations. The RUN can also be optionally set to run by only a signed-on individual or individuals. The RUN limitations relative to database security are set. A fixed storage-access limit is set. This is an allowed quantity of read and write accesses (I/Os) to storage. A logic line limit is set. This is allowed quantity of control-statement lines that will be read from the RUN.
A flag is then set with the registration indicating that the RUN is in a design phase of development.
The whole process or RUN registration is done in real-time. It is usually done in minutes over the phone by the user requesting the registration to be done by the Report Processing system Coordinator.
Registration is then complete, and the user can begin design. If he or she is new to design work, he or she may elect to use some of the tutorial RUN design aids, which were discussed in class, that provide guidance in filling out the various parts of the RUN function control statements. He or she is also taught in RUN design class to set up a small sample test data base containing examples of all data elements. This will allow the full development of the logic of the RUN. This not only protects the original report data but creates a faster response time during the interactive debugging process.
As he or she completes the definitions of the control statements, they can be executed immediately to see if they perform correctly. If there are errors in defining the statements, the RUN fails, and the failing RUN control report is displayed starting at the failing instruction. A diagnostic statement appears at the top of the display indicating the nature of the error, and the cursor is placed on the offending field or subfield of the erring control statement. This design work is quickly done, and testing is equally fast because there is no waiting for assemblies, compiles, or diagnostic listings to be provided. As a general rule, as an indication of efficiency of this application design method, it can be said that a real-time, transaction-oriented application with real-time updating can be done in less time than it would take to prepare a program-design specification using conventional, structured programming methods. RUN design is typically one-tenth or less the time of conventional language design for a comparable real-time application.
It should be noted that he or she must complete this design testing in the allowed I/O and logic line limit set for this RUN at the time of registration. Working with the limited test database, this can be done easily within the set limits. If he or she should exceed the I/Os or logic line limits, the RUN stops and gives a diagnostic message indicating that the I/O or logic line limit has been reached. An important point here is that this design environment is perfectly controllable and system safe. The I/O limits effectively control the allowance of system resource, and the logic line limit protects against computer consumption or endless loops. Database accessibility is also safely limited.
Eventually, the user finishes the design and testing of the RUN. He or she had been instructed when ·asking to have the RUN registered by the Coordinator that the RUN was considered in design and that he or she would be expected to have the RUN "log analyzed" when design was done and ready to put into production. So when ready for analysis, he or she makes an entry in the RUN that turns on the detailed transaction-logging process for the RUN. He or she then executes the RUN, noting the start and stop time of the RUN. With this information, he or she contacts the Coordinator, usually by phone, giving the station number at which the RUN was executed and the times of the RUN. The Coordinator then uses the real-time log-analysis function on hand to extract those RUN-related transactions from the total transaction log. He or she now has a step-by-step, instruction-by-instruction, detailed picture of the RUN in execution. There are also RUNs designed to test RUN design quality, which the user can use to determine RUN design quality before requesting final anlaysis from the Coordinator.
From this log data, the Coordinator can evaluate the specific impacts of each instruction executed in terms of I/Os expended, lines of data processed, response time, and identity of report data processed. He or she has RUNs, which have been developed for Coordinator use, that perform calculations on the log data. These calculations determine cost of the RUN in terms of resource dollars, and totals are developed for I/Os used, data and logic lines processed, response time, and other factors. From these analytical statistics, a very clear picture is established of the nature of the RUN, its effectiveness and system-resource impacts. At this point, if design improvements are suggested, the designer will be given the log analysis with suggestions on corrections to be made. The design-analysis interchange continues till the Coordinator is satisfied that a sound RUN has been created. Realistic I/O and logic line limits are then set for actual production use.
Often these production limits can be lower than those allowed in the design phase. In a real world of random-access, real-time Report Processing, control is obtained by executing many small processes. This characteristic also holds true in RUN function use. The vast majority of RUNs are relatively small analytical processes. This is another fact that many batch processing oriented, data-processing professionals have a hard time grasping. True real-time transactions-processing system design experience is not that common among data-processing professionals. Most are familiar with larger batch-job control systems. They fail to appreciate the nature of the transactional Report Processing environment, which is really a seething sea of small transaction processing that can be seriously polluted with a batch-job oriented control philosophy.
Some RUN functions can be developed that will do large amounts of data processing. They are designed in the same manner as other RUNs. After all the logic is developed, tested, and analyzed with a small test base, the RUN is allowed to execute against its full base with large-scale processing. To make this system safe, the I/O and logic line limits are established at appropriate larger settings. However, an allowed time of execution limit is established in addition to the other limits. This will allow the RUN to be executed only at nonbusy system times such as in the evening or over the noon hour. Such RUNs can also be scheduled to automatically start at a specific time perhaps well into second-or third-shift operation. A log analysis is also performed on the first execution under full-scale limits. With the knowledge from this analysis, the limits of I/O, logic lines, and time are ideally set for production use.
The development of RUN functions that process large amounts of data and provide extensive analytical power can often serve as a valuable initial design phase for the development of structured systems. For instance, a sizable RUN function may be developed that is providing an extensive data analysis and a resultant report generation in print-listed form. The simplicity of the RUN function language will enable the user to develop all the logic of the RUN and actually produce the desired result. Now it can be decided that this analysis could as easily be performed with a COBOL batch-report generator. Taking this type of large-scale report generation out of real-time system priority and running it at batch priority is obviously a better use of resources. Lower priority and larger data buffers make this batch processing resource effective for massive data processing.
With the developed RUN for guidance, the process of designing the COBOL report generator is made much simpler. All the logic is specifically defined in the RUN as well as the database relationships. There is also no question that the form of the output is what is really wanted. Clearly, the whole process of structured program design is made much more efficient and the success of the effort more assured.
Analysis tools are also available to Coordination to aid in monitoring production use of the RUNs. The entire transaction log record for each day is reduced to a record for each RUN indicating its frequency of use and highest I/O impact. These daily records are summarized on a weekly basis and on a monthly basis to establish a history of actual RUN use that provides a sound basis for RUN management. From these records, it is also possible to identify RUN functions that have become inactive and can be removed from the system.
So there is really no danger in allowing the users to become designers of RUNs. A completely system-safe, controlled, fully limited design environment can be created. Visibility is provided to ensure efficient design, and use of the RUNs can be monitored to ensure performance to plan and even to identify RUNs that become inactive.
Clearly, there is no danger in involving the innovative Power User members of the user-community in RUN design. The real danger lies in not doing so. For then, that rich, innovative potential that exists in every user community is stifled, and a burdensome, expensive data processing bureaucracy is unnecessarily encouraged.
In the history of MAPPER Report Processing systems, many Power Users developed rewarding careers in the promotion of Report Processing concepts in their operations. Often they were key in influencing Data Processing management to include Report Processing services in the computer systems available to them. Introducing Report Processing not only enables the users to develop powerful, valuable applications it also improves the image of Data Processing Services in the eyes of the users. The companies, Data Processing Services and the users are all winners as computer applications create powerful new dimensions of information exchange and management. As Report Processing services are integrated with the core company systems and the proliferation of user unique PC applications a dynamic world of information exchange evolves. Power User driven Report Processing services provide a powerful catalyst that enables a next generation of computer potential.
Chapter 17
MAPPER_A New Name & Image = Opportunity!
The MAPPER system opportunity is still viable today after a history of more than a 35 years. The MAPPER Systems development group still exists even though it has been reduced to half its original size. It still produces enhancements to the MAPPER products. A sizable MAPPER customer base still exists even though it is frustrated with Unisys neglect for these systems. There are several ways in which the MAPPER opportunity can be exploited.
One way is to increase Unisys stock value by differentiating the company as a true Innovator in the industry. This can be done by repackaging Unisys MAPPER Systems and offering the concept of Virtual Report Processing (VRP)as a major new dimension in computing capabilities. It is also possible that VRP MAPPER systems products could form the basis of a very profitable spin off company and very lucrative IPO stock offerings
The concepts of Real-Time Report Processing and User Designed Computing provided by the MAPPER System were originally defined in 1968. A new, added functional release has been made almost every year since then, hence its functional richness, which is unequaled in the industry. It is critical to recognize the fact that these capabilities are truly unique in the industry. No other products offer in one integrated, scalable software system: Functionality available across a wide range of industry open systems, An equivalent user executable set of Information Power Tools, A Report Structured Database with interfaces to industry Relational DB's, A complete, Powerful 4GL Application Development Language, Extensive screen, edit and application code generation, Client-Server Networking across a range of system sizes and vendors, Internet Integration and accessibility, A full set of system, user and database security controls, Upward application compatibility from MS Windows PC's to client-server and mainframe systems.
MAPPER software has been constantly upgraded to run on all of these state-of-the-art systems: Unisys main frame A, 1100/2200 and ClearPath series systems, Microsoft Windows and NT systems, Unisys UNIX, UNIXWARE, SUN, ATT and IBM RISC RS6000 and OS/2 systems.
Interfaces are available to create applications that integrate the MAPPER system capabilities and database with industry relational database systems such as: ORACLE, SYBASE, INFORMIX, Microsoft SQL Server, DB2, and Object Database Connectivity (ODBC).
MAPPER Development over the years and with increasing emphasis has promoted MAPPER system modernization. These modernization concepts encompass: A modern Graphic User Interface (GUI Windows like) look and feel for control of the interactive information Power Tools, + A modern application development environment, GUI, Unified system and database administration utilities, + Tools to aid in modernization of existing applications, Expanding interoperability with other industry software environmnents, Improved Internet operability and integration.
It is incredible that a system as powerful and openly system based as the MAPPER system is essentially unknown in the industry. It is unknown simply because Unisys does not choose to promote its potential either through education of its sales force or national advertising. Few members of the sales force understand the potential of MAPPER software selling or how to do it. Clearly a major, multi-billion $ business market and opportunity is being lost with this neglect. An indication of Unisys reluctance to promote MAPPER products is illustrated by the fact all the advertising about its new COOL ICE product does not mention that this is a MAPPER internet software feature.MAPPER has also been Web enabled with its Cool Ice offering. Cool ICE is a Web application server and set of development tools that enables you to manage Web services through the Internet. Cool ICE gives you the ability to: Create dynamic Internet-based application services.
Add new dimension and functionality to existing applications. Integrate multiple systems and databases. Provide secure Web access to data and applications on existing host systems.
Easily create, manage and maintain Internet documents, forms, and service categories.
Maintain a repository of applications and data.
Using Cool ICE, developers can create new Web-based business applications that extend the capabilities of the existing databases and applications beyond their original intent. Cool ICE enables developers to: Integrate an organization's existing back-end databases and applications.
Manipulate the data pulled from these databases and applications. Transform the data so it is available to users from a Web browser and in new Web-based business applications. Control access to the organization's Web-based applications and services.
Cool ICE is a software integration solution that allows organizations to manage dynamic Internet Web services on a corporate Intranet or the public Internet and World Wide Web.
What's New in Cool ICE?
The Cool ICE solution also offers the following capabilities: Accessing Cool ICE services with the Cool ICE COM Object model through Active Server Pages (ASP), Building Cool ICE applications using JavaScript and VB-Script, Build query definitions, data services and ActiveX Data Objects (ADO) from one or more data sources with the Cool ICE Wizard. Creating Cool ICE User Profiles through the ICE Administration tool, Managing gateways, configurations and connection pools with the Gateway Configuration tool, Modifying Cool ICE scripts and services with the Windows-based Cool ICE Script Editor.
The future potential of MAPPER Systems: The unequaled Virtual Report Processing capabilities of the Unisys MAPPER System can be the catalyst that would differentiate Unisys as a true industry innovator. No other software offers the functional richness and user empowerment potential of Virtual Report Processing. This potential was demonstrated as it drove Sperry Corporation successes, which eventually prompted the Unisys merger. When one considers that without the MAPPER software revenues and the hardware sales generated, Sperry would have had essentially no profitable, proprietary application software advantage. The case can be made that without MAPPER software revenue, the $ billion Sperry cash surplus that attracted the merger would never have been created.
The proprietary nature of MAPPER software also creates a unique vendor loyalty, which leads to system expansion hardware purchases from Unisys. The high profit margins of proprietary Unisys MAPPER software are very valuable. Such loyalty is not the case when Unisys markets other vendor's software, applications and databases. These other vendor products can be and are energetically shopped at initial purchase and at each enhancement level thereby critically reducing potential profit margins and customer loyalty.
The concepts of shared, Real-Time, Virtual Report Processing and User-Designed Computing that MAPPER systems have provided still represent a new way of using computers with essentially unlimited potential. These concepts clearly have enormous end-user appeal as illustrated by the Sperry success and the loyalty of the Unisys MAPPER customer base. The closest comparative software in the industry today is LOTUS NOTES, called Group Ware, which provides methods for managing message and E-mail sharing. IBM recognized the value of LOTUS NOTES and purchased the company. MAPPER software provides 150+ user-executable Information Power Tools with 750+ options for user-driven processing of a real-time, electronic file cabinet reporting database that can be networked across systems. This is a far greater capability than that offered by NOTES. Consider the impact that NOTES has had on the industry. MAPPER Systems potential for management Report Processing could be 10 times that if properly promoted.
Obviously, programming productivity has been greatly improved by developments such as Windows, Object and Visual methods. However, the full potential of computing will be limited as long as applications are primarily developed by professional programmers. Large scale, new computing can be unleashed to the extent that users can become designers and architects of their own databases and applications.
The most popular and productive computing applications have been those that allow users to design their own computing services. Examples of these are spread sheets, word processors, graphics design systems, etc. What makes these user-driven is that they are tool sets with which users can design and tailor their own computing services. A major dimension of computing remains to be exploited by users designing their own applications using user-driven Information Power Tools to do Virtual Report Processing. This is User-Designed-Computing (UDC). The potential of Report Processing UDC equals or could exceed all user-designed computing to date.
It is important to recognize that user-driven Virtual Report Processing does represent a new dimension of computing to the industry even though it has a long history of success with Unisys. It is a best-kept secret. It truly can be represented as Next Generation Computing for Users.
EXPLOITING THE MAPPER SYSTEM OPPORTUNITY: If Unisys is to realize the potential of the MAPPER System products as a "New Killer Application" it will be necessary to repackage them, creating a new, modern image. To do this, MAPPER systems should be renamed and promoted as the powerful Virtual Report Processing systems they are. Unisys should establish industry recognition for the concepts of Virtual Report Processing. (See the definition of Virtual Report Processing in Chapter 17.)
This will be unique in the industry. No other software systems offer an equivalent scale of shared, real-time Report Processing functionality. This would distinguish Unisys in the computer industry as a major innovator and change agent. Such recognition would stimulate interest in its stock. To effectively market VRP Systems, the following must be done:
Spin off the MAPPER Development Group into a VRP Systems company with its own development, marketing and support organizations. This is essential to focus the effort and ensure that promotions are done with a clear objective and understanding of Virtual Report Processing and user-driven computing concepts. This would also dispel the classic image of MAPPER systems and reinforce the idea that VRP systems truly represent new, innovative concepts as they actually do. While Report Processing enjoys a long history with the MAPPER system evolution, it is a new concept to the general computing industry. This venture requires a focused, true entrepreneurial spirit.
The VRP Systems company could also represent a valuable IPO stock offering with enormous profit potential. By promoting its unique, user driven Virtual Report Processing available over its range of Unisys and open industry systems and emphasizing its Cool Ice internet interface a stock offering of incredible appeal could be created.
With the current annual MAPPER software revenue base of ~$20 million, the VRP Company would immediately be profitable and able to support effective promotions and advertisement. The proven appeal of VRP capabilities to word-of-mouth recommendation among users would also aid recognition. With proper promotion, VRP Systems would have a $ billion market potential and would be the innovative "Jewel in the Crown" of Unisys as it was for Sperry.
Another option to take advantage of the Report Processing systems opportunity would be for a group of investors to take advantage of Unisys lack of interest and buy out its holdings in these systems. This group could then properly promote the Virtual Report Processing systems as a lucrative IPO stock offering. They could emphasize the proven, productive Virtual Report Processing capabilities as well as the system's internet potentials. These investors could also establish Virtual Report Processing service centers that would offer dial-in or internet accessible, real-time, shared Virtual Report Processing services on a user-fee basis to individuals and businesses of all kinds. This could be done either with MAPPER software rights or by licensing MAPPER software from Unisys. As these centers prove to be profitable they could be multiplied through franchise methods.
If this group obtains MAPPER software rights, they could also take over support of the existing MAPPER customer base from Unisys and thereby receive the ongoing software license fees which currently average approximately $20 million per year. The large remaining MAPPER customer base would welcome this given the current lack of interest and support Unisys shows for the software. This lack of interest and support on the part of Unisys is the primary cause of the constant erosion of the existing MAPPER customer base. The large, remaining MAPPER customer base would very much like to see a company dedicated to developing and supporting VRP System products.
The possibilities for exploitation of the extensive MAPPER system capabilities are truly unlimited. The question simply is, who will take advantage of these possibilities? Unisys is in the best position to take actions that will exploit the potentials. But, if not, Unisys can also benefit from a sell off of the product and still gain from others promoting it through hardware sales to VRP customers or from stock potentials in an IPO.
