################################################################## Copyright (C) 2005 IBM Corp. - All Rights Reserved. IBM makes no representations or warranties about the suitability of this program, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. ################################################################## WEBSPHERE PRODUCT CENTER LIMITED AVAILABILITY INTERIM FIX 5.1.0-LA002 ======================================== 1. ABOUT THIS LIMITED AVAILABILITY FIX 2. LIMITED AVAILABILITY FIX REQUIREMENTS 3. LIST OF INTERIM FIXES 4. LIST OF PREVIOUS PATCHES ROLLED IN 5. INSTALLATION ======================================= 1. ABOUT THIS LIMITED AVAILABILITY INTERIM FIX ============================================== This document provides details on Limited Availability Interim Fix 5.1.0-LA002 on the following platform: WebSphere Application Server 5/Oracle IMPORTANT NOTE: ============== THIS LIMITED AVAILABILITY FIX REPLACES PREVIOUS FIX 5.1.0-LA001.THIS LA CAN BE APPLIED ON VERSIONS OF WPC PRIOR TO 5.1.0-LA001 AND IT CARRIES FORWARD THE FIXES PROVIDED AS PART OF 5.1.0-LA001, BUT CANNOT BE APPLIED ON TOP OF 5.1.0-LA001. IF 5.1.0-LA001 IS ALREADY APPLIED, YOU MUST ROLL BACK TO A PREVIOUS FIX LEVEL. 2. LIMITED AVAILABILITY INTERIM FIX REQUIREMENTS ================================================ Websphere Product Center 5.1.0 must be installed prior to the application of Limited Availability Fix 5.1.0-LA002: It is recommended to apply the Limited Availability Interim Fix to a test system to identify any issues. 3. LIST OF FIXES ================ 3.1 Fixes ============= ============================================ 3.1.1 Fixes carried forward from 5.1.0-LA001 ============================================ JR22218 Script operation category: ReorderEntry() does not work beyond the first 100 entries and certain errors reset ordering Above mentioned fix involves database schema migration. Please follow the steps given below for migration AFTER COMPLETING THE STEP 5.2(Apply Fix Pack). IMPORTANT: Compeltion of step 5.2 is required to complete this migration. However, please do not re-start the system till this step is completed. 1. Run the following SQLs via SQLPlus or any other tool alter table tctg_odd_ord_detail add odd_prev_id number(9,0); 2. Now,run the following Java executable from commmand line using the command below, from $TOP/jars directory. This program migrates the existing data for the ordering table into the new format. $JAVA_RT common.migration.OddTableDataMigration Note: It is very important to run the above said Java executable before executing the oracle scripts given below. Running the scripts below before executing the Java executable will lead to permanent data loss. 3. Run the following SQLs via SQLPlus or any other tool alter table tctg_odd_ord_detail drop column odd_order; drop index ictg_odd_2; create index ictg_odd_2 on tctg_odd_ord_detail( odd_parent_id, odd_next_version_id, odd_version_id, odd_ord_id, odd_type, odd_company_id, odd_child_id); JR22408 getEntriesInStep() exception This delivery includes a combination of code fixes, corruption detection/cleanup scripts, and usage guidelines which will help alleviate the problem of data corruption being found in a collaboration area (otherwise known as Ghost Items). The usage guidelines are provided as a separate document, and should be followed to reduce the risk of ghost item creation. The guidelines are NOT enforced in code, so the failure to comply with the guidelines will potentially result in data corruption. In addition to the guidelines, the following changes/fixes have been made: 1. There are changes in code to better handle possible error condiditons where data corruption may be the result. The extent of the changes is not comprehensive, and is related mainly to Item check-in from a collaboration area to the source catalog. 2. There have been corrections made to ensure that a workflow event can be processed only in the workflow engine process. This is provided through an enhanced signature of the checkoutEntries script operation: HashMap CollaborationArea::checkOutEntries(EntrySet entrySet, [String stepPath], [boolean waitForStatus], [int timeout]) Description Checks-out the entries in the entrySet into the collaboration area. If stepPath is not specified the entries will be checked-out into the Initial step (give the value "Initial" for this parameter if you want to give it some value, in order to use some of the subsequent optional parameters). If waitForStatus is false (which is the default), then the checkout is asynchronously processed by the workflow engine and returns null. If waitForStatus is true, then this script op will busy wait as specified by the value of the timeout parameter for the separate workflow engine process to have processed the event. The default value of timeout is the value of the wfl_engine_poll_time specified in common.properties (typically 5 seconds). The timeout parameter has an effect only in the case that waitForStatus is true; in that case, a positive timeout value supplied will be interpreted as a value in seconds. When waitForStatus is true and the checkout completes within the effective timeout, then this script op returns a HashMap of entry primary key to the status of the checkout. Each entry's checkout status is one of the following: CHECKOUT_SUCCESSFUL, CHECKOUT_FAILED, ALREADY_CHECKEDOUT, ENTRY_LOCKED or ATTRIBUTE_LOCKED. If any entry attribute needed by (the workflow of) this collaboration area is locked in some other collaboration area, then the status of ATTRIBUTE_LOCKED is returned for that entry's primary key. ENTRY_LOCKED will be returned if that primary key is locked, in the GUI for example. The other possible status values should be self-explanatory. If the waitForStatus parameter is false, or if it is true but the checkout doesn't complete within its allowed timeout, this script op returns null. 3. There have been enhancements made to debug logging which will provide insight to the IBM support team in case of certain error conditions. Please set your application's workflow logging level to debug. When in communication with IBM support in matters of workflow data corruption, please be sure to send the workflow.log file from the workflowengine_* logging directory. 4. There are ghost items detection and cleanup scripts provided with this delivery. These scripts should be used to detect instances of collaboration area item data corruption, and can be used to clean the corruption. ========================== 3.1.2 Fixes in 5.1.0-LA002 ========================== WPC00020955 Gap custom tool returns the error 'error adding child' when ordering a category with more than 100 items. JR22495 In a catalog where 'Use Ordering' is enabled, updating category properties (such as display name) leads to losing of ordering for that category. WPC00020896 When same hierarchy is selected for two catalogs, ordering of categories done under one catalog has impact on ordering of categories under another catalog. ==================== 3.2 Known issues =================== Ordering information is not maintained across versions of the catalogs: If a catalog is rolled back to a previous version, ordering done before the version is created is not maintained. Instead, system applied the ordering done in the version of the catalog pre-rollback. This is a known issue and will be addressed in a future patch. 4. LIST OF INCLUDED PREVIOUS PATCHES ===================================== 5.1.0.4 5.1.0.5-IF 5.1.0.6-IF 5.1.0.6-IF003 5.1.0.6-IF004 5.1.0-TF001 5.1.0-TF002 5.1.0.6-IF005 5.1.0-LA001 (5.1.0-LA002 is a replacement for 5.1.0-LA001) 5. INSTALLATION =============== This section provides general guidelines to apply a Fix Pack to WebSphere Product Center. Some information may differ depending on the methods used for previous installations. Contact your support representative for WebSphere Product Center with any installation issues. 5.1 Preparation Before attempting to apply the latest Fix Pack to WebSphere Product Center, the following preparation is recommended: 5.1.1 Stopping the whole application on the local machine Complete the following steps to stop the WebSphere Product Center instance: a) Check the scheduler to make sure there are no critical jobs that need to be completed. If the queue is clear, kill the scheduler manually by running the following script: $TOP/bin/go/stop/stop_scheduler.sh b) Abort the entire application by running the following script: $TOP/bin/go/abort_local.sh All services running on the local machine is aborted. The RMI registry is aborted. Note: Check to make sure all processes have stopped using the 'ps' command. Kill off any rogue "java" or "rmiregistry" processes that remain after shutting down the instance. Occasionally, it may take several attempts to kill off all java processes. Continue killing all java processes until they are all dead. 5.1.2 Backup a) Create a full backup of the current WebSphere Product Center directories before applying the Fix Pack. The Fix Pack will overwrite files that have changed. If any issues occur, the backup will allow a rollback to a previous version b) It is recommended to apply the Fix Pack to a test system to identify any issues before applying the Fix Pack to a production system c) Perform a full backup of the database before applying the Fix Pack to a production system Note: Do not delete the old WebSphere Product Center version until performing thorough testing with the new installation. 5.1.3 Delete Tomcat working directory For configurations using Tomcat, delete the Tomcat working directory using the following command: rm -rf $TOP/etc/default/tomcat33/webapps/ccd Once the working directory has been deleted, restart the application server and apply the Fix Pack. 5.2 Apply Fix Pack To apply the Fix Pack to WebSphere Product Center, complete the following tasks: a) Unpack tar file b) Run WebSphere Application Server script c) Update configuration files d) Test installation 5.2.1 Unpack tar file Purpose: To extract and update any new installation files into the current working directory Note: GNU tar is needed to untar the WebSphere Product Center files. 1. Copy the WebSphere Product Center tar file to the user or temporary directory. Example: {HOME_OF_WPC}/tarballs 2. CD to $TOP, the current working directory, and unpack the tar file: Example: Using GNU tar, the following command extracts and unzips the tar file using an absolute path: tar zxvf /home/WPC/tarballs/wpc_5001_03_fixpak_from_5000_15_was5_db2.tgz 5.2.2 Run WebSphere Application Server script After unpacking the tar file in the previous section, ensure that the default server (server1) is running and run the following WebSphere Application script: $TOP/bin/websphere/install_war.sh Note: Ensure that the default server (server1) is running, as it is required for the WebSphere Application Server script to work. If needed, start the WAS default server by issuing the following command as root: ${WAS_HOME}/bin/startServer.sh server1 5.2.3 Verify configuration files Verify all configuration files required by the new installation and make any updates as needed. Refer to the backup copy of the configuration files for the previous installation if needed. * common.properties * admin_properties.xml * init_ccd_vars.sh common.properties On startup, the system will use this file to read in all system level parameters. This file includes settings for the database layer (connection parameters), directory settings, default character sets, thread-pooling parameters, and other settings, which are documented in the file. File location: $TOP/etc/default admin_properties.xml This file is used by the administrative utilities to configure clusters of the application. File location: $TOP/etc/default init_ccd_vars.sh The initialization file is the shell script that initializes the shell variables used by the system. File location: $TOP/setup IMPORTANT NOTE: =============== Before proceeding to step 5.3, please complete the schema and data migration for the fix JR22218(details in section 3.1). Starting the system without doing the migration may lead to data loss. 5.3 Test installation 5.3.1 Start WebSphere Product Center To start the WebSphere Product Center, execute the following script: $TOP/bin/go/start_local.sh The script starts all the services needed to run WebSphere Product Center. Note: This process should take approximately 30-40 seconds, depending on the speed of the processor. 5.3.2 Check status Run the $TOP/bin/go/rmi_status.sh script that was provided by WebSphere Product Center and verify the following services have started correctly. * admin_ * appsvr_ * eventprocessor * queuemanager * scheduler * workflow YOU HAVE SUCCESSFULLY APPLIED THE LIMITED AVAILABILITY FIX FOR WEBSPHERE PRODUCT CENTER!