Transaction processing in a distributed data processing system

Abstract

A system for processing transactions and a methodology for the design of such a system for enhanced transaction processing across different computing platforms. Transaction orders and transaction data are transferred and stored within the system in a standard, hardware independent format. Data generated as part of a transaction is stored in a circular queue; orders are stored so that they can be accessed by their order number or other key attribute. Nonvolatile memory is used extensively to increase system reliability and data integrity by reducing the chances of data loss due to a system shutdown. Data is stored to nonvolatile memory before pointers to the data are modified to eliminate problems due to pointers pointing to nonexistent data.

Claims

What is claimed is:

1. A transaction processing method for use in a transaction processing system comprising a first processor for processing a plurality of orders, a second processor connected to the first processor, and a controller connected to the second processor, wherein the second processor receives, stores, and controls execution of a transaction associated with the one of plurality of orders, and formats transaction results resulting from the transaction execution, and wherein the controller executes the transaction, the method comprising the steps of:

entering a first order at the first processor;

building a first order record representative of the first order, wherein the first order record comprises:

a record identifier identifying a record type;

a first data structure, the first data structure comprising:

a first data field length;

a first data field, wherein the first data field contains first data; and

a first attribute code identifying the first data field; and

a second data structure, the second data structure comprising:

a second data field length;

a second data field, wherein the second data field contains second data; and

a second attribute code indentfying the second data field;

transferring the first order record from the first processor to the second processor;

storing the firs order record in the second processor with other order records received from the first processor;

retrieving the first order record;

building a controller record comprising a data structure derived from at least one data structure from the first order record;

transferring the controller record to the controller,

executing the first order at the controller;

reporting, from the controller to the second processor; transaction results of the first order execution; and

formatting the traction results as one or more transaction result records, wherein each of the transaction results records comprise:

a record indentifier indentfying a record type;

a data structure, the data structure comprising:

a data field length;

a data field, wherein the data field contains transaction data; and

an attribute code indentifying the data field;

wherein the step of formating the transaction results is performed in the second processor.

2. The transaction processing method according to claim 1, wherein the step of building the controller record comprises the steps of:

scanning the first order record to locate the first data structure; and

storing the first data structure in the controller record.

3. The transaction processing method according to claim 1, wherein the step of executing the first order at the controller comprise the steps of:

scanning the controller record to locate

the first data and the first data attribute; and

processing the first order based on the first data and the first data attribute.

4. The transaction processing method according to claim 3, wherein the step of processing the first order at the controller comprises the step of:

measuring a quality of material transferred.

5. The transaction processing method according to claim 1, further comprising the step of:

transferring the transaction results records to the first processor.

6. The transaction processing method according to claim 1, wherein the step of executing the first order at the controller comprises the step of:

measuring a quantity of material transferred.

7. A distributed data processing system for coordinating a plurality of transaction, including a first transaction involving a transfer of a quality of material, the system comprising:

an order generation computer including order entry means for entering a first transaction order, including data needed to execute the first transaction, and order formatting means for creating an order record from the first transaction order, wherein the order record comprises a record identifier and a plurality of data fields, each data field comprising a data field length, data and a data field attribute code indentifing the data field and wherein one of the plurality of data fields includes an order number;

a transaction processing computer, connected to the order generation computer, for processing the order record, the transaction processing computer including:

nonvolatile memory; and

order control means, connected to the nonvolatile memory and the order generation computer, for receiving from the order generation computer the order record, for saving the order record to a location in the nonvolatile memory, the recording the order number associated with the order record, and for recording the location of the order record; and

a controller connected to the order control means, wherein the controller comprises means for receiving the order from the order control means, order executing means for executing the first transaction data formatting means for creating a transaction data record, wherein the order executing means comprise measurement means for measuring the quality of material transferred and wherein the transaction data record comprises a record indentifier and a transaction data field, the transaction data field comprising a data field length, transaction data captured by the measurement means and a data field attribute code indentifying the transaction data field;

wherein the transaction processing computer further comprises transaction data control means, connected to the nonvolatile memory and the controller, for receiving the transaction data record from the controller, for storing the transaction data record to the nonvolatile memory and for transferring the transaction data record to the order generation computer.

8. The system according to claim 7 wherein the transaction data control means includes data transfer means for monitoring transfer of the transaction data record to the order generation means and for requesting from the order generation means the record indentifier associated with the transaction data record transferred to the order generation means

9. The system according to claim 8 wherein the transaction data record is stored within a block of nonvolatile memory, wherein the block has a block number and wherein the transaction data record transferred to said order generation means is identified by the block number and a relative record number.

10. The system according to claim 9, wherein the transaction data control means further includes processor memory and block image means for maintaining an image of the block in the processor memory, for writing the transaction data record to the block image and for writing the block image to the nonvolatile memory.

Description

BACKGROUND OF THE INVENTION

1. Filed of the Invention

The present invention pertains to the field of transaction processing and more particularly, to a system for enhanced transaction processing across different computing platforms.

2. Background Information

Transaction processing system development has in the past be somewhat of an art. Diverse computing platforms running different operating systems are connected together to form a system. Software developed for these systems has been tuned to the idiosyncracies of the computing platform and, therefore, difficult to port to new platforms. In addition, since each platform uses a different approach to resource management, changes at the system level ripple through the system, creating a maintenance nightmare. An example of an application using a variety of platforms is described below.

In the world of commodities trading margins are low. Profitability for the enterprise depends on the meticulous tracking of orders and the precise measurement of the commodity to be bought or sold. In prior art systems, an order is received and then entered into an order processing computer running a database application. The order is verified and transferred to a minicomputer for execution. The minicomputer is connected via serial communication links to one or more scale controllers; the scale controllers control loading of the commodity into a carrier such as a truck.

Some time later, the truck arrives at the plant to receive the amount of the commodity requested in the order. A worker enters the order number into the scale controller and the order is retrieved from the minicomputer. The worker verifies the order, places the truck onto the scale and fills the truck. The truck driver receives a bill of lading stating the gross weight of the filled truck, the tare weight (the weight of the truck before loading) and the net weight of the commodity loaded. The scale controller also prints the transaction to a printer as required for auditing purposes. Transactions are stored to nonvolatile memory and transferred as they become available to the order processing computer for balancing of the accounts.

Programmers wishing to make changes to the system are required to learn the intricacies of operation of each computer and controller. Minor changes to items such as field length during software maintenance ripple throughout the system, making code development and verification a costly and inherently unreliable prospect.

Attempts have been made to develop processing environments which allow the connection of platforms in a seamless system. One example is the Distributed Automation Environment (DAE) promoted by International Business Machines. However, typically such an environment extends to only platforms produced and supported by that computer manufacturer. In addition, data transfers between systems are restricted to fixed length, fixed position transfers. Changes in system requirements often lead to costly or unwieldy solutions.

It is clear that there is a need for an integrated approach to efficient processing of transactions across different computer platforms. Systems designed according to this approach should be modular to allow reliable maintenance as system requirements change.

SUMMARY OF THE INVENTION

The present invention is a system for processing transactions and a methodology for the design of such a system for enhanced transaction processing across different computing platforms. Transaction orders and transaction data are transferred and stored within the system in a standard, hardware independent format. Data generated as part of a transaction is stored in a circular queue; orders are stored so that they can be accessed by their order number or other key attribute.

In another aspect of the present invention, nonvolatile memory is used extensively to increase system reliability and data integrity by reducing the chances of data loss due to a system shutdown. Data is stored to nonvolatile memory before pointers to the data are modified to eliminate problems due to pointers pointing to nonexistent data.

According to yet another aspect of the invention, keyed variable length records are stored in an index accessible by their keys.

According to yet another aspect of the invention, a system design methodology is disclosed that leads to the development of inherently modular and maintainable systems.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level block diagram of a transaction processing system according to the present invention.

FIG. 2 is a high-level block diagram of an alternative embodiment of a transaction processing system according to the present invention.

FIGS. 3a-f are representations of data and command records formatted according to the present invention.

FIGS. 4a and 4b are flow diagrams representative of the steps a computer goes through in scanning a record according to the present invention.

FIG. 5 is a diagram of a indexed access file according to the present invention.

FIG. 6 is a diagram of a direct data access file according to the present invention.

FIGS. 7a and 7b are flow diagrams representative of the steps a computer goes through in reading from a direct data access file according to the present invention.

FIG. 8 is a flow diagram representative of the steps a computer goes through in writing to a direct data access file according the present invention.

FIGS. 9a and 9b are flow diagrams representative of the steps a computer goes through in positioning the direct data access file at program startup according to the present invention.

FIG. 10 is a high-level diagram of the software architecture for a processing system according to the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

In the following detailed description of the preferred embodiment, references made to the accompanying drawings which form a part thereof, and which is shown by way of illustration a specific embodiment in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention.

FIG. 1 illustrates a high-level block diagram of transaction processing system 10. System 10 consists of a transaction processing computer 12 connected to order processing computer 14, controllers 16.1 through 16.N, keyboard 18, display 20, nonvolatile memory device 22, printer 24 and audit printer 26. Printer 24 is used to print a bill of lading that accompanies each transaction. Audit printer 26 is used to print a record of the transaction to use as an audit trail.

Controllers 16.1 through 16.N are connected to pump control 28.1 through 28.N, respectively. Pump control 28 controls the transfer of the commodity to the carrier. Controllers 16.1 through 16.N are also connected to strain gauge 30.1 through 30.N, respectively, for monitoring the weight of commodity transferred to the carrier. Strain gauge 30 can also used to prevent filling the carrier past a prescribed limit weight.

In operation, order processing computer 14 receives an order for a certain quantity of a commodity. Computer 14 logs the order and then sends it with an identifying order number to transaction processing computer 12. Computer 12 stores the order to nonvolatile memory device 22 and waits for a request for that order number before proceeding further on filling the order.

Requests for orders are entered through keyboard 18 and displayed on display 20. Computer 12 checks the number of the order requested against a table of pending orders. If the order number matches a pending request, computer 12 retrieves the order from device 22 and sends it to the designated controller 16. Controller 16 then monitors the amount of the commodity loaded into the carrier and provides a transaction record indicating the finish of the transaction and amount of commodity transferred. This transaction record is sent to computer 12 where it is stored to nonvolatile memory device 22 and used to generate a bill of lading and an audit trail.

Transaction records stored to nonvolatile memory device 22 are stored in a queue. The least recently received transaction record stored in device 22 is transferred to order processing computer 14. There it is used to close out the order. If computer 14 is unavailable, computer 12 will continue to store new transaction records to device 22. When computer 14 becomes available, transactions are once again sent across, starting with the least recently received transaction record.

FIG. 2 illustrates a high-level block diagram of an alternative embodiment of a transaction processing system according to the present invention. In transaction processing system 40 the audit printer 26 of system 10 is replaced by audit printers 26.1 through 26.N connected to controllers 16.1 through 16.N, respectively.

Regulatory certification requires that processors connected to an audit printer must place code relating to the conversion of a measurement to a weight and the recording of that weight to an audit printer in read only memory. In system 10, computer 12 and processors 16.1 through 16.N must be certified. In system 40, only processors 16.1 through 16.N must be certified. In this application, the controller 16 needed in system 10 can be a less complex, less expensive controller. This makes system 10 the preferred embodiment.

A design methodology is used in the development of the code to implement an application such as system 10. This methodology can be used to construct complex yet elegant transaction processing applications on small computers. This is accomplished by restricting the system developer to the use of a predefined record format in all data transfers and to the use of predefined code primitives in software design. In the preferred embodiment, these primitives are implemented as function calls. Each primitive performs a function that, when combined with the other primitives, permits the construction of a simple yet elegant transaction processing system. A class of primitives is provided for manipulating records. A second class of primitives is provided for storing records in an index. A third class of primitives stores and retrieves records from a queue. In addition, primitives are provided to handle communication between different processors in a uniform manner.

In the preferred embodiment of system 10, orders for a commodity are placed in an order record. They are then stored to an index created in nonvolatile memory 22 where they can be access by a key such as an order number. They remain in the index until requested at keyboard 18.

To process an order, a worker enters an order number at keyboard 18. Computer 12 retrieves the order record associated with the order number, it is verified by the worker and the transaction is executed. Weights related to the commodity transferred and other transaction status are placed into a data record and stored to a queue created in nonvolatile memory 22. Records are stored to the queue in order of arrival. Once the record is stored to the queue, computer 12 attempts to transfer the stored record to computer 14. If computer 14 is busy or otherwise unavailable computer 12 will continue processing orders and storing records associated with those orders to the queue. When computer 14 becomes available, computer 12 transfers records in the order of storage to computer 14.

In the preferred embodiment, communications software primitives on computer 12 and computer 14 are used to transfer an order record from computer 14 to computer 12. A record processing primitive on computer 12 is used to scan the record to determine that it is an order record. An index access primitive on computer 12 is used to save the record into the index and to retrieve it some time later. Communications primitives on computer 12 and processors 16.1 through 16.N are used to transfer the order record to a controller 16. A record processing primitive on controller 16 is used to scan the order record in order to execute the order. Communications primitives on computer 12 and processors 16.1 through 16.N are used to transfer the data records generated as the result of a transaction from a controller 16 to computer 12. A direct data access primitive on computer 12 is used to save the data record to a queue, to maintain the queue and to coordinate the retrieval and transfer of data records from the queue. And communications primitives on computer 12 and computer 14 are used to transfer retrieved data records from computer 12 to computer 14.

The primitives are tied together at the application level using application code. The use of these primitives to insulate the system designer from the hardware is illustrated in FIG. 10. In FIG. 10, controller application code 260 is separated from the operating system 266 by record manipulation primitive 262 and communications primitive 264. The interface from code 260 to primitive 262 and primitive 264 is kept static. Primitives are segmented into a protocol level and a utility level. Code at the protocol level is written in a high level language. Code at the utility level can be written in any level language. In the preferred embodiment, code at the protocol level is written in "C". Code at the utility level is written in assembly language for increased processing speed.

All accesses to controller resources are filtered through either primitive 262 or primitive 264. Changes in controller hardware are hidden from the application code by appropriate changes at the driver and, possibly, protocol level.

In a like manner, application code 270 for computer 12 is insulated from operating system 282 and therefore, its hardware platform by communications primitive 272, direct data access primitive 274, record manipulation primitive 276, index data access primitive 278 and communications primitive 280. These primitives provide all the necessary functions required to build a complex transaction processing system on computer 12.

Finally, in FIG. 10, application code 290 for computer 14 uses communications primitive 292, direct data access primitive 294 and record manipulation primitive 296 to communicate and transfer data to and from computer 12. Code 290 also is shown directly accessing system resources for other application functions. This can be done according to the present invention. However, it is risky because it does tie the application more closely to a hardware platform.

In code developed according to the present invention, the application interface to a primitive is static. Therefore, primitives can be adapted to new hardware platforms without impacting the application code. A computer or controller can be replaced with a different computer or controller and, as long as the new system has the proper compilers, the application code remains unchanged. Changes are only required at the primitive level.

In a like manner, since the primitives are static, changes in application code are limited in their ripple effect. The basic structure of the code still contains tested code. Only the new application code must be tested. The result is a system design that is modular both in hardware and software design and is more easily maintained in the face of changing hardware requirements.

In the preferred embodiment of the present invention the communications hardware is implemented as RS-232 direct connections using a serial communications protocol as described in the American National Standard (ANSI) specification X3.28-1976.

Alternatively, any communications medium could be used. It is up to the system designer to choose the appropriate medium. The choice of medium should not affect the interface to the application code.

The fundamental data structure in a system implemented according to the present invention is a record. The record is a string of data starting with a record identifier identifying the type of record and proceeding with sets of attributes with data and sets of attributes without data (trailing attributes or attribute-only fields) as required. The record identifier can be used to select a software routine to process the record or for routing. Specific data fields are defined by specific attribute codes. Data can therefore be located by the appropriate attribute code.

The format of a record is not rigidly "fixed" beyond the record identifier, but does have a logical order. The record identifier is the first field in the record. The next field is the field length of the first attribute with data. If there is no data in this record, this field length is set to zero.

A record can have more than one attribute with data. The string of attributes with data must be followed by a terminating field length of zero. This permits the construction of long strings of variable length data identified by their attributes.

Attributes with data can be followed by attribute-only fields. A count field is appended to the record string after the terminating field length of zero. This count indicates the number of attribute-only fields in the record. If there are no trailing attributes this count is set to zero.

The length of the record identifier, the attribute, the field length and the count are determined by the system designer. In the preferred embodiment, the length of the record identifier is two bytes, the length of the attribute field is two bytes and the field length and count fields are one byte each. All data, attributes and lengths are stored in a machine independent fashion.

The record identifier and attributes provide hooks for the definition, processing and routing of information. The use of the attribute fields means that data is not fixed to a specific position in the record. Also, since in the record format the length of a data field is stored with the attribute, data length is easily modified. This facilitates change, as neither the position of data nor its length is fixed for a specific data field in an application.

Some different examples using the record format are shown in FIGS. 3a-f. FIG. 3a illustrates the simplest of the records. It consists of only a record identifier. The field length and the count field are both set to zero. This type of record is useful for sending set commands or triggers.

FIG. 3b illustrates a record with no data. One or more trailing attributes are attached to the record to further define the record. This type of record is useful for sending commands with modifiers or for sending status.

FIG. 3c illustrates a record with data. An attribute with data is provided. Note the first 00 terminating the attribute with data field and the second 00 stating that there are no trailing attributes. This type of record is useful for sending data between processors. It could also be used to send an identifier with the record for use in later retrieving the record.

FIG. 3d illustrates a record with more than one string of data. Two different attributes are provided, both with data. This type of record is useful for sending records containing different types of data between processors.

FIG. 3e illustrates a record with both data and one or more trailing attributes. An attribute with data is provided. This type of record is useful for sending data with modifiers, for sending commands containing variables or for sending status with data between processors.

The use of the record format frees the application from a fixed position or fixed data length data format. Data processing applications integrating this format into their data transfer protocols significantly relax the constraint of fixed data length and position.

In the preferred embodiment, commodity orders are formatted in the record format. They include an order number or identifier in an attribute with data field. A representative order is illustrated in FIG. 3f. The order illustrated is simply an example. In the preferred embodiment, an order record is a much more complex record including a customer name field, three or more address fields and the amount of commodity needed.

The use of a record as the fundamental data structure simplifies the transfer of data. By applying this method, data need only be defined at the record identifier level and record identification need only be established once during system design. This method goes beyond quantitative and descriptive data identification (i.e. dollar amounts, part numbers and descriptions). Events, application specific commands, information requests and responses may be defined as records.

In the preferred embodiment, a group of record manipulation primitives are provided to build a record and retrieve specific information from a record. FIGS. 4a and 4b illustrate the steps a computer or controller goes through in scanning a record for a specific attribute in order to extract data from its data field. A single attribute is located per scan. That attribute location may then be used by the application code to extract data from that data field. This simplifies design of the primitive.

The fundamental scanning method makes use of the length and count fields to scan a record. In the preferred embodiment, several function calls use this method to locate attributes or to make lengths and attribute offsets known to an application. The program starts at the label "SCAN" and it is assumed that a function call has been made to locate an attribute. This function requires that the scan start at the beginning of the record or at the record identifier. At 60 an offset index into the record is incremented past the record identifier and points to the first length field.

At 62, the length is saved and at 64 the length is compared to zero. If the length is zero, the end of the key/data fields has been reached. At 66 the offset index into the record is incremented to the count field. The count field follows a zero length field. The logic is then directed to label "S2" of FIG. 4b.

If the length is not zero, at 68 the offset index is incremented to point to the attribute. The attribute follows the length in the key/data fields. At 70 a check is made to determine if the attribute pointed to by the offset index matches the attribute passed in the function call. If the attributes match, at 72 the attribute offset index is set to the offset of the found attribute in the record. The application now has access to the length of the key/data field and the location of the attribute. The function then returns to the application. In the preferred embodiment, a function was written that adjusts the attribute offset to point to the key/data field of interest if the attribute is found. This is not shown in the flow diagram.

If the attributes do not match, at 74 the index offset is incremented by the previously saved length and the length of the attribute field. The index offset now points to the next length field and at 76 it is saved. The logic then loops back to 64 to compare the saved length to zero.

At 78 of FIG. 4b the logic compares the count field to zero and if it is determined to be zero the end of the record has been reached. Then, at 80, the attribute offset index is set to zero indicating to the application that the attribute was not found. The function then returns from the call.

If the count is not equal to zero, one or more attribute-only fields exist and at 82 the count is saved. At 84 the index offset is incremented to the first attribute-only field. At 86 a check is then made to determine if the attribute pointed to by the offset index matches the attribute passed in the function call.

If the attributes match at 88 the attribute offset index is set to the offset of the found attribute in the record. This indicates to the application that the attribute does exist. The function then returns from the call.

If the attributes do not match, at 90 the index offset is incremented to the next attribute-only field and at 92 the saved count is decremented by one. At 94 the count is compared to zero. If the count is zero, the end of the attribute only fields has been reached and at 96 the attribute offset is set to zero indicating to the application that the attribute was not found. The function then returns from the call.

If the count is not zero, the logic loops back to 86 to again compare the attributes.

In the preferred embodiment, other record manipulation primitives are available for building a record. A function call is provided to start the build of a record by placing a record identifier into a memory buffer. A second function call is used to add length and attribute fields to a record in the buffer. This would be followed by a third function to move a field of data into a record. Then, to add one or more attribute-only field or to end the record, a fourth function call is provided. This function call appends a length field of zero, a count field and the attribute fields. It can also end the record by appending a length field of zero and a count field of zero if the record is to end with no attribute-only fields.

A fundamental approach to design in this methodology is the use of nonvolatile memory for preserving the integrity of records. Two different approaches to nonvolatile data storage are used. One is called the Direct Data Access Method. The second is called the Index Access Method.

The Direct Data Access Method is used to store and retrieve records from a queue. This makes this method useful in the capturing of data and the storing of records in time of arrival order.

The Index Access Method is used to store records so that they can be easily located through the use of a key field. This method is useful in creating indices of records for such things as orders or for creating record-lookup tables.

Direct Data Access (DDA) primitives are used to build and access a data file from its beginning to end sequentially. The logical beginning and end of the file are dynamic such that the data file is used in a circular fashion or perpetually. All data written to the file are by order of arrival and all data retrieved from the file are by order of arrival.

DDA primitives are responsible for directing access to the physical beginning of the file when the physical end of the file is detected. They are is also responsible for maintaining the logical beginning and end of file pointers such that data is not over-written or over-read.

In the DDA method, all data blocks are fixed to a specified length on a per file basis. The method provides for variable length records provided the record length is within the specified block size. In the method, only the currently accessed data block is held in memory, keeping memory requirements for the method at a minimum. The memory image is written to disk on each addition of a record to the data block. This assists to provide reliable storage of data.

In the preferred embodiment, a function is provided for storing the relative block and record number in a data record. This is significant in keeping two systems in lock step when transferring data. To keep two systems in lock step, the system capturing the data will store the relative block and record numbers with each data record. Data collection, codification and storage can occur, then the memory image of the data record can be transferred to another system. It is the responsibility of the receiving system to store the data as it is received. When the communications or transfer medium is not available data storage can continue on the first system.

The systems can be programmed such that when the state of the communication medium is restored, the first system requests the last relative block and record numbers that the second system received. Then the first system directs the method to transfer all records that it may have collected from that point on.

Periodically during normal transfer, the first system can request the last relative block and record pointers that the second system has received. This is in essence how the logical beginning and end of file pointers are maintained. With this method and appropriate programming, data collection, storage transfer and basic file maintenance can occur without human intervention.

With appropriate file data structure addressing more than one direct access file can be utilized in an application. A file write is permitted during a read of the file. This is to provide continued data storage capability.

A file is allocated and formatted for use as a Direct Data Access Method file. The specifications for allocation are described below.

Disk sector size: This is generally the smallest subdivision of a disk file that the operating system will read or write. The file allocation is based on multiples of the sector size.

Size of the data block: This is the size of a data block in bytes, based upon the perceived application requirement. The size of each data block will be rounded up to multiples of the sector size. All data blocks are allocated to the same size for a specified file.

Number of data blocks: This is the total number of data blocks that the file will hold based upon the perceived application requirement.

From the above specifications the size of the file is determined. The block size is rounded up to a multiple of the given sector size. The total space required for data blocks is the block size times the number of given data blocks.

In addition to the data blocks a header record is required for each file. This header record is allocated as the size of one sector. The total byte size of the file is a summation of the above.

When the file is created the data blocks are initialized to binary zeros and control information placed at the beginning of each block. A given file can be represented by the diagram illustrated in FIG. 6. In the preferred embodiment, the file header record contains the file specifications information and is formatted as follows:

Two byte unsigned integer for the last relative block read;

Two byte unsigned integer for the last relative record read;

Two byte unsigned integer for the sector size in bytes;

Two byte unsigned integer for the header record size in bytes;

Two byte unsigned integer for the data block size in bytes;

Two byte unsigned integer for the number of data blocks in the file;

Two byte unsigned integer for the file full flag;

Two byte unsigned integer for optional application identification;

Seven byte field for the file creation date stored as unsigned hexadecimal values (YYYYMMDDHHMMSS);

Open space for the remainder of the header record.

In the preferred embodiment, a data block is formatted as follows:

One byte unsigned for the cycle byte;

Two byte unsigned integer for the free space length in bytes;

Two byte unsigned integer for the free space offset in the data block;

Open space for the remainder of the data block.

Due to the detail and complexity of the Direct Data Access Method, data structure variables will be referenced by their declared symbolic name.

The "ddam.sub.-- head" structure holds the values from the file header record. The "ddam.sub.-- head" structure is referenced by prefixing "hd->" to a specific structure variable name (e.g. hd->hdsz).

    ______________________________________
              struct ddam.sub.-- head {
               USHORT rbn;
               USHORT rrn;
               USHORT secsz;
               USHORT hdsz;
               USHORT blksz;
               USHORT blkn;
               USHORT full;
               USHORT sysid;
               UCHAR create[7];
               UCHAR opn[512];
              };
    ______________________________________

    ______________________________________
              struct ddam.sub.-- calc {
               USHORT rbn;-
               USHORT rrn;
               USHORT first;
               USHORT last;
               UCHAR cycle;
               USHORT from.sub.-- rbn;
               USHORT from.sub.-- rrn;
              };
    ______________________________________

    ______________________________________
               struct ddam.sub.-- blk {
                USHORT *hd;
                UCHAR *cb;
                UCHAR *fsl;
                UCHAR *fso;
               };
    ______________________________________

    ______________________________________
              struct ddam.sub.-- blkg {
               USHORT *hd;
               UCHAR *cb;
               UCHAR *fsl;
               UCHAR *fso;
              };
    ______________________________________

    ______________________________________
              struct ddam.sub.-- get {
               USHORT rbn;
               USHORT rrn;
               USHORT flag;
               USHORT w.sub.-- flag;
               USHORT lnth;
               UCHAR *addr;
              };
    ______________________________________

• Inventors
  Heffron, Donald J.;
• Published
  Aug-1-1995
• Current US Classes:
  710/100
  718/100
• Application #
  133824
• International Classes
  G06F 015/24; G06F 015/46
• Field of Search
  364/401 364/408 364/464.01 364/465 364/466
• Examiner
  Kriess; Kevin A.
• Agent
  Schwegman, Lundberg & Woessner
• US Patent References:
  4266271
  4383298
  4445176
  4468750
  4589069
  4623964
  4694396
  4791561
  4901237
  5063507
  5155809
  5165018
  5187787
  5212789