The MD table was originally introduced to support CTO conversions from "traditional" multivalue databases, but has functionality that may be useful to all OpenInsight developers. The MD table is in many respects comparable to the VOC table, though the records stored in the MD table are typically more compatible with the original PICK (R83) MD file.
Records in the MD table fall into four broad classes:
1. "Pointers" to executable routines;
2. Batch routines (or "pointers" to batch routines);
3. "Pointers" to tables; and
4. User-defined records
OpenInsight, CTO, and AREV32 look in both the MD and VOC table for any relevant record when a stored procedure is invoked, or when a table is about to be opened.
The order in which these tables are searched will vary depending on whether the invocation of the stored procedure occurs in the OpenInsight, CTO, or AREV32 environmen - in CTO, the MD table is searched before the VOC table; in OpenInsight and AREV32, the VOC table is searched before the MD table.
It is important to remember that, since OpenInsight, CTO, and AREV32 check BOTH the MD and VOC tables by default, you may experience unexpected behavior if records with the same name are stored in both the MD and VOC tables.
In all cases, though, the designated table(s) are searched for the executable pointers or batch routines, or table pointers, as appropriate; if no entries are found in these tables, then the default system behavior occurs.
It is also possible to customize which table(s) are checked by CTO and AREV32 for executable pointers. If CTO or AREV32 find a record named PROCPATH in the MD table, the list of tables specified in field 2 of this record (@VM-delimited) defines which tables should be checked for executable and batch routines and pointers.
A special table named MD_MASTER contains the basic, default information that should be contained in any application's MD table; if for any reason an application does not have an MD table, or must have a new MD table created, the contents of the MD_MASTER table should be copied into the application-specific MD table for proper system operation.
When OpenInsight prepares to run a stored procedure, it first locates where the "object code" for that stored procedure should be loaded from. By default, this is the SYSBOJ table; however, the MD table allows you to specify explicitly the table (and even the record name) of the object code to load. Using these "catalog pointers", developers can store object code in non-SYSOBJ tables. The layout of the catalog pointer is:
ID: Name of stored procedure
1. P
2.
3.
4.
5. <object code table name>
6. <object code record name>
This is comparable to the "catalog pointers" that are normally found in the VOC table (as generated by AREV/AREV32), though the VOC record layout is:
ID: Name of stored procedure
1. RBASIC (or VERB)
2.
3. <object code table name>
4. <object code record name>
Pointers to U2 executables (accessed via the U2 BFS) can also be defined; these are identified by "U2" in field 1 of the record.
Addionally, internal CTO executable pointers are located in the MD table; these are identified by a "V" in field 1 of the record.
The MD table allows you to define batch routines that can perform tasks nearly as complicated as basic+ stored procedures. The MD table supports both PROC and PARAGRAPH batch syntax. A PROC can be identified by the letters "PQ" in field 1 of the MD record; a PARAGRAPH will contain the letters "PA" or "S" in field 1.
Though a full discussion of the PROC and PARAGRAPH syntax is beyond the scope of this document, the following functionality is supported in PROCS:
Proc Chaining - [], ()
User Exits - U01AD, U31AD, U01A6
Primary and Secondary Buffer Manipulation - A, B, F, +, -, R, S
Labels/GoTo
Output Buffer Manipulation - H, STON, STOFF, P, PW, PX, PH
Console Input and Output - O, T, I, D, IH, IP, IS, IN
Comments - C
Conditional Evaluation - IF {#}{SEA} {⇒<][#}
The following functionality is supported in PARAGRAPHS:
Console input and output - CLEARPROMPTS, DISPLAY, «prompts»
Execution control - ABORT, LOOP, REPEAT, GO
Conditional Evaluation - IF
Output Buffer Manipulation - DATA
The internal processing of tables in OpenInsight has been enhanced to allow for "redirection" through MD records. When a table is accessed, OpenInsight will look in the MD table to see if there is a pointer record with that table name; if a pointer record does exist, then the information in that record will be used to find the proper table to open. The layout of these pointer records is:
ID: Name of table
1. Q
2. {<application name>}
3. {<real table name>}
Because the first field of this pointer record contains a "Q", these are often referred to as "q-pointer records". If an application name is specified in field 2, then that application must contain the requested table (either attached to the database definition, or defined in that application's MD table); if left blank, then the current application is assumed. If the real table name is specified, then that is the actual table that will be accessed; if left blank, the originally requested name is used.
For example, the MD of the SYSPROG application might contain the following record:
ID: CUST
1. Q
2. EXAMPLES
3. CUSTOMERS
Any requests to access a table named CUST while in the SYSPROG application will actually access the CUSTOMERS table in the EXAMPLES application.
RTP9’s q-pointer handling, by default, will work in the “normal PICK way”: any time a q-pointer record is accessed, it is “resolved” at that time, and so any changes to any q-pointers are immediately reflected. This provides the ultimate flexibility, but at the cost of performance – each time the q-pointer is accessed, we must trace through and find where it _really_ lives.
Now, If desired, developers/users can set a flag in SYSENV (CFG_QPTR, and its various permutations – CFG_QPTR*app*user, CFG_QPTR**user, CFG_QPTR*app) to allow for the q-pointer information to be retained after it has been resolved. This means that any changes to the q-pointer, after it has been accessed, will NOT be immediately seen; instead, users will need to exit/re-enter OI/CTO/AREV32/whatever to see their changed q-pointer, or they can run DETACH_TABLE on the q-pointer. This provides much better performance, at the cost of the flexibility that “traditional MV” users expect.
Any other user or configuration record might be stored in the MD table; traditionally, these should contain an "X" in field 1.