[1]The file description information will normally be left as zero, or set to the first and last record and block numbers. They could also be used to indicate a subset of a file. [2]The date and time fields are stored packed, using routine FMPKTM. They can be unpacked using routine FMUPTM.
The disk file name should be entered in the format of the host operating system. For VM/CMS systems, the convention <user.address> filename.filetype is used. If address is omitted, user may then be any valid entry in a GIMEUSER, GIMEGRP or GIMESYS names file. If not found in a GIME names file, the default address 191 will be used.
An extract from a GIME names file is given below:
:NICK.L3DSTS :USERID.L3MAXI
:ADDR.222
:LINKMODE.RR
:FILEMODE.E
Using this example, files such as <L3DSTS>RUN1.DST would be assumed
to be on the 222 disk of user L3MAXI.
For VAX/VMS systems, the full file name, including disk and directory names should be entered.
If the FATMEN software finds that the current node is in the same cluster as the node specified in the FATMEN catalogue and the disk specified is available, it will treat the entry as if the file were on the current node.
Example of valid disk file names for the cluster VXCERN
* Create a valid entry in an existing FATMEN bank
CALL UCTOH('VXCRNA',IQ(LFAT+MHSNFA),4,6)
* or we could use the VAXcluster alias rather than current node name
CALL UCTOH('VXCERN',IQ(LFAT+MHSNFA),4,6)
* Create a valid disk file name
* Note that logical name for disk is unique and consistant HEP-wide!
CALL UCTOH('DELPHI$DK123:<DELPROD.MCDSTS>RUN567',
+ IQ(LFAT+MFQNFA,4,35)
The FATMEN system can use DFS[11] or NFS[10] to access a remote disk file, if the disk or file system on which it resides is mounted locally. Users are strongly recommended to adopt a convention for DFS and NFS names, so that the same name is used throughout a LAN. For DFS it is recommended that the disk in question have the same logical name on the system to which it is directly attached as on those where it is mounted via DFS. Thus, a disk on the central cluster with logical name VXCERN$DISK999 should be mounted remotely via DFS with the same logical name. If the FATMEN system finds a DFS device of the corresponding name on the local system, it will assume that the physical device to which it points is indeed the correct one. N.B. the FATMEN software currently considers only the 'system' logical name table ( LNM$SYSTEM_TABLE).
Example of mounting a remote disk via DFS
$!Mount the VXCERN disk DELPHI$DK123 $!The 'access-point' is defined on VXCERN and points $!to the disk in the previous example. This will allow $!users on the current node to access data on this disk $!that is catalogued in FATMEN transparently. $RUN SYS$SYSTEM:DFS$CONTROL DFS>mount access-point DELPHI$DK123 /SYSTEM DFS>exit
If the dataset name in the FATMEN entry (MFQNFA) starts with a $, then on Unix systems FATMEN will assume that the text that follows up to the first slash character is an environmental variable and attempt to translate it. An example is given below.
FM> ls C01 -gn # List full generic name and corresponding dataset name //CERN/OPAL/DDST/PASS4/FYZ1/P19R1973/C01 Fileid: $OPALDATA/fyz1/p19r1973.c01 Files: 1 FM>quit [zfatal] > echo $OPALDATA /u/ws/ddst [zfatal] > [zfatal] > [zfatal] > telnet shift1 ... shift1 [2] printenv OPALDATA /user/ws/data shift1 [3]
This is an integer code indicating the LAN or site where the data resides. Currently, the only supported LAN is CERN, for which the location code is defined as 1. This code is used by the FATMEN system for a first pass selection of the best copy of a data set. The correspondance between the location code and the LAN will be stored in the FATMEN database itself.
This is obtained through QUERY USERID on VM/CMS systems, the $GETJPI system service on VAX/VMS and the getpwuid function on Unix.
This is obtained through JOBNAM (CERN Program Library Entry Z100) on VM/CMS systems, the $GETQUI system service on VAX/VMS and the getpwuid function on Unix.
This is obtained through the QUERY ACCOUNT command on VM/CMS, the $GETUAI system service on VAX/VMS or the getuid function on Unix.
This is obtained through the QUERY USERID command on VM/CMS and the $GETSYI system service on VAX/VMS.
This is obtained through the QUERY CMSLEVEL command on VM/CMS and the $GETSYI system service on VAX.
This is obtained using the CP QUERY USERID command on VM/CMS systems and the $GETSYI system service on VAX/VMS machines.