Fix (APAR): PK37358 Status: Fix Release: 6.0.2 Operating System: AIX Supersedes Fixes: CMVC Defect: PK37358 Byte size of APAR: 1992901 Date: 2007-01-24 Abstract: The BatchDataStream (BDS) method positionAtInitialCheckpoint() is not called at step initialization time. Customer applications which expect that method to be driven in their imple Description/symptom of problem: PK37358 resolves the following problem: ERROR DESCRIPTION: The column name of CHECKPOINTREPOSITORY in LREE db does not match with its data in XDv6.0.2 LOCAL FIX: local fix PROBLEM SUMMARY USERS AFFECTED: All users of WebSphere Extended Deployment version 6.0.2 using Batch/Grid functionality. PROBLEM DESCRIPTION: The BatchDataStream (BDS) method positionAtInitialCheckpoint() is not called at step initialization time. Customer applications which expect that method to be driven in their implementation of the BDS positionAtInitialCheckpoint() are not called when the BDS is initialized at step initialization time. An example of a scenario where this may pose a problem is: 1) Job step 1 completes; 2) Job step 2 processing begins and many BDS records are processed by step 2 but the first checkpoint of the BDS has not yet been taken; 3) The job is cancelled. Then, when the job is restarted, all the step 2 BDS records which were processed before the job was cancelled must be processed again since the BDS positionAtInitialCheckpoint() is not called. Customer applications which are written to avoid this processing are unable to do so. In addition, information in the Long-running job execution environment (LREE) CHECKPOINTREOSITORY database is incorrect. Information in the STEPNAME and BATCHDATASTREAMNAME columns is interchanged. Because these columns comprise the primary key for the table, the RESTARTTOKEN is not found when the job step is restarted. This causes the BDS to be repositioned at the beginning whenever the failing job step restarts, contrary to the expected behavior. The expected behavior is that the BDS should be repositioned based upon the contents of the CHECKPOINTREOSITORY RESTARTTOKEN field of the last successful checkpoint. RECOMMENDATION: None The Long-Running Execution Environment (LREE) incorrectly records information in the CHECKPOINTREOSITORY database. The data in columns STEPNAME and BATCHDATASTREAMNAME is interchanged. The STEPNAME column contains the BATCHDATASTREAMNAME information and vice-versa. The BatchDataStream (BDS) positionAtInitialCheckpoint() method is not called at step initialization time because the CHECKPOINTREOSITORY key is not matched. PROBLEM CONCLUSION: Code changes are made such that the Long-Running Job Execution Environment correctly updates the CHECKPOINTREPOSITORY table and calls the BDS method positionAtInitialCheckpoint() at step initialization time. The above fix will be installable on top of WebSphere Extended Deployment v6.0.2. This fix also supersedes the fix for APARs PK31087, PK24302, PK28106 and PK28814. Directions to apply fix: x_ Application Server Nodes __ Deployment Manager Nodes __ Both NOTE: The user must have Administrative rights in Windows, or be the Actual Root User in a UNIX environments. Also, you should be logged in with the same authority level when unpacking a fix, fix pack or refresh pack. DOWNLOAD THE UPDATE INSTALLER TOOL IN ORDER TO INSTALL A FIX. The Fix Installer can be downloaded from the following link: http://www.ibm.com/support/docview.wss?rs=180&uid=swg21205991 The Update Installer for V5.0 does not have a maintenance directory. It uses fixpacks and fixes as the location of the unpacked files. Customers must be at V6.0.2.2 or newer of the Update Installer. This can be checked by reviewing the level of the Update Installer in file /updateinstaller/version.txt. Installation instructions for ifix: (assuming customer has installed update installer already) 1) Place 6.0.2-WS-XD-IFPK37358.pak (for XD 6.0.2 on WAS 6.0.2) or 6.0.2-WS-WXD-IFPK37358.pak (for XD 6.0.2 on WAS 6.1) in updateinstaller/maintenance folder and launch update installer. 2) Shutdown the endpoint (LREE) server(s) and the LongRunningScheduler server. Manually execute setupCmdLine.bat in Windows or . ./setupCmdLine.sh in Unix from the WebSphere instance that maintenance is being applied to. 3) Launch Update Installer 4) Enter the installation location of the WebSphere product you want to update. 5) Uninstall any previously installed Batch/Grid iFixes (i.e., PK31087, PK24302, PK28106, PK28814): a) Select "Uninstall maintenance package" operation. b) Enter the file name of the maintenance package to uninstall (PKxxxxx.pak). c) UnInstall maintenance package. d) Relaunch the update installer. 6) Select the "Install maintenance package" operation. 7) Enter the file name of the maintenance package to install (PKxxxxx.pak file which was copied in the maintenance directory). The V5.0 and V5.1 fix packs and fixes are unpacked as .jar files and should be unpacked into fixpacks or fixes directory. 8) Install the ifix. The ifix updates: /lib/batchruntime.jar /lib/gridendpointselector.jar /installableApps/LongRunnngScheduler.ear /installableApps/LREE.ear 9) This ifix requires that the LongRunningScheduler.ear and LREE.ear applications be re-installed. a) backup your configuration using the backupConfig command. For instructions refer to: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp search for "backupConfig" b) uninstall the LongRunningScheduler.ear and LREE.ear applications from the cell. c) install the LongRunningScheduler.ear and LREE.ear applications located in /installableApps. For instructions refer to: http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp search for "Installing the long-running scheduler application EAR file" and "Installing the execution environment" 10) Start the Long Running Scheduler and LREE servers. 11) If you desire to uninstall the IFIX, use the update installer to uninstall the maintenance and use the restoreConfig command to restore your original configuration. Directions to remove fix: Directions to remove fix: NOTE: The user must have Administrative rights in Windows, or be the Actual Root User in a UNIX environments. NOTE: FIXES MUST BE REMOVED IN THE ORDER THEY WERE APPLIED. DO NOT REMOVE A FIX UNLESS ALL FIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED. YOU MAY REAPPLY ANY REMOVED FIX. Example: If your system has fix1, fix2, and fix3 applied in that order and fix2 is to be removed, fix3 must be removed first, fix2 removed, and fix3 re-applied. 1) Shutdown WebSphere Manually execute setupCmdLine.bat in Windows or . ./setupCmdLine.sh in Unix from the WebSphere instance that uninstall is being run against. 2) Start Update Installer 3) Enter the installation location of the WebSphere product you want to remove the fix. 4) Select "Uninstall maintenance package" operation. 5) Enter the file name of the maintenance package to uninstall (PKxxxxx.pak). 6) UnInstall maintenance package. 7) Restart WebSphere Directions to re-apply fix: Directions to re-apply fix: 1) Shutdown WebSphere 2) Follow the Fix instructions to apply the fix. 3) Restart WebSphere Additional Information: This iFix changes the content of the LREE CHECKPOINTREPOSITORY tables. The meaning of the data in the STEPNAME and BATCHDATASTREAMNAME columns has changed. These columns compose part of the table key. Therefore, jobs which are in restartable state before application of the iFix WILL NOT BE RESTARTABLE after application of the iFix. Such jobs should be purged from the LongRunningScheduler and LREE databases. Additional Information: