⟦e82c3dfd1⟧

TextFile

C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_

0. REFERENCES .............................................1

1. INTRODUCTION ...........................................2
1.1 Requirements ......................................2
1.2 Use of the System .................................2

2. BASIC PRINCIPLES .......................................4
2.1 Phase of Analysis .................................4
2.2 Phase of Reorganization ...........................4
2.3 Reinsertion of CF-Listfiles .......................5
2.4 Adaption ..........................................7

3. SPECIFICATION ..........................................9

4. LIMITATIONS ............................................14

5. FILE FOR FUTURE AMENDMENTS .............................16

6. OPERATING GUIDE ........................................17
6.1 Call of Reanalyse .................................18
6.2 Call of Reextract .................................23
6.3 Call of Reform ....................................24
6.4 Call of Reinsert ..................................26
6.5 Use of Resources ..................................27
6.6 Examples of Program Calls .........................30

7. RUN JOURNAL ............................................35
7.1 Reanalyse Run Journal .............................35
7.1.1 Survey of Affected Files ...................36
7.1.2 Results of Analysis ........................37
7.1.3 Errors .....................................42
7.1.4 Hard Errors ................................44
7.2 Reextract Run Journal .............................45
7.3 Reform Run Journal ................................46
7.4 Reinsert Run Journal ..............................46 \f

C_O_N_T_E_N_T_S_ _(_c_o_n_t_i_n_u_e_d_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_

8. HARD ERROR .............................................50
8.1 Errors in the Call Parameters .....................50
8.2 Errors due to Lack of Resources ...................51
8.3 Errors from the CF-System .........................52
8.4 Errors from the SQ-System .........................52
8.5 Run Time Errors ...................................53

9. DANISH APPENDIX ........................................55
9.1 Keywords in Program Calls .........................55
9.2 Run Journal .......................................61
9.2.1 Reanalyse Run Journal ......................61
9.2.2 Reextract Run Journal ......................68
9.2.3 Reform Run Journal .........................68
9.2.4 Reinsert Run Journal .......................69

10. INDEX ..................................................71
\f

0_._ _ _ _ _ _ _ _ _ _ _ _ _ _R_e_f_e_r_e_n_c_e_s_

(1) Introduction-TOOLS
RCSL 21-V001 (Danish edition)

(2) Connected Files System
RCSL 28-D5

(3) RC8000 SQ-System
RCSL 31-D561

(4) DATABASE80
RCSL 21-V045\f

1_._ _ _ _ _ _ _ _ _ _ _ _ _ _I_n_t_r_o_d_u_c_t_i_o_n_

REORG80 is a System80 basic module intended for database
reorganization.

purpose The purpose of REORG80 is: to let the initial creation of a
new database, or the reforming of an existing database, be
made automatically, governed by the contents of the old and
new database descriptions.

In this version of REORG80 files of the type cf-master,
cf-list and outvar can be reorganized and fileheads can be
created.

Danish The program can optionally run with Danish Keywords and
texts Danish output. For Danish users this facility and the texts
will be described in chapter 9: Danish Appendix.

1_._1_ _ _ _ _ _ _ _ _ _ _ _ _R_e_q_u_i_r_e_m_e_n_t_s_

requirements A basic requirement for the use af the system is that a
descripfile set up by DATABASE80 exists. (ref (1) and (4)).

1_._2_ _ _ _ _ _ _ _ _ _ _ _ _U_s_e_ _o_f_ _t_h_e_ _S_y_s_t_e_m_

use of the REORG80 should be used when:
system
1. A descripfile, but no database exists. Fileheads for the
initialization described files may then be created by the system.

2. Two versions of the same descripfile and a database,
reorganization corresponding to the oldest version of the descripfile,
exist.
\f

3. A database and one descripfile exist, and the database
tidying up needs some tidying up. E.g. the dead records in a listfi-
le must be removed. The system finds out if the changes
which have been introduced into the new version of the
descripfile are legal; and whether they should result in
a reorganization of the database. If both conditions are
fulfilled the real reorganization can be carried out. \f

2_._ _ _ _ _ _ _ _ _ _ _ _ _ _B_a_s_i_c_ _P_r_i_n_c_i_p_l_e_s_

REORG80 REORG80 consists of four programs reanalyse, reextract, re-
programs form, and reinsert.

A reorganization is carried out in two phases, the phase of
analysis and the phase of reorganization. The phase of ana-
lysis should a_l_w_a_y_s_ be started when changes have been made
in a descripfile, in order to check the need for a reorgani-
zation.

2_._1_ _ _ _ _ _ _ _ _ _ _ _ _P_h_a_s_e_ _o_f_ _A_n_a_l_y_s_i_s_

phase of In this phase the old and the new version of the descripfile
analysis are compared. This is done with the program reanalyse which
after final comparison prints a list of any differences and
reanalyse errors found and forms a table (reotab). The table makes up
the entire adaption for the programs which are to be activa-
ted in the following phase, the phase of reorganization. The
phase of analysis is concluded when it is correctly carried
through, i.e. when no illegal amendments are found.

2_._2_ _ _ _ _ _ _ _ _ _ _ _ _T_h_e_ _P_h_a_s_e_ _o_f_ _R_e_o_r_g_a_n_i_z_a_t_i_o_n_

phase of This phase is to be started by the user if the reanalyse
reorganiza- program finds it necessary. Three programs belong to this
tionphase:

reextract reextract: Extracts all records from the files which are to
be reorganized.

reform reform: Reforms the extracted records in accordance with
the new version of the descripfile.

reinsert reinsert: Creates fileheads for new files and for files
which are to be reorganized, and inserts the
reformed records in the respective files.

These programs must run in the given sequence either
immediately after each other or separately.

In case of an initialization of a new database, there will
be no records to extract from old files. Therefore the user
need only call the two programs: reanalyse and reinsert, but
of course, call of the other programs will do no harm.

2_._3_ _ _ _ _ _ _ _ _ _ _ _ _R_e_i_n_s_e_r_t_i_o_n_ _o_f_ _c_f_-_l_i_s_t_f_i_l_e_s_

reinsertion As it is not obvious how records can be reinserted into
of cf-list- cf-listfiles this phase will be described in more detail
files here.

Reinsertion must satisfy the two main goals:

1. all records are reinserted
2. all records are connected to all the chains they have
been connected to, unless the chain has been removed.

In order to fulfill this we had to make clear two points:

a. as there may be records which are not members of the
primary list, which list shall be chosen as insert list,
and in which order shall we connect the other lists,

b. in which order shall we insert or connect the records in
the chains.

The strategy we have chosen works as follows:

insertlist a) the order of the lists is defined as the order in which\f

the lists are described in the list section of the new
descripfile. The first list is the primary list. The
first list a record is connected to will be its insert
list.
E.g.
the structure:

(tegning)

is described in the list section as:

l24 .....
l34 .....
l14 .....

All the records which are connected to list 24 are inser-
ted into list 24, next all the records which are n_o_t_ con-
nected to list 24 but are connected to list 34 are inser-
ted into list 34 and the rest is inserted into list 14.

b) normally, before the records are inserted, they will be
record order sorted according to the ident-fields.
If it is necessary to keep the records in the same order
as they were in before reorganization, then this will be
achieved if the following requirements are fulfilled.
- the primary chain is the same before and after reorga-
nization
- all the records are connected to the primary chain
(otherwise they won>t be reinserted!) \f

- reanalyse has been called with a special fp-parameter
denoting which chain should be kept in order.
order.<list' reanalyse ... order.<primary chain no'
- reextract must have access to the mother-file.
Normally, reextract needs only to have access to the
listfile, unless the motherfile itself must be
reorganized.
The other chains will always be connected in
recnocf-order.

The strategy fulfills the two goals we set in 1 and 2.

The user is able to determine the insertion order just by
choosing the order of the lists and the ident-fields, or
by specifying the same order as before.

2_._4_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _A_d_a_p_t_i_o_n_

adaption The only kind of adaption which REORG80 demands of the
user is, besides any fp adaption, the new descripfile and
the descripfile which corresponds to the existing
database.

fp adaption In the phase of analysis it is standard that only files
of the type cfmaster and cflist are treated. However, it
is possible by fp-adaption to demand an analysis of all
files or of outvar files only. By means of fp-adaption it
is furthermore possible to demand reorganization of
certain files, though the description is not changed, for
tidy up a instance you can tidy up a file if it has grown too big.
file This adaption only controls the phase of reorganization,
not the analysis.

exclusion By means of fp-adaption certain files may also be
of files excluded from the reorganization. This adaption only
controls the phase of reorganization not the analysis. \f

This possibility may be used if, for some reason it is
desired to split up the reorganization into more jobs.
Furthermore it is necessary to exclude both mother- and
listfile-to- daughterfile, if the database contains a cf-listfile
listfile which is mother to a cf-listfile, as the current version
of REORG80 cannot reorganize this structure.

Note:

The user is advised to decide carefully which files he
wants to exclude from reorganization.

Often a reorganization of a motherfile results in a
reorganization of the daughterfile and vica versa,
because the chainparts are updated. Therefore the user
should use a rule of thumb:

1. reorganize every motherfile if a cf-listfile is
reorganized,

2. reorganize every daughterfile if the keyfields of a
cf-masterfile are changed.

Our strategy requires that motherfiles are reorganized
before daughterfiles. This is done automatically if all
files are reorganized at a time, but if the
reorganization is split up, you have to see to it
yourself. \f

3_._ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _S_p_e_c_i_f_i_c_a_t_i_o_n_

specification The Reorgsystem is in this version able to do the
following:

tidy up a 1. Reorganization on demand of the user (for instance for
file the purpose of tidying up).

filehead 2. Insertion of a new file. Causing a new filehead for
creation the file concerned to be created.

insertion of a 3. Insertion of a new logical file in an existing file.
logical file Only causing reorganization if identfields or certain
file parameters are changed.

insertion of a 4. Addition of a new list attached to a cfmaster file.
list Causing all records in the logical file, which is part
of the cfmaster file, to have a new chain field, while
existing chain connections are preserved.

If there exist records in the cf-listfile which is
daughter of the new list, these records will have a
new chainfield too.

insertion of a 5. Insertion of a new record type in the existing logical
record type file. Only causing reorganization if the identfields
of the logical file or certain file parameters are
changed.

insertion of a 6. Insertion of a new group in an existing record type.
group Causing the fields of the group to be inserted in the
record. By a repeating group only one control word,
but no fields, is inserted as the number of
repetitions is = 0.
\f

removal of a 7. Removal of a logical file or a file.
logical file Note that the reextract program extracts all records,
or file including those which shall be removed. The reinsert
program inserts only the records which shall remain in
the database.

removal of a 8. Removal of a record type. Functions as described under
record type point 7 for records of the current record type.

removal of 9. Removal of a group. Functions as removal of fields.
a group (See later).

insertion of 10. Insertion of new fields. Standard value is inserted if
a field it exists, otherwise all the bits of the fields are
set to zero.

removal of 11. Removal of a field. Causes the field to be removed
a field physically, where it exists.

moving of 12. Moving of a field. Occurs probably mostly in connecti-
a field on with insertion of new fields, but can also occur
for instance by moving of a field from one group to
another, or from the record-type-specific part of the
record to the logical-file-specific part or the other
way round. Moving of the field may furthermore take
place in connection with any of the under point 14-18
described changes.

By moving of a field f_r_o_m_ the record-type-specific
part of one record or f_r_o_m_ an ordinary group t_o_ a
repeating group the following happens:

If the field is simple (described without dimension)
the field contents is transferred to the first incar-
nation of the field in the repeating group. In any
other incarnations of the fields, 0 or standard value
is inserted.\f

If the field, which is to be moved, is an array (in-
dicated by dimension) a number of elements are trans-
ferred: e.g. the number of elements which correspond
to the number of incarnations of the field in the
group. If the number of incarnations ' dimension, 0 or
standard value is inserted in the extra elements.

moving of 13. Moving of f-bits. Is only relevant for logical files
f-bits with application code gvs. By change in a record type
description the serial numbers, which are assigned to
the fields by DATABASE80 and, which are used as bit
index in f-bits by GVS, can be changed. REORG80, how-
ever, moves the bits so they will correspond to the
new field serial numbers.

change of 14. Field type change. Not all combinations are allowed
field type here; generally you can say that the field types half,
word, long real and text can be mutually transformed.
A decimal point described under representation is in-
cluded in the transformation.

By change of field type from text to another field ty-
pe standard value is inserted, and by change of field
type to text a null text is inserted.

An aggregate field can>t be changed to another type
(and vice versa).

Mref - or dref field can>t be changed to another type
(and vice versa).

change of 15. Change of array length. By extension of an array field
array length a standard value, if any, is inserted or the number of
elements which the extension includes are set to zero.
By diminishing of an array a number of elements in the
upper part of the array are cut off.\f

change of a 16. A simple field can be changed to an array of the same,
simple field or of another field type. (As seen under point 14).
to array
field

change of a 17. Change of text field length. By extension of a simple
text field field of the type text null characters are inserted.
length By diminishing of a text field a null character is in-
serted as the last character of the text field. When
the subject is a text array the length of the indivi-
dual elements are changed as for simple fields of the
type text; at the same time the elements are pushed.

change of the 18. Change of layout concerning decimals. This can be done
number of for fields of the type half, word, long and real.
decimals

removal of 19. Removal of a list removes a chainfield from all re-
a list cords of the mother file and daughter file.

Note: if there exist some cf-listrecords which are on-
ly attached to the removed list these records cannot
be inserted into the listfile again, so they will be
removed too.

change of the 20. The keyfields of a cf-masterfile may be changed even
keyfields of a if one or more lists are attached to the file. This
cf-masterfile will result in a reorganization of all the cf-listfi-
les which are daughterfiles.

change of 21. If two files are connected by more than 1 list, the
list sequence sequence of the lists may be changed. Especially the
change of primary list may be changed, resulting in another or-
primary list dering of the daughter-file records.
\f

change of 22. Change of ident-status and reordering of ident-fields
ident-fields is allowed as far as the limitations of DATABASE80 are
met. Especially for list files, reordering of ident-
fields results in reordering of the list records (see
2.3, record order). \f

4_._ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _L_i_m_i_t_a_t_i_o_n_s_

limitations The limitations below concerning changes in the db-
description apply to version 7:

changes con- 1. Cf-listfiles may only be reorganized if they are
cerning file daughters of masterfiles.
of the type
cf-list

removal of a 2. A logical file which is stored in several files must
logical file be removed from all of these at the same time.

repeating 3. As to repeating groups the following is prohibited:
groups
Change of group type from ordinary to repeating and
vice versa.

Moving of a field f_r_o_m_ a repeating group to another
part of the record.

change of 4. Change of the numbers of files, lists, logical files,
file-, logi- record types and groups is not allowed, as they are i-
cal file-, dentifiers of the individual elements in the descrip-
record type-, tion.
and group no.

change of 5. Change of both field no and field name is not allowed.
field no and If it is necessary to change both, the user can in the
field name first turn change the field no, then run reorganizati-
on and then change the field name, for example.

negative 6. There must not be any records containing negative key-
keyfields fields (other than the dummy-record with keyfield -1
and without any daughter records attached to it). The
reason is, that keyfields in the phase of sorting and
comparison are described as a sequence of abs-half-\f

words, with the result that negative fields are consi-
dered bigger than non-negative fields.

Note: It is absolutely necessary for the user to pay
attention to (and obey) the above mentioned restricti-
ons as a thorough control not in all cases (can be or)
is made by REORG80. \f

5_._ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _F_i_l_e_ _f_o_r_ _F_u_t_u_r_e_ _A_m_e_n_d_m_e_n_t_s_

file for If the user needs a file for future amendments (from now
future on called fut.amend.) this file must be described in the
amendments db-description. Furthermore the corresponding logical fi-
le and list/lists must be described (see about this in
corresponding ref (4), section 5.3). The file can only be attached to
logical files files of the type cf-master.

future file As lists attached to the fut.amend. file do not contain a
mother reference there is no problem of reorganization in
connection with change of ident fields in a mother logi-
cal file. Thus it should be possible to reorganize the
mother logical file. The problem is however, that the
records of the file for future amendments contain field
no, -address and -type for the field, which should be
changed, and it might very well happen that this
information after the reorganization of the mother
logical file does not fit the actual circumstances
anymore.

We have thus chosen to cut off the old connection with
the list file by reorganization of its mother file. Which
means that all records in the list attached to the cur-
rent mother file are lost. That is, the records are still
there but are not available. This may gradually result in
a space problem for which reason it is recommended that
the user as far as possible sees to it that all fut.a-
mend. have become effective b_e_f_o_r_e_ the reorganization.
The record contents in the fut.amend. file may be printed
by means of GVS before the reorganization. Only lists be-
longing to master files which are reorganized will be cut
off. \f

6_._ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _O_p_e_r_a_t_i_n_g_ _G_u_i_d_e_

operating The REORG80 programs must run in a fixed sequence (see
guide section 2). In case that only cf-file heads are to be
created run with the programs reextract and reform may be
omitted.

fp-adaption It is strongly recommended to read section 6.1 about call
of reanalyse as the fp-adaption of this program controls
the remaining part of the reorganization.

The programs reextract, reform and reinsert do not nor-
mally need fp-adaption besides name of descripfile. Fur-
thermore reading of section 6.6 is recommended.

newformat The two files for extracted records, newformat and old-
oldformat format, must be specified as sq-files, e.g.:
newformat = set <segm' <disc' 0 0 0 21.4
Here the blocklength is specified as 4 segments. In lar-
ger reorganizations the blocklength may be specified as
8. (see ref. (3)).

Note:
If the files are set as normal files, you may end with an
empty database.\f

6_._1_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _C_a_l_l_ _o_f_ _r_e_a_n_a_l_y_s_e_

<reanalyse-call'

reanalyse
call*
newdescrip
olddescrip
init
analyse
file*
reanalyse record .<parameters'
reotab1
field
order
size
test
testout
0

No parameter group is mandatory. In the following the
parameters are discussed individually in the above
mentioned sequence.

newdescrip newdescrip.<new descripfile name'

The name of the file which contains the new descripfile.
Standard: newdescrip.descripfile. \f

olddescrip olddescrip.<old descripfile name'

The name of the file which contains the old descripfile.
Standard: olddescrip.olddescrip.

M_ 1
yes
init init.
no
P_ 1

By yes it may be indicated that it is a first time run,
which means that only fileheads shall be created in the
new database.
Standard: init.no

M_ 1
cf
analyse analyse. outvar
all
P_ 1

At this point is indicated which file types that should
be treated in the phase of analysis:

cf all files of the type cf _master and cf _list.
outvar only files of the type outvar.
all all files of the type cf _master, cf _list
or outvar.

Standard: analyse.cf\f

M_ *2
file file .<reorgmark' .<file no'
P_ 11

Indicates that certain files must or may not be reorga-
nized, no matter whether the files are changed or not.

<reorgmark'

noreorg
reorg

M_ *
reorg reorg .<file no'
P_ 1

The files mentioned m_u_s_t_ be reorganized, whether changes
in the db description have been made or not.

May for instance be used, when a file needs some tidying
up.

M_ *
noreorg noreorg .<file no'
P_ 1

The files mentioned m_a_y_ _n_o_t_ be reorganized, whether
changes have been made or not.

May for instance be used for partition of a big reorga-
nization into several smaller parts. Should be used with
care.

N_o_t_e_:
If the database contains a cf-listfile which is mother
to a cf-listfile, it is necessary to exclude both files\f

by means of
noreorg. <mother file no'.<daughter file no'

File numbers indicated by >reorg> and >noreorg> should
be a subset of the files indicated by >analyse>.

Standard: Change in the db-description concerning
the contents of a file results in a
reorganization of the file.

M_ *
record record .<rec-type no'
P_ 1

Indicates those record-types which m_a_y_ _n_o_t_ be
reorganized.
Concernes only record-types in files which are to be
reorganized.

Standard: If a file is reorganized, then all record-
types included will be so.

reotab reotab.<reotab - name'

The name of the discfile in which the table created by
the program is to be stored.

Standard: reotab.reotab.

M_ 1
M_ number
field field.
P_ name
P_ 1

Information about whether field number or -name should
be used by comparison of field descriptions.

Standard: field.number \f

M_ *
order order .<chain no'
P_ 1

(See also 2.3, reinsertion of cf-listfiles)

The cf-listfile records which are daughters of the chains
mentioned, will be inserted into the chains in the same
order as before reorganization.
<chain no' must be a primary chain both before and
after reorganization.

Standard: listfile records will be inserted, sorted
according to the identfields.

size size.<percentage'

This parameter can be used to increase the size of some
internal tables, whose size cannot be calculated on
before hand.
The need for this is indicated by a >field> or >index>
alarm in a run of reanalyse.
The meaning of size.100 is for instance a hundred percent
increase of these tables. This could be necessary if much
reforming of many records types is to be made.

Standard: size.0

M_ 1
M_ yes
test test.
P_ no
P_ 1

At this point it is indicated whether test prints from
the run are wanted.
This parameter should not be used unless the user is
advised so by the systems maintenance group.

Standard: test.no\f

M_ 1
testout testout.<testout name'.extend
P_ 0

At this point the name of the file in which the test
prints should be printed is stated. The file is created
if it does not already exist. Must be printed with the
convert command.
If the file is created it has the length 21 segments, and
test prints will be written cyclically.
This means that the user only can see the last 21
segments of the prints. If it is necessary to see all of
it the user must use the parameter

extend testout.<testout name'.extend

which automatically extends the file as long as the
resources allow it.

Standard: testout.testout.

6_._2_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _C_a_l_l_ _o_f_ _r_e_e_x_t_r_a_c_t_

reextract <reextract-call'
call

<olddescrip' = reextract,
M_m_m_ *
reotab
.<parameter'
oldformat
P_p_p_ 0

No parameter groups are mandatory, but <olddescrip' is
so.\f

<olddescrip' <olddescrip'

Name of the descripfile, which corresponds to the
existing database.

reotab reotab.<reorgtable-name'

As the name of the discfile, in which the table created
by the reanalyse program is stored.
Standard: reotab.reotab.

oldformat oldformat.<outfile-name'

The name of the outvar file, in which all the extracted
records are to be written. The file must be created in
advance. (See example 4 in section 6.6).
Note that the file must be a sq-file.
The file is inputfile to the reform-program.
Standard: oldformat.oldformat.

6_._3_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _C_a_l_l_ _o_f_ _r_e_f_o_r_m_

reform call <reform-call'

<left side' = reform,

reotab UUU*DDD
oldformat .<parameter'
newformat DDD0UUU

No parameter groups are mandatory, but the <left side' is
so.\f

<left side' <left side'

The name of the old or new descripfile.

reotab reotab.<reorgtable-name'

The name of the disc-file, in which the table, created by
the reanalyse program is stored.
Standard: reotab.reotab.

oldformat oldformat.<infile name'

The name of the outvar file, in which the extracted
records created by the reextract program are stored.
Standard: oldformat.oldformat.

newformat newformat.<outfile-name'

Name of the outvar file, in which the reformed records,
created by the program are stored.
The file must be created in advance, and must be a
sq-file.
The file is inputfile to the reinsert-program.

Standard: newformat.newformat.

6_._4_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _C_a_l_l_ _o_f_ _r_e_i_n_s_e_r_t_

reinsert <reinsert-call'
call
M_m_m_ *
reotab
<newdescrip' = reinsert .<parameter'
newformat
P_p_p_ 0

No parameter groups are mandatory, but <newdescrip' is
so.

<newdescrip' <newdescrip'

The name of the new descripfile

reotab reotab.<reorgtable-name'

The name of the discfile, in which the table, created by
the reanalyse program is stored.

Standard: reotab.reotab.

M_ 1
newformat newformat.<infile-name' .clear
0

The name of the outvar file in which the records reformed
by the reform program are stored.

.clear The extension .clear has the effect, that the file is
cleared as soon as all the records are read. This serves
to save space, when reorganizing very large cf-listfiles.

Standard: newformat.newformat. \f

work work
workkit workkit .<discname'

Indicates the name of the disckit on which the workfiles
shall be created.
This parameter is useful when you want to reorganize a
very large cf-listfile, and you don>t have enough space
for the workareas on the usual disckits, but you have got
an extra kit. (See chapter 6.5 use of resources in rein-
sert)
If there is not enough space on the kit specified, a war-
ning is printed and the program attempts to create the
file on another disc.

Standard: work.disc.

6_._5_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _U_s_e_ _o_f_ _R_e_s_o_u_r_c_e_s_

use of The use of resources depends on the size of the database
resources and the extent of the reorganization. Besides, it depends
on how the reorganization is executed. The reanalyse pro-
gram should always run in an independent run so that the
user is able to check that the amendments in the db de-
scription have the desired effect. The reorganization it-
self on the other hand can be split up into three jobs
and s_h_o_u_l_d_ definitely be split up by big reorganizations
both for space and security reasons. By less extensive
reorganizations and by creations of fileheads the reorga-
nization itself can very well be executed in one job.

Make sure that there are enough permanent segments to put
the new database onto. The minimum size for new cf-files
has been increased, so it is possible that very small fi-
les will grow in reorganization, although they will just
grow with empty space for future extensions. \f

In the following, it is implied that all programs run in
their respective jobs. Only resources exceeding standard
are stated.

reanalyse:

size 50000
temp disc 3000 20 Is in most cases sufficient
perm <disc' 100 1 For storage of reotab
time 7 0 Should be sufficient

reextract:

size 35000
perm <disc' <segs' 1 The maximum total size
of the files which are to be
reorganized and one entry,
used for oldformat.
time Depends on the dimension of
the reorganization.

reform:

size 35000
perm As reextract, used for newformat
time Depends on the dimension of
the reorganization.

reinsert:

size 80000 Space necessary for sorting
of list file records
area 13 Will be enough if no
daughterfile has more than 4
motherfiles.
perm <disc' Enough segments and entries
to put the new database into.\f

temp disc <segs' 20 There must be enough seg-
ments to hold newformat + 2*
space for all the records in
the biggest cf-listfile.

time Depends on the dimension of
the reorganization.

workareas The temporary segments and entries are used to hold some
workareas during reinsertion of one listfile at a time:
(See 2.3 reinsertion of cf-listfiles)
a) the records are split into work-files accor-
ding to insert-list
b) the records in every work-file are sorted
(normally all the records will belong to the
primary chain and be sorted at the same time).
The sorting area is taken from the area which
later on will be used for the cf-listfile it-
self.

workkit When a workkit is specified, these workareas will be cre-
ated on the workkit.

It may be useful to know that the areas described in a)
and b) will n_o_t_ be necessary if the records are inserted
in the same order as before reorganization, because the
records then will be moved directly from newformat to the
listfile.

If reextract, reform and reinsert are run in the same job
the resources are as follows:

size 80000
perm <disc' The size and number of the
entries are the total size
of the created database files
plus the number of these.
\f

temp disc The maximum total size of
the files which are to be
organized multiplied with 2
+ 2 * space for all records
in the biggest cf-listfile +
1000
25 entries.
time Depends on the dimension of
the reorganization.

6_._6_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _E_x_a_m_p_l_e_s_ _o_f_ _p_r_o_g_r_a_m_ _c_a_l_l_s_

examples of In the examples 1-3 are shown calls of the reanalyse
program calls program. The other examples call reextract, reform and
reinsert.

example of Ex. 1
reanalyse Reanalyse can be called in a job as this:

job ue 29xxxx size 50000 perm dkxxxxxx 100 1,
time 7 0

reotab = set 1 dkxxxxxx
reanalyse field.name
scope user reotab
finis

Explanation:

In this case an old descripfile with the standard name
olddescrip and a database corresponding to this exist.
The new descripfile has the standard name descripfile. By
comparison of the old with the new descripfile field
names are to be used. The reotab must be permanent as it
will be read by the following programs.
\f

reanalyse Ex 2
example The call of reanalyse could also look as follows:

reanalyse olddescrip.descripfile reorg.4

Explanation:

tidy up of The descripfile is unchanged thus old and new descripfile
file in the call are the same. A >tidying up> of file no 4 is
wanted.

reanalyse Ex 3
example This is first call of reanalyse:
reanalyse init.yes

Explanation:

filehead There exists no database and only one descripfile. It is
called descripfile and it is desired that fileheads for
all files of type cfmaster and cflist described in this
file are created.

reextract Ex 4
example The reextract program is called in a job as
follows:

job ue 29xxxx size 35000,
perm dkxxxx 3500 1,
time 6 0

oldformat = set 100 dkxxxx 0 0 0 21.4
olddescrip = reextract
scope user oldformat
finis
\f

Explanation:

Reotab, olddescrip (the old descripfile) and the files
which are affected by the reorganization, must be
available as permanent files. Oldformat must be set as a
sq-file and must be permanent as it later will be read by
the reform program. The 3500 permanent segments
correspond to the total size of the files which in this
case will be reorganized.

reform Ex 5
example The reform program can be called in a job as
follows:

job ue 29xxxx size 35000,
perm dkxxxx 3500 1,
time 6 0
newformat = set 1 dkxxxx 0 0 0 21.4
descripfile = reform
scope user newformat
finis

Explanation:

Reotab, descripfile and oldformat must be available as
permanent files. Newformat must be set as a sq-file and
must be permanent as it later will be read by the
reinsert program.

reinsert Ex 6
example The reinsert program can be called in a job as
follows:

job ue 29xxxx size 80000,
perm dkxxxx 3500 5,
area 13,
temp disc 6000 20,
time 10 0

; here new and reorganized files can be set.

descripfile = reinsert
; scope user of created files

finis

Explanation:

Reotab, descripfile and newformat must be available as
permanent files. Reorganized files and fileheads for new
files are created (preferably on drum or disc), if they
are not already set or found in a non-reorganized
edition. In the latter case the original files will be
reused and cut down to the minimum length.

reinsert Ex 7
example If you lack resources on the usual disc, you
supply with your private workdisc and call
reinsert in this way:

job ue 29xxxx size 80000,
perm dkxxxx 3500 5,
area 13,
temp disc 500 5,
temp dkwork 6000 20,
time 10 0
; set new and reorganized files here \f

work. descripfile = reinsert work.dkwork
.clear newformat.newformat.clear
; scope user of created files

Explanation:

Everything works as in example 6 except the following:
the temporary workareas will be created on the
disc dkwork and the file newformat will be cleared
as soon as all the records are read from it.

reextract, Ex 8
reform re- In this example reextract, reform and reinsert are run in
insert the same job:
example
job ue 29xxxx size 20000,
perm dkxxxx 2000 3,
temp disc 7000 20 time 12 0,
area 13

oldformat = set 1 disc 0 0 0 21.4
olddescrip = reextract

newformat = set 1 disc 0 0 0 21.4
descripfile = reform
clear temp oldformat

; here new and reorganized files can be set

descripfile = reinsert newformat.newformat.clear
scope user - - -

finis

Explanation:

Reotab, olddescrip and descripfile are implied available.
Besides, other commentaries should be superfluous. See
the examples 4, 5, 6 and 7. \f

7_._ _ _ _ _ _ _ _ _ _ _ _ _ _R_U_N_ _J_O_U_R_N_A_L_

run This chapter describes the run journals which are produced
journal by all programs and printed on current output.

The chapter is split up into 4 parts, describing the run
journal for one program each, and each part starts with some
overall description before the messages are listed in number
order and described.

The run journal is an account of the run progress, given in
the form of error messages and information about the number
of read and written records plus which database files that
are affected.

All messages are identified by a unique message number.

-error- In case of an error message (the line starts with the word
-error-) you can>t go on but must try to find the reason for
the error and correct it before a rerun.

*system error* In case of a line starting with the phrase *system error* RC
myst be contacted.

7_._1_ _ _ _ _ _ _ _ _ _ _ _ _R_e_a_n_a_l_y_s_e_ _R_u_n_ _J_o_u_r_n_a_l_

reanalyse The run journal from reanalyse consists of up to four main
messages parts under the following head lines:

survey of affected files
results of analysis
errors
hard error

Within each part, the individual messages are sorted accord-
ing to some criteria, described later. The last line of the\f

run journal will be one of the following, depending on the
result of the analysis.

creation of No illegal amendment found, reotab created.
reotab No amendment found, reotab not created.
Illegal amendment found, reotab not created.

Note: Only when reotab is created is it possible to continue
the reorganization.

7_._1_._1_ _ _ _ _ _ _ _ _ _ _S_u_r_v_e_y_ _o_f_ _a_f_f_e_c_t_e_d_ _F_i_l_e_s_

survey of At this point survey information about for example the files
affected which should be reorganized and which are to be created is
files printed.

There will be one line per file, and one line per list, at
most.
Sorting criterium is the sysdok reference.

List of messages:

1: the file <file name' must be removed

The mentioned file is not included in the new descripfile
and thus must be removed from the database.

The actual reorganization may be started if there are no
system errors.

2: the file <file name' must not be reorganized

The descripfile is altered and the file should thus be
reorganized, but via fp-adaption reorganization has been
prohibited.
\f

3: the file <file name' must be created, block length:
<blocklgt'

A filehead for the mentioned file of the type cfmaster,
cflist or outvar is to be created. This will be done in the
phase of reorganization. The block length is the blocklength
measured in segments with which the file should be created.

The actual reorganization can be started as far as no error:
messages occur.

4: the file <file name' must be reorganized, block length
<blocklgt'

The file must be reorganized, either because its description
is changed or because it is required via fp-adaption. The
blocklength is the blocklength with which the new file is
created.

The actual reorganization can be started as far as no error
messages occur.

7_._1_._2_ _ _ _ _ _ _ _ _ _ _R_e_s_u_l_t_s_ _o_f_ _A_n_a_l_y_s_i_s_

results of At this point information about the amendments, which have
analysis been found in the descripfile, is printed. The only relevant
amendments are those which can have influenced a reorgani-
zation.

This part will normally be the biggest one, and therefor it
is split up according to the sorting criteria:

1. logical file number
2. record type number
3. list numberand
4. sysdok reference. \f

Thus the messages become structured in 4 levels in this way:

Level:
1: the whole db
messages concerning a whole file at a time

2: per logical file
messages concerning the whole log.file

3: per recordtype in current log.file
messages concerning userfields in this recordtype

4: per list in current record type
messages concerning keyfields belonging to this list

There are special headlines to denote which logical file,
record type and list the following messages concern:
M_
1
P_ 20: logical file number: <lf no' record type number: <no'
0

Denotes that the following results will concern this logical
file and, if given, this record type.

Note: Starting with version 7 of reorgprograms, this message
will be replaced by the following two:

20: logical file number: <lf no'

Denotes that the following results will concern this logical
file.

21: record type number: <rec.type no.'

Denotes that the following results will concern this record
type.
\f

Note: The record type number >-13> is used for the initial
dummy record of a cfmaster file.

22: list number: <list no'

Denotes that the following results concern keyfields belong-
ing to the list mentioned.

In this special case the sysdok-references will be

a) for fields in cf-masterfiles:
the sysdokreference for the list
b) for fields in cf-listfiles:
the sysdokreference of the mother
field corresponding to this chainfield.

L_i_s_t_ _o_f_ _m_e_s_s_a_g_e_s_:

30: no-mref changed to mref

The list description where no-mref (without mother
reference) is changed to mref (with mother reference).
Reorganization of daughter file.

31: file description removed

The file description is only found in the old descripfile.
Possible reorganization.

32: file description changed

One or more amendments have been found in the description of
the file concerned. It could for example be amendment of
min-, norm- or segs, blocklength or if the file type is cf
master an amendment of the key description or segs _pr _buck.
A part of these parameters may be calculated by DATABASE80,
and thus the user can not always see what actually has been
changed.
Reorganization.\f

33: list description removed

The list description only exists in the old descripfile.
Reorganization of mother file and possible daughter file.

34: new file description inserted

New file is described.
Reorganization.

35: new list description inserted

New list is described.
Reorganization of mother file and possible daughter file.

36: key size of mother file changed

The key size of the mother file is changed.
Reorganization of mother- and daughter file.

37: list sequence changed

The sequence in the description of lists in a connection- or
network structure is changed so that the primary list is no
longer the same.
Reorganization.

50: new logical file description inserted

New logical file is described.

51: logical file description removed

The logical file description only exists in the old
descripfile.
Possible reorganization. \f

52: primary list changed

The primary list in the description of a logical file is
changed.
Reorganization.

53: record type description removed

The record type description only exists in the old
descripfile.
Reorganization.

54: new group description inserted

New group is described.

55: group removed from record type

The group is no longer, according to the description, meant
to be included in the record type.
Reorganization.

56: field address changed

The address of the field concerned is changed.
Reorganization.

57: field description changed

One or more amendments have been found in the description of
the field concerned. It may for example be amendment of
field type, dim, repr, or amendment with regard to adm.
status ident.
Reorganization.

58: field description removed

The description of the field is only existing in the old
descripfile. \f

Reorganization if it is not an equivalence field or field
type mref or list.

59: new field description inserted

New field is described.
Reorganization, if it is not an equivalence field or the
field type is mref or list.

7_._1_._3_ _ _ _ _ _ _ _ _ _ _E_r_r_o_r_s_

error found This list contains information about errors; that is,
by reanalyse illegal amendments in the descripfile. You must not go on
with the run before these are corrected and the reanalyse
program has been rerun:

Sorting criterium is the sysdok reference.

L_i_s_t_ _o_f_ _m_e_s_s_a_g_e_s_:

100: -error- a file of type cf list
must not be motherfile

The file mentioned is described as motherfile of a list.
This is not allowed in reorg80.

If you want to reorganize the other files of the database,
then exclude both mother- and daughterfile of a listfile-
to-listfile construction by using the calling parameter:
reanalyse ... noreorg.<m.file no'.<d.file no'

101: -error- daughter file no changed

The daughter file no. of the list description is changed
(stated indirectly by the user via daughter logical file
name). \f

102: -error daughter logical file no changed

The daughter logical file no of the listdescription is
changed.

103: -error- field type changed

Illegal amendment of fieldtype is found. Which means change
from or to aggregate, list or mref.

104: -error- group type changed

The type of the group is changed from an ordinary to a
repeating - or the other way round.

105: -error- field in repeating group moved

A field description is moved f_r_o_m_ a repeating group to
another part of a record type.

106: -error- file type changed

The type of the file is changed.

107: -error- included logical file missing

One or more (but not all) logical files are removed in the
new file description.

108: -error- list reference changed

List reference (list name) in the description of field of
the type dref or mref is changed.

110: -error- mother file no. changed

The mother file no of the list description is changed
(stated indirectly by the user via the mother logical file
name).\f

111: -error- mother logical file no. changed

The mother logical file no of the list description is
changed.

112: -error- logical file type changed

The type of the logical file is changed.

7_._1_._4_ _ _ _ _ _ _ _ _ _ _H_a_r_d_ _e_r_r_o_r_

Most of the hard errors will cause the program to stop at
once, without printing the run journal. These errors are
described in chapter 8, as they may occur in all reorg80
programs.

But there are some few kinds of hard errors which can be
detected by reanalyse in good time. When reanalyse meets one
of them, the run journal will be printed out, however
unsorted, and the last message will be the hard error
message. Then the program will terminate.

L_i_s_t_ _o_f_ _p_o_s_s_i_b_l_e_ _h_a_r_d_ _e_r_r_o_r_ _m_e_s_s_a_g_e_s_:

180: dimension error - more lists than <no of lists',
increase size-parameter

181: dimension error - more recordtypes in one register
than <no of rectypes',
increase size-parameter

See chapter 6.1 concerning the size-parameter.

*system error* ....

Contact the system80 group of RC \f

7_._2_ _ _ _ _ _ _ _ _ _ _ _ _R_e_e_x_t_r_a_c_t_ _R_u_n_ _J_o_u_r_n_a_l_

The run journal from reextract gives an account of the
records read from the different files and written in the
oldformat file.

L_i_s_t_ _o_f_ _m_e_s_s_a_g_e_s_:

200: number of records in the file: <file name' read: <number',
written: <number'

Information about how many records per file are read and how
many that are written in the oldformat file.

L_i_s_t_ _o_f_ _e_r_r_o_r_ _m_e_s_s_a_g_e_s_:

250: -error- record type does not belong to current file
<record type no' <file name'

In the file to be reorganized or deleted, a record is found
with a record type which is described as belonging to
another file. The record concerned is printed b_e_f_o_r_e_ the
error message.
The record is skipped.

251: -error- unknown record type <record type no'<file name'

In the file to be reorganized or deleted, a record is found
with a record type which is not described in the descripfi-
le. The record concerned is printed b_e_f_o_r_e_ the error message.
The record is skipped.

It is up to the user to decide whether reorganization shall
continue after these errors. \f

7_._3_ _ _ _ _ _ _ _ _ _ _ _ _R_e_f_o_r_m_ _R_u_n_ _J_o_u_r_n_a_l_

reform The run journal from reform will be empty unless errors
messages occur.

L_i_s_t_ _o_f_ _m_e_s_s_a_g_e_s_:

350: -error- field type change: <old type'
to <new type' causes overflow,
recordtype: <rec type no'

The new field contents will be the greatest possible number.

The user can check the field changes in the record concerned
(e.g. in the reanalyse run journal) to decide which field
causes the error.

It is up to the user to decide whether reorganization shall
continue after this error.

7_._4_ _ _ _ _ _ _ _ _ _ _ _ _R_e_i_n_s_e_r_t_ _R_u_n_ _J_o_u_r_n_a_l_

The run journal from reinsert gives an account of, how the
files are created and how many records there are inserted
into each of them.

Besides resource problems, there may be some errors with
records which cannot be inserted or connected correctly.
These errors may, originate in some undetected inconsisten-
cies in the old database. The user is advised to have a look
at these records after the reorganization is finished and
possibly repair and reinsert them explicitly.
\f

L_i_s_t_ _o_f_ _m_e_s_s_a_g_e_s_:

400: temporary file created, file no. and name <file no'
<file name'

A file with the number and name stated in the message
created on scope temp by the program.

401: filehead created, file no. and name: <file no'
<file name'

A filehead is created.

402: number of records in the file <fileno',read: <number'
, written: <number'

Information per file about how many records are read from
the new format file and how many that are written in any new
reorganized file.

403: no records in file to be reorganized file no.: <file no'

The file concerned, which was to be reorganized, is empty.

404: total number of records read: <number'

Number of records read in the new format file.

L_i_s_t_ _o_f_ _e_r_r_o_r_ _m_e_s_s_a_g_e_s_:

450: -error- the file can>t be created, file no., result:
<file no'<result'

Probably, resources on the disc on which the file with the
current number is created are lacking.
The run is terminated. \f

451: -error- the file can>t be extended, file no.,resultcf:
<file no'<result'

Probably, resources on the disc on which the file with the
current number is created are lacking.
See RCSL 28-D5, Connected Files System concerning extend _cf.
The run is terminated.

452: -error- record is already existing in file no: <file no'

There exist more records with identical identification after
reform.

456: -error- worknames exceeded, number = <no'

The worknames procedure can only create 999 worknames.
Try to split up reorganization by means of the parameter
noreorg. <file no'

457: -error- workfile cannot be created on: <discname'

It is impossible to create the necessary workfiles on the
disc specified by:

workkit.<discname'

458: -error- mother record not found, m.file, d.file:
<m.filename' <d.filename' list: <list no'

When inserting records in the listfile, a record points to a
motherrecord which cannot be found.
The error message is continued with some information which
serves to identify records and which should be sent to the
System80-group at RC:

- a printout of the mref - or insert record, \f

- a printout of the first part of the current
motherrecord
- the summary following:

total number of not satisfied references:<no'

After this error, the run is not terminated, but the records
mentioned are not inserted into the database, or they are
not connected to one of their chains. But the database will
be consistent.
You should contact the system80-group and discuss what to do
with the records causing this error.\f

8_._ _ _ _ _ _ _ _ _ _ _ _ _ _H_A_R_D_ _E_R_R_O_R_

This section deals with those errors which are so grave that
the run is terminated.

Errors can occur at various points in the run and in diffe-
rent parts of the software. They are divided into the fol-
lowing sections:

8.1 errors in the call parameters
8.2 errors due to lack of resources
8.3 errors from the cf-system
8.4 errors from the sq-system
8.5 run time errors

8_._1_ _ _ _ _ _ _ _ _ _ _ _ _E_r_r_o_r_s_ _i_n_ _t_h_e_ _C_a_l_l_ _P_a_r_a_m_e_t_e_r_s_

Each time a reorg80-program starts running, the fp-para-
meters are printed from the beginning and simultaneously
checked.

If there is an error in a parameter, the sign combination
below is printed immediately after it:

<*'

Then the rest of the parameters in that group follow (see
section 6 call), without being checked. The checking-up is
resumed by the next parameter group.

If a parameter group is terminated too early by the next pa-
rameter group, the error-mark below will appear:

<*<

After the keyword for the next parameter group. This group\f

will be treated in the normal way.

If an error has occured, the print-out of the fp-parameters
is followed by the line:

*** error in fp-parameters: <n' errors detected

where <n' is the number of error-marks.

The run is then terminated with:

end <progname' ...
*** error 1 ....

8_._2_ _ _ _ _ _ _ _ _ _ _ _ _E_r_r_o_r_s_ _d_u_e_ _t_o_ _L_a_c_k_ _o_f_ _R_e_s_o_u_r_c_e_s_

In connection with the opening of various files hard errors
may occur, causing the error-message:

bytes 0 line ....
called from ...
device status ***device status <name'
M_ *
status
P_1

The important lines to notice are the last lines including
<name' and <status' (see system 3 utility Programs, Part
One; sections 6 and 7).

E.g. <status':

process does not exist.

can mean, either that the file does not exist, or that the
job has not specified the resource >area> adequately (see\f

Boss 2 - User>s Manual, section 2).

<status':

end of document

means that the job has not got segments enough for the file
in question (see section 6.5, use of resources).

8_._3_ _ _ _ _ _ _ _ _ _ _ _ _E_r_r_o_r_s_ _f_r_o_m_ _t_h_e_ _C_f_-_S_y_s_t_e_m_

For cf-master files, errors can occur either because the
contents of the file is incorrect:

buflengthcf ***buflengthcf

and

prep _i prep _i

or because the file is not correctly updated:

protect _Cf ***protectcf alarm:
updmark 1

These errors are described in (ref (2), appendix A).

8_._4_ _ _ _ _ _ _ _ _ _ _ _ _E_r_r_o_r_s_ _f_r_o_m_ _t_h_e_ _s_q_-_S_y_s_t_e_m_

These errors have the format:

*** <sq-procedure' on: <filename'
<errortext' <n'

For a more detailed description, see ref (3).\f

The errortexts most likely to occur are:

contents contents <n'

the catalog entry has an illegal contents value. <n' is the
value found. Maybe a wrong filename is used.

Note: Both oldformat and newformat must have contents 21.

create create 4

This means that resources are lacking for the creation of
the work file <filename'. The situation is managed by
extending the resource temp disc in the job line.

s.length s.length 0

Can be due to, either that the oldformat-file has
disappeared, or that it has the wrong contents.

sq-sum sq-sum <n'

The file has been violated.

8_._5_ _ _ _ _ _ _ _ _ _ _ _ _R_u_n_ _T_i_m_e_ _E_r_r_o_r_s_

These errors include field-, index-, case-, and stack-errors
from the running program, i.e. errors of the type:

field 1793 line 107-109
called from line .....
....

Normally this is a program error.

It may also be due to a machine error, so one should repeat
the run as a precautionary measure before sending the error
report in.\f

When a >field> or >index> alarm occurs in running the
reanalyse program, this could mean that the upper limit of
an internal table has been exceeded. This situation can be
avoided by means of the fp-parameter:

size. <increase percentage'

in a rerun (see section 6.1).

Concerning the error:

stack stack

it should be mentioned that it may occur if the resource
>size> has not been specified large enough, or because size
is omitted in the job line so that one is running with
standard size. \f

9_._ _ _ _ _ _ _ _ _ _ _ _ _ _D_A_N_I_S_H_ _A_P_P_E_N_D_I_X_

I dette kapitel beskrives dels de danske nøgleord og stan-
dard filnavne, dels de danske tekster i kørselsjournalerne.
Alt andet end nøgleord og tekster er kun beskrevet i den
engelske del af manualen.

sprog Alle REORG80-programmer accepterer både engelske og danske
nøgleord i kaldene. Derimod fastlægges sproget for standard-
navnene og for teksterne ved en særlig katalogindgang som
bruges af alle værktøjsprogrammer.
Indgangen s_8_0_i_n_s_t_m_o_d_e_ er beskrevet i følgebrevet til værk-
tøjssystembånd, version 3.

9_._1_ _ _ _ _ _ _ _ _ _ _ _ _K_e_y_w_o_r_d_s_ _i_n_ _P_r_o_g_r_a_m_ _C_a_l_l_s_

Her er syntaksen for alle nøgleord og alle standardnavne
remset op.
Beskrivelsen skal derimod søges i den engelske del af
manualen, kap. 6.1-6.4. For hver dansk parameter er den
tilsvarende engelske anført nedenunder.

K_a_l_d_ _a_f_ _r_e_a_n_a_l_y_s_e_

reanalyse
kald nybeskriv
glbeskriv
init
analyseD_D_*
reanalyse fil .<parametre' D_D_1
individ
reotab
felt
orden
size
test
testud \f

Ingen parametergruppe er obligatorisk.

nybeskriv nybeskriv .<nyt db-registernavn'

engelsk: newdescrip

Standard: nybeskriv.beskrivreg

glbeskriv glbeskriv. <gl db-registernavn'

engelsk: olddescrip

Standard: glbeskriv.glbeskriv

M_init ja U_U_U_1D_D_D_
init.
P_nej D_D_D_1U_U_U_

engelsk: init

Standard: init.nej

M_cf U_U_U_1
analyse analyse. outvar
P_all D_D_D_1

engelsk: analyse

Standard: analyse.cf

M_*2
fil fil .<reorgmarkering' .<filnummer'
P_ 11

engelsk: file

<reorgmarkering'\f

reorg
ejreorg

engelsk: reorg, noreorg

Standard: Ændring i db-beskrivelsen, som medfører en ændring
i en fils indhold, bevirker reorganisering af
denne.

M_individ *
individ .<individtypenummer'
P_1

engelsk: record

Standard: Alle i-typer i en fil reorganiseres, hvis filen
reorganiseres.

reotab reotab .<reotab navn'

engelsk: reotab

Standard: reotab.reotab

M_ felt nummer 1
felt .
P_ navn 1

engelsk: field

Standard: felt.nummer

M_ orden *
orden .<kæde nummer'
P_1

engelsk: order

Standard: Listefilindivider indsættes, sorteret efter ident-
felterne.\f

size size .<procent forøgelse'

engelsk: size

Standard: size.0

M_ test ja U_U_U_1
test .
P_nej D_D_D_1

engelsk: test

Standard: test.nej

M_ testud 1
testud. <testud fil navn' .extend
P_ 0

engelsk: testout

Standard: testud.testud

K_a_l_d_ _a_f_ _r_e_e_x_t_r_a_c_t_

M_ reextract reotab*
kald <gl beskriv'= reextract .<parameter'
P_ glformat0

<glbeskriv' <glbeskriv'
<gl db-registernavn'

engelsk: <olddescrip'

reotab reotab .<reorgtabel-navn'

engelsk: reotab

Standard: reotab.reotab \f

glformat glformat .<udfil-navn'

engelsk: oldformat

Standard: glformat.glreorgfil

K_a_l_d_ _a_f_ _r_e_f_o_r_m_

reformkald reotab*
<venstre side' = reform glformat .<parameter'
nyformat0

<venstre side' <venstre side'

<gl dbregisternavn'
<ny dbregisternavn'

engelsk: <left side'

reotab reotab .<reorgtabel-navn'

engelsk: reotab

Standard: reotab.reotab

glformat glformat .<indfil-navn'

engelsk: oldformat

Standard: glformat.glreorgfil

nyformat nyformat .<udfil-navn'

engelsk: newformat

Standard: nyformat.nyreorgfil\f

K_a_l_d_ _a_f_ _r_e_i_n_s_e_r_t_

reinsert kald reotab U_U_U_*
M_m_m_ nyformat
<nybeskriv' = reinsert .<parameter'
P_p_p_ work
workkit D_D_D_0

<nybeskriv'
<nybeskriv' <nyt db-registernavn'

engelsk: newdescrip

reotab reotab .<reorgtabelnavn'

engelsk: reotab

Standard: reotab.reotab

M_ nyformat 1
nyformat .<indfil-navn' .clear
P_ 0

engelsk: newformat

Standard: nyformat. nyreorgfil

M_m_m_ work work
.<discnavn'
P_p_p_workkit workkit

engelsk: work, workkit

Standard: work.disc

9_._2_ _ _ _ _ _ _ _ _ _ _ _ _R_u_n_ _J_o_u_r_n_a_l_

I de følgende afsnit findes en liste over alle meddelelser
der kan komme fra de 4 programmer.

Alle meddelelser er identificeret med et ntydigt nummer.

Teksterne vil ikke blive forklaret, med mindre det er meget
væsentlige og ikke selvforklarende tekster. Ellers kan
forklaringen findes under de tilsvarende engelske
meddelelser.

-fejl- Hvis der kommer en fejludskrift, startende med -fejl-, må
man ikke køre reextract, men rette fejlårsagen og køre
reanalyse om.

*prgfejl* Hvis der kommer en programfejl, startende med *prgfejl* skal
man kontakte værktøjsgruppen på RC.

9_._2_._1_ _ _ _ _ _ _ _ _ _ _R_e_a_n_a_l_y_s_e_ _R_u_n_ _J_o_u_r_n_a_l_
R_e_a_n_a_l_y_s_e_ _K_ø_r_s_e_l_s_j_o_u_r_n_a_l_

reanalyse Kørselsjournalen kan bestå af op til fire dele med følgende
kørsels- overskrifter og i den nævnte rækkefølge:
journal
Oversigt over berørte filer
analyseresultater
fejl
alarm

dannelse Sidste linie i kørselsjournalen er en af følgende:
af reotab
ingen ulovlig ændring fundet, reotab dannes
ingen ændring fundet, reotab dannes ikke
ulovlig ændring fundet, reotab dannes ikke
\f

B_e_m_æ_r_k_:

Kun når reotab er dannet, er det muligt at køre videre.

Oversigt O_v_e_r_s_i_g_t_ _o_v_e_r_ _b_e_r_ø_r_t_e_ _f_i_l_e_r_
over berørte
filer Der udskrives højst n linie per fil og n linie per liste,
udskrifterne sorteres efter sysdokreferencen.

1: filen <filnavn' skal fjernes

2: filen <filnavn' må ikke reorganiseres

3: filen <filnavn' skal oprettes, bloklængde: <bloklgd'

4: filen <filnavn' skal reorganiseres, bloklængde: <bloklgd'

A_n_a_l_y_s_e_r_e_s_u_l_t_a_t_e_r_

analyse Denne del vil normalt omfatte mange meddelelser og den er
resultaterdelt op for at gøre den mere overskuelig. Sorteringskriteria
for meddelelserne er:

1: registernummer
2: individtypenummer
3: kæde nummer og
3: sysdokreference

Meddelelserne bliver struktureret på denne måde:

1: hele databasen
meddelelser vedrørende en hel fil ad gangen\f

2: per register
meddelelse vedrørende hele registret

3: per i-type i det aktuelle register
meddelelse vedrørende brugerfelter i
i-typen

4: per kæde i den aktuelle i-type
meddelelse vedrørende nøglefelter
hørende til kæden.

Specielle overskrifter viser, hvilket register, hvilken
i-type og hvilken kæde de efterfølgende meddelelser drejer
sig om.

M_1
20: registernummer: <regnr' individtype: <no'
P_0

De efterfølgende medd. drejer sig om dette register og evt.
angivne individ type.

B_e_m_æ_r_k_: Fra og med version 7, erstattes denne overskrift af
følgende to:

20: registernummer: <regno'

21: individtype nummer: <itypeno'

22: liste nummer: <liste nr'

De efterfølgende medd. drejer sig om kædefelter til denne
kæde.
\f

I dette tilfælde vil sysdokreferencen være:

a) for felter i cf-masterfilen:
sysdokreferencen for liste-beskrivelsen.

b) for felter i cf-listefiler:
sysdokreferencen for det felt i moderen som svarer til
dette kædefelt.

Ø_v_r_i_g_e_ _m_e_d_d_e_l_e_l_s_e_r_:

30: ejref ændret til mref

31: filbeskr fjernet

32: filbeskr ændret

33: listebeskr fjernet

34: ny filbeskr indsat

35: ny listebeskr indsat

36: nøglelængde for moderfil ændret

37: listerækkefølge ændret

50: ny registerbeskr indsat

51: registerbeskr fjernet

52: primærliste ændret

53: individtypebeskr fjernet

54: ny feltgruppebeskr indsat

55: feltgruppe fjernet fra individtypen

56: feltadresse ændret

57: feltbeskr ændret

58: feltbeskr fjernet

59: ny feltbeskr indsat

F_e_j_l_

fejl Her gives en meddelelse for hver ulovlig ændring.

Sorteringskriterium er sysdokreferencen.\f

100: -fejl- en fil af type cf-list må
ikke være moderfil

Hvis du skal reorganisere andre filer i databasen, skal du
udelukke både moder- og datterfilen i en
listefil-til-listefil konstruktion ved at bruge
fp-parametren:

reanalyse .... ejreorg.<m.filnr'.<d.filnr'

101: -fejl- datterfilnr ændret

102: -fejl- datterregisternr ændret

103: -fejl- felttype ændret

104: -fejl- feltgruppetype ændret

105: -fejl- felt i rep. feltgr. flyttet

106: -fejl- filtype ændret

107: -fejl- indg. register mangler

108: -fejl- listehenvisning ændret

110: -fejl- moderfilnr ændret

111: -fejl- moderregisternr ændret

112: -fejl- registertype ændret

alarm A_l_a_r_m_

Der er hårde fejl som reanalyse kan opdage, men som bevirker
at kørslen ikke kan fortsættes.

Kørselsjournalen bliver så skrevet ud, omend usorteret, og
den sidste meddelelse vil være den der beskriver den hårde
fejl.

Læs iøvrigt kap. 8 om hårde fejl.

180: dimensionsfejl - der er flere kæder end <antal kæder'
sæt size-parameter op

181: dimensionsfejl - der er flere ityper i et register
end <antal ityper'
sæt size-parameter op

*prgfejl* ......

Henvend dig til værktøjsgruppen på RC. \f

9_._2_._2_ _ _ _ _ _ _ _ _ _ _R_e_e_x_t_r_a_c_t_ _R_u_n_ _J_o_u_r_n_a_l_
R_e_e_x_t_r_a_c_t_ _K_ø_r_s_e_l_s_j_o_u_r_n_a_l_

reextract Kørselsjournalen giver en oversigt over antal poster læst
kørsels- fra de forskellige filer og skrevet i filen glformat.
journal
200: antal individer i filen: <filnavn' læst: <ant', skrevet: <ant'

fejlmeddelelser:

250: -fejl- itype tilhører ikke aktuel fil <itypenr'<filnavn'

I en fil, som skal reorganiseres eller slettes, er fundet et
individ med en individtype, som er beskrevet som hørende til
en anden fil. Det pågældende individ skrives ud f_ø_r_
fejludskriften. Individet skippes.

251: -fejl- ukendt individtype <itypenr'<filnavn'

I en fil, som skal reorganiseres eller slettes, er fundet et
individ med en individtype, som ikke er beskrevet i
db-beskrivelsen. Det pågældende individ skrives ud f_ø_r_
fejludskriften. Individet skippes.

Det er op til brugeren at afgøre, om reorganiseringen skal
fortsætte efter disse fejl.

9_._2_._3_ _ _ _ _ _ _ _ _ _ _R_e_f_o_r_m_ _R_u_n_ _J_o_u_r_n_a_l_
R_e_f_o_r_m_ _k_ø_r_s_e_l_s_j_o_u_r_n_a_l_

reform Kørselsjournalen vil være tom med mindre der er fejl.
kørsels-
journal 350: -fejl- typeændring: <gl type' til <ny type'
giver overflow,
individtype: <itypenr'\f

Det nye feltindhold vil være det størst mulige tal. Brugeren
kan checke feltændringerne i den pågældende individtype (f.x. i
reanalyse kørselsjournalen) for at se hvilket felt der forårsager
fejlen.

Det er op til brugeren at afgøre om reorganiseringen skal
fortsætte.

9_._2_._4_ _ _ _ _ _ _ _ _ _ _R_e_i_n_s_e_r_t_ _R_u_n_ _J_o_u_r_n_a_l_
R_e_i_n_s_e_r_t_ _K_ø_r_s_e_l_s_j_o_u_r_n_a_l_

reinsert Kørselsjournalen beskriver forløbet af reinsert.
kørsels-
journal Mulige fejlårsager er resource problemer eller poster, der
ikke kan indsættes eller connectes korrekt. Dette kan
skyldes uopdagede konsistensfejl i den gamle database.

Det tilrådes at brugeren efter kørslen kigger på disse
poster og afgør om de evt. skal rettes og genindsættes
explicit.

400: temporær fil oprettet, filnr og -navn:
<filnr'<filnavn'

401: filhoved oprettet, filnr og -navn: <filnr'<filnavn'

402: antal individer i filen: <filnr' læst: <ant'
skrevet: <ant'

403: ingen individer i fil, som reorganiseres, filnr: <filnr'

404: samlet antal individer læst: <antal'\f

450: -fejl- filen kan ikke oprettes, filnr, resultat

451: -fejl- filen kan ikke udvides, filnr, resultat

Se evt. ref. 2, angående extend-cf.

452: -fejl- individ findes i forvejen i filnr: <filnr'

456: -fejl- for mange arbejdsfiler, filnr: <nr'

Der kan kun dannes 999 arbejdsnavne. Split reorganisationen
op v.h.a. parametre noreorg .<filnumre'

457: -fejl- arbejdsfil kan ikke oprettes på <discnavn'

458: -fejl- moderpost ukendt, moderfil, datterfil:
<m-filnavn'<d-filnavn', kæde: <kædenr'

En listefilpost peger på en ukendt moderpost.
Fejlmeddelelsen efterfølges af en udskrift som identificerer
posterne og som skal sendes til system80 gruppen på RC.

- en udskrift af mref eller insertposten,
- en udskrift af starten af det aktuelle moderfilindivid,
- følgende afslutning:

total number of not satisfied references: <antal'

Efter denne fejl fortsætter kørslen, men de omtalte listefil-
poster er enten ikke indsat eller ikke connected til en af
mødrene. Den reorganiserede database er dog konsistent og
kan bruges. Brugeren skal kontakte system80-gruppen på RC og
afklare hvordan posterne skal behandles. \f

1_0_._ _ _ _ _ _ _ _ _ _ _ _ _I_N_D_E_X_

adaption 7
analyse 19

change of array length 11
change of cf-list files 14
change of field name 14
change of field number 14
change of field type 11
change of file number 14
change of group number 14
change of ident-fields 13
change of keyfields 12
change of list sequence 12
change of logical fileno 14
change of primary list 12
change of record typenumber 14
change of simple field to array field 12
change of text field length 12
change of the number of decimals 12
corresponding logical files 16
creation of reotab 36

Danish appendix 55
division of reorganization 4

errors 35, 42
errors due to lack of Resources 51
errors found by reanalyse 42
errors from the Cf-System 52
errors from the Sq-System 52
errors in Call Parameters 50
examples of program call 30
exclusion of files 7 \f

f-bits, moving of 11
field, insertion of 10
field name, change of 14
field number, change of 14
field, removal of 10
field type, change of 11
file for future amendments 16
filehead creation 9, 31
file, insertion of 9
file numbers, change of 14
file, removal of 10
fp-adaption 7, 17

group, insertion of 9
group, removal of 10
groups, repeating 14

hard error 44, 50

initialization 2
insertion of a field 10
insertion of a group 9
insertion of a file 9
insertion of a list 9
insertion of a logical file 9
insertion of a record type 9
insertlist 5

limitations 14
list sequence, change of 12
list-to-listfile 8

moving of a field 10
moving of f-bits 11

negative keyfields 14
new format 17
\f

oldformat 17
operating guide 14

phase of analysis 4
phase of reorganization 4
programcall, examples 30
purpose 2

reanalyse 4
reanalyse call 18
reanalyse, examples of 30, 31
reanalyse messages 35
reanalyse run journal 35
record order 6
record type, insertion of 9
record type number, change of 14
record type, removal of 10
reextract 4
reextract call 23
reextract, example of 31, 34
reextract run journal 45
reform 4
reform call 24
reform, example of 32, 34
reform run journal 46
reinsert 5
reinsert call 26
reinsert, examples of 33, 34
reinsert run journal 46
reinsertion of cf-listfiles 5
removal of a field 10
removal of a file 10
removal of a group 10
removal of a list 12
removal of a logical file 10,14
removal of a record type 10
REORG80 programs 4 \f

repeating groups 14
requirements 2
result of analysis 37
run journal 35
run time errors 53

specifications 9
survey of affected files 36
sysdok references 37
system error 35

tidy up a file 3, 7, 9, 31

use of resources 27
use of the system 2

Timeforbrug:

800203 2 timer BE
\f

T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_

1. INTRODUCTION ........................................... 1

2. PUT PROCEDURES ......................................... 2
2.1 Putnumber ......................................... 2
2.2 Putfixed .......................................... 5
2.3 Putchar ........................................... 6
2.4 Puttext ........................................... 7

3. GET PROCEDURES ......................................... 10
3.1 Getnumber ......................................... 10
3.2 Getfixed .......................................... 16
3.3 Getchar ........................................... 17
3.4 Gettext ........................................... 17

4. TEXT COMPARISON ........................................ 21
4.1 Comparetext ....................................... 21

5. ERROR HANDLING ......................................... 23
5.1 Putgeterror ....................................... 23
5.2 Alarm Messages .................................... 24

6. PROGRAMMING EXAMPLES ................................... 25
6.1 Concatenating of Text Strings ..................... 25
6.2 Extraction of a Substring ......................... 25
6.3 A Text Compared with a String ..................... 26
6.4 Conversion of String Format ....................... 26
6.5 Conversion of Characters in a String .............. 26
6.6 Reading of Punched Cards .......................... 27

A_P_P_E_N_D_I_X_:

A. REFERENCES ............................................. 31
\f

ii
\f

1_._ _ _ _ _ _ _ _ _I_N_T_R_O_D_U_C_T_I_O_N_ 1.

This manual describes a set of procedures intended for handling
of text strings in ALGOL programs.

Text strings may be packed into arrays of type boolean, long or
real by means of the procedures described in chapter 2.

Chapter 3 describes some procedures for extracting a substring, a
single character, or a numeric value from a textarray.

Chapter 4 describes how to compare two text strings.

Chapter 5 contains a general description of error handling and a
list of alarm messages.

Finally, chapter 6 shows some programming examples.

The text handling procedures are designed for use in ALGOL pro-
grams, but they may also be used directly in a FORTRAN program if
no string parameters are specified. If an external ALGOL pro-
cedure using the text procedures is called from a FORTRAN pro-
gram, long text string references must be avoided.
\f

F_ 2_._ _ _ _ _ _ _ _ _P_U_T_ _P_R_O_C_E_D_U_R_E_S_ 2.

The put procedures putnumber, putfixed, putchar and puttext are
intended for generating a text string in an array in the same way
as write would output the characters through a zone.

The text may be created as a sequence of 12-bits characters in a
boolean array, or as an ordinary string of 8-bits characters in a
long or real array.

When the text is generated in a boolean array, one character is
stored in each halfword. The character is placed in the 8 least
significant bits, and the remaining bits are set equal to zero.

The characters generated by the put procedures may use the full
ISO-low and ISO-high alphabet, i.e. 0 <= char <= 255.

Neither replacechar nor outtable has any influence on the
generating of characters by the put procedures, but a character
conversion table may be stated as a parameter in the procedure
call, giving the same possibilities as a call of outtable before
write.

However, the possibility of using different characters for
leading space, space in number, and ending space by means of
replacechar does not exist in putnumber/putfixed.

2_._1_ _ _ _ _ _ _ _P_u_t_n_u_m_b_e_r_ 2.1

This integer procedure converts a numeric value into a text
string in an array, in the same way as a numeric parameter is
converted by write.

M_m_m_ 1 1
C_a_l_l_: put _number (dest, pos, conv, layout, num)
P_p_p_ 0 0
\f

put _number (return value, integer).
Shows the result of the conversion:
>=0: no. of characters inserted into dest,
=-1: conversion stopped because dest is full,
=-3: layout exceeded, see below.

dest (call and return value, array of type boolean,
long, or real).
The converted text string is inserted into this
array, see below.

pos (call and return value, integer).
As call value pos denotes the character position
into which the first character is to be inser-
ted. Pos = 1 means first character in dest(1),
so pos may be negative if lower limit of dest is
less than 1.

The return value of pos denotes the character
position after the last inserted character, so
that pos is ready for a following call of a
put-procedure.
The contents of dest outside this character
position interval are unchanged.

conv (call value, one-dimensional integer array, op-
tional parameter). If this parameter is speci-
fied, it is supposed to contain a character
conversion table, by which all characters are
converted before insertion into dest, see below.

layout (call value, string, optional parameter). An
ordinary ALGOL layout with the same format and
meaning as in write. If this parameter is
omitted, the same standard layout is used as in
write (<< _d> or << _-dd.dddd>).
\f

num (call value, integer, long or real). The value
of this parameter is converted into character
form according to the layout, in the same way as
by write.

F_u_n_c_t_i_o_n_: The characters generated by put _number are inserted
into dest depending on the type of this array. For an
array of more than one dimension the lexicografical
ordering is used.

If dest is a boolean array, the characters are
generated as so-called 12-bits characters, with one
character per array element. The characters are stored
in the 8 least significant bits, whereas the remaining
bits are set to zero. So, all character values in the
range 0<= char <= 255 may be used.

In an array of type long or real, and in a zone record,
the characters are stored as 8-bits characters with 3
characters per word (24 bits). Here, too, the full
character range 0-255 is allowed.

If dest is a zone, a zonerecord must exist, i.e.
recordlength > 0.

C_h_a_r_a_c_t_e_r_ _c_o_n_v_e_r_s_i_o_n_:
In all put procedures character conversion is totally
independent of a possible call of outtable and/or
replacechar, and the value of outindex is insignificant
as well. If no conv parameter has been specified, the
characters are never converted.

If a conv parameter has been specified, each character
is converted before insertion into dest, according to
the following algorithm:

new _char: = conv (char) extract 12;
\f

If new _char > 255 or char is not a legal index in conv,
no character is generated.

L_a_y_o_u_t_: A possible layout is specified and used in the same way
as in write, with the exception of a layout containing
"ending blanks". If the number value exceeds the range
of such a layout, write will print a * as error symbol
in the last position. Put _number will instead insert as
many characters as possible within the layout, and then
return with the procedure value -3.

E_r_r_o_r_s_: Too many parameters, or illegal parameter types will
cause a run-time alarm (param <paramno>).

A call value of pos outside the index range of dest
will cause a run-time alarm (charpos <pos>).

If dest is filled up before the number conversion is
finished, the character conversion stops, and the
procedure returns with the procedure value -1. In this
case the return value of pos denotes the first
non-existent character position in dest. So a possible
new call of a put procedure (with pos unchanged) will
give the charpos alarm above.

A negative procedure value may be changed into a
run-time alarm by means of the standard variable
'put _get _error'.

2_._2_ _ _ _ _ _ _ _P_u_t_f_i_x_e_d_

This integer procedure converts an integer or long value into a
text string in an array, giving the possibility of inserting a
decimal point in a fixed position (like writeint).
\f

M_m_m_ 1 1
C_a_l_l_: put _fixed (dest, pos, conv, layout, num)
P_p_p_ 0 0

put _fixed
dest
pos see put _number.
conv
layout

num (call value, integer or long). The value of this
parameter is converted into character form
according to layout in the same way as writeint.
I.e. if the layout contains a decimal point, a
point is inserted into the generated textstring
in the corresponding position.

E_r_r_o_r_s_: As put _number.

2_._3_ _ _ _ _ _ _ _P_u_t_c_h_a_r_ 2.3

This integer procedure inserts a single character into one or
more positions of a text string in an array.

M_m_m_ 1 1
C_a_l_l_: put _char (dest, pos, conv, char ,rep )
P_p_p_ 0 0
put _char (return value, integer).
Denotes the result:
>=0: no. of characters inserted into dest
=-1: too few characters inserted, dest is full.

dest
pos see put _number
conv
\f

char (call value, boolean or integer).
The rightmost 8 bits of char are considered a
character, which may be converted by a possible
conv parameter. The resulting character is
inserted into dest in the position denoted by pos
(and possibly following positions, see rep). The
contents of the remaining bits of char are
insignificant.

rep (call value, integer, optional parameter). This
parameter specifies how many times char is going
to be inserted into dest. If the parameter is
omitted, char is inserted just once. If rep <= 0,
nothing is inserted.

E_r_r_o_r_s_: As put _number.

2_._4_ _ _ _ _ _ _ _P_u_t_t_e_x_t_ 2.4

This integer procedure moves a text string into an array from a
string parameter or from another array, possibly after conversion
of each single character.

M_m_m_ 1 1
C_a_l_l_: put _text (dest, pos, conv, text ,length )
P_p_p_ 0 0
put _text (return value, integer).
Denotes the result:
>=0: no. of characters inserted into dest,
=-1: transfer stopped, because dest is full,
=-2: transfer stopped, because text is exhausted.

dest
post see put _number
conv
\f

text (call value, string or array of type boolean,
long, or real).
The characters are transferred one by one from
text into dest, to be stored from character
position pos and on (after possible conversion).

length (call value, integer, optional parameter). This
parameter controls the transfer as described
below.

F_u_n_c_t_i_o_n_: The contents of text are transferred one character at a
time into dest.

If text is an array of more than one dimension, the
lexicographical ordering is used. The first character
transferred is the first character of text(1). If text
is a zone, a zone record must exist, i.e. recordlength
> 0.

The array is supposed to contain a simple string of
characters. A long text string reference (as described
in ref. 1) cannot occur, as it would be interpreted
as characters.

When text is a boolean array, the characters are taken
one from each array element, using only the 8 least
significant bits.

From arrays of type long or real the characters are
taken as 8-bits characters with 3 characters per word
(24 bits).

If the text parameter is of type string, this must be a
simple string, i.e. a string constant (<:...:>), or a
simple variable referring to a string constant (a:=
long <:...:>). From a string expression like "string
ra(increase(i))" only the characters in the first array
element would be transferred.
\f

L_e_n_g_t_h_: The length parameter controls the transfer in the
following way:

If length is not specified or equals zero, characters
are transferred until either a null-character is read
from text or text is exhausted. The null-character is
not transferred.

If length > 0, e_x_a_c_t_l_y_ length characters are
transferred regardless of possible null-characters. So
the procedure works as a sort of "text-tofrom".
However, this is senseless when text is of type string,
in which case length > 0 is handled as length < 0.

When length < 0, a_t_ _m_o_s_t_ abs length characters are
transferred, the transfer stopping if a null-character
is read from text.

The character transfer may stop prematurely if text is
exhausted, or dest becomes full. In this case puttext
returns a negative procedure value.

See also the description of procedure gettext, which
transfers a text controlled by character classes
instead of by null-characters.

E_r_r_o_r_s_: As put _number.

Furthermore, the run-time alarm "index 1" will occur,
if the text parameter is an array of which the element
number one does not exist.

And the run-time alarm "string 0" occurs, if the text
parameter is of type string, but contains an impossible
long text string reference. This alarm will also occur
when a legal long text string reference is used from a
FORTRAN program (because of the differences between the
ALGOL and FORTRAN running systems).
\f

F_ 3_._ _ _ _ _ _ _ _ _G_E_T_ _P_R_O_C_E_D_U_R_E_S_ 3.

The get procedures getnumber, getfixed, getchar, and gettext are
intended for reading from a text string in an array, instead of
reading through a zone.

The reading may be controlled by character classes in the same
way as in the ordinary read procedures (read, readstring), or a
fixed number of characters may be read by specifying a "layin"
for number reading or a length for text reading.

A possible call of intable has no influence on the get
procedures, but a character conversion table may be specified
directly as an optional parameter in the procedure call.

The array from which the characters are read may contain 12-bits
characters in a boolean array, or 8-bits characters in an array
of type long or real.

If a proper conv table is specified, characters within the full
ISO-low and ISO-high alphabet may be read, i.e. 0<= char <= 255.

3_._1_ _ _ _ _ _ _ _G_e_t_n_u_m_b_e_r_ 3.1

This integer procedure converts a (part of a) text string in an
array into a numeric value.

M_m_m_ 1 1
C_a_l_l_: get _number (source, pos, conv, layin, num)
P_p_p_ 0 0
get _number (return value, integer). Denotes the result
of the conversion:
>=0: char _class shift 12 + char _value extract 12
of the last read character.
=-4: conversion stopped because source exhausted.
=-6: syntax error or number to great.
\f

source (call value, array of type boolean, long, or
real). This array is supposed to contain the
string of characters to be converted, see
below.

pos (call and return value, integer).
As call value pos denotes the character position
from which the first character is to be read.
Pos=1 means first character in source(1), so pos
may be negative if lower limit of source is less
than 1.

The return value of pos denotes the character
position after the last read character, so that
pos is ready for a following call of a get
procedure.

conv (call value, one-dimensional integer array,
optional parameter). If this parameter is
specified, it is supposed to contain a character
class table, see below. If the parameter is
omitted, the ISO standard character classes are
used.

layin (call value, string, optional parameter).
This parameter specifies, how the contents of
source should be interpreted, see below.

num (return value, integer, long, or real).
The number read from source is returned in this
parameter, which however remains unchanged, if
the result value of getnumber is negative.

F_u_n_c_t_i_o_n_: Characters are read from source depending on the array
type, and converted into a numeric value which is
returned in the parameter num. If source is a zone, a
zone record must exist, i.e. record length > 0. For an
array of more than one dimension the lexicographical
ordering is used.
\f

From a boolean array characters are read as 12-bits
characters, one from each array element. Only the 8
least significant bits are used:
char:= source(index) extract 8

From an array of type long or real characters are read
as 8-bits characters, three characters from each word.
A long text string reference cannot occur, as it would
be interpreted as characters.

All character values in the interval 0 <= char <= 255
are allowed, but if the ISO standard character classes
are used, character values > 127 will give an index
alarm, as will a character value which is not a legal
index in a specified conv table.

C_h_a_r_a_c_t_e_r_ _c_o_n_v_e_r_s_i_o_n_:

A possible call of intable has no influence on the
character conversion, nor has the value of tableindex.

If a conv parameter is specified, the array must
contain a character class table, each element composed
of a character class and a character value:
conv(char) = class shift 12 + value extract 12

Where class is an integer 0 <= class <= 4095, and value
is an integer -2048 <= value <= 2047. (See the
description of intable, ref. 2).

As character class = 1 (shift character) is useless
when tableindex is not used, such characters are
considered blind (like class = 0).

A possible EM character has no special meaning in the
get procedures, but is handled like any other
terminator.
\f

L_a_y_i_n_: The layin parameter is an ALGOL layout, allowing only a
part of the possibilities given in write. A layin is
composed of

<fill>: If <fill> is non-empty, the layin is called an "o_p_e_n_
l_a_y_i_n_", and the reading is controlled exclusively by
character classes (like procedure read). In this case
the number of d's in the layin is insignificant.

When <fill> is empty, the layin is a "c_l_o_s_e_d_ _l_a_y_i_n_",
which means that exactly so many characters are read as
indicated by the total number of positions in the
layin. This may be useful for reading position
controlled data, such as punched cards. The data field
may contain leading and/or ending delimiters (character
class >= 6), whereas any delimiter between digits is
considered a data error.

Blind characters (class <= 1) are skipped, and they are
not counted.

<first letter>: The first letter of the layin must be either b or
d.

When <first letter> is b_, the field may be empty, in
which case the num parameter remains unchanged. If the
layin is open, reading stops immediately after the
first delimiter. If the layin is closed, an empty field
may contain all delimiters.

When <first letter> is d_, a closed layin requires the
field to contain at least one digit. If the layin is
open, leading delimiters are skipped like in procedure
read.
\f

<dec.point> A possible decimal part in the layin is allowed, but
its only significance in putnumber is to tell the field
length when the layin is a closed one.

If no layin parameter is specified, the open layin
<<d _> is used.

For illustration of the effect of various layins, see
the example below.

N_u_m_b_e_r_ _s_y_n_t_a_x_:

The number is read according to the syntax of ALGOL
numbers (see ref. 1), i.e. a number may contain a
sign, decimals and/or an exponent part, which are not
specified in the layin.

E_x_a_m_p_l_e_: Suppose long array la contains the following string
from index 1 and on:

ab1234x567

The statement
get _number (la, 1, string layin, num)
will read the following values for various layins:

Open layins: last char.
<<b > num unchanged a
<<d > num:= 1234 x
<<ddd.dddd > num:= 1234 x

Closed layins:
<<b> num unchanged a
<<bd> - - b
<<bdd> num:= 1 1
<<d> syntax error a
<<dddd> num:= 12 2
<<ddd.dd> num:= 1234 4
<<ddddddd> num:= 1234 x
<<dddddddd> syntax error 5
\f

E_r_r_o_r_s_: Too many parameters, or illegal parameter types will
cause the run-time alarm "param <paramno>".

A call value of pos outside the index range of source
will cause the run-time alarm "charpos <pos>".

A layin containing illegal layout components will cause
the run-time alarm "layin 0".

If a character value is read which is not a legal index
in a specified conv table (or in the standard ISO
table), the run-time alarm "index <char value>" occurs.

If source is exhausted before the number reading is
finished, the procedure returns with the procedure
value -4, and the num parameter remains unchanged. In
this case the return value of pos denotes the first
non-existent character position in source. So a
possible new call of a get procedure (with pos
unchanged) will give the charpos alarm above.

When a syntax error is found in source, or when the
number is too great for the actual num parameter, the
return value of the procedure is -6 and the num
parameter remains unchanged. If the layin was a closed
one, the specified number of characters have always
been read. Otherwise reading continues up to and
including the first delimiter.

A negative procedure value may be changed into a
run-time alarm by means of the standard variable
'put _get _error'.
\f

3_._2_ _ _ _ _ _ _ _G_e_t_f_i_x_e_d_ 3.2

This integer procedure converts a (part of a) text string in an
array into a numeric value to be stored in an integer or long
variable. A decimal fraction may be scaled i.e. stored as an
integral number after multiplication by a power of ten.

M_m_m_ 1 1
C_a_l_l_: get _fixed (source, pos, conv, layin, num)
P_p_p_ 0 0

get _fixed
source see get _number
pos
conv

layin as get _number, see also below.

num (return value, integer or long).
The number read from source is returned in this
parameter, which however remains unchanged when
the result value of get _fixed is negative.

F_u_n_c_t_i_o_n_: The procedure works like get _number except for handling
of decimals in the layin.

In get _fixed the decimals in the layin are significant
in an open as well as in a closed layin. If the layin
contains "dec" decimals, the number read from source is
multiplied by 10**dec. So the values

12, 12.3, 12.345, -12.345

will, when read by the layin <<dd.dd _> be stored as

1200, 1230, 1235, -1235

E_r_r_o_r_s_: As get _number.
\f

3_._3_ _ _ _ _ _ _ _G_e_t_c_h_a_r_ 3.3

This integer procedure fetches one single character from a text
string in an array.

M_m_m_ 1
C_a_l_l_: get _char (source, pos, conv, char)
P_p_p_ 0

get _char (return value, integer). Contains char _class
shift 12 + char _value extract 12 after possible
conversion of the character.

source
pos see get _number
conv

char (return value, integer). The character value
(after possible conversion) of the character in
source denoted by pos. Even a blind character
(class <= 1) will be returned by getchar.

E_r_r_o_r_s_: Only the run-time alarms "charpos <pos>" and "index
<charvalue>" (as described by get _number) can occur.

3_._4_ _ _ _ _ _ _ _G_e_t_t_e_x_t_ 3.4

This long procedure moves a text string from one array to
another, possibly with conversion of each character.

M_m_m_ 1 1
C_a_l_l_: get _text (source, pos, conv, text , length )
P_p_p_ 0 0
\f

get _text (return value, long). Denotes the result of
the transfer:
>= 0: the value is a combination of two
integers:
no _of _chars shift 24 + last _char.
no _of _chars is the number of characters
packed into the new textstring. last _char
is
class shift 12 + value extract 12
(after possible conversion) of the last
character read from source.

= -4: Transfer stopped, because source is
exhausted.
= -5: Transfer stopped, because text is full.

source
pos see get _number
conv

text (call value, array of type boolean, long, or
real). The text string is transferred from
source into this array, after possible
conversion of each character.

length (call value, integer, optional parameter).
Denotes how many characters are to be
transferred, see below.

F_u_n_c_t_i_o_n_: The contents of source, from character position pos and
on, are transferred one character at a time into text,
where they are stored from index 1 and on. If text is a
zone, a zonerecord must exist, i.e. recordlength > 0.
If text is an array of more than one dimension, the
lexicographical ordering is used.
\f

The characters are stored in text according to the type
of this array. If text is a boolean array, the
characters are inserted as 12-bits characters, one in
each array element. The characters are stored in the 8
least significant bits, whereas the remaining bits are
set to zero.

In an array of type long or real the characters are
stored as 8-bits characters with 3 characters per word
(24 bits).

C_h_a_r_a_c_t_e_r_ _c_o_n_v_e_r_s_i_o_n_:

If a conv parameter is specified, each character read
from source will be converted. The character value is
found by
new _char: = conv (char) extract 8.
(See also getnumber).

L_e_n_g_t_h_: The length parameter controls the transfer in the
following way:

If length is not specified or equals zero, characters
are transferred in the same way as by readstring:
Leading delimiters (class >= 7) are skipped, and the
following characters are packed into text until a final
d_e_l_i_m_i_t_e_r_ is recognized. This character has been read,
but is not stored in text. All blind characters (class
<= 1) are skipped.

If length > 0, e_x_a_c_t_l_y_ length characters are
transferred regardless of the character class. Even
blind characters are transferred, so the procedure
works as a sort of "text-tofrom". This is also suitable
for extracting a substring of a text.
\f

If length < 0, a_t_ _m_o_s_t_ abs length characters are
transferred, the transfer stopping if a t_e_r_m_i_n_a_t_o_r_
(class >=8) is read from text. A possible terminator
has been read, but is not packed into text. Blind
characters are neither transferred nor counted.

After the last character a NULL-character is inserted
in text. If text contains 8-bits characters the
remaining part of the last word (of 3 characters) is
set equal to zero. The return value no _of _chars in the
procedure value does not count this NULL-character.

The character transfer may stop prematurely if source
is exhausted or text becomes full. In this case gettext
returns a negative procedure value, and no final
NULL-character is inserted in text.

E_r_r_o_r_s_: As getnumber.

Besides the run-time alarm "index 1" will occur, if the
text parameter is an array of which the element number
one does not exist.
\f

F_ 4_._ _ _ _ _ _ _ _ _T_E_X_T_ _C_O_M_P_A_R_I_S_O_N_ 4.

Two text strings may be compared by the procedure compare _text,
when they are both stored as 8-bits characters in long arrays,
starting in first character of a word. These start conditions are
easily obtained by means of gettext.

4_._1_ _ _ _ _ _ _ _C_o_m_p_a_r_e_t_e_x_t_ 4.1

This integer procedure compares two text strings.

C_a_l_l_: compare _text (text1, text2, chars)

compare _text (return value, integer). The result of the
comparison:
= 0: text1 = text2
= -1: text1 < text2
= +1: text1 > text2

text1, text2 (call values, long arrays). Each of the
two arrays is supposed to contain a string of
8-bits characters starting at the first
character in the element with index 1.

chars (call and return value, integer). The call value
denotes the maximum number of characters to be
compared. The call value may be <=0 meaning all
characters. The return value of chars is the
field address of the word at which the
comparison stopped.
\f

F_u_n_c_t_i_o_n_: The contents of text1 and text2 are compared word by
word (24 bits). The comparison involves at most 'chars'
characters (stored in (chars+2)//3 words), but the
comparison stops as soon as a difference between the
strings has been encountered, or the last character of
a word contains a null-character, or when the upper
index of one of the arrays is reached.

E_x_a_m_p_l_e_: If the long arrays la1 and la2 contains the following
strings
la1 = <:abcdefghij:>
la2 = <:abcd:>
then the comparison
compare _text (la1, la2, 4)
will give the result 0 (equal),
but the comparison
compare _text (la1, la2, 0)
will give the result 1 (la1 > la2).
\f

F_ 5_._ _ _ _ _ _ _ _ _E_R_R_O_R_ _H_A_N_D_L_I_N_G_ 5.

Parameter errors in a call of a put or get procedure (e.g.
illegal parameter type) will always cause a run-time alarm.

An error in the contents of a text parameter is handled as a data
error, causing a negative return value of the procedure. This may
however be changed into a run-time alarm by means of the standard
variable 'put _get _error'.

5_._1_ _ _ _ _ _ _ _P_u_t_g_e_t_e_r_r_o_r_ 5.1

This integer variable controls the handling of data errors by the
put and get procedures.

Each possible negative procedure value corresponds with a bit in
put _get _error. If this bit has the value 1 the procedure will
provoke a run-time alarm instead of returning, in case the cor-
responding data error occurs. The alarm may be trapped, so that
data errors can be handled centrally in the program.

The possible data errors and the corresponding bits in
put _get _error are listed below:

proc putgeterror alarm explanation used by
v_a_l_ _ _b_i_t_ _ _ _ _ _ _ _ _ _m_e_s_s_a_g_e_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _p_r_o_c_e_d_u_r_e_ _ _ _ _ _ _ _ _
-1 1 shift 1 put full -1 dest array full all put procedures
-2 1 shift 2 put exh. -2 text array exhausted puttext
-3 1 shift 3 p.layout -3 layout exceeded putnumber/putfixed
-4 1 shift 4 get exh. -4 source array exhausted all get procedures
-5 1 shift 5 get full -5 text array full gettext
-6 1 shift 6 getvalue -6 syntax or num too great getnumber/getfixed

The default value of put _get _error is 0, i.e. no run-time alarms
on data error.
\f

5_._2_ _ _ _ _ _ _ _A_l_a_r_m_ _M_e_s_s_a_g_e_s_ 5.2

The following parameter alarm messages may occur from the put and
get procedures. The alarm address is in any case the name "text
procs"

called from
a_l_a_r_m_ _t_e_x_t_ _ _ _e_x_p_l_a_n_a_t_i_o_n_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _p_r_o_c_e_d_u_r_e_ _ _
charpos <n> The characterposition specified by all put
pos (2nd parameter) is outside dest/ and get
source. <n> shows the position. procedures

index 1 The array element with index 1 of puttext or
the text parameter (3rd or 4th gettext
parameter) does not exist.

index <n> A character value outside the used all get
alphabet is read from source. <n> procedures
is the character value.

layin 0 A layin containing illegal layout getnumber
components (sign, first letter f or
or z, exponent part, leading spaces, getfixed
or space between d's) is specified.

string 0 The string parameter contains an im- puttext
possible long text string reference.
Or a long text string parameter is
used in an external ALGOL procedure,
which is called from a FORTRAN pro-
gram.
\f

F_ 6_._ _ _ _ _ _ _ _ _P_R_O_G_R_A_M_M_I_N_G_ _E_X_A_M_P_L_E_S_ 6.

This section shows some examples of use of the put and get
procedures.

6_._1_ _ _ _ _ _ _ _C_o_n_c_a_t_e_n_a_t_i_o_n_ _o_f_ _T_e_x_t_ _S_t_r_i_n_g_s_ 6.1

A number of different texts may be concatenated into one text
string by means of the put procedures. The following program part
forms a text string consisting of a string, a number and some
single characters.

begin
integer p, num; long array la (1:10);
...
p:= 1;
puttext (la, p, <:this is a text:>);
putchar (la, p, '-',3);
putnumber (la, p, <<d>, num);
putchar (la, p, 0);
...
write (out, la);

If num = 123 the write statement will produce the following
output:
this is a text---123

6_._2_ _ _ _ _ _ _ _E_x_t_r_a_c_t_i_o_n_ _o_f_ _a_ _S_u_b_s_t_r_i_n_g_ 6.2

A part of a text string may be extracted by means of gettext:

if gettext (la, 5, subla, 4) < 0 then error;

This call will extract a substring consisting of 4 characters
from position 5, 6, 7, and 8 of la.

6_._3_ _ _ _ _ _ _ _A_ _T_e_x_t_ _C_o_m_p_a_r_e_d_ _w_i_t_h_ _a_ _S_t_r_i_n_g_ 6.3

As the procedure comparetext requires array parameters the
contents of a text array can be compared with a string constant
in this way:

puttext (compare, 1, <:...:>);
if comparetext (la, compare, 0) = 0 then
begin <*equal*>
...
end;

6_._4_ _ _ _ _ _ _ _C_o_n_v_e_r_s_i_o_n_ _o_f_ _S_t_r_i_n_g_ _F_o_r_m_a_t_ 6.4

A text string may be converted from 8-bits characters to 12-bits
characters (and vice versa) by means of puttext or gettext:
length:= ...; <*no. of chars, > 0 *>
puttext (ba, 1, la, length); <*from 8 to 12*>
gettext (la, 1, ba, length); <*from 8 to 12*>
and
puttext (la, 1, ba, length); <*from 12 to 8*>
gettext (ba, 1, la, length); <*from 12 to 8*>

Whether you should use puttext or gettext depends on the wanted
startposition in from-array or to-array, as a startposition can
be specified only for the first parameter.

6_._5_ _ _ _ _ _ _ _C_o_n_v_e_r_s_i_o_n_ _o_f_ _C_h_a_r_a_c_t_e_r_s_ _i_n_ _a_ _S_t_r_i_n_g_ 6.5

The character values in a text string may be converted by means
of puttext or gettext using a conversion table:

isotable (conv);
<*change the wanted characters in conv*>
...
length:= ...; <*no. of chars > 0 *>
puttext (new _la, 1, conv, la, length);
or
gettext (la, 1, conv, new _la, length);
\f

(See section 6.4 concerning whether to use puttext or gettext).

6_._6_ _ _ _ _ _ _ _R_e_a_d_i_n_g_ _o_f_ _P_u_n_c_h_e_d_ _C_a_r_d_s_ 6.6

The get procedures are particularly suited for reading of punched
card images. Each card consisting of 81 characters (80 characters
followed by a NL character) may be read by a call of inrec6 and
subsequently interpreted by means of the get procedures.

Suppose some of the cards contain the following information:

column datatype contents
1- 3 text cardtype = emp
4- 7 num employee number (4 digits)
8-36 text employee name (29 chars)
37-65 text employee address (29 chars)
66-68 num department
69-77 num salary (with 2 decimals)
78-79 num rate of taxation
80-80 char status

The card deck is terminated by a card with cardtype = fin.

These cards may be read and used for creation of employee records
by the program listed below.
\f

F_
\f

F_ A_._ _ _ _ _ _ _ _ _R_E_F_E_R_E_N_C_E_S_ A.

1 RCSL No 42-i0606:
ALGOL7, Reference Manual

2 RCSL No 42-i1278:
ALGOL8, User's Guide, Part 2
\f

F_
\f

«eof»

DataMuseum.dk

CP/M

⟦e82c3dfd1⟧ TextFile

Derivation

TextFile