modify

Modifies or adds scheduling objects. When modifying objects, the modify command extracts only the objects that can be locked by the current user.

Authorization

You must have add access if you add a new scheduling object. If the object already exists in the database, you must have modify access to the object.

Syntax

{modify | m}
{[calendars | calendar | cal=calname] |
[eventrule | erule | er=eventrulename] |
[parms | parm | vb=[tablename.]variablename] |
[vartable | vt=tablename] |
[prompts | prom=promptname] |
[resources | resource | res=[workstationame#]resourcename] |
[cpu={workstationame | workstationclassname | domainame}]
[workstation | ws=workstationame] |
[workstationclass | wscl=workstationclassname] |
[domain | dom=domainame] |
[jobs | jobdefinition | jd=[workstationame#]jobname] |
[sched|jobstream|js= [workstationame#]jstreamname
   [valid from date|valid to date |valid in date date]
   [;full]] |
[users | user=[workstationame#]username]}

Arguments

calendars | calendar | cal

If no argument follows, modifies all calendar definitions.

If argument calname follows, modifies the calname calendar. Wildcard characters are permitted.

eventrule | erule | er

If no argument follows, modifies all event rule definitions.

If argument eventrulename follows, modifies the eventrulename event rule. Wildcard characters are permitted.

parms|parm|vb

If no argument follows, modifies all global variable definitions found in the default variable table.

If argument tablename.variablename follows, modifies the specified variable of the tablename table. If tablename is omitted, composer looks for the variablename variable definition in the default variable table. Wildcard characters can be used on both tablename and variablename. For example:

modify parms=@.@

Modifies all variables on all tables.

modify parms=@

Modifies all variables on the default table.

modify parms=@.acct@

Modifies all the variables whose name starts with acct on all the existing tables.

Remember: The action of modifying or adding a variable locks the variable table that contains it. This implies that, while the table is locked, no other user can run any other locking commands on it or on the variables it contains.

vartable | vt

If no argument follows, modifies all variable table definitions.

If argument tablename variable table follows, modifies the tablename variable table. Wildcard characters are permitted.

prompts | prom

If no argument follows, modifies all prompt definitions.

If argument promptname follows, modifies the promptname prompt. Wildcard characters are permitted.

resources | resource | res

If no argument follows, modifies all resource definitions.

If argument workstationame#resourcename follows, modifies the resourcename resource of the workstationame workstation on which the resource is defined. If workstationame is omitted, the default is the workstation on which composer is running. Wildcard characters are permitted for both workstationame and resourcename.

cpu

Modifies workstations, workstation classes, or domains.

workstation: The name of the workstation. Wildcard characters are permitted.
workstationclass: The name of the workstation class. Wildcard characters are permitted.
domain: The name of the domain. Wildcard characters are permitted.

workstation | ws

If no argument follows, modifies all workstation definitions.

If argument workstationname follows, modifies the workstationname workstation. Wildcard characters are permitted.

domain | dom

If no argument follows, modifies all domain definitions.

If argument domainname follows, modifies the domainname domain. Wildcard characters are permitted.

workstationclass | wscl

If no argument follows, modifies all workstation class definitions.

If argument workstationclassname follows, modifies the workstationclassname workstation class. Wildcard characters are permitted.

jobs | jobdefinition | jd

If no argument follows, modifies all job definitions.

If argument workstationame#jobname follows, modifies the jobname job of the workstationame workstation on which the job runs. If workstationame is omitted, the default is the workstation on which composer is running. Wildcard characters are permitted for both workstationame and jobname.

sched | jobstream | js

If no argument follows, modifies all job stream definitions.

If argument workstationame#jstreamname follows, modifies the jstreamname job stream of the workstationame workstation on which the job stream is defined. If workstationame is omitted, the default is the workstation on which composer is running. Wildcard characters are permitted for both workstationame and jstreamname.

valid from: date Restricts the selection to job streams that have a valid from date equal to the indicated value. The format is mm⁄dd⁄yyyy.
valid to: date Restricts the selection to job streams that have a valid to date equal to the indicated value. The format is mm⁄dd⁄yyyy.
valid in: date date The time frame during which the job stream can run. The format is mm⁄dd⁄yyyy - mm⁄dd⁄yyyy. One of the two dates can be represented by @.
full: Modifies all job definitions contained in the job stream.

users | user

If no argument follows, modifies all user definitions.

If argument workstationame#username follows, modifies the username user of the workstationame workstation on which the user is defined. If workstationame is omitted, the default is the workstation on which composer is running. Wildcard characters are permitted for both workstationame and username.

Comments

The modify command performs the following sequence of actions:

Locks the objects in the database.
Copies the objects definition into a temporary file.
Edits the file.
Replaces the definition contained in the temporary file to the database.
If the modify command fails on a subset of the selected objects, composer asks "do you want to re-edit?" and the file saved before is reopened for editing and the next steps of the sequence are repeated.
Unlocks the objects in the database.

Event rule definitions are opened with an XML editor (see Event rule definition for XML reference and see The composer editor for details on setting up an XML editor).

If you modify with the same modify command two or more objects linked together by any relationship, for example a successor job and its predecessor job, then it might be relevant for the successful result of the modify command the order in which the objects are listed in the temporary file. This happens because the modify command reads in sequence the objects contained in the temporary file; so, if the referencing object is displayed before the object being referenced, the modify command might fail on the referencing object.

For example, if the command:

modify FTA1#@PROVA

produces the following temporary file:

SCHEDULE FTA1#PROVA VALIDFROM 08/31/2005
MATCHING SAMEDAY
:
FTA2#MY-JOB
 FOLLOWS FTA1#COPYOFPROVA.MY-JOB06
END

SCHEDULE FTA1#COPYOFPROVA VALIDFROM 08/31/2005
MATCHING SAMEDAY
:
FTA1#MY-JOBO6
END

and you change the name of the predecessor job from FTA1#MY-JOB06 to FTA1#MY-JOB05 in both job streams FTA1#PROVA and FTA1#COPYOFPROVA, then the modify command:

At first tries to change the definition of job stream FTA1#PROVA and it fails because it finds a follows dependency from a job FTA1#MY-JOB05 which is still unknown.
Then it tries to change the definition of FTA1#COPYOFPROVA and it succeeds.

The second time you run modify to change the predecessor job from FTA1#MY-JOB06 to FTA1#MY-JOB05 in job stream FTA1#PROVA, the command is successfully performed since the predecessor job FTA1#MY-JOB05 now exists in the database.

If job stream FTA1#COPYOFPROVA had been listed in the temporary file before FTA1#PROVA, then the modify command would have run successfully the first time because the name of the predecessor job would have been modified before changing the dependency definition in the successor job.

For user definitions, if the password field keeps the "*******" value when you exit the editor, the old password is retained. To specify a null password use two consecutive double quotes (“”).

The modify command checks for loop dependencies inside job streams. For example, if job1 follows job2, and job2 follows job1 there is a loop dependency. When a loop dependency inside a job stream is found an error is displayed. The modify command does not check for loop dependencies between job streams because, depending on the complexity of the scheduling activities, this check might be too time and CPU consuming.

Examples

To modify all calendars, run the following command:

modify calendars=@

To modify job stream sked9 that is launched on workstation site1, run the following command:

m sched=site1#sked9

To modify all the event rules that include an action with job DPJOB10, run: