Security planning

The JES Explorer view within the Host Explorer perspective provides a mechanism to view job output, purge job output, and cancel running jobs. All of these features can be controlled or limited by a software security product such as RACF or ACF2. In addition, for users that may not have a security package or are not implementing SYSOUT security rules through their security software, a limited set of alternative options to control what output can be viewed by BMC AMI DevX Workbench for Eclipse users are available.

JES Explorer allows for a significant degree of freedom to view any output in the system. This often occurs when users apply the security settings supplied by the software used to view output on an IBM 3270-type device, such as SDSF or IOF. These security settings apply only to those products and are not the same as system-wide security settings, which can be implemented using system security software products, such as RACF, ACF2, or Top Secret. Thus, a setting within SDSF or IOF to limit allowable viewing only applies to SDSF or IOF, not the system. Alternatively, if the system security software was used to impose output security, then all attempts to view output are controlled regardless of the viewing software. We recommend using the available security settings of the system software security product to impose output security (Options 1 and 2, here).

The next sections discuss the available options for security limitations:

•  Option 1—Controlling the ability of users to view output using a security product.
•  Option 2—Controlling the ability of users to cancel jobs or output using a security product.
•  Option 3—Implementing a basic form of security that limits viewing output when a security product is not installed or not configured for output control.

Option 1: Limit user’s ability to view output using a security product.

The JES Explorer view allows users to view the output from jobs within the system. Installations wishing to secure this access and control user access to output can do so by setting the appropriate profiles for the security class JESSPOOL.

Profiles for JESSPOOL are in the format:

Local-nodename.userid.jobname.jobid.dsnumber.name

Using combinations of user IDs and wild card characters, output viewing can be limited on a user id or group id basis as the installation chooses.

For installations that simply wish to invoke basic user-level security for output, where a user is limited to viewing only their own output, simply activate the JESSPOOL class in their security software and specify no profiles.  User owning-only access is then the default action.

As provided by IBM system action, users are always allowed access to their own jobs or output, regardless of profiles under JESSPOOL that might seemingly restrict it.

Please consult your installation's appropriate security software administration documentation for additional information. For RACF installations, controlling access to output via the JESSPOOL class is documented in the z/OS Security Server RACF Security Administrator's guide, "Controlling Access to Spool Data”.

Option 2: Limit user’s ability to cancel jobs or purge output using a security product.

The JES Explorer viewer provides a mechanism for BMC AMI DevX Workbench for Eclipse users to purge job output as well as cancel jobs that are in execution. These types of requests cause a JES2 $CJ cancel command or a JES3 MODIFY command to be issued to the system in order to honor the request. Installations wishing to secure or limit what can be canceled can do so by setting the appropriate JES2.CANCEL.* or JES3.MODIFY.* profiles for the security class OPERCMDS using the security software package in use on their system.

These are the only command types that JES Explorer will issue.

The setting specific OPERCMDS profiles only restricts a user's ability to issue the command itself (the user is either permitted or denied to issue the command); there is no control for which jobs can be canceled nor output be purged.  In order to control a user's ability to cancel specific jobs or output, you must use OPERCMDS profiles that allow the commands above to be issued in conjunction with appropriate JESSPOOL profiles that allow ALTER access to the jobs identified by the profiles.

As provided by IBM system action, users are always allowed access to their own jobs or output, regardless of profiles under JESSPOOL that might seemingly restrict it.  Further, users are always permitted to cancel their own jobs or purge their own output (if OPERCMDS profiles allow it) even if no JESSPOOL profiles exist that would give the user ALTER access to the resource.  A JESSPOOL profile with ALTER access would be required for a user to cancel a job or purge output that he does not own.

Installations that are using output viewing software such as SDSF or IOF probably already have OPERCMDS properly set to allow JES2 $CJ or JES3 MODIFY commands to be issued by general users, so that they can purge their own output.

Installation may also choose to use conditional access profiles to control whether JES Explorer users can issue JES2 $CJ or JES3 MODIFY commands to cancel a job or purge output. Conditional access may allow for use of some existing security rules already in place — by using the WHEN(CONSOLE(name)) conditional in your security software in conjunction with the CONSOLEPOE statement in the CSS TP Configuration section of the HCI00 Parameter member. The CONSOLEPOE statement allows a pseudo-console to be named that is also defined to the CONSOLE security class to be designated as a security port-of-entry. The pseudo-console name is tested by the WHEN conditional clause (if present) in profiles for JES2.CANCEL.* and JES3.MODIFY.* when JES2 $CJ or JES3 MODIFY commands are issued. The console name used in CONSOLEPOE and defined to the CONSOLE security class can be a new name with new conditional profiles designed solely for that console, or the name can specify an existing CONSOLE class member, such as SDSF. Installations desiring to use conditional access should see the CONSOLEPOE statement in the TP configuration section, as well as the section here titled Using Conditional Access for Canceling Jobs or Purging Output via JES Explorer.

Please consult your installation's appropriate security software administration documentation for additional information. For RACF installations, controlling access to system operator commands using the OPERCMDS class is documented in IBM’s z/OS Security Server RACF Security Administrator's guide, in the section entitled “Administering the Use of Operator Commands”.

Option 3: Limit user's ability to view only their own output (no security product setup required).

Within the BMC AMI Common Shared Services (CSS) TP Configuration section of the HCI00 Parameter member, there is a configuration setting that can be used to allow the installer to impose a “by-userid” level of security when viewing output within the JES Explorer. This setting is the SYSOUT configuration statement.

This optional setting causes any attempts to view output by users to be denied unless they are the owning user ID. This means that no user can view any other user's output, except for their own.

To enable the setting, specify the keyword BY-USERID in the SYSOUT statement. This enables the by-userid security. Otherwise, the setting is set to DEFAULT, which means that the rules of your installation's security software profiles and the JESSPOOL resource class dictate the handling of output. We recommend using the JESSPOOL resource class and your security software for the best and most flexible security arrangement that meets your installation's requirements.

A setting of BY-USERID does not override any rules enforced by your security software. Rules that are more restrictive than by-userid security will continue to be enforced by your security software.

Using Conditional Access for Canceling Jobs or Purging Output via JES Explorer

The TP Configuration section provides an optional statement parameter which gives the TP the capability to name a console which is also defined to your system security software in the CONSOLE class. This console name is used to issue JES cancel and purge commands on behalf of BMC AMI DevX Workbench for Eclipse as a security port of entry (POE). Use of the CONSOLEPOE statement provides a mechanism for installations to use conditional security rules to control which users or groups may issue commands to the system via the WHEN(CONSOLE(console-name)) clause in security profiles.

The HCI Parameter member is pointed to by the //CWPARM DD statement in your HCI start-up JCL.

The CONSOLEPOE statement, if coded, can be used to specify a console name under which system commands will be issued. These system commands are issued by the JES Explorer for the purposes of purging job output or canceling active jobs. Security rules at some installations require a console name as a port of entry in order to validate the authority of the command. At present, BMC AMI DevX Workbench for Eclipse only issues $CJ commands (JES2) or *MODIFY J=,C commands (JES3).

The console name specified by the CONSOLEPOE statement may be any name and the console name chosen must be defined to the system security software as a console in the CONSOLE class.  For RACF users, example statements used to define the console are shown here.   The console name may also be a console already defined to the CONSOLE class, such as SDSF.

The console name chosen should not be the same name an existing hardware console. There is no physical relationship between the JES Explorer console port of entry name and a real MCS console.

After specifying a CONSOLEPOE statement in your member with an appropriate console name, restart the HCI. The next time a JES Explorer user wishes to cancel a job or purge output, the resulting command will be issued under the authority of the named console as a security port of entry.

This means that security rules in place that specify conditional access, for example the commonly used WHEN(CONSOLE(SDSF)) syntax, can also be specified with conditional access using the named console from the CONSOLEPOE statement, for example, WHEN(CONSOLE(CXTP01))

Specifying the CONSOLEPOE SDSF statement in the member would allow BMC AMI DevX Workbench for Eclipse to issue commands on behalf of the user with SDSF as the security port of entry, thereby invoking existing SDSF rules for validating the authority to issue the commands. This means that a duplicative set of rules similar to those already in place for SDSF need not be created for a console of another name (such as CXTP01 shown above).

Defining a Console to RACF to use Conditional Access

Defining an SDSF console to RACF is documented in z/OS SDSF Operation and Customization (SA22-7670), subsection "Using Conditional Access".

Similarly, to define a console to RACF for the purposes of using a console name such as the CXTP01 example above, your RACF administrator would issue the example commands here.  These commands illustrate how to define a console named CXTP01 to RACF and how to set a rule permitting a user to issue JES2 Cancel commands via the CXTP01 port of entry.

First, activate the CONSOLE class and define the console as a member of the class:

Then, to give conditional access to permit users or groups to issue JES2 Cancel commands only when using the JES Explorer:

The use of the CONSOLEPOE statement in the HCI Parameter member (default is HCI00) to establish a security port of entry for conditional access to the JES2.CANCEL.* or JES3.MODIFY.* security profiles only allows a user to issue the necessary command into the system. Actual execution of the command and the authority to do so against the affected job or job output is still enforced by JES2 or JES3 and is subject to the security profiles of the JESSPOOL class.

Controlling User Ability to View SYSLOG from JES Explorer

Options are available for controlling access to the system log data set (SYSLOG) from JES Explorer. The SYSLOG statement in the TP Configuration File member is used to control this capability for JES Explorer. The format and options of the SYSLOG statement are detailed in Workbench for Eclipse—CSS TP Parameters.

Controlling viewing access of the system log involves security profile rules, which may already exist on your system. Access to viewing may simply be a matter of using those rules for the JES Explorer to follow. However, if rules do not exist, they can be created and then specified in the TP Configuration File member.

The SYSLOG statement can be used to direct JES Explorer to follow SDSF rules or IOF rules. In these cases, the same rule (used by either SDSF or IOF) is checked by JES Explorer and viewing rights are permitted (or denied) accordingly.
For example, if you set the SYSLOG statement to use SDSF rules, and SDSF allows User A to view the system log data set, then User A will also be able to view the system log data set through JES Explorer. And conversely, if User A does not have viewing rights in SDSF, then the user will also not have them in JES Explorer. Rules for IOF work similarly.

Whenever an SDSF user attempts to view the system log, SDSF validates the user's access rights against a profile named ISFCMD.ODSP.SYSLOG.JESx, where x is either 2 or 3 (representing either JES2 or JES3 systems) in the SDSF security class. If a user or group has READ access to that profile, SDSF allows viewing rights.   JES Explorer follows this same SDSF rule provided you configured a rule choice of SDSF on the SYSLOG statement. More information about the SDSF profile for system log access can be found in the IBM publication SDSF Operation and Customization (SA22-7670).

Using IOF is similar to using SDSF as described previously, however the IOF profile name must be determined by reviewing your IOF installed settings and referring to the IOF TSO Installation guide, within the Access Control Reference section. Once determined, specify the IOF profile name on the SYSLOG statement in the configuration (along with a rule choice of IOF). Using IOF as the rule also requires specifying the associated security class name, which can be determined by inspecting IOF's A60ACF install settings member.

Both the SDSF and IOF rule choices simply determine whether or not a given user has the right to attempt to access and view the system log.   If the attempt is permitted, then JES gets involved and further checks a user's access authority for the physical system log data set residing on the spool before any system log records are returned. This means that the user or group must also be permitted access via a profile in the JESSPOOL security class. The profile name is defined by IBM to be:

Regardless of the rule choice chosen in the SYSLOG configuration statement, the JESSPOOL profile must allow the user or group to have access before they will be permitted to view the system log. In most cases if a user can view the system log via SDSF or IOF today, then the JESSPOOL profile for system log access is already set properly and does not need to be adjusted.

More information about protecting the system log data set (SYSLOG) can be found in the IBM publication z/OS Security Server RACF Security Administrators guide(SA22-7683), within the Providing Security for JES section. If you are using security software other than RACF should consult the appropriate documentation pertaining to securing JES.

Controlling User Ability to Issue System Commands

The SYSCMD statement in the TP Configuration File member is used to access and permit users to issue system commands from BMC AMI DevX Workbench for Eclipse—including JES commands, MVS operator commands, or any command that could be issued from a z/OS console. The format and options of the SYSCMD statement are detailed in Workbench for Eclips—CSS TP Parameters.

The SYSCMD statement can be used to disable access entirely, such that BMC AMI DevX Workbench for Eclipse users would not be able to issue commands into the system. However, many sites have groups of users authorized to issue limited system commands from a console that you may wish to extend to BMC AMI DevX Workbench for Eclipse.

If command capability is to be permitted, then several choices exist for how you may wish to verify that a given user has the proper authority to issue commands. All of them involve security profiles that may already exist on your system, and permitting commands to be issued by BMC AMI DevX Workbench for Eclipse is simply a matter of specifying which rules you want BMC AMI DevX Workbench for Eclipse to follow. If rules do not currently exist, they can be created and then specified in the TP Configuration File member so that BMC AMI DevX Workbench for Eclipse will follow them.

Many z/OS installations use a TSO-based application, such as SDSF or IOF, to permit issuance of some commands into the system. Both of these applications are capable of validating that a TSO user has permission to issue commands (or not) by checking a security profile. The SYSCMD statement can specify which type of rules BMC AMI DevX Workbench for Eclipse should follow (for example, SDSF, IOF, or system rules). Regardless of what rule type is configured, the rule itself will be checked by BMC AMI DevX Workbench for Eclipse and the command may or may not be issued depending on the result of that check. For example, if you specify on the SYSCMD statement that you want BMC AMI DevX Workbench for Eclipse to follow SDSF rules and SDSF allows User B to issue system commands, then User B will also be able to issue commands using BMC AMI DevX Workbench for Eclipse. If User B does not have command authority rights in SDSF then User B will also not have them in BMC AMI DevX Workbench for Eclipse. Rules for IOF work similarly. The system's rules refer to the operating system validation of a profile in the OPERCMDS class prior to executing the command.

Whenever an SDSF user attempts to issue a system command, SDSF validates the user's access rights against a profile named ISFOPER.SYSTEM in the SDSF security class. If a user or group has READ access to that profile, SDSF allows the command to be issued into the system. BMC AMI DevX Workbench for Eclipse will follow this same SDSF rule if you specify a rule choice of SDSF on the SYSCMD statement in the configuration. More information about the SDSF profile for system commands can be found in the IBM publication SDSF Operation and Customization (SA22-7670).

IOF functions the same way, however the profile name is determined by reviewing your IOF installed settings and referring to the IOF TSO Installation guide within the Access Control Reference section. Once you determine the correct profile, specify the profile name on the SYSCMD statement in the configuration along with a rule choice of IOF. Using IOF as the rule choice also requires that the security class name being used by IOF be specified; this can be determined by inspecting IOF's A60ACF install settings member.

Both the SDSF and IOF rule choices simply determine whether or not a given user has the right to attempt to issue a command into the system. If the attempt is permitted then the operating system gets involved and checks a user's access authority for the specific command submitted. This means that the user or group must also be permitted authority to issue the command via a profile in the OPERCMDS security class. Typical profile names are defined by IBM to be:

subsystem-name.command.[qualifier]

For example:

Regardless of the rule choice chosen in the SYSCMD configuration statement, the OPERCMDS profiles must allow the user or group to have access before the command will be permitted to execute. In most cases if a user can currently issue the command from SDSF or IOF today, then the OPERCMDS profile for command issuance is already set properly and does not need to be adjusted.

It is important to understand that the settings on the SYSCMD configuration statement do not affect the ability of the user to cancel jobs or job output from JES Explorer. The SYSCMD setting only pertains to those commands that a user can physically type in the actual command text and then attempt to have the command issued. Cancel commands issued by JES Explorer are generated internally depending on specific action by the user; the user is not allowed to type the command text or job number for this purpose. Control of JES Explorer cancel commands is controlled by the options described in Using Conditional Access for Canceling Jobs or Purging Output via JES Explorer.

More information about protecting system operator commands can be found in the IBM publication z/OS Security Server RACF Security Administrators guide(SA22-7683), within the Protecting General Resources section, in subsection “Administering the Use of Operator Commands”. If you are using security software other than RACF should consult the appropriate documentation pertaining to securing JES.

CXSS0000 Started-task Procedure Security Considerations

When using the CXSS0000 started-task JCL procedure (used by File-AID/Eclipse, BMC AMI Strobe, and CA-Endevor support for BMC AMI DevX Workbench for Eclipse), the system's security software must be set to allow for the jobname of the CXSS0000 procedure to increment sequentially for each invocation of a new started-task.

Each time a BMC AMI DevX Workbench for Eclipse user initiates a new File-AID session or a CA-Endevor session, a started-task will begin execution. It will be assigned a jobname that corresponds to the task number of the user's session with HCI. For example, CXSS0001, CXSS0002, CXSS0003,…,CXSSnnnn.

Some installations use physical jobnames in their system security settings to place into effect restrictions or authorizations based on these jobnames. As a result, the system security settings must allow for the jobnames of the CXSS0000 started-tasks to range from CXSS0000 - CXSS9999. If your security requirements enforce the use of jobname restrictions, it is suggested that a wild-card arrangement be specified, such as CXSS* in the system security settings to allow for the full range of possible jobnames that could be generated.

When the procedure is started by the HCI, the procedure is assigned to the default security user ID on the system (for example ++++++++ on RACF systems). The default security user ID may not have authority to access the data sets specified in the procedure JCL. Therefore, READ access to these data sets must be provided in order for the procedure to successfully begin execution. The two options available for establishing sufficient access authority are to either:

• Make all of the data sets specified within the CXSS0000 procedure available for READ access by specifying UACC=READ for each data set in the JCL. This includes all data sets in the STEPLIB DD concatenation. This option allows the system default user ID to have READ access to the procedure's data sets so that the procedure can start up and the configuration file can be processed.
• Add the name of the start-up procedure to an STCGRP security class as appropriate for your security software and define all of the data sets specified in the procedure JCL as belonging to the STGGRP with READ access.   This option causes the procedure to start up with the authority of STCGRP and therefore can read and process the procedure's data sets.

Once the procedure successfully begins execution, the initiating user ID (the user ID associated with the Workbench for Eclipse session that caused the procedure to get started) is authenticated and the procedure will execute under the security rules in place for that user ID and not the rules of the default system user ID or STCGRP. Providing READ access to the STEPLIB data set (whether via UACC=READ or STCGRP) does not allow individual users more or less security than they had before.

SSAS Security Considerations

You may wish to add the name of the start-up procedure to the STCGRP security class as appropriate for your security software. Otherwise, when the SSAS starts, it uses the default security level on your system. This does not prevent SSAS from normal operation because each user request for services runs under the security rules of that user. However, whether you add the procedure name to STCGRP or not, all the load libraries specified within the procedure must have system-wide read access.

We recommend that the Shared Services load library not be APF-authorized. The SSAS is designed to run without any need for APF-authorization. However, if your installation normally places the Shared Services load library in the system link list, the contents could become APF-authorized when executed from a link list search. In order to ensure that the SSAS runs non-authorized, you should specify the Shared Services load library in the start-up procedure’s STEPLIB DD so that the system link list does not get searched during SSAS start-up. Further, if the Shared Services load library is APF-authorized for other reasons, the SSAS operates correctly.

Cross-LPAR Copy Security Considerations

Cross-LPAR Copy (the Copy To… feature in Topaz) has some extra security considerations.

• If TCP_ACEE parameter is set to USER, any user seeking to use this functionality will need to have a fully defined OMVS segment.  
• If TCP_ACEE parameter is set to HCI, the HCI's OMVS segment will be used for communications and users without an OMVS segment will be able to complete cross-LPAR copies.

Controlling user access to the CSS TP for BMC AMI DevX Workbench for Eclipse connection port

The CSS TP is the entity and programming logic executing inside the HCI address space that services requests on behalf of the BMC AMI DevX Workbench for Eclipse clients for access to z/OS resources. The TP authenticates user access by requiring that the BMC AMI DevX Workbench for Eclipse client user provide a user ID and password which will be validated by the system security software (RACF, ACF2, Top Secret, etc). If authentication is successful, then the user has the same access rights to z/OS resources as he would have if he had logged on to TSO on the same z/OS image.

Some installations may wish to limit access for certain users or groups to the CSS TP even though those users may have TSO access. Installations may have TSO security exits in place that restrict access to TSO or to resources accessible by TSO, and they find that the CSS TP allows too much freedom based on user ID and password authentication alone.

Installations may choose to optionally invoke application level security support within the CSS TP in order to limit which users or groups can access the HCI ports that invoke the CSS TP when a user attempts to connect to the port.

Application level security

System security software can control access to applications by the use of an application name. The application name is a one to eight character name that is determined by the installer or security administrator. The application name is added to the security database as a profile in the APPL security class. A possible suggested name for the application is the TPNAME, for example "CXTP01".

The security administrator then assigns one or more user IDs and/or groups to have READ access to the application name profile.

The application name is correspondingly made known to the CSS TP via the TP Configuration File section, using the APPLICATION statement within the member. This statement allows the CSS TP to know the application name defined to the security software.

When the APPLICATION statement is specified in the TP Configuration File member, the CSS TP will request that the system security software validate that the user ID attempting to sign-on to the port has access to the application name. If the user has access to the application, use of CSS TP services is permitted and the session continues. If the user does not have access, the CSS TP connection with the client is terminated.

If multiple HCIs/ports are in use, a unique application name can be assigned to each port, thereby permitting or restricting access on a port basis and a user ID basis.

If the APPLICATION statement is not specified in the configuration member, then the CSS TP will not make a request to the security software to validate application access and only the user ID/password authentication will be used to determine if the connection is permitted.

Defining application access to your security software

Please consult your installation's appropriate security software administration documentation for additional information on how to set up application security.  For RACF installations, protecting applications is documented in IBM’s z/OS Security Server RACF Security Administrator's guide (SA22-7683), in the section Protecting General Resources and subsection Protecting Applications.

As an example of how to define application access to RACF, the following RACF commands are presented to illustrate what is necessary to configure this level of access. In this example, an application name representing BMC AMI DevX Workbench for Eclipse production users will be created for this purpose. The name chosen in this example is WBPROD. Only users and groups defined to have access to the WBPROD profile will be able to successfully use BMC AMI DevX Workbench for Eclipse to access the HCI port represented by this application name.

If you have not already done so, activate the APPL class:

Create a profile in the APPL class and give users or groups permission to access that application:

In the TP Configuration File section, specify the APPLICATION statement:

Then refresh the TP Configuration File or recycle the HCI to make application security take effect.

HCI security considerations

Top secret users

For users of Top Secret for system security, it requires a new facility to be placed in the Facility Matrix Table. Use the following facility control options:

ACF2 users

The CXSSTC Started Task ID needs to have a GSO definition in the STC table to allow it to start jobs with a dynamic name.

System security for the HCI

For the HCI to properly function, it must be permitted access to the following, regardless of whether it is a started-task or a submitted job:

•  All libraries in the STEPLIB concatenation must be Authorized
•  HCI PARMLIB data set containing HCI Server Activation Facility members

The HCI must be authorized for the following via the MVS system security package:

• To generate SDUMPs. If DMPPFX=SDUMP has been specified (the SDUMP specification is recommended by BMC)
• To output submitted jobs via an internal reader
•  For operator commands with update authority:
•  – START
•  – STOP
•  – CANCEL
•  – MODIFY (if OPCMD=MODIFY has been specified)

Considerations for using AT-TLS

AT-TLS can provide increased security of data transmissions by encrypting transmissions using SSL/TLS. This section serves to identify a few considerations when configuring AT-TLS policy. AT-TLS does not require any changes to HCI or CSS TP. AT-TLS is application transparent, thus BMC AMI DevX Workbench for Eclipse can communicate on AT-TLS secured ports.

Using AT-TLS is optional. If a higher level of data security is required by your installation, then you must configure any AT-TLS policies describing which ports will be secured and specific security information regarding the encryption key.  Configuring AT-TLS policies can be complex and beyond the scope of this space. Full AT-TLS configuration documentation is supplied by IBM.

When a port is secured using AT-TLS, the port should be secured for inbound and outbound connections. While a port secured for inbound-only traffic will operate correctly for BMC AMI DevX Workbench for Eclipse and BMC AMI DevX Workbench for VS Code connections, an outbound definition is also required if you intend to use the Cross-LPAR Copy feature or for Code Debug debugging over secure ports. These mainframe-based features initiate outbound connections to the HCI port; hence, the port should be configured for inbound and outbound.

The following figure shows the policy configuration statements in use on BMC system. Port 46806 is defined as a secure port for both inbound and outbound connections. In addition, some figures of the policy agent configuration utility are shown, which may be of assistance. For full AT-TLS documentation and configuration information, please consult your IBM documentation: z/OS Communications Server IP Configuration Guide (SC31-8775); see the section titled “Application Transparent Transport Layer Security Data Protection”.

Policy configuration statements

CMSC security considerations for zAdviser

For TLSv1.3, you must specify the certificate validation mode [GSK_CERT_VALIDATION_MODE] as ANY. Include the following DD statement in the CMSC PROC and recycle the CMSC task