Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1367

News	FAQ
Search	Home

Activation

It is clear from the user requirements that it must be possible to run aips++ tasks from an ordinary user account rather than a generic ``aips'' account, and from a unix shell, such as Bourne shell or C shell. These requirements have a significant bearing on the way that task activation is implemented. In particular, it means that tasks must be able to determine system parameters for themselves at run-time. For example, a task might need to determine the amount of memory installed in the machine on which it is running (this would be stored in $AIPS/$ARCH/$VERS/$SITE/$HOST/aipsrc). It is unrealistic to suppose that all information of this type be translated into environment variables defined from the user's login script, so the aipsrc databases themselves would have to be consulted at run-time. That is, an aips++ task or script which needs to know about devices etc. will read the aipsrc files as required.

The information stored in the aipsrc databases could be said to be static in that it does not change between invokations of aips++ tasks. However, some parameters may change between a user's login sessions, in particular, $ARCH and $HOST. Moreover, $PATH, must be known in order to start a task, and $AIPS, $VERS, and $SITE are required to find the aipsrc files themselves. Information of this kind would be stored in ``activation'' databases.

It would be desirable to minimize the number of environment variables that need to be defined in order for a task to be activated. The most basic requirement is that the user's PATH be modified to include the aips++ binaries and scripts. In general this would involve evaluating $ARCH and is more than can be done by a single line entry in a user's login file, unless it be an invokation of a special purpose script, i.e.

     . /aips++/aipsinit.sh

for Bourne-like shells, such as sh, bash, ksh, and zsh, or

      source /aips++/aipsinit.csh

for C shell-like shells, such as csh and tcsh. Although it is possible to determine a host's architecture by indirect means (as does the vi/wave/bin/arch script in PVwave), these are rather kludgy and a $AIPS/hosts database would be needed to resolve $SITE as well as $ARCH. $VERS should default to base unless overridden by a command-line argument to the aipsinit.[c]sh script.

Apart from redefining the user's path, the aipsinit.[c]sh script must also define $AIPS as an environment variable so that any aips++ task can find the $AIPS/hosts database and rederive $ARCH, $SITE and $HOST for itself, since it will need these to find the aipsrc databases. Since the users specify $VERS at login time, it must also be recorded by aipsinit.[c]sh as an environment variable. Alternatively, it may be more efficient to store $ARCH, $SITE and $HOST as environment variables also, or instead have one single environment variable which stores all five components.

As discussed below, aips++ will probably use server processes for image display, remote tape access, and other functions. It would be best to free aips++ users from responsibility for the activation of these servers; tasks should start them automatically where required. The inetd mechanism, in which a server is activated when a client requests a connection, would be ideal for this purpose. However, it would require a root installation on all server machines and this is inadmissable. One solution would be for the client to try to connect() to the server and, if this fails, try once to system() an rsh script which activates it. Certain implementation problems have been glossed over here. Suffice it to say that efficient, automatic activation of servers, particularly image display servers, may be challenging.

The problem of assigning tcp or udp port numbers to network services has been discussed at length in the aips2-tools exploder. There is a potential for conflicts if port numbers are adopted arbitrarily, but registration of port numbers in the /etc/services file would require root privilege and so is inadmissable. aips++ therefore needs a mechanism for the flexible allocation of port numbers, and to this end, a site-specific set of numbers for each service could be specified in the aipsrc databases. When a task invokes a server via rsh as described above, the port number would be passed to the server as a command-line option.

Where aips++ tasks are being initiated from an interactive unix shell, users will be required to implement multi-tasking for themselves by backgrounding and foregrounding jobs in the usual way. Multi-tasking should probably be implemented automatically within the aips++ shell itself.

One of the advantages of providing for aips++ tasks to be run from a unix shell is that it provides a simple method for creating procedure scripts. Within these scripts it is conceivable that non-aips++ tasks might be interspersed with those of aips++ . These scripts would also be suitable for submission to the host operating system's batch facility. However, there was a clear requirement in the user specifications for a batch system in aips++ , and given the poorness of some unix batch systems, aips++ will probably have to implement its own batch system eventually.

Any procedure scripts required in aips++ , for example those required for activating servers, may be written in perl. The simple aipsinit.[c]sh Bourne shell and csh scripts which define environment variables would still be required. Likewise the scripts used to define directory logicals for programmers who want them.

Given that aips++ will be installed and provided at many sites by a centralized management, a standard mechanism for sending messages to users should be included in the distribution. A simple system called GRUNT has been operating for some time within $\cal {A}$IPS at the ATNF and has proved invaluable. It records which users have read each message so as to avoid printing the same message twice. We have found that users are much more likely to pay attention to messages if the only messages they receive are new ones, although they still have the option of reviewing old messages via the ``NEWS'' command if they want. GRUNT allows for multiple message classes, and for deactivating old messages without deleting them so they can be kept as a record. It does, however, require that users run from their own account so they can be identified. We will probably also want to integrate it with the documentation system.