Re: SQLRPGLE create table

On 24-Oct-2011 07:37 , Raul A. Jager W. wrote:

In:
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rzakb/rzakbmstlfkeyw.htm

I copy below part of it.
_______________________________________________________________________

DATFMT(date-format)

The date-format parameter specifies the format for the date. The
following table describes the valid date formats and their default
separator values for physical file fields.

Format name Date Date Field Example
format format and length
parameter separator

Job Default *JOB^1
Month/Day/Year *MDY^1 mm/dd/yy 8 06/21/90
Day/Month/Year *DMY^1 dd/mm/yy 8 21/06/90
Year/Month/Day *YMD^1 yy/mm/dd 8 90/06/21
Julian *JUL^1 yy/ddd 6 90/172

<<SNIP>>

Notes:

1. These DATFMTs are not valid for the date (L) type field. They are
only valid on logical file zoned, packed, or character types having a
physical file based on date type fields.
2. DATFMTs that do not have any "days" specified are implied to be
day 1 of the specified month.

_______________________________________________________________________

I was very surprised when I tried and it did accept *dmy as valid for a
physical file.

Your advise to create a new SQL table and bulid alogical using DDS is
great, I plan to use it

The direct link to DATFMT is:
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rzakb/rzakbmsttddatfm.htm

There are *two* tables, each table has its own "Notes:" section. The above copied\pasted table details are from the first table, but the "Notes:" section was copied\pasted from the second table. The "Notes:" which are associated with the portion of the first table in the quoted text is:

Note: If this format is specified and the field allows the null value,
you must specify a valid date for the DFT keyword for this field.

While I can see how the lack of "1." might lead to that mis-read\misinterpretation, I read them as the documentation intends. I am not aware of what release that the "1." disappeared, but in the releases I recall reviewing the DDS Reference documentation, the "1." was there. Out of curiosity I checked v5r3 which I know I had reviewed, and then checked v5r4 which I am not sure if I reviewed... And, no surprise, the loss of the "1." to correlate to the ^1 [superscript one] references in the prior table details occurs since v5r4.

You may wish to "send feedback" to submit a "reader comment card" about the error in the documentation. I did not; as I noted, the doc is clear to me, even without the ^1.

Regards, Chuck