- Email: [email protected]
Chapter XVIII In-Memory Operations
Chapter XVIII IN-MEMORY OPERATIONS
Having considered a general approach to the construction of mathematical models, to the retrieval of stored information, and to programming or realtime jobs, we must now bring under proper perspective the subject of inmemory operations. The process by which a real-time integrated data system regulates its own operation can be called "guidance logic." Neithertheparts nor the whole of this guidance logic need be very complex, but there should be present one or more logical mechanisms for guidance action. Here is exactly where mathematics and programming come together. The guidance functions should be set into a sequence that considers all in-process operations. Then, each function should be elaborated to a greater level of detail, and the housekeeping information used and developed by the guidance functions should be established. Consideration should always be given to unexplored alternatives and further ways and means of multi phase analysis. This is particularly true ofin-memory operations. Though variations may exist both as to the nature and the importance of data storage, in a general manner this may be thought of as comprising: • Information of a semipermanent type, "cataloging" the nature of the stored transaction programs and records • Information of a semitemporary type, relative to the current conditions in respect to capabilities and activities of the system components • Information of a temporary type, relative to the current condition of an in-process transaction program • Commands for special operations and for decision making when unexpected situations arise • Waiting lines containing information of a very temporary type defining the priority" interrelationships of different transactions being simultaneously processed and necessary in maintaining intratransaction continuity.
325
326
PART V.
PROGRAMMING FOR REAL-TIME DUTY
While guidance activities and characteristics ultimately are traceable to the job, the system must develop instantaneous motor action within its operational environment. This will relate directly to chosen methods of system design. A discussion about it will be more meaningful when it is oriented in a direct context.
SELECfION IN MEMORY In a real-time system, data may need to be selected on the basis of their content or of their relation to other records. This selection can be effected in a certain predetermined sequence, in a computer generated sequence, or according to a set of different criteria which will change with the application. The "selection-in-memory" problem becomes more involved if one considers that a certain flexibility should be provided to the system and that not every case of data demand can be forecasted. If records are to be selected on the basis of their content, the programmer should not be concerned with the exact machine address of a record. Since the computer will move records from one memory device to another, as their activity and age change, it will be virtually impossible for a programmer to know, at any moment, exactly where a record might be located. In the long run, indexing would become too complicated to upkeep. Some automatic information retrieval techniques must be used to enable the computer to identify the desired record. As a data system ages on the job, its operation can be enhanced if the identification and selection of a certain "data block" are based upon data contained in that record. To accomplish this, the system must retrieve a record on the basis of certain predetermined criteria. For instance, a code may be assigned by the computer to each in-process operation to designate 'its stage of completion. Then, selection based on the completion criterion will be a simple matter ofseparating all orders with the right completion code, a well-known capability of computers and extensively used in all types of file analysis. The situation is more involved if the prediction of new sequences is required. Inventory analysis and scheduling, for example" require that special consideration be given to in-memory data selection. Let us assume that we are faced with a total, integrated industrial application, where inventory management must be performed automatically and on a real-time basis. In the process of determining if an item should be reordered, it would probably be necessary to examine the outstanding requirements whose due dates fall between the present date and the next due data for "in-process" items. Apart from other complications, the solution of this problem may be interlocked
XVIII.
IN-MEMORY OPERA nONS
327
with the nonavailability of certain data, whose processing has been automatically delayed by the machine. The criteria for such retention or delay might well have been quite independent of those concerning inventory control. In this, as in a variety of other process control applications, the total cycle of inmemory selection would include writing new records on the large capacity storage, selecting records from that storage, storing them in the working memory, and, after processing, returning the records to the large capacity storage. This does not differ significantly from present-day electronic computation practices, regarding its major steps. But, the differences are rather outstanding as to the implementation of these steps. Because of the integrated nature of the system one input event may, with some delay, trigger off a series of transactions, the initiation of which is under machine, not human, control. However, an input to the system may be erroneous or incomplete at the time of entry, or it may be correct at the time of entry but changed at a later time. Hence, it is necessary that the following be provided in addition to detecting as far as possible inputs of an erroneous or incomplete nature at the time of entry: • A general-purpose tracing procedure which will, upon request, automatically trace the consequences of any input and present information about these consequences to the person requesting it • A general-purpose nullification procedure which will, upon request, nullify the consequences of any input as far as this is possible. These are fundamental considerations for the real-time program by which, given a transaction input, the effect of input on the information in the system can be traced. The ability to do this is an almost essential requirement. The ability to carry out the converse of this operation, given a piece of stored . information, to trace all transactions which changed this information, is sometimes a desirable, although not necessarily an essential, requirement. In either case, the burden for analyzing then scheduling the corresponding in-memory operation is on the programmer. The retrieval and in-memory selection procedures, outlined in the foregoing, would probably necessitate separate control subunits within the memory system. An in-memory control subunit might be composed of the following: • A fast bit control register with relatively simple instructions, as, for example, single and multiple record accept, forward, and shift between alternative storage devices. • An in-out address register with special trapping features, a control device able to perform memory lockout for space availabilities.
328
PART V.
PROGRAMMING FOR REAL-TIME DUTY
• Two compare registers containing the search information necessary to determine the correct storage location. One register is needed to hold the data constituting the basis of the comparison and another for the variable word compared against the standard. The larger the memory, the more severe will be the problem of data control and regulation in every phase it is approached. For instance, the initial job of loading the files and creating an index for a memory unit of very large size is a major task because of, among other factors, the problem of interweaving file patterns so that the records are located at the optimum access and in correct patterns. This problem, apart from other considerations, puts a heavy task on the programmer because of the deadlock possibilities it can entail.
THE DEADLOCK PROBLEM
Deadlock possibilities exist not only within the range of memory assignments but for every matter concerning subsystem and component availabilities. A program conflict is said to exist when one program wants a facility that is already being used by another program in such a way as to make simultaneous use impossible. This situation can arise if there is at least one facility in the system that cannot be used by more than one program at a time, while at least two programs can request the use of that facility in an unrestricted manner. Unless a program deadlock exists, a program conflict situation will resolve itself automatically when the executive coordinator releases the facility desired by a waiting program. However, if because of response requirements the waiting program must take the facility away from the possessing program before the latter is finished with it, complications might result. It may be, for instance, that a "first" program conflict situation is followed by a "second" one. Then say that the possessing program in the first conflict situation cannot proceed because it is a waiting program in the second conflict situation. What could and should the programmer do about it? The solution to situations like the foregoing has to be worked out under the perspective of the existing problem requirements and the available computing facilities. It is, nevertheless, true that the nature and extent of the programming conflicts can vary, at times presenting difficult to solve situations. With reference to the preceding example, say, for instance, that the second program conflict depends for its resolution on the release of a facility held by the waiting program in the first conflict. Then, none of the programs involved in the chain will be able to proceed; and, as long as none of the wanted facilities will be released, the deadlock situation will continue to exist.
XVIII.
IN-MR'vfORY OPERATIO,,"S
329
If the programmer makes no rule available which the interlocked programs can follow, the program deadlock may never be resolved. This might eventually cause the cessation of processing on all programs in the deadlock chain. Also, facilities held by these programs remain unattainable to other programs which, although not members ofthe deadlock chain, want a facility held by the deadlocked program. Here exactly lies the ingenuity of the analysis that preceded the programming work. With mathematical simulation, the analyst might have experimented on a variety of different deadlock situations, thus providing the programmer with some sound rules to follow. Experimentation on deadlock possibilities with a view to predecision may become, at times, quite involved, since several deadlock situations may exist simultaneously. The occurrence of just one more program conflict may cause multiple deadlocks to arise in a previously undeadlocked system. To break a program deadlock after it has occurred, the best approach might be to take a facility that is part of the deadlock chain away from the possessing program and give it to the program in the chain that wants it. With present-day programming practices, the "deprivation" possibility, to which reference has just been made, looks feasible for record facilities. For terminal facilities it would result in the intermixing of an output operation for one program with a previously initiated and not yet terminated input or output operation for another program. Taking away a terminal from one program and giving it to another, therefore, while feasible, may prove quite undesirable. In fact. depriving a program of a record facility and giving it to another may even have some undesirable consequences, since, when the deprived program finally regains the facility, the record may have been changed. If this is the case, then upon regaining the facility the deprived program must analyze the record to determine ifinformation previously used by it has been changed. -lf not, it can proceed as if nothing happened. If yes, it must go back, nullify the operations that made use of information now found to have been changed, and then redo these operations, using the new information in the record. In the case that the program had previously executed an irreversible action, such as the sending of an output message to an operator, then the nullification would be impossible and the hypothesized practice of periodically depriving facilities from certain programs might prove to be determinal. This suggests that a programming approach more sophisticated than those presently known and established may be necessary, such as, for instance, the automatic information retrieval approach, * which would enable the machine not only to write in, retain, and access information but also to abstract its fundamental nature, contents, and location.
* Sec
Chapters XI and XII.
330
PART V.
PROGRAMMING FOR REAL-TIME DUTY
For matters concerning in-memory operations, the day may come to classify machines by the qualitative reference of what they remember. We have no interest in storing information if the crucial aspects of this information cannot be retrieved. These aspects might constitute an automatic key to the use of the data on hand or the process under control. We may desire, for instance, that the information system "remember" those properties that are much more important than the physical information itself. For control systems purposes, it may be imperative that the computer remember such things as the quantity of information, its accuracy, what it described, its source, its use, and what it meant. The most important information for the guidance of a physical or man-made process is certainly not a collection of numbers or even a collection of formulas. Neither is it any collection of skills, techniques, and methodologies which have been programmed into the machine. It is the orderly, though stochastic in nature, collection of crucial data from "total experience" on the basis of which decisions can be made, and whose existence data control systems owe most of their value, if not their total reason of existence. For almost all guidance purposes, the value of the answers produced is much less important than the knowledge of what went on in the course of producing those answers. Almost inevitably, a computer, whose function involves the control of a certain process, must interpret, understand, and remember relationships and behavioral lines of critical importance. In this way, the information contained in the programs executed by a real-time system may be the only valid operational characterization of a major activity. In fact, it may be much more valuable in itself than the numbers that have been stored during data acquisition or have been calculated by the machine. Seen in this perspective, the in-memory deadlock problem takes on a completely different aspect. Three alternatives can then be stated as possible solutions: (I) A voiding deadlocks through the retrieval of qualitative reference to eventually provide the machine with a self-adjustingfaculty. Though this is still a remote possibility, it remains the most promising, particularly in view of the large variety of processing applications real-time systems will undertake in the years to come. (2) Avoiding deadlocks by scheduling the program's run well in advance so that applications which will be processed concurrently do not request identical facilities. This imposes a restriction on the application which, in general, would not be acceptable. (3) A voiding deadlocks by delaying the initiation of a program when one or more-of the facilities it must use is already occupied. Again, this is generally impractical since the records, and even terminals, a program is going to use are unpredictable.
XVIII.
IN-MEMORY OPERATIOI"S
331
Current automatic deadlock detection methods require that the machine keep an up-to-date table showing the programs currently possessing or wanting facilities and the facilities they possess or want. In a limited approach to deadlock detection, the machine is asked to determine whether or not a deadlock exists, without necessarily defining complete conflict chains. The computer would then produce a table, listing programs and facilities that are possessed and wanted, each properly labeled according to some set of rules. Even with the media available at the present time, in deciding how best to break a deadlock, it may be desirable for the machine to consider the nature of the programs involved, the stage to which they have progressed, and their priority. If these considerations are to be ignored, deadlocks could be broken taking into account only the number of programs and facilities involved. In this way, deadlocks can be broken by using the rule of disturbing the least number of programs, or the alternative rule of disturbing the least number of facilities.
ACCESS TO MEMORY
Another facet of the deadlock problem has to be examined. In a real-time data control system having multiprocessing capabilities, it is feasible that two programs operating simultaneously may want to use the same record. One solution is to use a multiplexing device, so that the one demand that gets to it first will select it. As a solution. this sequencing process is particularly good if the selecting program does not change, but will only refer to the record. Depending on the number of accessing media, any other program can select the same record before the first program is finished with it. If, however, the first program changes the record, a certain mark should be placed somewhere in the record to indicate that such a change took place. Two distinct cases can be stated in this respect. First, that the change is required before other programs make access to the record. Second, that the record should not be accessed while the affected change is still there. The first can be handled by delaying other requests until the change takes place. The second by blocking all attempts to use the record before the first program restores it to its former information condition. Waiting lines of transactions in data networks can be viewed as critical in "sustaining the thread" of information through the discrete stages of its in-process life. Although it might be argued that several times in a transaction's life no 'waiting line entry exists at all, it is also true that this data continuity might well be determined by the range of the considered time intervals. If these time intervals are large enough, several waiting line entries
332
PART V.
PROGRAMMING FOR REAL-TIME DUTY
would exist simultaneously for the same transaction. To avail a solution to this problem, the following provisions might be advantageous: • Whenever a terminal is found busy and cannot be utilized for new output, a "terminal busy" mark can be appropriately stored. • Transaction programs needing the terminal and sensing a "busy" mark should enter the waiting line. • All busy marks should be removed either when the last entry in the line is serviced or before any entries in the line are serviced. The need for this type of monitoring program arises because most data inputs to a real-time system have a random or almost random distribution of occurrences. Assuming that response to inputs must occur within a predetermined time range to justify the "real-time" characterization of the system, this behavior, along with company work hours and volume fluctuations over the month, causes capacity peaking of the data system. Extra capacity at certain times must be achieved either by increased speed or by multiprogram operation. But concurrent processing of several transactions would require either potentially inactive hardware or systems capable of component switching. Depending on the specific function of the system, much of the capacity increase can be avoided by treating some transactions with priority over others when a processing queue develops. Average working memory space requirements can vary by a factor of up to twenty between different types of transactions enterable from the same terminal. Working memory space required between extremes for the same type of transaction can vary even more. Fixed working memory space allocation, by terminal or transaction type, would require a working memory size substantially larger than if space were assigned on a demand basis. This might be done, for example, by limiting the number of in-memory registers reserved by input-output terminals for housekeeping while the rest of the working memory will be switched along applications by means of a memoryguidance feature.
MEMORY DUMPS AND SEMIPROGRAMS
The information to be dumped for a program can consist of a considerable range of inputs, of selected in-memory stored records, of partially set up outputs, and of temporary data developed by the transaction program itself. Because of the need for retrieving the information that will be dumped, an executive routine is necessary, enabling the first dump section to be addressed and providing for the storage of separate program parts in preassigned positions. A form of character count for each program part can be used to
XVIII.
IN-MEMORY OPERATIONS
333
recognize when one part has been completely retrieved, and initiating the retrieval of the next. In practice, many of the memory dump operations can be completed by a single throughput. Others, however, might require a "conversation" between different processing media. If this is the case, then processing subsystems must be provided with features that would enable them to keep track of partially executed programs whose completions depend on the other processing devices. To free the working memory from the data ofpartially executed programs, the "suspended" programs should be moved to a "dump" storage and stored there until the next in-line operational subsystem calls for them. In these terms, if the string of commands necessary for the complete processing of a certain job is still named a "program," then we must distinguish sections or segments of these programs on the basis that some of them will be definitely processed in an interrupted manner. The expression semiprogram can be used to denote any unit smaller than a complete transaction program. Only one "serniprograrn" need be brought into the working memory at a time. * In the case of a program-interrupt, until the discontinued transaction can be resumed, all information pertaining to it must be preserved for subsequent use. Hence it has to be stored somewhere. The information to be preserved for use with the following program section will, in general, include input data, data from retrieved records, and results of logical operations and of computation. If this information were simply left in the working memory, much ofthe working memory space would have to be allotted for this purpose, since at any given time a large number of transactions may be in a discontinued condition, the maximum number being the number of terminals. This is why instead of adopting the above scheme, it might be preferable to use a design approach of comparable logical complexity in which the characters of extra storage would be external to the working memory. For these reasons, an on-line integrated data control system may need to be provided with dump memory of a considerably cheaper material than the working memory, and which can operate at slower read and write speeds. With a dump memory it is possible to process programs that have long interspersed waiting periods, dumping information at the end of one program section and retrieving it when the next program section of the same program is initiated. Other cases demanding dumping are the entry of an input message that exceeds a pre-established size in characters, and a program wishing to use a facility, such as a terminal, but being unable to do so because the facility *The term "subprogram." or "subroutine" which might have been more appropriate. has already been used in computer programming in connection with quite different concepts. See also the following chapter.
334
PART V.
PROGRAMMING FOR REAL-TIME DUTY
is already being used by another program. The latter is essentially one ofthe conflicting program situations we have examined. A "conversational type" of handling transaction may also require dumping facilities. A transaction is said to take place in the conversational mode if, after an operator has completely entered an input message which is acted upon by the processing unit, he is requested to enter another input message which must be considered by the processing unit in conjunction with the previously entered information. The conversational mode is employed to tell an operator, after he has entered one item of information, what item of information he should enter next. It is also employed for error correcting purposes, in what would otherwise be single-input, single-output transactions. Say, for example, that an input message consisted of 30 different items, all entered consecutively without any computer intervention. The processing unit, upon finding an error in one of the items, after all items have been entered, would send an output message to the operator, requesting him to re-enter the item involved. Whenever a waiting period occurs in a "conversational mode" type of transaction, information must be dumped to be retrieved for use with the next program section of the same program after the next input message has been received from the operator. For each dumping condition, and after disappearance of the condition that caused the dumping, the program section that has been dumped must eventually be moved out of the dump memory and resumed. In all cases, except those of program conflict, the program resumption can be triggered off from the terminal involved when it initiates a processing request which is selected at random by the processing unit. Resumption of a program, which was dumped because of a processing conflict situation, might be done by occasionally picking one of these dumped programs at random and seeing if the desired facility had become available. Or, the dumped programs that want an unavailable facility might be associated with the facility in some manner, and resumed in turn after the facility becomes available. The implications posed by the foregoing on programming approaches is evident. A semiprogram will be ended by a specific file or processing reference, while a program will be ended by an output. Programs that would be executed in one piece will be brought to working memory from their temporary or permanent storage one at a time. Programs consisting ofsemiprograms will be brought in the memory in terms of the latter and it is, therefore, required that each semiprogram provide in itself the necessary information linkage. Program subdivision will enable the assignment of the working memory space where and when needed, and in only the quantities that are necessary for the processing of the job. The assigned space should be released as soon
XVIII. IN-MEMORY OPERA nONS
335
as the function for which it had been assigned has been carried out. Output space should be released after transmission is completed. The same is true for "interface" memory space.* These, of course, are among the requirements the process control programmer should carefully observe. Because interrupt signals for the processing of semiprograms have both input and output features, a problem of distinction arises within the processing system. It concerns which "start" signal means "what." The executive routine must also distinguish between "initiation" and "response" inputs; the latter being a linkage among semiprograms. The semiprograms would give end "responses" while the complete program would proceed by means of "initiation" and "completion" signals. Another programming distinction is between operations executed "on demand" and those executed "at leisure." "On demand" processing means that certain functions must be executed in a finite amount of time. As, for instance, the storage of characters of an input message before the information is lost off the end of the transmission line. Inversely, the term "at leisure" applies to all of the guidance activities that present no danger of losing information by failure to act before a certain time has elapsed. For the general programming case, it is difficult, nevertheless, to distinguish between "on demand" and "at leisure" job processing. Not only are jobs transferable from the one category to the other, depending on the requirements of the moment, but also for a system with finite processing capabilities, the larger the percentage of "on-demand" jobs the greater the delay of the "at leisure" jobs will be. The latter will eventually need to be critically evaluated as to the wisdom of putting them "on demand." Classification and reclassification functions can best be performed by a control subunit operating within the framework of the over-all guidance. The functions performed by this unit would be generally those of: • Recognizing service requests by terminal operators • Transmitting output messages in terminals specified by the transaction program • Interpreting specific considerations relating to the work of in-process and in-backlog. This type of work can obviously be performed either through real or through simulated hardware. The programming scheme that can perform these functions would not be basically different from the wayan executive routine is constructed, but due attention should be given to the handling of the "on leisure" opera!ions. For this, the executive program must be able to:
* As defined here, "interface" is the storage and other hardware required fordata transmission between subsystems.
336
PART V.
PROGRAMMING FOR REAL-TIME DUTY
• • • • •
Assign memory space for storing inputs and for the transaction program. Initiate the retrieval of interrupt information. Move into active memory the appropriate stored transaction program. Initiate the execution of the transaction program. Initiate selection from their permanent storage locations of any records ordered by the transaction program. • Initiate dumping operations for retainable programs.
In all, this complex of data operations through its own executive action must make sure that none of its components will sit idle for too long a time before reactivation by control programs. In priority assignments, what makes the over-all problem rather difficult is that higher-priority programs arriving at the data system subsequently to priority allocations would upset the established dominance in processing. Several priority schemes exist to answer the foregoing question, but a great deal of thought should be given to the subject before anyone is selected for a specific situation. Priority consideration could also be used for avoiding the need of system changes, on a temporary basis, because ofthe increased data processing requirements of the environment. In establishing relative degrees of priority recognition, the criteria might range from a rule of "first come-first served" to that of complete analysis and comparison of one transaction against all others processed by the system. This problem becomes more involved if one considers the complexity brought about through simultaneous operations. A priority rule worth considering is that of "due time." Due time priorities are based on a relative "deadline" for starting the transaction so as to still meet its particular response requirement. Recognition of priorities could begin with the assignment of input space, but again this has the drawback that relatively slow terminal data linkages entering highpriority transactions would sometimes unfairly delay lower-priority transaction responses. Analytically, the priority of a data operation can in general be established by a complete consideration of its functions. Some provisions should also be made for modifications and changes in priorities. A programmed rule for breaking priority sequence could be developed. Such a rule should, however, observe that it is not always feasible to interrupt other functions before they are completed. At times, a priority reassignment may have to wait its turn. In a multiarithmetic computer, the actual processing status of ajob would not be a trivial affair. Perhaps the best way to this end is to make the computer aware of its own organizational structure and to provide the machine with the ability to conceive any actual activity mix. The sensing of the status of each unit and the processing position of a program or semiprogram could avoid
XVIII.
I~-MEMORY
OPERATIONS
337
delaying the execution of other functions. Status registers would be helpful in this regard. Such registers should be interrogated by the machine program to determine interput and processing conditions. The programmer should duly consider throughout his work that interrupt points may also be needed during the execution of arithmetic-logic instructions. In fact, they can occur at any time in an instruction sequence due to a program's need to make a file reference, transmit an output, select the next program subsection to be run, dump itself, release some of its space, or carry out any combination of these activities. Strict demand allocation of space can be compromised by providing for a maximum for each type of input transaction. Here, again, multiprocessing considerations may affect, to a substantial extent, the complexity of the logical structure of the machine program. From a structural point of view, and for most industrial applications, the program for an on-line machine would operate generally on a cyclic basis in what concerns the performance of its functions. A substantial variety of inputs from different sources would arrive at the computer at different times and at varying rates, but, unless major changes take place in the process, each one of these data inputs would have its place in a certain operational cycle. To cope with such variations in input the programmer should temporarily store data on a certain buffer medium, then bring it into the working memory at the required time. A similar situation exists for outputs which would be generally transferred first to some output buffer, which then routes them to individual destinations at rates dictated by the control devices or communication facilities. Processing possibilities are often improved by classifying all controllable elements into three major categories, each characterized by its time sensitivity. In this way we may distinguish fast, intermediate, and slow computer control loops.
DATA RETRIEVAL AND PRIORITIES Priority loops help attain a more effective utilization of the machine capacity while they provide the basis for a timely control of the process. The techniques used in establishing priorities may vary with the application since they will necessarily reflect the relative importance of the different process components. Also, apart from the informationhandling considerations, the programmer must examine the technical requirements ~f the main processing units. The following basic rules should be observed if a data control system is to meet both economic and technical limits:
338
PART V.
PROGRAMMING FOR REAL-TIME DUTY
• Data automation must be suitable for both large and small production lots, adaptable to design changes, and capable of a building block approach. • The programming work must be flexible enough in handling a wide range of work and materials, so that there can be reasonably rapid conversion of the line from the manufacture of one commodity to another. • The programming philosophy must have sufficient flexibility so that new materials and also systems components may be used in the production system, once their reliability is assured, without developing guidance conflicts. • The computer programs must provide the necessary guarantees for the system's reliable performance. One of the most critical problems of automatic production methods is that of quality control and product testing or inspection. Quality assurance in itself constitutes a broad area for control systems applications. * The three areas of production analysis, the design of the product, the materials processing, and the fabrication machinery used, must be considered together as a system when automatic production is studied with a view to program development for digital control. We spoke of the implications of digital automation in design when, in Chapter XIV, we made reference to "mathematics for design automation." In the following, we will review another outstanding approach to a traditionally routine subject: data retrieval for personnel purposes. The Systems Development Corporation has written a "personnel data retrieval," time-sharing programming systern.t It provides an on-line inquiry capability for searching personnel data files. The inquiry capability is assisted by an on-line teletype send-receive set. This allows the inquirer to insert the commands, control information, and search parameters required for the data retrieval. It communicates the results of the search to the inquirer and enables him to specify the format of the desired output listing and the arithmetic operations to be performed upon the data. The use of the personnel data retrieval program enters within the general framework of the time-sharing project of ARPA. At the time we visited with the Job Corps in Washington:j: there were three users operating on three
* See also Chapter XXIX, Volume B, for a unified approach to quality history and continuous control procedures. t The writer wishes to express his appreciation to SDC management. The following text is based on the information kindly supplied by SOC and on the demonstration at the Job Corps. :j:This was in June. 1%5. We wish to thank Dr. Eigen and Dr. Stellwagen, of the Job Corps, for their collaboration in the demonstration that took place.
XVIII.
IN-MEMORY OPERATIONS
339
different "data bases": the Job Corps, the Air Force, and SOC. For reasons of homogeneity, a general ECCO program, under which the retrieval system operates, was developed. ECCO helps to reduce the amount of space required for storing various programs on the disk file and to reduce maintenance costs by having a single program meet the needs of all users. Further, it facilitates the application of the retrieval capability to new areas of interest, as the program will operate on any appropriately prepared data base including all those currently in existence. The retrieval system provides three basic features. The first is a general search capability whereby persons with various characteristics may be identified from the data base. These are selected as a function of search criteria; the full records for those persons who qualify or match on the specified criterion variables are temporarily stored either for subsequent searches on this subgroup or for a listing of the required information. As a special feature of the search capability, it is possible to locate all information about a single employee simply by using the employee's man number as the criterion variable. This search results in a complete listing of all items of information contained in the data base and concerning the selected person. The second feature comes into effect after the search has been completed. Its objective is to allow the operator to specify a printout of any of the information contained in each persons record, in a variety of formats. It is, therefore, possible to call for any item of information in the person's record once he has qualified on the search criteria, even though these items of information were not included in the original search criteria. The third is a mathematical faculty able to perform two statistical operations (arithmetical mean and range) on any qualified items of information in the data base. The words SIG MA and SQUARES are recognized by the program as equivalent to the statistical notions of mean and range. The ECCO program may be logged in by the procedure: ! LOGIN 4672 99000 ECCO,
where 4672 is the person's number* and 9900 is the appropriate work order number. The commands can be briefly described as follows: • The user indicates his intention to process or search the complete file which is identified by "TAPE XXXX." The system then responds that it is ready for the next command by the message "*OK, NEXT REQUEST."
* In this particular case it is an SDC person's number; users who do not have SDC numbers and work order numbers will log in according to the procedures described in a special manual.
340
PART
v.
PROGRAMMING FOR REAL-TIME DUTY
• The user requests that all those employees with a first speciality code of YYY and who are, say, over 30 years of age be located. The programming system gives the date and time, permitting the user to calculate the length of time required to search the file. · Following this operation the user, say, may request to reduce the file to just those employees whose start date is prior to ZZZ. The programming system will locate the persons who meet this additional criterion. • Then, the user may request the average of three numerical items in the data base for the group-selected persons: start date, years in first speciality, and birth date. The system calculates these averages and indicates the number of employee records on which these averages are based. • In the following operation, the user may request that certain information about these employees be listed, and specifies the items to appear and the format of the printout, indicating the number of spaces between columns with asterisks. • Finally, the user may wish to communicate directly with the computer system at any time to obtain information about the system itself. One such input is !USERS, which indicates how many users are simultaneously participating in the time-sharing system. Others include !TIME, indicating time of day to the nearest tenth ofa minute; !STATUS, concerning the condition of the user's program; ! DRUMS, indicating number of words available on drums; and !TAPES, indicating the number of tape drives available. To perform its function in an efficient manner, while presenting substantial systems reliability, a good deal of investment has been done in diagnostics, and in subsystems and components redundancy. This investment is said to represent about one-third of the cost of the machine. The ECCO command keywords are SEARCH, LIST, ONE, ALL, GIVE, IL and REWIND. REWIND calls a rescue operation and IL provides debugging information. The selection criteria are, in effect, also commands, but have no keyword. Wherever the program outputs the message "*OK, NEXT REQUEST" or "*ENTER CO RRECTED REQUEST" it expects one of the foregoing commands. The first word of the subsequent input is compared against a list of the command keywords. The commands are free inputs. The programming system also includes "responsive inputs" made as required answers to questions from the program. Examples of responsive inputs are: *HOW MUCH DISK? Response to this question is given in two numbers: the first is the number of records; the second is the length of each record in characters, which the user will want to store on disk as a subfile. There is no way to revise the estimate once it is entered except by reloading; a search requiring more disk than has been
XVIII.
IN-MEMORY OPERA nONS
341
requested is terminated by the message *FILE FULL. The message *HOW MANY MORE LINES? is used when a LIST operation has output the required number of lines, but has not reached an end of file. At the beginning of a communication between the peripheral device and the program a "reflector" systems check, concerning the two-way communication network, helps e-stablish the functional status. The device operator may input: "Everything I type, you reflect back to me," then: (l) Type on the keyboard the "ford: STATUS.
(2) Then, if the system is in control, he should receive for reply: STATUS. (3a) Should this reply be OK (as above), the device operator would act on it. (3b) If the reply is not OK, the operator will give the signal for "erase": ! Currently, at least, systems programming does not include diagnosis for the communications part of the job. In contrast, program "FIX" has been written for internal diagnostics. This program helps answer the question "what is wrong?" while other more sophisticated routines are in development concerning matters such as "voltage excursions." An example of what happens when an unexperienced device operator sits on the controls is the following sequence in intercommunication of which we would acknowledge the parenthood:
,
[1lUMS ; 92~ 72 WDS ON DRUMS LOGIN JC002 JGI07 $OK lOG ON 26 lOAD ECCO • $WAIT USERS
.b 9 USERS.
FROM 44
WHAT IS NUMBER OF TAPE YOU WANT lOADEQ 7
FROM 44 DO lOAD REQUEST AGAIN PLS lOAD ECCO • $WAIT
FRO~ 44 WE KEEP GETTING LOAD FOR 26 REEL • DIAL 9 TELL 44 WE WANT ECCO I AM ASKING PAT.
$/'ISG IN. DIAL 9 THE TAPE' IS 1599 •
lMS3 IN. ::iTA IUS
$NOT LQAOED OIAl 9 WHAT SEEMS TO BE THE TROUBLE. $/'ISG IN.
~lJHAT
1
I >Y(O[2""PfZGC
,AND THATS ALL
Having considered a general approach to the construction of mathematical models, to the retrieval of stored information, and to programming or realtime jobs, we must now bring under proper perspective the subject of inmemory operations. The process by which a real-time integrated data system regulates its own operation can be called "guidance logic." Neithertheparts nor the whole of this guidance logic need be very complex, but there should be present one or more logical mechanisms for guidance action. Here is exactly where mathematics and programming come together. The guidance functions should be set into a sequence that considers all in-process operations. Then, each function should be elaborated to a greater level of detail, and the housekeeping information used and developed by the guidance functions should be established. Consideration should always be given to unexplored alternatives and further ways and means of multi phase analysis. This is particularly true ofin-memory operations. Though variations may exist both as to the nature and the importance of data storage, in a general manner this may be thought of as comprising: • Information of a semipermanent type, "cataloging" the nature of the stored transaction programs and records • Information of a semitemporary type, relative to the current conditions in respect to capabilities and activities of the system components • Information of a temporary type, relative to the current condition of an in-process transaction program • Commands for special operations and for decision making when unexpected situations arise • Waiting lines containing information of a very temporary type defining the priority" interrelationships of different transactions being simultaneously processed and necessary in maintaining intratransaction continuity.
325
326
PART V.
PROGRAMMING FOR REAL-TIME DUTY
While guidance activities and characteristics ultimately are traceable to the job, the system must develop instantaneous motor action within its operational environment. This will relate directly to chosen methods of system design. A discussion about it will be more meaningful when it is oriented in a direct context.
SELECfION IN MEMORY In a real-time system, data may need to be selected on the basis of their content or of their relation to other records. This selection can be effected in a certain predetermined sequence, in a computer generated sequence, or according to a set of different criteria which will change with the application. The "selection-in-memory" problem becomes more involved if one considers that a certain flexibility should be provided to the system and that not every case of data demand can be forecasted. If records are to be selected on the basis of their content, the programmer should not be concerned with the exact machine address of a record. Since the computer will move records from one memory device to another, as their activity and age change, it will be virtually impossible for a programmer to know, at any moment, exactly where a record might be located. In the long run, indexing would become too complicated to upkeep. Some automatic information retrieval techniques must be used to enable the computer to identify the desired record. As a data system ages on the job, its operation can be enhanced if the identification and selection of a certain "data block" are based upon data contained in that record. To accomplish this, the system must retrieve a record on the basis of certain predetermined criteria. For instance, a code may be assigned by the computer to each in-process operation to designate 'its stage of completion. Then, selection based on the completion criterion will be a simple matter ofseparating all orders with the right completion code, a well-known capability of computers and extensively used in all types of file analysis. The situation is more involved if the prediction of new sequences is required. Inventory analysis and scheduling, for example" require that special consideration be given to in-memory data selection. Let us assume that we are faced with a total, integrated industrial application, where inventory management must be performed automatically and on a real-time basis. In the process of determining if an item should be reordered, it would probably be necessary to examine the outstanding requirements whose due dates fall between the present date and the next due data for "in-process" items. Apart from other complications, the solution of this problem may be interlocked
XVIII.
IN-MEMORY OPERA nONS
327
with the nonavailability of certain data, whose processing has been automatically delayed by the machine. The criteria for such retention or delay might well have been quite independent of those concerning inventory control. In this, as in a variety of other process control applications, the total cycle of inmemory selection would include writing new records on the large capacity storage, selecting records from that storage, storing them in the working memory, and, after processing, returning the records to the large capacity storage. This does not differ significantly from present-day electronic computation practices, regarding its major steps. But, the differences are rather outstanding as to the implementation of these steps. Because of the integrated nature of the system one input event may, with some delay, trigger off a series of transactions, the initiation of which is under machine, not human, control. However, an input to the system may be erroneous or incomplete at the time of entry, or it may be correct at the time of entry but changed at a later time. Hence, it is necessary that the following be provided in addition to detecting as far as possible inputs of an erroneous or incomplete nature at the time of entry: • A general-purpose tracing procedure which will, upon request, automatically trace the consequences of any input and present information about these consequences to the person requesting it • A general-purpose nullification procedure which will, upon request, nullify the consequences of any input as far as this is possible. These are fundamental considerations for the real-time program by which, given a transaction input, the effect of input on the information in the system can be traced. The ability to do this is an almost essential requirement. The ability to carry out the converse of this operation, given a piece of stored . information, to trace all transactions which changed this information, is sometimes a desirable, although not necessarily an essential, requirement. In either case, the burden for analyzing then scheduling the corresponding in-memory operation is on the programmer. The retrieval and in-memory selection procedures, outlined in the foregoing, would probably necessitate separate control subunits within the memory system. An in-memory control subunit might be composed of the following: • A fast bit control register with relatively simple instructions, as, for example, single and multiple record accept, forward, and shift between alternative storage devices. • An in-out address register with special trapping features, a control device able to perform memory lockout for space availabilities.
328
PART V.
PROGRAMMING FOR REAL-TIME DUTY
• Two compare registers containing the search information necessary to determine the correct storage location. One register is needed to hold the data constituting the basis of the comparison and another for the variable word compared against the standard. The larger the memory, the more severe will be the problem of data control and regulation in every phase it is approached. For instance, the initial job of loading the files and creating an index for a memory unit of very large size is a major task because of, among other factors, the problem of interweaving file patterns so that the records are located at the optimum access and in correct patterns. This problem, apart from other considerations, puts a heavy task on the programmer because of the deadlock possibilities it can entail.
THE DEADLOCK PROBLEM
Deadlock possibilities exist not only within the range of memory assignments but for every matter concerning subsystem and component availabilities. A program conflict is said to exist when one program wants a facility that is already being used by another program in such a way as to make simultaneous use impossible. This situation can arise if there is at least one facility in the system that cannot be used by more than one program at a time, while at least two programs can request the use of that facility in an unrestricted manner. Unless a program deadlock exists, a program conflict situation will resolve itself automatically when the executive coordinator releases the facility desired by a waiting program. However, if because of response requirements the waiting program must take the facility away from the possessing program before the latter is finished with it, complications might result. It may be, for instance, that a "first" program conflict situation is followed by a "second" one. Then say that the possessing program in the first conflict situation cannot proceed because it is a waiting program in the second conflict situation. What could and should the programmer do about it? The solution to situations like the foregoing has to be worked out under the perspective of the existing problem requirements and the available computing facilities. It is, nevertheless, true that the nature and extent of the programming conflicts can vary, at times presenting difficult to solve situations. With reference to the preceding example, say, for instance, that the second program conflict depends for its resolution on the release of a facility held by the waiting program in the first conflict. Then, none of the programs involved in the chain will be able to proceed; and, as long as none of the wanted facilities will be released, the deadlock situation will continue to exist.
XVIII.
IN-MR'vfORY OPERATIO,,"S
329
If the programmer makes no rule available which the interlocked programs can follow, the program deadlock may never be resolved. This might eventually cause the cessation of processing on all programs in the deadlock chain. Also, facilities held by these programs remain unattainable to other programs which, although not members ofthe deadlock chain, want a facility held by the deadlocked program. Here exactly lies the ingenuity of the analysis that preceded the programming work. With mathematical simulation, the analyst might have experimented on a variety of different deadlock situations, thus providing the programmer with some sound rules to follow. Experimentation on deadlock possibilities with a view to predecision may become, at times, quite involved, since several deadlock situations may exist simultaneously. The occurrence of just one more program conflict may cause multiple deadlocks to arise in a previously undeadlocked system. To break a program deadlock after it has occurred, the best approach might be to take a facility that is part of the deadlock chain away from the possessing program and give it to the program in the chain that wants it. With present-day programming practices, the "deprivation" possibility, to which reference has just been made, looks feasible for record facilities. For terminal facilities it would result in the intermixing of an output operation for one program with a previously initiated and not yet terminated input or output operation for another program. Taking away a terminal from one program and giving it to another, therefore, while feasible, may prove quite undesirable. In fact. depriving a program of a record facility and giving it to another may even have some undesirable consequences, since, when the deprived program finally regains the facility, the record may have been changed. If this is the case, then upon regaining the facility the deprived program must analyze the record to determine ifinformation previously used by it has been changed. -lf not, it can proceed as if nothing happened. If yes, it must go back, nullify the operations that made use of information now found to have been changed, and then redo these operations, using the new information in the record. In the case that the program had previously executed an irreversible action, such as the sending of an output message to an operator, then the nullification would be impossible and the hypothesized practice of periodically depriving facilities from certain programs might prove to be determinal. This suggests that a programming approach more sophisticated than those presently known and established may be necessary, such as, for instance, the automatic information retrieval approach, * which would enable the machine not only to write in, retain, and access information but also to abstract its fundamental nature, contents, and location.
* Sec
Chapters XI and XII.
330
PART V.
PROGRAMMING FOR REAL-TIME DUTY
For matters concerning in-memory operations, the day may come to classify machines by the qualitative reference of what they remember. We have no interest in storing information if the crucial aspects of this information cannot be retrieved. These aspects might constitute an automatic key to the use of the data on hand or the process under control. We may desire, for instance, that the information system "remember" those properties that are much more important than the physical information itself. For control systems purposes, it may be imperative that the computer remember such things as the quantity of information, its accuracy, what it described, its source, its use, and what it meant. The most important information for the guidance of a physical or man-made process is certainly not a collection of numbers or even a collection of formulas. Neither is it any collection of skills, techniques, and methodologies which have been programmed into the machine. It is the orderly, though stochastic in nature, collection of crucial data from "total experience" on the basis of which decisions can be made, and whose existence data control systems owe most of their value, if not their total reason of existence. For almost all guidance purposes, the value of the answers produced is much less important than the knowledge of what went on in the course of producing those answers. Almost inevitably, a computer, whose function involves the control of a certain process, must interpret, understand, and remember relationships and behavioral lines of critical importance. In this way, the information contained in the programs executed by a real-time system may be the only valid operational characterization of a major activity. In fact, it may be much more valuable in itself than the numbers that have been stored during data acquisition or have been calculated by the machine. Seen in this perspective, the in-memory deadlock problem takes on a completely different aspect. Three alternatives can then be stated as possible solutions: (I) A voiding deadlocks through the retrieval of qualitative reference to eventually provide the machine with a self-adjustingfaculty. Though this is still a remote possibility, it remains the most promising, particularly in view of the large variety of processing applications real-time systems will undertake in the years to come. (2) Avoiding deadlocks by scheduling the program's run well in advance so that applications which will be processed concurrently do not request identical facilities. This imposes a restriction on the application which, in general, would not be acceptable. (3) A voiding deadlocks by delaying the initiation of a program when one or more-of the facilities it must use is already occupied. Again, this is generally impractical since the records, and even terminals, a program is going to use are unpredictable.
XVIII.
IN-MEMORY OPERATIOI"S
331
Current automatic deadlock detection methods require that the machine keep an up-to-date table showing the programs currently possessing or wanting facilities and the facilities they possess or want. In a limited approach to deadlock detection, the machine is asked to determine whether or not a deadlock exists, without necessarily defining complete conflict chains. The computer would then produce a table, listing programs and facilities that are possessed and wanted, each properly labeled according to some set of rules. Even with the media available at the present time, in deciding how best to break a deadlock, it may be desirable for the machine to consider the nature of the programs involved, the stage to which they have progressed, and their priority. If these considerations are to be ignored, deadlocks could be broken taking into account only the number of programs and facilities involved. In this way, deadlocks can be broken by using the rule of disturbing the least number of programs, or the alternative rule of disturbing the least number of facilities.
ACCESS TO MEMORY
Another facet of the deadlock problem has to be examined. In a real-time data control system having multiprocessing capabilities, it is feasible that two programs operating simultaneously may want to use the same record. One solution is to use a multiplexing device, so that the one demand that gets to it first will select it. As a solution. this sequencing process is particularly good if the selecting program does not change, but will only refer to the record. Depending on the number of accessing media, any other program can select the same record before the first program is finished with it. If, however, the first program changes the record, a certain mark should be placed somewhere in the record to indicate that such a change took place. Two distinct cases can be stated in this respect. First, that the change is required before other programs make access to the record. Second, that the record should not be accessed while the affected change is still there. The first can be handled by delaying other requests until the change takes place. The second by blocking all attempts to use the record before the first program restores it to its former information condition. Waiting lines of transactions in data networks can be viewed as critical in "sustaining the thread" of information through the discrete stages of its in-process life. Although it might be argued that several times in a transaction's life no 'waiting line entry exists at all, it is also true that this data continuity might well be determined by the range of the considered time intervals. If these time intervals are large enough, several waiting line entries
332
PART V.
PROGRAMMING FOR REAL-TIME DUTY
would exist simultaneously for the same transaction. To avail a solution to this problem, the following provisions might be advantageous: • Whenever a terminal is found busy and cannot be utilized for new output, a "terminal busy" mark can be appropriately stored. • Transaction programs needing the terminal and sensing a "busy" mark should enter the waiting line. • All busy marks should be removed either when the last entry in the line is serviced or before any entries in the line are serviced. The need for this type of monitoring program arises because most data inputs to a real-time system have a random or almost random distribution of occurrences. Assuming that response to inputs must occur within a predetermined time range to justify the "real-time" characterization of the system, this behavior, along with company work hours and volume fluctuations over the month, causes capacity peaking of the data system. Extra capacity at certain times must be achieved either by increased speed or by multiprogram operation. But concurrent processing of several transactions would require either potentially inactive hardware or systems capable of component switching. Depending on the specific function of the system, much of the capacity increase can be avoided by treating some transactions with priority over others when a processing queue develops. Average working memory space requirements can vary by a factor of up to twenty between different types of transactions enterable from the same terminal. Working memory space required between extremes for the same type of transaction can vary even more. Fixed working memory space allocation, by terminal or transaction type, would require a working memory size substantially larger than if space were assigned on a demand basis. This might be done, for example, by limiting the number of in-memory registers reserved by input-output terminals for housekeeping while the rest of the working memory will be switched along applications by means of a memoryguidance feature.
MEMORY DUMPS AND SEMIPROGRAMS
The information to be dumped for a program can consist of a considerable range of inputs, of selected in-memory stored records, of partially set up outputs, and of temporary data developed by the transaction program itself. Because of the need for retrieving the information that will be dumped, an executive routine is necessary, enabling the first dump section to be addressed and providing for the storage of separate program parts in preassigned positions. A form of character count for each program part can be used to
XVIII.
IN-MEMORY OPERATIONS
333
recognize when one part has been completely retrieved, and initiating the retrieval of the next. In practice, many of the memory dump operations can be completed by a single throughput. Others, however, might require a "conversation" between different processing media. If this is the case, then processing subsystems must be provided with features that would enable them to keep track of partially executed programs whose completions depend on the other processing devices. To free the working memory from the data ofpartially executed programs, the "suspended" programs should be moved to a "dump" storage and stored there until the next in-line operational subsystem calls for them. In these terms, if the string of commands necessary for the complete processing of a certain job is still named a "program," then we must distinguish sections or segments of these programs on the basis that some of them will be definitely processed in an interrupted manner. The expression semiprogram can be used to denote any unit smaller than a complete transaction program. Only one "serniprograrn" need be brought into the working memory at a time. * In the case of a program-interrupt, until the discontinued transaction can be resumed, all information pertaining to it must be preserved for subsequent use. Hence it has to be stored somewhere. The information to be preserved for use with the following program section will, in general, include input data, data from retrieved records, and results of logical operations and of computation. If this information were simply left in the working memory, much ofthe working memory space would have to be allotted for this purpose, since at any given time a large number of transactions may be in a discontinued condition, the maximum number being the number of terminals. This is why instead of adopting the above scheme, it might be preferable to use a design approach of comparable logical complexity in which the characters of extra storage would be external to the working memory. For these reasons, an on-line integrated data control system may need to be provided with dump memory of a considerably cheaper material than the working memory, and which can operate at slower read and write speeds. With a dump memory it is possible to process programs that have long interspersed waiting periods, dumping information at the end of one program section and retrieving it when the next program section of the same program is initiated. Other cases demanding dumping are the entry of an input message that exceeds a pre-established size in characters, and a program wishing to use a facility, such as a terminal, but being unable to do so because the facility *The term "subprogram." or "subroutine" which might have been more appropriate. has already been used in computer programming in connection with quite different concepts. See also the following chapter.
334
PART V.
PROGRAMMING FOR REAL-TIME DUTY
is already being used by another program. The latter is essentially one ofthe conflicting program situations we have examined. A "conversational type" of handling transaction may also require dumping facilities. A transaction is said to take place in the conversational mode if, after an operator has completely entered an input message which is acted upon by the processing unit, he is requested to enter another input message which must be considered by the processing unit in conjunction with the previously entered information. The conversational mode is employed to tell an operator, after he has entered one item of information, what item of information he should enter next. It is also employed for error correcting purposes, in what would otherwise be single-input, single-output transactions. Say, for example, that an input message consisted of 30 different items, all entered consecutively without any computer intervention. The processing unit, upon finding an error in one of the items, after all items have been entered, would send an output message to the operator, requesting him to re-enter the item involved. Whenever a waiting period occurs in a "conversational mode" type of transaction, information must be dumped to be retrieved for use with the next program section of the same program after the next input message has been received from the operator. For each dumping condition, and after disappearance of the condition that caused the dumping, the program section that has been dumped must eventually be moved out of the dump memory and resumed. In all cases, except those of program conflict, the program resumption can be triggered off from the terminal involved when it initiates a processing request which is selected at random by the processing unit. Resumption of a program, which was dumped because of a processing conflict situation, might be done by occasionally picking one of these dumped programs at random and seeing if the desired facility had become available. Or, the dumped programs that want an unavailable facility might be associated with the facility in some manner, and resumed in turn after the facility becomes available. The implications posed by the foregoing on programming approaches is evident. A semiprogram will be ended by a specific file or processing reference, while a program will be ended by an output. Programs that would be executed in one piece will be brought to working memory from their temporary or permanent storage one at a time. Programs consisting ofsemiprograms will be brought in the memory in terms of the latter and it is, therefore, required that each semiprogram provide in itself the necessary information linkage. Program subdivision will enable the assignment of the working memory space where and when needed, and in only the quantities that are necessary for the processing of the job. The assigned space should be released as soon
XVIII. IN-MEMORY OPERA nONS
335
as the function for which it had been assigned has been carried out. Output space should be released after transmission is completed. The same is true for "interface" memory space.* These, of course, are among the requirements the process control programmer should carefully observe. Because interrupt signals for the processing of semiprograms have both input and output features, a problem of distinction arises within the processing system. It concerns which "start" signal means "what." The executive routine must also distinguish between "initiation" and "response" inputs; the latter being a linkage among semiprograms. The semiprograms would give end "responses" while the complete program would proceed by means of "initiation" and "completion" signals. Another programming distinction is between operations executed "on demand" and those executed "at leisure." "On demand" processing means that certain functions must be executed in a finite amount of time. As, for instance, the storage of characters of an input message before the information is lost off the end of the transmission line. Inversely, the term "at leisure" applies to all of the guidance activities that present no danger of losing information by failure to act before a certain time has elapsed. For the general programming case, it is difficult, nevertheless, to distinguish between "on demand" and "at leisure" job processing. Not only are jobs transferable from the one category to the other, depending on the requirements of the moment, but also for a system with finite processing capabilities, the larger the percentage of "on-demand" jobs the greater the delay of the "at leisure" jobs will be. The latter will eventually need to be critically evaluated as to the wisdom of putting them "on demand." Classification and reclassification functions can best be performed by a control subunit operating within the framework of the over-all guidance. The functions performed by this unit would be generally those of: • Recognizing service requests by terminal operators • Transmitting output messages in terminals specified by the transaction program • Interpreting specific considerations relating to the work of in-process and in-backlog. This type of work can obviously be performed either through real or through simulated hardware. The programming scheme that can perform these functions would not be basically different from the wayan executive routine is constructed, but due attention should be given to the handling of the "on leisure" opera!ions. For this, the executive program must be able to:
* As defined here, "interface" is the storage and other hardware required fordata transmission between subsystems.
336
PART V.
PROGRAMMING FOR REAL-TIME DUTY
• • • • •
Assign memory space for storing inputs and for the transaction program. Initiate the retrieval of interrupt information. Move into active memory the appropriate stored transaction program. Initiate the execution of the transaction program. Initiate selection from their permanent storage locations of any records ordered by the transaction program. • Initiate dumping operations for retainable programs.
In all, this complex of data operations through its own executive action must make sure that none of its components will sit idle for too long a time before reactivation by control programs. In priority assignments, what makes the over-all problem rather difficult is that higher-priority programs arriving at the data system subsequently to priority allocations would upset the established dominance in processing. Several priority schemes exist to answer the foregoing question, but a great deal of thought should be given to the subject before anyone is selected for a specific situation. Priority consideration could also be used for avoiding the need of system changes, on a temporary basis, because ofthe increased data processing requirements of the environment. In establishing relative degrees of priority recognition, the criteria might range from a rule of "first come-first served" to that of complete analysis and comparison of one transaction against all others processed by the system. This problem becomes more involved if one considers the complexity brought about through simultaneous operations. A priority rule worth considering is that of "due time." Due time priorities are based on a relative "deadline" for starting the transaction so as to still meet its particular response requirement. Recognition of priorities could begin with the assignment of input space, but again this has the drawback that relatively slow terminal data linkages entering highpriority transactions would sometimes unfairly delay lower-priority transaction responses. Analytically, the priority of a data operation can in general be established by a complete consideration of its functions. Some provisions should also be made for modifications and changes in priorities. A programmed rule for breaking priority sequence could be developed. Such a rule should, however, observe that it is not always feasible to interrupt other functions before they are completed. At times, a priority reassignment may have to wait its turn. In a multiarithmetic computer, the actual processing status of ajob would not be a trivial affair. Perhaps the best way to this end is to make the computer aware of its own organizational structure and to provide the machine with the ability to conceive any actual activity mix. The sensing of the status of each unit and the processing position of a program or semiprogram could avoid
XVIII.
I~-MEMORY
OPERATIONS
337
delaying the execution of other functions. Status registers would be helpful in this regard. Such registers should be interrogated by the machine program to determine interput and processing conditions. The programmer should duly consider throughout his work that interrupt points may also be needed during the execution of arithmetic-logic instructions. In fact, they can occur at any time in an instruction sequence due to a program's need to make a file reference, transmit an output, select the next program subsection to be run, dump itself, release some of its space, or carry out any combination of these activities. Strict demand allocation of space can be compromised by providing for a maximum for each type of input transaction. Here, again, multiprocessing considerations may affect, to a substantial extent, the complexity of the logical structure of the machine program. From a structural point of view, and for most industrial applications, the program for an on-line machine would operate generally on a cyclic basis in what concerns the performance of its functions. A substantial variety of inputs from different sources would arrive at the computer at different times and at varying rates, but, unless major changes take place in the process, each one of these data inputs would have its place in a certain operational cycle. To cope with such variations in input the programmer should temporarily store data on a certain buffer medium, then bring it into the working memory at the required time. A similar situation exists for outputs which would be generally transferred first to some output buffer, which then routes them to individual destinations at rates dictated by the control devices or communication facilities. Processing possibilities are often improved by classifying all controllable elements into three major categories, each characterized by its time sensitivity. In this way we may distinguish fast, intermediate, and slow computer control loops.
DATA RETRIEVAL AND PRIORITIES Priority loops help attain a more effective utilization of the machine capacity while they provide the basis for a timely control of the process. The techniques used in establishing priorities may vary with the application since they will necessarily reflect the relative importance of the different process components. Also, apart from the informationhandling considerations, the programmer must examine the technical requirements ~f the main processing units. The following basic rules should be observed if a data control system is to meet both economic and technical limits:
338
PART V.
PROGRAMMING FOR REAL-TIME DUTY
• Data automation must be suitable for both large and small production lots, adaptable to design changes, and capable of a building block approach. • The programming work must be flexible enough in handling a wide range of work and materials, so that there can be reasonably rapid conversion of the line from the manufacture of one commodity to another. • The programming philosophy must have sufficient flexibility so that new materials and also systems components may be used in the production system, once their reliability is assured, without developing guidance conflicts. • The computer programs must provide the necessary guarantees for the system's reliable performance. One of the most critical problems of automatic production methods is that of quality control and product testing or inspection. Quality assurance in itself constitutes a broad area for control systems applications. * The three areas of production analysis, the design of the product, the materials processing, and the fabrication machinery used, must be considered together as a system when automatic production is studied with a view to program development for digital control. We spoke of the implications of digital automation in design when, in Chapter XIV, we made reference to "mathematics for design automation." In the following, we will review another outstanding approach to a traditionally routine subject: data retrieval for personnel purposes. The Systems Development Corporation has written a "personnel data retrieval," time-sharing programming systern.t It provides an on-line inquiry capability for searching personnel data files. The inquiry capability is assisted by an on-line teletype send-receive set. This allows the inquirer to insert the commands, control information, and search parameters required for the data retrieval. It communicates the results of the search to the inquirer and enables him to specify the format of the desired output listing and the arithmetic operations to be performed upon the data. The use of the personnel data retrieval program enters within the general framework of the time-sharing project of ARPA. At the time we visited with the Job Corps in Washington:j: there were three users operating on three
* See also Chapter XXIX, Volume B, for a unified approach to quality history and continuous control procedures. t The writer wishes to express his appreciation to SDC management. The following text is based on the information kindly supplied by SOC and on the demonstration at the Job Corps. :j:This was in June. 1%5. We wish to thank Dr. Eigen and Dr. Stellwagen, of the Job Corps, for their collaboration in the demonstration that took place.
XVIII.
IN-MEMORY OPERATIONS
339
different "data bases": the Job Corps, the Air Force, and SOC. For reasons of homogeneity, a general ECCO program, under which the retrieval system operates, was developed. ECCO helps to reduce the amount of space required for storing various programs on the disk file and to reduce maintenance costs by having a single program meet the needs of all users. Further, it facilitates the application of the retrieval capability to new areas of interest, as the program will operate on any appropriately prepared data base including all those currently in existence. The retrieval system provides three basic features. The first is a general search capability whereby persons with various characteristics may be identified from the data base. These are selected as a function of search criteria; the full records for those persons who qualify or match on the specified criterion variables are temporarily stored either for subsequent searches on this subgroup or for a listing of the required information. As a special feature of the search capability, it is possible to locate all information about a single employee simply by using the employee's man number as the criterion variable. This search results in a complete listing of all items of information contained in the data base and concerning the selected person. The second feature comes into effect after the search has been completed. Its objective is to allow the operator to specify a printout of any of the information contained in each persons record, in a variety of formats. It is, therefore, possible to call for any item of information in the person's record once he has qualified on the search criteria, even though these items of information were not included in the original search criteria. The third is a mathematical faculty able to perform two statistical operations (arithmetical mean and range) on any qualified items of information in the data base. The words SIG MA and SQUARES are recognized by the program as equivalent to the statistical notions of mean and range. The ECCO program may be logged in by the procedure: ! LOGIN 4672 99000 ECCO,
where 4672 is the person's number* and 9900 is the appropriate work order number. The commands can be briefly described as follows: • The user indicates his intention to process or search the complete file which is identified by "TAPE XXXX." The system then responds that it is ready for the next command by the message "*OK, NEXT REQUEST."
* In this particular case it is an SDC person's number; users who do not have SDC numbers and work order numbers will log in according to the procedures described in a special manual.
340
PART
v.
PROGRAMMING FOR REAL-TIME DUTY
• The user requests that all those employees with a first speciality code of YYY and who are, say, over 30 years of age be located. The programming system gives the date and time, permitting the user to calculate the length of time required to search the file. · Following this operation the user, say, may request to reduce the file to just those employees whose start date is prior to ZZZ. The programming system will locate the persons who meet this additional criterion. • Then, the user may request the average of three numerical items in the data base for the group-selected persons: start date, years in first speciality, and birth date. The system calculates these averages and indicates the number of employee records on which these averages are based. • In the following operation, the user may request that certain information about these employees be listed, and specifies the items to appear and the format of the printout, indicating the number of spaces between columns with asterisks. • Finally, the user may wish to communicate directly with the computer system at any time to obtain information about the system itself. One such input is !USERS, which indicates how many users are simultaneously participating in the time-sharing system. Others include !TIME, indicating time of day to the nearest tenth ofa minute; !STATUS, concerning the condition of the user's program; ! DRUMS, indicating number of words available on drums; and !TAPES, indicating the number of tape drives available. To perform its function in an efficient manner, while presenting substantial systems reliability, a good deal of investment has been done in diagnostics, and in subsystems and components redundancy. This investment is said to represent about one-third of the cost of the machine. The ECCO command keywords are SEARCH, LIST, ONE, ALL, GIVE, IL and REWIND. REWIND calls a rescue operation and IL provides debugging information. The selection criteria are, in effect, also commands, but have no keyword. Wherever the program outputs the message "*OK, NEXT REQUEST" or "*ENTER CO RRECTED REQUEST" it expects one of the foregoing commands. The first word of the subsequent input is compared against a list of the command keywords. The commands are free inputs. The programming system also includes "responsive inputs" made as required answers to questions from the program. Examples of responsive inputs are: *HOW MUCH DISK? Response to this question is given in two numbers: the first is the number of records; the second is the length of each record in characters, which the user will want to store on disk as a subfile. There is no way to revise the estimate once it is entered except by reloading; a search requiring more disk than has been
XVIII.
IN-MEMORY OPERA nONS
341
requested is terminated by the message *FILE FULL. The message *HOW MANY MORE LINES? is used when a LIST operation has output the required number of lines, but has not reached an end of file. At the beginning of a communication between the peripheral device and the program a "reflector" systems check, concerning the two-way communication network, helps e-stablish the functional status. The device operator may input: "Everything I type, you reflect back to me," then: (l) Type on the keyboard the "ford: STATUS.
(2) Then, if the system is in control, he should receive for reply: STATUS. (3a) Should this reply be OK (as above), the device operator would act on it. (3b) If the reply is not OK, the operator will give the signal for "erase": ! Currently, at least, systems programming does not include diagnosis for the communications part of the job. In contrast, program "FIX" has been written for internal diagnostics. This program helps answer the question "what is wrong?" while other more sophisticated routines are in development concerning matters such as "voltage excursions." An example of what happens when an unexperienced device operator sits on the controls is the following sequence in intercommunication of which we would acknowledge the parenthood:
,
[1lUMS ; 92~ 72 WDS ON DRUMS LOGIN JC002 JGI07 $OK lOG ON 26 lOAD ECCO • $WAIT USERS
.b 9 USERS.
FROM 44
WHAT IS NUMBER OF TAPE YOU WANT lOADEQ 7
FROM 44 DO lOAD REQUEST AGAIN PLS lOAD ECCO • $WAIT
FRO~ 44 WE KEEP GETTING LOAD FOR 26 REEL • DIAL 9 TELL 44 WE WANT ECCO I AM ASKING PAT.
$/'ISG IN. DIAL 9 THE TAPE' IS 1599 •
lMS3 IN. ::iTA IUS
$NOT LQAOED OIAl 9 WHAT SEEMS TO BE THE TROUBLE. $/'ISG IN.
~lJHAT
1
I >Y(O[2""PfZGC
,AND THATS ALL