|
Restrictions
- Additional JZOS prereq if running on z/OS V1.4 or z/OS V1.5
In order to used the full functionality of the JZOS APIs introduced in Service Refresh 6, you must install the appropriate C++/LE compatability APAR/PTF:
APAR PQ84190 (PTF UK03870) for z/OS 1.5,
or
APAR PQ84190 (PTF UK03869) for z/OS 1.4
There is no additional prereq requirement if you are running on z/OS V1.6 and above.
- Possible problem using JZOS launcher as a Started Task
In some rare instances, running the JZOS launcher function delivered in SDK 1.4.2 SR6 (PTF UK17593) as a started task (STC) can result in a protection exception (0C4). Two conditions must be met for this failure to occur:
- JZOS is started as a started task
- No start parameters are passed to JZOS
To avoid this possible failure the following command syntax should be used:
START procname,,,BYPASS
Where "BYPASS" can be any arbitrary nonzero length string. The letters "BYPASS" or even "X" can literally be used. This approach can be used as a workaround for z/OS SDK customers until the fix is propagated to a new service refresh.
This potential problem does not exist for batch jobs launched with the JZOS function. Some customers have reported that the problem in the JZOS launcher function is intermittent. It can appear after the application of z/OS maintenance.
- The new I/O (NIO) channels in this SDK and Runtime Environment have a number of limitations, listed in the following table. Click on the defect number to link to the Sun Web site that documents the limitation. To go directly to the bug, you must be a registered member of the Java Developer Connection. To see which bugs have been fixed, you should check the contents of any service refreshes of this SDK and Runtime Environment.
-
| List of new I/O limitations |
| Sun bug number |
Brief description of limitation |
| 4460065 |
Interruption of file-locking operations not completely implemented |
| 4643189 |
FileChannel.transferTo() fails for files > 2^31 - 1 bytes |
| 4696508 |
Selector doesn't synchronize as specified |
| 4673298 |
Locking in Preferences sometimes fails on NFS mounted drives. NIO file locking over NFS might also be affected. |
- Support for IPv6
The class java.net.NetworkInterface does not currently support IPv6 addresses. The java.net.NetworkInterface methods getNetworkInterfaces(), getByInetAddress(), and getByName() return only network interfaces that have been configured with IPv4 addresses. The java.net.NetworkInterface method getInetAddresses() returns only IPv4 addresses.
- Co-existence restriction for SMP/E installed SDK versions
If you need to keep an SMP/E installed version of the Java SDK 1.4 product (IBM SDK for z/OS, Java 2 Technology Edition, 5655-I56) and the SMP/E installed version of the Java z/OS SDK 1.3.1 product (IBM Developer Kit for OS/390, Java 2 Technology Edition, 5655-D35), you should read this section.
Installing the JAVA SDK 1.4 product (HJVA140) in the same SMP/E zones as 1.3 will remove 1.3 (HJVA130). Therefore, you will need to install HJVA140 in separate zones and libraries. This can be accomplished by following these instructions:
- Create separate target and dlib zones in your CSI:
SET BDY(GLOBAL) .
UCLIN .
ADD GLOBALZONE ZONEINDEX(
(#tzone,#csi,TARGET)
(#dzone,#csi,DLIB)) .
ENDUCL .
SET BDY(#tzone) .
UCLIN .
ADD TARGETZONE(#tzone) RELATED(#dzone)
OPTIONS(#options) SREL(Z038) .
ENDUCL .
SET BDY(#dzone) .
UCLIN .
ADD DLIBZONE(#dzone) RELATED(#tzone)
OPTIONS(#options) SREL(Z038) .
ENDUCL .
Change #csi to your existing csi.
Change #tzone to your new target zone.
Change #dzone to your new dlib zone.
Change #options to the existing options name.
- Create separate libraries, HFS, and DDDEFs:
To create the new libraries use the AJVALLOC job. Allocate these libraries with a middle level qualifier to differentiate them from the 1.3 libraries. The recommended MLQ is V1R4M0. Follow the instructions in the job.
To create the new HFS data set, use the AJVISHFS job. The recommended mountpoint is ../usr/lpp/java/J1.4. Note that J1.4 is required to be the final directory in this path. Follow the instructions in the job. Edit and run the AJVISMKD job following the instructions in the job.
To create the required DDDEFs use the AJVDDDEF job with appropriate modifications as instructed in the job. Be sure to include the MLQ as part of the data set names.
- Continue with installation as documented in the Program Directory.
- Customization:
Assuming the recommended mountpoint in "Create separate libraries, HFS, and DDDEFs" was used, Set the PATH environment variable:
export PATH=.../usr/lpp/java/J1.4/bin:$PATH
- The optional parameter -Djava.awt.headless=true is supported, as of PTF UQ90449 (corresponding to SDK 1.4.2).
- Users of JAAS features in this Service Refresh exploiting methods in the ThreadSubject() class may encounter a java.security.AccessControlException exception which manifests itself in the form of a traceback similar to the following:
java.security.AccessControlException: access denied
(java.util.PropertyPermission file.encoding read)
at java.security.AccessControlContext.checkPermission
(AccessControlContext.java:284)
at java.security.AccessController.checkPermission
(AccessController.java:415)
at java.lang.SecurityManager.checkPermission
(SecurityManager.java:554)
at java.lang.SecurityManager.checkPropertyAccess
(SecurityManager.java:1303)
at java.lang.System.getProperty(System.java:621)
at com.ibm.security.auth.ThreadSubject.doAsThreadSubject
(Native Method)
at com.ibm.security.auth.ThreadSubject.privateDoAs
(ThreadSubject.java:399)
at com.ibm.security.auth.ThreadSubject.doAs
(ThreadSubject.java:128)
at OS390TestPL_TS.main(OS390TestPL_TS.java:34)
at PLTS130Thread.run(plts130.java:42)
A workaround is available for users who encounter this error. Insert the following line into the java.security.policy file used by the application for the codebase from which the application is being loaded:
permission java.util.PropertyPermission "file.encoding",
"read";
For example, if the application is invoked with the following command:
java
-Djava.security.manager
-Djava.security.auth.login.config=
./policy/login.config
-Djava.security.policy=./policy/java.policy
-Djava.security.auth.policy=
./policy/javax.policy plts130
then the java.policy file in the above example might contain the following:
grant codeBase "file:/home/JoeUser/myApplication/*" {
permission javax.security.auth.AuthPermission
"createLoginContext";
permission javax.security.auth.AuthPermission
"threadSubjectDoAs";
permission javax.security.auth.AuthPermission "doAs";
permission java.util.PropertyPermission "java.home",
"read";
permission java.util.PropertyPermission
"file.encoding", "read";
};
The last line in this stanza is the workaround described above.
An update will be incorporated in the next service refresh (beyond October, 2003) of the product to circumvent the need to manually update the user's java.security.policy file with this permission change.
Other Considerations
- When running the Java SDK1.4 product at PTF UK07860 (SDK1.4.2 SR3) or later and using MQ Series, please review MQ APAR II13740.
- To allow IMS to run with the SDK1.4 Java product in addition to running with the SDK1.3 Java product:
-
- The SDK1.3 product must be at PTF UQ76273 or later
- The SDK1.4 product must be at PTF UQ77468 or later
- For IMS V7, install PTF=UQ80879 (APAR=PQ76609)
- For IMS V8, install PTF UQ82427
Note: for running with the SDK1.4 product, follow the IMS instructions to specify the XPLINK environment.
- To allow DB2 to run with the SDK1.4 Java product in addition to running with the SDK1.3 Java product:
-
- The SDK1.3 product must be at PTF UQ76273 or later
- The SDK1.4 product must be at PTF UQ77468 or later
- For DB2 V7, install PTF=UQ81669 (APAR= PQ76769)
- For DB2 V8, the support is included in the base.
|
