************************************************************************************ IBM DB2 Digital Library 2.0 CSD2 for AIX March 21, 2000 This is a formal Corrective Service Delivery that will bring all systems at the syslevels described in the Installation Requirements to 2.3.2.0 (syslevel 2.3.2.0) Table of Contents: 1. Installation Requirements 2. Installation Instructions 3. APAR Fixes with Descriptions ********************************************* 1. Installation Requirements ********************************************* This CSD is for AIX. In order to install this CSD, you must have the following product base level installed: a) Digital Library 2.0 with CSD1 applied (syslevel 2.1.2.8246.UR50030) ********************************************* 2. Installation Instructions ********************************************* 1. Download the dl2320.tar.gz file in binary mode to a temporary subdirectory on your workstation. You will need at least ??MB of free space in your temporary directory. 2. To unpack the GZIP compression, enter: gzip -d dl2320.tar.gz If you don't have GZIP, you can obtain this freeware tool from: http://aixpdslib.seas.ucla.edu/aixpdslib.html 3. Unpack the dl2320.tar file into your temporary subdirectory using the AIX tar utility. For example: tar -xvf dl2320.tar 4. Log in as root. 5. Start the Installation wizard by entering ./frnxupdate.sh ************************************************** 3. APAR Descriptions ************************************************** APAR NUMBER: IR41002 COMPONENT: Object Server PMR NUMBER: 99999 APAR DESCRIPTION: Lan cache file copies not left when migrating files from staging area to remote server. Some perfotmance degradation caused if server must cache a copy on a subsequent retrieve request. Impact will vary depending cache usage. FIX DESCRIPTION: Internal value incorrectly translated. Should be applied to all Lan Cache systems. APAR NUMBER: IR40730 COMPONENT: Library Server PMR NUMBER: 55189 APAR DESCRIPTION: The problem was cause by data that was inserted into library server by the migration utility. The problem index classes were never 'created' as such. They were inserted into the library server database by the migration utility and due to an error in the utility they had userid value which was not in the database. If the index classes had been 'created' via sys admin or using the APIs, the proper userid would have been specified. When the user that created the index class is deleted, the userid filed is set to zero which is value that is reserved and never exposed to the user and will always be there. So the problem described will never happen. To fix this APAR, I have fixed the migration utility to set userid field to zero. FIX DESCRIPTION: To fix this APAR, I have fixed the migration utility to set userid field to zero. APAR NUMBER: IR41326.23 COMPONENT: Object Server PMR NUMBER: 65126,032 APAR DESCRIPTION: This data is entered by R. Simunic for Ingo Grassmann VI Statistics don't get updated correctly, when documents get destaged and purged from staging area. The used size of the staging area is calculated wrong. New documents are added with the size in full 4KB blocks that they use, but when they get destaged and purged, only the real size is subtracted. e.g.: a new document has size 18441 bytes. In an AIX filesystem it needs 5 * 4 KByte blocks = 20480 bytes (assuming default block sizes) For calculation of the space used in the staging area VI addes this 20480 bytes to the internal statistics. But when this document gets destaged, Vi only decreases it by 18441. FIX DESCRIPTION: Fix lbscmn.c and lbspurgr.c size calculation. IR41239.v23 - AIX APAR NUMBER: IR41126 COMPONENT: Library Services - AIX PMR NUMBER: 37697 APAR DESCRIPTION: The FRNXLBPR process can receive a signal 'PIPE' or '13' if the client hangs up during the dataexchange across the TCP socket. The current code for the FRNXLBPR process does not handle this signal. In AIX unhandled signals cause process termination. FIX DESCRIPTION: The FRNXLBPR process can receive a signal 'PIPE' or '13' if the client hangs up during the dataexchange across the TCP socket. The current code for the FRNXLBPR process does not handle this signal. In AIX unhandled signals cause process termination. APAR NUMBER: IR40377 COMPONENT: Toolkit PMR NUMBER: 50589,005,000 APAR DESCRIPTION: Running Multi-thread application or multiple multi-process applications to retrieve/update same or different objects concurrently to files, sometimes fails. If running a multi-thread application or a bunch of multi-process applications, and try to retrieve/update same or different objects concurrently to files, not all of these will be successful. Most of them will be successful, but some will fail. This is after applying APAR IR40115 fix. Without that APAR fix, the whole thing can fail. FIX DESCRIPTION: APAR NUMBER: IR41126 COMPONENT: Library Services PMR NUMBER: 37697 APAR DESCRIPTION: The FRNXLBPR process can receive a signal 'PIPE' or '13' if the client hangs up during the dataexchange across the TCP socket. The current code for the FRNXLBPR process does not handle this signal. In AIX unhandled signals cause process termination. FIX DESCRIPTION: APAR NUMBER: IR39876 COMPONENT: Library Server PMR NUMBER: 00768,001,865 APAR DESCRIPTION: After V231 migration utility is used, clients timeout on logon if Oracle is the database. FIX DESCRIPTION: Fixed the update of the SBTCLASSDEFS and SBTVIEWDEFS INSTALLATION INSTRUCTIONS: Do not use the frnxmill.oracle.sh from the CD-ROM under the Migration directory. Use the one supplied with this APAR fix. APAR NUMBER: IR40445 COMPONENT: Object Server PMR NUMBER: n/a APAR DESCRIPTION: During run and recovery synchronization it will update the base object table and prevent object server from coming up defect 12776 FIX DESCRIPTION: No update on base_volume table subdir. APAR NUMBER: IR40470 COMPONENT: Library Services PMR NUMBER: 42255,010,618 APAR DESCRIPTION: Client using unsupported codepage hangs the library server during logon. FIX DESCRIPTION: Valid codepage conversion will be tested. IF an invalid codepage combination is in use, the request will be rejected with ISOERR_CONVERSION_NOT_AVAIL 9054. IR40698 - AIX APAR NUMBER: IR40425 COMPONENT: Object Server PMR NUMBER: n/a APAR DESCRIPTION: The migrator ends its cycle prematurely (stalls) if the last object in a batch cannot be migrated. In a system where many migrator errors occur, this can prevent the migrator from ever processing some objects and reduces migrator throughput. If all objects in a batch failed the migration, then the rest of objects will not be migrated not even at the next cycle. This is because the entire failing batch will be reselected again at the next cycle. FIX DESCRIPTION: After issueing a migration failure message (FRN9816) for a single object, the migrator will ignore the failure and continue to process other migration candidates. APAR NUMBER: IR40445 COMPONENT: Object Server PMR NUMBER: n/a APAR DESCRIPTION: During run and recovery synchronization it will update the base object table and prevent object server from coming up. FIX DESCRIPTION: No update on base_volume table subdir. APAR NUMBER: IR40448 COMPONENT: Toolkit PMR NUMBER: n/a APAR DESCRIPTION: SimLibCreateItem API returns control before the DB2 commit is complete on the object server. A SimLibGetItemAffiliatedToc is getting object not found. FIX DESCRIPTION: Change the code in fopcopy2.c to avoid bad return code within. This way all API calls within Ip2StartTrnsaction and IP2EndTransaction will not have bad return code from the Library Server, hence will not roll back. APAR NUMBER: IR40011 COMPONENT: Object Server PMR NUMBER: 76994 APAR DESCRIPTION: Running VI 231 (base) windows client with image cap software (custom code) makes each page of the object 1 part. Thus causing the customer only to view 50 pages. The customer is unable to view page 51+. VisualInfo 231 (base) and vi 2311 has limit of 50 parts/elements. FIX DESCRIPTION: List manager code has been changed to allow the maximum number of elements configurable. Also, memory leak fixes have been applied. Users can export FRNDMNCFGOS=n (where n > 5) to determine maximum number of objects that can be opened at any time. Internally we multiply the value of n by 20 to come up with this number. For example, if you export FRNDMNCFGOS=8, the maximum number is 160. APAR NUMBER: IR38768, IR38769 COMPONENT: Library Server (DB/2 Server only) PMR NUMBER: n/a APAR DESCRIPTION: Under some timing circumstances, Ip2GetNextWBItem API would return an item that is no longer in the wb. FIX DESCRIPTION: We have moved the WB query to a different package and bound it with isolation level of read stability. APAR NUMBER: IR38826 COMPONENT: Toolkit (DB/2 Server only) PMR NUMBER: 46218 APAR DESCRIPTION: Under some circumstances Ip2GetNextWBItem returns a wrong item. If multiple users use Ip2GetNextWorkBasketItem to look at the same work basket concurrently, and one user checks this item out, this item ID still shows up for the other users. When other users try to work on this item, they get bad return code saying this item has been checked out already. FIX DESCRIPTION: Update implemented to conditionally leave the transaction open when querying the information from the server, then end the transaction. APAR: IR40403 COMPONENT: Library Server PMR NUMBER: n/a APAR DESCRIPTION: When an index class is deleted, the related views remain defined in the database catalog. FIX DESCRIPTION: When an index class is deleted, all views associated with that index class are also deleted. APAR NUMBER: IR40382 COMPONENT: Object Server PMR NUMBER: 03066 APAR DESCRIPTION: Migrator crash with core dump 1 doc is already on 3995 but it's marked out as delete. The migrator tries to delete an object but msg: FRN9860 occurs. After several times the migrator crashes. The document can not deleted by ADSM. FIX DESCRIPTION: Added extra checking for communication termination with Isolator APAR: IR39026 COMPONENT: Object Server PMR Number: 43682,057 APAR DESCRIPTION: The frnxlbpu process terminates prematurely. As a result the staging area will fill. The frndiag.log may show 9930 messages just before the failure occurs. If the staging area goes full clients may appear to hang and timeout during store or replace operations on blobs. FIX DESCRIPTION: Purger was incorrectly handling messages from processors requesting space. Behavior of the system is now changed. 1. Purger and Destager will honor disabled state at all times except when enabled or started by an administration client or during start up of server when they destager and purger will enable approximately 1 minute after startup. It is the Administrators responsibility to enable the processes if he disables them. 2. A Store operation will check the staging area purge start limit. If found to be over the start limit the store will attempt to notify the destager to start the destage operation. Destager will then notify purger at theend of the destage cycle. 3. Messages requesting destage or purge operations received when the operation is in progress will be discarded or answered with an error code as appropriate. 4. Only the first process requesting space when the purger is enabled and not running will be posted when the space is available. All others will be returned a 9930 error indicating insufficient space currently available. Destager and Purger will run and rectify space constraint if possible. Practical Implications. 1. Destage operation will happen at either purge start limit or by time idle setting. Small values for time idle causing destager to run very frequently should be avoided as they will slow down overall system performance. Destage frequency/time idle on systems where stores are occuring through out the day may find a very large value to be the most satisfactory. As destager will run as needed. 2. Purger time idle on systems read mostly should be set for a frequency such that the staging area never reaches 100% full but does not cycle too frequently. Small values for frequency/time idle will degrade system preformance. For most systems a value of less than 30 may indicate that the staging area size should be reviewed. 3. Most systems should find the staging area maintained closely within the percent start / stop bounds of the purger regardless of large values set for frequency/idle time for destager and purger. APAR: IR39391 PMR Number: 24800 COMPONENT: Object Server Problem description: Object server is unresponsive or is hung. Shared memory is not being released eventually causing an out of memory condition. FIX DESCRIPTION: Mounter was not freeing small amount of memory due to incorrect reference counting caused by underlaying api layer change. APAR: IR37770 PMR Number: 12687,060 COMPONENT: Library Services (AIX 4.2.1) APAR DESCRIPTION: When starting any of the following: library server, object server, sms server or object server database recovery, the following messages are issued: FRN7282A and FRN9035A. The application terminates, and a subsequent process listing shows that one process is left running: the comm. isolator frnxliis. If the communications isolator is first started from the command line and the server startup script is started afterwards (and pause for, say, a second between these two actions) the server starts without problems. FIX DESCRIPTION: The server process needs to bring up isolator process frnxliis. While waiting for frnxliis, the server process might get interupted by the operating system. Modification has been made to handle operatint system interupt. APAR: IR39865 COMPONENT: OBJECT SERVER APAR DESCRIPTION: The Destager will not destage the objects if the size is zero length. Destager will have a error msg in frndiag.log. Recovery will not update the base_object's size if the size is not match. FIX DESCRIPTION: The Destager will check the size of the object in the staging area. The destager will not destage the object if the size is zero. Recovery will not update the base_object's size, if the size is not match. TRADEMARKS *IBM, ImagePlus, VisualInfo and OS/2 are trademarks of the International Business Machines Corporation in the United States or other countries. **Microsoft, Windows, and the Windows 95 logo are trademarks or registered trademarks of Microsoft Corporation. All other marks are the properties of their respective owners.