Operation [ COBOL/HP-UX Operating Guide for the Series 700 and 800 ] MPE/iX 5.0 Documentation
COBOL/HP-UX Operating Guide for the Series 700 and 800
Operation
This COBOL system handles files of four different organizations and four
different file assignments. You can map file-names which enables you to
take advantage of advanced file assignment facilities.
File-naming for this COBOL system is based on standard operating system
file-naming.
Multiple reel files are supported for sequential files. This means that
you can specify that your file is held on more than one of the same type
of media.
Data and key compression are supported as are duplicate keys.
A call conversion module is provided to enable systems using Btrieve to
use the calls used by EXTFH, the Micro Focus External File Handler.
These features are explained in the following sections.
COBOL Data File Organizations
COBOL programs can create, update and read files of four different
organizations:
* record sequential
* line sequential
* indexed sequential
* relative
Record sequential, indexed sequential and relative files can contain
either fixed or variable length records. Line sequential files consist
of a series of variable length records.
See Chapter 17 , File Formats later in this manual for information on
the formats of these file types.
COBOL File Naming Conventions
This COBOL system, and applications created with this system, all use the
standard operating system file-naming convention:
[path-name/]file-name[.ext]
where:
path-name is the operating system path containing or to contain the
file.
If you do not specify a path-name, the current directory
is assumed.
file-name is the name of the disk file.
.ext is a period (.) followed by the
file-name extension.
This COBOL system also recognizes the following symbolic names, which
must appear without any path-name or extension:
:CI: Standard input
stdin
:CO: Standard output
stdout
:CE: Standard error
stderr
To handle the symbolic names used by other operating systems, use
file-name mapping to map the symbolic names onto UNIX device names.
The maximum sizes of path-name, file-name and .ext is consistent with the
UNIX system limits. Typically, the total size of the combination of all
three name components is 100 characters. The maximum size of the
combination of file-name and .ext is 14 characters. See your Release
Notes for the values used in your environment.
In the interests of program portability, we advise you not to build the
absolute path-names of files into your programs. You should use relative
path-names instead. For example, you are recommended to use:
mylib/file1
rather than:
/usr/mylib/file1
This COBOL system detects any path names which exceed the permitted
maximum number of characters for a path when you attempt to open,
split/join or map such files. It similarly detects any component names
which exceed the permitted maximum number of characters for a component
name.
For example:
* An OPEN...OUTPUT with FILE STATUS defined operation using a file
whose component name exceeds the permitted number of characters
for a component name, or uses a file whose path-name exceeds the
permitted maximum number of characters for a path-name causes a
file status error.
* An OPEN...OUTPUT without FILE STATUS defined operation using a
file whose component name exceeds the permitted maximum number of
characters for a component name, or uses a file whose path-name
exceeds the permitted maximum number of characters for a path-name
causes a fatal run-time error.
* A CALL...ON EXCEPTION operation using a file whose path-name
exceeds the permitted maximum number of characters for a path-name
causes an EXCEPTION error.
* A CALL operation with no exception clause that uses a file whose
path-name exceeds the permitted maximum number of characters for a
path-name causes a fatal run-time error.
The fatal run-time error is:
188 Filename too large
except for indexed files for which you receive the fatal run-time system
error:
75 Indexed data file name too long
See your Release Notes for details of the maximum number of characters
permitted in a component name and a path-name.
COBOL Data-File Assignment
This COBOL system offers four types of file assignment:
* Fixed file assignment, in which you assign the logical file-name
to a literal which gives a physical file-name.
* Dynamic file assignment, in which you assign the logical file-name
to a data item defined in your program. You store the name of
physical file in this variable at run-time before opening the
file.
* External file assignment, in which you assign the logical
file-name to an environment variable in your program to specify
the external name of the file being referenced.
* File-name mapping which enables you to alter the physical
file-name accessed by your program at run-time, assign files to
UNIX pipes (including named pipes), assign the index and data
files of indexed files to different directories, and assign a file
to a printer.
These are described in the following sections.
Fixed File Assignment.
In fixed file assignment, you assign a literal file-name to an internal
file-name used by your program.
Environment Division
In the File-Control paragraph the format of the SELECT...ASSIGN TO clause
is as follows:
select file assign to {literal }
{disk [literal]}
where:
file is the internal user file-name and can be any COBOL
word you define.
literal is the UNIX path-name of the corresponding file.
For example: select myfile assign to "mylib/file3"
associates the file that your program refers to as
MYFILE with the file named file3 in the directory
mylib relative to the current directory.
disk gives you the choice of specifying the file-name
literal either in the SELECT clause or in the FD
entry for the file in the FILE SECTION. For example:
select myfile assign to disk "myfile/lib3"
has the same effect as if you have specified
literal, above. However, you could achieve the same
effect another way:
select myfile assign to disk
. . .
. . .
data division.
file section.
. . .
fd myfile value of file-id "myfile/lib3"
If you do not specify literal with disk in the SELECT clause and do not
specify the VALUE OF FILE-ID clause in the file's FD entry, the effect is
to use a physical file-name that is the same as the internal file-name.
Note that the internal file-name is folded to uppercase by the compiler.
Therefore, if in the above example, you were to omit the VALUE OF FILE-ID
clause in the FD entry, the file myfile would be associated with a file
with the UNIX file-name MYFILE.
Refer to your operating system manuals for more information on file names
and to your Language Reference for information on the ASSIGN TO clause.
Dynamic File Assignment.
In dynamic file assignment, you associate the internal file-name used by
your program with a data-item declared in your program.
Environment Division
In the File-Control paragraph the format of the SELECT...ASSIGN TO clause
is:
select file assign to dynamic {disk }
{data-item}
where:
data-item is the name of a data-item declared in the
Working-Storage section of your program. You must
declare this item as PIC X(n), where n is the
maximum length of the path-name you want to use. If
you do not declare this data-item, the compiler
declares it for you automatically as PIC X(100).
If you use the disk option in the SELECT clause, you specify the name of
the data-item that holds the file-name in the VALUE OF FILE-ID clause in
the file's FD entry.
For example:
select myfile assign to dynamic file-name
. . .
data division.
. . .
working-storage section.
. . .
01 file-name pic x(25).
. . .
procedure division.
. . .
move "mylib/file3" to file-name.
open myfile...
assigns the relative path-name mylib/file3 with the internal file-name
MYFILE. You could achieve the same effect as follows:
select myfile assign to dynamic disk
. . .
data division.
. . .
file section.
. . .
fd myfile value of file-id is file-name.
. . .
working-storage section.
. . .
01 file-name pic x(25).
. . .
procedure division.
. . .
move "mylib/file3" to file-name.
open myfile...
External File Assignment.
With external file assignment, the ASSIGN clause specifies the name of an
environment variable. The
environment variable value must be set prior to running the program,
specifying the name of the file being referenced.
Using this method, you can easily set the external file-name without
having to change the program.
Environment Division
In the File-Control paragraph, the format of the SELECT...ASSIGN TO
clause is:
select file-name
assign to external external-file-reference
where:
file-name is the internal user file-name and can be
any COBOL word you define.
external-file-reference identifies a UNIX environment variable
whose value is used as the file's path
name.
Before you run a program containing EXTERNAL file assignment, you must
ensure that you have declared an environment variable with the same name
as the external-file-reference. You must also ensure that the value of
this environment variable is the path name for the appropriate file.
With EXTERNAL file assignment, you must be careful how you specify file
and environment names. The external-file-reference the follows
EXTERNAL is not a literal in the usual COBOL sense as the compiler
treats is as a user name. One consequence of this is that if the
external-file-reference is in lower case, the compiler converts it
internally to upper case. Therefore when you create the environment
variable its name must be in upper case.
The following is an example of how you use EXTERNAL file assignment.
Before you run this program, you must create a UNIX environment variable
called DD_MYENV and give it a value, for example mylib/file3.
select myfile assign to external myenv
. . .
procedure division.
. . .
open myfile ...
When you run this program, the file with the internal file-name myfile is
associated with the file whose path name is the current value of the
environment variable DD_MYENV.
If external-file-reference contains any hyphen ( - ) characters only the
positions to the right of the right-most hyphen have any significance.
For example:
select myfile assign to external a-b-c-defg
The environment variable required and searched for by the run-time system
is DEFG.
If you use the ASSIGN"EXTERNAL" directive, you can omit the word EXTERNAL
from this clause. In which case, the internal file-name is used.
External Files
When using files which have been assigned as EXTERNAL, you must also
declare the Working-Storage item representing that file's UNIX path-name
as external. For example:
select myfile assign to file-name.
. . .
data division.
. . . file section.
. . .
fd myfile external.
. . .
working-storage section.
. . .
01 file-name external pic x(25).
However, this program does not function correctly if another program uses
the same EXTERNAL file.
File-Name Mapping.
File-name mapping allows you to make use of more advanced file assignment
facilities.
When your program opens a file, the system prefixes "DD_" to that file's
name. Note that "dd_" is also recognized. The system then extracts the
first element of the file-name and looks for an environment variable with
that name. The first element of the file-name consists of either all the
text before the first "/" character, all the text if the name does not
include such a character, or nothing if the file-name actually starts
with the "/" character. So, for example, if you try to open a file named
dir/file1, the system searches for the environment variable dd_dir; if
you try to open a file named dir1/dir2/file1, the system searches for
dd_dir1 and if the file is named file1, the system searches for dd_file1.
If the system finds the environment variable for which it searches, it
then takes the value of that environment variable and prefixes this to
the remaining elements of the original file-name; that is, the name in
the SELECT ASSIGN statement. This name is then considered to be the
physical file for which the system is to search.
Consider the following examples:
-------------------------------------------------------------------------------
| | | | |
| Filename ASSIGNed in | Environment | Environment | Physical File-name |
| program | variable | variable | |
| | searched for | contents | |
| | | | |
-------------------------------------------------------------------------------
| | | | |
| dir/file1 | dd_dir | d2 | d2/file1 |
| | | | |
| dir/file1 | dd_dir | d4 | d4/file1 |
| | | | |
| dir/file1 | dd_dir | d2/d4 | d2/d4/file1 |
| | | | |
| dir1/dir2/file1 | dd_dir1 | d2 | d2/dir2/file1 |
| | | | |
| dir1/dir2/file1 | dd_dir1 | d4 | d4/dir2/file1 |
| | | | |
| dir1/dir2/file1 | dd_dir1 | d2/d4 | d2/d4/dir2/file1 |
| | | | |
-------------------------------------------------------------------------------
Following these rules, if the original SELECT ASSIGN file-name consists
of a single element, the value contained in the associated environment
variable is used as the physical file-name. For example:
-------------------------------------------------------------------------------
| | | | |
| Filename ASSIGNed in | Environment | Environment | Physical File-name |
| program | variable | variable | |
| | searched for | contents | |
| | | | |
-------------------------------------------------------------------------------
| | | | |
| file1 | dd_file1 | d2 | d2 |
| | | | |
-------------------------------------------------------------------------------
File-names which begin with a slash ( / ), a "-" or the digits 0 to 9 are
not mapped.
The rules for file-name mapping described above allow you to put all the
files connected with one application in the same directory and to be
certain that this COBOL system will be able to find all of them. You
achieve this by defining each file as application-name/file-name and by
setting up an environment variable which points to the name of the
directory which contains all these files.
If the system fails to find the environment variable for which it
searches, or it finds the environment variable but the contents of this
are not set, the system assumes that the physical name of the file is the
same as its logical name. For this reason, you must ensure that the
logical file-names do not contain any special characters that cannot be
included in environment variable names. However, although the period ( .
) character is not allowed in the names of environment variables, it is
often used in file-names, so you may want to map logical file-names
containing this character. In this case, you must replace the "." with
the underscore ( _ ) character. For example:
dd_file_PNT=/usr/qa/myfile.pnt
refers to the logical file-name "file.PNT".
Notes:
* If you set up dd_ environment variables so that they cause
commands to be executed by the operating system shell, the shell
used is that defined in the environment variable SHELL or, if this
has not been set, by /bin/sh.
* The ASSIGN TO PRINTER clause does not send output to a printer; it
sends is to LPT1. To send output to a physical printer, you must
use the dd_LPT1 environment variable or, if your system supports
the LP printer spooler, use LPT1=LP.
Setting up Multiple Paths
You can specify multiple paths for file-name mappings for files OPENed
for INPUT or I/O in the contents of environment variables. This causes
the system to search for subsequent files specified in the path if a
"file not found" condition is returned for the first file in the path.
If the first component of a path is a directory, the first component of
the environment variable searched for must also be a directory.
Similarly, if the first component is a file, the dd_ component must also
be a file.
Consider the following example contents of an environment variable named
dd_dir:
dd_dir="/a/b:/c/d: ..."
This causes the system to search /c/d for the ASSIGNed file if a "file
not found" condition is returned on /a/b. Note that in this example, the
quotation marks are as typed into the shell. They are not actually
present in the value of the environment variable. The same is true for
all of the examples in this section.
Consider the following examples:
-------------------------------------------------------------------------------
| | | | |
| Filename ASSIGNed in | Environment | Environment | Physical File-name |
| program | variable | variable | |
| | searched for | contents | |
| | | | |
-------------------------------------------------------------------------------
| | | | |
| dir1/file1 | dd_dir1 | d1:d2 | d1/file1 |
| | | | if this is not found |
| | | | then: |
| | | | d2/file1 |
| | | | |
| file1 | dd_file1 | d1/f1:d2/f2 | d1/f1 |
| | | | if this is not found |
| | | | then: |
| | | | d2/f2 |
| | | | |
| file1 | dd_file1 | f1:f2 | f1 |
| | | | if this is not found |
| | | | then: |
| | | | f2 |
| | | | |
| dir1/file1 | dd_dir1 | :d1/d2 | current |
| | | | directory/file1 |
| | | | if this is not found |
| | | | then: |
| | | | d1/d2/file1 |
| | | | |
-------------------------------------------------------------------------------
For files OPENed I/O or OUTPUT, if the file is not found on any part of
the path, it will be created in the first directory in the search
sequence.
Each path in a dd_ path list may be up to the permitted maximum number of
characters for a path in length. Should this limit be exceeded, you will
receive either the run-time system error:
188 Filename too large
or, if the file is an indexed file, the error
75 Indexed data file name too long
See your Release Notes for details of the maximum number characters
allowed in a path name.
Additionally, you can map files on a global basis by setting the COBDATA
environment variable. See the section "Global File-Name Mapping" for
further information of the COBDATA environment variable.
Search Sequence
The overall search sequence employed by the RTS, or the run-time system
support libraries to find a specified file, is dependent on the file
assignment of that file.
The search order for files ASSIGNed DYNAMIC is:
1. dd_environment variables
2. environment variables defined in cobcap
3. any COBDATA environment mappings
4. unmapped name on disk
The cobcap facility is provided for compatibility with previous versions
of this COBOL system.
Note: If you dynamically change such environment variables using a
call to "SYSTEM", they are not reaccessed by this COBOL system
after the start of its run. However, changing them using COBOL
syntax causes the updated setting to be used.
For files ASSIGNed EXTERNAL, only the last element of the file-name
following the final hyphen is significant for file-name mapping.
The search order for file ASSIGNed EXTERNAL is:
1. dd_environment variables
2. environment variables defined in cobcap
3. $filename environment variables
4. file-name literals (variables which may or may not be preceded by
"dd_" but which map external file-names)
5. any COBDATA environment mappings
6. unmapped name on disk
In this case, the file-name literals are reaccessed by this COBOL system
after the start of a run. This is for compatibility with previous
versions of the COBOL system.
The %NLS% Characters in File-names
This feature is applicable only if your COBOL system has National
Language Support implemented.
If the physical file-name in your program starts with the characters
"%NLS%", the file is processed in accordance with the rules for National
Language Support (NLS) facilities. Consider the following example
contents of a SELECT statement:
Select file-name assign "%NLS%file1"
This causes the system to process file1 in accordance with NLS rules.
You can then map file1 using the environment variable dd_file1 as
described earlier in this chapter. In this case, the mapped file is
processed in accordance with NLS rules.
Alternatively, a file assigned without the "%NLS%" characters can be
processed in accordance with NLS rules, if you specify a mapping for the
file which is preceded by the characters "%NLS%".
Consider the following example:
-------------------------------------------------------------------------------
| | | | |
| Filename ASSIGNed in | Environment | Environment | Physical File-name |
| program | variable | variable | |
| | searched for | contents | |
| | | | |
-------------------------------------------------------------------------------
| | | | |
| file2 | dd_file2 | %NLS%file3 | file3 |
| | | | |
-------------------------------------------------------------------------------
This causes file3 to be processed in accordance with NLS rules.
See Chapter 30 , National Language Support later in this manual for
full details of NLS facilities.
The "&" Character in Environment Variables
When you are specifying the contents of an environment variable you can
place an ampersand (&) character at the start to indicate that an indexed
sequential file is to have its index and its data files in separate
directories (and, by implication, on separate disks). You cannot use
this character while specifying multiple paths.
Note: As the "&dquote; character has this special meaning when used in
environment variables, if you want to reference any file whose
name begins with this character you must precede the name with a
backslash ( \ ) character.
Consider the following example contents of an environment variable named
dd_dir:
dd_dir="&/disk1/data.dat&/disk2/data.idx ..."
This causes the system to place the data part of the original ASSIGNed
indexed sequential file in /disk1/data, while the index part of the file
is placed in /disk2/data.idx.
The "$" Character in File-names
If the physical file-name in your program starts with a dollar ($)
character, this forces the system to attempt to map the specified file.
If no mapping exists, the system returns a "file not found" condition and
does not search for the unmapped file-name.
Consider the following example contents of a SELECT statement:
select file-name assign "$file1"
This causes the system to search for the environment variable "dd_file1"
then "$file1". If this is found, the system follows the rules for
file-name mapping given in the previous sections. If this is not found,
the system returns a "file not found" condition and does not attempt to
search for "file1".
Forcing the system to attempt to map the specified file in this way is
supported only when mapping is to a file-name. It is not supported to a
directory path list, pipes or to split index and data-names.
Setting up Pipes
When you specify the contents of an environment variable, you can use the
following three characters to set up pipes or named pipes:
* >
* <
* |
The meanings of these characters when used in the value of an environment
variable are described below.
Notes:
* These special characters are only recognized by this COBOL system
if they appear at the start of an environment variable.
* The OPEN...EXTEND operation on a dd_pipe or named pipe matches
that of an OPEN...OUTPUT.
* You CANNOT use these characters with:
* multiple paths
* variable length records
* multiple 01 level data-items
* a RECORDING MODE clause.
* As these three characters do have a special meaning in environment
variables, if you want to reference any file whose name begins
with any of these characters, you must precede the name with a "\"
character.
The "<" Character
The less than (<) character defines the specified file as a pipe
connected to the standard output of the given command. The file ASSIGNed
within your program must be either sequential or line sequential, and
must be OPENed for INPUT. Its name can be only one element long; that is,
it must not contain a "/" character.
Consider the following example contents of an environment variable named
dd_dir:
dd_dir="<ls -l ..."
This causes every READ statement in the program of the original ASSIGNed
file to return the value of the next line of the output from the "ls -l"
command.
The pipe is set up using the UNIX "popen()" library routine.
The ">" Character
The greater than (>) character defines the specified file as a pipe
connected to the standard input of the given command. The file ASSIGNed
within your program must be either sequential or line sequential and must
be OPENed for OUTPUT. Its name can be only one element long; that is, it
must not contain a "/" character.
Consider the following example contents of an environment variable named
dd_dir:
dd_dir=">pr -h Title ..."
This causes every WRITE to the file in the program to be passed to the
standard input of the "pr -h Title" command.
The "|" Character
The pipe ( | ) character defines the specified file as a two-way pipe to
the specified process. The file ASSIGNed within your program must be
either sequential or line sequential and must be OPENed for I/O.
Consider the following example contents of an environment variable named
dd_file:
dd_file=|"proc"
This defines the file "file" as a two-way pipe to the process "proc";
that is, all the READ operations on that file will read the standard
output of the process "proc".
Note: You will receive an error if you attempt to write to a line
sequential file, or sequential file OPENed for I/O unless the
file has been mapped using the "|" character.
Global File-Name Mapping.
The COBDATA environment variable enables you to globally map groups of
files to different file-names and file organizations. This allows you to
place working data files in a directory whose name is not known until
run-time. See the section "File-Name Mapping" for further
information on mapping individual files.
The format of the COBDATA environment variable is:
COBDATA=:directory:directory ...
export COBDATA
where:
directory is the name of a directory to which you want COBDATA
to point.
For example:
COBDATA=:demo:user:progs
export COBDATA
COBDATA is considered set if there is an environment variable of this
name in your environment space and its value is non-empty.
If you specify an empty directory, this is equivalent to specifying the
current directory using the "." character.
Search Sequence
The search order for files assigned DYNAMIC is:
1. dd_ environment variables
2. environment variables defined in cobcap
3. any COBDATA environment mappings
4. unmapped name on disk
The cobcap facility is provided for compatibility with previous versions
of the COBOL/2 system
Note: If you dynamically change such environment variables using a
call to "SYSTEM", they are not reaccessed by this COBOL system
after the start of its run. However, changing them using COBOL
syntax causes the updated setting to be used.
For files ASSIGNed EXTERNAL, only the last element of the file-name
following the final hyphen is significant for file-name mapping.
The search order for file ASSIGNed EXTERNAL is:
1. dd_environment variables
2. environment variables defined in cobcap
3. $filename environment variables
4. file-name literals (variables which may or may not be preceded by
"dd_" but which map external file-names)
5. any COBDATA environment mappings
6. unmapped name on disk
In this case, the file-name literals are reaccessed by this COBOL system
after the start of a run. This is for compatibility with previous
versions of this COBOL system.
For multiple directory paths specified either in the COBDATA environment
variable or a dd_ environment variable, the system searches the first
directory specified followed by a slash ( / ) character as a prefix to
the user name. If the file is not found, or is not readable, the search
continues until the final directory has been searched. If no file is
found and the OPEN mode is I/O or OUTPUT, the first directory is used if
a file is to be created.
The COBDATA value string must begin with a colon ( : ) character or the
search will not work. All mappings are ignored for any file-name
starting with a hyphen ( - ) character or a "/". It is also illegal to
have a "-" anywhere within an environment variable name.
When using COBDATA for file-name mapping, you should not specify a
file-name that starts with "COB..." as words beginning with this are
reserved for the COBOL system.
You can use COBDATA for files OPENed in any mode and for fixed or
variable length files. If you are using indexed files, both the data and
indexed files will be in the same directory.
COBDATA affects file deletions, using the rules given here, and file
opens.
If you use COBOL development system programs, we recommend that you first
unset COBDATA, as many of these programs open data files and are
therefore affected by the value of COBDATA.
Multiple Reel Files
You can specify sequential files as multiple reel (or multiple unit)
files. This means that a sequential file can be held on more than one
floppy disk, cartridge tape, tape reel, or disk partition. You must
specify the file as a multiple reel file in the SELECT clause of the
Environment Division.
You cannot specify a sequential file as multiple reel if it has variable
length records, since the file header record (see below) stores only one
record length.
Whenever you specify a sequential file as a multiple reel file, you are
prompted to load the appropriate reel of the file. This applies also to
the first reel of the file, even though it may already be loaded. The
prompt is:
PLEASE LOAD VOLUME nnnn OF FILE file-name FOR access
ENTER NEW DEVICE (IF REQUIRED) AND <CR> WHEN READY
where:
nnnn is the four-digit reel number of the reel to be
loaded. nnnn is in the range 0001 to 9999.
file-name is the file-name as specified in the SELECT clause
in the source program.
access is INPUT, OUTPUT or I/O as specified in the source
program.
At this prompt you must ensure that the relevant reel is loaded (media
for output must already be formatted), and enter the file-name. The
system accepts input only in response to this prompt. If you load the
wrong volume of a file, or if the header information is in some way
corrupt, an error is returned.
When you have entered the relevant parameters for the first prompt,
another prompt is displayed as follows:
PLEASE ENTER CAPACITY OF DEVICE IN 1024 BYTE BLOCKS
At this prompt, enter the capacity of the device that the file is going
to, in 1024 byte blocks.
If you decide not to continue, you must enter Ctrl+D at the prompt to end
the run cleanly. This ensures that all the files are closed and that all
the information is saved, as though you had executed a STOP RUN
statement.
The prompt to load a reel is displayed whenever:
* a multiple reel file is opened
* a CLOSE REEL statement is executed
* the reel becomes full while writing to a multiple reel file (this
is a forced reel-swap on WRITE)
* "end of reel" is true for a multiple reel file opened for INPUT
(or I/O on READ). This is true provided that a continuation reel
was created when the file was written.
Note: Although you can specify REWRITE operations on a file opened for
INPUT-OUTPUT, we do not recommend that you do so. If the record
you are rewriting is at the end of a reel, the preceding READ
statement will have forced a reel-swap, so the rewrite will
fail.
Multiple Reel File Header Record.
Multiple reel files have a block of header information that is 256 bytes
long. This header occupies the first 256 bytes of each reel and contains
information that describes the reel. This header contains 44 bytes, an
area of which is reserved for your use.
When running programs to read multiple reel files created by early
versions of Micro Focus COBOL, you must use the -V run-time switch. This
disables checking of the header title.
The following sets out the structure of the multiple reel file header:
Bytes Content
0-49 "MICRO FOCUS COBOL MULTIPLE UNIT HEADER V1.0."
50-69 File-name. This is the name of the file as specified in
the SELECT clause.
70-75 Date of file creation in the form yymmdd (year, month, day
in ASCII digits). If your system does not return the
date, this part of the header contains ASCII zeros.
76-83 Time of file creation in the form hhmmsscc (hours,
minutes, seconds, hundredths of a second in ASCII digits).
If your system does not return the time, this part of the
header contains ASCII zeros.
84-127 Filler.
128-131 Reel number. This is a four-digit ASCII value showing the
reel number in the range 0001 to 9999.
132 Continuation flags. A one-byte value that shows how the
reel ends. The value is ASCII "Y", "A" or "N" as follows:
Y This reel is followed by a continuation reel. A
CLOSE REEL statement was used to change the reels.
A This reel is followed by a continuation reel. The
reels were changed automatically when this reel
became full.
N This reel has no continuation. It is the last reel
of the file.
133 Reserved. Currently contains the ASCII value "N".
134-145 Reel length. A 12-digit ASCII value which indicates how
many bytes of information are on this reel. This part of
the header contains zeros if your system cannot determine
the reel length.
146-151 Record
length. This is a six-digit ASCII value that shows the
record length of records in this file.
152-157 Block size. This is a six-digit ASCII value that has the
same value as the record size area of the header.
158-239 Reserved area containing ASCII spaces.
240-255 Multiple reel header end identification.
File Usage
The maximum size of any file you can create is limited by the environment
variable ulimit. You may find that the default limit, as supplied with
your UNIX system, is rather small. However, this limit can be increased
by a superuser.
The maximum number of files that can be open at any one time, excluding
the standard input, output and error files, is dependent on the
configuration of your UNIX system. See your Release Notes for details of
configuration for your system.
You should consider the following:
* Each open indexed sequential file counts as two files.
* Up to five temporary work files can be open concurrently while a
SORT or MERGE statement is executing, depending on the number of
records to be sorted. However, when sorting small files, no work
files are required at all.
* By default, a maximum of 3 Mbytes of memory can be used by a SORT
or MERGE, although a minimum of 55% of the original calculated
requirement will generally be sufficient.
If this value is considered too high for your environment, the
environment variable COBSW=-s should be used to restrict the
memory utilized. If, however, you have more than 3 Mbytes of
memory to deal with larger amounts of data, COBSW=-s can be used
to allow SORT/MERGE to utilize this extra memory.
In general, if the memory that SORT/MERGE has at its disposal
exceeds the size of the data to be sorted or merged, this will
give SORT/MERGE peak performance.
See Appendix E , Descriptions of Run-Time Switches for further
information on the -s setting of COBSW.
* Whenever the COBOL system executes a GO TO, PERFORM or CALL
statement that causes an overlay to be loaded, another file is
used while the overlay or subprogram is being loaded.
* The open mode of a file can influence the maximum number of files
opened at any one time. Files opened for INPUT are limited to the
maximum number of files per process which has been configured for
your UNIX system. Files with EXCLUSIVE access (for example, files
opened for OUTPUT) acquire file locks and are thus limited to the
maximum number of file locks per process which has been configured
for your UNIX system. These two limits are not necessarily the
same.
File Compression
This COBOL system enables you to store files in compressed form in order
to save disk space. This can be accomplished either through key
compression or data compression.
Data Compression.
Data compression is a process that can be applied to the data of a
sequential or indexed file. Only one type of compression, called run
length encoding, is provided.
Data compression is not specified by COBOL syntax. You enable it by
specifying the DATACOMPRESS directive. For details on DATACOMPRESS, see
Appendix G Directives for Compiler/Generator. Specifying data
compression for a fixed structure file changes it into a variable
structure file. See Chapter 17 , File Formats for further
information. This will not affect your program. However, since variable
structure files take more space than fixed structure files, there are
certain cases in which a bigger file may result.
Data compression routines are also callable from your program. You do
this either by including the DATACOMPRESS directive in a $SET statement
or by including the compression routine in a call statement. See Chapter
14 , Callable File Handler for details on how to do this.
Run-Length Encoding
When a file is defined with run-length encoding, any string of repeating
characters is stored as a single character with a repetition count.
Key Compression.
Key compression is a technique that can be applied to the keys of an
indexed file. Three types of compression are available:
* compression of trailing spaces
* compression of identical leading characters
* compression of duplicate alternate key values.
Any combination of these can be used on any key, though the compression
of duplicates is only appropriate to alternate keys with duplicates
allowed.
Key compression is not specified by COBOL syntax. You enable it by
specifying the KEYCOMPRESS directive in a $SET statement using options to
indicate which types of compression you want. For details on
KEYCOMPRESS, see Appendix G , Directives for Compiler/Generator.
Compression of Trailing Spaces
When a key is defined with compression of trailing spaces, trailing
spaces in a key value are not stored in the file. However, information
is stored so that the key can be correctly located.
For example, assume you have a prime or alternate key that is 30
characters long, and that you write a record in which only the first 10
characters of the key are used, the rest being spaces. Without
compression, all 30 characters of the key are stored. With compression
of trailing spaces, the key only occupies 11 bytes in the index file (10
characters of the key 1 byte as a count of the trailing spaces)
Compression of Leading Characters.
When a key is defined with compression of leading characters, all leading
characters that match leading characters in the preceding key are not
stored in the index file. However, information is stored to allow the
key to be correctly reconstructed.
For example, assume that records are written with the following key
values in a key defined with compression of leading characters:
AXYZBBB BBCDEFG BBCXYZA BBCXYEF BEFGHIJ CABCDEF
The keys actually stored in the index file are:
AXYZBBB BBCDEFG XYZA EF EFGHIJ CABCDEF
Compression of Duplicate Keys
When an
alternate key is defined with compression of duplicates, only the first
duplicate key is contained in the file. The rest are not stored, but
information is stored to allow correct recreation of the keys.
For example, suppose you write a record with an alternate key value
"ABC". If you have enabled compression of duplicate keys, and you write
another record with the same key value, the file handler does not
physically store the duplicate key value in the index file. However, the
record is still available along the alternate key path.
Example of Setting Compression.
In the following program, data compression is specified for TRANSFILE but
not for MASTERFILE. For key compression: suppression of trailing spaces
and of leading characters matchin the previous key is specified for keys
T-REC-KEY and M-REC-KEY. Suppression of repetition of duplicate keys is
also turned on for M-ALT-KEY-1 and M-ALT-KEY-2.
$set datacompress
$set keycompress"6"
select transfile
assign to ...
key is t-rec-key.
$set nokeycompress
$set nodatacompress
select masterfile
assign to ...
organization is indexed
$set keycompress"6"
record key is m-rec-key
$set keycompress"7"
alternate key is m-alt-key-1 with duplicates
alternate key is m-alt-key-2.
$set nokeycompress
Duplicate Keys
All alternate keys in indexed files can be duplicate keys.
To allow duplicate keys, you specify the phrase "WITH DUPLICATES" in the
ALTERNATE RECORD section of the SELECT statement.
When you use duplicate keys, you should be aware of two limitations:
* A maximum number of 65535 duplicate keys is allowed for every
individual key in a standard file. Each time you specify a
duplicate key, an increment of one is added to its occurrence
number. However, because the occurrence number is used to ensure
that duplicate key records are read in the order in which they
were created, and any occurrence number whose record you have
deleted cannot be reused, the duplicate key maximum may be
reached.
To overcome this, a different file format is available:
IDXFORMAT-4. You invoke this file format either when you specify
the IDXFORMAT"4" compiler directive within the SELECT statement
for individual files or for all files in the program, or by
setting the file format field of the FCD to 4 (see Chapter 14 ,
Callable File Handler for details of the file format field).
IDXFORMAT-4
format files allow a maximum of 4,294,967,297 duplicate keys,
although any additional information is stored in the data record
so that the handling of such a number of keys is quicker. This
causes the data record of such files to be larger than those of
the default files.
* Primary keys should not allow duplicates. This is because, with
duplicates allowed, it is not possible to uniquely identify
records in a file. See the READ, REWRITE and DELETE statements in
your Language Reference.
MPE/iX 5.0 Documentation