Technical Notes |
|
This document describes important information about version 9.8 of Verastream Integration Broker. In addition to this document, please see the file vsreadme.txt, located in the root folder of your product CD for further information.
This section includes updates that affect your Verastream Integration Broker product installation.
1. Create a library called VERASTREAM.
To prevent permission problems, you must also change the ownership of the installed files and directories to the new user and verify that your applications and data files are accessible to the new user.
When you uninstall Verastream, only the originally installed files are removed. None of the files created or modified when Verastream runs, such as snregtab.dat, vscsx.cfg, or log files, are removed.
If you subsequently install the new version of Verastream in the same location, any files still present in the Verastream directory may cause errors or unexpected results. Remove these files to prevent these errors.
Verastream Integration Broker version 9.8 is supported on the following additional platforms:
Oracle 10g is supported on the following platforms:
Sonic MQ version 6.1 is supported on the following platforms:
Upgrading by installing over an earlier version is not supported. The Verastream installation program for MS-Windows will not install Verastream in an installation directory that contains a different version of Verastream.
Axis-related jar files are no longer placed in the java folder of the VIB installation. Instead, the AXISCLASSPATH parameter is defined in the sn.ini. If you want to consume a web service with Axis in the Verastream Java VM, you can add it to your path. For example:
VSCLASSPATH=...;%AXISCLASSPATH% You do not have to add the Axis jars to the class path if you are providing a web service.
During the component adapter configuration for Verastream Host Integrator (VHI), the default version of the adapter is the same as the installed VHI product. If VHI is not installed, the default is version 5.0.
On Itanium, the native float or double format is IEEE; on Alpha, the native float or double format is F_FLOAT/G_FLOAT. By default, the RMS COBOL, RMS, and Datatrieve adapters use the native format. However, when VIB tries to access a table from a platform other than the one on which it was created, an option is necessary to indicate the difference. The table and database object option DOUBLE_FORMAT=[IEEE_T_FLOATING|G_FLOATING] can be specified for this purpose.
Example:
TABLE alphaTable TYPE=rmc OPTIONS='DOUBLE_FORMAT=G_FLOATING' DATABASE itaniumTables TYPE=RMSCOBOL OPTIONS='DOUBLE_FORMAT=IEEE_T_FLOATING'There is a new RMS and RMS COBOL option: UPD_UNLOCK=[yes|no], default yes. By default, UPD unlocks the current record, even if it was not originally set by UPD. A lock set by function LOCK would also be removed. Now, when UPD_UNLOCK=no is specified, the lock can only be removed if it was set by UPD.
There is a new option called AUTO_ORDER (AUTO_ORDER=[yes|no], default no). This option is only valid for SQL-oriented databases. When AUTO_ORDER is set to yes, an ORDER is forced on each SQL statement, created as a result of FIRST, and so on, when no explicit ORDER is set. This option replaces variable MSQLNOAUTOORDER. See also the information about AUTO_ORDER in the description of TRUNCATE, below.
This function deletes all records from the current one until the end of the file. When available, an RDBMS specific function is used to accomplish this. For example, 'DELETE FROM <table> [WHERE <clause>]' for SQL based databases or sys$truncate() for RMS tables on OpenVMS. Without specific RDBMS functionality, NEXT/DEL is executed internally.
Sequential files do not support the deletion of an individual record (VSL function DEL). It is possible, however, to delete all records from the current record until the end of the file. The function TRUNCATE was created for that purpose.
For SQL-oriented databases only: when an ORDER is available (either set explicitly or by setting AUTO_ORDER to 'yes'), the SQL statement for TRUNCATE will use a WHERE clause that is able to delete records from the current one through the end of the table.
When option AUTO_ORDER is set to no and there is no specific ORDER set, TRUNCATE executes 'DELETE FROM <table>'. This deletes all records in the table. If no exact WHERE clause is possible to select the records from the current one until the end of the table, records will be deleted one by one. The function TRUNCATE cannot be executed in combination with an active SELECT. In that case the function will fail with an EMPARAM error message.
There is a new option called dbsetlogintime(). The option dbsettime() is intended for setting the timeout for SQL statements. A failing connection has a default timeout of 60 seconds, but with new option dbsetlogintime(n) it is now possible to alter the login response timeout value to 'n' seconds.
Example:
DATABASE sqsDbs TYPE=sqs OPTIONS='dbsetlogintime(10)' By default, the RMS and RMS COBOL adapter creates indexed sequential files. Now, there is a new RMS and COBOL database and table option called ORGANIZATION (ORGANIZATION=[INDEXED|SEQUENTIAL|RELATIVE], with INDEXED as default), which allows users to create another type of RMS file.
When you use the option ORGANIZATION, you must set it before the table is created, because the option will have no effect on a pre-existing table (the table already has a type and that type is detected automatically by the adapter).
The option VARIABLE_LENGTH (VARIABLE_LENGTH=[yes|no], default no) is valid for indexed, sequential, and variable files. In this case, too, the option must be set before the table is created.
In sequential file organization, records are arranged one after the other, in the order in which they are stored. New records created with the VSL function ADD are added to the current end of the file.
A relative file consists of a series of fixed-length record positions (or cells) numbered consecutively from 1 to n. This enables RMS to calculate the record's physical position on the disk. The number, referred to as the relative record number, indicates the record cell's position relative to the beginning of the file.
The adapter can access all types of RMS file organizations and also supports all possible access modes. The tables that follow describe the possibilities.
| |
File Organization |
||
| Access Mode |
Sequential |
Relative |
Indexed |
| Sequential |
Yes |
Yes |
Yes |
| Random by relative record number |
Yes* |
Yes |
No |
| Random by key value |
No |
No |
Yes |
| Random by record file address |
Yes |
Yes |
Yes |
*Permitted with fixed-length record format only.
| Access Method |
Description |
| Sequential Access |
Records are stored or retrieved one after another starting at a particular point in the file and continuing in order through the file. |
| Relative Record Number Access |
Records are stored and retrieved by relative record number or by file address. Records occupy cells of equal length, and each cell is assigned a relative record number, which represents the cell's position relative to the beginning of the file. |
| Record File Address Access |
When a record is accessed directly by its file address, the distinction is made by its unique location in the file; that is, its record file address (RFA). |
| Indexed Access |
Indexed file records are stored and retrieved by a key in the data record. The desired records are usually accessed directly and then retrieved sequentially in sorted order using a key embedded in the record. |
Most of the access modes are invisible and are automatically used as a result of VSL functions such as FIRST, SELECT, etc.
Random access by relative record number is possible using the new RRN option and the VSL function POSITION. Random access by record file address is possible using the new RFA option and the VSL function POSITION. Both for RRN and RFA refer to the detailed description in this release note.
Sequential files do not support the deletion of an individual record (VSL function DEL). It is possible, however, to delete all records from the current record until the end of the file. Function TRUNCATE is created for that purpose. Refer to its descrption in these Release Notes.
There is a new table and database option called RRN (RRN=[yes|no], default no). When this option is set, the first column must be an integer. It will receive the RRN for relative files and sequential files with fixed length records. POSITION with RRN is possible.
Example:
When this option is set, one column must be added as the first column in the table (not as part of KEY).
FIELD RRN int(5) FMT=NNNNNTABLE tstRRN DATABASE=tstDbs OPTIONS='RRN=yes'COLUMNS{RRNk1 KEYk2}SET RRN 79POSITION tstRRN RRNNotes:
There is a new table and database option called RFA (RFA=[yes|no], default no). When set, the first three columns must be of type integer and will receive the RFA. If RRN is also enabled, the RFA columns are 2, 3, and 4.
The RFA is a three byte short integer, unique per record. By enabling it, the RFA is read into three integer fields, that can be used with POSITION to go to a certain record and continue from there.
Example:
When this option is set 3 columns MUST be added as the first columns in the table (not part of KEY).
FIELD RFA1 int(5) FMT=NNNNNFIELD RFA2 int(5) FMT=NNNNNFIELD RFA3 int(5) FMT=NNNNNTABLE tstRFA DATABASE=tstDbs OPTIONS='RFA=yes'COLUMNS{RFA1RFA2RFA3k1 KEYk2}SET RFA1 25SET RFA2 0SET RFA3 27POSITION tstRFA RFA1 RFA2 RFA3Note: The RFA field cannot be used for anything else. No criterion is allowed on the RFA column (so no FIND). No ORDER is allowed that includes the RFA column.
A database object name can now have the value of a table type. For example, you can now specify the following:
DATABASE cat TYPE=cat and TABLE x DATABASE=catLogging has been improved in situations where a Verastream Integration Broker table definition does not match the layout of the physical table.
See Transactions and Locking in Verastream Integration Broker, Version 9.8.
In Verastream Integration Broker version 9.7, an ADD on an empty RMS COBOL table resulted in an EMFAILED error. An EMFAILED error also occurred when a SELECT was set on an 'empty' table. This error was a result of the RMS error "%RMS-F-RSZ, invalid record size". This problem has been fixed. The workaround communicated earlier by Technical Support (using "OPTIONS compdata_rec 'VARIABLE_LENGTH=yes'") can be disregarded.
SQL Server tables with spaces in the name can now be imported. Such table names are now quoted by using '[' and ']' around the name. For example: SELECT * FROM dbs.[Order Details].
When TIMESTAMP values with microsecond portions other than '000000' (the default) are read into a datetime field, the resulting error occurs: "[EMCONV] Field conversion failed." Now, these types of TIMESTAMP values can be read into a string field instead. Doing so allows the microsecond portion to be correctly retrieved. This new feature has been added for DB2 and AS4 table types (AS/400 only).
In earlier versions of Verastream, when a table definition contained property 'FILE=owner.tablename', or when a database object contained property OWNER, column names larger than 30 positions were truncated. This problem has been fixed.
The OpenVMS daemon now creates detached processes by submitting all servers and switches to a job queue.
Several queues are created when Verastream starts. The hostname$VSQ queue is set up as a generic batch queue, targeting four batch queues named hostname$VSQ1, hostname$VSQ2, hostname$VSQ3, and hostname$VSQ4. Together, these queues allow a theoretical maximum number of 1020 jobs.
The name of the queue that the daemon will use is determined by the parameter "VSJOBQUEUE". This parameter is set in the vs.com script. By default, the name of the queue is hostname$VSQ. You can change the queue name or configuration by editing the vs.com script.
The job that is submitted by the daemon to the queue is indicated by sn.ini parameter VSJOBSPEC=nova$dev:[com]vsjob.com. The job has two parameters; P1 is the default directory and P2 is the command line that is executed. If the process is registered to run as a different user than the daemon, the daemon will submit the job to run as that user (requires CMKRNL privilege).
You can now stop any VIB VCP server by invoking the STOP method. The STOP method is recognized as a special case by the VIB engine. If a VCP server receives a STOP method, it will invoke the CLOSEME event, which typically causes the component to end execution. The STOP method is used by CSX switches to stop the servers after the configured (server idle) timeout has elapsed. The STOP method can also be invoked on a running CSX switch, and this will stop the switch. Note that, depending on the configuration of the switch (i.e., non-standby), a new switch may be started immediately.
To invoke the STOP method, use the VIB VCP Component Directory Explorer. Right-click on the server instance and choose Stop on the pop-up menu.
If, for any reason, you do not want a VCP component to honor the STOP method, you have three options:
The STOP method is not available in C and Java VCP components. Because it is a normal method call, you can easily create the method yourself. The signature of the method is:
METHOD STOP ARGUMENTS { reason FIELD FORMAT=string }The older "stop" method (lowercase) is no longer supported by the VIB VCP Component Directory Explorer.
The Java VCP library can now be used in multithreaded mode. The VCP client object will create a thread itself when used in multithreaded mode. Because creating a thread is not always desired or allowed, the new multithreaded mode must be turned on explicitly. You can do this by calling the method setMultiThreaded(true) before connecting. In multithreaded mode, the VCP client will not handle VCP events. The VCP object will make concurrent calls on a single socket. You must use a CSX switch to forward such calls to multiple servers.
When the VCP object is in multithreaded mode, it also supports failover. You do not have to explicitly connect() the object to the server; the first call will connect automatically. If the connection is lost, the next call will automatically reconnect.
With these changes it becomes easier to write a servlet that makes calls to a VCP server. For example, store the VCP object in the servlet's sessionContext, and augment the VCP object so that it implements the javax.servlet.http.HttpSessionBindingListener interface. In the valueBound() function, do nothing; in the valueUnbound() function, call disconnect().
Pre-starts:
In previous versions of Verastream, replication recovery caused CSX to reset pre-starts. This problem has been fixed.
Pre-starting all configured servers simultaneously creates large loads. To remedy this, one server process per switch, per machine is started at a time. When the server process is available and idle, the next one is pre-started. This applies to pre-starting only. The algorithm for starting extra servers has also been improved.
Restarts:
Occasionally, replication recovery caused CSX to restart servers. This issue has been resolved.
The Verastream daemon now restarts if it detects that an IP address has changed, even if UDP replication is disabled.
Improvements:
In previous versions, the VIB web services solution serialized all requests because the Java VCP library was not thread-safe. This restriction has been lifted.
Note: You must now use a CSX switch if you want to route the concurrent calls to multiple servers.
A race condition on fast machines previously caused CSX to malfunction. This issue has been resolved.
A CSX switch previously contained a problem that would occur if a client disconnected in the middle of a method call. The effect was that the server that was executing the call for the client would become unavailable for further method calls.
In previous versions, CSX sometimes went into an infinite loop after network disconnects. This problem has been fixed.
On OpenVMS platforms, the VCP registration table 'snregtab.dat' no longer contains the full path, extension, and version number of the executable. It now contains the actual command that is executed to start the server.
Enhancements:
To make it easier to define CSX pools for all of your components, a different view mode is available in the CSX Configuration tool. The view mode shows all VCP components in the tree view.
It is now possible to disable all servers for a certain CSX pool on a certain host, so that server application files can be maintained. When a server is disabled, the setting for the minimum number of servers is disregarded and no servers are pre-started. Any running servers are immediately shut down, disregarding the server idle timeout. If all possible servers for a certain pool are disabled, no calls can be made, and client calls will eventually time out.
The following informational and error conditions that may occur in the daemon or CSX switch are now reported to the Windows Event Log:
To avoid losing logged message events, consider changing the log size or overwrite options in the Windows Event Viewer log properties.
Messages such as "The service was started" are readable in the Windows Event Log Viewer as long as the daemon is installed on the system. After an uninstall, the above message would read similar to the following: "The description for Event ID ( 104 ) in Source ( sntcpd ) cannot be found."
CSX switches:
In previous versions of Verastream, there was a problem involving non-standby secondary CSX switches whereby servers sometimes failed to close when the configured server idle time was reached. This problem has been fixed. The primary CSX switch now calls the STOP method and forces the server to close.
The CSX configuration tool has a new option that allows you to change defaults for the switch idle timeout, the client call timeout, the server idle timeout, and the statistics sample timeout values.
It is now possible to define the log file and settings (MYDBG) for an individual CSX switch. You can enter the MYDBG parameter in the CSX configuration tool. If you do not specify a MYDBG value for an individual switch, the MYDBG value in the sn.ini is used.
You can now create a shared memory segment that contains multiple applications. To initialize such a segment, issue the following command:
nova -w -eshminit file=<text file> In the text file (which you can create with any editor), specify a list of applications to place into shared memory. Each line must contain the following:
A line starting with the keyword APPL indicates an application that must be placed into shared memory. The optional arguments work exactly like the arguments of LOADMODULE/SUBAP. Note that for a Process Integrator (PI) application, you must specify TYPE="pia".
Here is a typical example of this file:
APPL apname1 TYPE="pia" APPL apname2 TYPE="pia"APPL apname3 TYPE="pia"Because the modules (subapplications) loaded by your PI application are already automatically included in the shared memory segment, they do not have to be listed in the text file. If your application loads subapplications during runtime, with LOAD/SUBAP or LOADMODULE/SUBAP, you can add these subapplications to the shared memory segment by specifying SUBAP lines below the APPL line.
For example, if you have a main application "main" that loads two subapplications, you could specify this as follows:
APPL main FILE="main" TYPE="fle" SUBAP subap1 FILE="subap1" SUBAP subap2The documentation for the XML DOM method hasElement on component ExtDocument states that the function fails if the path doesn't exist. In actuality, if the path didn't exist, an exception was thrown. Now, the hasElement method behaves as it is described in the documentation. Note that this change could affect your existing code.
Exceptions thrown by XML DOM components did not always contain an exception string. This has been fixed.
In previous versions of Verastream, if you inserted data into an XML document but used an incorrect root element, you would receive a ClassCastException. Now a 'normal' error message is generated.
The VIB method getServerName() on component ModelVars is now generated by the Repository. The VIB method directly calls the Verastream Host Integrator method with the same name. The description of the latter is "Method used to get the name of the Host Integrator Server for the current session."
In previous versions, a VHI table procedure that had no output parameter was not shown correctly in the Repository. This problem has been fixed.
The Verastream Host Integrator adapter that's provided with Verastream Integration Broker now behaves as follows: First, when necessary, the current entity is set using SetCurrentEntity(). After that, when necessary, the current record set is set using the AppConn method SetCurrentRecordSetByName().
In previous versions of Verastream, the VHI component argument MaxRecords (internal buffer name '!Max#Records!') could not contain a NULL value. If MaxRecords contained a NULL value, the following error message was displayed: "Type of field '!Max#Records!' should be 'integer'". Now, a NULL value in MaxRecords is ignored.
Performing a CLOSE on SIEBEL will now also close all SIEBELBS objects. This behavior was implemented because the SIEBEL and SIEBELBS components share the connection to the Siebel system.
In previous versions of Verastream, CLOSE functions did not always work correctly. Some examples of these functions are CLOSE VHI, CLOSE SIEBEL, CLOSE VCP. These functions now work correctly.
When you attempt to view a table in the Repository that doesn't exist, you will receive the following message: "Table does not exist."
The RMS-COBOL Copybook Redefines Wizard now includes a list box from which you can select a copybook.
A new icon now displays the difference between an RMS table and a REDEFINE pseudo table. This new icon appears in the Repository and in the RMS-COBOL Redefine Wizard.
The VBC Wizard has a new check box: strip leading and trailing spaces. This box is only enabled when the Omit string length check box is selected. For strings that have a size, stripping is always done; this cannot be changed.
It is now possible to specify the date, time, and mtime in NVNOCONFIRM. The specification is similar to that of MYDBG. For example, with file name result.txt:
NVNOCONFIRM=result.txt!date!mtime
The resulting output looks similar to the following: 2005/05/13 15:45:44.407 - a message. Operating system-dependent separators other than '!' can be used as well.
You can also use %p, %a, etc., in the file name that is specified in NVNOCONFIRM (as you can with MYDBG). This may be useful if, for example, you want to find out which process created which NVNOCONFIRM file.
When 'Tools/Options/Application Defaults' is chosen in Process Integrator, the values on that tab are compared against those of the current application (re-use of data objects, the roll-back mechanism, and NULL fields). If there is a difference between the two sets of values, you will have the opportunity to apply the new defaults to the current application after you click OK or Apply.
In previous versions, spaces within quotes were seen as options separators. This problem has been fixed.
In earlier versions of Verastream, dataserver tables and databases would not close correctly if a network connection was lost. This problem has been corrected.
Note: To recover from a dataserver network error in your program, you must close all database objects that are using the service, and call DISPATCH/BASE.
Verastream now distinguishes between successful and unsuccessful host name lookups and can assign them different time-to-live values in the cache. The existing parameter VSHOSTCACHETIME determines the time-to-live of successful lookups. A new parameter, VSHOSTNEGCACHETIME, determines the time-to-live of unsuccessful lookups. If neither parameter is set, the time-to-live value in the cache is indefinite. Neither parameter is pre-set in a standard installation. To set them, edit the Verastream sn.ini file (where each parameter is commented out by default).
In previous versions, an empty string set by a client could silently become a NULL on the server side. This has been fixed.
A new expression function called isnumeric is now available. It can be used to test whether a string can be converted to a numeric value.