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] [;force] |
[workstationclass | wscl]=[folder/]workstationclassname [;force] |
[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 namedcal1
. - ;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.
- [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.
- 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.
- 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.
Examples
DOMAIN1
to DOMAIN2
, run the following
command: rename dom=DOMAIN1 DOMAIN2
ACCTOLD
(defined in table
ACCTAB
) to ACCTNEW
, run the following command:
rename parm=ACCTAB.ACCTOLD ACCTNEW
LABJST1
to
LABJST2
on workstation CPU1
, defined in folder
myfolder
, run the following command:
rename js=myfolder/CPU1#LABJST1 CPU1#LABJST2
rename js @#ROME_MILAN_@ @#/ROME/MILAN/@
The
result is structured as
follows:ITALY_WS#/ROME/MILAN/_JOB_STREAM_NAME
See also
From the Dynamic Workload Console you can perform the same tasks as described in:
the Dynamic Workload Console User's Guide.
- To rename workstations, see
- To rename event rules, see
- To rename security domains and security roles, see
- To rename all other objects, see