DataStage and the DST change

[chulett]

For those of us in the US and needing to deal with the change in Daylight Savings Time start and end times this year - are there any 'DataStage issues' to be aware of? A 'big project' is underway to coordinate this change across the enterprise and I've been pinged for DataStage.

Seeing as how we're not doing anytime timezone specific and get anything time related from the O/S I'm assuming "we" are out of the loop on this.

Yes, no, maybe so?

[DSguru2B]

Seeing as how we're not doing anytime timezone specific and get anything time related from the O/S I'm assuming "we" are out of the loop on this.

If thats the case then I am guessing it shouldnt be a problem. The only thing would be your scheduling criteria but thats out of your hands in into the scheduling folks side. I'd suggest having a chat with IBM as well on this. Maybe something might pop up.

[shawn_ramsey]

The DataStage eService site states that they have engineers looking at it and you should subscribe to the notification e-mail list to get information as they make it available.

Support site: https://www.ascential.com/eservice

[chulett]

Thanks... I do receive Product Alerts for DataStage currently but just added a Platform Alert for our O/S as well. From the site:

A provision of the Energy Policy Act of 2005, extends Daylight Saving Time (DST) in the United States by four weeks, beginning in 2007. Systems and applications that process dates and times will be affected by this change. In 2007, U.S. Daylight Saving Time (DST) will begin on the second Sunday in March and end on the first Sunday in November. This change in the schedule -- the first in 20 years -- will make U.S. Daylight Saving Time four weeks longer. The U.S. Energy Act of 2005 made this change to reduce energy consumption. This will impact many existing technology products and solutions.

How do I know if these changes apply to me or if I could be affected?
Daylight Savings time is not observed by all countries, not even by all states within the United States. Date and time processing functions in systems and applications in countries implementing the new DST rules (U.S., Canada, Bermuda) are affected. Systems and applications in countries not implementing the DST changes could be affected if they support users, transactions, or applications involving countries that are implementing the new DST rules. Please check with your local or national government if you are unsure.

How do I know if my Information Integration products could be affected?
IBM Product Engineers are currently working on the Information Integration (formerly Ascential) products to determine if there will be any impact. We will be providing email notifications containing detailed information regarding DST as soon as it becomes available. To receive these notifications, you must subscribe yourself to our TechAlert email notifications for the products that you are using.


There is also this site to check for all products, it turns out:

http://www.ibm.com/support/alerts/us/en ... alert.html

[I_Server_Whale]

Thanks for sharing. Craig and Shawn.

[vmcburney]

There is no support entry yet for DataStage or any of the other related tools. There is one for Information Integrator which advises people to run a utility for the IBM Java Runtime Environments (JRE). The product itself is not impacted.

I think DataStage gets all its times and dates off the operating system. As for the Universe bundled engine or repository this support page indicates Universe is not affected but a Sun Java run time would require a patch.

So the question is, does the DataStage server have a java runtime environment on it?

[chulett]

So the question is, does the DataStage server have a java runtime environment on it?

Most definitely. Used by the XML stages at the very least.

[chulett]

Here is the official verdict from IBM for all products:

https://www.ascential.com/eservice/public/dst.jsp

For DataStage, it's all about the Java components. So, if you are using the Web Services PACK or RTI / SOA, you'll need to upgrade the embedded JVM to be compliant. No mention of XML, which kind of surprised me. My understanding is it is based on the Xerces XML parser, which is typically Java, but could be C++ based.

[chulett]

Has anyone actualy done this on their system yet? Seems to be turning into a major PITA.

Using the IBM 'jtzu' (which is supposed to be used to patch the RTI Agent) to search for JREs that it can patch finds these relevant bits:

Code: Select all

parentDirectory1 - /opt/datastage/Ascential/DataStage/DSEngine/java/jre/bin
parentDirectory2 - /opt/datastage/Ascential/DataStage/DSEngine/java/jre
parentDirectory1 - /opt/datastage/Ascential/DataStage/DSEngine/java/jre/lib
parentDirectory2 - /opt/datastage/Ascential/DataStage/DSEngine/java/jre
/opt/datastage/Ascential/DataStage/DSEngine/java/jre:  Only a vendor's JRE License file located. No IBM License Notice.
parentDirectory1 - /opt/datastage/Ascential/DataStage/DSEngine/java/jre/lib
parentDirectory2 - /opt/datastage/Ascential/DataStage/DSEngine/java/jre
parentDirectory1 - /opt/datastage/Ascential/RTIAgent/jre/bin
parentDirectory2 - /opt/datastage/Ascential/RTIAgent/jre
parentDirectory1 - /opt/datastage/Ascential/RTIAgent/jre/lib
parentDirectory2 - /opt/datastage/Ascential/RTIAgent/jre
parentDirectory1 - /opt/datastage/Ascential/RTIAgent/jre/lib
parentDirectory2 - /opt/datastage/Ascential/RTIAgent/jre
Javaexecutable - /opt/datastage/Ascential/RTIAgent/jre/bin/java
Found a SDK/JRE - /opt/datastage/Ascential/RTIAgent/jre

Which all seems reasonable. There's a different (HP) patch for the JVM embedded in DataStage and it seems to find the RTI version ok. However, following the instructions to actually patch that JRE gets me:

Code: Select all

/home/dsuser/dst/jtzu $ ./runjtzu.sh
*********** Welcome to the IBM Time Zone Update Utility for Java (JTZU) Version 1.3.7a ***********
JTZU Home: /home/dsuser/dst/jtzu
Set the variables using the script /home/dsuser/dst/jtzu/runjtzuenv.sh
Launching the Java Time Zone Updater Tool.
Exception in thread "main" java.lang.UnsatisfiedLinkError: /opt/datastage/Ascential/RTIAgent/jre/lib/PA_RISC2.0/motif21/libmawt.sl: specified file is not a shared library, or a format error was detected.
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1585)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1456)
        at java.lang.Runtime.load0(Runtime.java:737)
        at java.lang.System.load(System.java:811)
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1585)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1477)
        at java.lang.Runtime.loadLibrary0(Runtime.java:788)
        at java.lang.System.loadLibrary(System.java:834)
        at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.awt.Toolkit.loadLibraries(Toolkit.java:1441)
        at java.awt.Toolkit.<clinit>(Toolkit.java:1479)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:141)
        at com.sun.java.swing.plaf.motif.MotifLookAndFeel.class$(MotifLookAndFeel.java:1162)
        at com.sun.java.swing.plaf.motif.MotifLookAndFeel.<clinit>(MotifLookAndFeel.java:1162)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:219)
        at javax.swing.SwingUtilities.loadSystemClass(SwingUtilities.java:1677)
        at javax.swing.UIManager.setLookAndFeel(UIManager.java:426)
        at JTZUMain.main(JTZUMain.java:231)

More calls to Support are in order, it seems.

[ray.wurlod]

Possibly a bad (corrupted) libmawt.sl file?

[chulett]

Seems like it. I'll try some other things over the weekend and follow up with Support on Monday - I opened a case and got the 'will be forwarded to the appropriate engineer' email.

[chulett]

Getting late in the game, but just in case anyone is wondering...

This update is expecting to be run on the console and so have access to a GUI display. I just telnet in from my PC via putty and that was causing the abort.

In my case, I couldn't follow the instructions on How to patch a JRE or SDK at a known location as it has the NOGUI environment variable set to false. I needed to follow the instructions for How to selectively search for SDKs and JREs and then perform selective patching, which utilizes a NOGUI setting of true.

The first attempt to search took forever and eventually cratered with an 'out of memory' error. I then changed the contents of the DirectorySearch.txt file, removing the 'all' line and replacing it with my location for DataStage - in my case (and the UNIX default):

+/opt/datastage/Ascential

The search then went quickly and the patch (which uses a file of the search results which lists the 'patchable' JREs found) completed without error.

FYI.