task
This option is needed for specifying parameters of tasks used in process configuration. The process configuration consists of several tasks grouped into activities. Many of tasks used there need to know some input data, for example system names, dataset names, and much more. The options which are required are described in details in the online help of Procman/HOS and therefore we show only a sam-ple demonstrating how to configure these options. The fact that the process definition and task options are separated helps to separate process logic from the data like systems, datasets, content of select boxes,...
The example is just a little part of the environment definition. All preceding options of the environment are usually inserted in the request and activity specified with wildcards. But this is usually not the case of task option. This is because task options must be valid for concrete process definition and the task names in the environment and in the process definition must match. In the example we use t0400 task and we define several options in the inner array. These options will therefore be available in t0400 task of JCL_CHANGE_PROD_APPROVE activity of JCL_CHANGE_PROD process in HORIZONT client. In this case t0400 in the corresponding process configuration calls m_jcl_approve module, which shows the approve web page. Systems and datasets coded in the environment are required by this module in order it is able to offer correct systems and libraries in its select boxes.
There are a few methods how to define items in the task array. Each one produces a different result on the web page. All available methods are listed below.
• constant:
In this case there is no visible field on the web page, where the user can select or see the value. The value is always SYSH_ID and it can't be edited and it is hidden.
• empty text field:
In this case an empty text field is displayed on the web page:
• initialized text field:
In this case a text field is rendered on the web page and its content is initialized with the value speci-fied in the array.
• read-only text field:
In this case the value can't be changed (like when you define a constant), but it is visible on the screen. You can make the field read-only by adding ! in front of the value. The result is:
• select box:
In this case a select box is rendered on the web page. When you specify only values like in case of the target library then you see exactly the values from the array. You can also specify a value and a label separated by a colon. In this case you see the label but the value is used when an item is selected. This is common when you specify systems, as their ID is im-portant for Procman/HOS while the label is important for users.
• select box with a default value:
Enter ! in front of the value you wish to select by default:
In this case P391D.PETRH.TEMP2 is selected by default when the page is first displayed:
• reference:
Use it when the value is the same as a value of another field:
• conditional field:
It is possible to render a field by any of the preceding methods conditionally. That means the rendering method depends on a value of another field:
In this case when SYSH_ID export system is selected then the export library shows an edit field initial-ized with your SYSUID followed with '.DATA.TEST'. If SYSH2_ID system is selected then the export library changes to a select box with two items.
and
You can also use remote dependencies in conditional fields. They are available only in some cases (when the referenced task stores data to JCKIN database table). This shows a reference in the same activity:
The target library is rendered as a read-only edit field initialized with P391D.PETRH.TEMP1 if the tar-get library selected at task t0500 in the same activity is P391D.NEW.TEMP1. The second row should be clear, it is analogous.
This sample shows a reference to another activity:
In this case the condition is based on target_library option of t0500 task in JCL_CHG_REQUEST activity.
You can use variables in any value used in task options. Please note the mandatory dot at the end. Available variables are:
%SYSUID. it is replaced with the user that is logged in Procman in upercase.
%(VAR). it is replaced with VAR HWM variable.
%(VAR,n). it is replaced with a substring of VAR HWM variable that starts at 'n' position. The position is 1-based.
%(VAR,n,p). it is replaced with a substring of VAR HWM variable that starts at 'n' position and has a maximal length equal to 'p' . The position is 1-based.
Let's now assume that the current user is P391D and that HWM variable DEPARTMENT equals 'DEP14':
%SYSUID..JOBLIB.* is substituted as P391D.JOBLIB.* %SYSUID..JOBLIB.%(DEPARTMENT)..* is substituted as P391D.JOBLIB.DEP14.* %SYSUID..JOBLIB.%(DEPARTMENT,3)..* is substituted as P391D.JOBLIB.P14.* %SYSUID..JOBLIB.%(DEPARTMENT,1,4)..* is substituted as P391D.JOBLIB.DEP1.*
You can use variables also in keys of conditions. A few examples:
If the selected source_system equals the value of TESTVAR1 HWM variable then use the first value. If the selected source_system equals the value of TESTVAR2 HWM variable then use the second value. Else use the last default value:
If the value of client HWM variable equals TEST then use the first value. If the value of client HWM variable equals HORIZONT then use the second value.
Else use the last default value:
Last updated