next up previous contents index
Next: Description of user Up: Direct access input-output Previous: Main goals

Practical examples of usage of the RZ package

HBOOK

The RZ package is probably most widely used to store HBOOK histograms and ntuples, e.g. for subsequent analysis with PAW. In such cases, shared write access is not normally required. The file is typically created by a single user or job and subsequently read a small number of times.

Example of storing HBOOK histograms in an RZ file

PAW > ldir

 ************** Directory ===> //LUN1 <===

                  Created 911030/1215  Modified 911030/1215

 ===> List of objects 
     HBOOK-ID  CYCLE   DATE/TIME   NDATA   OFFSET    REC1    REC2     
          1       1   911030/1215    103       1       3    
          2       1   911030/1215    104     104       3    
          3       1   911030/1215    107     208       3    
          4       1   911030/1215    106     315       3    
          5       1   911030/1215    106     421       3    
          6       1   911030/1215     56     527       3    

  Number of records =    2  Number of megawords =  0 +  1606 words
  Per cent of directory quota used =    .050
  Per cent of file used            =    .050
  Blocking factor                  =  28.418
 PAW >

The above output from the PAW command LDIR shows the contents of an RZ file which has no subdirectories and a few histograms. The objects are accessed using the top directory name //LUN1 and the histogram ID.

One could of course have used a more complex directory structure, but the number of directories and objects in such a file is typically rather small.

CMZ

The CMZ code management system provides a good example of the use of the cycle facility of the RZ package. In a CMZ file, code is stored in the familiar two level structure of HIGZ, namely patches and decks. Each patch is a directory immediately below the top level directory of the file. Each deck is a Fortran vector in the directory corresponding to the appropriate patch, as is shown in the following example.

Example of the directory structure of a CMZ file

fatmen [0] ls
 Current Working Directory = //FATMEN
 Following subdirectories :
  HISTORY           FATFLAGS          FATDOC            *FATCAT         
  *DSYIBM           *GSIIBM           *SHIFT            *CERNVM         
  *CERNVMB          *FRCPN11          *LEPICS           *APOL3          
  *FAT2SQL          *FATSQL           *FATUSER          *FATO2Z         
  *FATO2F           *FATNEW           *FATSRV           *FATSEND        
  *FMCDF            *FMKUIP           *FATLIB           *SQL            
  *FODEL            *FOGET            *FOPUT            FFATMEN         
  FATHEAD           FATCDES           FATBODY           FATUTIL         
  FMTMS             FATUSER           FATSRV            FMUTIL          
  FMINT             FATUOUS           FATASM            L3UTIL          
  SQLCOM            FMLOGI            FODEL             FOGET           
  FOPUT             FMZTOR            FATO2F            FMOTOZ          
  FATNEW            FMKUIP            FMCDF             FATSQL          
  FMORAC            FMH               FMC               FATSTAT         
  TAPELOAD          NAMES             REXX              FATTEST         
  UNREF             DCL               SCRIPT            FATULOK         
  FATCAT            EXAMPLE           SQLINT            JCL             
  FAT2SQL           SQL               FATSEND           FMVAX
Following DECKS :
 TITLE;22    TITLE;21    
 Number of DECKS =   1 Number of CYCLES =  2
 fatmen [1] cd fmtms
 fatmen/fmtms [2] ls
 Current Working Directory = //FATMEN/FMTMS
 00_PATCH;1  FMALLO;1    FMGTMS;1    FMLOCK;1    FMPOOL;2    FMPOOL;1    
 FMQTMS;1    FMSREQ;1    FMULOK;1    FMPREF;1    FMXVID;1    FMTAGS;1    
 FMPROT;1    FMUTMS;1    FMUALL;1    FMQVOL;2    FMQVOL;1    FMUVOL;1    
 FMEDIA;1    
 Number of DECKS =  17 Number of CYCLES =  19
 fatmen/fmtms [3]

A listing of a given directory in 'ZEBRA' format shows that each deck is identified by a single Hollerith key, namely the deckname. RZ cycles are used to identify different versions of a deck. Each time it is editted and changed, a new cycle is automatically created.

Example of the keys and cycles structure in a CMZ file

 fatmen/fmtms [5] ldir

 ************** Directory ===> //FATMEN/FMTMS <===

                  Created 910923/1423  Modified 911028/1628

 ===> List of objects 
     DECKNAME      CYCLE   DATE/TIME   NDATA OFFSET   REC1    REC2     

     00_PATCH         1   910923/1423     19      1    471    
     FMALLO           1   910923/1423   1145     20    471     472 ==> 480   
     FMGTMS           1   910923/1423    441     13    480     481 ==> 483   
     FMLOCK           1   910923/1423    455     70    483     484 ==> 487   
     FMPOOL           2   911021/1503    906     19    541    5669 ==> 5675   
     FMPOOL           1   910923/1423    905     13    487     488 ==> 494
 ...

FATMEN

The FATMEN system uses the ZEBRA RZ package in a more complex manner. In this case the RZ files are read by many jobs simultaneously, often over the network. Much more complex object names are used, with pathnames such as the following example from the DELPHI collaboration.

Example of an RZ pathname in FATMEN

FM> pwd
Current Working Directory = //CERN/DELPHI/P01_ALLD/CDST/PHYS/Y90V03/E093.3/L0312
FM>

A single RZ file that is used by FATMEN may well contain in excess of one hundred thousand entries in several thousand directories. In addition, these RZ files are constantly updated and must retain consistancy to long running batch jobs.

These goals are met by ensuring that only a single process ever has write access to a FATMEN RZ file. All updates are performed by dedicated servers.



next up previous contents index
Next: Description of user Up: Direct access input-output Previous: Main goals


Janne Saarela
Mon May 15 08:34:47 METDST 1995