Dataview Errors - Database Return Codes and Length Discrepancies

Document ID : KB000056257
Last Modified Date : 14/02/2018
Show Technical Document Details

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

  • Datadictionary, CA-Datacom and CA-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.

  1. 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=SYS TYPE=USR RETURN CODE=12
DESCRIPTION: 1-IDAETDVW04E - Discrepancy in element length for CA-DATACOM DVW
PROGRAM=ELMDISC PROCEDURE=$MAIN STATEMENT=000100

Note: CA-Ideal detects element length discrepancies on "reads" of Datacom tables. When a discrepancy is detected by CA-Ideal, error message IDAETDVW04E is reported. With "updates" and "adds", CA-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 CA-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 CA-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 CA-Datacom returned and the length that CA-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 CA-Ideal System Name
    TEMP CA-Ideal Program Name
    002 CA-Ideal Program Version
    000101110605 Program Compile Date-Time(yymmddhhmmss)
    022 Release of CA-Ideal Program Compiled Under
    TEMP Module Prefix
    000605122027 Module Link Date-Time (yymmddhhmmss)
    022 Release of CA-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.