RE: Embedded SQL date in DS array problem

Hi Chuck,

Thank you, you hit on a solution - it is for all the wrong reasons and
should not be so but it is a solution <g>

When you have a date field in DS array (or MODS) host variable it looks as
if the pre-compiler ignores the SET OPTION DATFMT = *ISO directive and the
default DATFMT(*ISO) on the H Spec.

(Chuck, in RPG IV the default format for date fields defined in a program is
specified using the DATFMT keyword on the H SPEC. If the DATFMT keyword is
not present it defaults to *ISO. This is not the same as the old UDATE and
*DATE stuff that defaults to *JOB).

The program compiles if

1. (As Chuck discovered) I specify DatFmt(*ISO) on the Date field and
compile with DATFMT(*JOB)
2. I specify DatFmt(*ISO) on the H Spec and compile with DATFMT(*JOB)

I can honestly say that over the years the pre-compiler has wasted more of
my time than anything else on the system :-(

One more to the list of "this sucks".

Regards

Paul Tuohy
ComCon
www.comconadvisor.com
www.systemideveloper.com

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of CRPence
Sent: 20 January 2008 00:40
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Embedded SQL date in DS array problem

I asked because I did copy/paste to try the compile :-) and I wanted
to be sure I was not missing something. I had figured the reference was
to both the DS field and the DB field, but I was not sure. For some
reason my brain was stuck on the word /variable/ for the DS field. For
a column it is moot, as SQL DDL always creates the date column with *ISO
attribute. However there was no indication that I could see, why the
RPG field in the DS would have been defined as *ISO; understand, I am
only somewhat literate in RPG. I ignored the SET OPTION because I was
thinking that was /just the SQL/; I see the implication now... The
expectation that the pre-compiler would force the *ISO definition in the
DS [or whatever it needs to do to function without error], given the SET
OPTION was coded as the first SQL statement.

So with my less experienced perspective, for lack of seeing the Date
Format coming from an External definition, I inferred the internal
definition must be defaulting to *JOB. Thus I changed the source to add
the DatFmt(*ISO) on the DS field and *it compiled*! But apparently it
compiled only because I have additionally specified the DATFMT(*ISO) on
the compile. That is...

The slightly modified source shown below actually does compile fine
for me on v5r3 when specifying DATFMT(*ISO) on the compile [which is my
default]. I also experienced that the unchanged source _does not_
compile with the default DATFMT(*JOB); neither does the modified source
The changed source per CMPPFM:

I - D MyDate d DatFmt(*ISO)
D - D MyDate d

Sometimes it pays to be somewhat confused or even clueless, to
circumvent a problem. ;-) At least I hope my unwitting changes prove
functional [for compile; not tested functionally for run-time] for you also.

Regards, Chuck