SQL*LIMS Technical Note. Document Number: LIMS023 Software Versions: SQL*LIMS v4.x and v5.x

Transcription

1 Document Number: LIMS023 Software Versions: SQL*LIMS v4.x and v5.x Brief Description: Daylight Savings Time 2007 Applies To: Patches for SQL*LIMS Oracle and Java Components Last Revised: 08-MAR-2007 Authors: Ken Madsen, Patrick Hutcherson, Georgianne Schade Scope Beginning in 2007, Daylight Savings Time (DST) in the U.S. and Canada will begin on the second Sunday in March and end the first Sunday in November rather than beginning on the first Sunday in April and ending the last Sunday in October, as it did in the past. Mexico is still using the old DST rules and is not affected by this change. Under the new rules for 2007, DST will start on March 11, 2007 and end on November 4, As a result, times displayed and/or recorded in various applications may be off by one hour during these additional weeks added for DST, unless patches are applied. Applied Biosystems (AB) has identified several areas in SQL*LIMS where this may occur, and which patches provided by Oracle and Sun need to be applied as a result of these changes. The scope of this document is to describe the testing performed on each version of SQL*LIMS, the items identified as problems, and to provide information to resolve the issues associated with the change in Daylight Savings Time. The testing done by AB was performed on Windows for all versions after the latest OS patches were applied. The Java elements that Applied Biosystems recommends to be patched should also be patched on UNIX. Patches for the various Java components based on operating system are available at: This document is structured by SQL*LIMS release, and within each release there are two sub-sections: 1 - Problems expected, or found, through testing (should be seen only during the interval between the new DST and old DST time change dates) 2 - Recommended patches. These patches were applied to AB systems, and later tested to ensure the problems were resolved. Please note that we do not include details of operating system patches in the 'Recommended patches' sections. We only cover Oracle and Java patches. For information on how to apply Windows OS patches, please refer to the following links: and

2 SQL*LIMS 5.1 1) Problems expected, or found through testing Remote Notification tools shows time one hour less than it should. Electronic signature records the incorrect local timestamp. Calendar widget generates the wrong time when selecting the Now button. The log files for the Java-based services (Security Monitor, Agent, Router) do not display the correct time. 2) Recommended patches Update the Business Logic Server, Admin Client and Midtier SQL*LIMS 1.4 JVM s using one of the following two options: - Option 1: Sun s TzUpdater tool Available at - Option 2: Replace the JVM as per Sun s recommendations. Refer to the supplemental installation instructions at the end of this document. Update the Oracle DB as follows: - Upgrade the DB to OR - Apply one-off patch Update the Oracle Infrastructure and Oracle Midtier JVM's: - Follow the recommended patches per Oracle note Update the Oracle Mid-tier as follows: - Oracle Jinitiator patch , with Jinitiator version (also covered in via referenced articles)

3 SQL*LIMS 5.0.x (5.0.0/5.0.1) 1) Problems expected, or found through testing Remote Notification tools shows time one hour less than it should. Electronic signature records the incorrect local timestamp. Calendar widget generates the wrong time when selecting the Now button. The log files for the Java-based services (Security Monitor, Agent, Router) do not display the correct time. Archiver related DST issues - Java Calendar widget generates the wrong time when selecting the Now button. - Archive request timestamp shows time without DST correction. - View Panels for Submissions, etc. show time without DST correction. 2) Recommended Patches Update the Business Logic Server, Admin Client and Midtier SQL*LIMS 1.4 JVM s using one of the following two options: - Option 1: Sun s TzUpdater tool Available at: - Option 2: Replace the JVM as per Sun s recommendations. Refer to the supplemental installation instructions at the end of this document. Update the Oracle Infrastructure and Oracle Midtier JVM's as follows, - Follow the recommended patches per Oracle note Update the Oracle Mid-tier as follows: - Oracle Jinitiator patch , with Jinitiator version (also covered in via referenced articles)

4 SQL*LIMS 4.1 1) Problems expected, or found through testing Remote Notification tools shows both client and server timestamps without DST correction. The log files for the Java-based services (Security Monitor, Agent, Router) do not display the corrected time. AdminTool creates wrong timestamps for new records from TPL, ASL, and ARE tabs. This data goes into the NAI_XXX_AUTHORIZATIONS tables. Archiver related DST issues - Java Calendar widget generates wrong time when selecting the Now button. - Archive request timestamp shows time without DST correction - View Panels for Submissions, etc. show time without DST correction. 2) Recommended Patches Update the Business Logic Server and Admin Client 1.3 JVM's with Sun's 1.3.1_18 JVM using the following process: - Obtain The Sun 1.3.1_18 JVM from: - Unzip the downloaded 1.3.1_18 JVM into a directory. - Back up the existing JVM directory from SQL*LIMS server directory. - Copy the new 1.3.1_18 directory to SQL*LIMS Server directory. - Rename 1.3.1_18 directory to *Note - If you have installed the v4.1 SQL*LIMS Archiver, which ships with JRE embedded into the BLS and Client SQL*LIMS homes, use the Sun recommended JRE 1.4.2_13 instead of the above versions. The Sun 1.4.2_13 JVM can be obtained here: Select the JRE download link.

5 SQL*LIMS ) Problems expected, or found through testing The log files for the Java-based services (Agent, Router) will not be correct for DST at the right times. AdminTool creates wrong timestamps for new records from TPL, ASL, ARE tabs. This data goes into the NAI_XXX_AUTHORIZATIONS tables. A JVM upgrade was performed to test whether or not this would resolve the problems listed above. Testing confirmed that problems found during testing could NOT be circumvented by a JVM upgrade. 2) Recommended patches It is recommended that no Oracle or JVM patches be applied. The Router and Agent are minor monitors that are not crucial for the operation of the application. The fact that the monitor timestamps are offset by an hour will not affect any application data, but only administration and troubleshooting of these monitors.

6 Clarification for v5.x on locations of the JVM (Java Home) In a v5.x architecture, there are JVM s that are supplied with SQL*LIMS and JVM s supplied by Oracle. The patching of the JVM s is different for each so this will clarify by example the types of JVM s that are patched. Your actual home directory names may be different as they are set during installation. The directory name will also indicate whether the JVM is a JRE or a JDK. Client Tier SQL*LIMS Admin Utilities Client This tier has only the SQL*LIMS JVM, which is located by default at: C:\SQLLIMS_UTILS\jre142 SQL*LIMS Business Logic Server Tier This tier has only the SQL*LIMS JVM, which is located by default at: C:\sqllimssvr\JRE Oracle Application Server Infrastructure Tier This tier has only the Oracle JVM, which is located by default at: C:\OraHome1\jdk Oracle Application Server Middle Tier This tier has 3 JVM s, one for SQL*LIMS and 2 for OracleAS 1) SQL*LIMS JVM is located by default at : C:\sqllims\jre142 2) Oracle JDK is located by default at: C:\OraHome1\jdk 3) Oracle Jinitiator is located by default at: C:\OraHome1\jinit

7 Updating JRE vs Patching with tzupdater Utility 1) There are 2 ways to achieve the timezone updates for the Java JRE that SQL*LIMS uses: Use Sun's tzupdater utility - This method allows the JRE Platform to remain as it was in our factory testing for the release. OR Update the JRE to the latest version in Java 1.3 or 1.4, per Sun's recommendation. - This method is being included to support those who would prefer to follow Sun s recommendation. - Our testing added some additional testing in v5.0.0 to demonstrate that it will not adversely affect SQL*LIMS functionality of the Java based applications that used the installed, embedded JRE. - The affected services are: (a) Router (b) Agent (c) Security Monitor (SecMon) (d) Archiver (e) Fiorano also uses the installed JRE to function as well. (f) A small portion of Remote Notification is called the message publisher and is called from forms. This uses the JRE on the client (for v4.1) and the embedded JRE on the middle tier in the SQL*LIMS home (for v5.x). 2) When using the tzupdater, it is possible that the incorrect JRE will be patched in cases where the computer has more than one JRE installed. To ensure you are patching the JRE that SQL*LIMS uses, use the following supplemental instructions for this tool: From a command prompt window, change the directory to the SQL*LIMS home directory's JRE directory. - For example: cd c:\sqllimssvr\v5_0_0\jre - Note: In v4.1 without Archiver and earlier, the JRE is installed, so it would be in a directory like C:\Program Files\JavaSoft\JRE\ cd to the bin directory. Place the tzupdater distribution here and extract it. To see if this directory is correct and is updated, run the command like this:

8 java -jar tzupdater.jar -t -v The output will include the Java home, which will identify the place where the tzupdates are applied. For example: D:\sqllims\jre142\bin>java -jar tzupdater.jar -t v java.home: D:\sqllims\jre142 java.vendor: Sun Microsystems Inc. java.version: 1.4.2_02 JRE time zone data version: tzdata2007a Embedded time zone data version: tzdata2007a Validating the time zone data Validation complete Once you have confirmed the Java home is the SQL*LIMS Java home, repeat the command like this to apply the updates: java -jar tzupdater.jar -u -v It will validate the time zone data after updating Supplemental Installation Instructions if an Updated JRE is Installed 1) For version 4.1 with Archiver and v5.x, SQL*LIMS ships an embedded JRE that is installed on the monitor tier, client utilities tier and OAS middle tier (in the SQL*LIMS home). For these versions ONLY, follow these supplemental install instructions: 2) With all users off the system and all SQL*LIMS Java services shut down (including the Fiorano service), rename the SQL*LIMS JRE directory to JRE.orig. 3) Obtain the JRE from Sun and the JDK from Sun. The patches are prefixed with j2re and j2sdk respectively. Install the JRE in custom mode and change the install directory to match the former SQL*LIMS JRE directory. - For example: C:\sqllimssvr\v5_0_0\JRE - Use the same name, as on some tiers the directory name is jre142. 4) Either obtain the files from the JDK that is patched for OAS (v5.x) or install the JDK. This can be on a separate server or computer if you do not want to install on the server. 5) Go to the jdk\jre\bin directory and copy the server subdirectory. 6) Paste it into the freshly installed JRE\bin directory. 7) For Archiver, it is necessary to copy 2 additional files on the SQL*LIMS BLS. Omit this step for v5.1. From JRE.orig\bin, copy rtsnative.dll and paste it to the freshly installed JRE\bin directory.

9 From jdk\lib, copy tools.jar and paste it to the freshly installed JRE\lib directory. This scenario was tested with SQL*LIMS v Support Please contact SQL*LIMS Technical Support for any further questions: Option1 or