In order for this site to work correctly, and for us to improve the site, we need to store a small file (called a cookie) on your computer.
By continuing to use this website, you agree to our cookies and privacy policy.
  
Home page Home page Home page Home page
Pixel
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel
Pixel

File Variables

Unlike some programming environments, AREV shields the developer from system level I/O. When files are read from and written to, the physical DOS files are opened, accessed and closed. This explains why AREV can have an unlimited amount of files "open" at one time.

To facilitate this, AREV stores the information it needs to access an AREV file quickly in the file variable. In this one place, the system brings together all the information that is required to gain rapid access to the DOS data file and if needs be the associated index. Before considering file variables it is necessary to point out that this article will only be considering linear hash files (RTP57) as each BFS has its own way of implementing file variables.

To understand the structure of a file variable it is first necessary to consider what information AREV needs to actually access a file. As you will be aware, ALL file i/o is routed via a BFS - the program that actually accepts the filing system opcodes and implements them. This BFS needs to know what file it is working on in a native format; the rest of the information is implicit to the BFS. Thus in its simplest form a file variable needs only to consist of the name of the BFS followed by the name of the DOS file (including path) to access. Were we to open a non-indexed file it would be seen that this is exactly what the file variable consists of. An EVAL statement such as EVAL OPEN "VOC" TO VF THEN CALL MSG(VF,"","","") would produce a display similar to this

         旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커
                       RTP57               
           000012000008SPREZZ\REV52008.LK  
             Press any key to continue     
         읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸

The file variable consists of two multivalues - the first is the BFS and the second all information relating to the DOS file. The first character of the 2nd multivalue is an offset into the value where the DOS file name is to be found. The characters between this first byte and the offset character contain the Modulo of the file and additional information. Thus in the above example, the first character is a CHAR(13), and at an offset of 13 characters from the offset byte, the DOS filename begins. Thus to extract a DOS filename from a non-indexed file variable one could just


0001        OPEN "VOC" TO VF THEN
0002         FILE_INFO = VF<0,2>
0003         OFFSET = FILE_INFO[1,1] ; FILE_INFO[1,1] = ""
0004         DOS_NAME = FILE_INFO[SEQ(OFFSET),999]
0005        END

The situation becomes more complex in the case of an indexed file variable. In this case to ensure maximum efficiency when writing to the file, it is desirable to have the index file information to hand as well as the data file information. Under these circumstances, the system adds additional information into the file variable as follows (where + represents sub-value marks and "~" represents text marks)

         旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커
                      SI.MFS+RTP57               
                          USERS                  
           RTP57~0000180000B1SPREZZ\REV52041.LK  
               0000170000E3SPREZZ\REV52000.LK    
                 Press any key to continue       
         읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸

Note that in this instance the variable now has a structure as follows

     < 1,1 >        Sub-value delimited list of MFSs/BFSs for Data File
     < 1,2 >        Filename
     < 1,3 >        BFS of Index File : @TM : Dos File Info of Index File
     < 1,4 >        Dos File Info of Data File

Thus if it is necessary to disable indexing on the fly (for example, when importing a DOS file into an indexed AREV file), the file could be opened to a file variable, and the file variable stripped down to its basic "non- indexed" form. To do this, it would be necessary to take the first multivalue of the file variable and, as the BFS is the last subvalue of the first multivalue, remove all other subvalues. Then as the file information is in the last multivalue of the variable it would be necessary to remove values two and three leaving the last value. Finally to construct a new file variable the first bit and the second bit would need to be concatenated together with a value mark.

This could be achieved by the following section of code (using extended sub-string manipulation features (see R/BASIC Command Reference N4.3 et seq))


0001    OPEN "PRODUCTS" TO FILE_VAR THEN
0002     *
0003     * Remove everything except RTP57
0004     *
0005     NEW_VAR = FILE_VAR<0,1>[-1,"B" : @SVM]
0006     *
0007     * Now remove file name, indexing file file var and just leave file info
0008     *
0009     NEW_VAR<0,-1> = FILE_VAR[-1,"B" : @VM]
0010     FILE_VAR = NEW_VAR
0011    END

A more generic version of the routine given above to obtain a DOS filename for a REV file could then be


0001        OPEN "VOC" TO VF THEN
0002         FILE_INFO = VF[-1,"B" : @VM]
0003         OFFSET = FILE_INFO[1,1] ; FILE_INFO[1,1] = ""
0004         DOS_NAME = FILE_INFO[SEQ(OFFSET),999]
0005        END

Volume File Variables

An incredibly useful application of this theoretical knowledge can be gained if one considers that the REVMEDIA file is itself a Linear Hash file (hence the LK and OV extensions). This being the case, given the file variable it would be possible to read and write the REVMEDIA file and by so doing, dynamically add/remove MFSs from a file regardless of the current account. To do this normally requires that the user be logged into SYSPROG but this is not always convenient.

As it is known that the REVMEDIA file is not indexed, the simpler form of file variable (BFS : @VM : DOS_FILE_INFO) is required. For a Linear Hash file it is known that the BFS is RTP57, the only additional information required is the Dos File Information. This can be extracted from the VOLUMES file. When a Volume is attached, a record is constructed in the VOLUMES file similar to this (where + is a multi-value mark)

         旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커
          14:52:30      02 APR 1989                          
          SPREZZ                                             
          TEMPLATES+POPUPS+HELP+MERGES+LABELS+DICT.MARKETING 
          RTP57                                              
          000010000002SPREZZ\REVMEDIA.LK                     
          Press any key to continue                          
         읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸

Note that the fourth field contains the BFS and that the fifth field contains the Dos File Information.. Thus it is possible to construct a volume file variable by simply taking the fourth and fifth fields of the volume record and concatenating them with a value mark. EG


0001        OPEN "VOLUMES" TO VF THEN
0002         READ VOL_REC FROM VF,"SPREZZ" THEN
0003          * Create file var
0004          FILE_VAR = VOL_REC<4> : @VM : VOL_REC<5>
0005          SELECT FILE_VAR
0006          EOF = 0
0007          LOOP
0008            READNEXT ID ELSE EOF = 1
0009          UNTIL EOF DO
0010            READ REC FROM FILE_VAR,ID THEN
0011             * Display results
0012             CALL MSG(ID : "||" : REC,"","","")
0013            END
0014          REPEAT
0015         END
0016        END

It can be seen that this can be used to permit manipulation of REVMEDIA entries.

As previously mentioned the above techniques can only be reliably used with RTP57. In the next issue, the use of direct calls to the BFS to establish the volume file variable will be introduced.

(Volume 2, Issue 7, Page 9)
Pixel
Pixel Footer R1 C1 Pixel
Pixel
Pixel
Pixel