SERVOPTS

Purpose

The SERVOPTS statement is for a server which handles transactions directed to the controller subsystem name on the same z/OS® system as the server.

Format


1  SERVOPTS?  ARM (
2.1! NO
2.1 YES
1 )?  CODEPAGE (
2.1! IBM – 037
2.1 host system codepage
1 )?  DBOPTPRM (
2.1! DBOPT
2.1 member
name
1 )?  JSCHOSTNAME (
2.1! local
hostname
2.1 hostname
2.1 IP address
1 )?  PORTNUMBER (
2.1! 425
2.1 value
1 )?  SCHEDULER ( + , Scheduler
name )  SUBSYS (
2.1 Controller Subsystem name
1 )?  TASKUSR (
2.1! YES
2.1 NO
1 )?  USERMAP (  parameters library member )

Parameters

This section describes parameters that apply to all connection types. Parameters that are specific to a connection type are described separately in the sections that follow.

ARM (YES|NO)
The z/OS Automatic Restart Manager (ARM) can reduce the impact of an unexpected error to HCL Workload Automation for Z because z/OS can restart it automatically, without operator intervention.

Specify YES if automatic restart of the failed HCL Workload Automation for Z component should be activated. ARM recovery of the failed HCL Workload Automation for Z component is possible in the same image (restart-in-place). This feature allows the recovery of the tracker and a fast restart of the controller and the server. In addition, restart-in-place does not reduce the number of standby controllers when there is a controller failure. The number of restarts and the period of a restart are parameters that can be customized for each HCL Workload Automation for Z component in the z/OS ARM policy.

CODEPAGE (host system codepage|IBM–037)
The name of the host code page. You can provide the IBM®–nnn value, where nnn is the EBCDIC code page. The default value, IBM®–037, defines the EBCDIC code page for US English, Portuguese, and Canadian French. If you specify a codepage value different from the default value, a check has been implemented to use the default codepage if the first four characters of the codepage you specify are different from "IBM-". The following is a list of the EBCDIC code pages:
IBM®–939
Japan Extended
IBM®–937
Taiwan
IBM®–935
China
IBM®–933
Korea
IBM®–875
Greece
IBM®–871
Iceland
IBM®–870
Latin 2
IBM®–838
Thai
IBM®–500
International
IBM®–424
Israel
IBM®–297
France
IBM®–285
UK
IBM®–284
Spain - Latin America
IBM®–280
Italy
IBM®–278
Sweden - Finland
IBM®–277
Denmark - Norway
IBM®–274
Belgium
IBM®–273
Germany
IBM®–1388
China
IBM®–1122
Estonia
IBM®–1112
Baltic
IBM®–1047
Open Systems
IBM®–1026
Latin 5 (Turkey)
IBM®–1025
Cyrillic
The following is a list of the EBCDIC code pages for EURO support:
IBM®–1140
Finland, Sweden
IBM®–1141
Austria, Germany
IBM®–1142
Denmark, Norway
IBM®–1143
USA
IBM®–1144
Italy
IBM®–1145
Spain, spanish-speaking Latin America
IBM®–1146
UK
IBM®–1147
France
IBM®–1148
Belgium, Switzerland
IBM®–1149
Iceland
DBOPTPRM(member name|DBOPT)
Indicates the member of the PARMLIB that contains the parameters to connect to the database and manage the historical data archiving process.
JSCHOSTNAME (JSChostname|IP address| local hostname)
Specifies the host name or IP address that is used by a remote application to connect to the server, when PROTOCOL=TCP. It can be up to 52 alphanumeric characters. The default is the host name returned by the operating system.

You can define a virtual IP address for each server of the active controller and the standby controllers. If you use a dynamic virtual IP address in a SYSPLEX environment, when the active controller fails and the standby controller takes over the communication, the remote application automatically switches the communication to the server of the standby controller.

If you specify the TCPOPTS statement for the server, the HOSTNAME parameter overrides the JSCHOSTNAME parameter in the SERVOPTS statement. It applies also if the HOSTNAME parameter is not explicitly defined: in this case, the default value overrides any different value specified in the SERVOPTS statement.

PORTNUMBER (value|425)
The port number used by the server when PROTOCOL=TCP. Valid values are from 0 to 65535. The default is 425. This port number is used by the server to connect to the remote application.

If you specify the TCPOPTS statement for the server, the SRVPORTNUMBER parameter overrides the PORTNUMBER parameter in the SERVOPTS statement. It applies also if the SRVPORTNUMBER parameter is not explicitly defined: in this case, the default value overrides any different value specified in the SERVOPTS statement.

SCHEDULER (scheduler name)
Identifies the name of the server as an APPC scheduler. This parameter is used only if PROTOCOL is set to APPC. If you omit this parameter, the started task name is used as scheduler name.
SUBSYS (controller subsystem name)
Identifies the controller for which this server is started.
TASKUSR(NO|YES)
Specifies if a started task is to be run with the user ID associated with the task, instead of the user ID associated with the job name.
YES
The task is run with the user ID associated with the started task name. This is the default.
NO
The task is run with the user ID associated with the job name.
USERMAP (parameters library member)
Defines a member in the file identified by the EQQPARM DD statement in the server startup job. This member contains all the associations between a Z connector user and a RACF® user ID. If the USERMAP exists, the TMEADMIN security class is ignored.

If the RACF class EQQADMIN is defined and enabled (meaning that AUTOMAPPING APPLDATA(‘YES’) is set in the class), the USERMAP definitions and TMEADMIN class are ignored.

The syntax of a USERMAP is:
USER 'z_connector_user_ID' RACFUSER(matching_RACF_user_ID) 
     RACFGROUP(matching_RACF_group_ID)
USER 'z_connector_user_ID' RACFUSER(matching_RACF_user_ID) 
     RACFGROUP(matching_RACF_group_ID)
...
USER 'z_connector_user_ID' RACFUSER(matching_RACF_user_ID) 
     RACFGROUP(matching_RACF_group_ID)
where RACFGROUP can be omitted if RACF_group_ID is the default.
For example:
USER 'BMDLPS@ITSWB019'      RACFUSER(BMDLPS) 
USER 'BMDLPS@ITSWB020'      RACFUSER(BMDLPS)  
USER 'BMD1LPS@ITSWB019'     RACFUSER(BMDLPS) 
USER 'BMD2LPS@ITSWB020'     RACFUSER(BMDLPS)  
USER 'RSOGFK@ITSWB019'      RACFUSER(RSOGFK) 
USER 'RSOGFK@ITSWB020'      RACFUSER(RSOGFK) 
USER 'RSOLLM@ITSWB019'      RACFUSER(RSOLLM) 
USER 'RSOLLM@ITSWB020'      RACFUSER(RSOLLM)
Parameters
USER 'z_connector_user_ID'
The ID of every Dynamic Workload Console user who is authorized to log on to HCL Workload Automation for Z using the HCL Workload Automation for Z connector. The ID format is username@domain. This parameter is mandatory.

Note that you must also include the ID of the user who installed the HCL Workload Automation for Z connector (administrator). For more information about associating the administrator to RACFUSER, see User IDs involved with Dynamic Workload Console.

RACFUSER(RACF_user_ID)
The RACF® user ID defined for every Z_connector_user_ID specified with the USER keyword. This parameter can be up to 7 characters in length and is required (see User IDs involved with Dynamic Workload Console).
RACFGROUP(RACF_group)
The RACF® group related to the RACF® user. This parameter can be up to 8 characters in length and is optional (see RACF® group definitions). It is used to set a group different from the default one associated with the specified matching_RACF_user_ID of the RACFUSER.
To simplify the task of mapping users in the USERMAP member, you can use the following wildcard characters:
Asterisk (*) for USER
To filter 0 or more characters in z_connector_user_ID. Only one asterisk per row is allowed.
Ampersand (&) for RACFUSER
To match in matching_RACF_user_ID the string wildcarded in z_connector_user_ID.
For example, to add the following users:
USER 'BMDLPS@ITSWB019'      RACFUSER(BMDLPS) 
USER 'BMD1LPS@ITSWB019'     RACFUSER(BMDLPS)
you can enter:
USER 'BMD*LPS@ITSWB019'      RACFUSER(BMDLPS)
or to add the following users:
USER 'RSOGFK@ITSWB020'      RACFUSER(RSOGFK) 
USER 'RSOLLM@ITSWB020'      RACFUSER(RSOLLM)
you can enter:
USER 'RSO*@ITSWB20'      RACFUSER(RSO&)
The rows containing wildcard characters are resolved at runtime.
Important:
  • Updates to the USERMAP require a stop and restart of the TCP/IP server to become active. But if you use the wildcards, and you want to add a Dynamic Workload Console user that falls within an already wildcarded definition, this does not require to restart the server. For example, this would be the case if the USERMAP already contains the following entry:
    USER 'RSO*@ITSWB20'      RACFUSER(RSO&)
    In this example, the new user RSO115@ITSWB20 (who has already been defined to RACF as RSO115) can connect to HCL Workload Automation for Z without the need of a USERMAP update and of a server restart.
  • The '*' and '&' characters respectively represent the '5C' and '50' hexadecimal characters of the 037 codepage. If you run on a different codepage, replace '*' and '&' with the characters that match '5C' and '50' HEX on that codepage.
  • When the '&' character is processed at runtime to match the string wildcarded in z_connector_user_ID, the resulting RACFUSER entry may exceed the 8-character limit. For example, to add user:
    john.smith@mydomain.com
    in the USERMAP, you enter:
    USER 'JOHN.*@MYDOMAIN.COM'    RACFUSER(RACF&)
    At runtime the RACFUSER entry is resolved as RACFSMITH, which is 9 characters.

    When this happens, the RACFUSER entry is automatically truncated to 8 characters and message EQQPH70W is issued to communicate that this action was taken. In this example RACFUSER becomes RACFSMIT.

  • To activate auditing on the mapping tasks between USER and RACFUSER, edit member EQQPH6 to set MLOG=YES in the headers of messages EQQPH64, EQQPH65, and EQQPH66. Then run a RECYCLE of the TCP/IP server.