HP 3000 Manuals HP 3000 Manuals
System-Defined Files
System-defined file designators indicate those files that the file system
uniquely identifies as standard input/output devices for jobs and
sessions. These designators are described in Table 3-1 . When you
reference them, you use only the file name; group or account names and
lockwords do not apply.
Table 3-1. System-Defined File Designators
---------------------------------------------------------------------------
| | |
| FILE | DEVICE/FILE REFERENCED |
| DESIGNATOR (NAME) | |
| | |
---------------------------------------------------------------------------
| | |
| $STDIN | The standard job or session input device from which |
| | your job/session is initiated. For a session, this |
| | is always a terminal. For a job, it may be a disk |
| | file or other input device. Input data images in |
| | this file should not contain a colon in column 1, |
| | because this indicates the end-of-data. (When data |
| | is to be delimited: use the EOD command, which |
| | performs no other function.) |
| | |
| $STDINX | Same as $STDIN except that MPE/iX command images |
| | (those with a colon in column 1) encountered in a |
| | data file are read without indicating the |
| | end-of-data; however, the commands :EOD and EOF |
| | (and in batch jobs, the commands JOB, EOJ and DATA) |
| | are exceptions that always indicate end-of-data, |
| | but are otherwise ignored in this context--they are |
| | never read as data. $STDINX is often used by |
| | interactive subsystems and programs to reference |
| | the terminal as an input file. |
| | |
| $STDLIST | The standard job or session listing device, nearly |
| | always a terminal for a session and a printer for a |
| | batch job. |
| | |
| $NULL | The name of a nonexistent ghost file that is always |
| | treated as an empty file. When referenced as an |
| | input by a program, that program receives an |
| | end-of-data indication upon each access. When |
| | referenced as an output file, the associated write |
| | request is accepted by MPE/iX but no physical |
| | output is actually done. Thus, $NULL can be used |
| | to discard unneeded output from a running program. |
| | |
---------------------------------------------------------------------------
As an example of how to use some of these designators, suppose you are
running a program that accepts input from a file programmatically defined
as INFILE and directs output to a file programmatically defined as
OUTFILE. Your program specifies that these are disk files, but you wish
to respecify these files so that INFILE is read from the standard input
device and OUTFILE is sent to the standard listing device.
You could enter the following commands:
FILE INFILE=$STDIN
FILE OUTFILE=$STDLIST
RUN MYPROG
Input/Output sets
All file designators can be classified as those used for input files
(Input Set), or those used for output files (Output Set). For your
convenience, these sets are summarized in Table 3-2 and Table 3-3
.
Table 3-2. Input Set
-----------------------------------------------------------------------------------
| | |
| File Designator | Function/Meaning |
| | |
-----------------------------------------------------------------------------------
| | |
| $STDIN | Job/session input device. |
| | |
| $STDINX | Job/session input device with commands allowed. |
| | |
| $OLDPASS | Last $NEWPASS file closed. Discussed in the |
| | following pages. |
| | |
| $NULL | Constantly empty file that returns end-of-file |
| | indication when read. |
| | |
| *formaldesignator | Back reference to a previously defined file. |
| | |
| filereference | File name, and perhaps account and group names and |
| | lockword. May be a temporary file created in |
| | current job/session, created and saved in any |
| | job/session. |
| | |
-----------------------------------------------------------------------------------
Table 3-3. Output Set
-----------------------------------------------------------------------------------
| | |
| File Designator | Function/Meaning |
| | |
-----------------------------------------------------------------------------------
| | |
| $STDLIST | Job/session list device. |
| | |
| $OLDPASS | Last file passed. Discussed in following pages. |
| | |
| $NEWPASS | New temporary file to be passed. Discussed in the |
| | following pages. |
| | |
| $NULL | Constantly empty files that returns end-of-file |
| | indication when read. |
| | |
| *formaldesignator | Back reference to a previously defined file. |
| | |
| filereference | File name, and perhaps account and group names and |
| | lockword. Unless you specify otherwise, this is a |
| | temporary file residing on disk that is destroyed |
| | on termination of the creating program. If closed |
| | as a temporary file, it is purged at the end of the |
| | job/session. If closed as a permanent file, it is |
| | saved until you purge it. |
| | |
-----------------------------------------------------------------------------------
An input file and a list file are said to be interactive if a real-time
dialog can be established between a program and a person using the list
file as a channel for programmatic requests, with appropriate responses
from a person using the input file. For example, an input file and a
list file opened to the same teleprinting terminal (for a session) would
constitute an interactive pair. An input file and a list file are said
to be duplicative when input from the former is duplicated automatically
on the latter. For example, input from a magnetic tape device is printed
on a line printer.
You can determine whether a pair of files is interactive or duplicative
with the FRELATE intrinsic call. (The interactive/duplicative attributes
of a file pair do not change between the that time the files are opened
and the time they are closed.)
The FRELATE intrinsic applies to files on all devices.
To determine if the input file INFILE and the list file LISTFILE are
interactive or duplicative, you could issue the following FRELATE
intrinsic call:
ABLE := FRELATE(INFILE,LISTFILE);
INFILE and LISTFILE are identifiers specifying the file numbers of the
two files. The file numbers were assigned to INFILE and LISTFILE when
the HPFOPEN/FOPEN intrinsic opened the files.
A half-word is returned to ABLE showing whether the files are interactive
or duplicative. The half-word returned contains two significant bits, 0
and 15:.
if bit 15 = 1, INFILE and LISTFILE form an interactive pair
if bit 15 = 0, INFILE and LISTFILE do not form an interactive pair
if bit 0 = 1, INFILE and LISTFILE form a duplicative pair
if bit 0 = 0, INFILE and LISTFILE do not form a duplicative pair
Passed files
Programmers, particularly those writing compilers or other subsystems,
sometimes create a temporary disk file that can be automatically passed
to succeeding MPE/iX commands within a job or session. This file is
always created under the special name $NEWPASS. When your program closes
the file, MPE/iX automatically changes its name to $OLDPASS and deletes
any other file named $OLDPASS in the job/session temporary file domain.
From this point on, your commands and programs reference the file as
$OLDPASS. Only one file named $NEWPASS and/or one file named $OLDPASS can
exist in the job/session domain at any one time.
The automatic passing of files between program runs is depicted in Figure
3-1 .
To illustrate how file passing works, consider an example where two
programs, PROG1 and PROG2, are executed. PROG1 receives input from the
actual disk file DSFILE (through the programmatic name SOURCE1) and
writes output to an actual file $NEWPASS, to be passed to PROG2.
($NEWPASS is referenced programmatically in PROG1 by the name INTERFIL.)
When PROG2 is run, it receives $NEWPASS (now known by the actual
designator $OLDPASS), referencing that file programmatically as SOURCE2.
Note that only one file can be designated for passing.
![[]](../../pic3k/M012018/FFN103c50.gif)
Figure 3-1. Passing Files between Program Runs
:
FILE SOURCE1=DSFIL
FILE INTERFIL=$NEWPASS <---
RUN PROG1 |- Same File
FILE SOURCE2=$OLDPASS <---
RUN PROG2
:
A program file must pass through several steps as it is executed; passed
files are most frequently used between these steps. A program file must
be compiled and linked before it is executed. By default, the compiled
form of a text file is written to $NEWPASS. When the compiler closes
$NEWPASS, its name is changed to $OLDPASS; it is this file that is linked
for execution. The linked form of the program file is written to a new
$NEWPASS, which is renamed $OLDPASS when the file is closed; the old
$OLDPASS is deleted. Now, this file is ready to be executed. This
$OLDPASS may be executed any number of times, until it is overwritten by
another $OLDPASS file.
The steps that a program takes as it is run are depicted in Figure 3-2
(*).
![[]](../../pic3k/M012018/FFN113c50.gif)
Figure 3-2. Passing Files within a Program Run
$NEWPASS and $OLDPASS are specialized disk files with many similarities
to other disk files. Comparisons of $NEWPASS to new files, and $OLDPASS
to old files, are given in Table 3-4 and Table 3-5 .
Table 3-4. New Files Versus $NEWPASS
--------------------------------------------------------------------------------------------
| | |
| NEW | $NEWPASS |
| | |
--------------------------------------------------------------------------------------------
| | |
| Disk space allocated. | Disk space allocated. |
| | |
| Disk address put into control block. Disk address put into control block. |
| | |
| Default close disposition: | Default close disposition: |
| Deallocate space. | Rename to $OLDPASS. |
| Delete control block entry. | Save disk address in current job or session |
| | table. (Job Information Table) |
| | Delete control block entry. |
| | |
| Disk address not saved | Disk address saved for future |
| (Not in any directory). | use in the current job session. |
| | |
--------------------------------------------------------------------------------------------
Table 3-5. Old Files Versus $OLDPASS
---------------------------------------------------------------------------
| | |
| OLD | $OLDPASS |
| | |
---------------------------------------------------------------------------
| | |
| Directory (job temporary or | Disk address obtained from Job |
| system) searched for disk address | Information Table (JIT) |
| | |
| Disk address put into control block. Disk address put into control block.
| | |
| Default close disposition: | Default close disposition: |
| Delete control block. | Delete control block. |
| | |
| Disk address still in directory | Disk address still in JIT for future
| for future use. | use in current job session. |
| | |
---------------------------------------------------------------------------