HPlogo Accessing Files Programmer's Guide: HP 3000 MPE/iX Computer Systems > Chapter 3 Specifying a File Designation

System-Defined Files

» 

Technical documentation

Complete book in PDF
» Feedback

 » Table of Contents

 » Index

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 “System-Defined File Designators”. 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\DESIGNATOR (NAME)DEVICE/FILE REFERENCED
$STDINThe 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.)
$STDINXSame 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.
$STDLISTThe standard job or session listing device, nearly always a terminal for a session and a printer for a batch job.
$NULLThe 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 “Input Set” and Table 3-3 “Output Set”.

Table 3-2 Input Set

File DesignatorFunction/Meaning
$STDINJob/session input device.
$STDINXJob/session input device with commands allowed.
$OLDPASSLast $NEWPASS file closed. Discussed in the following pages.
$NULLConstantly empty file that returns end-of-file indication when read.
*formaldesignatorBack reference to a previously defined file.
filereferenceFile 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 DesignatorFunction/Meaning
$STDLISTJob/session list device.
$OLDPASSLast file passed. Discussed in following pages.
$NEWPASSNew temporary file to be passed. Discussed in the following pages.
$NULLConstantly empty files that returns end-of-file indication when read.
*formaldesignatorBack reference to a previously defined file.
filereferenceFile 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 “Passing Files between Program Runs”. 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.

Figure 3-1 Passing Files between Program Runs

[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 “Passing Files within a Program Run”.

Figure 3-2 Passing Files within a Program Run

[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 “New Files Versus $NEWPASS” and Table 3-5 “Old Files Versus $OLDPASS”.

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: Deallocate space. Delete control block entry.

Default close disposition: Rename to $OLDPASS. Save disk address in current job or session table. (Job Information Table) Delete control block entry.

Disk address not saved (Not in any directory).

Disk address saved for future use in the current job session.

 

Table 3-5 Old Files Versus $OLDPASS

OLD$OLDPASS

Directory (job temporary or system) searched for disk address

Disk address obtained from Job Information Table (JIT)

Disk address put into control block.

Disk address put into control block.

Default close disposition: Delete control block.

Default close disposition: Delete control block.

Disk address still in directory for future use.

Disk address still in JIT for future use in current job session.