Temporary files are job-specific. They cannot be accessed by other jobs running under the same user ID or by other users. On completion of the job, they are automatically deleted by LOGOFF handling if the owner has not already deleted them explicitly. If a spoolout job for a temporary file is still outstanding at LOGOFF, the file is not deleted until the job has been executed. If a job is aborted due to abnormal termination of the system, temporary files remain cataloged until systems support imports the pubset again, since no LOGOFF handling is executed in this case.
Temporary files can be processed with the access method ISAM, SAM, UPAM, FASTPAM, DIV or BTAM. By default, they are created in the user area of the system and DMS treats them, wherever permissible, just like permanent files of the same type. They can be created on tapes, but not on private disks.
Nonprivileged users can only create temporary files on the default pubset for their user IDs.
The user creates a temporary file by prefixing a special character to the file name. This special character (# or @) is defined by the TEMPFILE system parameter at system startup and can be queried using the SHOW-SYSTEM-PARAMETER command or the NSIOPT macro (see the “Executive Macros” manual [2 (Related publications)]).
The user-defined name for a temporary file is then, for example, “#CUSTOMERLIST”. Under this name, the temporary file can be processed (opened, closed, deleted...).
Temporary files are maintained in the file catalog under an internal file name with the following format: S.<sysid>.<tsn>.filename, where
<sysid> | is the ID of the system within the network (three-digit number) |
<tsn> | is the current task sequence number (TSN) |
Example of the internal name of a temporary file: S.100.1QXR.TEMP.FILE.
In various macros as well as in system messages, the internal file name is output. These naming conventions ensure that identically named temporary files of concurrently active jobs of a user do not collide. If the user assigns a file name whose format matches that of a temporary file (name starting with “S.” followed by a three-digit number, a period and a four-digit combination of letters and numerals), this name is rejected by the system.
If the user explicitly creates a file whose name has all the above-mentioned attributes
(S.<sysid>. <tsn>), this file is created as a temporary file. To process it, the user needs to enter the file name with the appropriate special-character prefix (see above). Once the task has terminated, this file is lost.
If temporary files (with a prefix in their names) are created on tape, neither the prefix nor the character string “S.<sysid>.<tsn>” is included in the HDR1 or HDR3 labels (only the file name without a prefix). The file is flagged as temporary only in the catalog. If such a file is opened with OPEN INPUT or OPEN INOUT (see chapter "OPEN processing"), DMS does not check this character string as part of HDR1/HDR3 processing.
Temporary file generation groups are not permitted.
Recataloging a work file as a temporary file or vice versa is not possible.
In an SM pubset, renaming a temporary file as a permanent file or vice versa is rejected if changing the file attributes implies reallocation to another volume set (S0 migration).
EAM files
The SYSEAM area is a domain on public volumes which is maintained under the user ID TSOS. Files created here by the user or by the system are temporary files and can be processed with the access method EAM (see chapter "EAM - Event Access Method" (EAM - Event Access Method)). These EAM files are subject to different conventions than the other temporary files, e.g. the file naming: the first time an EAM file is opened, the system assigns a twobyte binary number (1 <= name <= 14000) as the file name and the user can use this number to address the file. In contrast to other temporary files, EAM files are not kept in the user catalog.
The system-created object module file is a special EAM file. It can be referred to as the * file or *OMF file. (Examples: specifying the ERASE * macro or the DELETE-SYSTEM-FILE *OMF command deletes the object module file.) The EAM macro also offers access to the object module file.
Logical system files
BS2000 uses system files for statement and data input to the operating system and for output of data and messages by the operating system. These input and output areas predefined by the system are known as logical system files; they are job-specific and therefore temporary files.
Just like other temporary files, the logical system files can be used without affecting the user's public-space allocation.
The total set of system files available to a job is called the SYSFILE environment. This is significant, for example, when writing checkpoints (see the WRCPT macro in the “Executive Macros” manual [2 (Related publications)]).
System files may be used as the input or output paths of the system, for example by means of the WRLST and RDATA macros (see the “Executive Macros” manual [2 (Related publications)]).
The Data Management System of BS2000 supports only the processing of permanent and temporary user files and of EAM files. Refer to the “Commands” [3 (Related publications)] and “Executive Macros” [2 (Related publications)] manuals for details of processing logical system files.