Computers: Universe: Remote Commands

A remote command is a pointer in the VOC file to a command record stored in another file. Typing in the name of the remote command record causes the command pointed to to execute.

The first line of a remote command carries its type (as do all VOC records): in this case, an R.

The second line contains the name of the file which contains the command record to be executed.

The third line contains the key to the command record to be executed.

An example follows:

>ED VOC DO.SOMETHING
New record.

----: I
0001= R
0002= VOCLIB
0003= SOMETHING
0004= (Press RETURN)
Bottom at line 3.
----: FI
"DO.SOMETHING" filed in file "VOC".
>

The command record pointed to by this record might run as follows:

>ED VOCLIB SOMETHING
New record.

----: I
0001= PA
0002= DISPLAY What would you like me to do? Go away.
0003= (Press RETURN)
Bottom at line 2.
----: FI
"SOMETHING" filed in file "VOCLIB".
>

Testing this example of a remote command produces the result:

>DO.SOMETHING
What would you like me to do? Go away.

Remote commands have two main uses:

1. Some commands, particularly long paragraphs, can be extremely large records. Large records can damage the performance of static files by causing overflow (see above, Static Files): and the voc is a static file. as every command, every parameter and every filename referenced by a universe application must be read from the voc before it can be interpreted, an overflowed voc file can cause an entire application to perform badly. by using a remote control, large voc records can be moved into another file, and replaced with small remote control records which point to them. in principle and file can be used to store the command, but he file voclib (short for 'voc library') is provided specifically for this purpose, and rather than allowing commands to be stored in many different files, it is probably better to keep them solely to the VOC and VOCLIB files. Note that in the example above I called the remote command DO.SOMETHING and the command itself SOMETHING, to minimise the danger that they would be confused. However, most commonly remote commands point to commands with the same name in the VOCLIB file: and this is good practice to follow.

2. Remote commands can carry an extra, fourth field, which is the name of a globally cataloged UniVerse Basic subroutine. Unless you have previous knowledge of UniVerse, this phrase will not mean much to you yet: but by the end of the section on UniVerse Basic you will know how to create these. They are simply a particular kind of program. If the name of such a program is included on the fourth line of a remote control, the program is run before the command is executed. If the program returns a '0' value in its final parameter, the command is not executed, and a security violation message is displayed. In this way, it is possible to apply security control to individual commands in the UniVerse command language: and this is the main purpose of this feature. However, it can also be used to log activity, provide help, or indeed anything that can be achieved using UniVerse Basic.

The program named on the fourth line of a remote control record accepts and returns certain parameters, another term which may be familiar to you from other programming languages, but will be covered in depth later. For now, it is worth recording the names of these parameters, so that you can return to this section once you're writing such programs:

REMOTE.COMMAND

The remote command VOC record itself

COMMAND

The command the user typed in, complete with parameters

LEVEL

0=Command typed in at UniVerse prompt, 1=Command invoked by another command, or 2=Command invoked by a command invoked by a command (or even more layered)

PORT

User's port number

ACCOUNT

The name of the account the user is in

USER

The user's login name

FLAG

Value returned by the program, 1 allowing the command to execute, 0 preventing it