 |
Description  |
|
|
TABLE OF CONTENTS
Abstract of Disclosure
Background of the Invention
Summary of the Invention
Brief Descripton of the Drawings
Description of the Preferred Embodiments
General System Operation
Syntax
Commands and Responses
System Hardware
Processors
Mpu
Ram4
Prom4
P10
S10
Pic-8
Dmab
Detailed System Operation
Communications Level
Dbms level
Storage Level
System Software
Introduction
System Symbols/MACROS
Communications Level
Dbms level
Subroutines (all levels)
Storage Level
BACKGROUND OF THE INVENTION
This invention relates to digital information storage systems of the type
accessible by a central processing unit.
Digital information storage facilities are known which are designed to
store large quantities of information in digital form and which are
normally accessible by a general purpose digital computer. In such
systems, the digital information is typically stored on magnetic record
media, such as disk packs or magnetic tapes and forms a data base of user
information, such as inventories, payroll and accounting records, weather
data, seismic data and the like. The storage facility is normally
associated to a general purpose digital computer capable of extracting
information from the record media, processing the extracted information
and returning processed information to the record media.
In the past, all significant data processing functions have been performed
in the host digital computer, and the information storage facility has
functioned merely as a slave to the host computer or at best as a simple
fixed location single key search, and has been provided with a functional
capability of merely transferring information thereto. In a typical
installation, the host computer is provided with a resident program for
specifying the manner in which information is to be processed and, once
operational, one or more application programs are performed step by step
in the host computer until a step in a given program is reached which
requires information from the storage facility. Thereafter, further
activity in the specific program is terminated and the host computer
transmits a request to the information storage facility to retrieve a
first index block. That block of information is located and transferred to
buffer storage in the host computer after which the computer searches for
a reference, commonly termed a pointer. Once the pointer has been located,
another index block is requested by the host computer and transferred from
the storage facility to the host computer buffer storage, after which the
second index block is searched for an additional pointer. This process
continues for several iterations until the particular record block has
been located in the storage facility and transferred to the host computer,
whereupon the application program may be resumed. The application program
then must extract the individual data item of interest. Each transfer of
information between the host computer and the storage facility requires a
high speed data path in order for the process to operate with some degree
of efficiency, which in turn requires that the host computer be in close
physical proximity to the information storage facility. This requirement
of close physical proximity is inconvenient in some applications and
totally undesirable in others.
An even greater disadvantage to known systems of this type is the fact that
a large percentage of the functional capability of the host compouter is
diverted from the execution of the application program, and thus wasted,
due to the relatively large amount of computer time spent in obtaining a
file, record or item from the information storage facility. As the size or
use of the data base expands, the amount of host computer time spent on
index retrieval and searching expands accordingly, which renders known
systems of this type even more inefficient. While some information storage
facilities have been designed for use with more than one host computer,
such systems have not remedied the disadvantages noted above.
SUMMARY OF THE INVENTION
The invention comprises an information storage facility provided with
plural levels of processing capability, which permits symbolic access by
the host computer to information stored therein and frees the host
computer to perform processing functions while information is being stored
in and retrieved from the storage facility. In addition, the invention is
entirely expandable and can be tailored to meet the exact requirements of
any data base.
In its most general aspect, the system comprises three processing levels,
viz. a communications level, a data base management system (DBMS) level,
and a storage level, with the central DBMS level separated from the other
two levels by a pair of shared memory units. Communications between
processors and/or levels is accomplished via shared memories and/or Direct
Memory Access (DMA) bus, which bus may optionally be controlled by a
separate processor. In all implementations, the use of the DMA bus may be
incorporated to supplant or supplement the use of shared memory. The
communications level processor is configured to communicate with a host
computer. an intelligent terminal or other processor devices on either a
serial, parallel or DMA basis and performs all communication functions
with such external devices, such as handshake, protocol and the like. The
communications level processor exchanges information with the DBMS level
processor by means of a first shared memory unit, and is dedicated to
predetermined external processors. The storage level processor is
configured to operate the associated storage devices, such as tape memory
transport or, in the preferred embodiment, one or more disk storage
devices and performs data storage and retrieval, error recovery and
storage device management. The storage level processor communicates with
the DBMS level processor via a second shared memory unit. The DBMS level
processors are configured to perform syntax scanning functions and hashing
and coding/decoding routines, as well as all data access functions
including indexing, searching, buffering, blocking, deblocking, storage
management, and error recovery functions.
The one or more processors at each of the three levels is also configured
to perform mailbox routines whereby requests or responses are cached in
the appropriate adjacent shared memory facility for use by one of the
processors at the appropriate adjacent level. For example, a request from
the communication processor to the DBMS processor is transferred via a
mailbox in the shared memory unit coupled therebetween, while the request
from the DBMS processor to the storage level processor is transmitted via
a mailbox in the shared memory unit therebetween. In all cases describing
messages, commands and/or data as moving via shared memory mailboxes, this
implementation can be augmented or supplanted by use of a DMA bus
facility, to move any of the above classes of information.
The system architecture is modular so that each processor level and each
shared memory unit may be expanded or contracted as dictated by the
requirements of any given application. Thus, the system can grow along
with an expanding data base or an expanding number of external processor
devices by simply inserting additional processor and/or shared memory
modules.
In operation, each processor at each level is continuously searching for a
task to perform. When an incoming message is received, it is acknowledged
by the communications level processor associated to the particular
external processor at which the message originated, processed into a DBMS
level request and placed in a mailbox in the shared memory unit juxtaposed
between the communications level and the DBMS level. The cached request is
fetched from that mailbox by a DBMS processor which translate the request
into DBMS routines necessary to perform the tasks inherent in the
originally received message. The tasks required at the storage level are
placed in a mailbox in the shared memory unit juxtaposed between the DBMS
level and the storage level. The storage level processor fetches these
tasks and directs the required operation of the data storage devices
associated thereto. Informaton flow from the storage level to the
communications level proceeds in reverse fashion.
Each processor at each level is provided with a resident program preferably
stored in a programmable read only memory (PROM) for supervising and
directing operations thereof. The communications level processors are
additionally provided with both serial and parallel input/output devices
to permit communication with external processors, which may be remote or
proximate; while the storage level processors are each associated to a
storage controller, such as a disk controller to permit data storage and
retrieval, as well as error recovery and disk management.
For a fuller understanding of the nature and advantages of the invention,
reference should be had to the ensuing detailed description taken in
conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a general system block diagram illustrating the invention;
FIG. 2 is a block diagram of a microprocessor unit;
FIGS. 3A-E and 4A-F are circuit schematics of the microprocessor unit and
RAM memory units, respectively;
FIG. 4G is a diagram of a jumper socket for the RAM of FIG. 4;
FIGS. 5A-E are circuit schematics of the PROM unit;
FIGS. 5F and G are jumper diagrams for the FIG. 5 PROM unit;
FIGS. 6A-E are circuit schematics of the PIC 8 unit;
FIGS. 6F-H are jumper diagrams for the FIG. 6 unit;
FIGS. 7A-G are schematic diagrams of the SIO unit; FIGS. H-Q are jumper
diagrams and illustrative examples illustrating connections for the FIG. 7
SIO unit;
FIGS. 8A-E are schematic diagrams of the PIO unit;
FIGS. 8E and G are jumper diagrams for the FIG. 8 unit;
FIGS. 9A-E are schematic diagrams of the optional controller panel
assembly;
FIG. 10 is a block diagram and FIGS. 11A-E, 12A-D, 13 and 14A-E are circuit
schematics illustrating a shared memory unit;
FIGS. 15-22 are circuit schematics showing the disk controller TIFA unit;
FIGS. 23-30 are schematic diagrams illustrating the disk controller TIFB
unit;
FIGS. 31-47 are flow charts for all three processor levels of the system;
FIGS. 48 and 49-51 are a block diagram and detailed diagrams, respectively,
of a disk controller unit;
FIG. 52 is a circuit schematic of the CRC circuitry;
FIGS. 53 and 54 are illustrative memory maps; and
FIGS. 55-75 are detailed and schematic diagrams illustrating the DMAB unit.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
GENERAL SYSTEM OPERATION
Initially it is noted that the terms STORAGE LEVEL, MEMORY LEVEL, and DISK
LEVEL have equivalent meaning in the ensuing description. Further, in all
implementatons, the movement of messages, data, or commands may be
accomplished via a DMA bus facility in lieu of or in addition to a shared
memory. Such DMA buses may be used to connect processors, levels, shared
memories (if any) and one or more external computers, terminals, modems,
or communications line interface devices.
Turning now to the drawings, FIG. 1 is a generalized system diagram
illustrating the preferred embodiment of the invention. As seen in this
FIG. the system includes a communications processor level comprising a
plurality of microprocessors, 10, 11 each dedicated to a different group
of external processor units, such as a host computer 12 and an intelligent
terminal 13, as well as a modem 14 for permitting remote communication.
Each communications microprocessor is configured in such a manner as to be
capable of both serial and parallel information transfer with units 12 and
13. Also included in the system is a direct memory access bus (DMAB) 15
controlled by a separate processor 16 for enabling high speed data
transfer of large blocks of information between host computers 12, 12' and
the data storage devices described below.
Each communications microprocessor 10, 11 is coupled to a shared memory
unit 20 termed an expandable cache memory. Memory unit 20 is shared with a
plurality of DBMS level microprocessors 21-24, each of which is also
coupled to a second shared memory unit 25. Memory unit 25 is shared with a
plurality of microprocessors 26, 27 at the storage level, each of which is
coupled to an associated data storage device 28, 29, respectively and data
storage device controller 30, 31, respectively. In the preferred
embodiment, the data storage devices 28, 29 are disk storage devices of
conventional design; however, other types of data storage devices may be
employed as desired, such as magnetic tape devices or the like.
General system operation proceeds as follows. With the system in operation,
processors 10, 11 continuously look for incoming messages, processors
21-24 look for tasks from shared memory unit 20 and results from shared
memory unit 25, while processors 26, 27 look for tasks from shared memory
unit 25. When an incoming message is received by processors 10, 11, it is
error checked, acknowledged and passed on to a mailbox in shared memory
unit 20. The first processor of the processor group 21-24 which tests the
filled mailbox assumes responsibility for performance of that task. If
processor 22, for example, assumes responsibility of the particular task,
it communcates to the appropriate disk control processor 26 or 27 via one
or more mailboxes in shared memory unit 25 until the task is completed.
Once the task is completed, an appropriate message is transferred back to
the mailbox in shared memory unit 20 by the responsible processor 22,
after which the message is fetched by the communications processor 10 or
11 and transmitted to the external processor.
To summarize, the communications level microprocessors perform line
handling functions, error routine and mailbox routines; the DBMS level
processors handle the syntax scanning funtions and hashing and
coding/decoding routines, all data access functions including indexing,
searching, buffering, blocking, deblocking, storage management, and error
recovery functions. In addition, the DBMS processors handle read/update,
add/delete, lock/unlock, save/restore, index, and mailbox routines. The
disk control processors 26, 27 handle disk management read/write, error
recovery, and mailbox routines.
At the communications level, messages are handled by communications service
routines which buffer a message and handle all the protocol with regard to
the message. The message is then passed via a mailbox routine and shared
memory unit 20 to the DBMS level. The DBMS level examines the message,
checks syntax, converts symbolic names to 3-byte internal codes,
determines the appropriate command routine and executes that routine using
various utility subroutines. The command routine causes information to be
read or written from the data storage disks 28, 29 by sending messages
through the mailbox routine and shared memory unit 25 to the disk control
level processors 26, 27. Upon receiving the required information or
completing the required task, the DBMS level processor then sends a
message or messages to the communications level which then sends these
messages back to the external device which initiated the command.
Both serial and parallel interfaces are provided between the communications
level processors 10, 11 and the external devices. Message protocol for
either serial or parallel mode comprise an ACK-NAK handshaking sequence.
Each character or a received message is checked for parity errors and the
entire message is checked against the check sum contained in the message
as transmitted. If there is a parity error of if the calculated check sum
does not match the check sum received with the message, a NAK message is
returned to the sender who may then repeat the message. The reception of a
NAK is an indication that the receiver denies all responsibility for the
message and stores no information about the message. If there are no
parity errors and the check sum matches, an ACK is returned signifying
that the receiver has taken responsibility for the message.
It should be noted that the handshaking sequence may be modified by
providing automatic time-out routines which assume reception of a NAK
message upon expiration of a predetermined time period. Further, other
standard message protocols may be employed, as desired.
SYNTAX
Command syntax is as follows:
COMMAND, COMMAND ID, ARG 1, ARG 2, ARG 3, ARG 4 where the command is a
string of characters, e.g. UPDATE or LOCK. COMMAND ID is a user selector
identifier used to identify the command and is returned with the response.
COMMAND ID may be the null string, i.e. may be missing. However, the
delimiter following COMMAND ID must be present. The arguments to a command
are character strings separated by commas (or any non-alphanumeric
character). In any argument position where a symbolic file, record or item
name can be used, a number can be used to refer to a file, record or item
by its sequential position rather than its name.
Response syntax is as follows:
COMMAND ID, TRANSACTION #, ERROR CODE, DATA where TRANSACTION # is the
unique string of digits used to identify a transaction for use in
reprocessing transactions during recovery from a problem. A TRANSACTION #
is returned only for operations which involve modification of the data
storage disk, i.e. disk 28 or 29. COMMAND ID is the command identification
in the command which invoked this response. An ERROR CODE which identifies
the error type and location is returned if an error occurs at any level.
If no error occurs, the delimiters are still present but the error code is
not. Data can take one of several forms depending on the command executed.
For example, if the command caused the return of an item, the data will
simply be that item value. If the command caused the return of a record,
the data will have the format:
ITEMNAME L ITEMVALUE
where ITEMNAME is the internal three-byte code for the item name, L is the
length 0 to 127 of the item value and the ITEMVALUE is simply the
itemvalue as referred to above. If the command causes return of a file,
the data will have the format:
RECORDNAME L RECORD RECORDNAME L RECORD
where RECORDNAME is the internal three-byte code for the record name, L is
the length of the record and RECORD is the record in the same format as
immediately above. If the command causes the return of a sector off data
storage disk 28 or 29, the data will be in exactly same form as it existed
on the disk.
Response messages are returned 128 bytes of data at a time. If a response
requires more than one message, then more than one message is returned.
The COMMAND ID is included in every message. The last message of a series
of messages in response to a command contains and end-of-response
indicator: a transaction number of 1.
Commands and Responses
Update: the UPDATE command has the form:
UPDATE COMMANDID, FILENAME,RECORDNAME,ITEMNAME,DATA and results in the
specific item having a value of DATA. If the file, record or item
mentioned in the command does not exist, it is added to the data
The response to this command is:
COMMANDID,TRANSACTION#,ERRORCODE
If updating a record or file is required, then only FILENAME, RECORDNAME or
FILENAME are given. The data must be in the proper format as noted above.
Errors that may occur other than standard internal errors are:
Item is locked
record is locked
file is locked
read: the READ command has the form:
Read commandid,filemane,recordname,itemname
and results in the return of the item's value as previously set by an
UPDATE command.
The response format is:
Commandid,errorcode,data
if reading of a record or file is required, then only FILENAME, RECORDNAME
or FILENAME is specified. The data will have the form noted above.
Errors that may occur other than standard internal errors are:
File is locked
record is locked
item is locked
file is non-existent
record is non-existent
item is non-existent
get: the GET command has the form:
Get commandid,diskid,trackid,sectorid
the result is the return of the data on the track and sector on the disk
mentioned. It is in the form:
Commandid,errorcode,data
the data is the exact data that resides on the disk in that sector. Errors
that may occur other than standard internal errors are:
Disk does not exist
track does not exist
sector does not exist
put: the PUT command has the form:
Put commandid,diskid,trackid,sectorid,data
the result of this command is the writing on the disk of the data in the
specified place.
The response has the form:
Commandid,transaction#,errorcode
other than standard internal errors the only errors possible are:
Disk does not exist
track does not exist
sector does not exist
sector not allocated by a request command
request: the REQUEST command has the form:
Request commandid,diskid,trackid,sectorid
the result of a REQUEST command is the return of a TRACKID and SECTORID
near the specified track or sector on a specified disk and the marking of
that track and sector as allocated for user use.
The response format is:
Commandid,transaction#,errorcode,diskid,trackid,sectorid
the only errors other than standard internal errors are:
No more sectors on disk
disk does not exist
track does not exist
sector does not exist
return: the RETURN command has the form:
Return commandid,diskid,trackid,sectorid
the result of the RETURN command is the deallocation for user use of the
specified sector.
The response format is:
Commandid,transaction#,errorcode
the only errors other than standard internal errors are:
Not an allocated sector
disk does not exist
track does not exist
sector does not exist
lock: the LOCK command has the format:
Lock commandid,filename,recordname,itemname
the result of the LOCK command is that an item (record or file, if only
record or file is specified) is locked and unavailable for reading or
updating by any other terminal. The item remains locked until an UNLOCK
command is given for that item, record or file.
The response format is:
Commandid,transaction#,errorcode
other than standard errors, the only errors are:
File locked by another terminal
record locked by another terminal
item locked by another terminal
file non-existent
record non-existent
item non-existent
unlock: the UNLOCK command has the form:
Unlock commandid, filename, recordname, itemname
the result of the UNLOCK command is that the file, record or item is
unlocked only if the file, record or item was previously locked by the
same terminal now originating the UNLOCK command. The response format is:
Commandid,transaction#,errorcode
other than standard internal errors, the only possible errors are:
File locked by another terminal
record locked by another terminal
item locked by another terminal
file non-existent
item non-existent
file is not locked
record is not locked
item is not locked
name: the NAME command has the form:
Name commandid,filename,recordname,itemname
this command returns the symbolic name of the item specified or of the file
or record specified if the FILENAME,RECORDNAME or FILENAME is given.
Normally, the NAME command is only used when a sequence number is in place
of ITEMNAME or when sequence numbers are used in place of ITEMNAME and
RECORDNAME or when the sequence numbers are used in place of
FILENAME,RECORDNAME or ITEMNAME.
The response is:
Commandid,,errorcode,data
where DATA is the symbolic name being returned.
The only errors other than standard internal errors are:
Filename does not exist
recordname does not exist
itemname does not exist
add: the ADD command has the form:
Add commandid,filename,recordname,itemname
the result of the ADD command is the addition of the item to the data base.
If only the file and record names are specified, the result is the
addition of only the record to the data base. If only FILENAME is
specified, only the file is added to the data base.
The response is:
Commandid,transaction#,errorcode
in the case where file, record and item are specified, the only errors are:
File does not exist
record does not exist
in the case where only file and record are specified, the only error is:
File does not exist
in the case where only file is specified, only standard internal errors are
possible.
Delete: the DELETE command has the form:
Delete commandid,filename,recordname,itemname
the result is to delete the item from the data base. In the case where only
FILENAME and RECORDNAME are specified only the record is deleted. If
FILENAME is only specified, then the file is deleted. When none are
specified, the entire data base is deleted. The response is:
Commandid,transaction#,errorcode
the only possible errors, other than standard internal errors are:
Record does not exist
file does not exist
item does not exist
copy: the COPY command has the form:
Copy commandid,diskid1,diskid2
the result of this command is the copying of the entire contents of disk 1
onto disk 2, destroying any data formerly residing on disk 2. This is a
straight copy and involves no reorganization of the data. The response is:
Copy commandid,disk
commandid,transaction#,errorcode
the only error other than standard internal errors is:
Disk does not exist
the following are several elementary examples illustrating the use of
various of the commands available in the system of FIG. 1.
Each command, as given in this section, will assume, unless otherwise
stated, that all previous commands in this section have been executed and
all previous explicit assumptions about what exists in the disk data base
apply.
Assuming that there are 3 files in the disk data base (PAYROLL, ACCOUNTS
RECEIVABLE, and INVENTORY) and there are two terminals connected to the
data base (Terminal 1 and Terminal 2), and assuming that the PAYROLL file
has a record in it by the name of GEROGE-ALLEN and that the record now has
no items in it, a message from Terminal 1 such as:
Update d1,payroll, george-allen,payrate,7.39
would invoke a response from the system of:
Cmd1,473652,,
where CMD1 is the COMMANDID from the command, the 473652 is the
TRANSACTION# and the two commas at the end indicate there was no error.
The result of the command is that the PAYRATE item was added to the
GEORGE-ALLEN record of PAYROLL and received an item value of 7.39. If,
later, a message is sent such as:
Update payroll,george-allen,payrate,1.21
the response would be:
,4736700,,
Note that there is no COMMANDID in the response although the delimiter
comma is there and that the TRANSACTION# is larger than the previous
TRANSACTION#. This command results in the changing of the item value from
the previous value of 7.39 to 1.21.
Now, if the message
Namex531,payroll,george-allen,1
was sent, the response would be
X531,,,payrate(5a274b)
the X531 is the COMMANDID, there is no TRANSACTION# or ERRORCODE and the
data returned is PAYRATE, the symbolic name of item 1 is the GEORGE-ALLEN
record. The 5A274B in parentheses is the hexadecimal representation of the
3-byte internal code. Now, a command
Read payroll,george-allen,payrate
would invoke the response
,,,1.21
as the COMMANDID is null, there is no TRANSACTION# and no errors. Note that
the delimiter after the null command in the READ command is a space. If
the LOCK command is now performed:
Lock xx, payroll
the response
Xx,47398,,
is received and the PAYROLL is locked and no terminal may access it except
the terminal that gave the LOCK command. The PAYROLL updating program
might use this command to prevent access to the PAYROLL file by any other
terminal. Now a command
Delete foo,payroll
would result in a response
Foo,7file is locked
where the 7FILE IS LOCKED indicates that the file is locked, and therefore
cannot be deleted. To delete the PAYROLL file, it would be necessary for
TERMINAL 1 (which issued the LOCK command) to issue the command
Unlock payroll
which will receive the response
,475411,,
The PAYROLL file would then be unlocked and available for deletion. Even if
only a single record was locked within the PAYROLL file, the file could
not be deleted because deletion of a locked record is not permitted. Of
course, deletion of a locked item or file is not permitted either.
A series of commands might be issued at this point to back up the entire
data base. Assuming a two-spindle configuration with two disk packs to be
backed-up, the operator would place the first pack to be save on DRIVE1
and a fresh pack on DRIVE2. The command
Copy drive1, drive2
would be issued to copy the contents of the pack on DRIVE1 to the new pack
on DRIVE2. The DRIVE1 (old) and DRIVE2 (new) packs would then be set
aside. Then, the second pack to be backed-up would be placed on DRIVE2
with a fresh pack placed on DRIVE1. The command
Copy drive2,drive1
would then be issued to copy the contents of old pack DRIVE2 onto new pack
DRIVE1. The new pack DRIVE1 would then be set aside and the first pack to
be copied would then be replaced on DRIVE1. The result is that the copies
of the two packs would be shelved (labeled as, for instance, COPY1 and
COPY2) and the two original packs would then be in position on their
respective spindles ready for further commands. Another command which may
be issued by a systems program run on one of the terminals is:
Get drive1, track17,sector25
and the response would be
,,,(string of data)
The string of data would be the contents of a particular sector. This
command could be issued for any sector on the disk.
A corresponding PUT command attempting to write on a given sector on the
disk would not be permitted as no REQUEST command had been executed to
gain excess to a particular sector and make it available for PUT usage.
The following shows how several commands can work together to produce the
desired result. The example chosen is an algorithm for listing the entire
contents of a data base in a very structured manner.
The format that the data base lister will use is:
(1) FILENAME1(1C)
(1) recordname1(1c)
(1) itemname1(1c) itemvalue
(2) itemname2(1c) item value
(3) . . .
(n) itemnamen(1c) itemvalue
(2) recordname2(1c)
(1) itemname1(1c) itemvalue
(2) itemname2(1c) itemvalue
(3) . . .
(n) . . .
(3) . . .
(n) . . .
(2) filename2(1c)
(1) . . .
(1) . . .
(n) . . .
(n) . . .
(3) . . .
(n) . . .
the data base lister will be presented as an algorithm rather than a
program. The particular operations in the algorithm such as OUTPUT, INPUT
and PRINT will not be strictly defined. In particular, OUTPUT will mean
output from the external device to the system, a string or a command;
INPUT will mean the data received from one of these commands; and PRINT
will mean to print on a lineprinter associated to the external device
lineprinter the string following that. Other operations, such as DO will
assume their normal meanings.
The Data Base Lister is as follows:
__________________________________________________________________________
Print "DATA BASE LISTING"
Do FILECOUNT= 1 to .infin. ;loop through all files
Output "NAME" FILECOUNT ;get name of file and
Input FILENAME ; the 3-byte code
If Error="NO SUCH FILE" then exit Do Loop
;if no more files, quit
Print (Col 10) FILECOUNT ")" FILENAME
;list filename
Do RECORDCOUNT=1 to .infin. ;loop through files
Output "NAME" FILECOUNT","RECORDCOUNT
;get name of record
Input RECORDNAME ;
If Error="NO SUCH RECORD" then exit Do Loop
;if no more records do next file
Print (Col 20) RECORDCOUNT,")",RECORDNAME
;list recordname
Do ITEMCOUNT=1 to .infin. ;
Output "NAME" FILECOUNT","RECORDCOUNT","ITEMCOUNT
;get name of item
Input ITEMNAME ;
Output "READ" FILECOUNT","RECORDCOUNT","ITEMCOUNT
;get value of item
If Error="NO SUCH ITEM" then exit Do Loop
;if no more items, do next record
Input ITEMVALUE | | |
