Date: 10-01-2012 Subject: RELEASE 9.6 DATA Manager Files These release notes pertain to the following programs or files: SUNDM.EXE 9.6 01 Oct 2012 9,6,0,500 SUNDM64.EXE 9.6 01 Oct 2012 9,6,0,500 SUNWSRV.DLL 9.6 01 Oct 2012 9,6,0,500 *============================================================================== The following files have been changed as noted: ------------------------------------------------------------------------------- SUNDM - Modified the Data Manager to support the AAM Cancel character feature that allows an AFILE READ to be aborted. In order for this feature to work as expected, both the client runtime and the Data Manager must have a version of 9.6 or later. - Added a new command option named '-w[n]' that can be specified before other commands to identify the number of seconds to wait before exiting the Data Manager. The '-w' option must be specified after a CFG file if it is used and before other command options. If the [n] wait value is not specified, the '-w' command waits 3 seconds as the default. Format: sundm [cfg name][-w[n]] - - Modified the HTTP instruction to support a new input keyword named '*HTTPAUTH={svarlit}'. This keyword must contain the 'username' and 'password' packed into the {svarlit} with a ':' delimiter. Therefore, the {svarlit} data is formatted as 'username:password'. The HTTPAUTH data is put into the HTTP message as input provided as a HTTP Basic Authentication record. Note: The HTTPAUTH keyword ONLY takes affect and sends an AUTHORIZATION header field when the {flags} bit definition specifies the HTTP/1.1 protocol type and raw mode is not being used. Example: xFlags INTEGER 4,"0x00000010" HTTP HostName, ResourcePath, *Flags=xFlags: *Result=Response: *HTTPAUTH="myuser:mypassword" - Modified SQLIO access to the SQL Server database engine to support the SQL data type of NCHAR which is identified as the National Character Set. For SQL Server, the NCHAR SQL data type is stored in the database tables as UTF16. For PL/B SQLIO, two new SQL data types have been added as follows: 13 - SQL_NCHAR_T This data type is a NCHAR SQL type where any trailing blank UTF16 characters are truncated. The NCHAR SQL type for the SQL Server specifies that the National Character Set is to be used and data is stored as UTF16 characters in the SQL tables. 14 - SQL_NCHAR This data type is a NCHAR SQL type for the SQL Server that specifies that the National Character Set is to be used and data is stored as UTF16 characters in the SQL tables. Note: 1. The SQL NCHAR and NCHAR_T data types are being implemented to allow data using national characters sets (like Hebrew) to be stored and retrieved from the SQL tables using PL/B READ and WRITE instructions. 2. When the SQL NCHAR or NCHAR_T data type is specified for a column, the field/variable data to be written by a PL/B WRITE operation MUST be given as UTF16 characters. In this case, all data MUST be 2 bytes for each character. eg A 10 character NCHAR field requires a DIM size of 20 bytes. 3. When a NCHAR or NCHAR_T data field is being retrieved using a SQLIO READ instruction, the *ABSON MUST be used. In this case, the SQL NCHAR data is stored into the PL/B DIM variables as UTF16 data. The actual data transferred from the record into and back from the SQL table column with a NCHAR/NCHAR_T is not modified in any way. Therefore, the NCHAR/NCHAR_T fields must be read using the *ABSON control to insure the UTF16 is unchanged when it is stored into a DIM variable. 4. When declaring a NCHAR or NCHAR_T SQL type in the schema definitions, the data size must be specified as the PL/B DIM size required to hold all of the 2 byte UTF16 characters. This means that a DIM size of 10 characters is required for 5 NCHAR characters stored as UTF16 characters. Thus, schema definition size for a SQL NCHAR/NCHAR_T must be specified as a multiple of 2. eg The NCHAR schema size is 10 characters that is required for a DIM variable size that is used to hold 5 UTF16 characters. 5. ISAM PL/B instructions are supported when using the SQL NCHAR and NCHAR_T data types. 6. When using the NCHAR/NCHAR_T SQL types, the following errors can occur as follows: I86 subcode 24 The filed size of a SQL_NCHAR or SQL_NCHAR_T column is not a multiple of 2 when the schema column is created. I86 subcode 44 A file with a SQL_NCHAR_T or SQL_NCHAR column is opened or prepared on an unsupported driver. The National character set support is not available on all database engines. I86 subcode 45 An AAM file with a SQL_NCHAR_T or SQL_NCHAR column in the key specification is opened or prepared. The AAM key specifications can not include a field/column using these data types. 7. When using the SQL_NCHAR or SQL_NCHAR_T data type, the following limitations are defined: a. Only the SQL SERVER is supported. An I86 subcode 44 error will occur for SQLite and MySQL database engines using these data types. b. New Sunbelt DBFILE drivers are required to support these SQL data types. The sunwado.dll and sunwodbc.dll drivers have been modified to support these SQL data types. c. The new SQL types cannot be used in AAM key specifications. d. Any PL/B instructions that are used for SQLIO operations to process data for these data types can not be used for non-SQLIO operations (i.e. native disk I/O). This means that normal native disk I/O does not support UTF16 data required by the SQL_NCHAR and SQL_NCHAR_T data types. - Modified the FILTER instruction expressions to allow the data from a left operand that is a column/field name to be compared as a string to the data from a right operand that is a column/field name. In this case, the data from the right operand is retrieved and a string comparison is performed to the data of the left operand up to the size of the smallest operand. - Corrected a problem for SQLIO where a SQL_DATETIME mask was not being used as a default to format the data for a SQL_DATETIME field. - Corrected a problem for SQLIO using the SQL Server database engine where the data being READ for a SQL_DATETIME field was not being formatted properly. - Corrected a problem where the READKS instruction would set the OVER flag erroneously when the previous READKS instruction encountered a FORMAT error that was trapped and ignored by a PL/B application. - Modified the READKP instruction to cause the OVER flag to be set for subsequent READKP instructions after an IO error for the ISI file occurs and is trapped/ignored by the PL/B application. - Corrected a problem where the READKEY would return an unexpected result after a READKS or READKP instruction caused the OVER flag to be set because there are no more keys to be found in the ISI tree. In this case, the READKEY should return a NULL variable result. - Corrected an issue where a blank key on an IFILE READ was not being set to a 0 value for SQL numeric fields when using SQLIO. This problem would cause an unexpected I86 error for the IFILE READ when using SQLIO. ------------------------------------------------------------------------------- SUNDM REPLICATION SUPPORT - Modified the replication servers to default to use the Version 2 support that allows multiple communication channels to be used for replication operations. With this change, the V2_REPLICATION keyword has to be set to the OFF state to use the Version 1 replication mode that only allows 1 primary channel when communicating with the secondary/backup servers. - Modified to put the WAL directory in the log file when the DM server is started. - Modified the log entries for WAL file errors to include the OS error code value for the error. - Corrected a problem on a Secondary replication server where a replicated file was being left open unexpectedly. This problem would prevent the file from being opened directly in an application. - Corrected a GPF error that could occur on a Secondary replication server when a small IDLE_CLOSE time (like 10 seconds) was being used and the Secondary replication server was a threaded executable. - Corrected a SEGV error that would occur when a Secondary replication server was continuing to execute using the version 2 replication protocol after a Primary replication server had encountered an initialization problem and had stepped down to use the version 1 replication protocol. - Corrected a caching problem at the Primary replication server that could prevent a file from being replicated properly when the file was continually growing via a FTP file transfer to the primary server. -------------------------------------------------------------------------------