RevMedia

RTPs (Run Time Programs) are those programs used within the system to do the legwork. They are to our application what DOS is to AREV. The routines for the most part make use of the SYSCOM area and thus cannot be called from our own program. The only way around this is to call the RTPs via an EVAL statement (for an explanation of SYSCOM and why EVAL works see notes following). This is frequently too much of an overhead to be of any use.

A working knowledge of the RTPs can be incredibly useful when we get an "RTP xxx Variable Not Assigned a Value" message. If we know what individual RTPs do, we will find it that much easier to correct any errors.

Notes: SYSCOM (Short for SYSTEM COMMON) is that group of common variables set aside for use by the system. As an example of the sort of information that is stored in SYSCOM we have the Break Key Status, the Printer Status etc. One interesting area to consider is the @FILES variable which contains the files attached. This is in fact a dimensioned System Common variable with five elements. To check this out, simply drop into the debugger and type /@FILES. Note that the debugger shows you each array element one at a time. Those of you have who programmed AFSs and MFSs will realise that you have had to duplicate elements of the @FILES variable yourself (Annoying eh?), but most of them are not available to the end user programmer. The only way to gain access to these variables is with a System Compiler, something that understandably Revelation Technologies do not release.

The EVAL statement has to contain the SYSCOM area to be able to call RTP5 directly. Thus by EVALing your calls to RTPs you can include the SYSCOM area and thus explore the use of RTPs. This will not work with all RTPs, especially those that return an implicit "True" or "False" (eg READV rec FROM file.var,id THEN true ELSE false) as we cannot intercept this THEN or ELSE and consequently get a stack overflow. Note that if you try this no responsibility is accepted for the results - and if backing up is not yet a habit with you I suggest you change NOW!

If you do wish to amend RTP1 to change the logon processing messages do the following -

    Firstly back up your system

    Just in case things do go wrong, make an extra copy of REVBOOT at dos
    (call it REVBOOT.BAK or somesuch), that way if after making the changes
    you find that you cannot log in, you just copy your backup copy onto
    REVBOOT and try again. (NB do not call it REVBOOT.OLD as the system uses
    this name when we rebuild REVBOOT later).

    Log into SYSPROG

    EDIT VERBS $RTP1 (Ensure the status line displays Ed Ovr)

    Ctrl-F to find the processing message you want

    Overwrite the message with your own (NB Ensure that you own message is
    of IDENTICAL length to that it replaces)

    Save the record and return to TCL

    At TCL type BUMP

    In the BUMP window, change your network driver to something else and
    press return. Confirm that you wish to do the change and the system will
    then display the "Rebuilding REVBOOT" message.

    Change your network driver back to what it was (same steps as above) and
    log out.

This should have changed the message.

NB: To remove AREV 1.1 banner invoke AREV (S

(Volume 1, Issue 1, Pages 5,7,8)

GENERAL NOTES

At logon, all routines found in SYSOBJ are loaded onto the Program Stack and remain there for the duration of the AREV session. Thus if we want our routines to stay memory resident, we can put the compiled code into SYSOBJ.

If however, we do not wish to clutter up SYSOBJ with our object code, we can put the name of our routine into a record called SECONDARY.LOAD in the SYSOBJ file, and put the object code for the routine into the VERBS file. Once SYSOBJ has been loaded onto the stack, the bootstrap processor checks SECONDARY.LOAD and puts the object code pointed to by the source names onto the Program Stack.

One point to note with this is that the name of the routine must be the name as it is found in the VERBS file without the $ sign. It is not enough that it be a catalogued routine. Putting the name of a catalogued routine into SECONDARY.LOAD will (if the object code is not in VERBS) prevent you form logging back onto the system. AREV will display a W175 message and then return you to DOS. The only way around this problem is to either restore your REV00001.* (SYSOBJ - unless you've recreated it ) files from a backup, or to use a Q-Pointer from another AREV system to reinstall the SECONDARY.LOAD record. So if you are going to play with SECONDARY.LOAD ensure that you have backed up your SYSOBJ file first! (OK, I admit it, I didn't...).

Again, it is worth pointing out that object code in SYSOBJ or VERBS does not need a CATALOG pointer, but there is no guarantee that subsequent AREV upgrades will not overwrite our code. If you use this method be aware of the potential problems and call your routines by names unlikely to be overwritten (E.G. MY.OWN.POPUP not POP.UP!).