UniVerse v11.1.10 released
UniVerse v11.1.10 has been released for the following operating systems:
- AIX POWER 5.3, 6.1, 7.1
- HP/UX Itanium 11.23, 11.31
- Windows x86 XP (SP3), 2003 (SP2 R2), VISTA (SP2), 2008 (SP2 R2), Windows 7 (SP1)
- RedHat Enterprise Linux x86 5, 6
- SuSE Linux Enterprise Server x86 11.0 (SP1)
- Solaris SPARC 10
- Solaris x86 10
- HP/UX PA-RISC 11.23, 11.31
This release addresses the following issues:
UniVerse -- Several UniVerse supplied BASIC programs, including BACKUP, DEVICE.MAINT, DO.VCOMM, SETUP.VCOMM, TRANSFR.ACCT, VCOMM.INIT, and TIMDAT contained unassigned variables. The unassigned variables might result in "variable not assigned" errors when using the UniVerse System Administration Menu. These problems have been fixed.
UniVerse BASIC -- Using the UniVerse BASIC SELECTINDEX statement with the syntax to save the select list to a variable (i.e. "TO LISTNAME") might cause the UniVerse session to abort under certain conditions. If the dictionary item specified with SELECTINDEX statement was not an indexed field, in a Pick flavor account on Windows an unhandled exception and access violation occurred. This failure was due to a memory problem with an internal runtime variable, and has been fixed.
UniVerse -- On Linux platforms only, the "Start the rpc daemon" option from the UniVerse Administration menu might incorrectly indicate the unirpc daemon was already running and not allow it to start. This problem has been fixed.
UniVerse Transaction Logging -- Before this release, the MKFILELIST command did not handle multi-level files. The list of files to be activated for transaction logging included the top level directory rather than the sub files. The MKFILELIST command will now correctly include the sub files in the generated select list.
UniVerse BASIC -- The UniVerse BASIC RELEASE statement may have leaked 4 bytes of memory when executed against a file that is a member of a distributed file. This leak only occurred when the syntax of the RELEASE statement included the record key, such as "RELEASE File,Key." This problem has been fixed.
UniVerse Transaction Logging -- Prior to this release, the MKFILELIST and ACTLIST commands used with UniVerse Transaction Logging did not properly handle dictionary only files. The VOC pointer for a dictionary only file has the dictionary defined in field 3 and the data definition in field 2 is empty. The empty data file definition caused these files to be skipped. The MKFILELIST and ACTLIST commands will now correctly process dictionary only files.
UniVerse Transaction Logging -- A problem was discovered when the VOC entries for dictionary files included the dictionary name in field 3 and field 2 defining the data file was empty. Prior to this release, the MKFILELIST and ACTLIST used with UniVerse Transaction Logging did not properly handle a dictionary only file. The MKFILELIST and ACTLIST commands will now correctly process dictionary only files.
UniVerse -- Before this release, the LONGNAMES ON command did not always take effect until you logged out and logged back into UniVerse. This command will now take effect immediately.
UniVerse -- Beginning at this release, the default entry for the uvrpc port is automatically added to the /etc/services file on UNIX platforms during the UniVerse installation, as in the following example:
UniVerse -- At this release, the uv -admin command has been implemented on Windows platforms:
uv -admin -start [-init] starts the UniVerse Resource Service and the UniVerse Telnet Service. The -init option starts the uvrepmanager with the -i option.
uv -admin -stop stops the UniVerse Resource Service and the UniVerse Telnet Service.
UniVerse -- On Linux platforms only, when SUSPEND.FILES was enabled, UniVerse processes may have consumed 100% of the cpu when the SUSP_IO_WAIT time expired and file I/O was still suspended. This is not a new problem. However, the issue was more likely to occur since the introduction of the SUSP_IO_WAIT uvconfig parameter which allows setting the wait time less than the default of 60 seconds. This problem has been fixed.
UniVerse -- When connecting to UniVerse through telnet, the connection failed if the license limit was exceeded, but no message was displayed indicating the reason for the connection failure. This problem occurred because the socket was closed so quickly that the message could not been seen. A delay has been added so the message should now be visible prior to the connection being closed.
UniVerse SQL -- A SQL statement which performed selection criteria on an indexed field would abort immediately when the EXPLAIN keyword was included with the statement. Note, the SQL statement would work correctly if the EXPLAIN keyword was removed. This problem was actually fixed at the 11.1.5 release of UniVerse.
UniVerse SQL -- When executing a SQL SELECT statement where the TO SLIST 0 syntax was used, under certain conditions the number of records selected differed from the number of records saved by SAVE.LIST. The problem could occur when the statement performed selection criteria on an indexed field and the statement contained a sub query. The problem occurred because of an error in a global variable used in a sub query, and has been fixed.
U2 Data Replication -- Prior to the 11.1.9 release, if an update failed to be applied on the subscriber, the U2 Data Replicationlogs would indicate that the update had been cancelled. Beginning at 11.1.9, additional logging has been added to the error message to help identify the cause of the update being cancelled. For example, you may now see something similar to:
Thu Oct 25 14:34:03 RW(0,761) WRITE attempt on read-only file. if the failure was caused by a permissions issue on the subscriber. Note, this change was made in the 11.1.9 release.
UniVerse BASIC -- When using the BASIC BSCAN statement on an index file, UniVerse may have returned an error message incorrectly indicating that the index was corrupt, as in the following example:
Program "PROBLEM": Line 33, Internal file corruption detected.
File must be repaired
The problem was related to the index file being updated by other users while the BSCAN statement was being used. While there was no real file corruption, the error was fatal and caused the BASIC program to abort at the point of the BSCAN statement.
This problem has been resolved.
UniVerse -- A UniVerse READ of an item in a type 1 or type 19 file may have caused an abnormal termination of UniVerse. This problem was caused by an out of memory boundary problem that occurred when UniVerse was checking if a line ended with CR/LF. The failure was dependent on the size of the item as well as the data in the item. The problem has been fixed.
UniVerse -- Before this release, the uvtelnetd process did not populate the UNIX utmp file with the connection IP address. Due to this behavior, the Unix shell command 'who' would not include the IP address of processes initiated by uvtelnetd as it does for other telnet connections. This caused problems determining where uvtelnetd sessions were initiated. The uvtelnetd process will now correctly populate the utmp file with the IP address.
UniVerse BASIC -- On Windows platforms, if the owner of a UniVerse file was no longer a valid user, the UniVerse BASIC STATUS statement may have caused UniVerse to terminate abnormally with an "Unhandled exception..." error. This problem could be encountered if the user owning the file had been deleted from the Windows system or if domain name changes altered the user credentials. This problem has been fixed.
UniVerse -- When attempting to read a record from a dynamic file which exists in a group where the resize bit was set, UniVerse may have aborted with an unhandled exception on Windows platforms or result in an infinite loop on UNIX platforms. This situation would typically only occur if a RESIZE operation did not complete normally. At the current release, UniVerse will return to TCL and displays an error message indicating the resize bit is still set.
CallMQI -- Under certain conditions, calling the MQIINQ function and passing in multiple selectors on Windows
platforms may have caused UniVerse to terminate abnormally. This problem has been fixed.
UniVerse -- Beginning at this release, if a timeout is defined and a timeout later occurs, UniVerse now automatically writes a message to the unirpc debug log file you define similar to:
:RPCPID=909390 - 12:45:00 - UVRPC_TIMEOUT error when reading
the first packet from (IP number) '127.0.0.1'
UniVerse -- On Windows platforms, if the operating system level ownership of a file belonged to a user that was no longer valid on the system, attempting to back up that file with the UniVerse uvbackup command could fail with an unhandled exception. This problem has been fixed.
UniVerse -- Attempting to access UniVerse files on a CIFS-mounted file system would fail when accessing the files from UniVerse running on RHEL 6. The problem was not related to a specific UniVerse release as the same release of UniVerse running on RHEL 5 was able to access the files. The problem was due to a change in behavior of a Linux function at RHEL 6. The current version of UniVerse has been modified to now also handle the RHEL 6 behavior.
UniVerse -- When an environment variable which had been defined at the operating system level was cleared within
UniVerse using the ENV CLEAR command, the UniVerse session may have been abnormally terminated. On Linux platforms an error similar to the following was returned:
glibc detected uvdls: munmap_chunk(): invalid pointer:
This problem has been fixed.
U2 Data Replication -- On the HP Itanium platform only, when using the Object Updates Report of the uvreptool utility, uvreptool dumped core when attempting to start counting. This problem occurred because of an alignment issue in U2 Data Replication shared memory, and has been fixed.
UniVerse -- Beginning at 11.1.0, UniVerse saves existing logs to the saved_logs directory and creates new, empty logs when UniVerse is started. This includes the standard errlog file which exists in uvhome. A problem was discovered where all users may have been unable to write to the active errlog file after UniVerse was started. This problem was due to the permissions of the new errlog file being based on the umask of the user starting UniVerse. Now, UniVerse creates the permissions on the errlog to 666 which ensures all users have write access to the file.
RetrieVe -- On the AIX and HP Itanium platforms, executing an I-type dictionary record that was compiled prior to UniVerse 11.1 may have caused UniVerse to abnormally terminate. This problem occurred because of an internal alignment difference related to UniVerse now being a 64bit port at 11.1 on these two platforms. The alignment difference was specific to the treatment of directly coded floating point numbers (i.e. REUSE("1.02")) by the dictionary compiler and would not impact most I-type dictionary items. This issue has been fixed.
UniVerse -- A problem was discovered on AIX platforms only where a uvnetd process may have hung when trying to
initialize. This problem was due to a prior UVnet process Incorrectly marking the user number of an already existing
background process as available. If a subsequent UVnet process attempted to use the user number which had been marked as available, the uvnetd process spun in a loop and needed to be killed. This problem has been resolved.
UniVerse -- Prior to this release, the PTERM SUSP command i could only be used successfully on AIX platforms to trap the defined suspend key. The PTERM SUSP command can now be used successfully on all UNIX platforms.
UniVerse -- Beginning at UniVerse 11.1, any UniVerse process that required a printer segment had to allocate an LCT entry and put the pid and NET_signature in that LCT entry. If the NET_signature was found to be a duplicate when starting a new UniVerse process, the internal logging performed by UniVerse may have marked the wrong LCT entry as a duplicate. This problem has been fixed.
UniVerse -- At this release, the maximum disk shared memory size on Linux platforms has been increased from 32 MB to 256 MB.
UniVerse -- Due to a change made at 10.3 to fix a problem related to long running phantom jobs which spawned child phantom processes, the behavior of the NOTIFY ON command has been altered. While NOTIFY ON will continue to have the child phantom processes exit completely at the operating system level (i.e. not remain in a 'defunct' state), the "phantom complete" message is now displayed when the parent process returns to TCL. There is no software change at 11.1.10 but the changed behavior is being documented here as it was only recently reported.
UniVerse -- A problem was discovered where a user who was a member of the uvadm group could not delete temporarily created transaction cache files. This problem occurred because the temporary transaction cache files were created with an owner of uvadm. When the UniVerse process attempted to delete the temporary files, the user did not have permissions on the operation failed. The problem of creating the temporary files with the incorrect user and group permissions has been fixed.
U2 Data Replication -- If the LIST.REPLICATION.FILE filename command produced more than a single screen of output and you exit at the "Press any key to continue.." prompt, locks related to the replicated filename specified will be left set on the system. Note, if all output was displayed, no problem existed. This problem of leaving locks behind has been fixed.
U2 Data Replication -- Before this release, the uvrepmanager process dumped core if it ran out of memory when allocating the dynamic object table, with no indication of the nature of the problem. Now, UniVerse returns a meaningful message similar to the following example if this situation occurs: RM: Allocate memory failed(size=%d, errno=%d). Insufficient memory for replication manager daemon
UniVerse -- When running as the administrator on a French version of Windows 7, the performance of the ED command was slow. This problem was due to the English version of the administrator login being stored in the UniVerse login cache by default. The administrator on the French version of Windows did not match the English version stored in cache resulting in performance delays while performing the login lookup. The issue would occur on other non-English version of Windows. The appropriate administrator login for the version of Windows being used is now stored in the UniVerse login cache resolving this problem.
UniVerse -- Two problems existed regarding the REP_LOG_PATH uvconfig parameter when a UniVerse 11.1.x upgrade was performed. First, the REP_LOG_PATH parameter was moved to the bottom of the uvconfig file and separated from the comment describing the parameter. Second, if the REP_LOG_PATH value had previously been changed from the default of uvhome/replog, the new value would be lost and REP_LOG_PATH would be reset to the default. A UniVerse upgrade will now maintain the current value of REP_LOG_PATH and no longer move the parameter to the bottom of the uvconfig file.
U2 Data Replication -- Changes have been made at this release to the locking methodology used by the U2
Data Replication uvrw processes which replicate UniVerse data on the subscriber. These changes are intended to improve the performance on the subscriber under conditions of heavy lock contention.
UniObjects -- At this release, the UniObjects server log will now contain the pid of the uvapi_slave process being started as well as the user name starting the process to assist in troubleshooting.
UniVerse SQL-- A change was made at UniVerse 11.1.5 that allowed an embedded "\n" as a newline character in an SQL statement when the statement is coming from a client, such as Business Objects. The change was accomplished by replacing the embedded newline character in the SQL statement with a space. This resulted in some issues where the newline was inside a quoted string and intentional. Beginning at this release, a newline character within a quoted string will remain a newline character. All other newline characters in the SQL statement will continue to be converted to a space.
UniVerse -- At this release, a further fix was made to the problem when starting the UniVerse unirpcd daemon with the -d# option. This is an indication that unirpcd debug and trace information will be recorded. If unirpcd was started with the -d# option and a condition occurred which caused the client connection to be interrupted because of a failure, an internal issue could cause the unirpcd daemon to hang such that no new client connections could be processed. This problem has been fixed.
UniVerse -- A problem was discovered when using TANDEM with uvapi_slave processes. These processes did not handle the input from TANDEM properly, and exited when input was required. This problem has been fixed.
In order to attach to background processes and debug UniVerse BASIC programs, you must have the following 2 lines in the UniVerse BASIC program:
Before the UniVerse BASIC program reaches the DEBUG statement, use following command to attach to the processes:
where net_signature is the output of the PORT.STATUS command. Do not enter the "0x" prefix, only use the last 8 characters, for example, ACEBAF43.
UniVerse SQL -- On Solaris, Linux. and Windows platforms, a SQL SELECT statement might dump core under certain conditions. If the UNNEST keyword was being used and the selection criteria involved a column with an index, the problem might occur. In such instances, the use of the NO.OPTIMIZE keyword in the SELECT statement eliminated the problem. This problem has been fixed.
U2 Data Replication -- Prior to this release, running the BUILD.INDEX command on the subscriber would fail if a VOC file pointer existed defining the index file. An error would occur when BUILD.INDEX attempted to update the index file. The error indicated an attempt was made to update a replicated file even though Type 25 files are not currently replicated. The BUILD.INDEX program has been modified to set a flag to not replicate updates on the index file or index directory after they are open. Therefore updates on the publishing system do not generate replication logs and the BUILD.INDEX command on the subscribing system will no longer be blocked which resolves this issue.
UniVerse -- Beginning at the 11.1 release, dynamic array substring replacement operations were reported to perform slower than at previous releases (i.e. 10.3, 10.2, etc.) on the Solaris Sparc platform. The performance change was identified to be related to compiler and compiler flags used for the 11.1. release. Changes have been made at this release and the performance of dynamic array substring replacement operations is now comparable to previous releases (i.e. 10.3, 10.2, etc.)
EDA - When a UniVerse file is converted to EDA, the original file is saved as filename.edasave. If you copied the
filename.edasave file back to filename, you could not reconvert the file to an Oracle database. This problem has
UniVerse -- Beginning at UniVerse 11.1.9, the VCATALOG command would incorrectly return an unable to open file
error and fail. This problem occurred due to an internal change made to the CATALOG command at UniVerse 11.1.9 for U2
Data Replication. The problem this change caused for VCATALOG has been fixed.
GCI -- On Solaris platforms only, the XML libraries were not built into the new uvsh created when doing a GCI make.
Therefore, attempting to use XML with the new GCI built uvsh would fail with an error similar to the following:
Program "XMLSETOPTIONS": pc = 38, Can't load
"/disk1/uv1119uvadm/bin/libicuuc.so.38": ld.so.1: uvsh.new:
fatal: relocation error: file /disk1/uv1119uvadm/bin/libicuuc.so.38:
symbol _1cGCrunKpure_error6F_v: referenced symbol not found
At this release, the GCI makefile for UniVerse on Solaris has been modified to ensure the necessary XML related libraries are included in the GCI built uvsh.
UniVerse -- At this release, additional information is written to the uvapiserver logs, including the number of bytes read from a pipe to help with debugging.
UniVerse -- When NLS was enabled on the UniVerse server, JDBC connections to the server might fail with RPC related issues. The problem was due to a memory related issue which caused the uvsrvd process on the server to abort and close the connection. The problem was introduced by a file open/close related issue fixed at the 11.1.4 version of UniVerse. This problem has been fixed.
UniVerse -- On Windows platforms only, if a user's login name was changed and the original login name existed in the UniVerse login cache, @LOGNAME incorrectly returns the original login name. Now, if the user's login name does not match the login name and domain name for the SID stored in the UniVerse login cache, UniVerse deletes the old cache entry and creates a new one, correcting the problem.
U2 Data Replication -- A problem was discovered where processes may have returned error messages when attempting to access the Replication log files because the permissions on the new log files were based on the umask of the user starting UniVerse. Now, UniVerse creates the permissions on the errlog to 666, correcting the problem.
U2 Dynamic Object -- An enhancement has been made at this release which improves the performance of processes adding
objects to a U2 Dynamic Object array.
UniVerse -- Beginning at the 10.3.0 release, the ability to nest multiple IF/THEN/ELSE/IF clauses in an I-descriptor
expression was limited compared to earlier releases. For example, at 10.3, an I-descriptor expression similar to the
following would not compile when the number of IF statementsreached approximately 30.
0002: FIELD(@ID,"#",2);IF @1 = "A" THEN 1 ELSE IF @1 = "B"
THEN 2 ELSE IF @1....
The above example was similar to a distributed file partitioning algorithm where the problem was first noticed. Changes have been made at this release to allow such I-descriptor expressions to compile.
U2 Data Replication -- If a published file contained only one virtual field index and that virtual field index returned an empty string, the index was incorrectly reevaluated on the subscriber, even if RW_REEVALUATE_VF was set to 0 in the repconfig file. This problem has been fixed.
UniVerse BASIC -- At this release, an enhancement has been made to the getSocketInformation() function. The socket's operating system file descriptor is now returned in the 7th multivalue of the output parameter.
UniVerse BASIC -- Beginning at 11.1.6, under certain conditions, a READU lock may not have been released on a DELETE statement. The conditions involved a primary file containing a virtual field index that called a UniVerse BASIC subroutine. Under these conditions, UniVerse did not release an active READU lock on the record when it was deleted. This problem has been fixed.
NLS -- Beginning at UniVerse 11.1.9, if NLS Locale functionality was enabled, UniVerse did not format numbers correctly. For example, with a FMT specification of "10R1", the value "0.0" would be incorrectly formatted as "0" rather than "0.0". This problem has been fixed.
UniVerse -- At this release, the UCI64.a library has been added to Linux platforms, allowing users to link their
applications with UCI on 64-bit Linux platforms.
UniVerse -- When installing UniVerse on a 64-bit Windows 7 system, the "failed to setup UniVerse Error:1" dialog box may have appeared, and error messages appeared in the install.log file. This problem occurred if the UniVerse service took a while to start which would cause certain UniVerse functions executed by the install process to fail. Now, if the status of the UniVerse service is not started, the internal function sleeps for 1 second and retries up to 60 times. This will ensure the required UniVerse service has been started before the install process continues and executes UniVerse functions.
UniVerse -- An issue was introduced at 11.1.9 where PORT.STATUS would no longer display active UVCS and UVNET users on Windows platforms. This problem has been fixed.
UniVerse -- Beginning at UniVerse 11.1, updating a distributed file that contained a trigger and an index may have failed in multiple ways. The UniVerse process may have abnormally terminated, orphaned locks with invalid keys may have been left in the lock table, the UniVerse process might hang, or a fatal error due to corrupted transaction cache may have occurred. The problem was caused by memory corruption due to Bthe value of a variable being changed during the evaluation of the virtual field index or trigger. The value is now saved and reset after the evaluation so the proper value is maintained and the memory corruption is eliminated.
U2 Data Replication -- In certain situations, some replication processes may have hung on the subscribing system. The problem
occurred when a uvrw process was trying to obtain a record lock, but the lock was held by another process. The uvrw
process went into a wait queue until the lock was released and then tried to obtain the lock. However, if a FILELOCK
operation had occurred, an exclusive lock was placed on the file and uvrw process could not obtain the lock and returned to the calling function. This problem has been fixed.
U2 Data Replication -- If a zero-length record was written to a replication file, a file lock was incorrectly set on the
file on the subscribing system. This problem has been fixed.
UniVerse -- Beginning at release 11.1, record IDs may have been duplicated in an alternate key index, causing items to be selected more than once. The problem occurred when the file contained a virtual field index, a trigger, and updates to the file were done within transaction boundaries (i.e. BEGIN TRANSACTION..... END TRANSACTION). At the time of update, the original value of the virtual field index was not correctly compared with the current value resulting in the record ID being inserted into the index again. This problem has been fixed.
UniVerse -- A problem existed prior to 11.1.10 when an encrypted index on a UniVerse file was based on a calculated field. Under those conditions, updates to the data file could result in record ID values being duplicated in the index, or not being removed when the record was deleted. A calculated field can be an I-type dictionary item or a PICK-style "A" or "S" type dictionary that contains a correlative in field 8.
For example, an encrypted index based on the I-type expression "OCONV(F2,"MCU") or an "A" type dictionary with "MCU" in field 8 would have caused this problem. No problem existed if field-level encryption was active on fields in the file other than the indexed field. However, if you were using WHOLERECORD encryption, the index is encrypted by default, and the problem would have occurred. This problem has been fixed.