Plex 2E

 View Only
  • 1.  DT# data type not generating correct data type for LF DDS source

    Posted Feb 10, 2020 08:23 AM
    I defined a key relation for a field 'Effective date' of data type DT# so that it can have 10 length alphanumeric. When i generated the source, Physical file access path has been generated with DDS correctly with data type L for this field and compiled successfully. However Update Index and Retrieval Index is generated with DDS with data type 10 A and getting a compilation error CPD5719 - Field length specified for date format is not valid. Any idea on why LF is generated with data type explicitly defined as 10 A instead of doing a reference to PF fields?

    LF DDS Source:
    A CTHBS1                             TEXT('LOCATION POLICY TYPE')
    A                                             RENAME(LOCPTP)
    A CTXSDT    10A                   TEXT('TRANS EFF DATE')
    CPD5719-***** 
    A                                             RENAME(TEFFDT)

    I would like to understand how other key fields for example CTHBS1 above is not explictly defined in LF source and used the same definition as it is in the PF. But CTXSDT is having 10A explicitly defined.


    ------------------------------
    Raj
    ------------------------------


  • 2.  RE: DT# data type not generating correct data type for LF DDS source
    Best Answer

    Posted Feb 10, 2020 09:48 AM

    Hello Raj,

    Seeing the RENAME statement in the snippet of your logical, leads me to ask you if the physical file in question is perhaps an assimilated one (i.e. one imported into your 2E model). You can check this by zooming into the EDIT FILE DETAILS screen and checking whether the Assimilated physical flag reads YES.

    If set to YES, this flag generates an additional screen in 2E. In order to access it, enter Z against the PHY, then again Z, and on the following screen, you will see F8=PF entries at the bottom.(F8 is only shown if the mentioned assimilated flag is set to Y).

    Press F8 to access the EDIT PHYSICAL FILE FORMAT ENTRIES screen  to see whether the fields listed there do exactly correspond to the imported physical file's original structure. Do you perhaps state manual overrides for the length column of the date field which could explain why you see a length of 10A as result on your logicals?

    You can get further information on the Assimilation process of existing physical files in the CA 2E manual 'Defining a Data Model ', chapter 7, Assimilation. The special F8=PF entries screen I have mentioned above is dealt with in topic Editing I OS Physical File Format Entries.

    Do these hints help solve your problem ?

    Best regards

    Anette-Nicole




  • 3.  RE: DT# data type not generating correct data type for LF DDS source

    Posted Feb 10, 2020 11:41 PM
    Hi Anette,

    A very big thanks to you !!
    yes, you cracked this problem correct. This is an assimilated physical file and as you said there is an option to override the data type and length in F8=PF entries. However the override allows only to change the data type as P-Packed or Z-Zoned and not to L data type. Not a problem, since this is an assimilated PF, I manually overridden in the LF DDS source and compiled it fine.

    I didn't notice this Assimilation flag enabled in this file. Thank you for providing detailed information. This is very useful.

    Cheers
    Raj

    ------------------------------
    Raj
    ------------------------------



  • 4.  RE: DT# data type not generating correct data type for LF DDS source

    Posted Feb 11, 2020 03:22 AM
    Hello Raj,

    good to hear that this was the problem. But I would like to ask another question: You are right, you can only change the data type to packed or zoned, not to L, but what about the length column ? Because if I explicitly enter 10 into the override length column, I experience the same compile error for my logical as you. So do you see a 10 entered into the override length column ? If yes, remove it for a trial and compile the LF again, it should compile without error now. I would not manually change the DDS source from outside of 2E because next time you regenerate it, the modification will be lost and you will be runnting into the same problem.

    Best regards

    Anette-Nicole