Rocket Business Connect

1410020
A serious defect affects all platforms of UniVerse 10.3.6 and 10.3.7.

Beginning at release 10.3.6, an issue has been detected which can occur when the uvconfig UVTSORT parameter is set to 1. If a sort operation (i.e. SORT, SSELECT, etc.) is performed where the number of records being sorted exceeds the uvconfig QSRUNSZ parameter (default value of 2000), the user shared memory segment will be marked for deletion when the sort process completes. This results in the following known side effects (there may be others as well).

1. If the user performing the sort held locks at the time of the sort, the LIST.READU command will no longer display the pid and user id of the user owning the readu lock. This can cause significant issues attempting to trace lock ownership.
2. More importantly, once the shared memory segment is marked for deletion and the user holds locks, if they execute an external command (i.e. LIST.READU, BASIC, CREATE.FILE, etc.) the record locks will be RELEASED allowing other users to gain access to the records.
3. Once the user shared memory segment has been marked as deleted, using the CREATE.FILE command in prompting mode will not function as expected. Input data will not be echoed to the screen and the line feed normally issued after each prompt will be missing. The following is an example of this behavior.

>CREATE.FILE DATA TEST.FILE

Please enter the following information for the DATA file:

Modulo = Separation = File type = File description =
Creating file "TEST.FILE" as Type 18, Modulo 101, Separation 4.

For this issue, it is recommended that the UVTSORT uvconfig parameter be set to 0 if running any of the effected releases. This can be done by stopping UniVerse, modifying the uvconfig file to set UVTSORT to 0, executing the uvregen command, and then restarting UniVerse. This change should not cause a major impact on the performance of your application.