Last updated 15 February 2007.
(c) Copyright International Business Machines Corporation, 1999, 2006. All rights reserved.
U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
The IBM Time Zone Update Utility for Java (JTZU) updates an IBM-supplied Java installation with the latest time zone information.
It provides a method of applying preventive service to IBM products that imbed the Java SDK or JRE. It avoids the need to carry out a total replacement of the SDK or JRE and executes independently of any Fix Packs or Service Packs supplied by IBM products. It will update only the time zone information and apply no other fixes.
With time zone arrangements now changing at more frequent intervals, JTZU provides a method for customers unable to wait for the delivery of time zone fixes by conventional service processes to keep their systems up to date with time zone data changes.
JTZU uses data from the Olson Time Zone data tables (URL: http://www.twinsun.com/tz/tz-link.htm) to update the equivalent information contained in the Java SDKs and JREs. From Java 1.4 onwards, the SDKs and JREs calculate their time zone information using a set of rules for time zone offsets in tables very similar to the Olson tables. In Java 1.3.1 and earlier releases, these rules are encoded inside the Java class logic. When JTZU is used to update installed SDKs or JREs, it replaces either the timezone tables (for Java 1.4 and later releases) or the Java class file containing the timezone logic (Java 1.3.1 and earlier).
The level of time zone data is identified in the same way as in the Olson database; for example tzdata2006x, where the "x" is one of a series of refreshes delivered in 2006. The level of the time zone data table is reflected in the version level of JTZU - for example JTZU Version 1.0.7a contains timezone data at the level of Olson's tzdata2007a.
When JTZU is processing an IBM-supplied SDK or JRE, it first checks the level of the time zone data in it and then performs an update if the SDK or JRE is at an earlier time zone data level than the target level contained in JTZU. For example, if the target level is tzdata2007a, any JRE with a time zone data level of tzdata2006p or earlier will be updated.
JTZU does not support Java on Series i (i5/OS) platforms. To update Java on i5/OS, refer to Updating Java for Daylight Time Saving changes on i5/OS platforms.
SDKs and JREs detected and patched by JTZU:
Note: * Java 1.2.2 and 1.3.0 are no longer supported releases. JTZU is able to process some 1.2.2 and 1.3.0 JREs and SDKs, but this ability has not been fully tested across all platforms. You may use JTZU on these releases, with the understanding that you do so at your own risk, and a response or fix to any problems that you report is not guaranteed. No assistance is possible with Java 1.2.2 or 1.3.0 on Solaris or HP-UX platforms, because these releases are no longer supported by Sun and HP.
For a complete list of the JREs and SDKs found on your system, see the LogFile.log file generated by JTZU.
jar -xvf <filename>
chmod 755 runjtzu.sh
Before running JTZU, you must decide which JRE to use to run it. This JRE may be the same JRE as the one that the Utility is going to patch. You specify the location of the JRE used to run the utility in the JTZU Settings file. This JRE must be at a level of Java 1.3.1 or higher. If you are updating a 1.2.2 or 1.3.0 JRE or SDK, you must use a 1.3.1 (or higher level) JRE to drive the utility. If this JRE is not available on the local machine, it can be located on a network drive.
Edit the JTZU Settings file: runjtzuenv.bat on Windows, runjtzuenv.cmd on OS/2, or runjtzuenv.sh on other platforms.
In the JTZU Settings file, set JAVA_HOME to the path of the directory containing the JRE that you are going to use to run the utility.
On OS/2 platforms, set JTZU_HOME in the runjtzu.cmd file to the path of the directory containing the JTZU utility.
Now that you have specified the JRE used to run the utility, you can carry out the following tasks:
You do not need to reboot your system after patching SDKs or JREs.
By default, JTZU will search the entire file system.
The utility will search for JREs and save the results in the LogFile.log file. SDKs and JREs that can be updated by JTZU will also be stored in the SDKList.txt file. This operation can take a long time depending on the size of the system being searched, but your JREs can still be running while they are being discovered.
Use the GUI to locate all JREs and SDKs on a system, then patch supported JREs and SDKs.
The GUI will display all SDKs and JREs supported for patching in the top section, and all SDKs and JREs that require patching in the bottom section. The GUI will not display SDKs and JREs that JTZU cannot patch.
You do not need to reboot your system after patching SDKs or JREs.
Two "advanced user" facilities are available. The first provides more control over directory searching and the second gives you more control over the SDKs and JREs to patch after a directory search. Each of these facilities can be used independently or they can be used together. You can limit the scope of directory searching to reduce the length of time this operation takes to run, which will depend on the size of the system being searched. Your JREs can still be running while they are being discovered.
You can perform a full search or a selective search of your directories, controlled by the DirectorySearch.txt file.
The SDKList.txt file will be populated with all the discovered SDKs and JREs that can be patched along with the version of the time zone data they contain. For 1.2.2 and 1.3.1 SDKs and JREs that have not previously been patched by JTZU, the time zone data level will be shown as "Update Required".
You do not need to reboot your system after patching SDKs or JREs.
Directory searching is controlled by the DirectorySearch.txt file. Edit this file to restrict where JTZU searches for JREs on your system. Each entry must begin on a new line.
You can add and remove locations from the search by adding a directory to the DirectorySearch.txt file with a + or - at the beginning. There must not be a space between the + or - and the name of the directory.
On Windows or OS/2, a DirectorySearch.txt file containing:
+c:\programs -c:\programs\ibm\java142
will cause JTZU to recursively search the contents of the c:\programs directory, excluding c:\programs\ibm\java142 and all its subdirectories.
On other platforms, a DirectorySearch.txt file containing:
+/usr -/usr/bin
will cause the JTZU to recursively search the contents of the /usr directory, excluding /usr/bin and all its subdirectories.
If the all entry is the first entry in the file, JTZU will search everywhere on the system except for specified exclusions. If the all entry is not in the file, or is not the first entry in the file, JTZU will search only in specified locations.
On Windows or OS/2, a DirectorySearch.txt file containing:
all -c:\workarea
will cause JTZU to search the entire system except the c:\workarea directory.
On other platforms, a DirectorySearch.txt file containing:
all -/proc
will cause JTZU to search the entire system except the /proc directory. This is the default on AIX, z/OS, Linux, Solaris, and HP-UX platforms.
By default, JTZU will not search the /proc directory. This directory is excluded because it contains dynamically generated directories that could form an infinite loop.
You might also consider excluding the /dev and /sys directories depending on your platform. The /etc, /tmp, and /var directories are also unlikely to contain JREs.
Log information is written to the LogFile.log file. The log file shows all search paths, all detected JREs, and all patched JREs. Any errors are logged to this file.
On AIX, Linux, Windows, and z/OS, the JTZU makes a backup of the core.jar file as core.jar_jtzubackup (rt.jar as rt.jar_jtzubackup on 1.3.1 and older) under the jre/lib folder of the Java installation. On HP-UX and Solaris, the JTZU makes a backup of the zi directory as zi_jtzubackup under the jre/lib folder of the JRE installation.
The following Web site contains information about known problems with DST adjustment that apply whether you have run JTZU to upgrade your system or upgraded using service refreshes or fix packs:
http://www-1.ibm.com/support/docview.wss?rs=3068&context=SSNVBF&uid=swg21250503
In addition, the following limitations apply to JTZU:
When updating Java 1.2.2 SDKs and JREs, you must have an instance of Java 1.3.1 or later on the server being patched or you must run JTZU on a machine with network drives (mount points) to the server that need to be patched.
On AIX, Linux, Windows, and z/OS, attempting to patch the JRE used to run the Utility twice will result in the following error message:
java.lang.InternalError: jzentry == 0,
jzfile = 3259568,
total = 2859,
name = C:\cn142-20060217\sdk\jre\lib\core.jar,
i = 2541,
message = invalid LOC header (bad signature)
at java.util.zip.ZipFile$2.nextElement(ZipFile.java(Compiled Code))
at java.util.jar.JarFile$1.nextElement(JarFile.java(Compiled Code))
at JTZUVersionCheck.retrieveCurrentVersion(JTZUVersionCheck.java(Compiled Code))
at JTZUVersionCheck.<init>(JTZUVersionCheck.java:43)
at JTZUUpdater.updateTimeZoneInformation(JTZUUpdater.java:65)
at JTZUInteractive$JTZUInteractiveWorkerThread.updateTimeZoneInformation(
JTZUInteractive.java:322)
at JTZUInteractive$JTZUInteractiveWorkerThread.run(JTZUInteractive.java:186)
This error message can be avoided by restarting JTZU after patching the JRE for the first time.
On AIX, Linux, Windows, and z/OS, using a 1.3.1 JRE prior to SR10, attempting to patch the JRE used to run JTZU will result in the following error message:
java.lang.NoClassDefFoundError: javax/swing/JComponent$1
at javax.swing.JComponent.revalidate(JComponent.java:3658)
at javax.swing.AbstractButton.setMargin(AbstractButton.java:329)
at javax.swing.plaf.basic.BasicOptionPaneUI.addButtonComponents(BasicOpt
ionPaneUI.java:654)
at javax.swing.plaf.basic.BasicOptionPaneUI.createButtonArea(BasicOption
PaneUI.java:567)
at javax.swing.plaf.basic.BasicOptionPaneUI.installComponents(BasicOptio
nPaneUI.java:141)
at javax.swing.plaf.basic.BasicOptionPaneUI.installUI(BasicOptionPaneUI.
java:103)
at javax.swing.JComponent.setUI(JComponent.java:346)
The JRE will still be successfully updated. This problem is fixed in 1.3.1 SR10.
If you patch a JRE that has been installed under SMP/E on z/OS or installp on AIX, those utilities might flag the JRE as corrupt or inconsistent. Such a message is expected because you have modified the JRE.
Settings are stored in a file named runjtzuenv.bat on Windows or runjtzuenv.sh on other platforms.
A set of FAQs covering JTZU is available here: http://www-1.ibm.com/support/docview.wss?rs=3068&context=SSNVBF&q1=time+zone+faq&uid=swg21249759&loc=en_US&cs=utf-8&lang=en