Super-descriptor containing multi-value field

, , , ,
1

I am trying to create a file that contains a super-descriptor made from an A25 that is part of a PE and a D field. The file is defined as shown in Predict:


    Ty L Field ID                         F Cs Length   Occ   D U DB S    All  
    *- - -------------------------------- *- * -------- ----- * * -- *         
    PE 1 PRODUCT-GROUP-GROUP                            100       AA           
       2 PRODUCT-GROUP                    A       25.0            AB N         
       2 INSIDE-COMMISSION                N        3.5            AC N         
       2 OUTSIDE-COMMISSION               N        3.5            AD N         
       2 NEW-BIZ-COMMISSION               N        3.5            AE N         
       1 EFF-DATE                         D                       AH           
       1 EXP-DATE                         D                       AI           
    SP 1 PRODUCT-GROUP-EFF-DATE           A       29.0        D   AJ N

Predict creates the super as shown:


 SUPER    I  AJ  I   29   I    A   I NU,PE             I AB (   1 -  25 )   A 
          I      I        I        I                   I AH (   1 -   4 )   P

The DDM is also created by Predict and the super is shown below:


P 1 AJ COMMISSN-PRODUCT-GROUP-EFF-DATE   A   29  N S 
*        -------- SOURCE FIELD(S) ------- 
*        COMMISSN-PRODUCT-GROUP(1-25) 
*        COMMISSN-EFF-DATE(1-4)

When attempting to use the super, a NAT0106 (Invalid descriptor in READ LOGICAL statement) occurs. If I remove the P from the super-descriptor definition in the DDM, the NAT0106 goes away. Anyone have any ideas on where my error is in Predict? How do I correctly define a multi-value super-descriptor using Predict? Any help would be appreciated.

Thank you.

2

This is not a Predict issue. You cannot use a READ LOGICAL when the Super contains an MU element. You can use HISTOGRAM or FIND, though.

1 Like
3

Thanks Ralph.

I recalled that at a previous employer, they did read by this type of super-descriptor. I remotely recalled there being a catch to it and after a little experimentation, I think removing the P from the super is what they had done. This allows for a read by the super, despite the PE being part of it. As I actually need this super for a FIND, I’ll avoid implementing the hack. Thanks again for the info.

4

Clarification: An MU does not have the same rules as a PE: you can do a READ LOGICAL on a superdescriptor that includes an MU field; you cannot do a READ LOGICAL on a superdescriptor that includes a PE field.

You may be able to “trick” Natural by editting the DDM and removing the PE annotation, but the restriction is an Adabas restriction and attempts to do a READ LOGICAL on a superdescriptor derived from a PE field will fail with a response code 61 (NAT3061) at run time.

5

While I was playing with this, I was very much able to trick Natural by removing the P in the DDM. Additionally, I stored a couple of records then read them back using the super-descriptor without getting a 61. This is not an endorsement to do this, just an observation. The FIND is what my real goal is. I misunderstood my original error to mean the super-descriptor couldn’t be used at all. I appreciate you both clearing up that it only applies to the READ.