Data Base Conversion System

The present invention relates to apparatus and method for the translation and conversion of programs.

With the rapid development of different types of digital computer systems, the need to be able to utilize existing programs on new or different computer systems has become of considerable importance to users. In general, where a user desires to convert to another system, it becomes necessary to rewrite every program to be utilized on the new system. Additionally, it is necessary to translate the files utilized on the first system to a form useable by the second system. Of course, this conversion process becomes exceedingly time consuming and costly.

Accordingly, it is a primary object of the present invention to facilitate conversion of programs originated for a first system for use in a second system.

It is a further object of the present invention to allow users to be able to execute data base type programs on another system without having to make changes affecting the logic of such programs.

The above objects are achieved in a preferred embodiment of the present invention which includes a plurality of stored tables. The tables include information in the form of a data base description which defines the description of the first data base system in terms of the data base system upon which the program or programs are to be run. The system further includes a plurality of emulator routines arranged to perform a number of primitive operations. During the running of a program, the program generates a call to the operating system of the data processing system which in turn causes the selection of a particular group of the emulator routines for processing that call. The routines are operative to reference different ones of the stored tables for interpreting the call and for generating the appropriate information in order to execute the operation specified by the program as written originally. The routines also invoke the appropriate one of a number of data base routines of the system to perform the primitive operations required for satisfying that call. Upon the completion of the operations required, the routines are operative to provide the required appropriate return information to the original program so that program operates in the same manner as when it is run on the data base system for which it was originally written.

By including stored tables and additional operating system routines in accordance with the present invention, the system is able to run all of the data base type programs originated for another system without modifying the logic of such programs. Further, the arrangement of the invention maximizes the use of the facilities present in the system for executing programs written for its data base thereby sharing routines normally included in the system to perform data base operations for its own data base.

While in the preferred embodiment, the existing data base operations are implemented by program routines, they could also be performed by other means such as hardware or firmware. Examples of the systems arranged to perform such operations are described in the patent applications referenced in the introductory portion of the specification. Because of the desire to utilize the facilities and functions of existing computer systems, the present invention lends itself to a program general purpose machine implementation disclosed herein.

The above and other objects of this invention are achieved in the preferred embodiment disclosed hereinafter. Novel features which are believed to be characteristic of the invention both as to its organization and method of operation, together with further objects and advantages thereof will be better understood from the following description when considered in connection with the accompanying drawings. It is to be expressly understood, however, that these drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the present invention.

FIG. 1 shows in block diagram form a system which utilizes the arrangement of the present invention.

FIG. 2 illustrates diagrammatically the conversion performed by the system of FIG. 1.

FIG. 3a illustrates diagrammatically the translation performed by the host system.

FIG. 3b illustrates the memory organization of the host system in accordance with the present invention.

FIG. 3c is an IMS program used in explaining the operation of the present invention.

FIG. 3d illustrates diagrammatically the program conversion performed in accordance with the present invention.

FIG. 3e illustrates the organization of emulator modules for processing one type of data base operation in accordance with the present invention.

FIG. 3f illustrates in greater detail the organization of 3e.

FIG. 4 illustrates the organization of tables in accordance with the present invention.

FIGS. 5a through 5h illustrate in greater detail the format of each of the tables of FIG. 4.

FIGS. 6a through 6s are flow charts of the modules of FIG. 3e.

FIG. 7a is another IMS program used to explain the operation of the present invention.

FIG. 7b illustrates diagrammatically the operation of the program of FIG. 7a.

FIG. 7c illustrates the organization of emulator modules for processing another type of data base operation in accordance with the present invention.

FIG. 7d is a flow chart of other ones of the emulator modules of FIG. 7b.

FIGS. 7e and 7f show in greater detail certain modules of FIG. 7d.

FIG. 7g illustrates diagrammatically the changes in file structure in accordance with the present invention.

FIG. 1 illustrates a data processing system which includes the arrangement of the present invention. Referring to the figure, it is seen that the system includes a processor 100 which couples to a memory controller 200 for accessing a number of memory modules 300. The memory controller connects to one of a number of ports of an I/O controller 400 which controls the operation of a number of input/output devices by means of adapters which connect to controllers 500 and 600 as shown in FIG. 1. Additionally, card reader and card punch devices 700 and 800 also connect to the controller 400 as shown.

The systems of FIG. 1 may take the form of the system disclosed in U.S. Pat. Nos. 3,413,613 and 3,514,772. The management controls subsystem for supervising and managing the operation of the data processing systems referenced above in a preferred embodiment may take the form of the system described in U.S. Pat. No. 3,618,045.

Before discussing the system of the present invention, a brief discussion of data base management concept will be given. In the context of the present invention, the term "data base" refers to a set of files maintained by a data base management system for use in user specified creation, updating and interrogation processes. In general, the files of a data base are accessed through names or other identifiable data by the user in a prior definition process. The data base management system impairs a data base to be utilized through a combination of hardware and software facilities and operational conventions. The data base management systems just described have been characterized as being a "most language" group in contrast to a "self-contained" group. This group is dependent upon and supported by an already existing "host" language.

The system of FIG. 1 utilizes the Integrated Data Store (IDS) system. This system is described in considerable detail in a publication "IDS/l User's Guide Series 60 Level 66)/6000" published by Honeywell Information Systems Inc., Copyright 1974 designated by Order No. DC53, Rev. O. The data base management system is associated with one or more programming language compilers and operating systems. The compiler in this instance is COBOL and the operating system is described in the aforementioned patent and User's Manual. Additionally, reference may also be made to the text titled "Computer Data Management and Data Base Technology" by Harry Katzan, Jr., Van Nostrand Rinehold Company, Copyright 1975 by Litton Educational Publishing Company.

The basic unit of data in the IDS system is the record. A number of records comprises a file. The records in the data base are linked to one another through the use of chains which consist of a master record and a number of subordinate or detail records. In the present system, the user program defines a data record in a conventional fashion and the IDS system supplies the identification and chain fields. At least one chain field exists for each chain in which the record participates as a "member". A chain field contains the reference code (i.e., page and line number) of the "next" record in the ring structure. Additionally, the language used to describe the structure of an IDS data base in the IDS section of an IDS program enables a record to be linked to a prior record and to the master record for each chain in which it participates. Thus, the arrangement employs the so-called set concept which is used to recognize and represent the structural relationship between the data stored in the file. A set is an accessible collection of associated logical records representing a simple relationship between physical entities. Thus, any data base can be viewed as consisting of a number of logical files, each consisting of a number of logical records associated into a data base set wherein each record generally represents data concerning a physical entity and each set generally represents data concerning some logical relationship between the physical entities. In general, the records and sets accessed are classified according to a data structure diagram comprising at least two record-classes and at least one set-class. All of the records are individually processed through a data base management system using set access methods. The user employs a data definition language (DDL) which describes the structural information represented by the data structure diagram although a data processing system can create the data structure concerned in such a way to enable production of information through the use of the set access methods. For further background information regarding the Integrated Data Store system, the aforementioned references should be consulted.

The other data base system is defined as the Information Management System (IMS). As indicated, a data base provides for the integration or sharing of common data in the fashion that obviates the need for changing the data and programs of previously integrated applications. Thus, it makes the application program independent of the specific data organization and specific physical devices. This data base is also characterized as a host language system which means that programs can be written in a common programming language which is COBOL. The program interface is through the CALL program statement as explained herein.

In contrast to the IDS data base system, the IMS data base system comprises tree structured entities from which logical data files are defined by the user. In the process of defining data, the following definitions are applicable. A segment is the basic data element that has an interface between the program and defining data language. The segment which includes one or more logically related data fields is fixed in lengths. A logical data record is a hierarchal tree structure of segments which can be referenced independently of its physical representation. Data within the IMS system is organized from top to bottom, left to right segment order. When the program is required to access data within an IMS data base, it accesses segments as compared to accessing records in the IDS system. The major unit of data storage is the logical data base which consists of a set of logical data base records stored in accordance with one of a number of IMS organization techniques and is accessible by different ones of the defined access methods all well known in the art.

Before an application program can utilize an IMS data base, a description of the data base must be generated by the data processing system. The data base description (DBD) is specified through the use of a set of DBD macro instructions which generate an object code version of the data base description, the DBD is stored and used during program execution. The generation of the data base description includes the specifying of the data base name, segment names, and attributes, intersegment relationships, field names and attributes, data base organization and access methods. A description of the data in the data base to which a program is "sensitive" is included in a program specification block (PSB) also referenced during program execution. The PSB is generated separately in the same manner as the DBD. The PSB normally includes the definition of the data base that can be used by the program, a specification of an operational mode (e.g. retrieve only, update, etc.) and a specification of the segments to which program that has access (is "sensitive").

In general, when the IMS system form is included in a batch processing environment, the operating system initially passes control to the program and a parameter list that accompanies the call from the so-called IMS load module, called a region controller, provides access to information included in the program's PSB. That is, in the IMS system, the region controller initiates data base processing by calling the user program. At that time, as indicated, the controller passes the PCB addresses as arguments in the order in which they appear in the programs PSB. Since the PSB, as mentioned, includes a description of each data base accessed by the user program, the PSB consists of one or more PCB's.

The IMS user program communicates with Data Language/I modules through call statements each of which in COBOL has the general form: CALl `CBLTDLI` USING (parmcount) FUNCTION, PCB-NAME, I/O AREA, SSA1, SSA2, . . . SSAn. When making an input or output call, the user program or "host language program" specifies the following required and optional parameters:

1. Symbolic name of the desired input or output function (e.g., INSERT).

2. PCB -name (e.g., CALL `CBLTDLI` using (parmcount) function, PCB name).

3. Input/output work area (e.g., I/O area SSA1, . . . SSAn).

4. Optical "segment search arguments".

The segment search argument is used by a user program to specify a desired segment by field names and field names in parent segments leading to the desired segment.

The format of the PCB is:

The program interacts with the system data language modules to access the data base. Upon receiving a call from the program, the data language module references the PSB and DBD control blocks to verify the validity of the request and to obtain descriptive information on the data requested by the program. The data language module provides two interfaces with the program. The first is a means of describing the logical structure of the data base and the second is a program linkage for specifying input and output requests from the program.

Summarizing the above, the major differences between the two are as follows. Both IMS and IDS systems employ different "currency philosophies" in the data base. In the IDS case, the currency is maintained through IDs reference codes or IDS storage device (disk) addresses expressed in page and line number. The data base structure is ringed or chained implemented by means of "threaded lists". In IMS, the data base structure is sequential and currency information must be retained for higher levels.

As mentioned previously, information in IMS is organized on a top to bottom, left to right segment order. That is, for example, in an arrangement where one segment is at a first level, two segments are at a second level and one segment is at a third level, segment 1 would be at level 1, segment 2 at level 2 (left most), segment 3 at level 3, and segment 4 would be the right most segment at level 2. Since each segment has a different segment number, the segments can be regarded as separate. As discussed above, this is not the case in IDS.

Another significant point of difference concerns the manner of communicating between user programs and data bases. IDS is a compiler oriented system and hence call parameters must be "bound" or fixed before execution. For example, whenever a retrieve call statement is included, it will always retrieve the same kind or type of record. In IMS, the interpretation of the call can be qualified by means of qualifier codes or parameters. Hence, the call parameters are not bound until execution time enabling a different type or kind of record to be retrieved by a call statement.

A still further difference relates to the description of the data base. In IDS, the description of the data base is resident in the user's program. In IMS, as mentioned above, the description of the data base is maintained externally and the programmer is advised of its location.

Another major difference relates to the way in which items are stored in the data base and the manner in which the data base is maintained or kept current. As mentioned, IDS has a completely random file structure whereas IMS has a fixed file format and the type of addressing is sequential. Accordingly, IMS user programs in many instances are written to take advantage of the sequential nature of the IMS data base.

From the foregoing, the significant differences in the characteristics of the two data base systems can be seen. In order to accomplish conversion, a number of preliminary operations are performed by both the original system and the system upon which the unconverted programs are to be run. The operations are illustrated diagrammatically by FIG. 2.

Referring to FIG. 2, it is seen that the original system includes the IMS data base stored on file 901 and that the system includes a utility program represented by block 902 which writes the data base contents onto magnetic tape 903. As indicated by the figure, each of the original user programs written in COBOL are also loaded onto magnetic tape 903 as illustrated by block 904.

It will be appreciated that the two tapes 903 and 904 are placed on magnetic tape devices of the host data base system. The operations just described with respect to the original system are carried out in a well known manner.

It will be appreciated that because of the differences in architecture between the two systems it is necessary to translate the original COBOL programs so that they can be run directly on the host system. However, the translation does not affect the logic of the program itself. Except for changes required by the COBOL to COBOL conversion, all calls remain unchanged. Thus, the calling sequence is still CALL CBLTDL using FUNCTION CODE, PCB-NAME, I-O AREA, SSA-1, . . . SSA-7, or CALL CBLTDL using ARG-COUNT, FUNCTION CODE, PCB-NAME, I-O AREA, SSA-1, . . . SSA-6. Accordingly, it is possible to use conventional COBOL translators. For example, in the arrangement of the present invention, a conversion aids programming system (CAPS) illustrated in FIG. 3d.

Before a source program can be converted, the user prepares parameter cards to identify the source program, specify its characteristics and select certain options. The user also prepares job control language (JCL) cards for specifying how the program is to be run on the operating system. When the conversion takes place, the conversion aids program (CAPS) object deck is loaded into the processor and the user prepared JCL and parameter cards are also loaded into the system. The conversion is performed and the output takes the form of a listing of the translator program source code. It will be appreciated that the conversion program constructs a source program that is logically and functionally equivalent to the input program. Thereafter, the translator program undergoes some hand tailoring which may involve a manual patching or coding of a program to the source language of the new system via a terminal device. Hand tailoring is necessary in order to correct those instances where the conversion aid program may not have been able to convert source language for a specific peripheral device on the new system and it is necessary to modify manually the coding of the program to correct this problem. However, such tailoring will not affect the logic of the program.

It can also be seen from FIG. 2 that the tape containing the data base is converted via a load program into an IDS data base. Stated differently, the files containing, for example, numbers of the subscribers organized according to subscriber number is formatted to the IDS format. The format takes the form of that described in the aforementioned IDS manual. It will be appreciated that part of the format modifications are necessary in that the format of the disk files on each of the systems are arranged in an entirely different fashion.

While it is necessary to reformat the files in the original system to the IDS file structure in the old system, this is time consuming, but only to be done once.

It can be seen from FIG. 2 that the file translation operation requires information defining the data base description of the IDS data base. This information which characterizes how that data base is organized in the host system is utilized by an IDS translator of block 912 which translates the IDS user data base description into object code to be used at execution time by IDS routines. During the translation, the translator 912 is operative to store information enabling the translation to be reversible. Stated differently, the translator is arranged to provide information which describes the IMS data base in an IDS form to be used by the host system. Therefore, instead of having the translation be performed to completion, the IDS translator 912 is interrupted and an intermediate form of code which relates the IMS file information to the IDS information is stored on file 940 (e.g., relationship of a subscriber record (IMS) to a membership record [IDS]).

The intermediate form of code serves as an IDS data base description which is in turn used by other translators corresponding to blocks 934 and 926, to generate the resulting PSB information stored on file 924. Before describing the operations of these translators, it will be noted that each IMS job required data base descriptions in card form as illustrated by block 936. This information is supplied to translator 934 along with the IDS data base description. The translator in a manner analogous to the translation performed by the IMS translator produces an intermediate data base description stored on file 932. The translator 934 utilizing the IMS data base description as well as the IDS data base description on file 940 produces the intermediate file as mentioned which represents a combination of the IDS description in terms of the IMS data base.

The translator 926 satisfies requirements of the IMS data base relating to defining the data bases to be used by a particular program. Normally before you can execute a program in the IMS data base, it is necessary to perform program specification block generation which indicates to a particular program what data bases it is going to utilize, what records and fields out of those data bases it will utilize and with what permission (e.g., can it read a record, write a record, delete a record, insert a record, etc.). The result of the PSB generation is normally stored in a file and fetched during execution time by the system.

In a fashion similar to that described above, the translator 924 performs checks for determining whether the data base and records are valid and generates a result which is stored on file 924. As explained herein, this file comprises a number of tables which can be divided into two sections: an IDS section and an IMS section. In accordance with the present invention, the emulation routines utilize the IDS section while the user IMS program uses the IMS section. Thus, the emulation routine provides an interface between the IDS and the IMS program responding to calls by the IMS program and initiating the one or more IDS operations necessary to satisfy the request given. Additionally, the emulation routines provide the appropriate information that the IMS program would normally expect to receive and operate in its original environment. Thus, the logic of the program is maintained in this manner.

FIG. 3b illustrates diagrammatically the organization of memory 300 during the execution of user IMS programs. As seen from the figure, the memory 300 has resident, the various modules which comprise the operating system and IDS modules. Additionally, the memory stores the emulator routines while the data description tables and user IMS program are stored in a slave program area in accordance with the organization described in U.S. Pat. No. 3,618,045. The IDS data base representative of the files which have been previously converted reside on disk storage as illustrated diagrammatically by FIG. 3b. FIG. 3e illustrates diagrammatically a number of the emulator routines used to process an IMS data base call as described herein in greater detail. The various modules which comprise the routines of FIG. 3e are illustrated in greater detail in FIGS. 6a though 6s. FIG. 3f illustrates in further detail those emulator modules which can be referenced by the particular module of FIG. 3e.

Before describing the operation of the system of the present invention, the organization of the set of tables which make up the PSB structure stored in file 924 will be discussed in connection with FIG. 4. The table organization is illustrated by the data structure diagram of FIG. 4. Referring to the figure, it is seen that the PSB structure comprises a number of definition tables, each including a plurality of entries and referenced by the named entries listed next to the different lines in the figure.

The PSB definition table exists for each program and contains a number of half word (i.e., 18 bit) pointers which serve to identify the program as an IMS program which is going to utilize the emulator routines. The "PSB" is an IMS term which stands for program specification block and is a table which is generated by an IMS utility routine. The pointer contents of the PSB table enable it to reference all of the tables within the structure.

The first table referenced is the program control block (PCB) definition table. The system contains a PCB definition table for each data base which the program is going to reference. As explained herein, the table contains information which points to all of the segments or in "IDS terms" to all of the records the program can reference. In addition, it contains information indicating the permissions the program has with respect to those records.

The PCB definition table points to two groups of items which do not have any meaning in the IMS terms. These are the SSA table and qualification table. Both the SSA table and qualification table are completely empty at the time of PCB translation. There is no data stored in either table until the user program is executed. The data stored in either table is dependent upon a call at a given time. This is in contrast to the rest of the tables in which the information contained therein remains constant through program running, the tables having been loaded by the translator. The SSA table contains information for the segment involved in a call required for qualification criteria if any, information indicating the operation to be performed in connection with the call (e.g., move, etc.), when it wants an IMS command code set, etc. The Qualification table contains information further specifying the type of qualification.

There is a segment definition table for every segment the program can reference. A segment corresponds very closely to an IDS record. The segment definition table includes information such as the name of the segment, the permissions the program has against the segment, what kind of segment it is, what its equivalent IDS record is, if any, and a pointer to the equivalent IDS record if it exists. As seen from FIG. 4, the segment definition tables serve as the central point in relation to the rest of the tables. The major tables that it points to include the PC definition table. This table includes information which relates the segments to their children and to their parents, as indicated by the two lines. Since the contents primarily serve to define the IMS tree structure in terms of a table, the actual data content is not particularly important to the present invention. The segment definition table also points to a key record table which contains the keys important to the user program. These are the: IMS keys which in IDS terms correspond to fields which the program can inquire against. That is, the program uses the keys to qualify the retrievals it makes. The key definition table contains such information as the name of the key, the length of the key, where it starts in the record.

The logical segment (LSEG) table pointed to by the segment definition table is complex. It was included to handle those situations where the IMS segment is not equivalent to the IDS record. For example, in an IMS system, it is possible for a segment to be composed of more than one IDS record. The logical segment definition table contains information in the form of how the one segment is mapped to multiple IDS records.

The last table is the logical chain (LCHN) definition table which provides compatibility with the IDS data base system. It is referenced in situations where there is an IMS segment which can reference more than one IDS chain. The table ensures the integrity of the data base by specifying where a particular segment is involved in a number of chains. This is necessary in order to enable a segment to be deleted or added and still ensure that the IDS data base does not contain invalid records or include broken chains.

The various octal codes specified in each of the tables are employed for integrity checking purposes. Each unique code identifies the particular table and it is checked to verify that the correct table is being referenced at any given point in time. This arrangement is usually employed in IDS data base systems. The PSB table is arranged to contain a pointer which points to the first PCB entry which in turn points to the next PCB, etc., until finally the last PCB entry contains a pointer pointing back to the PSB table thereby providing a ring. This technique is used throughout all the tables. For example, the PCB table through the process chain entry will point to the first segment definition table which will in turn point to the next segment definition table, etc., until it points back to the PCB table. By including pointers within the tables which point to other tables, this in effect provides a way of structuring an in core data base. It can be said that in general, the arrangement is similar to IDS chains which are used in connection with the translator of FIG. 2. The arrangement allows you to run programs originated to operate with IMS data bases to be run on the system of FIG. 1. The actual information contained within the tables makes the established structure specific to one individual IMS data base. Thus, the generalized structural arrangement of the tables in accordance with the present invention allows any IMS data base program to be run on the system of FIG. 1.

FIGS. 5a through 5h illustrate the formats of each of the tables of FIG. 4. FIG. 5a illustrates the format of the PCB Definition Table. Each PCB table includes 8, 36 bit words which are coded as follows:

FIG. 5b illustrates the format of the Segment Definition Table. Each table includes 13, 36 bit words which are coded as follows:

FIG. 5c illustrates the format of the Key Definition Table. Each table entry includes 5, 36 bit words, each of which are coded as follows:

The P-C Definition Table has the format shown in FIG. 5d. Each table entry includes 4, 36 bit words, coded as follows:

The L segment Definition Table has the format shown in FIG. 5e. Each table entry includes 5, 36 bit words coded as follows:

FIG. 5f illustrates the format of the L Chain Definition Table. Each table entry has 5, 36 bit words coded as follows:

The SSA Table has the format shown in FIG. 5g. Each table entry has 10, 36 bit words coded as follows:

The last table which corresponds to the Qualification Table has the format shown in FIG. 5h. Each such table entry has 4, 36 bit words coded as follows:

The function of each of the emulator modules of FIG. 3e will be described. The first module is designated CBLTDLI. This module is the common entry for all IMS Data Language/I call statements. It directs the interpretation of the call statement and its arguments/parameters in addition to insuring that the proper data base manipulating modules are invoked for the various IMS data base operation calls such as get unique (GU), get next (GN), get next within parent (GNP), insert (ISRT), replace (REPL), and delete (DLET). The functions performed by each of these modules are as mentioned above.

Also mentioned previously, the results of the above basic IMS functions can be modified by including coded arguments (command codes) in the appropriate fields in the segment search arguments of the IMS call statement. The significance of the various command codes D, F, L, N, P, U, V, and C are given in the glossary. Accordingly, the input arguments to the CLBTDLI module in addition to including optional segment search arguments describing the segments to be manipulated are coded to include the IMS function to be performed, the PCB describing the data base to be used and the user's I/O area.

The module as illustrated in greater detail in FIG. 6a produces the following results:

(1) returns a status code in the user's PCB indicating the successful or unsuccessful performance of the function;

(2) modifies the segment level and segment name fields in the PCB to reflect the current segment;

(3) updates key feedback length and key feedback area to reflect the concatenated IMS key of the current segment;

(4) stores the segment's data portion in the user's I/O area after a get type call and leaves the area unchanged after an update tupe call; and

(5) causes requested operation to be performed on the data base.

As seen from FIGS. 3e and 6a, the CBLTDL module invokes each of the modules shown. The CHKFNC module, shown in greater detail in FIG. 6b, is operative to validate the function argument codes supplied by the user program. The module produces the following results:

(1) Sets a validity switch to indicate whether or not the function was a legal one; and

(2) Assigns a numeric code to represent the specific function such as zero for get unique (GU), 1 for get hold unique (GHU), etc. As illustrated in FIG. 3e, the CHFMC module does not call any other module.

The ISCODE module shown in greater detail in FIG. 6c is operative to scan the command codes for a given segment search argument (SSA). This module receives input arguments, codes designating the SSA to be scanned and the character position in the SSA at which the command codes begin. The results produced by the module are as follows: Modifies the SSA table to store the command codes included in the input segment search argument; stores information indicating the character position which signified the end of the command codes; and, sets a validity switch indicating whether or not the command codes were syntactically valid. The ISCODE module as illustrated by FIG. 3e does not reference further modules.

The PERMIS module shown in greater detail in FIG. 6d determines whether or not the user program has the proper sensitivity permission to access the requested segment. This module receives the address of the segment search argument table for the requested segment and sets a validity switch to indicate whether or not the user program has the proper permissions. The PERMIS module does not call any other modules.

The ISFLD module shown in greater detail in FIG. 6e is operative to scan a segment search argument for isolating and verifying for accuracy all of the IMS key fields used in the segment search argument. The module receives input arguments coded to designate the segment search argument to be scanned and the character position in that argument at which scanning is to begin. The module is operative to produce the following results:

(1) Stores in the argument table any qualifiers found in the argument;

(2) Stores in the qualification table the coded form of the qualifiers along the comparison operators, Boolean codes in search of values; and

(3) Sets a validity switch indicating whether or not the key fields scanned were syntactically correct. Similar to the other modules, the ISFLD module does not call any other modules.

The BLDTAL module shown in greater detail in FIG. 6g builds "tally words" and Extended Instruction Set (EIS) descriptions used by the host system for segments which are to be moved into or out of the user's program's I/O area by the call. The module receives as input arguments, the addresses of the SSA tables. The module produces as output results the tally words and EIS descriptors for each segment to be moved which it places in the appropriate place in the SSA table. As seen from FIG. 3e, the module is required to call no other modules, but returns control back to the CBLTDL module.

The GU module, shown in greater detail on FIG. 6u, performs the main processing for the IMS function get unique. The module receives as input arguments, the hierarchical level of the segment requested in the call and the contents of internal tables which have been constructed to reflect the call. The module produces the following results:

(1) Stores the results of an attempt to locate the requested segment in a common position in the internal tables;

(2) Where the attempt is successful, internal tables are updated to reflect the "currency" of the requested segment and the moving of the segment contents to the user's I/O area. As seen from FIG. 3e, the GU module calls the two modules PTCHGU and FNDUNQ.

The MOVEIO module illustrated in FIG. 6a performs the key switching specified by the IMS handling of logical segments in the user's I/O area. This module receives as input agruments, the SSA table with the assumption that the data portion of the logical components is available in the emulator I/O area for a retrieval function or in the user's I/O area in the case of an update function. The module produces the following results:

(1) For a get function involving a logical segment the user's I/O area will have the following format--logical parent key, logical child data, logical child key and logical parent data;

(2) For an update function involving a logical segment the emulator I/O area will contain information having the following format--logical child key, logical child data, logical parent key and logical parent data; and

(3) For physical segments, the module takes no action. As seen from FIG. 3e, the module returns control back to the calling module and calls no other modules.

The next module is USRPCB, shown in greater detail in FIG. 6n, which is operative to place values indicating the results of an IMS call into the user program's PCB area. These values include: status code; segment name; segment level and key feedback area. The module receives as input arguments, the address of the user's PCB area and the PCB definition for the data base just referenced. The module produces as output results values outlining the results of the last IMS call as mentioned. As seen from FIG. 3e, the module is required to call no other modules, but returns control back to the CBLTDL module.

The next module PTCHGU, shown in greater detail in FIG. 6i, determines the hierarchical level at which retrieval should begin. In addition, the module examined the qualification table isolating the retrieval specifications which can be satisfied by a single record. The module receives as input arguments, the hierarchical level number of the lowest level segment in the IMS call. The module is operative to produce as output results:

(1) The level number at which further retrieval should begin which is the lowest common level between the call and the current data base position;

(2) Marking the search argument tables for uniquely qualified segment search arguments. As seen from FIG. 3a, the PTCHGU module does not call further modules, but returns control back to the CBLTDL module.

The next module FNDUNQ, shown in greater detail in FIG. 6j, appears as the main work routine for processing a get unique call. It is operative to cause the correct record(s) to be retrieved and to update the user program's PCB to reflect the identity of the segments found. The module receives as an input argument, the level number at which retrieval should begin. The module is operative to produce the following as output results:

(1) Signals indicating an attempt to find the requested segments;

(2) Updating the user's PCB to reflect the results of the attempt; and

(3) Movement of the found segments to the user's I/O area.

As illustrated by FIG. 3e, the FNDUNQ module is operative to reference the modules CLEAR through MVESEG.

The next module is the CLEAR module shown in greater detail in FIG. 6k. This module initializes the "currency" words in the segment definitions contained in the current PCB. The module receives as an input argument the level number for the lowest level segment whose currency is to be retained. The module produces as output results the setting of the currency words to zeros contained in the segment definition segments other than the input argument and its parents. As seen from FIG. 3e, the CLEAR module is not referenced by other modules, but returns control back to the FNDUNQ module.

The next module referenced by the FNDUNQ module is the SATGU module shown in greater detail in FIG. 6e. This module is operative to perform the retrieval against a data base for a get unique call (GU). It attempts to satisfy the request for the segment search argument for one particular level specified in the call. The module receives as an input argument the level number to be satisfied. The module produces as output results the following:

(1) Signal indications of an attempt to find the requested segment--if found, it will be the current segment and the current IDS record; and

(2) The setting of a validity switch for indicating whether or not retrieval was successful.

As seen from FIG. 3e, the SATGU module is able to call modules ID AREA through UPDATE.

The FIXPCB module, shown in greater detail in FIG. 6o, is operative to modify fields in the PCB definition tables to reflect the segments most recently retrieved. Since the module works entirely from the emulator's common area and definition tables, it does not receive any input arguments. As mentioned above, the module is operative to produce the modification of the current PCB definition table to indicate the identity of the current segment. As seen from FIG. 3e, the FIXPCB module is not required to call further modules, but returns control back to the FNDUNQ module.

The other modules referenced by the FNDUNQ module correspond to the CCODE module and MVESEG module shown in greater detail in FIGS. 6p and 6a respectively. The CCODE module processes command codes (D) and (P) after the completion of a get call. The module receives as an input argument the highest level number for which the segment was retrieved by the call. The module is operative to produce the following results:

(1) For a (D) command code, it moves the contents of the segment at the level to the user program's I/O area; and

(2) For a (P) command code, the module sets the parentage call in the PCB definition table to indicate that the segment at that level is to be the current parent.

As seen from FIG. 3e, the CCODE module can either call the MVESEG module or return control back to the FNDUNQ module.

The MVESEG module shown in greater detail in FIG. 6q moves the data portions of the most recently accessed segment to the user program's I/O area. This module is similar to the CCODE module and works entirely from the emulator's common area and the definition tables. Hence it receives no input arguments. The MVESEG module can return control back to the FINDUNQ module or call another module designated .QETD, not shown. The .QGETD module takes the form of a standard IDS module which functions to retrieve a record through its reference code (i.e., page and line number). The manner in which this module operates is described in the aforementioned and publications and patent applications mentioned hereinafter.

The group of modules referenced by the SATGU module mentioned above will be discussed briefly. The IDAREA module will not be discussed in greater detail herein since it usually takes the form as a user coded routine which determines the correct area for a segment which may encompass or "participate" in more than one area. For the purpose of the present invention, this module can be considered conventional in design.

The next module is .QGET. As indicated in FIG. 3e, this module is an IDS module which performs in the fashion similar to the IDS function retrieve record-name. This module searches the records and one chain (either a normal IDS chain or an area chain) looking for a record that satisfies the segment search argument. The module receives as input arguments the address of the master definition of the chain to be searched together with the address of the SSA table which references the values for which the search will be made. The module is operative to produce the following results:

(1) store a zero in the IDS cell error reference to indicate that a record was found satisfying the search criteria while a non-zero indicates that no record was found; and

(2) setting of all currency indicated to reflect the finding of a record (all indicators remain in their original status if no qualified record can be found).

The .QUGET module can return control to the SATGU module as shown in FIG. 3e or referenced in further modules not shown.

The last two modules referenced by the SATGU module correspond to .QGCUR and UPDATE module shown in greater detail in FIGS. 6m and 6n respectively. The .QCUR module checks the segment search argument to determine whether or not the current segments satisfy the supplied search criteria. The module receives as an input argument the contents of index register 3 (.times.3) which contains the address of the segment search argument table to be checked. The module produces the following results.

It sets the error-reference IDS communication cell to indicate the results of the check wherein a zero indicates success while a non-zero indicates that the search criteria had not been met.

The module as indicated by FIG. 3e can return control to the SATGU module. It also can call a standard IDS subroutine for retrieving a record based upon the reference code.

The UPDATE module updates the area chain tables for all area chains in which the current record participates. That is, "updating a chain table" means that the chain pointers in the table (current, next, master, and prior) are replaced by the current record and its pointers. The module receives as an input argument the contents of the next register 4 (.times.4) which points to the segment definition table. As seen from FIG. 3e, this module returns control back to the SATGU module.

The above description indicates the basic operations performed by each of the modules of FIG. 3e and the input parameter requirements.

For a more complete understanding of the preferred embodiment of the present invention, the following example will be considered in connection with the detailed flow charts of FIGS. 6a through 6s. For further information on the specific modules, reference may be made to the source listings included in the attached Appendix. The listings are for the most part written in Honeywell 6000 assembly code language described in the publications previously cited.

FIG. 3c outlines a sequence of user COBOL program statements for having the host processor determine whether or not the file of a "member" is contained within the data base. In general, the user program includes a data base GET UNIQUE call causing the host processor to find out if a new record or "subscriber" exists in the data base files 918 of FIG. 2. If it does exist, the user program causes the host processor to move its contents back to the program's working area so that the program can print it or perform any other operations it desires.

In greater detail, as mentioned, every IMS data base call is received by the CBLTDL module of FIG. 3e which is operative to examine the call to find out the type of call. The user program or calling program includes four arguments (i.e., get unique, member PCB, I/O area and MPO5ROOT-SSA). These arguments are passed to the CBLTDL module. Of course, the module is arranged so that it can accept more or less than four arguments. In the host system, every program call to the operating system is translated into the following subroutine: (1) there is a branch to the CBLTDL module; (2) there is a transfer around all of the arguments; (3) there is some error linkage word in case of a problem; and (4) the addresses of all of the arguments. Generally, the number of arguments is determined by subtracting addresses. That is, following the transfer statement, there is another transfer around all of the arguments. By taking the number specified in the last transfer and its address, subtracting from it the address to which there is a transfer, the number of arguments can be established. It will be understood that the manner by which the module determines the number of arguments can be considered conventional. Here, it corresponds to that of the operating system. The CBLTDL module is then operative to initialize to zeros the different areas contained within the segment search argument table and the qualification table of FIG. 4. At that time, CBLTDL module is operative to establish the SSA table and qualification table addresses. These addresses are derived from the information contained within the segment search argument (i.e., from the character positions). It will be appreciated that the segment search argument is a string of characters (BCD) arranged in the following format.

The eight segment name characters specify the type of segment. The command code characters when included augment or qualify the data base operation or function. A list of these codes is given in the glossary. The field name provides an eight character key field in the specified segment and the comparative value characters provide a value which must be equal size and type to the field with which it is being compared.

Next, the module references the CHKFNC module for examining the call parameters to determine whether or not the call is "legal". If it is legal, the CHKFNC module is operative to convert the call into a numeric code and pass it back to the calling CBLTDL module.

As seen from FIG. 6b, the CHKFNC module takes the call parameter code and performs a type of table lookup operation using this to reference the search function table included as part of the PCB located in working storage. Since the PCB should contain the segment search arguments as discussed earlier, the CHKFBC module is operative to set the validity switch bit to a binary ZERO followed by setting the function code included by the CBLTDL module in the call equal to the position in the table (i.e., translates code into "O" for GU). If for some reason the argument is not found, the module sets the switch to a binary ONE. The CHKFNC module then returns control back to CBLTDL module. The signaling of an invalid function causes the CBLTDL module to insert the appropriate IMS error code into the first entry of the PCB table of FIG. 5a. The meanings the codes have to the IMS user program are set forth in the glossary. It will be appreciated that these codes provide the same status information to the program that it would have received when executed in its original system.

As seen from FIG. 6a, next the CBLTDL module tests to determine whether or not the processing of the segment search arguments has been completed. The host processor maintains a count of the number of SSA's in working storage so that it can be referenced by other modules. Initially, the CBLTDL module sets the SSA count and the count remains at that value until the processing of the call is completed. Before exiting, as seen in FIG. 6a, the module puts the SSA count into working storage. The SSA's in the last call normally provide for a look backward capability required for processing REPL and DLET commands.

Since it is assumed that processing of the SSA's is just beginning, the CBLTDL module next tests to determine if the segment name in the SSA is valid. This was stored in the first part of word 0 of the SSA table of FIG. 5g. It does this by checking its length and coding. From FIG. 3c, it is seen that the name is MPO5ROOT and that it is eight characters in length. The detection of the asterisk symbol can be used for verifying the length of the segment name.

Since the name is valid, the CBLTDL module next references the ISCODE module fo FIG. 6c.

Referring to FIG. 6c, it is seen that this module sets the validity switch indicator bit to zero and clears the table of command code settings.

In greater detail, from the format discussed previously, it is seen that the asterisk symbol denotes the beginning of the command code field within the SSA. In this example, the field contains dashes which indicate that this is a "null" call command requiring no action. As seen from FIG. 6c, the ISCODE module takes the value indicating the character position within the SSA and increments the value by one upon detecting the asterisk character symbol. It continues incrementing this value until all of the null character codes have been processed. Since there were no command codes present, the ISCODE module returns control back to the CBLTDL module.

As seen from FIG. 6a, the CBLTDL module next references the PERMIS module of FIG. 6d. This module tests the function code previously stored in working storage by the CHFNC module and tests it. Since it is a get unique operation, the module takes the segment name MPO5ROOT and references the first segment definition table entry of FIG. 5b to determine whether or not the user program has the correct permission (i.e., G permission=1) to perform the indicated operation. When permission is not granted, the module sets the appropriate error status in the PCB entry. Assuming that permission has been granted, the PERMIS module returns control back to the CBLTDL module as shown.

As seen from FIG. 6a, the CBLTDL module next references the ISFLD module of FIG. 6e. This module isolates the IMS unrecorded BCD characters stored in the qualification statement field and verifies their correctness. Also, the module stores the pertinent characters in the first qualification table entry of FIG. 5h.

In greater detail, the ISFLD module detects the parenthesis character symbol in the program of FIG. 3c. This signals the start of the qualification statement field which includes the eight character key field "MPROOTKY" followed by a space designated by a triangle character symbol. The module adds 8 to the character position count to determine whether the field found is in the specified segment. Since it specifies a key field, the result of the test is positive.

Next, the module isolates the relational operator (i.e., RO) and increments the character position by 2. The operator (RO) is an = sign which means that the key must be equal to the key specified.

Since the = sign is a valid symbol, the result of the next test is positive. The key definition address and operator are stored in the first qualification table entry of FIG. 5h as indicated. The qualifier count in the SSA table of FIG. 5g is fetched by the module and incremented by one. As mentioned, the SSA can contain from 1 to 255 characters. In the present example, this field contains the root value which is specified as being 9 characters in length which is the length of unique identifiers for subscriber roots.

The ISFLD module, as seen from FIG. 6e, stores the qualification table address in word 9 of the first SSA table entry (FIG. 5g) and stores the address of the field or comparative value in to word 3 of the first qualification table entry. As seen from FIG. 6e, the module sums the character position value and the length of the field (9 characters) and examines the character code at that position. From FIG. 3c, it is seen that this code corresponds to a right parenthesis character symbol. This signals the end of the qualification field and that the module has completed its processing of the SSA. It will be noted that the remaining operations shown in FIG. 6e are performed when the SSA contains other qualifiers signaled by a valid connector character symbol (i.e., * or +). Since there is no connector character, the boolean code in word 0 of the qualification entry remains 0 as indicated in FIG. 5h. Summarizing the above, it is seen that the modules CHKFNC through ISFLD load the SSA and qualification table entries of FIGS. 5g and 5h with values obtained from the user program of FIG. 3c. As mentioned, by contrast the remaining tables are loaded with appropriate values at translation time. These values are indicated in the attached Appendix.

At this time, the host processor of FIG. 1 has evaluated the get unique data base call, established that the call is valid and that there have been no errors. The emulator modules now proceed to find the record the user program has requested.

Referring to FIG. 6a, it is that the CBLTDL module tests to determine whether this is the first SSA. Since it is the first SSA, the module next tests to determine whether all of the SSA arguments have been processed. The result of this test is also positive and the module tests to establish whether there were any SSA's. Again, the result is positive.

The positive result of the last test causes the CBLTDL module to call the MISSING module of FIG. 6f. This module essentially checks to see that the user program has included the correct information in the call in conformance with IMS procedure. For example, a user program cannot request two segments at the same level in a call. Also, the user program must request the segments in the proper hierarchical sequence (i.e., level 1, level 2, . . . , etc.). As mentioned, the IMS structure can be viewed as a hierarchy of fixed length segments emanating from a root segment for each data base. In the IMS system contemplated, the data base can include up to 255 segment types arranged in a maximum of fifteen levels and each segment type may occur any number of times or not at all under a given root. Thus, the module operates to enforce the IMS data base requirements. Also, the MISSING module is required to provide the level number information in the segment definition table entry for all levels above the level requested.

In the present example, the user call specified the root segment which corresponds to the first level. Accordingly, the MISSING module need only insert the level number information into the first segment definition table entry of FIG. 5b.

Referring to FIG. 6f, it is seen that the MISSING module is operative to compare the current level and previous level values stored in the PCB definition table and segment definition table. Assuming the user call is correct, the result of this test should be negative which causes the module to set the work level value equal to the previous level-1 and fetch the address of the segment definition table entry from the SSA table entry of FIG. 5h.

Next, the module compares the current level with the work level and the result is positive which causes the module to reference the FIND-PARENT "macro" of FIG. 6f. The term "macro" is used in its conventional sense to denote a source language instruction which calls in a special routine to perform a particular function (e.g., find the parent of the segment).

Briefly, the FIND-PARENT macro tests to determine whether the named segment has a parent. In the present example, since the segment specified is the root segment and has no parent, the MISSING module returns control back to the CBLTDL module. That is, the macro decrements the level number (i.e., 1) by one which causes the result of testing the current level to be positive.

Referring to FIG. 6a, it will be noted that when the "hierarchy" is correct, the MISSING module causes the CBLTDL module to test for the presence of command code C. However, if user program provided an incorrect call, the CBLTDL module as seen from FIG. 6a enters the appropriate error status code into the PCB.

The C command code as described in the glossary denotes the presence of a concatenated key. Since there were no command codes in the call, the result of this test is negative. Next, the CBLTDL module sets the SSA count in working storage and then calls the BLDTAL module of FIG. 6g.

As mentioned previously, the BLDTAL module "builds" the addresses (tally words and EIS descriptors) necessary for the host processor to fetch the segment from the IDS data base. In the host processor, addresses must be provided indicating where the segment is, where it is to be moved, etc. The addresses are discussed in greater detail in the aforementioned references.

Referring to FIG. 6g, it is seen that the BLDTAL module generates a "tally word" for each SSA using the I/O area address, starting character and segment length information obtained from the segment definition table of FIG. 5b. The module then stores the tally word in the SSA table entry of FIG. 5g. The module also generates the appropriate descriptor information in a well known fashion.

In the present example, after generating the tally word for the root segment, the BLDTAL module returns control to the CBLTDL module. As seen from FIG. 6a, the CBLTDL module next calls the appropriate one of the modules GU through DLET to perform the actual data base operation. Since the operation specified by the user program of FIG. 3c was a get unique operation, the CBLTDL module calls the GU module, shown in greater detail in FIG. 6h. The GU module examines the call and the contents of the SSA and qualification tables to determine what levels in the IMS hierarchical structure is the segment located. In the present example, as mentioned, the user program call specified the root or first level segment.

Referring to FIG. 6n, it is seen that the GU module operates to turn off or reset the hold flag indicator in the first entry in the PCB definition table of FIG. 5a (bit position 17 of word 0). This indicates that the IMS data base operation is not a "hold" operation which was described previously. As seen from FIG. 6h, the GU module then calls the PTCHGU module of FIG. 6i.

As seen from FIG. 6i, the PTCHGU module is operative to make changes to the SSA and qualification tables which specializes them for the get unique call which is to be processed by the other emulator modules. In greater detail, the PTCHGU module performs a number of tests involving the user's supplied level information stored in the PCB definition table entry. As from FIG. 6i, the first test the module makes determines whether the level number is less than 2. Since the level here is the first level, the module switches the common-level information to zero and sets the variable I=1. Next, the module tests the value of I to determine whether it is greater or equal to the lowest level. Since it is in this example, the PTCHGU module returns control back to the CBLTDL module. The other tests performed by the PTCHGU module enable the modules to sequence in effect through the hierarchical structure which is characteristic of the IMS data base.

As seen from FIG. 6h, the GU module then calls the FNDUNQ module shown in detail in FIG. 6j. This module performs the necessary data base retrieval operation. Referring to FIG. 6i, it is seen that the FNDUNQ module first transfers control to the CLEAR module of FIG. 6k. This module insures that there is no incorrect IDS currency information contained within the PCB and segment definition tables for the named segment. That is, it validates the currency information contained in the PCB definition table and segment definition table.

As seen from FIG. 6k, the CLEAR module first computes the address of segment definition table for the input level (level number) stored in the PCB and segment definition table entries. This information is passed to the CLEAR module by the calling module. The CLEAR module saves the level number and then sets the variable I=1 in a location in working storage for that module. It then sequences back one level by incrementing the stored value for I. The module then tests to determine whether it is already at the top level of the hierarchical structure. Assuming that it is, the module then starts at the PCB definition table level and references the GNPRO macro.

GNPRO is a macro used whenever the host processor is requested to find a ROOT segment. The macro eliminates the currency information in all of the segments in the data base which belong to the ROOT segment. In this example, all of the segments in the particular data base definition are cycled through and cleared. Since all of the segments are chained together in a ring structure starting from the PCB, the macro begins its operation at that point. It sequences through the process chain next referencing the segment definition table and clears its currency to ZERO. Upon completing a loop through the process chain, the macro exits from the loop and resets any currencies (here, there would be none). The CLEAR module then returns control back to the FNDUNQ module.

It is seen from FIG. 6j that the FNDUNQ module next sets the work level to equal the start level. It then sets the last unsatisfied segment address into the appropriate word location in the PCB definition table (i.e., bit positions 18-35 of word 3). In this example, this would correspond to the current segment definition address which is the ROOT segment.

The FUDUNQ module then references the SATGU module of FIG. 61. The SATGU module is called once for every level in the hierarchy required for the user program call (i.e., for level requested and all higher levels). In the present example, the SATGU module is called once to locate the ROOT segment. The module looks at the SSA and qualification tables, information describing the physical characteristics of the data base, determines the type of IDS data base it is, that is, its area, etc., as explained herein. In greater detail from FIG. 61, it is seen that the SATGU module first sets the validity switch located in segment definition table to a binary ZERO. It then tests to determine whether the named segment is a logical segment by testing the contents of the segment definition table entry. Since it is not a logical segment, the SATGU module then tests to see if the segment has been qualified (tests the state of indicator). In this example, the segment has been uniquely qualified by the call. Since the state of the uniqueness indicator bit stored in the SSA table had been set, the SATGU module then places the tally word in the IDS field definition table entry of FIG. 5b. This information identifies a physical area of the data base disk file storage 918 of FIG. 2.

Next, the SATGU module tests the segment definition table to see whether this is a multiarea segment. In the IDS data base, the user program can access a data base composed of up to 64 areas. This module provides or assigns the area in working storage required for the segment. That is, the segment length stored in the segment definition table entry is defined by the user at the time the data base is loaded by the host processor. When the segment encompasses more than one area (i.e., a multiarea segment), the SATGU module calls the user program IDAREA module.

Assuming that in this example, the segment involves a single area, the SATGU module next references the IDS .QGET module. As mentioned, this module is an IDS module which performs in IDS terms a "retrieve function". This module is one of the IDS primary subroutines which performs the actual operation upon the data base external to the host processor. The operations performed by the .QGET module are described in the previously referenced publications in addition to the publication "GE625-635 Integrated Data Store Flow Charts", publication no. CPB-1332, by General Electric Company, copyright 1966. It will be appreciated that such operations could also be performed as described in the following patent applications:

(1) "Data Base Instruction Find Direct" invented by Benjamin S. Franklin et al bearing Ser. No. 535,392, filed Dec. 23, 1974, now abandoned, and assigned to the same assignee as named herein; and

(2) "Data Base Instruction Find Owner" invented by Benjamin S. Franklin et al bearing Ser. No. 588,434, filed June 19, 1975, now U.S. Pat. No. 4,025,901, and assigned to the same assignee as named herein.

As seen from FIG. 61, following the retrieval of the segment by the .QGET module, control is returned to the SATGU module. The module then examines the results of the call. Since the segment was found and call was satisfied, the testing of the successful indicator is positive. Next, the SATGU module tests to see if there are any more qualifiers. That is, the SATGU module determines whether the segment was qualified on more than one key field by examining the qualifier count contained in the SSA table. If the module determines that the user program supplied more than one key, the module calls the .QGCUR module. This module, shown in greater detail in FIG. 61, again checks the qualifier count and when greater than 1, the module checks the current record to determine if it still satisfies the other keys besides the unique one.

In this example, since there are no other keys except a single key, the SATGU module is operative to call the UPDATE module of FIG. 6m.

The UPDATE module is operative to update the IDS currency information to ensure that the record is current with all of the chain tables. This is done to make sure that both the emulator modules and IDS modules reference the same records.

As seen from FIG. 6n, the UPDATE module references the PC definition table for the segment's parent and calls the AREA macro. The marco performs the tests indicated which result in the building of the appropriate tally word information and the altering of the next, master, and prior pointers as required. The UPDATE module then returns control back to the SATGU module. As seen from FIG. 61, the SATGU module stores the IDS currency information in the segment definition table and work area for further reference. It then returns control back to the FNDUNQ module. As seen from FIG. 6j, the FNDUNQ module tests to determine whether or not the SATGU module found the record whose key was equal to the key provided by the user program. Since it did, the FNDUNQ module then calls the FIXPCB module of FIG. 6o.

The FIXPCB module sets the appropriate conditions in the user program's PCB area to indicate that the particular record requested was located, indicate the type of record it was (MPO5ROOT) and store cerrtain information in different areas. The important area in this instance is the so-called feedback area in which the key(s) of the current record are stored. This enables the FIXPCB module to move the stored key values (i.e., ROOT value) back into the user program's PCB area.

As seen from FIG. 6o, the FIXPCB module references the PCB definition table to fetch the address. It then sets the IDS reference code of the segment in the PCB definition table entry to the current reference code stored in the IMS common area (i.e., area of store). Also as illustrated in FIG. 6o, the FIXPCB module sets the current level number in the PCB definition table entry to the level contained within the current segment. It also sets the IMS status code to ZEROS as indicated (spaces).

Next, the FIXPCB module tests to determine whether the segment has a sequence key. When it does, the module then builds a "tally" for the key field which is stored in the key feedback area. Also, it builds a "tally" for the key field in the current IDS record and moves the field from the IDS buffer to the feedback area. The FIXPCB module then returns control back to the FNDUNQ module of FIG. 6j.

As seen from FIG. 6j, the FNDUNQ module increases the work level value by one and tests its value. Since in this example, the work level was the first level, the result of the test is negative and the FNDUNQ module calls the CCODE module of FIG. 6q. As indicated previously, where the work level is other than the first level, the FNDUNQ module calls the SATGU module the number of times required to obtain the segments for all other levels.

As mentioned, the CCODE module processes any command codes found previously by the ISCODE module. Since there were no command codes, the CCODE module after sequencing and performing tests returns control back to the FNDUNQ module of FIG. 6j.

As a final operation, the FNDUNQ module transfers control to the MVESEG module of FIG. 6q. This module performs the actual transfer of the record to the user program's I/O area. That is, as indicated above, the IDS .QGET module brings an entire IDS page into the main store 922 of FIG. 3b. The MVESEG module takes the record to be moved into the I/O area.

In greater detail, referring to FIG. 6a, it is seen that the MVESEG module makes the tests indicated and builds a description for the segment in the specified user program's I/O area. The module calls another IDS subroutine .QGETD which performs the retrieve direct function which retrieves the record identified by the reference code contained in the direct reference field. The MVESEG module returns control back to the FNDUNQ module of FIG. 6j.

Since retrieval has been completed, the record removed and the PCB updated, the FUDUNQ module returns control back to the CBLTDL module.

The remaining operations to be performed are in the nature of housekeeping or clean-up operations. As seen from FIG. 6a, the CBLTDL module calls the MOVEIO module of FIG. 6r. This module moves the information within the IMS logical segment area as a consequence fo modifications of keys in various records. From FIG. 6r, it is seen that the MOVEIO modules sets the current-level equal to the level number obtained from the PCB. Since the call specified a get function, the MOVEIO module sets the update switch to zero. The result of the test for I greater than current is negative while the test for I=SSA-CNT is positive (level number=1). The module then proceeds to build up the tally for the segment in the user program's I/O area. The MOVEIO module then tests whether the segment is a logical segment and if a logical segment it performs the modifications to the keys indicated for the logical segment. Since the segment here is not a logical segment, the MOVEIO module tests the update switch and then moves the data from the emulator I/O area to the user program's I/O area. Following that, it then returns control to the CBLTDL module.

As shown in FIG. 6a, the CBLTDL module transfer control to the USRPCB module of FIG. 6s. The module fetches the addresses of the PCB definition table and user's PCB area in order to store the current level number in the user's PCB area. Also, the USRPCB module takes the IMS status code and places it in the "prior" slot in the PCB definition table entry. It also stores the status code in the user program's PCB area.

The USRPCB module then tests the current segment address value. Since the address is not zero, the module moves the segment name (MPO5ROOT) from the segment definition table entry to the user program's PCB area. It also sets the feedback length (FBLEN) to zero. Since the segment found in this example does have a sequence key, the feedback length is arranged to store the key length for starting location. The USRPCB module moves these values to the feedback length word in the user program's PCB. This completes the operations to be performed by the CBLTDL module. Accordingly, the module returns control back to the user program. At this point, the call has been completed, the ROOT segment has been found and moved to the user program's I/O area. Also the status code has been filled in and the call completed.

The user program moves to the next statement which specifies testing the results stored in the PCB. More specifically, the user program tests the status code to see if it equals spaces. If it does not equal spaces, this means that the record was not found. Since in this example the record was found, the status code has the space value which signals the user program that the segment is located in the user program's I/O area. Thus, the user program can now perform the operations it desires with the record.

FIG. 7a shows another example of a user program used to illustrate how the system of the present invention modifies the data base records (subscribers) in response to data base calls included in the program.

It is assumed that the program (replace program) is performing a series of transactions to change names which are incorrectly spelled on the data base of FIG. 7g. The data flow of replace program is diagrammatically illustrated in FIG. 7b. The two point cards contain the changes to be made to the data base by the replace program.

Referring to FIG. 7a, it will be noted that the program in part performs in a fashion similar to the program of FIG. 3c. It finds or reads an input record which is identified by subscriber number corresponding to some number of a given plan (e.g., insurance plan). It retrieves it using the IMS function GU. When the program finds a good member record containing a given subscriber number, it changes the name using the IMS function REPL. The program cycles through all of the input records until it reaches the end. To perform this task, the program includes a procedure division shown. It will also be noted that the program specifies the required information in working storage and a description of the input file containing the records.

FIG. 7g illustrates the data base before the replace program is run and the data base after running the replace program. As shown, the data base includes a series of records, four example records, that contain certificate numbers and names. The changes to be made to the data base involve two of the example records. Specifically, in one record, "SMITHE" spelled with an "i" is to be changed to "SMYTHE". In the other record, "TRAMER" is to be changed to "CRAMER".

In greater detail, each of the two records are retrieved by the emulator modules in the manner illustrated in FIG. 3e. Following retrieval, the emulator modules make the specific changes in the manner illustrated in FIG. 7c. Since the operation of the host processor in performing a GU function was discussed in considerable detail in connection with the first example user program, only the operation of the emulator modules of FIG. 7c will be discussed further herein.

Referring to FIG. 7c, it will be noted that in response to the REPL call, the CBLTDL module in turn calls modules CHKFNC through BLDTAL. These modules operate in the manner described previously in connection with FIG. 6a. From that Figure, it is seen that the CBLTDL module in response to the REPL function now calls the REPL module of FIG. 7d in lieu of the GU module.

In general, the REPL module verifies the correctness of the replace request of the user program, performs IDS journalization and physically replaces the segment(s) in question. The module is "driven" by information contained in the SSA tables, the definition tables and the currency values in the data base.

The REPL module produces the following output results:

(1) If any errors are encountered during the processing of the replace function, the module includes the appropriate status code in the user program's PCB and makes no changes to the data base; and

(2) In the absence of errors, the module physically replaces the segment(s) on the data base and reflects the modification in the IDS journal.

Referring to FIG. 7d, it is seen that the REPL module includes two internal subroutines FLDCHK and REPLACE. The FLDCHK routine makes certain that none of the IMS key fields in a segment have been changed. In IMS, it is illegal to change a key without deleting the segment and storing a new one. Thus, this routine ensures that this IMS procedure is followed by user programs. The REPLACE routine physically replaces the segment on the data base. In doing this, it may call an IDS subroutine .QGETD, but it always calls the module QSBEF which is a journalization subroutine in IDS.

Similar to the CLEAR module, the FLDCHK and REPLACE routines include two macros, "GNCOMP" and "GNMAKE". As indicated, GNCOMP stands for get next definition in the composed-of-chain and GNMAKE stands for get the master definition in the makes-up-chain. These chains were described previously in connection with the tables of FIG. 4. Since they are used primarily for logical segments and are not pertinent to the present example, they will not be described herein.

In operation, as seen from FIG. 7d, the REPL module sets I to a 1 since the hold flag bit in the PCB definition table entry should be set to a binary ONE for a REPL function. Because I should not be greater than 1, the module sets up the segment address to fetch the record. Since this SSA was supplied in the last call (i.e., GU function), the REPL module calls the FLDCHK routine of FIG. 7e.

As mentioned, the FLKCHK routine checks the key fields to ensure that they have not been changed. The routine after establishing there is a key field sets the legal switch indicator to zero. It then builds a "tally" for the key field in the program's I/O area and fetches the currency from the segment definition table of FIG. 5b.

The FLDCHK routine next calls the IDS routine QGETD which actually fetches the key. Next, the routine tests for an error indicating a change in the key. Assuming no error, the FLDCHK routine builds a "tally" for the key field in the buffer. Since the fields in the buffer and I/O area should be the same, the routine tests the LGL-SW indicator and returns control back to the REPL module.

The REPL module tests the state of the validity switch which should be zero and increments the value I by one. Since I is now greater than the SSA count, the REPL module calls the REPLACE routine of FIG. 7f.

As seen from FIG. 7f, the REPLACE routine first tests the permission indicator bit in the segment definition table entry of FIG. 5b. After determining the segment is not a logical segment, the routine builds a tally for the segment, fetches the currency information and then calls the IDS routine .QGETD. Following the fetching of the segment conta.ning the desired record by the QGETD routine, the REPLACE routine then builds a "tally" for obtaining the record in the buffer. It then calls the .QSBEF routine which performs the journalization of the IDS page which is about to be changed.

The REPLACE routine next moves the segment from the user program's I/O area to the buffer and turns on the must write buffer switch. The routine then returns control back to the CBLTDL module. Thereafter, the host processor writes the changed record into the data base producing the result as illustrated in FIG. 7g. The above operations when repeated result in the replacing of the second record.

From the above example programs, it is seen how the host processor is able to process the data base requests included therein. It will be appreciated that only the emulator modules necessary for processing the example calls were described. FIG. 3f further illustrates the organization of other emulator modules for processing other types of calls in connection with the GU function. It will be obvious to those skilled in the art how organizations similar to those shown can be employed for handling other data base functions.

From the foregoing, it is seen how the host system of the present invention provides for the execution of IMS user programs written for execution on a given system having substantially different data base. The system enables such programs to perform operations it performed when executed by the original system. The arrangement of the present invention performs other operations such that the IMS user program can be viewed as still operating in its own data base, employing the same set of rules. This arrangement enables IMS user programs to be run on the host system without having to change or alter the logic of the program in any fashion.

More importantly, the arrangement of the present invention enables the host system to run IMS user programs efficiently preserving the advantages obtained from the user programs as written originally. It will also be appreciated that the emulation control system of the present invention also provides for efficient execution of such user programs taking advantage of the existing data base facilities included in the host system with a minimum of increase in additional apparatus to the host system.

In addition to the above, it will be appreciated that the arrangement allows the host system to run both IMS user programs and IDS user programs and access records of the same data base as part of its normal mode of operation. Other advantages of the present invention will be readily appreciated by those skilled in the art.

To prevent undue burdening the description within the ken of those skilled in the art, a block diagram approach has been followed with a detailed functional description of each block and specific identification of the circuits represented. The individual engineer is free to select elements and components such as registers, etc., from the individual's own background or from available standard references such as those referenced herein.

Also, the exact coding for all modules was not disclosed since it is not believed necessary for an understanding of the present invention. While the invention has been disclosed in terms of "software modules", the invention as mentioned may be implemented in various ways such as by "firmware", hardware or combinations thereof. For example, the macros disclosed and the IDS modules may be implemented by "firmware".

For purposes of completeness, the source listings of the softward modules are included in an appendix. It will be noted that the code listings for the most part are written in the Series 600/6000 Macro Assembler Program (GMAP) language. The assembly code language is described in the publication "Series 600/6000 Macro Assembler Program" by Honeywell Information Systems Inc., copyright 1973, designated by order number 13N86Rev. 2. Other code listings are written in the COBOL programming language which is described in the Series 600/6000 COBOL Reference Manual published by Honeywell Information Systems Inc., copyright 1972, designated by order number B508Rev. 1.

Also, the appendix includes illustrations of the types of values stored in the emulation tables for the examples given and the sources of the values (e.g., IDS tables). In this regard, the appendix also includes the Syntax Definition for DBD and PSB File Generation to facilitate understanding as to how the specific information stored in certain ones of the tables are generated. As mentioned, for the purpose of the present invention, the translators can be considered conventional in design and may take the form of units currently employed in the different data base systems themselves.

The input and output operations that can be specified include the following:

It is possible to modify the effect of a basic IMS function by supplying coded arguments in the appropriate fields in the Segment Search Arguments (SSA's) in any IMS call. These coded arguments, called command codes, are defined as follows:

Part 1--Source Listings for Modules ANLZR through USRPCB.

Part 2--Values Table Used In Examples.

Part 3--Syntax Definition For DBD and PSB File Generation. ##SPC1## ##SPC2## ##SPC3## ##SPC4## ##SPC5## ##SPC6## ##SPC7## ##SPC8## ##SPC9## ##SPC10## ##SPC11## ##SPC12## ##SPC13## ##SPC14## ##SPC15##

Prior to executing an application program using the emulator, DBD and PCB translations must have been generated.

The Database Description (DBD) is the data language used to describe in detail the logical data structure and the Physical storage organization of a database.

The Program Communication Block (PCB) is the data language used to define the relations between the DBD and the User's application program.

When DBD and PCB generations have been successfully completed, the presence of a PSBGEN statement in the PCB will generate a Program Specification Block (PSB) which supplies the identification and the characteristics for the user's program interface.

Source input syntax to DBD and PCB generations is free form. Commas and/or spaces may be used for reader clarification.

Errors encountered during DBD and PCB generations will be printed following the statement line in error. The error line format is: * * * * * * (reason for error)

Each DBD and PCB execution will be processed until the source statements are exhausted, to allow for a complete syntax check of all the statements.

While in accordance with the provisions and statutes there has been illustrated and described the best form of the invention known, certain changes may be made to the system described without departing from the spirit and scope of the invention as set forth in the appended claims and that in some cases, certain features of the invention may be used to advantage without a corresponding use of other features.