rename

Renames a scheduling object already existing in the database. The new name must not identify an object already defined in the database. When renaming a scheduling object, in addition to modifying the name, you can also move the object to a specified folder path, where the folder names reflect strings contained in the scheduling object name. The folder must already exist.

Authorization

To rename scheduling objects, you must have delete access to the object with the old name and add access to the object with the new name.

To rename security objects, you must have permission for the modify action on the object type file with attribute name=security.

Syntax

{rename | rn}
old_object_identifier new_object_identifier [;preview]
{[calendars | calendar | cal=[folder/]calname] |

[parms | parm | vb=[[folder/]tablename.]variablename] |
[vartable | vt=[folder/]tablename] |

[prompts | prom=[folder/]promptname] |
[resources | resource | res=[[folder/]workstationame#][folder/]resourcename] |
[runcyclegroup | rcg=[folder/]runcyclegroupname] |

[workstation | ws=[folder/]workstationame]

[workstationclass | wscl]=[folder/]workstationclassname |
[domain | dom]=domainame] |

[jobs | jobdefinition | jd]=[[folder/]workstationame#][folder/]jobname |
[sched | jobstream | js]= [[folder/]workstationame#]
[eventrule | erule | er=[folder/]eventrulename] |
[wat=[folder/]workloadapplicationtemplatename]
[folder|fol] =foldername] |
[sched | jobstream | js]= [[folder/]workstationame#][folder/]jstreamname
[valid from date|valid to date |valid in date date]] |
[accesscontrollist | acl for securitydomainname] |
[securitydomain | sdom=securitydomainname] |
[securityrole | srol=securityrolename] |
[users|user=usesrname] }

Arguments

old_object_identifier: Specifies the old external key identifying the scheduling object, for example calendar name cal1 as identifier for a defined calendar object to be renamed.
new_object_identifier: Specifies the new external key identifying the scheduling object, for example calendar name cal2 as new identifier to be assigned to calendar object previously named cal1.
;preview: Optional. Use this option to review the result without actually performing the rename operation. No validation is performed for a preview, for example, a check on the existence of the target folders specified, or the use of reserved words in job or job stream names. This option can be used together with the following options: jobdefinition, jobstream, runcycle, runcyclegroup, folder, accesscontrollist, securityrole, securitydomain.

For what concerns jobs, job streams, resources and users both the old_object_identifier and new_object_identifier have the following formats:

[folder/][workstationame#][folder/]jobname: The command applies to this job definition. This format is used with the jobs|jobdefinition|jd key.
[folder/][workstationame#][folder/]jstreamname: The command applies to all versions of this job stream optionally defined in the specified folder. This format is used with the sched|jobstream|js key.
[workstationame#][folder/]jstreamname.jobname: The command applies to this job instance defined in this job stream where the job stream is optionally defined in this folder. See the js keyword in the Job stream definition syntax for additional details. This format is used with the jobsched|jb key.
[folder/][workstationame#]resourcename: The command applies to this resource definition. You can optionally specify the folder where the workstation hosting the resource is defined. This format is used with the resources|resource|res key.
[folder/][workstationame#][domain\]username: The command applies to this user definition. You can optionally specify the folder where the workstation hosting the domain manager is defined. This format is used with the users|user key.

For what concerns variables (global parameters):

old_object_identifier: Must be specified in the tablename.variablename format. If tablename is omitted, composer looks for the variable in the default variable table.
new_object_identifier: Must be specified in the variablename format. Adding the table name here generates an error.

Comments

To be renamed, the object must be unlocked or locked by the user who issues the rename command.

When renaming a folder, if the folder already exists in the plan, the new folder name is also reflected in the plan. After the change, you must use the new folder name when using listfolder and chfolder commands or when displaying scheduling objects from the Dynamic Workload Console. You can also rename a folder using the dedicated composer command renamefolder.

The variable table containing the variable is locked, while the variable is renamed. This implies that, while the table is locked, no other user can run any other locking commands on it. Folders, however, are not locked in the database while being renamed, therefore two concurrent rename commands on the same folder result in the folder being renamed as specified in the most recent command submitted.

If an object named as specified in the old_object_identifier field does not exist in the database an error message is displayed.

One or more wildcards can be used to express part of the job or job stream name. Wildcards are not supported for other objects. When you rename a job or job stream, you can tokenize part of the job or job stream name and then use the tokens to specify the names of the folders and sub-folders into which you want to move the jobs or job streams. When multiple wildcards are used, the positional order is respected after the rename operation. See Examples for details about how to move jobs and job streams into folders that are named after tokens in the job and job stream name. See Organizing scheduling objects into folders for more information about how to move jobs and job streams into folders in batch mode and for more complex examples.

When workstationame is not specified for objects that have the workstation name as part of their object identifier (for example, job or job stream definitions), the program uses one of the following for workstationame:

The default workstation specified in the localopts file
The master domain manager if the composer command line program is running on a node outside the HCL Workload Automation network. In this case, in fact, the default workstation set in the localopts file is the master domain manager.

The rename command is used to assign new names to objects already existing in the database. The new name assigned to an object becomes immediately effective in the database, while in the plan it maintains the previous name until the JnextPlan script is run again. If you submit ad-hoc jobs before generating again the production plan, use the previous name.

Note: Renaming any kind of domain manager, such as master domain manager, dynamic domain manager, or their backups is not a supported operation and might lead to unpredictable results.

Examples

To rename domain object DOMAIN1 to DOMAIN2, run the following command:

rename dom=DOMAIN1 DOMAIN2

To rename variable ACCTOLD (defined in table ACCTAB) to ACCTNEW, run the following command:

rename parm=ACCTAB.ACCTOLD ACCTNEW

To rename job stream LABJST1 to LABJST2 on workstation CPU1, defined in folder myfolder, run the following command:

rename js=myfolder/CPU1#LABJST1 CPU1#LABJST2

To rename and move all job stream definitions currently defined in the root (/) folder, corresponding to the naming convention ITALY_WS#ROME_MILAN_JOB_STREAM_NAME, to a folder structure with folder names based on strings contained in the job stream name, run the following command:

rename js @#ROME_MILAN_@ @#/ROME/MILAN/@

The result is structured as follows:

ITALY_WS#/ROME/MILAN/_JOB_STREAM_NAME