• Post Installation Issues
• Configuration Issues
• Running UACS
• Transaction Client Issues
• UniAccess Server Issues
• UniAccess ODBC Server for RDMS 2200 Issues
• UniAccess ODBC Server for DMS 2200 Issues
• UADriver Troubleshooting
• Distributed Transaction/UADTC Issues
• Accessing LINC Data
• Debugging UniAccess Programs

The following are solutions to commonly reported errors in configuring UniAccess.

Problem (UniAccess #1688):

After installing UniAccess 10R2-0, UACF returns the following message: "Invalid product key [UACLPRODKEY]. [26] *ERROR* UACF processing failed" even though the product keys are correct.

Solution:

Review this document, UniAccess updates are required with the EXEC in CP IX 9.2 (47R4B), CP IX 10.1 (47R5B), or later due to ER-CONFIG$ changes. to see if your site needs to upgrade to the latest UniAccess level.

back to top

Problem:

UniAccess 9R2 and Greater Product Key Compatibility Issues With ClearPath Systems Running EXEC 46R4, 46R5, or 46R6.

Solution:

Review this document to see if your site needs to apply this TCF.

back to top

Problem:

After the Configuration File has been updated, the change does not take effect.

Solution:

Make sure you have processed the UniAccess Configuration File with the proper options. Refer to the UniAccess for OS 2200 System Administration Guide for the correct procedures to initially execute and reconfigure the UACF processor. To verify that the changes have taken effect, use the ‘D’ option on the UACF processor to dump the contents of the UniAccess Configuration File. To verify that the changes to the COMSRV statement have been processed, use the 'B' option on the UACF processor to dump the contents of the UniAccess Configuration File. (Changes to the COMSRV statement require that the appropriate communications server be stopped and re-started.)

back to top

Problem (UniAccess #227):

After updating the UniAccess Configuration File, UARS (or any RPC) returns: UniAccess error #33800: "UACS error: Transaction UARS schedule failed (cmstor failed 400000000034)."

Solution:

Verify that the UniAccess Configuration File includes valid PIDs within the correct MCB. Note that these PID numbers cannot be in use by MAPPER or CMS.

back to top

Problem (UniAccess #226):

The trace file displays the following message: “TIP$SM call [%s] failed
[%o] affecting User = [%s], pid = [%d].”

Solution:

This error message is documented in the Unisys Transaction Processing (TIP) Administration & Operations Reference. The message may indicate invalid APPINF APPNAME or OSPARM SESSCTRL settings. Verify that these settings are correct in the UniAccess Configuration File.

back to top

Problem (UniAccess #316):

After UACS has been executed, UARS (or any RPC) returns the following message: "[14] Basic Mode CMS call error [cmstor] [400000001006]."

Solution:

Verify that the OSPARM SESSCTRL parameter is valid in the UniAccess Configuration File. YES indicates that TIP session control is configured. NO indicates that TIP session control is not configured. Defaults to NO.

back to top

Problem (UniAccess #309):

After UACS has been executed, it returns the following message: "UACS*PID ASSIGN/RELEASE ERROR [42] [12]".

Solution:

UACS Console Message #12 (documented in the UniAccess for OS 2200 System Administration Guide) directs the reader to the Unisys Transaction Processing (TIP) Administration & Operations Reference for information on error 42. Section 25 of that manual describes error 42 as: "A CMS program has attempted to assign this range of PIDs while it is assigned to some other CMS program."

Verify that the PID range configured for UniAccess does not conflict with the CMS and MAPPER PIDs.

back to top

Problem (UniAccess #1592):

The following error was encountered after increasing PIDCNT: [18] *ERROR" - TIP$SM call [Open Request] failed [7].

Solution:

UniAccess 10R1-3, 10R2-1, 10R3-0, and up have been modified to correctly calculate the number of access control words (ACWs) that are required on the RT$PID request to reserve the PIDs.

back to top

Problem (UniAccess #1953):

A new COMSRV parameter has been added that allows a site to switch the UACS unique-ID feature on (YES) or off (NO). The default is YES. The format for the new parameter is:

COMSRV [AUXUNIQID, {YES | NO}; ]

 

This UACS unique-ID is a 3 word field and is consistent during the UACS execution. UACS writes its unique-ID in the first 3 words of the UPA each time it schedules a transaction. The scheduled transaction uses the received UACS unique-ID as an input validation parameter when it receives its input data from the UAFG.  Sites deploying middleware to manipulate the UPA should probably switch the feature to NO to prevent possible UPA conflict.

Solution:

This is a new, undocumented, configuration option in UniAccess 10R2-3 and 10R3-1.

back to top

The following are solutions to commonly reported errors in running UACS (the UniAccess Communication Server).

Problem (UniAccess #209):

When UACS is executed, a Basic Mode CMS Call Error [CMINIT] with a status of 4000000000001 is received.

Solution:

Verify that MCB is active in the appropriate application group.

back to top

Problem (UniAccess #712):

ST UACS results in: No product service permissions exist in product key [92] ERROR

Solution:

Verify that the correct value was entered for the product key parameter(s) of the OSPARM statement. Deactivate and reactivate the UniAccess Fixed-gate. If this does not resolve the problem, please contact UniAccess Support: Email or phone UniAccess support. Note that UniAccess product keys for levels prior to 9R1 are not valid with 9R1 or later.

back to top

Problem:

ST UACS results in: Invalid product key. [94] *ERROR*

Solution:

UniAccess levels 9R1 and above require a new product key. Update the OSPARM product key parameter(s) in the UniAccess Configuration File with the new product key(s) and deactivate and reactivate the UniAccess Fixed-gate.

back to top

Problem (UniAccess #1331):

When UACS encounters a trace file cycle conflict it leaves the test-and-set lock on the UniAccess Trace File and eventually this causes all UACS activities to queue.

Solution:

This is resolved in UniAccess 10R1-1, 10R2-0, 10R3-0 and up.

back to top

Problem (UniAccess #1380):

Occasionally UACS receives QItems for CSPROCs which are not in use or are not linked to the originating MMPROC. This may lead to bad CSPROCs.

Solution:

This is resolved in UniAccess 10R1-1, 10R2-0, 10R3-0 and up.

back to top

Problem (UniAccess #1214):

UACS can hang and the CSPROC D-bank corrupted when an MCB output message has a total length greater than 512 characters.

Solution:

This is resolved in UniAccess 10R1-0, 10R2-0, 10R3-0 and up.

back to top

Problem (UniAccess #1199):

In a TIP session control environment and/or if a LOGOFF transaction is used, the UACS trace file can receive many [85], [48], and [38] errors.

Solution:

This is resolved in UniAccess 10R1-2, 10R2-0, 10R3-0 and up.

back to top

Problem (UniAccess #1365):

The CSPROC free chain introduced in 9R2 is getting corrupted such that freed PIDs become orphans until UACS declines new connections because the Free Chain indicates no CSPROCs are available, when in reality they are.

Solution:

This is resolved in UniAccess 10R1-2,  10R2-0,   10R3-0 , and up.

back to top

Problem (UniAccess #1595):

The run condition word contains 075 in T3 following UACS execution and normal termination.

Solution:

UniAccess 10R1-3, 10R2-1, 10R3-0, and up have been modified to not change the run condition word. The run condition word at program termination will contain the same value of the run condition word at UACS initiation.

back to top

The following are solutions to commonly reported errors in the UniAccess Transaction Client environment.

Problem:

UniAccess Transaction Client-Library (UACL) program receives "Receive request failed - library error 31" on a ct_results function call. The identical select statement works using ISQL against SQL Server.

Solution:

UAMM Error 31 is the result of a Network error. You should check the UACS trace file for error information. If the UACS trace file indicates a network read time-out error, try increasing the NWRTIMOUT and NWWTIMOUT parameter values. This is particularly an issue if very large or extremely complex requests are being issued.

back to top

Problem:

When a ISQL logon is issued, the following message is received: "ct_connect(); network packet layer: internal net library error: Specified CT-Library call to ct_connect failed."

Solution:

When a user executes ISQL, if the userid check is not bypassed, the userid and server information are immediately validated with the UAUSER and SERVER entries in the UniAccess Configuration File. If either the specified UAUSER or SERVER entries do not exist in the Configuration File, this message will be generated.

back to top

Problem:

After logging in using @ISQL, the following message is displayed: "CT_CONNECT() network packet layer: internal net library error: specified server name attribute could not be found."

Solution:

Verify that the UniAccess Transaction Server environment has been successfully configured in the UniAccess Configuration File. The SERVER configuration statement defines the server to which a client application will connect. This name is case sensitive and must match the server name specified on the @ISQL call as well as in the interfaces file. (Refer to the UniAccess for OS 2200 System Administration Guide for a description of the SERVER configuration statement.)

back to top

Problem (UniAccess #1549):

@ISQL is hanging when issuing an 'X' to cancel results following a select statement in @ISQL against MS SQL Server 2000 sp3a. Note: the 'C' command to continue displaying results works.

Solution:

This is resolved in UniAccess 10R1-3, 10R2-1, 10R3-0 and up.

back to top

Problem (UniAccess #1589):

@ISQL now accepts an 'X' option to abnormally terminate @ISQL on first error.

Solution:

This is resolved in UniAccess 10R1-3, 10R2-1, 10R3-0 and up.

back to top

The following are solutions to commonly reported errors in a UniAccess Server Environment. UniAccess servers include the UniAccess Transaction Server, the UniAccess ODBC Server for RDMS 2200, and the UniAccess ODBC Server for DMS 2200. This section first lists solutions to reported errors common to all three environments. Then solutions to reported errors in specific UniAccess server environments are listed.

Problem:

UniAccess Server-Library transactions may appear to stall until the TDWAITTIME specified in the TDFHEIBLK expires. The apparent stall of the UniAccess Server-Library transaction may cause the client application to indicate that the server has timed out.

This has been determined to be caused by modifications to memory handling introduced by the EXEC change 00006-61620-PCR.

Solution:

The suggested resolution is dependent upon the hardware platform.

• M Series Systems(2200/300, 2200/500, 2200/700, 2200/900, 2200/3800)

The resolution for the apparent transaction stall is to change the VALTAB to indicate that the transaction should run in "TIP-memory-compatible mode". This is specified by the O option in the VALTAB indicator field.

For additional information please see the OS 2200 Transaction Processing Administration and Operations Reference Manual that corresponds to the System Base installed on your system.

The resolution for C Series Systems, described below, will also work on M Series systems.

For better performance, the VALTAB program type for UARS should be reentrant PRG,3), and the FLAGBOX bit for STICKING should be set (FB ON STICKING). Additional performance gains can be made by making the transaction a resident transaction. Resident online programs (RTPS feature) are loaded either via TP keyin or RPINIT utility request.

• C Series Systems (1100/90, 2200/400, 2200/600, 2200/600ES)

If TIP memory is being used on the system, the VALTAB should be updated to indicate that the transaction should run in TIP memory. This is specified by the O option in the VALTAB indicator field.

If TIP memory is not being used on the system, the value of the WAITTIME parameter on the RELSRV configuration statement should be set to 0 (zero). UniAccess Server-Library transactions should set the TDWAITTIME to 0 (zero).

For better performance, the VALTAB program type for UARS should be reentrant (PRG,3), and the FLAGBOX bit for STICKING should be set (FB ON STICKING). Additional performance gains can be made by making the transaction a resident transaction. Resident online programs (RTPS feature) are loaded either via TP keyin or RPINIT utility request.

back to top

Problem:

RPCs receive an error when an update is attempted. The UACS trace file indicates the following: "[14] Basic mode CMS call error [cmstor][400000072006]".

Solution:

This error indicates invalid message/program options. Check the VALTAB settings for the RPCs, particularly the REC option. If recovery is not configured in the EXEC, make sure this option has the value of NONE.

back to top

Problem:

RPCs receive an error when an update is attempted. The UACS trace file indicates the following: "[14] Basic mode CMS call error [cmstor][400000072006]".

Solution:

This error indicates invalid message/program options. Check the VALTAB settings for the RPCs, particularly the REC option. If recovery is not configured in the EXEC, make sure this option has the value of NONE.

back to top

Problem:

The UniAccess Trace File occasionally displays a TSAM error 030612000004: “Error Indication Received From TCP.”

Solution:

This indicates that, although everything is set up properly, CMS could not get a message to the destination. The problem could be with a router or getting to a router. Run a sniffer on the line and determine where the errors are.

back to top

Problem:

The following error appears in the UniAccess Trace File: “Failed in function [mmopen] in UAMM, pid [pid #], other info [7] in trace file”.

Solution:

This error indicates that a PID is not able to initiate with UAMM (i.e., mmopen). Any attempt to open a PID will result in a UAMM error 7, which is unable to allocate a MMPROC. There are two situations that can cause a UAMM process (mmproc) to hang:

• If UniAccess aborts the connection and does not receive an abort confirm [see the Unisys OS 2200 Communications Management System (CMS 1100) Programming Reference Manual], the PID and mmproc will remain busy. Some cases in which UniAccess will attempt to abort the connection are when a PID is terminated with the operator keyin (UACS TERM PID,<pid>)are when UACS is terminated with active PIDs, and when a connection timeout (COMSRV CONTIMOUT parameter) occurs.
• If a transaction errors without the UniAccess contingency routine getting control, the mmproc will remain busy. (For example, a transaction may error prior to connecting to the UniAccess Fixed-gate subsystem--UAFG.) If this situation occurs, a print file should be created for the erring transaction.

Since the UAMM process slots are maintained in UAFG, they are not released when UACS is terminated. Therefore, hung mmprocs can collect over time. The only way to release the hung mmproc is by deactivating the UniAccess Fixed-gate subsystem and reloading it. (See the UniAccess System Administration Guide for information on activating, deactivating, and reinitializing UAFG.) Note that the number of UAMM process slots is defined by the PROCCNT parameter of the UAMM configuration statement.

back to top

Problem:

A UACS TERM PID, <pid> not only does not terminate the PID, but it places the PID in an ERROR state.

Solution:

The following scenarios can lead to a PID being placed into an ERROR state that will not be automatically resolved:

• UACS successfully schedules the transaction, but the transaction does not execute.
• UACS successfully schedules the transaction, but the transaction error terminates prior to performing the TDINIT call. When the transaction errors prior to performing the TDINIT call, the UniAccess Fixed-gate subsystem has not been registered for contingency notification and, therefore, must assume that the transaction is still active.

Execute the TERM PID,<pid> command a second time. The first TERM PID command may only mark the PID in ERROR; a second TERM PID command removes the ERROR.

back to top

Problem:

There are a number of situations that may result in hung PIDs. The hung PID may initially be identified as a problem connecting additional client applications or as the result of a UACS STATUS keyin. The most common of these situations are:

• UACS TERM PID,<pid> does not terminate the PID, but it places the PID in an ERROR state. 
• UACS successfully schedules a UASL transaction, but the transaction does not execute.
• UACS successfully schedules a UASL transaction, but the transaction error terminates prior to performing the TDINIT call.
• The client application terminates without notifying the server.

Solution:

Both the client and server side of a UniAccess transaction must be closed to release a PID. There are a number of configuration parameters that can detect a potential hung PID and automatically resolve the problem. These parameters are:

• CONTIMOUT on the COMSRV statement
• KEEPALIVE on the COMSRV statement
• NWRTIMOUT on the COMSRV statement
• NWWTIMOUT on the COMSRV statement.

When it becomes necessary to terminate a PID using the UACS TERM PID,<pid> keyin, always follow with a UACS STATUS PID,<pid> keyin to ensure that the connection was properly closed. If the PID has not closed, a second UACS TERM PID,<pid> keyin is required. The UniAccess Trace File, with traces on HIGH, will provide information that is useful in determining the cause of hung PIDs.

back to top

Problem (UniAccess #1590):

UASLSTUB has been modified to write MCB status error codes to the system log.

Solution:

This is resolved in UniAccess 10R1-3, 10R2-1, 10R3-0 and up.

back to top

Problem (UniAccess #1378):

A multiple-inital ACOB UASL transaction whose MCB time has expired has the contents of the MCB return code destroyed.

Solution:

This is resolved in UniAccess 10R1-2, 10R2-0, 10R3-0 and up.

back to top

Problem (UniAccess #1413):

If a transaction contingency occurs while a test-and-set lock is locked, any subsequent request for this lock will be queued.  

Solution:

This is resolved in UniAccess 10R1-2, 10R2-0, 10R3-0 and up.

back to top

Problem (UniAccess #1229):

UASL ACOB transactions do not permit the ability for the UASLSTUB and the parameters to be in an RSEG.

Solution:

This is resolved in UniAccess 10R1-1, 10R2-0, 10R3-0 and up. (This functionality was broken between UniAccess 8R1-0 and 8R2-0.)

back to top

Problem (UniAccess #1651):

UASL transactions communicating with Microsoft SQL Server issuing SQL Statements receive TDS protocol errors (although the SQL statements are processed) .

Solution:

This is resolved in UniAccess 10R1-3, 10R2-1, 10R3-0 and up.

back to top

The following are solutions to commonly reported UniAccess errors specific to the UniAccess ODBC Server for RDMS 2200 environment. See the proceeding section UniAccess Server Issues for other reported errors.

Problem:

ODBC UARS Transactions consume a lot of CPU time.

Solution:

Review this document to see if your site needs to apply this Unisys PLE.

back to top

Problem:

UniAccess Relational Service Transaction (UARS) Does Not Receive RDMS Table Information when used with RDMS 12R2, 13R1, 13R1A, or 14R1.

Solution:

Review this document to see if your site needs to apply this Unisys PLE.

back to top

Problem:

The UARS transaction may appear to stall until the RELSRV WAITTIME expires.

The apparent stall of the UARS transaction may cause the client application to indicate that the server has timed out.

This has been determined to be caused by modifications to memory handling introduced by the EXEC change 00006-61620-PCR.

Solution:

The suggested resolution is dependent upon the hardware platform.

• M Series Systems(2200/300, 2200/500, 2200/700, 2200/900, 2200/3800)
  
  The resolution for the apparent transaction stall is to change the VALTAB to indicate that the transaction should run in "TIP-memory-compatible mode". This is specified by the O option in the VALTAB indicator field.
  
  For additional information please see the OS 2200 Transaction Processing Administration and Operations Reference Manual that corresponds to the System Base installed on your system.
  
  The resolution for C Series Systems, described below, will also work on M Series systems.
  
  For better performance, the VALTAB program type for UARS should be reentrant (PRG,3), and the FLAGBOX bit for STICKING should be set (FB ON STICKING). Additional performance gains can be made by making the transaction a  resident transactions. Resident online programs (RTPS feature) are loaded either via TP keyin or RPINIT utility request.
  
  

• C Series Systems (1100/90, 2200/400, 2200/600, 2200/600ES)
  
  If TIP memory is being used on the system, the VALTAB should be updated to indicate that the transaction should run in TIP memory. This is specified by the O option in the VALTAB indicator field.
  
  If TIP memory is not being used on the system, the value of the WAITTIME parameter on the RELSRV configuration statement should be set to 0 (zero). UniAccess Server-Library transactions should set the TDWAITTIME to 0 (zero).

  For better performance, the VALTAB program type for UARS should be reentrant (PRG,3), and the FLAGBOX bit for STICKING should be set (FB ON STICKING). Additional performance gains can be made by making the transaction a resident transaction. Resident online programs (RTPS feature) are loaded either via TP keyin or RPINIT utility request.

back to top

Problem:

UARS transaction receives an out-of-memory error (RDM error 50000).

The VALTAB O indicator option causes the UARS transaction to run in TIP-compatible-memory.  The EXEC prevents the attempts to expand or contract application level backs for transactions in "TIP memory". 

Solution:

Any of the following will resolve the problem.

• Apply the changes associated with EXEC PLE 17074075.
• Move to EXEC level 45R2A, or later.  EXEC level 45R2A is supplied with SB7.1 and HMP-IX3.1.
• Remove the O indicator option from the UARS VALTAB and set the RELSRV WAITTIME to zero (0).

back to top

Problem:

When tables are dropped that were created using the implicit storage area feature of RDMS 2200, the underlying storage area that is automatically created by the create table command is not dropped. This creates a problem if an attempt is made to recreate the table.

Solution:

The storage area must be manually deleted before attempting to recreate the table. Implicit storage area creation can be overridden by specifying a Storage Area when a UniAccess data source is configured. This storage area must be created by the OS 2200 system administrator before any table creation commands can be issued. All tables that are created using the UniAccess data source will be placed in the storage area specified in the Storage Area field. See the Unisys Relational Data Management System (RDMS 2200) Administration Guide, section 2.3.2: Creating a Table with an Implicit Storage Area for more details.

back to top

Problem:

UARS receives the following message: "APP x DCS EX 20120 This run is not configured in UDS to pass a caller certified user-id. The BEGIN THREAD command is ignored.

This error will occur when TIP session control is not active and MASTER-RUN-USERID is not=@@@@@@@@@@@@

Solution:

Use @DD to update the UREP Configuration MASTER-RUN-USERID attribute in APP x to '@@@@@@@@@@@@'.

back to top

Problem:

Table or column information is not being returned to the ODBC client.

Solution:

When UREP is installed, it defaults to partial options set for RDMS. If this is the case, table and column names will not be maintained. The runstream SYS$LIB$*UAUTIL(T).UNIACCESS/CREATE, when added, changes this to RDMS-LEVEL COMPLETE, capturing all future table and column names to the repository. However, any tables created prior to adding this runstream are not automatically updated in the repository. Note: If there are foreign key relationships between tables, you must ATTACH the parent table first. To update the repository with the complete table information, perform the following:

@DD,E,appname
PROCESS TABLE tablename FOR SCHEMA schemaname ATTACH

back to top