Conference iamok::dtrdig

2987.0. "DTR$TOP problem after ECO" by CSC32::HENNING (A rose with no thorns) Fri Jan 31 1997 10:50

    My customer has installed the new ECO kit (DTRALPE01071) on his Alpha
    system, to address the "invalid dictionary directory" errors for STORE
    or MODIFY of fields validated by tables in a textfile dictionary.
    After applying the kit, he no longer needs to define the full pathname
    for tables in the VIA and IN clauses.  However, Datatrieve now returns
    errors for pathnames that begin with DTR$TOP -- where there was no
    error before the kit was installed.  
    
    When he tries to PRINT records that include this field definition:
    
            08 CHIEF_AREA
               COMPUTED BY CHOICE
                    SUPERVISOR IN DTR$TOP.DAILY.BODYSUPV THEN
                            SUPERVISOR VIA DTR$TOP.DAILY.BODYSUPV
                    SUPERVISOR IN DTR$TOP.DAILY.ENGNSUPV THEN
                            SUPERVISOR VIA DTR$TOP.DAILY.ENGNSUPV
                    SUPERVISOR IN DTR$TOP.DAILY.SUSPSUPV THEN
                            SUPERVISOR VIA DTR$TOP.DAILY.SUSPSUPV
                    ELSE ' '
                    END_CHOICE.
    
    DTR fails with:
    Element "CDD$TOP.DTR$TOP.DAILY.BODYSUPV" not found in dictionary.
    
    When he changes the field definition to:
    
            08 CHIEF_AREA
               COMPUTED BY CHOICE
                    SUPERVISOR IN CDD$TOP.DAILY.BODYSUPV THEN
                            SUPERVISOR VIA CDD$TOP.DAILY.BODYSUPV
                    SUPERVISOR IN CDD$TOP.DAILY.ENGNSUPV THEN
                            SUPERVISOR VIA CDD$TOP.DAILY.ENGNSUPV
                    SUPERVISOR IN CDD$TOP.DAILY.SUSPSUPV THEN
                            SUPERVISOR VIA CDD$TOP.DAILY.SUSPSUPV
                    ELSE ' '
                    END_CHOICE.
    
    DTR> PRINT ECRS
    The PRINT completes without error.
    
    I've attached a list of DTR* and CDD* logical definitions, which appear
    to be correct for /NOCDD Datatrieve.
    
    Does this reflect a change in DTR behavior, a result of incorrect DTR
    or CDD logical definitions, or was this perhaps 'broken' by the ECO?
    
    Thanks for your input,
    Mary
    
    
    $ SHOW LOGICAL/FULL DTR*
    (LNM$PROCESS_TABLE)     [kernel]
                            [no protection information]
    
      "DTR$EDIT" [super] = "TPU"
      "DTR$ENVIRONMENT" [super] = "/NOCDD"
      "DTR$NOWINDOWS" [super] = "TRUE"
      "DTR$STARTUP" [super] = "ECR$EXECUTE:DTRUP.COM"
      "DTR$SYNONYM" [super] = "ECR$EXECUTE:SYNONYM.DTR"
      "DTR$TOP" [super] = "ECR$DISK:[ECR.DTR$DICTIONARY.]"
    .
    .
    .
    (LNM$SYSTEM_TABLE)      [kernel]  [shareable,system]
                            [Protection=(RWC,RWC,R,R)] 
    [Owner=[SYSACNT,SYSTEM]]
    
      "DTR$ENVIRONMENT" [super] = "/NOCDD"
      "DTR$LABSTAT" [super] = "USR7:[LABDB.DTR$DICTIONARY.]"
      "DTR$LIB" [super] = "DSA15:[SYS0.SYSCOMMON.DTR.DTR$LIB.]"
      "DTR$LIBRARY" [exec] = "SYS$COMMON:[DTR]"
      "DTR$SUSPENSION" [super] = "USR7:[SUSPENG.DTR$DICTIONARY.]"
      "DTR$TCPSERVER" [exec] = "SYS$SYSTEM:DDMF.COM"
    
    $ SHOW LOGICAL/FULL CDD*
    .
    .
    .
    (LNM$SYSTEM_TABLE)      [kernel]  [shareable,system]
                            [Protection=(RWC,RWC,R,R)] 
    [Owner=[SYSACNT,SYSTEM]]
    
      "CDD$COMPATIBILITY" [exec] = "DISK$SYS2:[VMS$COMMON.CDDPLUS]"
      "CDD$DICTIONARY" [exec] = "DISK$SYS2:[VMS$COMMON.SYSEXE]"
      "CDD$EXTENSIONS" [exec] = "DISK$SYS2:[VMS$COMMON.CDD_EXTENSIONS]"
      "CDD$TEMPLATE" [exec] = "DISK$SYS2:[VMS$COMMON.CDD$TEMPLATE]"
      "CDD$TEMPLATEDB" [exec] = "DISK$SYS2:[VMS$COMMON.CDD$TEMPLATEDB]"
      "CDDL_TV" [exec] = "SYS$SYSTEM:CDDL"
      "CDDSHR_TV" [exec] = "SYS$LIBRARY:CDDSHR"
     

    BTW, customer did test the behavior after defining CDD$DEFAULT to
    DTR$TOP.  The behavior persisted, except that the path name changed. 
    The error message changed to:
    
    Element "CDD$DEFAULT.DTR$TOP.DAILY.BODYSUPV" not found in dictionary.

    It's been a while.  Any input out there?  Or should I IPMT this?
    
    Thanks,
    Mary