A Trick To Get Long Records And/Or Better Packing - IBM 1130 User Manual

Section
Subsections Page
80 40
I
10 01
A Trick to Get Long Records and/or Better
Packing
If you have records exceeding 320 words in length,
or records of a length that yields very poor packing,
you may wish to employ a trick, or, more properly,
an unorthodox usage of FORTRAN. This usage takes
advantage of the fact that an 1130 FORTRAN READ/
WRITE I/O list will be satisfied, regardless of the
FORMAT or DEFINE FILE statement.
For example, if we say
DIMENSION ITEMS(500)
READ (6'N) ITEMS
500 ITEMS will be read from the disk, starting at
record number N. It would not matter if the state-
ment:
DEFINE FILE 6(100,100, U, NEXT)
were used, indicating 100-word records. In fact,
no matter what the DEFINE FILE statement contains,
the entire ITEM array will be read,whether it ex-
ceeds 320 or not.
The DEFINE FILE statement has one effect, how-
ever, in that it still defines the length of the "defined"
record at 100 words. Reading the 500-word array
merely means that we have read five "defined"
records. If N were 100, you would have to increment
it by five to read the next 500 words or block of
five 100-word records.
The DEFINE FILE statement, then, must define:
1. A file that contains enough space to hold all
the data to be placed in it
2. A record length less than 320
3. Preferably, a record length evenly divisible
into 320 -- that is, 320, 160, 80, 64, 40, 32, 20,
16, 10, 8, 5, 4, 2, 1.
To illustrate, suppose you have a file containing
100 records, each with 400 words. Since
DEFINE FILE 1(100,400, U, N)
is not allowable, you could alternately specify
DEFINE FILE 2(200,200, U, N)
DEFINE FILE 3(400,100, U, N)
DEFINE FILE 4(800,50, U, N)
DEFINE FILE 5(500,80, U, N),
etc.
Note that all four files fulfill the first two rules:
same number of words as file number 1 (40,000) and
record length less than 320. However, only FILE 5
meets the third rule; 80 is evenly divisible into 320,
while 200, 100, and 50 are not.
The reason for the third rule should be self-
evident in light of the previous material in this
section:
• The FILE 2 combination (200, 200) results in
only one record per sector, with 320-200 or 120
words on each wasted. Total file size would be
200 sectors.
• FILE 3 (400, 100) gives three records per
sector, with 320 -3 x 100 or 20 words wasted. Total
file size is 400/3 or 134 sectors.
• FILE 4 (800, 50) yields six records per sector,
with 320 -6 x 50 or 20 words wasted. Total file
size is also 134 sectors.
• FILE 5 (500, 80) results in four records per
sector, with 320 -4 x 80 or no words wasted. Total
file size is 500/4 or 125 sectors.
To implement this trick, you need change only
the DEFINE FILE statement and the incrementing/
decrementing logic in existing programs. For
example, if you have a file that formerly contained
400 records of 196 words each:
DEFINE FILE 6 (400, 196, U, NEXT)
you now realize that it will use each sector quite
inefficiently. Therefore, you choose instead to
use
DEFINE FILE 6 (1600, 50, U, NEXT)
which replaces the old 196-word record with four
50-word records. (In addition to better packing,
you gain four words in each record.) In the body of
your program, where you coded
N=N+1
READ (6'N) data
you use instead
N=N+4
and so on throughout the program.
Where you use the automatically incremented
parameter NEXT
READ (6'NEXT) data
you need do nothing; NEXT will automatically reflect
the number of defined records that have been proc-
essed, and will be incremented by 4 rather than 1.