Move a set of scheduling objects in batch mode to specified folders using the scheduling
object naming convention to name the folders.
The following scheduling
objects can be defined in or moved into folders:
- jobs
- job streams
- workstations
- workstation classes
- calendars
- event rules
- prompts
- resources
- run cycle groups
- variable tables
- workload applications
You can organize your existing scheduling objects that use a specific
naming convention into folders. Folders might
represent a line of business or any other meaningful category to help you identify and
monitor your workload. When moving scheduling objects into folders, you can
choose to use part of the object's name as the folder name. The
folder
name might be a prefix or suffix used in the object's name. Removing this string from
the object name frees up some characters in the object name allowing you to create more
readable or descriptive names. Wildcards are used to represent tokens in the object
names which are then used to indicate the folder names.
Folders with these designated names must already exist. Rename the objects and move
them to specified folders in
batch mode using the composer rename command. The
;preview option is provided so you can first test the command,
without actually submitting it, to get a preview of the output and verify the
expected result.
In mixed environments
with agents at versions earlier than 9.5 FP2, ensure that master domain manager, backup master domain manager, and domain managers are at
version 9.5 FP2 level. For detailed information about using command-line commands and scheduling
objects in environments at various version levels, see section Compatibility scenarios and
limitations in IBM Workload Scheduler Release Notes.
Before you go ahead and move
scheduling objects into folders, it
is recommended that you first verify if there are any existing event rule
definitions that reference these objects. If references are found, duplicate the
event rule and update the references to the objects using the new name and folder path.
Then, proceed to rename and move the object to the desired folder as
described in the following procedure. You can remove the original event rule
definition that references the old object name only after verifying that no other
instances of the object with the old name exist in the plan.
The high-level steps for organizing your scheduling objects into folders are as follows:
-
Create the folders first. Create the folder hierarchy with the
required names in the IBM® Workload Scheduler
database. See mkfolder for creating folders from the composer CLI.
See Designing Folders to create folders from the Dynamic Workload Console.
-
Rename and move the scheduling object into the desired folder. Run the composer
rename command mapping the object name to folder names using wildcards. Use
the ;preview option the first time to ensure you obtain the expected result, and
then run the command a second time without the ;preview. There are several
approaches to organizing your jobs and job streams into designated folders with meaningful names.
The following are some examples of how to use wildcards to map tokens contained in the object
definitions to folder
names. The examples are divided in two categories: renaming objects without the workstation name in
the object identifier and renaming objects with the workstation in the object identifier.
- Renaming objects that do not have the workstation name as part of their object identifier
(calendars, event rules, prompts, workstations, workstation classes, variable tables, workload
applications, run cycle groups)
- Move a workstation from the root folder to a child folder
- Before:
AA_BB_WS1
AA_BB_WS2
After:
/AA/BB/WORKSTATION1
/AA/BB/WORKSTATION2
composer rename ws @_@_ws@ /@/@/workstation@
- Move a variable table to a child folder using a combination of the "@" and "?" wildcards
- Before:
AA_BB_EF_GHI
AB_CD_GH_IJK
BB_CC_EF_GHI
composer rename vt ??_??_@ /??/??/@
After:
/AA/BB/EF_GHI
/AB/CD/GH_IJK
/BB/CC/EF_GHI
- Renaming objects that have the workstation name as part of their object identifier (jobs, job
streams, resources)
Note: If
you define a rule to rename objects whose object identifier includes the workstation, for example, a
job, job stream, or resource, then remember that the wildcard character can also be used for the
workstation, with respect to positional order.
- Move them from the root to a first-level folder named after the prefix in
the object name
- Before:
WS_NAME#ABC_JSNAME
composer rename js @#ABC_@ @#/ABC/@
After:
WS_NAME#/ABC/JSNAME
- Move them from the root to a first-level folder named after the suffix in
the object name
- Before:
WS_NAME#DEFG_JSNAME_ABC
composer rename js @#@_ABC @#/ABC/@
After:
WS_NAME#/ABC/DEFG_JSNAME
- Move them from the root to a first-level folder where a wildcard character
is used to represent the root and is replaced with a blank
- Before: @#/@/@, where @#/@/@ represents WS_NAME#JSNAME and JSNAME is in the root
folder
composer rename js @#/@/@ @#/F_@/J_@
After:
WS_NAME#/F_/J_JSNAME
- Move them from the root into a hierarchy of folders named using both the
prefix and the suffix in the object name
- Before:
WS_NAME#ABC_DEF_JSNAME_GHI
composer rename js @#ABC_DEF_@_GHI @#/GHI/ABC/DEF/@
After:
WS_NAME#GHI/ABC/DEF/JSNAME
- Before:
WS_NAME#ABC_DEF_JSNAME
composer rename js @#ABC_DEF_@ @#/ABC/DEF/@
After:
WS_NAME#/
ABC/
DEF/JSNAME
- Before:
WS_NAME#ABCDEF_JSNAME
composer rename js @#ABCDEF_@ @#/AB/CD/EF/@
After:
WS_NAME#/AB/CD/EF/JSNAME
- Move them from an existing folder to sub-folders
- Before: WS_NAME#ABC/DEFG_JSNAME
composer rename js @#ABC/DEFG_@ @#/ABC/DE/FG/@
After:
WS_NAME#/ABC/DE/FG/JSNAME
- Move them from an existing folder to a different folder using the "?" wildcard character
- Before:
WS_NAME#MK_1_T/JOB_MY_DEF1_NOW_A
composer rename jd /MK_?_T/JOB_MY_DEF?_NOW_A /MY_TEST?/TEST_JOB1
After:
WS_NAME#/MY_TEST1/TEST_JOB1
- Move them from the root to a hierarchy of folders using both the "@" and "?" wildcard
characters
- Before: WS_NAME#/F1_JSMT01
composer rename WS@#F?_JS@ WS@#/F?/JS/@
After:
WS_NAME#/F1/JS/MT01
- Move them from an existing folder to a different folder and rename both the workstation and job
name
- Before: WS_NAME#/ROME/JOBNAME
composer rename jd @#/ROME/@ WKS_NAME#/PARIS/???_DA
After:
WKS_NAME#/PARIS/A_B_DA
WKS_NAME#/PARIS/A_C_DA
- Move them from an existing folder to a different folder and rename both the workstation and job
name
- Before: WS_NAME#/ROME/DPT
composer rename jd @#/ROME/@ S_MDM#/ROME/???_DA@
After:
S_MDM#/ROME/RE_DADPT, where the wildcard group "???" is matched to "RE" because there
were no other matches with more than two characters.
For more information about the
composer rename command and syntax, see
rename.
-
Update the security file to assign the appropriate security access. If access was
originally granted on a scheduling object based on matching criteria in the object name, then this
access must be modified to include the folder. Use a security domain and
add the folder name to the scheduling object, and the folder security object to the
security file. You must also add the CPUFOLDER attribute to all objects that include the CPU object
attribute, for example, jobs, job streams, userobj, resources, and parameters. See Security domain definition if you configure security using the
composer command line or Managing security domains if you configure
security from the Dynamic Workload Console.
If you are updating or upgrading your fault-tolerant agents to version 9.5 Fix Pack 2 or
later, these updates are especially important if you plan to use the command line on the
fault-tolerant agents to perform operations on the objects in
folders.
. The topic refers
to updating the security file on the master domain manager and backup master domain manager for the classic security model, but the
same updates apply to a fault-tolerant agent. If you updated your 9.5 or
9.5.0.x agents to version 9.5 Fix Pack 2 or later, then see Completing the security configuration for information about how to manually
update the security file to include access to folders. The topic refers to
updating the security file on the master domain manager and backup master domain manager for the classic security
model, but the same updates apply to a fault-tolerant agent.
If you upgraded
your agents from a previous product version, for example, 9.4.x, to 9.5 Fix Pack
2 or later, then see Completing the security configuration for information
about how to manually update the security file to include access to folders. This section refers to
updating the security file on the master domain manager and backup master domain manager for the classic security
model, but the same updates apply to a fault-tolerant agent.
The objects are now defined in the specified folder paths.