RevMedia

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

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))

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

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

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.