Method and system for optionally registering a local process to allow participation in a single system semantic5544316Abstract A method and system for providing communications services between multiple processes running in multiple computer systems is provided. A single system semantic can be used to access processes, whether such processes reside on a local or remote computer. A mechanism is provided to allow processes to register as part of a distributed context. Registration may be accomplished explicitly by any child process to name its parent in the hierarchy, or automatically by the parent process when spawning children. This mechanism allows the additional flexibility that destination nodes in the distributed environment may be selected at run time without requiring knowledge on the part of the executing process. This allows the ability to cause processes to be distributed based on machine type, facilities available on a specific node or load balancing considerations. This registration mechanism is expandable to allow general purpose server implementations in a distributed environment, thus providing to the user system transparent facilities for control in a distributed environment. Claims We claim: Description TECHNICAL FIELD
TABLE 1
______________________________________
struct child.sub.-- data
/* Child data tracking
structure */
{
short handle;
char. status;
char plug;
int rc;
pid.sub.-- t
pid;
pid.sub.-- t
fpid;
};
______________________________________
The important information to the user of a driver process is the return code and the status field of a child data structure. This information allows the driver to understand what child processes are outstanding and the current status of those processes. Once a child has completed, the return code from that process will be available in the child.sub.-- data structure for that process.
TABLE 2
______________________________________
Field descriptions:
______________________________________
handle - Childs handle
status - Current child process status
S.sub.-- PEND -
Mark a client entry as pending
S.sub.-- VALID -
Mark a client entry as valid
(running)
S.sub.-- TERM -
Mark a client as terminated
(valid exit)
S.sub.-- SIGD -
Client received a child died
signal (invalid exit)
S.sub.-- DONE -
Child processing is complete
(valid exit)
rc - Return code from child process if valid
exit.
pid - Process id of the registered child
process, this is the process id used to
communicate with the child for normal
operations and to notify when the child
terminates
fpid - Process of the forked process id that
the child was invoked through. This
information is maintained in case
the process exits before registering
with the server, in the case of abnormal
termination of the child process,
the death of child will yield this
process id as the dieing process and
will be used to clean up the child
processes.
______________________________________
Functions reserve.sub.-- slot(handle) The reserve.sub.-- slot routine is used by a parent process to reserve a client slot for the child being started in the server. The reserve.sub.-- slot function is called using the parent's handle. The return from this function is a new handle to be used for the child. The reserve.sub.-- slot routine is called by the start process routine and will not normally be used by a user program. When called, the reserve.sub.-- slot routine also sets up a child.sub.-- data record in the parent that will be used to associate the driver child data with the server client information. start.sub.-- process(hostname,command,handle) The start process command should be used to start all child processes. As you can see, the start.sub.-- process command has three parameters: hostname--Indicated the hostname where you wish the child process to execute. command--Gives the command with parameters to execute to start the child process. handle--This is the parent process handle. As depicted by FIG. 29, once the start.sub.-- process command is issued at 350, the following sequence occurs: 1) The hostname is checked at 352 to determine if you wish the process to be started on the local host or on a remote host. If the process is to run on the local host: 2) reserve.sub.-- slot is called to get a child handle at 354. 3) A local process is started at 356, and a child record is created at 358. 4) The new handle is put into the shell environment using putenv at 360. 5) A new process is forked at 362 and the process id is captured. 6) The command passed to start.sub.-- process is execed at 363. 7) The parent's child.sub.-- data table is updated with the handle and the forked process id at 364, and put in a pending state at 366. Once the child 363 starts, it will register with the server (see above) and the child.sub.-- data table entry will be in the valid state. If the process is to run on a remote host, as determined at 352, the following sequence occurs: 2) The remote.sub.-- command function is called to send the request to start a remote process to the server at 370. 3) The local server will build at 372 a client record for the remote process and send the command packet to the server at 374 indicated by hostname. 4) The remote host will receive the command packet and process the remote execute function on the server at 376. 5) The remote host will create a slot in the clients table for the process at 378. 6) The new handle is put into the shell environment using putenv at 378. 7) The new process is forked at 380, and the process id is captured. 8) The command passed to in the command packet is execed at 381. 9) The forked process id is stored in the parent's pid slot in the client data table at 382, and the table entry changed to pending state at 384. For either the local or remote process, the command packet is returned to the originating host server (368 for local; 386 for remote) with a good return code. The client information is updated at 388 to indicate the remote handle and the client information on the originating host is marked as valid. At this time, the parent process has no knowledge of the state of the forked process. All state information is held in the servers until the process registers on the remote system. Next is described what happens when a remote process registers to complete the picture. Register of Pending Remote Process The process that was exec'ed on the remote machine will register. When that happens, the client record on the remote server will be updated to reflect the pid of the actual registering process and the status of the client record will become valid. The remote server will then forward a command packet to the originating host server that a child has started. The server on the originating host will enqueue a message that the child has started and signal the parent process. The signal will be caught by the signal handler and a child.sub.-- data record will be created for the parent with a valid status. At this time, in either the local or remote case, the start.sub.-- process command will return the handle of the child that was started. The handle will always be the handle relative to the local server view of that process. Referring now to FIG. 30 The above description provides interprocessor communication support for multiple processes in an multi-computer complex. Directory Structure This test environment includes the designation of an all encompassing, somewhat complex, directory structure. The structure contains all the user task code, the scenario tools (including the scaffolding tools), and a structure that accumulates data during the scenario execution stage. Top Level Directory Structure Reference in now made to FIG. 3, to describe the preferred embodiment of the directory structure. It is known to those of ordinary skill in the art that differing structures could similarly be used to achieve a similar overall-hierarchical structure as disclosed herein. By default, the parent level directory structure for the test scaffold is /austin 80. Five directory structures are located in the /austin directory. These structures are named /austin/.def 82, /austin/.inst 84, /austin/tools 86, /austin/tasks 88, and /austin/runtime 90. It is possible to change the default location and/or the name of any of these directories, as described below. How these five directory structures are used will now be described. The .def Directory The definition directory 82 contains scenario definition files. The default location for the definition directory is /austin/.def. The .inst Directory The instance directory 844 contains scenario instance files, which are the files that describe a scenario. The default location for the instance directory is /austin/.inst. The Tools Directory The tools directory 86 is the repository for all the standardized scaffold tools and any other tools that are needed by the executing scenario. The structure is denoted by the name /austin/tools. In the /austin/tools directory 86, as shown in FIG. 4, there are the following five directories: src 92 for source code, *bin 94 for executables and shell scripts, dat 98 for data files, doc 100 for documentation, and *lib 96 for libraries. The /austin/tools directory is installed at installation time, and rarely changes. Any tools needed by task code can be standardized and placed into this directory structure. The denotation *bin and *lib is used to represent multiple bin and lib directories. In place of the *, a set of characters is used to indicate what type of executables or libraries are iD the directory. For example, currently, the tools directory structure has two directories named rsbin and rslib where RISC System/6000.sup.2 2 executables and libraries are placed. If the testing scaffold is compiled on a SUN SparcStation, two other directories, sunbin, and munlib could be used for the SUN executables and libraries. .sup.2 An IBM RISC-based computer system The advantage of having multiple binary and library directories is that the executables and libraries can be served from a single host in a network, and the client that is mounting the information can set their local environment variables or PATH environment variable such that they access the appropriate directories based on the client's operating system and hardware platform. The Tasks Directory Structure The tasks directory structure 88, as depicted in FIG. 5, is a repository for all the scenario developer's user code (tasks). Twenty-six directories 102 can be found in the /austin/tasks directory in the preferred embodiment. These directories at 102 are named a-z and are used to separate tasks via the first letter of their respective names. A task must have its own separate directory 104 in the tasks directory structure under the character directory 102 that is the same as the first letter of the task's name. Here, the task m is shown to have separate directories 104 called mtask1, mtask2 and mtask3. The directory the task creates should be the same as its name. The files 106 that make up the task are separated into the following four directories in the task name directory: src 104 for source code, *bin 108 for executable modules and shell scripts, dat 110 for data files, and doc 112 for documentation. The entire tasks directory structure changes quite often during the task development stage. However, during the scenario execution stage, the task scenario driver provides an interface that allows writing in a completely different directory structure so it is not necessary to write in the tasks directory structure at all. This helps eliminate any corruption of the tasks structure that might occur during the scenario execution stage. To further ensure that no writing is occurring in the tasks directory during the scenario execution stage, the directory structure can be made read-only by changing its permissions; or, if the scenario is being executed in a distributed environment, the tasks directory structure can be mounted read-only from the environment server. Note that the scenario driver does not explicitly ensure that the structure is read-only during the scenario execution stage. EXAMPLE As shown in FIG. 6, a task named rcp 120 would be found in the directory /austin/tasks/r 122, and the tasks named float 122 and ftp 124 would be found in the directory /austin/tasks/f 126. Every task in the tasks structure 104 is a directory name under its appropriate character directory 102. For example, for a task named rcp, there is a directory named /austin/tasks/r/rcp 120 that contains all the information 106 pertaining to the rcp task. This directory is referred to as the AUSCODEDIR directory (see later discussion). The Runtime Directory Structure The runtime directory structure 90, as depicted in FIG. 7, is used extensively during the scenario execution stage. When the top level scenario driver begins execution, it creates a directory 130 in the /austin/runtime directory 90 consisting of the name of the scenario instance 132 followed by the date 134 and time 136. This directory 130 is referred to as the scenario directory, and its full tree is referred to as the scenario directory structure. The time stamped scenario directory guarantees that scenario data may be kept from n number of scenario executions (barring system resource constraints). There are three directories 138 in the scenario directory 130 named pass 140, working 142, and fail 144 and a file 146 named scen.journal.<hostname> (i.e. one journal file per machine in the scenario). The working directory 142 is where all the runtime task activity takes place. Following the completion of a task, the files associated with the task are moved from the working directory 142 to either the pass 140 or fail 144 directory depending on the save configuration attribute and their success rate, as described below. The file scen.journal.<hostname> 146 is where the scenario journal information is recorded. This directory structure 138 is created at scenario execution time by the top level scenario driver, as will be described later. The Runtime Task Directory Structure When a task scenario driver executes, it creates a unique directory 150 in the scenario directories working directory 142 if the task is running as the root user, as shown in FIG. 8A. If the task is running as a non-root user, as shown in FIG. 8B, the unique task directory structure 152 is created in the user's home directory 154 (denoted by the environment variable HOME). This directory 150 or 152 is referred to as the task directory and its respective directory tree 156 or 158 is referred to as the runtime task directory structure (not to be confused with the task directory structure described earlier). The unique task directory name is created by combining the name of the task instance 158, the host 160 that task is executing on, the task's process identification number (PID) 162, and the task's iteration 164. This task directory uniqueness allows the same task to be executing on the same host at the same time or to be using the same scenario directory file space at the same time. The iteration allows uniqueness once the unique task directory structure is moved to the pass or fail directories. If the scenario is executing in a distributed runtime file space, and one of the fields used in creating the name of the task directory structure was not used, it would be possible to have tasks "stepping on each other." This unique working directory file space is one of the powerful aspects of the testing scaffold. Beneath the unique task directory three more directories 156 or 158 can be found--the bin 166, work 168, and jour 170 directories. The bin directory 166 is created for use by the task setup code for outputting compiled executables, as later described. The work directory 168 is where the user will be placed when their code begins execution. Unless it is warranted, the user should not change directories out of the work directory. The jour directory 170 is where the standard task journal 172 (task.journal) is located (also 72 of FIG. 1) as well as all journals created by the task scenario driver using the ausjournals configuration attribute, as will be later described. This entire runtime task directory structure is created by the task scenario driver. When the execution of the task scenario is complete, the unique directory structure for that task is moved to the scenario directories' pass or fail directory depending on the task's success and the value of the scenario driver save attribute. It is then compressed depending on the value of the scenario driver compress attribute. Note that no matter what the attributes are, the task directory structure is always removed from the scenario's working directory (for root users) or the $HOME directory (for non-root users). The movement of the information to the pass or fail directory is also a function performed by the task scenario driver. Multiple Runtime Scenario Directory Structures In FIG. 9, two different scenarios 180 and 182 have executed or are executing. The scenarios originated from the same scenario definition file for the engineering environment scenario, but different scenario instance files. This is apparent because the first field of the directory name is the same, indicating the same scenario definition, but the third field is different, indicating different instances (engineering.e.1 versus engineering.e.2), as was previously described. It is also apparent from the directory name that the scenario engineering.e.1 began Mar. 11, 1991, at 11:05 AM (the 910311.110500 date/time stamp), and that the second scenario began on Mar. 12, 1991, at 11:05 AM (the 920312.110500 date/time stamp). Therefore, the scenarios began execution exactly twenty-four hours apart. When the two scenarios that are using these two directory structures 180 and 182 both finish, these structures will be left in the runtime file space 90. The scenario driver provides options for task scenario cleanup (described below), but does not automatically remove a scenario directory structure. The following section will look at the execution of some of the tasks found in the tasks directory structure that are executing in environment scenario 180 in FIG. 9 (engineering.e.1.910311.110500). Scenario Directory Working Directory Structure Referring now to FIG. 10A, it is apparent that three tasks 184, 186, 188 are executing in the engineering environment scenario 130. Executing tasks will always be located under the directory named working in the scenario directory if the task executes as the root user, otherwise they will have a directory in the user's $HOME directory, as previously described. It can also be observed that the engineering scenario of FIG. 10A is executing using a distributed runtime file space because unique task directory names contain different host names, as well as the runtime directory containing multiple scenario journal files. If the scenario was not distributed, the task directories would contain the same host name. In the example shown, two of the tasks 184, 186 are executing on the host claussen and one of the tasks 188 is executing on the host the lake. Sample Runtime pass/fail Directory Structures FIG. 10B depicts the post-execution location of the unique task directories described above. Several items can be deduced from FIG. 10B. First of all, two of the tasks that were previously executing passed (rcp.t.1.claussen.999.1 as shown at 184, rcp.t.2.claussen.888.1 as shown at 186), and one failed (fp.t.2.thelake.1122.1 as shown at 188). Secondly, the scenario driver attribute aussave had the value all or pass for the tasks rcp.t.1 (184) and rcp.t.2 (186) and it had the value all or fail for the task ftp.t.1 (188). The third thing that can be observed from FIG. 10B is that the scenario driver attribute auscompress option was set to pass or all for the task rcp.t.1 (184) and was set to either none or fail for the task rcp.t.2 (186) and none or pass for ftp.t.1 (188). For more information on the save and compress scenario driver attributes, see below. Directory Structure Environment Variables Referring back to FIG. 3, the parent directory structure /austin 80 and each of the five directory structure's beneath it can all be moved to different locations and/or renamed if the need exists. Six environment variables are provided and need to be set to the new location of the directory structures if they are moved and/or renamed. The environment variables follow: AUSROOT Value is the new location of the/austin directory 80. AUSDEF Value is the new location of the/austin/.def directory 82. AUSINST Value is the new location the/austin/.inst directory 84. AUSTOOLS Value is the new location of the /austin/tools directory 86. AUSTASKS Value is the new location of the /austin/tasks directory 88. AUSRUNTIME Value is the new location of the /austin/runtime directory 90. If the default locations are used, no environment variables need to be set. The procedure that the scenario driver and the scenario build tool use to determine the location of the five directory structures beneath the /austin directory follows: 1) Check to see if the environment variable for that structure is defined. If it is, that is the value of the directory structure. If it is not defined, continue to step 2. 2) Check to see if the environment variable AUSROOT is defined. If it is, append the proper default directory name to the end of the directory specified by the AUSROOT environment variable, and that is the value of the directory structure. If AUSROOT is not defined, continue to step 3. 3) The value of the directory structure being searched for is the default. The above means that if the scenario build tool is searching for an instance, it will first check to see if the AUSINST environment variable is defined. If AUSINST is defined, the scenario build tool will expect the instance file to be located in the $AUSINST directory. If AUSINST isn't defined, the scenario build tool will then check to see if the AUSROOT environment variable is defined. If it is, then the instance is searched for in the SAUSROOT/.inst directory. If the AUSROOT environment variable is not defined, the instance is searched for in the /austin/.inst directory. Scenario Definition and Instance Files Definition and Instance File Interactions FIG. 11 shows the interactions that scenario definition files 56 and scenario instance files 54 have with the other components in the test scaffold. Definition and instance files are created, modified, and deleted through the scenario build tool 52, and instance files are used as configuration input to the scenario driver 58. The creation of definitions is a necessary step during the scenario development stage. These definitions are then used as templates for the creation of scenario instances. The creation of scenario instance files is also a necessary step during the scenario development stage. Without a scenario instance file, a scenario driver will fail to execute, and without a scenario definition, it is impossible to create a scenario instance (unless the scenario build tool is circumvented). Once instances have been instantiated from definitions, they are used as configuration information for the scenario driver. When each scenario driver is executed, it is passed one instance that defines the actions of that scenario driver. Each definition and instance is a separate file in the /austin/.def directory (for definitions) or the /austin/.inst directory (for instances). The name of the file is the name of the definition or instance. Within the file, a stanza can be found that is similar in nature to a stanza in /etc/filesystems (Note: this is a standard stanza commonly known and used by a UNIX compatible operating system). The name of the stanza is the same as the file name, or the instance/definition name. The stanza then contains several attribute name/value pairs, one per line. The attributes that begin with aus are referred to as scenario driver attributes, or scenario driver configuration attributes. The aus prefix is reserved for scenario driver attributes. Any other attributes that are found in the definition or instance file are referred to as user defined attributes. The purpose of both user defined attributes and scenario driver attributes is explained fully below. Definition files differ slightly from instance files as mentioned in the first paragraph above. The values for the user defined attributes in a definition file are not actually the values that will be found in the instantiated instance file of the definition. Instead, each of the values of the user defined attributes in the definition file represent a syntax that describes the user defined attribute type, its restrictions, its default value, and a short description of what the user defined attribute is used for. All this information is used by the scenario build tool when that variable is given an actual value by the at instantiation time. The scenario build tool insures that the actual value of the user defined attribute, as entered by the task developer at instantiation time, meets the criteria set up when the definition of that user defined attribute was defined. File Name Syntax Definition files consist of an arbitrary given name (must begin with a character and followed by zero or more alphanumeric characters, the underbar, or periods) followed by a period and the extension e, m, p, or t. The extension is placed on the definition file depending on whether the definition defines an environment scenario (e), machine scenario (m), person scenario (p), or task scenario (t). Instance files consist of the definition file name described above followed by a period and an extension which is a unique integer value for the current definition. For example, if a definition named foo.e had been instantiated twice, the instances foo.e.1 and foo.e.2 would exist. If it was instantiated a third time, a new instance named foo.e.3 would be created.
TABLE 3
______________________________________
Scenario Definition and Instance File Grammar
______________________________________
<def.sub.-- or.sub.-- inst>:
<identifier>:<attributes>
<attributes>: <attributes>
.vertline.
<attribute> <attribute>
<attribute>: <instance.sub.-- user.sub.-- def>
/* instance files only */
.vertline.
<definition.sub.-- user.sub.-- def>
/* definition files only */
.vertline.
auscodedir = <qstring>
.vertline.
ausbeghook = <qstring>
.vertline.
auscompress =
<comp.sub.-- and.sub.-- save>
.vertline.
ausdesc = <qstring>
.vertline.
ausdistributed =
<true.sub.-- or.sub.-- false>
.vertline.
ausendhook = <qstring>
.vertline.
ausjournals = <qstring>
.vertline.
ausloops = <integer>
.vertline.
ausmode = concurrent .vertline.
sequential
.vertline.
ausobjlist = <qstring>
.vertline.
ausbjnumlist = <qstring>
.vertline.
aussave = <compress.sub.-- and.sub.-- save>
.vertline.
austaskcode = <qstring>
.vertline.
austaskparams = <qstring>
.vertline.
austime = <integer> .vertline. <real>
.vertline.
austype = environment .vertline.
machine .vertline. person .vertline. task
.vertline.
aususer = <qstring>
.vertline.
ausverbose = <integer>
.vertline.
auswindows = <true.sub.-- or.sub.-- false>
<instance.sub.-- user.sub.-- def>:
<identifier> = <qstring>
.vertline.
<identifier =
<definition.sub.-- user.sub.-- def>:
<identifier> = <req> <type>
<restricts> <default>
<desc>
<true.sub.-- or.sub.-- false>:
true .vertline. false
<comp.sub.-- and.sub.-- save>:
none .vertline. fail .vertline. pass .vertline. all
<req>: req .vertline. opt
<type>: uns .vertline. int .vertline. flt .vertline. chr
.vertline. str
<restricts>: /* nothing */
.vertline.
<restrict> <restricts>
<restrict>: <item>:<item>
.vertline.
<item>
<item>: <unsigned>
.vertline.
<integer>
.vertline.
<real>
.vertline.
<character>
.vertline.
<qstring>
<default>: /* nothing */
.vertline.
<qstring>
<desc>: @[ .backslash.n]*.backslash.n
<identifier>: [A - Za - z][A - Za -
z0 - 9.sub.-- .]*
<real>: [-+]?[0-9]*"."[0-9]+
<integer>: [-+]?[0-9]+
<qstring>: "[ ".backslash.n]*[".backslash.n]
<character>: [ .backslash.n]
______________________________________
EXAMPLE The following is an example of a task definition file, using a typical stanza syntax.
TABLE 4
______________________________________
sample.t:
______________________________________
austype = task
ausdesc = "Tests NFS mounts from clients to
a server."
austaskcode =
"nfstest"
SERVER = req str @ NFS server, exports
directories
CLIENTS = req str @ List of NFS clients,
mounts directories
FILESIZE = opt int { 512 1024 2048 4096 } 512 @
Files size in Bytes
______________________________________
As can be seen from the sample definition file, the task has three reserved attributes defined and three user defined attributes (SERVER, CLIENTS, and FILESIZE). The user defined attribute SERVER is required, is of type string, has no restrictions, and has no default value. The user defined attribute CLIENTS is also required, is of type string, has no restrictions, and also has no default value. The third user defined attribute, FILESIZE, is optional, is of type integer, is restricted to either 512, 1024, 2048, or 4096, and has a default value of 512. The descriptions for the three attributes provide some information also. The name of this definition file is sample.t. By default, it would be located in the /austin/.def, and could be manipulated by the scenario build tool. Normally, creation and manipulation of the definition would be done completely through the scenario build tool. The following is an instantiation of the task definition file from above:
TABLE 5
______________________________________
sample.t.1:
______________________________________
austype = task
ausdec = "Tests NFS mounts from clients to
a server."
austaskcode = "nfstest"
auscompress = none
ausjournals = "klog elog SPOOL:spooljour"
ausloops = 1
austaskparams =
"-e 1 -f 16"
aussave = all
ausverbose = 7
SERVER = "arsenio"
CLIENTS = "carson leno oprah"
FILESIZE = "512"
______________________________________
The exact meaning of all the reserved attributes and the way the driver uses this instance file is described in detail below. As shown by this example, during the instantiation stage the scenario developer specified the host "arsenio" as the SERVER, the hosts "carson", "leno", and "oprah" as the CLIENTS, and a FILESIZE of 512. The scenario developer did not have to change the FILESIZE variable. By default, it would have been created with the value 512. Scenario Build Tool The scenario build tool presents a natural language, task-oriented interface to managing the scenario definition files and scenario instance files. The scenario build tool uses a hierarchical structure. This hierarchical structure consists of menu panels and dialog panels. Menus successively refine the task to be performed. Dialog panels allow data to be entered for definition and instance attributes. The basic functions that can be performed on both instances and definitions are adding, changing, removing, and listing. The scenario build tool is invoked in the traditional manner of entering a command name (e.g. aussbt) at the data processing system prompt. Upon invocation, as depicted in FIG. 12, the top line 200 of the scenario build tool displays the current menu panel or dialog panel title. At the bottom 202 of the menu or dialog panel the allowable function keys for the current menu or dialog are displayed. A list of task-oriented items is displayed in the menu panels at 204. FIG. 13 shows the resulting menu panel, after the task item was selected in FIG. 12. In the dialog panels, such as the one shown in FIG. 14, attribute names are displayed on the left and entry fields are displayed to the right. The dialog panel allows values for attributes to be supplied. Symbols are used to indicate various types of fields. The symbols may be displayed in various places in the dialog panel.
TABLE 6
______________________________________
Symbol Meaning
______________________________________
[ ] Indicates beginning and end of a typeable
field.
< Indicates there is more text to the left of
the visible field.
> Indicates there is more test to the right of
the visible field.
* Indicates that a value is required.
+ Indicates a list of choices or option ring
is available. Press F4 to display list or
tab to toggle through the option ring.
@ Indicates the attribute is read-only.
# Indicates a real or integer value is
required.
______________________________________
EXAMPLE FIG. 12 is an example of what the first menu panel of the scenario build tool looks like. The function keys 202 along the bottom of the screen vary from panel to panel. However, the five function key definitions on this main menu remain consistent throughout the panels in the preferred embodiment. Context sensitive help on a per panel basis is always available with the F1 213 key. The F2 215 key is used to refresh the screen. The F3 217 and ESC (not shown) keys always move back a panel. The F9 key 219 temporarily exits to the shell (return by typing `exit`), and the F10 key 221 will quit the scenario build tool at any panel. FIG. 13 is another menu panel. This particular menu panel is accessed by selecting Task from the first menu and Manage Instances from the second menu. It can be observed from this menu panel that each of the menu items has a character with an underbar. If this character is selected on the keyboard, that item will automatically be selected. FIG. 14 is a sample dialog panel. This particular dialog panel is what would be displayed by the scenario build tool for the task instance file previously described. To a new instance of the task definition called sample.t, the scenario developer would type aussbt to enter the build tool and then select Task, Manage Instances, Add an Instance, and select the sample.t definition. The sample.t.1 instance, and the dialog panel of FIG. 14 would then be displayed. The attributes austype 206 austaskcode 208 are all read-only during the task instance management stage. This is denoted with the `@` character 212 in the far left column. They are read-only because they are the attributes that define the scenario, and changing them would mean creating a different scenario definition, and to do that, the Task/Definition/Create option would be chosen instead. This panel only allows the instantiation of a predefined scenario (i.e. a scenario that already has an existing scenario definition file). Attributes auscompress 214, aussave 216 and ausverbose 224 have toggle rings represented by the `+` character 218 in the far right hand column. This means you can use the tab key to select a different value or use the F4 key to get a list of the possible values. Scenario driver attributes ausloops 220, austime 222, and ausverbose 224 all require numeric values. This is indicated by the `#` character 226 in the far right hand column. There is one user defined attribute, FILENAME 228, and it is required in the preferred embodiment. This is indicated by the `*` 230 in the far left-hand column. Note that FILENAME 228 also has a toggle ring (`+`) 218 in the far right-hand column, indicating that a user can use the tab key to select a different value or use the F4 key to get a list of the possible values. Once the information for this instantiation is complete, the Enter key is pressed and the instance file is actually created and can then be used to control a task scenario driver. Scenario Driver Referring now to FIG. 15, the scenario driver 58 is the primary component of the testing scaffold. The scenario driver can control the execution of four different scenario levels as was described above in the architectural overview. The scenario driver is a single executable whose actions are determined by a scenario instance file 54. The instance file gives the scenario driver a sense of identity. For example, one instance will cause the scenario driver to control the execution of a fifty host networked environment scenario that executes tasks that test an entire operating system while another instance will cause the scenario driver to control the execution of a single ten line shell script that functionally verifies a specific piece of an operating system. The advantage of the scenario driver is multi-fold. First of all, it sets up a scaffolding system that allows the automation of an entire environment scenario across multiple hosts. This scaffolding system simulates people performing daily tasks in an organization consisting of multiple hosts. Secondly, the scenario driver handles problems that occur in system test like environments where the same tasks are being executed at the same time as the same user on the same host or in the same network. The scenario driver does its best to set up an environment in which these tasks do not interfere with each other. The third advantage of the scenario driver is that much of the code that would previously have been found in tasks is now migrated to the scenario driver. For instance, instead of each task needing code for iteration purposes, this code has been moved into the scenario driver and its interface has been standardized. The creation of working directories, and the cleaning up of the runtime area, is no longer a problem that the user task code must address. It is controlled completely and consistently at the scenario driver level, and is variable depending on the needs of the scenario. The scenario driver also provides a set of standardized journals 62. Since the journals have a standard format, they can then be run through standard report filters to examine the execution results. The scenario driver can be executed beginning at any level from the environment level through the task level depending on the control that is needed in the current testing environment. In the preferred embodiment, the scenario driver has a dependency that its location be provided in the PATH environment variable. By default, the scenario driver is located in the austin/tools/rsbin directory. This directory can be added to the PATH environment variable using the following command: PATH=/austin/tools/rsbin:$PATH ;export PATH The scenario driver provides two usage statements. The first usage statement occurs when an error is detected on the command line. The information from the usage is printed to standard error (stderr). The second usage statement is the help usage statement that occurs when the `h` flag is passed to the scenario driver. The information from the help usage is printed to standard output (stdout). If the `h` flag is specified with a valid task scenario instance name, the help for that instance is displayed to standard output (stdout), as will be later described. The error usage statement follows:
TABLE 7
______________________________________
Usage: ausdriver [-c <n.vertline.f.vertline.p.vertline.a>] [-d
<t.vertline.f>
[-e ExcString] [-l Loops]
[-m <s.vertline.c] [-r RunString] [-s <n.vertline.f.vertline.p.vertline.a>
] [-t Hours]
[-u User] [-v Level] [-w <t.vertline.f>] <instance>
______________________________________
For driver help, a user would enter: ausdriver -h For task help, a user would enter: ausdriver -h <task.sub.-- instance> The information provided when the `h` flag is passed to the scenario driver with no <task.sub.-- instance>follows:
TABLE 8
______________________________________
Project AUSTIN V1.00
______________________________________
Usage: ausdriver [command.sub.-- options] <instance>
The ausdriver command.sub.-- options are:
-c <n.vertline.f.vertline.p.vertline.a>
Compress option (n--none, f--fail,
p--pass, a--all).
-d <t.vertline.f>
Distributed environment (t--true,
f--false).
-e ExcString Excludes instances mapped
to the integers in ExcString.
-h Gives help on task if the instance is
on the command line, otherwise,
prints out message describing all
possible options.
-l Loops Loops to execute for.
-m <s.vertline.c>
Mode of execution (s--sequential,
c--concurrent).
-r RunString Executes instances mapped to the
integers in RunString.
-s <n.vertline.f.vertline.p.vertline.a>
Save option (n--none, f--fail,
p--pass, a--all).
-t Hours Hours to execute for.
-u User User to execute the person scenario
as.
-v Level Sets the verbosity to the value of
Level (0-7).
-w <t.vertline.f>
Window option (t--true, f--false).
For driver help, enter:
ausdriver -h
For tast help, enter:
ausdriver -h <task.sub.-- instance>
______________________________________
The following defines the set of configurable scenario driver options. The configuration options communicate to the scenario driver 58 what test scenario level it is controlling, what it is to execute, and how it is to perform the execution. All configuration options can be communicated to the scenario driver by specifying them in the scenario instance file 54 that is associated with each scenario driver. Some of these configuration options can also be specified by command line flags when the scenario driver is called directly from the command line. In most situations however, unless the task driver is being executed stand-alone or the scenario driver that is being executed is the top level scenario driver in the scenario, the scenario drivers are called by higher level scenario drivers and thus they receive most of their configuration information from their associated instance. However, if command line flags that have been passed to the higher level scenario driver are pertinent, that scenario driver will automatically pass them to the scenario drivers it executes. Command line flag configuration attributes will override any instance file configuration attributes if there is a conflict. If the same flag is specified multiple times on the command line, or if the same attribute is specified multiple times in the instance, a warning message is issued and the last flag or attribute is used. Each attribute below is described first by the English phrase associated with the attribute. On the same line as the configuration attribute name in parenthesis can be found the corresponding scenario instance file attribute name and the command line flag if it exists. Following the configuration attribute name is a table that shows at which scenario driver levels the attribute is pertinent, which scenario driver levels it is required, and its default value at each level. The syntax for the instance attribute is then given and the syntax of the command line flag is given if there is one associated with the attribute. Next, a description of the attribute is given, and in most cases, there are examples showing how to use the attribute. The following is the syntax used throughout this section:
TABLE 9
______________________________________
<op1> Indicates that op1 is required and <op1> is
replaced by user's data.
[op1] Indicates that op1 is optional and [op1] is
replaced by user's data.
op1 .linevert split. op2
Indicates logical or-ing of op1 and
op2.
op1 . . . Indicates zero or more of op1.
N/V Indicates that the attribute has no default
value.
italics Italicized words are replaced by user's
value.
bold Bold faced text indicates that the text
should be taken literally
______________________________________
Instance Attribute Syntax ausbeghook="<begin.sub.-- hook>" Command Line Syntax None Description The begin hook provides a way in which user code can automatically be executed by the scenario driver prior to the scenario driver executing the next level of scenario drivers or the user task code. The begin hook would typically be used do some type of automated setup specific to the test scenario that is being executed. This allows customization of test scenarios. To perform the execution of the begin hook, the scenario driver passes the information in the double quoted string denoted by <begin.sub.-- hook> in the syntax diagram above to the system for evaluation. If a return code other than zero is received from the begin hook, the scenario driver terminates execution and passes control back to its parent scenario driver (or the AIX shell if it was the top level scenario driver). EXAMPLE 1 ausbeghook="/austin/tool s/rsbin/setup" In this example, the begin hook /austin/tools/rsbin/setup would be executed. If the program returns a return code other than zero, the scenario driver halts execution as described above. If /austin/tools/rsbin was already in the system path (via the PATH environment variable), the begin hook could have been specified as follows: ausbeghook="setup" EXAMPLE 2 ausbeghook="check. tcpip; check nfs" This example is a little more complicated. The string is sent to the system, and instead of one program getting executed, two programs will get executed sequentially. The two programs are actually the same program (check), but it is getting passed different parameters each time. The return code from the second of these programs will be returned from the begin hook execution. If, it is important that the scenario driver halts if either of these two programs fail, the developer could create a shell script that calls each of these programs, checking their return codes, and would then exit with that return code. The name of that shell script would then be placed in the ausbeghook.
TABLE 11
______________________________________
User's Base Code Directory (auscodedir)
Environment Machine Person Task
______________________________________
Required
N/V N/V N/V NO
Default N/V N/V N/V See
Description
______________________________________
Instance File Syntax auscodedir="<directory>" Command Line Syntax None Description The user's base code directory provides a way for the task developer to indicate the location of the task code if it does not reside in the default location. The string contains the value of the base level directory where the developer's task directory structure resides for the current task. The default value for this scenario driver attribute is computed by the task scenario driver at runtime using the location of the scenario's task directory structure (see section 4.5) and the name of the current instance. The directory is set to: <scenario's.sub.-- task.sub.-- directory.sub.-- structure>/<first.sub.-- letter.sub.-- of.sub.-- the.sub.-- instance>/<instance.sub.-- base> where the <instance.sub.-- base> is the instance name without the `.t.<int>`extension (see section 5.1). EXAMPLE 1 For example, if the task scenario driver is executed with the instance sampletask.t.1, and the default AUSTIN directory structure has not been modified by environment variables, the default task code directory structure for the sampletask.t.1 instance would be /austin/tasks/s/sampletask. Beneath that directory structure should reside the bin, dat, doc, and src directories that form each task code directory structure. EXAMPLE 2 If the task developer wished to have the tasks located in a different location because the tasks were in the task development stage, this could be accomplished by changing the auscodedir attribute. For example, if the developer was storing all the tasks in a directory named tasks in the home directory, the base code directory for the task named sampletask might be /u/username/tasks/sampletask. Beneath that directory the directories bin, dat, doc, and src would reside. To inform the scenario driver that this change has taken place, the attribute auscodedir would look as follows in the scenario instance file:
TABLE 12
______________________________________
auscodedir = "/u/username/tasks/sampletask"
Compression (auscompress, -c)
Environment
Machine Person Task
______________________________________
Required NO NO NO NO
Default none none none none
______________________________________
Instance File Syntax auscompress=<none.linevert split.pass.linevert split.fail.linevert split.all> Command Line Syntax -c<n.linevert split.p.linevert split.f.linevert split.a> Description The scenario driver compression configuration attribute determines whether or not saved task information is compressed following the execution of a task. If the value of the scenario driver save option (see section 7.2.12) is such that the task information is saved after the user task code is done executing, the compression option determines whether it will be compressed. The compression determination is based on whether the user's task passed or failed and the value of the compression attribute. Compression can be set with the auscompress instance attribute or the `c` command line flag to never perform compression (none or n), perform compress on passed tasks only (pass or p), perform compression on failed tasks only (failed or f), or always perform compression (all or a). The compression algorithm uses the AIX tar command to make the entire unique task working directory structure into a single unique file and then uses the AIX compress command to compress that file. This is a valuable option for an environment where information needs to be saved but the amount of information created during the scenario execution stage can be immense after running for extended periods of time. Two utilities exist that allow the compressed information to be uncompressed and recompressed (see section 12.1, 12.2). EXAMPLE 1 A scenario where thousands of tasks are going to be executing for multiple days might want to set the compression attribute such that all the task runtime information for the entire environment gets compressed. To do this, the auscompress attribute would be set to all in each of the machine instance files. Information in machine instance files automatically filters down to each of the task scenarios that are in the machine scenario. The following line would have this effect in the machine scenario instance files: auscompress=all EXAMPLE 2 In another situation, an environment scenario might be executing that has hosts that have varying hard disk resources. In this situation, the compress option might be set so that a host that has a massive amount of disk space compresses nothing (none or n), but a machine that has a small amount of disk space compresses everything (all or a). To accomplish this, the following attribute would be placed in the instance file of the host that has few disk resources: auscompress=all and the following attribute would be placed in the instance file of the machine that has a lot of disk resources: auscompress=none EXAMPLE 3 In this example, the machine scenario that is running very rarely looks at passed task information, so that information could be compressed by placing the following attribute in the machine scenario instance file: auscompress=pass EXAMPLE 4 It is important to note that the same task that is executing in an environment may have different compression options because it is associated with different instance files. For instance, the task rcp that executes on two different machines could have completely separate compression attributes because the first of the two task instances is associated with an instance that sets the compression attribute to pass, thus it only compresses the task files when the task passes. This would be done with the following scenario instance attribute: auscompress=pass The second instance of the task is associated with an instance file that sets the compression algorithm to all, thus all task files are compressed without respect to their success. This would be done with the following scenario instance attribute:
TABLE 13
______________________________________
auscompress = all
Description (ausdesc)
Environment
Machine Person Task
______________________________________
Required NO NO NO NO
Default -- -- -- --
______________________________________
Instance File Syntax ausdesc="<description>" Command line Syntax None Description The ausdesc attribute allows the information entered into the scenario build tool at scenario instance file creation time that describes each defined scenario to be kept in the instance file. This data is for informational purposes only. It is the "text" that describes the differences between instances. EXAMPLE The following is a sample description text for a scenario instance file: ausdesc="This instance sets the compress attribute to pass and save to all. " The following is another sample description text from a different scenario instance file that originated from the same scenario definition file: ausdesc="This instance sets the compress attribute to all and save to all." Distributed Runtime File Space (ausdistributed, -d)
TABLE 14
______________________________________
Environment
Machine Person Task
______________________________________
Required NO N/V N/V N/V
Default false N/V N/V N/V
______________________________________
Instance File Syntax ausdistributed=<true.linevert split.false> Command Line Syntax -d<t.linevert split.f> Description The distributed runtime file space attribute communicates to the environment scenario driver whether the intention is for the environment scenario to be executing with a distributed /austin/runtime file space or whether the /austin/runtime file space resides at each machine in the network. Note that no mounts are actually done by the scenario driver whether the distributed attribute is true or false. The value only communicates to the scenario driver what the user's intention is with respect to distributing the file space during the scenario execution stage. The actual distribution of the /austin/runtime file space is a good application of the begin hook. EXAMPLE 1 The following is an excerpt from an environment scenario instance file that is not distributing the /austin/runtime file space during the scenario execution stage: ausdistributed=false EXAMPLE 2 The following is an excerpt from an environment scenario instance file that is distributing the /austin/runtime file space during the scenario execution stage: ausdistributed=true
TABLE 15
______________________________________
End Hook (ausendhook)
Environment
Machine Person Task
______________________________________
Required NO NO NO NO
Default -- -- -- --
______________________________________
Instance File Syntax ausendhook="<end.sub.-- hook>" Command Line Syntax None Description The end hook provides a way in which user code can automatically be executed by the scenario driver after executing the next level of scenario drivers or the user task code. Other than the time that the hooks get executed, the same information applies to both the begin and end hooks (see section 7.2.1).
TABLE 16
______________________________________
User Defined Journals (ausjournals)
Environment
Machine Person Task
______________________________________
Required NO NO NO NO
Default -- -- -- --
______________________________________
Instance File Syntax ausjournals="[<env.sub.-- var:journal.sub.-- name.vertline.journal.sub.-- name>. . . [" Command Line Syntax None Description The ausjournals attribute is used to define any journals that the user's task code may want to use other than the default standard journal file that the journal commands write to. Prior to executing the user's task code, the task scenario driver will set environment variables, based on the value of the ausjournals reserved attribute. These environment variables contain the path of the user defined journal. This path is in the jour directory of the unique task runtime directory structure. This directory contains the standard task journal (named task.journal) and each of the user defined journals defined with the ausjournals command. The actual location of these files is not pertinent to the user's task code since the user refers to the journals using environment variables. The syntax for the ausjournals command is somewhat complex at first glance, but the following description and the examples should help to convey its meaning. The value of the ausjournals command is a double quoted string that contains a list of one or more items. These items can have either the format env.sub.-- var:journal.sub.- name or simply journal.sub.-- name. The scenario driver parses through this list of items and if the first form is found, it sets an environment variable named env.sub.-- var equal to the path of the current jour directory followed by the file name journal.sub.-- name. If the second form of the item is found, the scenario driver sets an environment variable which is the uppercase version of the journal.sub.-- name equal to the path of the current jour directory followed by the file named journal.sub.-- name. In this case, the env.sub.-- var is capitalized to follow "normal" UNIX environment variable naming conventions. EXAMPLE 1 In this example, the task developer requires the use of three journals for his/her task other than the default journal file. The value he/she might supply for ausjournals follows: ausjournals="Spooljour:spooljour cmdjour DiffResults:diff.sub.-- jour" This value contains both of the forms discussed above. The scenario driver would read this instance attribute and then set the following three environment variables to the values shown: Spooljour="/austin/runtime/<scenariodir>/working/<task-dir>/jour/spooljour" CMDJOUR="/austin/runtime/<scenariodir>/working/<taskdir>/jour/cmdjour" DiffResults="/austin/runtime/<scenariodir>/working/<taskdir>>/jour/diffjour " EXAMPLE 2 In this example, the scenario developer needs two journals named elog and klog. The following would be specified in the task scenario instance file: ausjournals="elog klog" This would result in the following environment variables with the following values: ELOG="/austin/runtime/<scenariodir>/working/<taskdir>jour/elog" KLOG="/austin/runtime/<scenariodir>/working<taskdir>/jour/klog" The user could then write to these files. The following is an excerpt from a shell script that uses the above files: ls -alt foofile>$ELOG diff $ELOG $AUSCODEDAT/expected.results>>$KLOG if ["$?"!=="0"]; then auserror "The ls -alt foofile command failed." else auslog "The ls -alt foofile command was successful." fi
TABLE 17
______________________________________
Loops to execute (ausloops, -l)
Environment
Machine Person Task
______________________________________
Required NO NO NO NO
Default 1 1 1 1
______________________________________
Instance File Syntax ausloops=<integer> Command Line Syntax -1 <integer> Description The loops to execute attribute communicates to the scenario driver how many times to execute the instances in the scenario attribute ausobjlist (see section 7.2.10) or how many times to execute the user's task code in the scenario attribute austaskcode (see section 7.2.13). Note that there is also a time to execute attribute. If both are specified within the same instance file or on the command line, the time to execute attribute takes precedence. If either is specified on the command line, they will take precedence over either in the scenario instance file. The integer value for ausloops must be positive. EXAMPLE If the loops to execute attribute has the following value in a task scenario instance file that was executed by a person scenario driver: ausloops=20 the user task code will be executed 20 times before returning control to the person driver. The sequence of operation would find the person driver executing its begin hook, and then executing the task driver. The task driver would execute its begin hook, and then execute its user task code twenty times, execute its end hook, and then return control to the person scenario driver. If the person scenario driver had a loops value of more than one, the task scenario driver would then be executed again and it would go through the same process a second time, executing its begin hook, its user task code twenty times, its end hook, and then return execution control back to the person scenario driver.
TABLE 18
______________________________________
Execution mode (ausmode, -m)
Environment Machine Person Task
______________________________________
Required
NO NO NO N/V
Default sequential sequential sequential
N/V
______________________________________
Instance File Syntax ausmode=<concurrent.linevert split.sequential> Command Line Syntax -m<c.linevert split.s> Description The execution mode attribute allows lower level scenario drivers to be executed sequentially or concurrently. If concurrent is specified, the scenario driver will begin the execution of all the instances in its ausobjlist (see section 7.2.10) at the same time and wait for them all to finish. If sequential is specified, the scenario driver executes the instances in ausobjlist sequentially. Once all objects in the just have executed and finished, whether it was concurrent or sequential, that makes up one loop of the scenario driver. EXAMPLE 1 If a person scenario consists of five task scenarios, and had the following value in the person scenario instance file: ausmode=concurrent it would begin the execution the five task scenarios concurrently. If the person scenario file was set to loop twice with the following attribute: ausloops=2 it would wait for each of the five tasks to complete their execution and then it would begin the same process a second time. By the end of the second iteration, the five tasks would have each been executed two times. It is important to note that when concurrent execution is used, a second iteration of all the lower level drivers is not begun until each of the previous executions of those drivers has completed. Thus, if four of the five task scenarios in this example took only 10 minutes to complete and the fifth took 30 minutes, two iterations of the person scenario would take a full hour. After beginning execution, the first four would finish after ten minutes and the fifth would continue executing for another 20 minutes before the five tasks would be executed for the second time. EXAMPLE 2 Using the example above of a person scenario with five tasks, four of which take ten minutes to execute and one of which takes thirty, this example shows the length of time it would take the same person scenario to execute two loops in sequential mode. To cause the driver to execute in sequential mode, the following attribute would be used in the person scenario instance file: ausmode=sequential The five tasks would be executed back to back, thus each iteration of the person scenario would take approximately seventy minutes. Thus, the two iterations of the person scenario would take approximately one-hundred forty minutes, or more than double the amount of time the concurrent execution took.
TABLE 19
______________________________________
Object list (ausobjlist)
Environment
Machine Person Task
______________________________________
Required YES YES YES N/V
Default N/V N/V N/V N/V
______________________________________
Instance File Syntax ausobjlist="<instance>. . . " Command Line Syntax None Description The object list attribute is very important to the scenario drivers that execute other scenario drivers (environment, machine, and person). The object list instance attribute named ausobjlist contains a list of one or more items. These items are the names of the instances that describe scenarios that the current scenario driver will control. When the scenario driver is ready to begin execution of other scenario drivers that run lower level scenarios, it goes through the ausobjlist and executes a scenario driver passing it the name of the current instance. The object list is what defines a scenario at the top three test scenario levels because it contains the core of what the test scenario will be executing. EXAMPLE In this example, a machine scenario is executing and its object list is the following: ausobjlist="person1.p.1 person1.p.2 person2.p.1 " After running through the scenario driver steps, the machine scenario driver will get to the point where it is ready to execute the lower level scenario drivers. To do this, it will examine the list above and begin three scenario drivers, either concurrently or sequentially that will be passed the instances person1.p.1, person1.p.2, and person2.p.1 respectively. This will cause three person scenario drivers to be executing and those scenario drivers will be controlled by the current machine scenario driver. Note that person1.p.1 and person1.p.2 are two instances of the same person.
TABLE 20
______________________________________
Object Number List (ausobjnumlist, -e, -r)
Environment Machine Person Task
______________________________________
Required
NO NO NO N/V
Default See See See N/V
Description
Description Description
______________________________________
Instance File Syntax ausobjnumlist="<integer>. . . " Command Line Syntax -r<integer>.linevert split.-r "<integer><integer>. . . " -e<integer>.linevert split.-e "<integer><integer>. . . " Description The object number list allows members of the ausobjlist attribute to be executed or excluded from the current scenario execution. This is done by specifying a list of integers that map to the items in the ausobjlist. By default, the object number list attribute is set to the list of integers corresponding to all the instances in the ausobjlist attribute, thus during execution, they will all get executed. The object number list configuration attribute is provided to allow a configurable object list during the instance creation/modification stage yet keep the template of instances in the ausobjlist unchanged since that list is what "defines" the current scenario and should not be modifiable during the instance management part of the scenario build tool. EXAMPLE 1 If a person instance contained the following ausobjlist and ausobjnumlist: ausobjlist="task1.t.1 task2.t.1 task3.t.1 task4.t.1 task5.t.1 task6.t.1" ausobjnumlist="1 2 3 6" when the person scenario driver executes, it will only begin four task scenario drivers although there are six task instances in the ausobjlist for that person because the ausobjnumlist has only four integers in it. The four tasks that will be executed will be task1.t.1, task2.t.1, task3.t.1, and task6.t.1, thus members four and five of the ausobjlist would be excluded. EXAMPLE 2 If the person scenario driver described above was executed with -r "1 2 3 4 5 6" on the command line, then the command line flag would override the ausobjnumlist instance attribute and all six task scenario drivers would be executed. EXAMPLE 3 Now, if the person scenario driver was described above was executed with -e "1 6" on the command line, the command line flag would again override the ausobjnumlist instance attribute and the first and sixth member of the ausobjlist would be excluded from execution and thus the rest of the tasks in the list would be executed.
TABLE 21
______________________________________
Save (aussave, -s)
Environment
Machine Person Task
______________________________________
Required NO NO NO NO
Default all all all all
______________________________________
Instance File Syntax aussave=<none.linevert split.pass.linevert split.fail.linevert split.all> Command Line Syntax -s<n.linevert split.p.linevert split.f.linevert split.a> Description The save option is used to communicate to the task level scenario driver whether or not to save the unique runtime directory structure that was created for the task execution. The decision on whether to save the task runtime information is based on whether the user's task passed or failed and the value of the save attribute. The save attribute can be set with the aussave instance attribute or the `s` command line flag to never perform the save (none or n), perform the save on passed tasks only (pass or p), perform the save on failed tasks only (fail or f), or always perform the save (all or a). The save function works hand in hand with the compression function to determine what information is saved at task runtime and what information gets compressed that is saved. EXAMPLE A machine scenario may want to keep only the task information in the machine scenario from tasks that fail. In this situation, the machine instance attribute aussave would be set as follows: aussave=fail Note that although this attribute isn't really doing anything at the machine scenario driver level, it is passed on down to the task scenario driver level where it is then used to determine whether or not to remove or save the task runtime directory structure.
TABLE 22
______________________________________
Task Code (austaskcode)
Environment
Machine Person Task
______________________________________
Required N/V N/V N/V YES
Default N/V N/V N/V N/V
______________________________________
Instance File Syntax austaskcode="<task.sub.-- file.sub.-- name>" Command Line Syntax None Description The task code parameter is vital to the execution of the task scenario driver. It is similar to the object list parameter that was specified for the other three scenario driver levels in that it contains the information detailing what is to be executed. The difference between the object list configuration attribute and the task code parameter is that the task code parameter contains the actual file name of the user's code that it is to execute. The actual path to the task file name should not be specified because the location of this file is determined in the following way: The runtime task bin directory structure denoted by $AUSBIN is checked first followed by the bin directory of the task code directory structure denoted by $AUSCODEBIN. EXAMPLE If the rcp task was executed by running the shell script foobar whose location was /austin/tasks/r/rcp/bin/foobar, the following would be specified for the austaskcode attribute in the task scenario instance file: austaskcode="foobar" < | ||||||