JVM server profile options

How options apply to different uses of a JVM server

The following table indicates whether an option is required, optional, or not supported for a particular use of a JVM server.

Axis2

Deprecated feature: Support for the JVMSERVER-based configuration option for the web services data transformation service is deprecated. The deprecated options can be replaced with the use of non-Java pipeline for CICS web services, z/OS Connect Enterprise Edition, or by writing web applications in Java or Node.js. For more details, see Stabilization notices.

JVM server options and descriptions

_DFH_UMASK={007|number}

Sets the z/OS UNIX System Services process UMASK that applies when JVMSERVER files are created. This value is a three digit octal. For example, the default value of 007 allows the intended read/write/execute permissions of owner and group to be respected, while preventing read/write/execute being given to other when a file is created. The supplied value must fall within the range of 000 (least restrictive) to 777 (most restrictive). UMASK applies for the lifetime of the JVM.

For security, it is best practice to allocate z/OS user IDs to groups. Permissions can be applied at a group level, rather than on an individual basis.

CICS_WLP_MODE={INTEGRATED|STANDARD}

For a Liberty JVM server, choose the level of integration between CICS and Liberty.

Specify the INTEGRATED mode to use CICS integrated-mode Liberty. The Liberty JVM server runs with CICS enabled threads, respects CICS security, integrates with a CICS unit of work, and makes the Java™ class library for CICS (JCICS) API available for your Java web applications. If this option is omitted or not valid, the default of INTEGRATED is used.

Specify the STANDARD mode to use CICS standard-mode Liberty. The Liberty JVM server runs in a mode that is more standard to all Liberty supported platforms. This mode allows you to port and deploy your Liberty applications from other platforms to CICS without change. The JVM server retains control of the Liberty server and manages the server creation, lifecycle, and configuration. However, threads are not CICS enabled by default and do not run within a CICS transaction context. CICS unit of work integration, CICS security integration, and the JCICS API are not directly available from your Java application.

CLASSPATH_PREFIX, CLASSPATH_SUFFIX=classpathnames

Use these options to specify directory paths, Java archive files, and compressed files to be searched by a JVM that is not OSGi enabled. For example, it is used for Java web services. Do not set a class path if you want to use an OSGi framework because the OSGi framework handles the class loading for you. If you use these options to specify the standard class path for Axis2, you must also specify JAVA_PIPELINE=TRUE to start the Axis2 engine.

CLASSPATH_PREFIX adds class path entries to the beginning of the standard class path, and CLASSPATH_SUFFIX adds them to the end of the standard class path. You can specify entries on separate lines by using a \ (backslash) at the end of each line that is to be continued.

Use the CLASSPATH_PREFIX option with care. Classes in CLASSPATH_PREFIX take precedence over classes of the same name that are supplied by CICS and the Java run time and the wrong classes might be loaded.

CICS builds a base class path for a JVM by using the /lib subdirectories of the directories that are specified by the USSHOME system initialization parameter and the JAVA_HOME option in the JVM profile. This base class path contains the Java archive files that are supplied by CICS and by the JVM. It is not visible in the JVM profile. You do not specify these files again in the class paths in the JVM profile.

Use a colon (:) not a comma to separate multiple items that you specify by using the CLASSPATH_PREFIX or CLASSPATH_SUFFIX options.

DIAGS_ARCHIVE_DIR=pathname

Specifies where the diagnostics archive tar file is stored when the the PERFORM JVMSERVER (jvmserver-name) JVM GATHER DIAGNOSTICS command completes. See Using the PERFORM JVMSERVER SPI to gather JVM diagnostics. The default is ${WORKDIR}/diagnostics/archives.

DIAGS_TEMP_DIR=pathname

Specifies where the diagnostics archive tar file is initially created and where trace information is stored as the PERFORM JVMSERVER (jvmserver-name) JVM GATHER DIAGNOSTICS command runs. See Using the PERFORM JVMSERVER SPI to gather JVM diagnostics. The default is /tmp.

DISPLAY_JAVA_VERSION={TRUE|FALSE}

If this option is set to TRUE, when a JVM is started by an application, CICS writes message DFHSJ0901 to the MSGUSER log, showing the version and build of the IBM Software Developer Kit for z/OS, Java Technology Edition that is in use.

IDENTITY_PREFIX={TRUE|FALSE}

To establish the origin of JVM server output, all STDOUT, and STDERR entries that are routed to JES are written with a prefix string of the JVM server name, which is useful if multiple JVM servers are sharing a JES destination. This behavior can be disabled by setting IDENTITY_PREFIX=FALSE, which disables use of the prefix string.

JAF_REGISTRATION={TRUE|FALSE}

6.2 This option is obsolete. CICS automatically adds the Jakarta Activation Framework (JAF) capability into the JVM server run-time, as necessary. Before Java 11, this technology was included as part of the JRE.

6.1 Specifies that the Jakarta Activation framework (JAF) registration JAR files are automatically added to the JVM runtime environment to support the usage of JAF by Java applications. This option is ignored for Liberty JVM servers. It is possible to opt out of the automatic addition of these files by setting JAF_REGISTRATION=FALSE. If this function is not required, opting out can prevent potential clashes with newer JAR files, can keep the JVM footprint smaller, and avoids unnecessary class loading. Before Java 11, this technology is included as part of the JRE.

JAVA_DUMP_TDUMP_PATTERN=

A z/OS UNIX System Services environment variable that specifies the file name pattern to be used for transaction dumps (TDUMPs) from the JVM. In the event of a JVM abend, Java TDUMPs are written to a data set destination.

JAVA_HOME=/usr/lpp/java/javadir/

Specifies the installation location for IBM® 64-bit SDK for z/OS®, Java Technology Edition or IBM Semeru Runtime Certified Edition for z/OS in z/OS UNIX. This location contains subdirectories and Java archive files that are required for Java support.

The supplied sample JVM profiles contain a path that was generated by the JAVADIR parameter in the DFHISTAR CICS installation job. The default for the JAVADIR parameter is java/J8.0_64/, which is the default installation location for the IBM 64-bit SDK for z/OS, Java Technology Edition. This value produces a JAVA_HOME setting in the JVM profiles of /usr/lpp/java/J8.0_64/.

For more information, see Setting the version of the Java runtime.

JAVA_PIPELINE={TRUE|FALSE}

Adds the required Java archive files to the class path so that a JVM server can support web services processing in Java standard SOAP pipelines. The default value is FALSE. If you set this value, the JVM server is configured to support Axis2 instead of OSGi. You can add more JAR files to the class path by using the CLASSPATH options.

Note: The options JAVA_PIPELINE=TRUE and SECURITY_TOKEN_SERVICE=TRUE are not compatible.

Deprecated feature: Support for the JVMSERVER-based configuration option for the web services data transformation service is deprecated. The deprecated options can be replaced with the use of non-Java pipeline for CICS web services, z/OS Connect Enterprise Edition, or by writing web applications in Java or Node.js. For more details, see Stabilization notices.

JAXB_REGISTRATION={TRUE|FALSE}

6.2 This option is obsolete. CICS automatically adds the Jakarta XML Binding API (JAXB) capability into the JVM server run-time, as necessary. Before Java 11, this technology was included as part of the JRE.

6.1 Specifies that the Jakarta XML Binding API (JAXB) registration JAR files are automatically added to the JVM runtime environment to support the usage of JAXB by Java applications. This option is ignored for Liberty JVM servers. It is possible to opt out of the automatic addition of these files by setting JAXB_REGISTRATION=FALSE. If this function is not required, opting out can prevent potential clashes with newer JAR files, can keep the JVM footprint smaller, and avoids unnecessary class loading. Before Java 11, this technology is included as part of the JRE.

JNDI_REGISTRATION={TRUE|FALSE}

Specifies that the JNDI registration JAR files are automatically added to the JVM runtime environment to support the usage of the JNDI by Java applications. This option is ignored for Liberty JVM servers. It is possible to opt out of the automatic addition of these files by setting JNDI_REGISTRATION=FALSE. If this function is not required, opting out can prevent potential clashes with newer JAR files, can keep the JVM footprint smaller, and avoids unnecessary class loading.

JVMLOG={{&APPLID;.&JVMSERVER;.}Dyyyymmdd.Thhmmss.dfhjvmlog|filename|JOBLOG|//DD:data_definition}

Specifies the name of the z/OS UNIX file or JES DD to which JVM server logging is written during operation of a JVM server. If you do not set a value for this option, CICS automatically creates unique log files for each JVM server.

If JVMLOG is left to default or is a relative file name, the output location depends on the LOG_PATH_COMPATIBILITY option. If LOG_PATH_COMPATIBILITY=FALSE, the files are placed in the WORK_DIR/applid/jvmserver directory. If LOG_PATH_COMPATIBILITY=TRUE, the files are placed in the WORK_DIR directory.

If an absolute file name is specified for JVMLOG, CICS creates any directories within the path that do not exist.

If the file exists, output is appended to the end of the file. To create unique output files for each JVM server, use the JVMSERVER and APPLID symbols in your file name, as demonstrated in the sample JVM profiles. If JVMLOG is left to default, CICS uses the APPLID and JVMSERVER symbols, and the date and timestamp when the JVM server started to create unique output files.

To route to a JES DD, specify the data definition name from JES by using the syntax //DD:data_definition.

If this option is set to JOBLOG, JVMLOG is routed to the current stdout location.

JVMTRACE={{&APPLID;.&JVMSERVER;.}Dyyyymmdd.Thhmmss.dfhjvmtrc|file_name|JOBLOG|//DD:data_definition}

Specifies the name of the z/OS UNIX file or JES DD to which JVM server tracing is written during operation of a JVM server. If you do not set a value for this option, CICS automatically creates unique trace files for each JVM server.

If JVMTRACE is left to default or is a relative file name, the output location depends on the LOG_PATH_COMPATIBILITY option. If LOG_PATH_COMPATIBILITY=FALSE, the files are placed in the WORK_DIR/applid/jvmserver directory. If LOG_PATH_COMPATIBILITY=TRUE, the files are placed in the WORK_DIR directory.

If an absolute file name is specified for JVMTRACE, CICS creates any directories within the path that do not exist.

If the file exists, output is appended to the end of the file. To create unique output files for each JVM server, use the JVMSERVER and APPLID symbols in your file name, as demonstrated in the sample JVM profiles. If JVMTRACE is left to default, CICS uses the APPLID and JVMSERVER symbols, and the date and timestamp when the JVM server started to create unique output files.

To route to a JES DD, specify the data definition name from JES by using the syntax //DD:data_definition.

If this option is set to JOBLOG, JVMTRACE is routed to the current stdout location.

LIBERTY_INCLUDE_XML=filenames

Specifies a file or a comma-separated list of files to be added to the server.xml as <include> elements.

Use the + character before a variable to append a comma and the value that is specified to the existing value of that variable. For example:

LIBERTY_INCLUDE_XML=/path/file1
+LIBERTY_INCLUDE_XML=/path/file2

This is the equivalent to:

LIBERTY_INCLUDE_XML=/path/file1,/path/file2

LIBERTY_PRODUCT_EXTENSIONS=name;location

Allows installation of your own product extension into a Liberty server.

The name is a unique name for the product extension. It is used also as the feature prefix. The location is the absolute location of the directory on zFS where the product extension is located and maintained.

You can add multiple product extensions by using a comma to separate them. Alternatively, you can use an append syntax.

LIBERTY_PRODUCT_EXTENSIONS=product1;/u/product1, product2;/u/product2

OR

LIBERTY_PRODUCT_EXTENSIONS=product1;/u/product1
+LIBERTY_PRODUCT_EXTENSIONS=product2;/u/product2

Warning: Do not name your product extension cicsts because it clashes with core JVM server support and gives unpredictable results.

Do not name your product extension usr because Liberty looks for the extensions in the ${wlp.usr.dir}/extension directory instead of your own directory.

LIBPATH_PREFIX, LIBPATH_SUFFIX=pathnames

Specifies directory paths to be searched for native C dynamic link library (DLL) files that are used by the JVM, and that have the extension .so in z/OS UNIX. This includes files that are required to run the JVM and extra native libraries that are loaded by application code or services.

The base library path for the JVM is built automatically by using the directories that are specified by the USSHOME system initialization parameter and the JAVA_HOME option in the JVM profile. The base library path is not visible in the JVM profile. It includes all the DLL files that are required to run the JVM and the native libraries that are used by CICS.

You can extend the library path by using the LIBPATH_SUFFIX option. This option adds directories to the end of the library path after the base library path. Use this option to specify directories that contain any additional native libraries that are used by your applications. Also, use this option to specify directories that are used by any services that are not included in the standard JVM setup for CICS. For example, the additional native libraries might include the DLL files that are required to use the Db2® JDBC drivers.

The LIBPATH_PREFIX option adds directories to the beginning of the library path before the base library path. Use this option with care. If DLL files in the specified directories have the same name as DLL files on the base library path, they are loaded instead of the supplied files.

Use a colon (:) not a comma to separate multiple items that you specify by using the LIBPATH_PREFIX or LIBPATH_SUFFIX option.

DLL files that are on the library path for use by your applications must be compiled and linked with the XPLink option. Compiling and linking with the XPLink option provides optimum performance. The DLL files that are supplied on the base library path and the DLL files that are used by services such as the Db2 JDBC drivers are built with the XPLink option.

LOG_FILES_MAX={0|number}

Specifies the number of old log files that are kept on the system. A default setting of 0 ensures that all old versions of the log file are retained. You can change this value to specify how many old log files you want to remain on the file system.

If LOG_PATH_COMPATIBILITY=TRUE, LOG_FILES_MAX is ignored.

If STDOUT, STDERR, JVMLOG, and JVMTRACE use the default scheme, or if customized,they include the &DATE;.&TIME; pattern, then only the newest number of each log type is kept on the system. If your customization does not include any variables, which make the output unique, then the files are appended to, and there is no requirement for deletion. The clean-up does not apply if the output variables are customized to route output to DD:// or JOBLOG. Special value 0 means do not delete.

LOG_LEVEL={INFO|WARNING|ERROR|NONE}

Provides control over the logged information that is returned in the dfhjvmlog file. A value of NONE suppresses all output and the file is empty. Any other value indicates the lowest log type that is written to the dfhjvmlog file. For example, selecting WARNING gives log entries of WARNING level and above.

LOG_PATH_COMPATIBILITY={TRUE|FALSE}

The default value is LOG_PATH_COMPATIBILITY=FALSE which provides a consolidated log output. This places the JVMSERVER log files in the same output directory structure that is used by existing subcomponents of the JVMSERVER; for example, the OSGi framework, and the Liberty server. To revert to behavior from previous releases, set the parameter to LOG_PATH_COMPATIBILITY=TRUE and the JVMSERVER log directories are created in the original location.

OSGI_BUNDLES=pathnames

Specifies the directory path for middleware bundles that are enabled in the OSGi framework of an OSGi JVM server. These OSGi bundles contain classes to implement system functions in the framework, such as connecting to IBM MQ or Db2. To specify more than one OSGi bundle, use commas to separate them.

OSGI_CONSOLE={TRUE|FALSE}

Adds the required OSGi bundles to the OSGi framework to enable the OSGi console. You must also set the following properties in the JVM profile: -Dosgi.console=host:port and -Dosgi.file.encoding={ISO-8859-1|US-ASCII|ASCII}. The default value is FALSE. If you want to look at the state of OSGi bundles and services, see Troubleshooting Java applications.

OSGI_FRAMEWORK_TIMEOUT={60|number}

Specifies the number of seconds that CICS waits for the OSGi framework to initialize or shut down before it times out. You can set a value in the range 1 - 60000 seconds. The default value is 60 seconds. If the OSGi framework takes longer to start than the specified number of seconds, the JVM server fails to initialize and CICS issues DFHSJ0215 message. Error messages are written to the JVM server log files in zFS. If the OSGi framework takes longer to shut down than the specified number of seconds, the JVM server fails to shut down normally.

PRINT_JVM_OPTIONS={TRUE|FALSE}

If this option is set to TRUE, when a JVM starts the options that are passed to the JVM at start are also printed to SYSPRINT. The output is produced every time a JVM starts with this option in its profile. You can use this option to check the contents of the class paths for a particular JVM profile, including the base library path and the base class path that are built by CICS, which are not visible in the JVM profile.

PRINT_PROFILE={TRUE|FALSE}

If this option is set to TRUE, the options, system properties, and environment variables from the profile that are passed to the JVM server and application are output to SYSPRINT.

PURGE_ESCALATION_TIMEOUT={15|time}

Specifies the interval in seconds between the disable actions that CICS performs when a JVM server encounters a TCB failure or a runaway task. After each timeout, CICS escalates to the next disable action (for example, from phaseout to purge), until the JVM server has been recycled.

CICS performs the following steps in sequence:

1. CICS disables the JVMSERVER resource with the PHASEOUT option to allow existing work in the JVM to complete where possible and prevent new work from using the JVM.
2. If the PHASEOUT operation fails to disable the JVMSERVER within the interval specified by the PURGE_ESCALATION_TIMEOUT JVM server option, CICS escalates to the next disable action PURGE until the JVMSERVER is disabled.

   For a Liberty JVM server, there is a minimum of 60-second timeout from phaseout to purge.

3. If the PURGE operation fails to disable the JVMSERVER within the interval, CICS escalates to the next disable action FORCEPURGE.
4. If the FORCEPURGE operation fails to disable the JVMSERVER within the interval, CICS escalates to KILL.
5. After the JVMSERVER is successfully disabled, message DFHSJ1008 is issued.
6. CICS attempts to re-enable the resource to create a new JVM.

SCRIPT_TIMEOUT_SECS={300|number}

Specifies the number of seconds the PERFORM JVMSERVER (jvmserver-name) JVM GATHER DIAGNOSTICS command is permitted to run before it is considered to have malfunctioned, after which execution is abandoned. See Using the PERFORM JVMSERVER SPI to gather JVM diagnostics.The default is 300 seconds.

SECURITY_TOKEN_SERVICE={TRUE|FALSE}

If this option is set to TRUE, the JVM server can use security tokens. If this option is set to FALSE, Security Token Service support is disabled for the JVM server.

Note: The options SECURITY_TOKEN_SERVICE=TRUE and JAVA_PIPELINE=TRUE are not compatible.

STDERR={{&APPLID;.&JVMSERVER;.}Dyyyymmdd.Thhmmss.dfhjvmerr|filename|JOBLOG|//DD:data_definition}

Specifies the name of the z/OS UNIX file or JES DD to which the stderr stream is redirected. If you do not set a value for this option, CICS automatically creates unique trace files for each JVM server.

If STDERR is left to default or is a relative file name, the output location depends on the LOG_PATH_COMPATIBILITY option. If LOG_PATH_COMPATIBILITY=FALSE, the files are placed in the WORK_DIR/applid/jvmserver directory. If LOG_PATH_COMPATIBILITY=TRUE, the files are placed in the WORK_DIR directory.

If an absolute file name is specified for STDERR, CICS creates any directories within the path that do not exist.

If the file exists, output is appended to the end of the file. To create unique output files for each JVM server, use the JVMSERVER and APPLID symbols in your file name, as demonstrated in the sample JVM profiles. If STDERR is left to default, CICS uses the APPLID and JVMSERVER symbols, and the date and timestamp when the JVM server started to create unique output files.

To route to a JES DD, specify the data definition name from JES by using the syntax //DD:data_definition.

If this option is set to JOBLOG, STDERR is routed to SYSOUT if defined, or to a dynamic SYSnnn if not.

If you specify the USEROUTPUTCLASS option on a JVM profile, the Java class that is named on that option handles the System.err requests instead. The z/OS UNIX file that is named by the STDERR option might still be used if the class named by the USEROUTPUTCLASS option cannot write data to its intended destination; for example, when you use the supplied sample class com.ibm.cics.samples.SJMergedStream. You can also use the file if output is directed to it for any other reason by a class that is named by the USEROUTPUTCLASS option.

STDIN=filename

Specifies the name of the z/OS UNIX file from which the stdin stream is read. CICS does not create this file unless you specify a value for this option.

STDOUT={{&APPLID;.&JVMSERVER;.}Dyyyymmdd.Thhmmss.dfhjvmout|filename|JOBLOG|//DD:data_definition}

Specifies the name of the z/OS UNIX file or JES DD to which the stdout stream is redirected. If you do not set a value for this option, CICS automatically creates unique trace files for each JVM server.

If STDOUT is left to default or is a relative file name, the output location depends on the LOG_PATH_COMPATIBILITY option. If LOG_PATH_COMPATIBILITY=FALSE, the files are placed in the WORK_DIR/applid/jvmserver directory. If LOG_PATH_COMPATIBILITY=TRUE, the files are placed in the WORK_DIR directory.

If an absolute file name is specified for STDOUT, CICS creates any directories within the path that do not exist.

If the file exists, output is appended to the end of the file. To create unique output files for each JVM server, use the JVMSERVER and APPLID symbols in your file name, as demonstrated in the sample JVM profiles. If STDOUT is left to default, CICS uses the APPLID and JVMSERVER symbols, and the date and timestamp when the JVM server started to create unique output files.

To route to a JES DD, specify the data definition name from JES by using the syntax //DD:data_definition.

If this option is set to JOBLOG, STDOUT is routed to SYSPRINT if defined, or to a dynamic SYSnnn if not.

If you specify the USEROUTPUTCLASS option on a JVM profile, the Java class that is named on that option handles the System.out requests instead. The z/OS UNIX file that is named by the STDOUT option might still be used if the class named by the USEROUTPUTCLASS option cannot write data to its intended destination; for example when you use the supplied sample class com.ibm.cics.samples.SJMergedStream. You can also use the file if output is directed to it for any other reason by a class that is named by the USEROUTPUTCLASS option.

TERMINATION_TIMEOUT={300|number}

Specifies the number of seconds that CICS waits for the LE enclave to shut down when a JVM server is disabled before it times out. The default value is 300 seconds. If the LE enclave takes longer to shutdown than the specified number of seconds, CICS issues DFHSJ0212 and continues terminating the JVM.

USEROUTPUTCLASS=classname

Specifies the fully qualified name of a Java class that intercepts the output from the JVM and messages from JVM internals. You can use this Java class to redirect the output and messages from your JVMs, and you can add timestamps and headers to the output records. This is not supported for Liberty. If the Java class cannot write data to its intended destination, the files that are named in the STDOUT and STDERR options might still be used.

Specifying the USEROUTPUTCLASS option has a negative effect on the performance of JVMs. For best performance in a production environment, do not use this option. However, this option can be useful to application developers who are using the same CICS region because the JVM output can be directed to an identifiable destination.

For more information about this class and the supplied samples, see Controlling the location for JVM output, logs, dumps and trace.

WLP_INSTALL_DIR={&USSHOME;/wlp|directory_path}

Specifies the Liberty installation directory. The default location for Liberty is the z/OS UNIX home directory for CICS in a subdirectory called wlp. The default installation directory is /usr/lpp/cicsts/cicstsnn/wlp, where nn reflects the release of CICS TS: for example, /usr/lpp/cicsts/cicsts62/wlp in CICS® TS 6.2.

To set the correct file path you can either:

• Use the &USSHOME; symbol to set the default file path and append the wlp directory.
• Specify the installation directory of an alternative Liberty version. This configuration is sometimes referenced as "Bring Your Own Liberty" or BYOL In this case, CICS verifies the level of Liberty requested by:
  • Enforcing a minimum version of Liberty. If you attempt to launch a version of Liberty that is below the minimum level that CICS supports, an exception is thrown and the Liberty JVM server does not start. The exception message - written to JVMLOG and STDERR - indicates the version of Liberty being launched and the minimum version accepted: Liberty version XX.X.X.X not supported. Minimum version is YY.Y.Y.Y.
  • Issuing a warning if the version of Liberty being launched is greater than the maximum version of Liberty supported by CICS. The warning is written to JVMLOG and Liberty continues to launch. This might happen if CICS does not yet offer support for this level of Liberty or if you have not applied the companion CICS service APAR. If you encounter this warning, it is prudent to confine your use of such versions to test, prototype, or development systems.
  The minimum and maximum supported Liberty versions are reassessed regularly and are changed, if appropriate, by the quarterly CICS Liberty fixpack APAR.

In addition to the &USSHOME; environment variable, you can also supply other environment variables and system properties to configure the Liberty JVM server. The environment variables are prefixed with WLP, and the system properties are described in JVM system properties.

WLP_LINK_TIMEOUT={30000|number}

Specifies the number of milliseconds that CICS waits to dispatch a request to invoke an application in the Liberty JVM server before it times out. If you specify 0, CICS waits indefinitely. The default value is 30000 milliseconds. If the task has no been dispatched to the Liberty JVM server after the specified number of milliseconds, the EXEC CICS LINK command fails and CICS issues DFHSJ1006 message.

WLP_OUTPUT_DIR=$WLP_USER_DIR/servers

Specifies the directory that contains output files for the Liberty profile. By default, the Liberty profile stores logs, the work area, configuration files, and applications, for the server in a directory that is named after the server.

This environment variable is optional. If you do not specify it, CICS defaults to $WORK_DIR/&APPLID;/&JVMSERVER;/wlp/usr/servers, replacing the symbols with runtime values.

If this environment variable is set, the output logs and work area are stored in $WLP_OUTPUT_DIR/server_name.

WLP_USER_DIR={&APPLID;/&JVMSERVER;/wlp/usr/|directory_path}

Specifies the directory that contains the configuration files for the Liberty JVM server. This environment variable is optional. If you do not specify it, CICS uses &APPLID;/&JVMSERVER;/wlp/usr/ in the working directory, replacing the symbols with runtime values. Configuration files are written to servers/server_name.

WORK_DIR={.|/tmp|directory_name}

Specifies the working directory on z/OS UNIX that the CICS region uses for activities that are related to JVMSERVER. The CICS JVMSERVER uses this directory as the route of configuration and output. A period (.) is defined in the supplied JVM profiles, indicating that the home directory of the CICS region user ID is to be used as the working directory. This directory can be created during CICS installation. If the directory does not exist or if WORK_DIR is omitted, /tmp is used as the z/OS UNIX directory name.

You can specify an absolute path or relative path to the working directory. A relative working directory is relative to the home directory of the CICS region user ID. If you do not want to use the home directory as the working directory for activities that are related to Java, or if your CICS regions are sharing the z/OS user identifier (UID) and so have the same home directory, you can create a different working directory for each CICS region.

If you specify a directory name that uses the &APPLID; symbol (for which CICS substitutes the actual CICS region APPLID), you can have a unique working directory for each region, even if all the CICS regions share the set of JVM profiles. For example, if you specify:

WORK_DIR=/u/&APPLID;/javaoutput

each CICS region that uses that JVM profile has its own working directory. Ensure that the relevant directories are created on z/OS UNIX, and that the CICS regions are given read, write, and run access to them.

You can also specify a fixed name for the working directory. You must ensure that the directory is created on z/OS UNIX, and access permissions are given to the correct CICS regions. If you use a fixed name for the working directory, the output files from all the JVM servers in the CICS regions that share the JVM profile are created in that directory. If you use fixed file names for your output files, the output from all the JVM servers in those CICS regions is appended to the same z/OS UNIX files. To avoid appending to the same files, use the JVMSERVER symbol and the APPLID symbols to produce unique output and dump files for each JVM server.

Do not define your working directories in the CICS installation directory on z/OS UNIX, which is the home directory for CICS files as defined by the USSHOME system initialization parameter.

WSDL_VALIDATOR={TRUE|FALSE}

Enables validation for SOAP requests and responses against their definition and schema. This option is ignored for Liberty and Classpath type JVM servers. For more information, see Validating SOAP messages. It is possible to turn off this option by setting WSDL_VALIDATOR=FALSE. Opting out can prevent potential clashes with newer JAR files, wasted storage, and slower start.

ZCEE_INSTALL_DIR={directory_name}

Provides the location of the IBM z/OS Connect feature installation. For z/OS Connect V2.0, the default is /usr/lpp/IBM/zosconnect/v2r0/runtime. For z/OS Connect V3.0, the default is /usr/lpp/IBM/zosconnect/v3r0/runtime.