Java updates for North America 2007 DST Changes and the IBM Time Zone Update Utility for Java (JTZU)

Transcription

1 Java updates for North America 2007 DST Changes and the IBM Time Zone Update Utility for Java (JTZU) Toby Corbin, Java Development Team Lead John Stainforth, Project Manager Java Technologies, IBM Hursley

2 Agenda Presented by John Stainforth Daylight Savings Time DST Update requirement for Java Java Service fix strategy for DST updates Alternative solution: Time Zone Update Utility Presented by Toby Corbin Overview of the IBM Time Zone Update Utility Graphical Mode Command Line Mode How does the JTZU work Miscellaneous Known problems with Java and Time Zones Guidance on using JTZU vs. applying Service Fixes Further info 2

3 Daylight Savings Time What is changing US Energy Policy Act 2005 added 4 weeks of Daylight Saving Time starting in 2007 Canada, Bermuda have also decided to change in step with US 11 March April October November

4 Daylight Savings Time Implications Original DST start- and end-dates currently hard-coded into operating systems, Java SDKs/JREs and application code may require changes Software applications that rely on these dates may function incorrectly during the shaded four weeks. Applications may be impacted if they: use calendar or scheduling functions are dependent on date and time stamps perform any type of date or time processing Where applications function across multiple time zones or interconnect with systems in other time zones, there are potential exposures during these four weeks This is an industry-wide matter, relevant to all software providers and users 4

5 DST Update requirement for Java Customers will have to apply preventive service to installed SDKs/JREs Wide variety of environments, middleware products, platforms and installed levels Strong recommendation: customers upgrade to latest refresh levels of Java (1.3.1, and 5.0) 5

6 DST Update requirement for Java Challenges for the customers applying DST fixes: Customers often require long lead time to upgrade Some customers view all Java upgrades as high risk Some customers have back-level refresh levels with customised i-fixes Current Java service mechanism requires total replacement of SDK Added constraints on Solaris and HP-UX: Sun & HP s Java very close to end-of-life and is unsupported Sun & HP will not produce i-fixes to back-level refreshes on any release Other countries also changing in step with US Canada & Bermuda definite still possible that others could follow suit Solution must eventually include these and allow for later roll-out Other countries announcing unrelated DST changes with little lead time (e.g. Brazil, W.Australia) 6

7 Java Service fix strategy for DST updates Many IBM Products that imbed a JRE/SDK are making available fix packs (or service packs) containing the DST-enabled Java Service Refreshes For stand-alone Java deliveries on z/os, AIX and Linux platforms, DST-enabled Java SRs are available from IBM developerworks DST-enabled Java Service Refreshes will be provided for 1.3.1, and 5.0 releases only. DST-enabled means a baseline set of Java SRs that contain both the US and Canada fixes. These are SR10-ifix, SR27 for z/os, SR6 and 5.0 SR3. For details of later SRs with time zone adjustments for other countries, see: 7

8 Java Service fix strategy for DST updates DST fix delivery plans for IBM products are contained in Product Flashes and Tech notes available at the following Customers whose DST-enabling requirements are not going to be met by standard product fix packs should use the IBM Time Zone Update Utility 8

9 Alternative solution: Time Zone Update Utility For customers of products not supplying DST-enabled fix packs And, for customers with products for which applying fix packs is impractical The Time Zone Update Utility will: Perform a localised update of the time zone content Avoid total replacement of SDK/JRE Utilise regularly-updated time zone tables IBM is supplying the utility and latest time zone tables: To Customers, ISVs and business partners (via IBM developerworks) 9

10 Overview of the IBM Time Zone Update Utility JTZU is the internal name we are using for the IBM Time Zone Update Utility for Java The JTZU provides the means to update an IBM JRE with a new set of time zone data without having to take a new service refresh JTZU works for Java 1.2.2, 1.3.1, 1.4.0, 1.4.1, and 5.0 All supported platforms except for 1.2.2/1.3.1 on Solaris and HP-UX The JTZU can run in two modes of operation Graphics mode (basic operation) Command line mode (advanced operation) 10

11 Overview of the IBM Time Zone Update Utility JTZU performs the following tasks Search and locate JREs/SDKs Patch a JRE/SDK at a known location Search and locate JREs/SDKs, patching everything it finds Search and locate JREs/SDKs and then perform a selective patching 11

12 Graphical Mode Running the tool in Graphical mode This is the default behaviour Must be run as root user Launched via a shell script runjtzu (either.bat or.sh) 12

13 Graphical Mode The Graphical mode can be run either interactively or noninteractively 13

14 Interactive mode Prompted for a single JRE to update 14

15 Non interactive mode Tool will automatically search entire hard disc for any IBM JREs and then update them all 15

16 Command Line Mode This mode allows full control over how and when the tool will patch JREs DirectorySearch.txt allows full configuration of search A Discover only mode will only search for JREs A Patch only mode will perform the updates 16

17 Command Line Mode Running the tool in command line mode This is not the default behaviour Requires modification of a command line flag In runjtzuenv, set NOGUI = true Must be run as root user Launched using shell script runjtzu script (either.bat or.sh) 17

18 Command Line Mode Controlling the hard disk search DirectorySearch.txt file controls where the tool will search for JREs (only applicable in command line mode) Keyword all when placed at the start of the file forces the tool to search everything (default) Search directories can be removed by adding them to this file and starting the line with - The all keyword can be replaced with a specific list of directories by adding them to the file and starting each line with + 18

19 Command Line Mode Examples of DirectorySearch.txt all -c:\temp -d:\builds\testcases +c:\windows +c:\program files -c:\program files\sun 19

20 Command Line Mode Discover only mode In this mode, the tool will only search for JREs, it will not patch them Enabled by setting the flag DISCOVERONLY=true in runjtzuenv (.bat or.sh) Any found JREs are written to SDKList.txt The SDKList.txt file can be manually edited 20

21 Command Line Mode Patch mode In this mode, the tool will patch any JRE s that are in the SDKList.txt file Enabled by setting DISCOVERONLY=false in runjtzenv SDKList.txt can be edited before running, to remove any JRE s if you do not wish to patch them Any running VMs must be stopped before patching 21

22 How does the JTZU work Search method The tool detects JREs by looking for certain characteristics and files associated with an IBM JRE For 1.4.x and above, core.jar under jre/lib (core.jar does not exist under a Sun JRE) For 1.3.1, rt.jar under jre/lib and also the addition of certain ORB libraries to distinguish us from Sun 22

23 How does the JTZU work The files are replaced By using jar which is shipped with the tool Will never replace newer files with old update Replace TimeZone.class and TimeZone$1.class with precompiled version 1.4.x and above update Replace time zone binary files in core.jar with those shipped with the tool Solaris and HP We replace time zone binary files in /jre/lib/zi directory 23

24 How does the JTZU work All changes made by the tool are backed up It is a manual process to revert any changes made by the tool The rt.jar file (which contains the time zone data) is backed up under jre/lib as rt.jar_jtzubackup 1.4.x and above The core.jar file (which contains the time zone data) is backed up under jre/lib as core.jar_jtzubackup Solaris and HP The zi directory is backed up as jre/lib/zi_jtzubackup 24

25 How does the JTZU work Everything the tool does is logged LogFile.log is created that details everything the tool does Shows all search paths Shows all detected JREs Shows all patched JREs Any errors get logged to this file 25

26 Miscellaneous When the tool is patching, all VMs to be patched must be stopped The machine does not need to reboot after running the tool The OS may require patching Running the wrong version of the tool i.e., 64-bit version run against a 32-bit build Jar will fail Product and Support teams should include the DST2007 keyword in any DST-related PMR, APAR and technote Technical Support Engineers have their choice of entering the keyword 'DST2007' anywhere in the Keyword 1, Keyword 2, Keyword 3 or Comment fields of the PMR. For those using the comment field, the PMR needs to be checked before closure to ensure that 'DST2007' still exists, as the comment field is likely to be overwritten while a PMR is open. 26

27 Known problems with Java and Time Zones URL for latest information: Problem PMR/APAR Resolution Notes Inconsistency with use of EST and MST when upgrading to PMR 31047,005,000 APAR PK30359 Customer must correct and recompile apps. Introduced when upgrading to SR5 or later SR5 and 5.0 SR1. For Java 1.3.1, JVM must be started with year=2007 to pick up 2007 DST fixes PMR 40283,500,000 To test apps during 2006, customer should set year=2007 Problem goes away on 1 Jan. Adjustment required for Brazil DST start and end dates PMR 55124,228,631 Run JTZU or apply 1.3.1SR10-ifix, SR7 or 5.0 SR4 Problem reappears between Feb

28 Guidance on using JTZU vs. applying Service Fixes PRIMARY mechanism: Service Packs/Fix Packs supplied by product SECONDARY mechanism: Customer uses the Time Zone Update Utility (JTZU). In some cases, the product is not planning to make available DSTenabled fix packs for their product, so JTZU will be the only method available. Where the products are making fix packs available, the customer will have a choice. Many factors will influence this choice, but the default IBM recommendation is to apply product fix packs as the normal method. To cater for exceptional situations not covered by fix pack delivery, the products will advise their clients to run JTZU against their installed systems to perform the required upgrade. 28

29 Guidance on using JTZU vs. applying Service Fixes Examples of these situations are: 1. Further DST fixes for other time zones (e.g., W.Australia, Bermuda) have to be applied urgently 2. Client has a back-level GA product or refresh level (without the latest Java service) and is unable/unwilling to upgrade to a version of the product containing the latest Java SR 3. Client has an i-fixed refresh with an essential "custom" service fix applied, 4. A Java release for which SRs are unavailable is involved (e.g., 1.2.2, 1.4.0, 1.4.1) 5. Customer has a vendor product that prereqs a level of Java for which fix packs are unavailable. 29

30 Further Info questions to Links to external web sites