Note: Before using this information, be sure to read the general information under Notices.
|
This edition applies to IBM®
Rational® Developer for z Systems™ Version
9.5 (program number 5724-T07, or part of program number 5697-CDT)
and to all subsequent releases and modifications until otherwise indicated
in new editions.
Order publications by phone or fax. IBM Software Manufacturing Solutions takes publication orders between 8:30 a.m. and 7:00 p.m. eastern standard time (EST). The phone number is (800) 879-2755. The fax number is (800) 445-9269. Faxes should be sent Attn: Publications, 3rd floor.
You can also order publications through your IBM representative or the IBM branch office serving your locality. Publications are not stocked at the address below.
IBM welcomes your comments. You can send your comments by mail to the following address:
IBM Corporation
Attn: Information Development Department 53NA
Building 501 P.O. Box 12195
Research Triangle Park NC 27709-2195
USA
You can fax your comments to: 1-800-227-5088 (US and Canada)
When you send information to IBM, you grant IBM a nonexclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you.
© Copyright IBM Corporation 2000, 2015
Note to U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
This document gives background information for various configuration tasks of IBM Rational Developer for z Systems itself and other z/OS® components and products (such as WLM and TCP/IP).
The information in this document applies to all IBM Rational Developer for z Systems Version 9.5.1 packages.
For the most up-to-date versions of this document, see the IBM Rational Developer for z Systems Host Configuration Reference Guide (SC27-8578) available at http://www-05.ibm.com/e-business/linkweb/publications/servlet/pbi.wss?CTY=US&FNC=SRX&PBL=SC27-8578.
For the most up-to-date versions of the complete documentation, including installation instructions, white papers, podcasts, and tutorials, see the library page of the IBM Rational Developer for z Systems website (http://www-01.ibm.com/software/sw-library/en_US/products/Z964267S85716U24/).
This document is intended for system programmers configuring and tuning IBM Rational Developer for z Systems Version 9.5.1.
While the actual configuration steps are described in another publication, this publication lists in detail various related subjects, such as tuning, security setup, and more. To use this document, you must be familiar with the z/OS UNIX System Services and MVS™ host systems.
This section summarizes the changes for IBM
Rational Developer for z Systems Version
9.5.1 Host Configuration Reference , SC27-8578-00 (updated
December 2015).
Technical changes or additions to the text and illustrations are indicated by a vertical line to the left of the change.
New information:
Removed information:
In version 9.5.1, the RSE and JES Job Monitor related
functions moved from IBM
Rational Developer for z Systems to
another product, IBM Explorer
for z/OS. This move includes
the related documentation.
This document contains information previously presented
in IBM
Rational Developer for z Systems Version
9.5 Host Configuration Reference , SC14-7290-09..
This document contains information previously presented
in IBM Rational Developer
for System z Version
9.1.1 Host Configuration Reference , SC14-7290-08.
This document contains information previously presented in IBM Rational Developer for System z Version 9.1.1 Host Configuration Reference, SC14-7290-07.
This document contains information previously presented in IBM Rational Developer for System z Version 9.0.1 Host Configuration Reference, SC14-7290-06.
This document contains information previously presented in IBM Rational Developer for System z Version 9.0.1 Host Configuration Reference, SC14-7290-05.
New information:
This document contains information previously presented in IBM Rational Developer for System z Version 8.5.1 Host Configuration Reference, SC14-7290-03.
This document contains information previously presented in IBM Rational Developer for System z Version 8.5 Host Configuration Reference, SC14-7290-02.
This section summarizes the information presented in this document.
The Developer for z Systems host consists of several components that interact to give the client access to the host services and data. Understanding the design of these components can help you make the correct configuration decisions.
Developer for z
Systems
interacts with other host components, which has security implications.
Developer for z Systems uses TCP/IP to provide mainframe access to users on a non-mainframe workstation. It also uses TCP/IP for communication between various components and other products.
Unlike traditional z/OS applications, Developer for z Systems is not a monolithic application that can be identified easily to Workload Manager (WLM). Developer for z Systems consists of several components that interact to give the client access to the host services and data. Some of these services are active in different address spaces, resulting in different WLM classifications.
Developer for z
Systems extends
the z/OS Explorer push-to-client,
or host-based client control, with support for project definitions.
This chapter contains information useful for a CICS Transaction Server administrator.
This section is provided to assist you with some common
problems that you may encounter when setting up Application Transparent
Transport Layer Security (AT-TLS), or during checking or modifying
an existing setup.
The Developer for z Systems host consists of several components that interact to give the client access to the host services and data. Understanding the design of these components can help you make the correct configuration decisions.
Developer for z
Systems builds
on top of IBM Explorer for z/OS . For z/OS Explorer related information, see “Security
consideration” in the IBM Explorer
for z/OS Host Configuration
Reference (SC27-8438).
The description in the previous paragraph and list shows the central role assigned to RSE. With few exceptions, all client communication goes through RSE. This allows for easy security related network setup, as only a limited set of ports are used for client-host communication.
To manage the connections and workloads from the clients,
RSE is composed of a daemon address space, which controls thread pooling
address spaces. The daemon acts as a focal point for connection and
management purposes, while the thread pools process the client workloads.
Based upon the values defined in the rse.env configuration
file, and the amount of actual client connections, multiple thread
pool address spaces can be started by the daemon.
Figure 2 shows
a basic overview of the owner of the security credentials used for
various z/OS Explorer and Developer for z
Systems tasks.
The ownership of a task can be divided into two sections.
Started tasks are owned by the user ID that is assigned to the started
task in your security software. All other tasks, with the RSE thread
pools (RSEDx) as exception, are owned by the client user ID.
Figure 2 shows the z/OS Explorer and Developer for z Systems started tasks (DBGMGR, JMON, and RSED), and sample started tasks and system services that Developer for z Systems communicates with. The USS REXEC tag represents the z/OS UNIX REXEC (or SSH) service.
RSE daemon (RSED) creates one or more RSE thread pool address spaces (RSEDx) to process client requests. Each RSE thread pool supports multiple clients and is owned by the same user as the RSE daemon. Each client has his own threads inside a thread pool, and these threads are owned by the client user ID.
Depending on actions done by the client, one or more additional address spaces can be started, all owned by the client user ID, to perform the requested action. These address spaces can be an MVS batch job, an APPC transaction, or a z/OS UNIX child process. Note that a z/OS UNIX child process is active in a z/OS UNIX initiator (BPXAS), and the child process shows up as a started task in JES.
The creation of these address spaces is most often triggered by a user thread in a thread pool, either directly or by using system services like ISPF. But the address space could also be created by a third party. For example, z/OS UNIX REXEC or SSH are involved when starting builds in z/OS UNIX.
The user-specific address spaces end at task completion or when an inactivity timer expires. The started tasks remain active. The address spaces listed in Figure 2 remain in the system long enough to be visible. However, you should be aware that due to the way z/OS UNIX is designed, there are also several short-lived temporary address spaces.
Developer for z Systems supports multiple methods to start a CARMA server. Each method has benefits and drawbacks. Developer for z Systems also provides multiple Repository Access Managers (RAMs), which can be divided into two groups, production RAMs and sample RAMs. Various combinations of RAMs and server startup methods are available as a preconfigured setup.
All server startup methods share a common configuration file, CRASRV.properties, which (among other things) specifies which startup method will be used.
The "CRASTART" method starts the CARMA server as a subtask within RSE. It provides a very flexible setup by using a separate configuration file that defines data set allocations and program invocations needed to start a CARMA server. This method provides the best performance and uses the fewest resources, but requires that module CRASTART is located in LPA.
RSE invokes load module CRASTART, which uses the definitions in crastart*.conf to create a valid environment to execute batch TSO and ISPF commands. Developer for z Systems uses this environment to run the CARMA server, CRASERV. Developer for z Systems provides multiple crastart*.conf files, each preconfigured for a specific RAM.
The "batch submit" method starts the CARMA server by submitting a job. This is the default method used in the provided sample configuration files. The benefit of this method is that the CARMA logs are easily accessible in the job output. It also allows the use of custom server JCL for each developer, which is maintained by the developer himself. However, this method uses one JES initiator per developer starting a CARMA server.
RSE invokes CLIST CRASUB*, which in turn submits an embedded JCL to create a valid environment to execute batch TSO and ISPF commands. Developer for z Systems uses this environment to run the CARMA server, CRASERV. Developer for z Systems provides multiple CRASUB* members, each preconfigured for a specific RAM.
Figure 5 shows an overview of the z/OS UNIX directories used by Developer for z Systems. The following list describes each directory touched by Developer for z Systems, how the location can be changed, and who maintains the data within.
Developer for z
Systems extends z/OS Explorer by providing additional
functions, some of which interact with other system components and
products, such as a Software Configuration Manager (SCM). Developer for z
Systems specific
security definitions are used to secure the provided functions.
The security mechanisms used by Developer for z Systems servers and services rely on the data sets and file systems it resides in being secure. This implies that only trusted system administrators should be able to update the program libraries and configuration files.
Developer for z
Systems builds
on top of IBM Explorer for z/OS . For z/OS Explorer related information, see “Security
consideration” in the IBM Explorer
for z/OS Host Configuration
Reference (SC27-8438).
The following topics are covered in this chapter:
CARMA authentication
Client authentication is done by RSE daemon as part of the client's connection request. CARMA is started from a user specific thread, and inherits the user’s security environment, bypassing the need for additional authentication.
SCLM Developer Toolkit authentication
Client authentication is done by RSE daemon as part of the client's connection request. SCLMDT is started from a user specific thread, and inherits the user’s security environment, bypassing the need for additional authentication.
Client authentication is done by RSE daemon as part of the client's connection
request. After the user is authenticated, self-generated PassTickets are used for all future
authentication requests, including the automatic logon to Debug Manager.
In order for Debug Manager to validate the user ID and PassTicket presented by RSE, Debug Manager must be allowed to evaluate the PassTicket. This implies that load module AQEZPCM, by default located in load library FEL.SFEKAUTH, must be APF-authorized.
When a client-based Debug Engine connects to the Debug Manager, it must present a valid security token for authentication.
Most communication between Developer for z Systems client and host goes through RSE, thus utilizing the connection security provided by z/OS Explorer.
TTLSRule RDz_Debug_Manager
{
LocalPortRange 5335
Direction Inbound
TTLSGroupActionRef grp_Production
TTLSEnvironmentActionRef RDz_Debug_Manager
}
TTLSEnvironmentAction RDz_Debug_Manager
{
HandshakeRole Server
TTLSKeyRingParms
{
Keyring dbgmgr.racf # Keyring must be owned by the Debug Manager
}
}
TTLSGroupAction grp_Production
{
TTLSEnabled On
Trace 2
}
The optional Integrated Debugger requires that users have sufficient access permits to specified security profiles. If the user does not have the required permit, the debug session will not start.
Developer for z Systems verifies access to the profiles listed in Table 1 to determine which debug permits are granted.
FACILITY profile | Required access | Result |
---|---|---|
AQE.AUTHDEBUG.STDPGM | READ | User is able to debug problem-state applications |
AQE.AUTHDEBUG.AUTHPGM | READ | User is able to debug problem-state and authorized applications |
RDEFINE FACILITY (AQE.AUTHDEBUG.STDPGM) -
UACC(NONE) DATA('RATIONAL DEVELOPER FOR Z SYSTEMS – DEBUG PROBLEM-STATE')
PERMIT AQE.AUTHDEBUG.STDPGM CLASS(FACILITY) -
ID(RDZDEBUG) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
The optional Integrated Debugger is capable of debugging CICS transactions. See CICS transaction debugging for more details.
The SCLM Developer Toolkit service offers optional security functionality for the Build, Promote, and Deploy functions.
If security is enabled for a function by the SCLM administrator, SAF calls are made to verify authority to execute the protected function with the caller’s or a surrogate user ID.
Refer to SCLM Developer Toolkit Administrator’s Guide (SC23-9801), for more information on the required SCLM security definitions.
Customize and submit the sample FELRACF job,
which has sample RACF® commands
to create the basic security definitions for Developer for z
Systems.
Customize and submit the sample AQERACF job, which has sample RACF commands to create the security
definitions for Integrated Debugger.
FELRACF and AQERACF are is located in FEL.#CUST.JCL,
unless you specified a different location when you customized and
submitted the FEL.SFELSAMP(FELSETUP) job. See
"Customization setup" in the Rational
Developer for z Systems Host
Configuration Guide for more details.
See the RACF Command Language Reference (SA22–7687), for more information about RACF commands.
Description |
|
Value |
---|---|---|
Developer for z Systems product high-level qualifier |
|
|
Developer for z Systems customization high-level qualifier |
|
|
Integrated Debugger started task name |
|
Attention: Some products, such as FTP, require being program controlled if "WHEN PROGRAM" is active. Test this program control before activating it on a production system. |
A RACF OMVS segment or equivalent that specifies a valid non-zero z/OS UNIX user ID (UID), home directory, and shell command must be defined for each user of Developer for z Systems. Their default group also requires an OMVS segment with a group ID.
When using the optional Integrated Debugger, the user ID under which the application being debugged is active, and its default group also requires a valid RACF OMVS segment or equivalent.
In the following sample RACF commands, replace the #userid, #user-identifier, #group-name, and #group-identifier placeholders with actual values:
ALTUSER #userid
OMVS(UID(#user-identifier) HOME(/u/#userid) PROGRAM(/bin/sh) NOASSIZEMAX)
The following sample RACF commands
create the DBGMGR started task, with protected user
ID (STCDBM) and the STCGROUP group
assigned to it.
ADDGROUP STCGROUP OMVS(AUTOGID)
DATA('GROUP WITH OMVS SEGMENT FOR STARTED TASKS')
ADDUSER STCDBM DFLTGRP(STCGROUP) NOPASSWORD NAME('DEBUG MANAGER')
OMVS(AUTOUID HOME(/tmp) PROGRAM(/bin/sh) )
DATA('Rational Developer for z Systems')
RDEFINE STARTED DBGMGR.* DATA('DEBUG MANAGER')
STDATA(USER(STCDBM) GROUP(STCGROUP) TRUSTED(NO))
Integrated Debugger requires UPDATE access to the BPX.SERVER profile
to create or delete the security environment for the debug thread.
Note that using UID(0) to bypass this requirement
is not supported. This permit is only required when the optional Integrated
Debugger feature is used.
Attention: Defining the BPX.SERVER profile
makes z/OS UNIX as a whole switch from UNIX level security to z/OS UNIX level
security, which is more secure. This switch might impact other z/OS UNIX applications
and operations. Test the security before activating it on a production
system. For more information about the different security levels,
see UNIX System Services
Planning (GA22-7800).
|
Servers with authority to BPX.SERVER must
run in a clean, program-controlled environment. This requirement implies
that all programs called by Debug Manager must also be program controlled.
For MVS load libraries, program
control is managed by your security software.
The following additional prerequisite libraries must
be made program controlled to support the use of optional services.
This list does not include data sets that are specific to a product
that Developer for z
Systems interacts with, such as IBM Explorer for z/OS.
The client's password or other means of identification, such as an X.509 certificate is used only to verify the identity upon connection. Afterward, PassTickets are used to maintain thread security. This step is required for clients to be able to connect.
RDEFINE PTKTDATA FEKAPPL UACC(NONE) SSIGNON(KEYMASKED(key16))
APPLDATA('NO REPLAY PROTECTION – DO NOT CHANGE')
DATA('RATIONAL DEVELOPER FOR Z SYSTEMS')
RDEFINE PTKTDATA IRRPTAUTH.FEKAPPL.* UACC(NONE)
DATA('RATIONAL DEVELOPER FOR Z SYSTEMS')
PERMIT IRRPTAUTH.FEKAPPL.* CLASS(PTKTDATA) ACCESS(UPDATE) ID(STCRSE)
SETROPTS RACLIST(PTKTDATA) REFRESH
RSE supports the using of an application ID other than FEKAPPL. Uncomment and customize the "APPLID=FEKAPPL" option in rdz.env to activate this, as documented in "Defining extra Java startup parameters with _RSE_JAVAOPTS" in the IBM Rational Developer for z Systems Host Configuration Guide. The PTKTDATA class definitions must match the actual application ID used by RSE.
Attention: The client connection
request fails if PassTickets are not set up correctly.
|
The MODIFY LOGS operator command uses the RSED started task user ID to collect host logs and setup information. And by default, user log files are created with secure file access permissions (only owner has access). To be able to collect secure user log files, the RSED started task user ID must be permitted to read them.
The OWNER argument of the MODIFY LOGS operator command results in the specified user ID becoming the owner of the collected data. In order to change ownership, the RSED started task user ID must be permitted to use the CHOWN z/OS UNIX service.
Note that when the SUPERUSER.FILESYS.ACLOVERRIDE profile is defined, access permissions defined in ACL (access Control List) take precedence over the permissions granted through SUPERUSER.FILESYS. The RSED started task user ID will need READ access permit to the SUPERUSER.FILESYS.ACLOVERRIDE profile to bypass ACL definitions.
During client logon, RSE daemon verifies that a user is allowed to use the application.
RDEFINE APPL FEKAPPL UACC(READ) DATA('RATIONAL DEVELOPER FOR Z SYSTEMS')
SETROPTS RACLIST(APPL) REFRESH
Servers with authority to BPX.SERVER must run in a clean, program-controlled environment. This requirement implies that all programs called by RSE must also be program controlled. For z/OS UNIX files, program control is managed by the extattr command. To execute this command, you need READ access to BPX.FILEATTR.PROGCTL in the FACILITY class, or be UID(0).
$ ls -Eog /usr/lib/libIRRRacf*.so
-rwxr-xr-x aps- 2 69632 Oct 5 2007 /usr/lib/libIRRRacf.so
-rwxr-xr-x aps- 2 69632 Oct 5 2007 /usr/lib/libIRRRacf64.so
JES Job Monitor issues all JES operator commands requested by a user through an extended MCS (EMCS) console, whose name is controlled with the CONSOLE_NAME directive, as documented in "FEJJCNFG, JES Job Monitor configuration file" in the Rational Developer for z Systems Host Configuration Guide.
RDEFINE OPERCMDS MVS.MCSOPER.#console UACC(READ)
DATA('RATIONAL DEVELOPER FOR Z SYSTEMS')
RDEFINE OPERCMDS JES%.** UACC(NONE)
PERMIT JES%.** CLASS(OPERCMDS) ACCESS(UPDATE) WHEN(CONSOLE(JMON)) ID(*)
SETROPTS RACLIST(OPERCMDS) REFRESH
Attention: Defining JES commands
with universal access NONE in your security software
might impact other applications and operations. Test the security
before activating it on a production system.
|
Table 3 and Table 4 show the operator commands issued for JES2 and JES3, and the discrete security profiles that can be used to protect them.
Action | Command | OPERCMDS profile | Required access |
---|---|---|---|
Hold | $Hx(jobid) with x = {J, S or T} |
|
UPDATE |
Release | $Ax(jobid) with x = {J, S or T} |
|
UPDATE |
Cancel | $Cx(jobid) with x = {J, S or T} |
|
UPDATE |
Purge | $Cx(jobid),P with x = {J, S or T} |
|
UPDATE |
Action | Command | OPERCMDS profile | Required access |
---|---|---|---|
Hold | *F,J=jobid,H |
|
UPDATE |
Release | *F,J=jobid,R |
|
UPDATE |
Cancel | *F,J=jobid,C |
|
UPDATE |
Purge | *F,J=jobid,C |
|
UPDATE |
Assuming the identity of the JES Job Monitor server by creating a JMON console from a TSO session is prevented by your security software. Even though the console can be created, the point of entry is different; for example, JES Job Monitor versus TSO. JES commands issued from this console will fail the security check if your security is set up as documented in this publication and the user does not have authority to the JES commands through other means.
Users require READ access to one of the listed AQE.AUTHDEBUG.* profiles to be able to use the Integrated Debugger for debugging problem-state programs. Users permitted to the AQE.AUTHDEBUG.AUTHPGM profile are also allowed to debug APF authorized programs. Replace the #apf placeholder with valid user IDs or RACF group names for those users that are allowed to debug authorized programs.
RDEFINE FACILITY AQE.AUTHDEBUG.STDPGM UACC(NONE)
PERMIT AQE.AUTHDEBUG.STDPGM CLASS(FACILITY) ACCESS(READ) ID(*)
RDEFINE FACILITY AQE.AUTHDEBUG.AUTHPGM UACC(NONE)
PERMIT AQE.AUTHDEBUG.AUTHPGM CLASS(FACILITY) ACCESS(READ) ID(#apf)
SETROPTS RACLIST(FACILITY) REFRESH
READ access for users and ALTER for system programmers is sufficient for most Developer for z Systems data sets. Replace the #sysprog placeholder with valid user IDs or RACF group names. Also, ask the system programmer who installed and configured the product for the correct data set names. FEK is the default high-level qualifier used during installation and FEL.#CUST is the default high-level qualifier for data sets created during the customization process.
ADDGROUP (FEL) OWNER(IBMUSER) SUPGROUP(SYS1)
DATA('IBM Rational Developer for z Systems - HLQ STUB')
ADDSD 'FEL.*.**' UACC(READ)
DATA('IBM Rational Developer for z Systems')
PERMIT 'FEL.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEL.#CUST.LSTRANS.*.**' UACC(UPDATE)
DATA('IBM Rational Developer for z Systems - SCLMDT')
PERMIT 'FEL.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEL.#CUST.CRA*.**' UACC(READ)
DATA('IBM Rational Developer for z Systems - CARMA')
PERMIT 'FEL.#CUST.CRA*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEL.#CUST.CRA*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#ram-developer)
SETROPTS GENERIC(DATASET) REFRESH
Use the following sample commands to display the results of your security-related customizations.
Developer for z Systems uses TCP/IP to provide mainframe access to users on a non-mainframe workstation. It also uses TCP/IP for communication between various components and other products.
Developer for z
Systems builds
on top of IBM Explorer for z/OS . For z/OS Explorer related information, see “TCP/IP
considerations” in the IBM Explorer
for z/OS Host Configuration
Reference (SC27-8438).
Figure 7 shows
the TCP/IP ports that can be used by z/OS Explorer
and Developer for z
Systems.
The arrows show which party does the bind (arrowhead side) and which
one connects.
If you use the PORT or PORTRANGE statement
in PROFILE.TCPIP to reserve the ports used by z/OS Explorer and Developer for z
Systems,
note that many binds are done by threads active in an RSE thread pool.
The job name of the RSE thread pool is RSEDx, where RSED is
the name of the RSE started task, and x is a random
single digit number, so wildcards are required in the definition.
PORT 4035 TCP RSED ; z/OS Explorer – RSE daemon
PORT 6715 TCP JMON ; z/OS Explorer – JES job monitor
PORT 5335 TCP DBGMGR ; Developer for z Systems – Integrated debugger
PORT 5336 TCP DBGMGR ; Developer for x Systems – Integrated debugger
PORTRange 8108 11 TCP RSED* ; z/OS Explorer – RSE_PORTRANGE
;PORTRange 5227 100 TCP RSED* ; Developer for z Systems - CARMA
CARMA (Common Access Repository Manager) is used to access a host-based Software Configuration Manager (SCM), for example CA Endevor® SCM. In most cases, like for RSE daemon, a server binds to a port and listens for connection requests. CARMA however uses a different approach, as the CARMA server is not active yet when the client initiates the connection request.
When the client sends a connection request, the CARMA miner, which is active as a user thread in an RSE thread pool, will request an ephemeral port or find a free port in the range specified in the CRASRV.properties configuration file and binds to it. The miner then starts the CARMA server and passes the port number, so that the server knows to which port to connect. When the server is connected, the client can send requests to the server and receive the results.
From a TCP/IP perspective, RSE (by way of the CARMA miner) is the server that binds to the port, and the CARMA server is the client connecting to it.
If you use the PORT or PORTRANGE statement in PROFILE.TCPIP to reserve the port range used by CARMA, note that the CARMA miner is active in an RSE thread pool. The jobname of the RSE thread pool is RSEDx, where RSED is the name of the RSE started task and x is a random single digit number, so wildcards are required in the definition.
PORTRange 5227 100 RSED* ; DEVELOPER FOR Z SYSTEMS - CARMA
CARMA (Common Access Repository Manager) is used to access a host-based Software Configuration Manager (SCM), for example CA Endevor® SCM. To do so, CARMA starts a user-specific server, which needs additional configuration to enforce stack affinity.
Similar to the z/OS Explorer
and Developer for z
Systems started
tasks, stack affinity for a CARMA server is set with the _BPXK_SETIBMOPT_TRANSPORT variable,
which must be passed on to LE (Language Environment). This
can be done by adjusting the startup command in the active crastart*.conf or CRASUB* configuration
file.
... PARM(&CRAPRM1. &CRAPRM2.)
... PARM(ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP") / &CRAPRM1. &CRAPRM2.)
... PARM(&PORT &TIMEOUT)
... PARM(ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP") / &PORT &TIMEOUT)
Unlike traditional z/OS applications, Rational Developer for z Systems is not a monolithic application that can be identified easily to Workload Manager (WLM). Developer for z Systems consists of several components that interact to give the client access to the host services and data. As described in Understanding Developer for z Systems, some of these services are active in different address spaces, resulting in different WLM classifications.
Developer for z
Systems builds
on top of IBM Explorer for z/OS . For z/OS Explorer related information, see “WLM
considerations” in the IBM Explorer
for z/OS Host Configuration
Reference (SC27-8438).
Figure 8 shows
a basic overview of the subsystems through which z/OS Explorer and Developer for z
Systems workloads
are presented to WLM.
RSE daemon (RSED), Debug Manager (DBGMGR) and
JES Job Monitor (JMON) are z/OS Explorer
and Developer for z
Systems started
tasks (or long-running batch jobs), each with their individual address
space.
RSE daemon spawns a child process for each RSE thread
pool server (which supports a variable number of clients). Each thread
pool is active in a separate address space (using a z/OS UNIX initiator,
BPXAS). Because these are spawned processes, they are classified using
the WLM OMVS classification rules, not the started task classification
rules.
The clients that are active in a thread pool can create a multitude of other address spaces, depending on the actions done by the users. Depending on the configuration of Developer for z Systems, some workloads, such as the TSO Commands service (TSO cmd) or CARMA, can run in different subsystems.
The address spaces listed in Figure 8 remain in the system long enough to be visible, but you should be aware that due to the way z/OS UNIX is designed, there are also several short-lived temporary address spaces. These temporary address spaces are active in the OMVS subsystem.
Note that while the RSE thread pools use the same user ID and a similar job name as the RSE daemon, all address spaces started by a thread pool are owned by the user ID of the client requesting the action. The client user ID is also used as (part of) the job name for all OMVS-based address spaces stated by the thread pool.
More address spaces are created by other services that Developer for z
Systems uses,
such as z/OS UNIX REXEC (USS build).
WLM uses classification rules to map work coming into the system to a service class. This classification is based upon work qualifiers. The first (mandatory) qualifier is the subsystem type that receives the work request. Table 5 lists the subsystem types that can receive Developer for z Systems workloads.
Subsystem type | Work description |
---|---|
ASCH | The work requests include all APPC transaction programs scheduled by the IBM-supplied APPC/MVS transaction scheduler, ASCH. |
JES | The work requests include all jobs that JES2 or JES3 initiates. |
OMVS | The work requests include work processed in z/OS UNIX System Services forked children address spaces. |
STC | The work requests include all work initiated by the START and MOUNT commands. STC also includes system component address spaces. |
Table 6 lists additional qualifiers that can be used to assign a workload to a specific service class. Refer to MVS Planning: Workload Management (SA22-7602) for more details on the listed work qualifiers.
ASCH | JES | OMVS | STC | ||
---|---|---|---|---|---|
AI | Accounting Information | x | x | x | x |
LU | LU Name (*) | ||||
PF | Perform (*) | x | x | ||
PRI | Priority | x | |||
SE | Scheduling Environment Name | x | |||
SSC | Subsystem Collection Name | x | |||
SI | Subsystem Instance (*) | x | |||
SPM | Subsystem Parameter | x | |||
PX | Sysplex Name | x | x | x | x |
SY | System Name (*) | x | x | x | |
TC | Transaction/Job Class (*) | x | x | ||
TN | Transaction/Job Name (*) | x | x | x | x |
UI | User ID (*) | x | x | x | x |
As documented in Workload classification, Developer for z Systems creates different types of workloads on your system. These different tasks communicate with each other, which implies that the actual elapse time becomes important to avoid time-out issues for the connections between the tasks. As a result, Developer for z Systems tasks should be placed in high-performance service classes, or in moderate-performance service classes with a high priority.
A revision, and possibly an update, of your current WLM goals is therefore advised. This is especially true for traditional MVS shops new to time-critical OMVS workloads.
Table 7 lists the address spaces that are used by z/OS Explorer and Developer for z Systems. z/OS UNIX will substitute "x" in the "Task Name" column by a random 1-digit number.
Description | Task name | Workload |
---|---|---|
Debug Manager | DBGMGR | STC |
(z/OS Explorer) JES Job Monitor | JMON | STC |
(z/OS Explorer) RSE daemon | RSED | STC |
(z/OS Explorer) RSE thread pool | RSEDx | OMVS |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
<userid>x | OMVS |
(z/OS Explorer) TSO Commands service (APPC) | FEKFRSRV | ASCH |
CARMA (batch) | CRA<port> | JES |
CARMA (crastart) | <userid>x | OMVS |
CARMA (ISPF Client Gateway) | <userid> and <userid>x | OMVS |
MVS build (batch job) | * | JES |
z/OS UNIX build (shell commands) | <userid>x | OMVS |
z/OS UNIX shell | <userid> | OMVS |
All Developer for z
Systems started
tasks are servicing real-time client requests.
Description | Task name | Workload |
---|---|---|
Debug Manager | DBGMGR | STC |
Debug Manager provides services to connect programs being debugged to clients debugging them. You should specify a high-performance, one-period velocity goal, because the task does not report individual transactions to WLM. Resource usage depends heavily on user actions, and will therefore fluctuate, but is expected to be minimal.
All workloads use the client user ID as base for the
address space name. (z/OS UNIX will substitute "x" in the
"Task Name" column by a random 1-digit number.)
The workloads will all end up in the same service class
due to a common address space naming convention. You should specify
a multi-period goal for this service class. The first periods should
be high-performance, percentile response time goals, while the last
period should have a moderate-performance velocity goal. Some workloads,
such as the ISPF Client Gateway, will report individual transactions
to WLM, while others do not.
Description | Task name | Workload |
---|---|---|
![]() ![]() |
<userid>x | OMVS |
CARMA (crastart) | <userid>x | OMVS |
CARMA (ISPF Client Gateway) | <userid> and <userid>x | OMVS |
z/OS UNIX build (shell commands) | <userid>x | OMVS |
z/OS UNIX shell | <userid> | OMVS |
The Legacy ISPF Gateway
is an ISPF service invoked by Developer for z
Systems to
execute non-interactive TSO and ISPF commands. This includes explicit
commands issued by the client as well as implicit commands issued
by the SCLMDT component of Developer for z
Systems.
Resource usage depends heavily on user actions, and will therefore
fluctuate, but is expected to be minimal.
CARMA is an optional Developer for z Systems server that is used to interact with host based Software Configuration Managers (SCMs), such as CA Endevor® SCM. Developer for z Systems allows for different startup methods for a CARMA server, some of which become an OMVS workload. Resource usage depends heavily on user actions, and will therefore fluctuate, but is expected to be minimal.
When a client initiates a build for a z/OS UNIX project, z/OS UNIX REXEC (or SSH) will start a task that executes a number of z/OS UNIX shell commands to perform the build. Resource usage depends heavily on user actions, and will therefore fluctuate, but is expected to be moderate to substantial, depending on the size of the project.
This workload processes z/OS UNIX shell commands that are issued by the client. Resource usage depends heavily on user actions, and will therefore fluctuate, but is expected to be minimal.
JES-managed batch processes are used in various manners by Developer for z Systems. The most common usage is for MVS builds, where a job is submitted and monitored to determine when it ends. But Developer for z Systems could also start a CARMA server in batch, and communicate with it using TCP/IP.
Description | Task name | Workload |
---|---|---|
CARMA (batch) | CRA<port> | JES |
MVS build (batch job) | * | JES |
CARMA is a Developer for z Systems server that is used to interact with host based Software Configuration Managers (SCMs), such as CA Endevor® SCM. Developer for z Systems allows for different startup methods for a CARMA server, some of which become a JES workload. You should specify a high-performance, one-period velocity goal, because the task does not report individual transactions to WLM. Resource usage depends heavily on user actions, and will therefore fluctuate, but is expected to be minimal.
Developer for z
Systems builds
on top of IBM Explorer for z/OS . For z/OS Explorer related information, see “Push-to-client
considerations” in the IBM Explorer
for z/OS Host Configuration
Reference (SC27-8438).
Developer for z
Systems clients
can pull client configuration files and product update information
from the host when they connect, ensuring that all clients have common
settings and that they are up-to-date.
The client administrator can create multiple client configuration
sets and multiple client update scenarios to fit the needs of different
developer groups. This allows users to receive a customized setup,
based on criteria like membership of an LDAP group or permit to a
security profile.
z/OS Projects can be defined individually through the z/OS Projects perspective on the client, or z/OS Projects can be defined centrally on the host and propagated to the client on an individual user basis. These "host-based projects" look and function exactly like projects defined on the client except that their structure, members, and properties cannot be modified by the client, and they are accessible only when connected to the host.
A development project manager defines a project and assigns individual developers to it.
See the Developer for z Systems IBM Knowledge Center for details about how the development project manager can perform the tasks assigned to them.
z/OS Projects can be defined individually through the z/OS Projects perspective on the client, or z/OS Projects can be defined centrally on the host and propagated to the client on an individual user basis. These "host-based projects" look and function exactly like projects defined on the client except that their structure, members, and properties cannot be modified by the client, and they are only accessible when connected to the host.
The base directory for host-based projects is defined (by the client administrator) in /var/rdz/pushtoclient/keymapping.xml, and is /var/rdz/pushtoclient/projects by default.
Host-based projects are also eligible to participate
in the multiple group setup . This eligibility means that host-based
projects can be defined also in /var/rdz/pushtoclient/grouping/<devgroup>/projects/.
When a workspace is bound to a specific group, and there are project definitions for a user in this group and in the default group, the user receives the project definitions from both the default and the specific group.
This chapter groups references to Developer for z
Systems components
that can work inside CICSTS regions.
For more information on Bidirectional language support, see the section "CICS bidirectional language support" in chapter "Other customization tasks" of the Rational Developer for z Systems Host Configuration Guide (SC27-8577).
For more information on diagnostic IRZ messages for Enterprise Service Tools, see the section "Diagnostic IRZ messages for Enterprise Service Tools" in chapter "Other customization tasks" of the Rational Developer for z Systems Host Configuration Guide (SC27-8577).
For more information on CICS transaction
debugging, see the section "Integrated Debugger CICS updates" in chapter "(Optional) Integrated
Debugger" of the IBM
Rational Developer for z Systems Host
Configuration Guide (SC23-7658).
This section is provided to assist you with some common problems that you may encounter when setting up Application Transparent Transport Layer Security (AT-TLS), or during checking or modifying an existing setup.
The Transport Layer Security (TLS) protocol defined in RFC 2246 provides communications privacy over the Internet. Similar to its predecessor Secure Socket Layer (SSL), the protocol enables client and server applications to communicate in a way that is designed to prevent eavesdropping, tampering, and message forgery. Application Transparent Transport Layer Security (AT-TLS) consolidates TLS implementation for z/OS-based applications in one location, allowing all applications to support TLS-based encryption without knowledge of the TLS protocol. See Communications Server IP Configuration Guide (SC31-8775) for more information on AT-TLS.
The Integrated Debugger in Developer for z Systems relies on AT-TLS for encrypted communication with the client, because the data for the debug session does not flow through the same pipe as other Developer for z Systems client-host communication.
The actions needed to set up AT-TLS will vary from site to site, depending on the exact needs, and depending on what is already available at the site.
Some tasks described in the following sections expect you to be active in z/OS UNIX. This can be done by issuing the TSO command OMVS. Use the oedit command to edit files in z/OS UNIX. Use the exit command to return to TSO.
The TCP/IP documentation recommends writing Policy Agent messages to the z/OS UNIX syslog instead of using the default log file. AT-TLS will always write messages to the z/OS UNIX syslog.
In order to do so, the z/OS UNIX syslog daemon, syslogd, must be configured and active. You will also need a mechanism to control the size of the log files created by syslogd.
syslog 514/udp
# /etc/syslog.conf - control output of syslogd
# 1. all files with will be printed to /tmp/syslog.auth.log
auth.* /tmp/syslog.auth.log
# 2. all error messages printed to /tmp/syslog.error.log
*.err /tmp/syslog.error.log
# 3. all debug and above messages printed to /tmp/syslog.debug.log
*.debug /tmp/syslog.debug.log
# The files named must exist before the syslog daemon is started,
# unless -c startup option is used
# Start the SYSLOGD daemon for logging
# (clean up old logs)
sed -n '/^#/!s/.* \(.*\)/\1/p' /etc/syslog.conf | xargs -i rm {}
# (create new logs and add userid of message sender)
_BPX_JOBNAME='SYSLOGD' /usr/sbin/syslogd -cuf /etc/syslog.conf &
sleep 5
AT-TLS support is activated by the TTLS parameter on the TCPCONFIG statement in the PROFILE.TCPIP data set. AT-TLS is managed by the Policy Agent, which must be active to be able to enforce the AT-TLS policy. Since the Policy Agent must wait for TCP/IP to be active, the AUTOSTART statement in PROFILE.TCPIP is a good place to trigger startup of this server.
TCPCONFIG TTLS ; Required for AT-TLS
AUTOLOG
PAGENT ; POLICY AGENT, required for AT-TLS
ENDAUTOLOG
//PAGENT PROC PRM='-L SYSLOGD' * '' or '-L SYSLOGD'
//*
//* TCP/IP POLICY AGENT
//* (PARM) (envar)
//* default cfg file: /etc/pagent.conf (-C) (PAGENT_CONFIG_FILE)
//* default log file: /tmp/pagent.log (-L) (PAGENT_LOG_FILE)
//* default log size: 300,3 (3x 300KB files) (PAGENT_LOG_FILE_CONTROL)
//*
//PAGENT EXEC PGM=PAGENT,REGION=0M,TIME=NOLIMIT,
// PARM='ENVAR("TZ=EST5DST")/&PRM'
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//*
#
# TCP/IP Policy Agent configuration information.
#
TTLSConfig /etc/pagent.ttls.conf
# Specifies the path of a TTLS policy file holding stack specific
# statements.
#
#TcpImage TCPIP /etc/pagent.conf
# If no TcpImage statement is specified, all policies will be installed
# to the default TCP/IP stack.
#
#LogLevel 31
# The sum of the following values that represent log levels:
# LOGL_SYSERR 1
# LOGL_OBJERR 2
# LOGL_PROTERR 4
# LOGL_WARNING 8
# LOGL_EVENT 16
# LOGL_ACTION 32
# LOGL_INFO 64
# LOGL_ACNTING 128
# LOGL_TRACE 256
# Log Level 31 is the default log loglevel.
#
#Codepage IBM-1047
# Specify the EBCDIC code page to be used for reading all configuration
# files and policy definition files. IBM-1047 is the default code page.
This sample configuration file specifies where the Policy Agent can find the TTLS policy. It uses Policy Agent default values for other statements.
A TTLS policy describes the desired AT-TLS rules. As defined in the Policy Agent configuration file, the TTLS policy is located in /etc/pagent.ttls.conf. The necessary definitions in your security software are covered later.
##
## TCP/IP Policy Agent AT-TLS configuration information.
##
##-----------------------------
TTLSRule RDz_Debug_Manager
{
LocalPortRange 5335
Direction Inbound
TTLSGroupActionRef grp_Production
TTLSEnvironmentActionRef act_RDz_Debug_Manager
}
##-----------------------------
TTLSEnvironmentAction act_RDz_Debug_Manager
{
HandshakeRole Server
TTLSKeyRingParms
{
Keyring dbgmgr.racf # Keyring must be owned by the Debug Manager
}
TTLSEnvironmentAdvancedParms
{
## TLSV1.2 only for z/OS 2.1 and higher
# TLSV1.2 On # TLSv1 & TLSv1.1 are on by default
SSLV3 Off # disable SSLv3
}
}
##-----------------------------
TTLSRule RDz_Debug_Probe-Client
{
RemotePortRange 8001
Direction Outbound
TTLSGroupActionRef grp_Production
TTLSEnvironmentActionRef act_RDz_Debug_Probe-Client
}
##-----------------------------
TTLSEnvironmentAction act_RDz_Debug_Probe-Client
{
HandshakeRole Client
TTLSKeyRingParms
{
Keyring *AUTH*/* # virtual key ring holding CA certificates
}
TTLSEnvironmentAdvancedParms
{
## TLSV1.2 only for z/OS 2.1 and higher
# TLSV1.2 On # TLSv1 & TLSv1.1 are on by default
}
}
##-----------------------------
TTLSGroupAction grp_Production
{
TTLSEnabled On
## TLSv1.2zOS1.13 only for z/OS 1.13
TTLSGroupAdvancedParmsRef TLSv1.2zOS1.13
Trace 3 # Log Errors to syslogd & IP joblog
#Trace 254 # Log everything to syslogd
}
##-----------------------------
TTLSGroupAdvancedParms TLSv1.2zOS1.13
{
Envfile /etc/pagent.ttls.TLS1.2zOS1.13.env
}
A TTLS policy allows for a wide range of filters to specify when a rule applies.
The Debug Manager is a server that listens on port 5335 for incoming connections from the Debug Engine. This information is captured in the RDz_Debug_Manager rule.
Since encrypted communication requires the usage of a server certificate, you specify that the Policy Manager must use the certificates on the dbgmgr.racf key ring, which is owned by the Debug Manager started task user ID. By default, TLS v1.2 support is disabled, so this policy explicitly enables it. SSLv3.0 is explicitly disabled due to known vulnerabilities in this protocol.
When the Debug Probe is started with Language Environment (LE) option TEST(,,,TCPIP&&ipaddress%8001:*), it is instructed to not use the Debug Manager but contact the Developer for z Systems client directly at port 8001. This implies, from a TCP/IP perspective, that the host-based Debug Probe is a client contacting a server (the Debug UI) in the Developer for z Systems client. This information is captured in the RDz_Debug_Probe-Client rule.
With the host being a TCP/IP client, the Policy Manager will need a way to validate the server certificate presented by the Debug UI. Instead of using a uniformly named key ring for all users that might require an encrypted debug session, we are using RACF’s CERTAUTH virtual key ring (*AUTH*/*). This virtual key ring holds the public certificates of Certificate Authorities (CAs), and can be used if the Debug UI presents a server certificate that is signed by one of the trusted CAs.
Note that for more complex policies, you should use the IBM Configuration Assistant for z/OS Communications Server. This is a GUI-based tool that provides a guided interface for configuring TCP/IP policy-based networking functions and is available as a task in IBM z/OS Management Facility (z/OSMF), and as a stand-alone workstation application.
TLS v1.2 support became available in z/OS 2.1, and is disabled by default. This policy shows the command (TLSV1.2 On) to explicitly enable it, but has it commented out as the target system is using z/OS 1.13.
#
# Add TLSv1.2 support to AT-TLS
# requires z/OS 1.13 with OA39422 and PM62905
#
GSK_RENEGOTIATION=ALL
GSK_PROTOCOL_TLSV1_2=ON
There are several updates required to your security setup for AT-TLS to work properly. This section has sample RACF commands to do the required setup.
# define started task user ID
# BPX.DAEMON permit is required for non-zero UID
ADDUSER PAGENT DFLTGRP(SYS1) OMVS(UID(0) SHARED HOME('/')) +
NAME('TCP/IP POLICY AGENT') NOPASSWORD
# define started task
RDEFINE STARTED PAGENT.* STDATA(USER(PAGENT) GROUP(SYS1)) +
DATA('TCP/IP POLICY AGENT')
# refresh to make the changes visible
SETROPTS RACLIST(STARTED) REFRESH
# restrict startup of policy agent
RDEFINE OPERCMDS MVS.SERVMGR.PAGENT UACC(NONE) +
DATA('restrict startup of policy agent')
PERMIT MVS.SERVMGR.PAGENT CLASS(OPERCMDS) ACCESS(CONTROL) ID(PAGENT)
# refresh to make the changes visible
SETROPTS RACLIST(OPERCMDS) REFRESH
# block stack access between stack and AT-TLS availability
# SETROPTS GENERIC(SERVAUTH)
# SETROPTS CLASSACT(SERVAUTH) RACLIST(FACILITY)
RDEFINE SERVAUTH EZB.INITSTACK.** UACC(NONE)
# Policy Agent
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(PAGENT)
# OMPROUTE daemon
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(OMPROUTE)
# SNMP agent and subagents
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(OSNMPD)
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(IOBSNMP)
# NAME daemon
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(NAMED)
# refresh to make the changes visible
SETROPTS RACLIST(SERVAUTH) REFRESH
# restrict access to pasearch command
# RDEFINE SERVAUTH EZB.PAGENT.** UACC(NONE) +
# DATA('restrict access to pasearch command')
# PERMIT EZB.PAGENT.** CLASS(SERVAUTH) ACCESS(READ) ID(tcpadmin)
# refresh to make the changes visible
# SETROPTS RACLIST(SERVAUTH) REFRESH
# permit Debug Manager to access certificates
#RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)
#RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ACCESS(READ) ID(stcdbm)
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(stcdbm)
# refresh to make the changes visible
SETROPTS RACLIST(FACILITY) REFRESH
# create self-signed certificate
RACDCERT ID(stcdbm) GENCERT SUBJECTSDN(CN('RDz Debug Manager') +
OU('RTP labs') O('IBM') L('Raleigh') SP('NC') C('US')) +
NOTAFTER(DATE(2015-12-31)) KEYUSAGE(HANDSHAKE) WITHLABEL('dbgmgr')
# (optional) additional steps required to use a signed certificate
# 1. create a signing request for the self-signed certificate
RACDCERT ID(stcdbm) GENREQ (LABEL('dbgmgr')) DSN(dsn)
# 2. send the signing request to your CA of choice
# 3. check if the CA credentials (also a certificate) are already known
RACDCERT CERTAUTH LIST
# 4. mark the CA certificate as trusted
RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
# or add the CA certificate to the database
RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
# 5. add the signed certificate to the database;
# this will replace the self-signed one
RACDCERT ID(stcdbm) ADD(dsn) WTIHLABEL('dbgmgr') TRUST
# Do NOT delete the self-signed certificate before replacing it.
# If you do, you lose the private key that goes with the certificate,
# which makes the certificate useless.
# create key ring
RACDCERT ID(stcdbm) ADDRING(dbgmgr.racf)
# add certificate to key ring
RACDCERT ID(stcbm) CONNECT(LABEL('dbgmgr') +
RING(dbgmgr.racf) USAGE(PERSONAL) DEFAULT)
# additional step required to use a signed certificate
# 6. add CA certificate to key ring
RACDCERT ID(stcdbm) CONNECT(CERTAUTH LABEL('CA cert') +
RING(dbgmgr.racf))
# refresh to make the changes visible
SETROPTS RACLIST(DIGTCERT) REFRESH
# check if the CA credentials (also a certificate) are already known
RACDCERT CERTAUTH LIST
# mark the CA certificate as trusted
RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
# or add the CA certificate to the database
RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
# refresh to make the changes visible
SETROPTS RACLIST(DIGTCERT) REFRESH
# verify started task setup
LISTGRP SYS1 OMVS
LISTUSER PAGENT OMVS
RLIST STARTED PAGENT.* ALL STDATA
# verify Policy Agent startup permission
RLIST OPERCMDS MVS.SERVMGR.PAGENT ALL
# verify initstack protection
RLIST SERVAUTH EZB.INITSTACK.** ALL
# verify pasearch protection
RLIST SERVAUTH EZB.PAGENT.** ALL
# verify certificate setup
RACDCERT CERTAUTH LIST(LABEL('CA cert'))
RACDCERT ID(stcdbm) LIST(LABEL('dbgmgr'))
RACDCERT ID(stcdbm) LISTRING(dbgmgr.racf)
TCPCONFIG TTLS
V TCPIP,,OBEY,TCPIP.TCPPARMS(OBEY)
EZZ4249I stackname INSTALLED TTLS POLICY HAS NO RULES
S PAGENT
EZD1586I PAGENT HAS INSTALLED ALL LOCAL POLICIES FOR stackname
P DBGMGR
S DBBMGR
The following publications are referenced in this document:
Publication title | Order number | Reference | Reference Web site |
---|---|---|---|
Program Directory for IBM Rational Developer for z Systems | GI11-8298 | Developer for z Systems | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Program Directory for IBM Rational Developer for z Systems Host Utilities | GI13-2864 | Developer for z Systems | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for z Systems Host Configuration Guide | SC27-8577 | Developer for z Systems | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for z Systems Host Configuration Reference | SC27-8578 | Developer for z Systems | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for z Systems Common Access Repository Manager Developer's Guide | SC23-7660 | Developer for z Systems | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
SCLM Developer Toolkit Administrator's Guide | SC23-9801 | Developer for z Systems | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Explorer for z/OS Host Configuration Guide | SC27-8437 | z/OS Explorer | |
IBM Explorer for z/OS Host Configuration Reference | SC27-8438 | z/OS Explorer | |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
Communications Server IP Configuration Guide | SC31-8775 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Configuration Reference | SC31-8776 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Guide | SA22-7591 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Initialization and Tuning Reference | SA22-7592 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS JCL Reference | SA22-7597 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS Planning Workload Management | SA22-7602 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS System Commands | SA22-7627 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Command Language Reference | SA22-7687 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF Security Administrator's Guide | SA22-7683 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Command Reference | SA22-7802 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services Planning | GA22-7800 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services User's Guide | SA22-7801 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Using REXX and z/OS UNIX System Services | SA22-7806 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Description | Reference Web site |
---|---|
Developer for z Systems IBM Knowledge Center | http://www-01.ibm.com/support/knowledgecenter/SSQ2R2/rdz_welcome.html |
Developer for z Systems Library | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Developer for z Systems home page | http://www-03.ibm.com/software/products/en/developerforsystemz/ |
Developer for z Systems Recommended service | http://www-01.ibm.com/support/docview.wss?rs=2294&context=SS2QJ2&uid=swg27006335 |
Developer for z Systems enhancement request | https://www.ibm.com/developerworks/support/rational/rfe/ |
Download Apache Ant | http://ant.apache.org/ |
Publication title | Order number | Reference | Reference website |
---|---|---|---|
ABCs of z/OS System Programming Volume 9 (z/OS UNIX) | SG24-6989 | Redbook | http://www.redbooks.ibm.com/ |
System Programmer’s Guide to: Workload Manager | SG24-6472 | Redbook | http://www.redbooks.ibm.com/ |
TCPIP Implementation Volume 1: Base Functions, Connectivity, and Routing | SG24-7532 | Redbook | http://www.redbooks.ibm.com/ |
TCPIP Implementation Volume 3: High Availability, Scalability, and Performance | SG24-7534 | Redbook | http://www.redbooks.ibm.com/ |
TCP/IP Implementation Volume 4: Security and Policy-Based Networking | SG24-7535 | Redbook | http://www.redbooks.ibm.com/ |
Tivoli® Directory Server for z/OS | SG24-7849 | Redbook | http://www.redbooks.ibm.com/ |
This information was developed for products and services offered in the US. This material might be available from IBM in other languages. However, you may be required to own a copy of the product or product version in that language in order to access it.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM Director of Licensing
IBM Corporation
North Castle Drive, MD-NC119
Armonk, NY 10504-1785
US
Intellectual Property Licensing
Legal and Intellectual Property Law
IBM Japan Ltd.
19-21, Nihonbashi-Hakozakicho, Chuo-ku
Tokyo 103-8510, Japan
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some jurisdictions do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.
Any references in this information to non-IBM websites are provided for convenience only and do not in any manner serve as an endorsement of those websites. The materials at those websites are not part of the materials for this IBM product and use of those websites is at your own risk.
IBM may use or distribute any of the information you provide in any way it believes appropriate without incurring any obligation to you.
IBM Director of Licensing
IBM Corporation
North Castle Drive, MD-NC119
Armonk, NY 10504-1785
US
Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.
The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us.
The performance data and client examples cited are presented for illustrative purposes only. Actual performance results may vary depending on specific configurations and operating conditions.
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBMproducts. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
Statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only.
This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to actual people or business enterprises is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. The sample programs are provided "AS IS", without warranty of any kind. IBM shall not be liable for any damages arising out of your use of the sample programs.
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the web at "Copyright and trademark information" at www.ibm.com/legal/copytrade.shtml.
Permissions for the use of these publications are granted subject to the following terms and conditions.
These terms and conditions are in addition to any terms of use for the IBM website.
You may reproduce these publications for your personal, noncommercial use provided that all proprietary notices are preserved. You may not distribute, display or make derivative work of these publications, or any portion thereof, without the express consent of IBM.
You may reproduce, distribute and display these publications solely within your enterprise provided that all proprietary notices are preserved. You may not make derivative works of these publications, or reproduce, distribute or display these publications or any portion thereof outside your enterprise, without the express consent of IBM.
Except as expressly granted in this permission, no other permissions, licenses or rights are granted, either express or implied, to the publications or any information, data, software or other intellectual property contained therein.
IBM reserves the right to withdraw the permissions granted herein whenever, in its discretion, the use of the publications is detrimental to its interest or, as determined by IBM, the above instructions are not being properly followed.
You may not download, export or re-export this information except in full compliance with all applicable laws and regulations, including all United States export laws and regulations.
IBM MAKES NO GUARANTEE ABOUT THE CONTENT OF THESE PUBLICATIONS. THE PUBLICATIONS ARE PROVIDED "AS-IS" AND WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE.
This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. The sample programs are provided "AS IS", without warranty of any kind. IBM shall not be liable for any damages arising out of your use of the sample programs.
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at www.ibm.com/legal/copytrade.shtml.
Adobe and PostScript are trademarks of Adobe Systems Incorporated.
Cell Broadband Engine - Sony Computer Entertainment Inc.
Rational is a trademark of International Business Machines Corporation and Rational Software Corporation, in the United States, other countries, or both.
Intel, Intel Centrino, Intel SpeedStep, Intel Xeon, Celeron, Itanium, and Pentium are trademarks of Intel Corporation in the United States, or other countries, or both.
IT Infrastructure Library is a trademark of Central Computer and Telecommunications Agency
ITIL is a trademark of The Minister for the Cabinet Office
Linear Tape-Open, LTO, and Ultrium are trademarks of HP, IBM Corp., and Quantum
Linux is a trademark of Linus Torvalds
Microsoft, Windows, and the Windows logo are trademarks or registered trademarks of Microsoft Corporation in the United States, or other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
UNIX is a registered trademark of The Open Group in the United States and other countries.