RD Controls

EPICURE Design Note No. 90.4

Epicure System-Level Environment

D.S. Baddorf, F.J. Nagy

Overview

The Epicure System-level Environment basically consists of:

• a manager account and captive operator accounts
• directory structure and file-naming conventions
• startup procedures within the above structures
• eventually, a captive code-distribution account

Currently, we have a real mess with different procedures, accounts and directory structures used on WARNER, DISNEY, the CAMAC Front Ends, the Cryo Workstations and the test stands.

Accounts

The overall structure will be to use EPICUREMGR and EOPERATOR accounts everywhere. EPICUREMGR owns the files, and does the initial startup at boot time. EOPERATOR can stop, start, restart, or check (is it running?) any product. The WARNER cluster will have accounts EPICUREMGR and EOPERATOR added to it. Software will be moved into these accounts (out of the WORK areas) when it is declared ``operational''. There will eventually be a distributor account on WARNER whereby systems programmers can distribute new versions of code to the EPICUREMGR area on WARNER and then on to the other nodes, but currently this is arranged through Deb.

This means the EPICURETEST accounts are to be changed on DISNEY, the CAMAC Front Ends and the test stands once the new system is in place. The EPICURETEST accounts will remain, for the diagnostics and trouble-shooting which cannot be done on the test stands, and individuals' setups and symbol definitions can remain there. On the test stands, the DAEWORK directory remains, to hold test versions of code.

Directory Structure

The EPICUREMGR account will be similar to the EPICURE_MGR accounts on the Cryo Workstations. However, we will redo the underlying directory structure. The Epicure H-kit distribution will NOT be used to maintain our software on systems under our direct control.

The current directory structure of the EPICURE_MGR accounts is to be scrapped and one adopted that is more like the structure used by the EPICURETEST accounts. That is the following subdirectories are introduced, with the obvious contents:

The master startup procedure will define logical names for all of these areas: RDCS_TOP for the top level, and RDCS_dirname for all the other areas (RDCS_DIAG, RDCS_DAR, ..., RDCS_LOGS, ..., RDCS_VDW). Since we already have logicals beginning with EPICURE_ for our programming environment on WARNER, the logicals for this system environment will begin with RDCS_ (RDC System). This will also allow us to use RDCU_ (RDC User) for the eventual user environment. Rules for our detached processes:

• Procedures to startup detached processes should include /OUTPUT= and /ERROR= qualifiers to write, respectively, .OUTPUT and .ERROR files in the log file area. Since the logical for the log file storage area (RDCS_LOGS) will be defined system wide, it can be used with these qualifiers. The file types must be .OUTPUT or .ERROR to avoid interference with the MAD_DELETER.

• Log file names shall be qualified by the node name. Use F$GETSYI(``NODENAME'') to get local host node name. Append this to the file name with something like:

  		$ node = F$GETSYI("NODENAME")
  		$ run ... /OUTPUT=RDCS_LOGS:filename-'node'.OUTPUT
  

• /DUMP may be used on the detached process. *.DMP files should also be sent to the RDCS_LOGS directory, as all others directories are to be considered ``read-only'' to the program. To send *.DMP files to the RDCS_LOGS directory, the startup process must do a SET DEFAULT RDCS_LOGS prior to the RUN RDCS_XXX:xxxxx/DUMP command. See EVERYNITE comments, below, for deletion rules.

• Detached processes should invoke LIB_LOG_SIGNALS so any unexpected signals (particularly aborts) are logged to OPCOM. Such messages should also go to an .ERROR or .OUTPUT file, since OPCOM is not generally watched.

An EVERYNITE.JOB will clean up the log file areas and the various subdirectories:

• Old .OUTPUT/.ERROR files with 0 blocks allocated will always be deleted.

• Non-empty .OUTPUT/.ERROR files will be deleted after N days. N will be 7 days initially. Files names are specifically chosen to avoid interference with the MAD_DELETER; hence the strict adherence to these file extentions.

• .DMP files will be deleted after days. will be 7 days initially.

EVERYNITE should monitor remaining disk quota and if necessary, lower the time limits and purge/delete files early, in order to free disk space used by EPICUREMGR. System, dump, output and error files will never be allowed to occupy greater than 100 MB of disk space. The remaining disk storage is considered dedicated to possible front end applications such as datalogging.

Startup

In order to get EPICURE going as soon as possible during a boot, the EPICURE startup job will be given special handling in our startup files. It will be moved to end of the COMMON_SYSTARTUP file, in parallel with the BOOTJOB task, and handled separately from the regular EVERYBOOT.JOB files. This will put the EPICURE startup in parallel with the completion of the SYSTARTUP, where VWS or DECWINDOWS is being started up, and will also overlap other BOOTJOB startups (which includes some logicals not needed by EPICURE, Decserver configuration restoration, DQS, RBMS, and Centurion startups, and other users' EVERYBOOT jobs).

In the EPICURE_SYSSTARTUP.COM file (running in the `node'_SYSTEM queue) will be the EPICURE startup:

• Check that the EPICUREMGR account exists via

  		$ getuai := $RDCS$EXE:GETUAI
  		$ getuai/exists=DO_EPICURE/default=WHERE  EPICUREMGR
  

• If DO_EPICURE is true then check for `where'EPICUREBOOT.JOB file (retain EVERYBOOT.JOB for regular use, possibly as an after-EPICURE-startup check that EPICURE processes and logicals are in place).

• If both checks pass, submit this batch job under user EPICUREMGR into `node'_SYSTEM queue. During queue setup, add line

  		$ SET ACL/OBJECT_TYPE=QUEUE  -
  		    /ACL=(IDENTIFIER=USE_SYS_QUEUE,ACCESS=READ+WRITE) -
  		    `node'_SYSTEM
  

  Do a one time grant of rights identifier USE_SYS_QUEUE to all EPICUREMGR accounts.

All of the above results in EPICURE processes being started earlier in the boot cycle. Currently, they wait for BOOTJOB to submit the EVERYBOOT.JOB and then to start the `node'_BATCH queue which runs these types of job. These two things happen quite late in the startup. The above changes will do the EPICURE startup in parallel with other BOOTJOB tasks. and while the STARTUP job is visibly finishing and VWS is starting. No synchronization problems are anticipated or noticed so far.

Notes

• When EPICUREMSG.EXE is moved from RDCS$LIB to RDCS_SYSTEM, one-time changes will be needed in EPICURELIB build. Changes might also be needed for the end-user Hkits. This change will be a second stage, after all code is being started from the EPICUREMGR area.

• Any programs writing files from within the code may need to be changed to follow file extension rules. This is again a one time change. I haven't noticed any wrong extensions on CYTST or BUGS yet.

Keywords: Epicure, program

Distribution: normal

Questions

• Who is responsible for installing software in operational systems?
  • It will be one person (system manager at present) with one or two backup persons trained.

• Who is responsible for installing applications and menu changes on DISNEY and on other nodes?
  • Again, it will be one person (system manager at present) with one or two backup persons trained.

• We absolutely must provide guidelines as to how and when products are updated on various production nodes. This includes:
  • Verifying copy integrity.
  • Timely startup of new versions in time to catch bugs.
  • Notification of operations (SOD and cryo) and experiments (NEWS?)
  • Administrative interlocks during operation for HEP (after 10/1/89).