17 Running under ICL

All the example programs discussed so far have been tested under the familiar DCL (Digital Command Language). However this approach does not allow ADAM to fulfil its rôle as a multi-tasking software environment. This means that a number of tasks (each task is a VMS process) can be active simultaneously and can communicate with each other. This functionality can be achieved using the Interactive Command Language (ICL). A full description of ICL is given in the ICL Users’ Guide available as a Starlink MUD. Section 18 discusses how to write the ICL equivalent of DCL command procedures.

One advantage of using ICL is speed. The following simple experiment should demonstrate this.

Set up a symbol to run one of the ADAM programs. (The example below uses REPDIM2 which reports the dimensions of the input NDF – as described in Section 6.)

Now run the program on an NDF:

Try this a few times and note how long it takes. A significant fraction of the run-time of this small program is occupied with loading the executable code into the computer’s memory. This loading takes place every time the program runs.

The session below shows how to run the same program under ICL:

This takes just as long as running the program under DCL, but the executable image has been loaded into a subprocess, in this case named 012DREPDIM2. This process remains active after the program execution is completed. Consequently on second or subsequent runs, the program execution begins immediately – with a large increase in speed for the user.

The process will endure throughout the ICL session unless the maximum number of allowed subprocesses is reached at which point the least recently used process will be killed.

For example, after loading REPDIM2 you might try loading some other programs. In the continuation of the session above, commands for ADDNEW and ADDCONST are defined and the programs run. The ICL command TASKS shows which tasks are active.

Three¹⁵ is the maximum number of tasks which can be simultaneously active. When another program is loaded the user is warned that the REPDIM2 process is being killed; a subsequent invocation of REPDIM2 would require it to be loaded again.

You can explicitly kill a process by typing KILL process name. All processes are usually stopped when the user leaves ICL by typing EXIT.

Monoliths.

The need to kill and reload tasks can be reduced by organising a group of programs into a monolith – such a monolith is loaded as a single task. KAPPA and the ICL version of Figaro are arranged in this way. The disadvantage is that the first time a program from the monolith is invoked, the whole monolith must be loaded. However once the monolith is loaded any programs it contains are ready to run. In the example below, once KAPPA is loaded, all the KAPPA commands are ready to run. (Section 21 explains how to build a monolith.)

Words of warning.

Programs which run under DCL should give the same results under ICL. Several possible problem areas should be noted:

Initialisation of variables – the programmer who relies on VMS initialising variables to zero will get away with this carelessness when running Fortran programs under DCL. However program variable values are ‘remembered’ between invocations of a program under ICL, so uninitialised variables may well have non-zero values. So don’t rely on initialisation to zero!

Case of input parameters – parameters entered on a DCL command line are automatically converted to upper case, but this does not happen on an ICL command line. This may catch out the program which is case sensitive. So don’t write case-sensitive programs if you can help it!

Message synchronization – as discussed in Section 5, it is possible for message reports to be made on the graphics screen of a VDU when running under ICL. An example of this undesirable behaviour occurs when a program reads and reports a series of cursor positions. The messages which report the co-ordinates may be output on the graphics screen – and may overwrite previous messages. This occurs because graphical output (such as the cursor) is sent directly to the terminal and causes a switch to graphics mode; text output is buffered and may arrive after the switch to graphics has occurred. The solution is to flush the textual output buffer immediately before any graphical output (such as a cursor call). This is done with the call:

        CALL MSG_SYNC (STATUS)

The program ADAM_EXAMPLES:CURSOR.FOR has this call in the necessary places; without the MSG_SYNC calls, the program exhibits the problem described above.

DCL commands.

DCL commands can be executed from ICL by prefixing the DCL command with ‘$’ (or ‘DCL’) thus:

The first time a DCL command is entered in an ICL session, a subprocess for executing DCL commands will be created. Note that although abbreviated forms of commands can be used, it is necessary to enter the complete DCL command on a line as the user cannot be prompted for unspecified command parameters. (So you cannot type $ SHOW and be prompted with _What?) Another consideration is that DCL commands are run in a separate process from the main ICL ‘command’ process. This has several implications. For example, changing the default directory in the DCL subprocess does not affect that associated with the command process; this remains set to the directory current when the ICL process began. The command DEFAULT can be used to set the default directory for both the command process and DCL subprocess, thus:

Similar comments apply to the allocation of devices such as tape drives to processes.