Edit date presentation

You need to handle the presentation of dates in display and printer files differently, depending on how they are stored.

  • As a normal decimal data field

    Your application program has responsibility for the way the date is entered, stored, and presented. The application must check to see that the date is entered in the right format, remove any date separators, convert the date to another format when necessary, and edit it on the display file or printer file.

    The DDS keyword DATE is used as an output-only field. DATE uses the job attributes DATE, DATFMT, and DATSEP. You can edit DATE using the edit code keyword, EDTCDE, for 6- and 8-digit date fields.

    Editing with EDTCDE includes the following changes to the appearance of displayed fields, depending on which edit code is specified:

    • Leading zeros are suppressed.
    • Zero values can be displayed as zero or blanks.
    • The field can be further edited using a user-defined edit code.

    For all other types of fields using the EDTCDE Y keyword, the program has to specify the format, and the system uses the date separator of the job that created the device file. The date separator is integrated in the object, and you are not able to change it dynamically at run time.

  • As an SAA data type DATE (L) field

    The DDS date format (DATFMT) keyword allows you to specify different date formats, including default date separators, at the database field level. For the *MDY, *DMY, *YMD, and *JUL parameters, the default date separator can be changed with the date separator (DATSEP) keyword. The *ISO, *USA, *EUR, and *JIS values have a fixed separator, and the DATSEP keyword is not allowed with these values. The DATFMT and DATSEP keywords allow you to specify the format and editing characters for storing date fields. The date is shown as a character string, including the separators.

    Any format conversion between the date input and the format the database asks for can be done by:

    • Application program routines
    • Field mapping through logical files that define different date formats and separators

    For example, you can provide a date conversion that is dependent on the actual job attributes by using the following CL program:

    PGM      PARM(&fromfmt &fromfld  &tofld  );
    DCL      VAR(&fromfmt); TYPE(*CHAR)  LEN(4)
    DCL      VAR(&fromfld); TYPE(*CHAR)  LEN(10)
    DCL      VAR(&tofld);  TYPE(*CHAR)  LEN(10)
    CVTDAT   DATE(&fromfld); TOVAR(&tofld);
    FROMFMT(&fromfmt); TOFMT(*JOB)  TOSEP(*JOB)
    ENDPGM

Your application program has to pass the format of the date you want to convert and the date itself to the CL program. The CL program assumes that the job attributes represent the way the user expects to see date fields edited. It retrieves these values and does the conversion, conforming to these values, and passes back the date in that way. The *ISO, *USA, *EUR, and *JIS values have a fixed separator that cannot be changed. If the TOFMT parameter contains one of these values, the TOSEP value is ignored.