The following examples go through some of the various options available when accessing a dataset. The simplest example as already been given, and is access to a dataset using the FATMEN shell.
We just type
FM> find generic-name unit
If unit is numeric, it will be interpreted as a FORTRAN unit number. Thus, after typing
find //cern/cndiv/jamie/test 11we would have the following.
One could also specify a unit such as VM11F001, if the file were to be read by VMIO, or any character string that would be used as a logical name or symbolic link, e.g.
find //cern/cndiv/jamie/test mydat
Our FORTRAN program could then open the named file MYDAT. (On VM or MVS systems, this corresponds to the DDNAME, rather than the file name.)
Normally, we will wish to issue the FIND command from FORTRAN, as this is more powerful. Although a routine FMFIND exists, we will describe the FMOPEN routine, which includes all of the functionality of FMFIND and more.
Our call to FMOPEN looks like
CALL FMOPEN('//CERN/CNDIV/JAMIE/TEST',CHLUN,LBANK,CHOPT,IRC)
Here, the generic name and unit are specified exactly as in the shell, and are both of type character. This permits the use of units such as VM11F001, MYDAT and so on. Again, if we call FMOPEN with
CALL FMOPEN('//CERN/CNDIV/JAMIE/TEST','11',LBANK,CHOPT,IRC)
the correct FORTRAN name on the system in question would be used.
The exception to this is when the generic name in question points
to a file which should not be processed by FORTRAN. In this case,
FMOPEN will automatically perform the correct operation.
For example, EPIO files on the IBM should be read with IOPACK,
hence FMOPEN will build a DDNAME of IOFILE11. (This was also
true for Zebra exchange format files on the IBM prior to
version 3.67, when FORTRAN I/O became the default).
Unlike the shell, FMOPEN will not only perform operations such as staging the file as required, but will also issue the correct OPEN. This may be overridden by the character option parameter CHOPT.
In the case of files to be processed by the Zebra FZ or RZ package, we can ask FMOPEN to perform the FZFILE or RZFILE call. For example,
CALL FMOPEN('//CERN/CNDIV/JAMIE/TEST','11',LBANK,'F',IRC)
where F indicates that a call to FZFILE is to be issued. FATMEN obtains the correct parameters for the call to FZFILE from the catalogue.
Another interesting option is the S option. This will instruct FATMEN to update the catalogue with the file size. This is useful for tape files, as future accesses will request a staging disk of the correct size, and hence use the system more efficiently.
We can also request that an automatic duplicate of the file is made into the robot at CERN (SMCF), via the D option. This option requires a pool of tapes gg_FAT1, e.g. XX_FAT1, in the TMS. Naturally, if a robot copy already exists a new one will not be made.
For a dataset on a tape volume to be accessible, a device capable of reading or writing the volume must exist on the local node, or on a server node, in the case of remote access to data or VAXcluster systems.
Suppose we wished to read the dataset with generic name //CERN/CNDIV/JAMIE/TEST. A copy of this dataset might exist on tape volume 123456. If this volume required a device of tape CT1, the FATMEN software will attempt to determine if such a device exists on the local node. Where remote tape access is available, it will check if such a device exists on one of the server nodes. This is done as follows.
A entry must exist in the file SETUP NAMES for the device CT1 (in this example). (Not yet implemented)
A logical name in the system table SETUP_CT1S (in this example) must exist for locally attached tapes. Served tapes must be defined in the file SETUP_EXE:TPSERV.CONF
An entry for the corresponding device must exist in the file /etc/shift.conf.
An entry for the corresponding device must exist in the file /etc/shift.conf or in the file /etc/TPCONFIG.
The above examples will work on both local and remote data, without any change. Note that a call to FMOPEN on an Apollo in Helsinki will not result in a cartridge being mounted in the robot at CERN. Remote access to tape data must be explicitly enabled. It is currently enabled in the SHIFT facility, where the data is staged via the CRAY, and on the L3 Apollos, where the data is staged through LEPICS.
Access to remote disk data requires explicit selection of a copy of a dataset. This may be done as shown below.
Example of using the FMSELK routine
* Argument declarations
PARAMETER (LKEYFA=10)
PARAMETER (MAXKEY=999)
DIMENSION INKEYS(LKEYFA),OUKEYS(LKEYFA,MAXKEY)
* The following statements will select all datasets
* with copy level (MKCLFA) of 1 (i.e. a copy of an original file),
* media type of 1 (i.e. disk) and location code of 1 (i.e. CERN)
INKEYS(MKCLFA) = 1
INKEYS(MKMTFA) = 1
INKEYS(MKLCFA) = 1
CALL FMSELK('//CERN/CNDIV/JAMIE/TEST',INKEYS,OUKEYS,NFOUND,MAXKEY,IRC)
IF(NFOUND.GT.0) THEN
* Just take the first one found which matches
CALL FMGETK('//CERN/CNDIV/JAMIE/TEST',LBANK,OUKEYS(1,1),IRC)
* Now pass the bank to FMOPEN.
CALL FMOPEN('//CERN/CNDIV/JAMIE/TEST','11',LBANK,'F',IRC)
ENDIF
In the current version this dataset would only be accessible if mounted via NFS.