Dataview Errors - Database Return Codes and Length Discrepancies

Products

Datacom DATACOM - AD Ideal Datacom/AD Datacom/DB Datacom/Server

Issue/Introduction

Database errors encountered while running Ideal programs commonly occur for one of the following reasons:

Datadictionary, Datacom and Ideal data definitions are not in sync.
The wrong database table is being accessed.
The wrong version of the program is being picked up.
The data in the table is not what is expected.

Below is a checklist of procedures to follow to help identify these problems.

Environment

Release: Ideal for Datacom

Resolution

The runtime error produced when a dataview error occurs will provide the name of the program and the statement number that encountered the error. Find out what FOR construct the statement identifies and the dataview and version it accesses. Next, determine what Datacom table is accessed by this dataview.

Sample RUNLIST output:

FATAL ERROR OCCURRED
CLASS=   TYPE=        RETURN CODE=12
DESCRIPTION: 1-IDAETDVW04E - Discrepancy in element length for DATACOM DVW
PROGRAM=     PROCEDURE=               STATEMENT=000100

Note: Ideal detects element length discrepancies on "reads" of Datacom tables. When a discrepancy is detected by Ideal, error message IDAETDVW04E is reported. With "updates" and "adds", Datacom detects discrepancies and reports RC=94(01).

Determine if you have changed the Datadictionary definitions of the existing elements and if they were posted to the CXX (Catalog in Datadictionary). If so, were the dataviews containing the changed elements recataloged? Were the programs that access these dataviews recompiled?

An error that is not obvious to detect can be caused by adding fields to the end of the element when those fields are actually part of an existing group field. When you catalog the structure to the CXX, the length of the element will include the additional fields you added, although they will not be present as fields included on the element list. When you attempt to catalog the dataview that accesses this element, you will receive an IDCMCDEP96E message indicating that there are missing fields in the element.

Determine if you have multiple tables with this name. It is possible that you are picking up the wrong table. To verify, you can enter the following command in CICS:

DBOC INQ=???.tbl

where 'tbl' is the three character name of the table in question. If multiple tables exist, the first table encountered with SYNONYM=NO indicates to Datacom that there are no more tables with this same name. The remainder of the tables will not be processed, even if the DBID and table ID coded in these URTs matches the DBID and table ID in the request area. In the following example, DBID 10 will always be used even if DBID 18 is requested.

DBOC INQ=???.ORD

URT 010(STD UNOPENED AUTO )                       PRTY=07 TXNUD
010 TABLE:ORD   DBID:010    UPDATE
URT 018(STD OPEN          ) ACTIVE=000 RESRVD=000 PRTY=07 TXNUD
018 TABLE:ORD   DBID:018    UPDATE      SYNONYM
DC00380I  TRANSACTION COMPLETED.

For batch, you will want to take a close look at the URT to see if the SYNONYM problem exists.

Run Ideal traces @I$DIALMASK 'V' (to trace the request area, RQA and UIB) and @I$DIALMASK 'VW' (to dump the dataview buffer). If you receive a key or element length discrepancy error in the trace, you will find a message stating the length that Datacom returned and the length that Ideal was expecting.

For all errors, the request area is displayed before and after the call to database. Check the table name and check the hex area at offset x'10' for the DBID. This is the table and DBID being requested. This may offer some new information about the problem. If this is not the DBID you thought you were picking up, are you using (or not using) the ASSIGN DATAVIEW or ASSIGN DBID commands to pick up thedesired table?

Make sure you are running the correct version of the program. Is there an ASSIGN PROGRAM in effect? Load modules could also be a factor. If a program was object transported and new load modules were not created, the old load module will be picked up instead of the new VLS member. @I$CALL ADLMTP will show which programs are considered load modules. You can dump the load module to check the version and compile date:

DBUT M=TEMPU

ADDRESS  OFFSET  -------  DATA IN HEX FORMAT ------- -CHARACTER FORMAT
+0       +4       +8       +C        0   4   8   C

0CD0A000  +0000 05F0440F 00000070 D8D8D8D8 D3D4C9C4 *.0......QQQQLMID*
0CD0A010  +0010 E3C5D4D7 E4404040 D7C7D4C3 E3C8E3C5 *TEMPU   PGMCTHTE*
0CD0A020  +0020 D4D74040 4040F0F0 F2F0F0F0 F1F0F1F1 *MP    0020001011*
0CD0A030  +0030 F1F0F6F0 F5F0F2F2 4004E3C5 D4D74040 *10605022 .TEMP  *
0CD0A040  +0040 40F0F0F0 F6F0F5F1 F2F2F0F2 F7F0F2F2 * 000605122027022*
0CD0A050  +0050 40024000 0000132A 00000000 00000000 * . .............*

QQQQLMID       Hard-coded literal
TEMPU          Module Name (Update Portion)
PGM            Entity Type
CTH            Ideal System Name
TEMP           Ideal Program Name
002            Ideal Program Version
000101110605   Program Compile Date-Time(yymmddhhmmss)
022            Release of Ideal Program Compiled Under
TEMP           Module Prefix
000605122027   Module Link Date-Time (yymmddhhmmss)
022            Release of Ideal Program Linked Under

If the problem is data related, it might be useful to run a DBUTLTY EXTRACT. This is especially true if the program appears to be returning "garbage", or invalid numeric errors. Check to see if the results are consistent with the data returned.
If you still cannot find the problem, run a CXX report to find out the length of the elements for the table and then sign on to DDOL. Check the definition of the elements and compare the two. Check the Datadictionary definition against the Ideal dataview.