EPICURE Software Release Note 3.1
EPICURE Code Development Environment
Project Work Areas
The code development environment on WARNER accommodates EPICURE, CRYO and OPS software development. The three types of development environment share command files but have parallel disk structures. It is important to keep the work environments separate, but to allow for easy switching between them. Commands are provided to move between directories and to set up the project. Commands are the same among the environments. A single set of commands is provided so that another programmer can easily step into the project when the first programmer leaves or is on vacation.
Shared symbol and logical definitions are set up by including the following line either in one's login file, or in another file which is always run before entering the WORK areas. You could put it in another file if you do not want these symbols and logicals defined except for sessions when you intend to work on software projects.
$ @PROJECT_COMMANDS:EPICURE_LOGIN.COMOne logical defined is PARAM_DIR. This is a directory where these procedures write internal information. If you have defined a logical USER_LANDFILL_SITE, then PARAM_DIR will point to that location. (Several programs on the WARNER systems use the landfill logical, so you can avoid having stuff left in your SYS$LOGIN directory. See RD Controls Software Release No. 49.) If you have no landfill logical, PARAM_DIR will point to a subdirectory in your SYS$LOGIN area called [.PARAM_SAVE]. Then, if the directory pointed to by PARAM_DIR does not exist, the EPICURE_LOGIN file will create it. This will only happen once.
Additional symbols which you may want to define are done by:
$ @PROJECT_COMMANDS:EPICURE_LOGIN_AUX.COMIt is strongly suggested that you read through this file of auxiliary symbols before running it. Some of the symbols may conflict with symbols you have already gotten used to using in your own login file. Some of them you may just decide you are unlikely to use. This file is now segmented into two parts. As you can see by reading the command file, if the set of symbols at the end conflicts with your normal usage, you can avoid them by calling the procedure with a parameter ``PARTIAL'':
$ @PROJECT_COMMANDS:EPICURE_LOGIN_AUX.COM PARTIALIf you don't want to use any of the symbols in this auxiliary file, you don't have to call it at all.
As mentioned, there are three types of software development sharing this structure. The three types are referred to as ``environments''. One's environment can be EPICURE, CRYO, or OPS.
Following the invocation of the EPICURE_LOGIN command file, you should select your environment. This can be in your login file or wherever you have put the EPICURE_LOGIN command file. Use only one of the following lines:
$ ENVIRONMENT EPICURE
$ ENVIRONMENT CRYO
$ ENVIRONMENT OPS
Later, the environment can also be changed interactively so that you can work in more than one environment. Since you will probably have one environment that you work on most often, it is best to declare that environment from the same command file which calls the EPICURE_LOGIN file.
The EPICURE_LOGIN command file defaults the environment to EPICURE. EPICURE programmers therefore don't really need to declare an environment, but it is still a good habit.
The command ENVIRONMENT can be abbreviated to ENV for faster typing.
This is an optional step. If you know what project you need to work on you can skip this step. However, this command is always available to help you find the name of projects available.
The ``search projects'' command is PROJECT or can be abbreviated PROJ.
$ PROJECTYou can type PROJECT to show the whole list. Basically the command is doing a SEARCH, so if you just type PROJECT it will ``find'' the whole file, and will highlight the whole file.
You can find all projects associated with any phrase.
$ PROJECT phraseFor instance,
$ PROJECT programmers_nameUse your imagination.
$ PROJECT CAMAC
$ PROJECT BEAM
To work on a project, the WORK command creates a consistent setup, no matter who needs to work with this project. To work with a particular project, you type:
$ WORK project_name
This does several things for you.
The CMS directories live in a directory parallel to the WORK areas. See Figure .
The only thing a programmer needs to do with the CMS directories is done by CMS or MMS commands. Files are put into these directories with the CMS command. For more information, type CMS and then HELP, or see the manual sets which are available. Don't ever manually put files into or take them out of the directories under the CMS tree.
When a new project is created, an empty PROJECT_SETUP.COM file is created. The project programmers can edit this file to do what they need to have done. Usually it defines symbols and logicals required for the particular project.
Symbols and logicals which a particular programmer wants to have in place for all his/her login sessions should go in their own LOGIN.COM file rather than the PROJECT_SETUP.COM file. This way they need not be repeated in each project you get assigned, and they also don't affect a different programmer who may have occasion to work with a particular project.
Remember that someone else might occasionally have to WORK with this project (even if they are just looking at the code) and may not have the same tastes, so try not to put things in the PROJECT_SETUP.COM file which would mess up somebody else's terminal.
This section describes the commonly used command procedures and the DCL commands used to invoke them. Command procedures are located in directory PROJECT_COMMANDS. The necessary DCL command symbols required to invoke these procedures are in files:
PROJECT_COMMANDS:EPICURE_LOGIN.COM andThe first file contains the command symbols that are required for software development. The second contains optional but possibly useful command symbols. As a rule, all EPICURE,CRYO or OPS software developers should refer to EPICURE_LOGIN.COM in their login.com file. Referring to EPICURE_LOGIN_AUX.COM is optional. Review both of these files to get an idea of what they do.
Many of these command procedures work in conjunction with other command procedures, especially those which deal with changing your default directory.
Many procedures need to have information kept after they have terminated. This is done in one of three ways.
Process symbols and logical definitions are used when the information is not needed to be maintained across logins. The parameter subdirectory is used when information is required across logins.
Software development command procedures include the following:
This procedure has two parameters, both of which are optional:
This procedure changes your default directory to be a subdirectory of your current directory. It has one optional parameter, the name of the subdirectory. Brackets must not be included with this command. If the parameter is omitted, then the last subdirectory used in the previous DOWN command is used. If no previous DOWN command has been issued since login, then you are prompted for the subdirectory name. Examples:
$ DOWN DOG
$ DOWN DOG.CAT.HORSE
Returns you to your default login directory. It has no parameters.
Sets your default directory to your previous default directory. Your previous directory is described by the logical LD:. LAST requires no parameters. The equivalent DCL command would be ``SET DEFAULT LD:''.
Moves your default directory up one in the directory hierarchy. The equivalent DCL command would be ``SET DEFAULT [-]''. There is an optional parameter. When specified, the UP command becomes a SIDEWAYS command, by making your default another directory on the same level. In this case, ``UP DOG'' is the equivalent of ``SET DEFAULT [-.DOG]''.
This command invokes EDT. If the file name is omitted when this command is used, the previous file edited is used. The previous file is maintained across logins. SYS$LOGIN is searched for EDTINI.EDT and is included in the command line if present.
This command invokes TPU. If the file name is omitted when this command is used, the previous file edited is used. The previous file is maintained across logins. SYS$LOGIN is searched for TPUSECINI.GBL and is included in the command line if present.
This defines the current work environment, EPICURE, CRYO or OPS. The environment is taken as a parameter on the command line. The basic action taken by this procedure is to define the logical PROJECT_ROOT to correspond to the requested environment root directory, EPICURE_ROOT, CRYO_ROOT or OPS_ROOT.
This procedure is used to display the projects in the current environment database. It has one optional parameter. If it is specified, it is searched for in the database (via the VMS SEARCH utility). If it is omitted, then the entire database is displayed. The information displayed is only for the current environment ( EPICURE, CRYO or OPS). If you wish information on another environment, you must first use the ENVIRONMENT command.
$ PROJ BEETHOVEN ! Look for projects that user BEETHOVEN is
$ ! involved with, or that have his name in it
$ PROJ 1991 ! Look for projects created in 1991
$ PROJ ! Display all available project names
This procedure gives the specified privilege(s) to your process if you have them available (see the system manager), and sets the DCL prompt to remind you that you have a privilege turned on. This is especially useful when you give yourself powerful privileges such as SYSNAM and WORLD. You specify as a parameter which privileges you wish to turn on. If the parameter you use is NO priv then that privilege will be turned off. SP DEF will set your privileges back to the state they were in when you first called SP (this login session). Note that to turn on any privilege, your account must be able to have that privilege.
$ SP SYSNAM
SYSNAM> SP NOSYSNAM
This defines your EPICURE/CRYO/OPS work project. Your default and CMS directories are set to the appropriate subdirectories. Also, if a subdirectory of your username exists in the chosen project directory, your default is set there. Your new default directory is then searched for the command procedure PROJECT_SETUP.COM and is invoked if it exists.
If no project is specified on the command line, then the last project worked with is assumed by default. This procedure works in conjunction with the ENVIRONMENT command.
$ @PROJECT_COMMANDS:EPICURE_LOGIN !in login file
$ @PROJECT_COMMANDS:EPICURE_LOGIN_AUX !in login file if desired
$ ENV OPS
$ WORK TIME_READ
Working with OPS project TIME_READ
- - - your TIME_READ related activity - - -
$ WORK PRESERVE
Working with OPS project PRESERVE
- - - your PRESERVE related activity - - -
$ ENV EPICURE
$ WORK RONALD
Working with EPICURE project RONALD
- - - your RONALD related activity - - -
Keywords: WARNER, software, programming