Re: Date conversion on chain

Date fields do not have a programmer-definable layout. They are date fields and hold only valid dates. My sometimes vague memory says the date field is actually a 4 character binary field, maybe a Lilian date?

*mdy is not a valid date. Specifying *mdy in the header is only telling the program how the programmer wants the date to look in that program.

Because of that, I never specify a default in the header, or anywhere else. Let the date field deal with however it wants to store it. I only use a format to tell the date field what I am giving it, or to tell a display or printer file how I want a user to see it. Since presentation of the date varies so widely even in the same program, I prefer to define the format to use at the point of use.


On 4/16/2014 2:01 PM, Charles Wilt wrote:

You have a problem...

In order to work with a date of 9999-12-31, you're going to have to have
datfmt(*ISO) or datfmt(*usa)..

I don't suppose you have a CMS that you could use to track down who and
when the datfmt(*mdy) was put in? As it sounds like it was done in
response to a problem. And knowning why it was done means you could fix it
the "right" way.

If this program is doing I/O to a display file, it's probably something to
do with moving the 6 digit screen date to the DB. You'll need to change
that code to convert between *mdy and *usa or *iso.

There's a reason I always have
datfmt(*ISO) timfmt(*ISO)

Charles

Good luck


On Wed, Apr 16, 2014 at 2:05 PM, Horn, Jim <jim.horn@xxxxxxxxxxxxxx> wrote:

I have a file that contains a date field with a value of 9999-12-31. I
need to "chain" this record into a program that has an Hspec of
datefmt(*mdy). I am getting error RNQ0114, Date or timestamp value not in
correct range. If I change the program to datefmt(*usa) the chain works.
The program specs say I need to use datefmt(*MDY). Tried entering a D
spec with the field name with DATEFMT(*mdy). Didn't work. Any ideas?

Jim

--