SLC database ACCESS procedures
 
 

Database ACCESS procedures provide means to turn on or off, standardize or reset specific digital devices such as, large power supplies, correctors, magnets, and klystrons. Different functions are created into the SCP panels so that the control room person would be able to use them at the appropriate time.

When a request to generate new database or to modify access procedures comes, files need to be created into the CMS library, just as any reference database file is created, but with ‘.access’ file name extension. They reside under the CMS_ACCESS library. Modify the abstract and modification sections in the header from the template, and note the name of the requestor. The verbs for the command language interpreter are coded or modified in the file. Include comments for the specific devices. Create or replace the file into CMS by using

    editaccess fn

Ask the systems administrator if you find that you need privilege to the CMS library.

The code is in the form of a scripting language, which uses primitives. See Ken Underwood’s access procedure document  for list of verbs and examples. Also there is online help on VMS and type: ‘slchelp access’.

Work on the code closely with the requestor, and especially note comments related to specific devices. Try to include as much qualifiers in one command-line. To exclude unit numbers, start with

    Set/device=(prim,micro,unit-unit)

followed by the range of unit numbers up to the one before the unit to exclude, and add the next range of unit numbers after that excluded unit, by the command:

    Add/device=(prim,micro,unit-unit)

The unit numbers will be stored in a list, and that list will be sticky to the subsequent commands requiring no qualifiers, such as LGON, or LGOF. Look for model files or templates in the ref_access directory to find the combination of commands suitable for the particular device. For instance, the verbs starting with PS: PSON, PSOF, PSRS, PSZR are for the PEP bitbus power supplies.
 
 

Test the script for syntax errors on the development host by running:

    slccom:access_test fn

where ‘fn’ is the test script file. Then the related panel files need to be modified or created, and tested on the SCP. As long as the test is done on the development host, the tester can check how the procedure executes. Try to run it from SCP and see that the script is free of syntax errors by looking at the global message section of the SCP panels or by running ERRDSP to see the logs of the test run.

The source of the script can be viewed by pressing ‘help’ on SCP. To include SCP panel help using the source, create the file into CMS by running

    edithelp panel_name

‘Panel_name’ is the touch panel name where the select button for the access procedure is under. Enter the keywords and comments for the help file. The touch panel name is the first level , and the button name is the second level in help. For example, the following lines represent the first-level and second-level keywords:

1 ACC_CID

2 CID_OFF

$Please try TYPE SLCACCESS:CID_OFF.ACCESS

The first level panel name is ACC_CID. The second level button name is CID_OFF and it needs to be the same parameter name just before the "@slccom:access cid_off" command procedure in the panel file. The next line will cause the help handler in SCP to display the script file when the help button is selected.
 
 

The ultimate test is when the script runs from the production host. Logs for the run can be found in ERRLOG, where every uncommented line in the access script file is logged. To look at the log, run ERRDSP and as an example, list the access script’s file where ‘fn’ is its name without the extension, with a command:

    ERRDSP> List/since=yesterday, before=today/string=fn

Another place to look at the logs is under the directory SLCLOG, and look for the file ‘fn’.log. If there are no other comments other than the login and accounting information in the file, the run for that script went well.
 

NLC SPECIFIC FUNCTIONS

The scripting language is unique and the verbs created are for specific devices. So the person writing the access procedure would need to work with the software developer who has the knowledge of device interfaces associated with the verbs. Existing files may be used as templates for procedures requiring a series of functions for similar devices. However if there are no existing files to base new devices with, it may not be clear as to what the right combination of verbs would be suitable for a particular device, and especially newer devices. For the NLC, new devices and/or device interfaces would imply new verbs will be designed, and any additions should also be included into the online help library.

The development of access procedure will rely on an expert system, where the person modifying or creating an access procedure would have to consult with the software developer who knows how to control the digital devices with the developed scripting language.
 
 

September  1999
Joan Paz