RE: To Date or Not to Date... that is the question -- RPG400-L

Charles

I think I was the first to say DSPFFD is lying. And I hold to that, with a need to explain my hyperbole, as when I want to see the length in storage - I seem to recall having some reason to do that once. I don't remember why now. Please, don't anyone ask why in the world would I need to do that - I have worked at companies that do other than line of business apps.

Also, there are columns in the outfile for DSPFFD that suggest representing the storage length, but they don't for date/time fields. For packed fields, the buffer lengths are what we expect - integer of half the number of (digits + 1). I now think I understand that the buffer lengths are the above-MI lengths.

As for DMPOBJ for physical files - you cannot see the actual data in the output from it, unless there is a flag I've not used. The only way I've seen the actual data is to use SST, and I forget now the rabbit warren I had to follow to get to the spaces that hold the actual data.

As to Dave's query about storage in the physical record, the RPG manual clearly says that dates are stored as 4-byte integers internally. As Chuck says, that's below the MI layer. I've enjoyed having things clarified in this discussion. And after looking at the link Bruce gave us, related to the CNVD MI instruction, it is again obvious that IBM has done its homework in the area of time operations and representation. Choices were made - we just need to understand the implications of them in order to use them.

Regards
Vern

At 06:36 AM 12/19/2007, you wrote:

No, the human readable is not stored in the DB. ( except in the case of the program describe file.
RPG handles dates as 10 character fields. You can see this in procedure calls with date parameters.)

Remember, i5 OS is object based, and what are a couple key points about objects? Abstraction and
information hiding; thus, the input/output to/from the DB for a date field are 10-char. But
internally, the data is converted and stored as an integer.

DSPFFD isn't really lying. From outside the object, 10-char is the format you see for I/O.

The only way to really see the internal format would be DMPOBJ.

HTH,
Charles

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
> On Behalf Of Dave Kahn
> Sent: Wednesday, December 19, 2007 6:42 AM
> To: RPG programming on the AS400 / iSeries
> Subject: Re: To Date or Not to Date... that is the question
>
> On 18/12/2007, CRPence <crp@xxxxxxxxxxxxxxxxxxxx> wrote:
> > DSPFFD does indeed effectively lie for the length of data types Date,
> > Time, and TimeStamp. The /buffer length/ is accurate for the specific
> > [human-readable] formatting for presentation, not the length for the
> > internal storage for the data type; as seen for Packed and Integer for
> > example.
>
> But what about the storage in the physical record? I create a database
> file with a date field DSPFFD tells me the field occupies 10 bytes. If
> I populate the database file and display it with DSPPFM I see a 10
> character ISO representation of the date. If I then create a new flat
> physical file and copy the database file to it with FMTOPT(*NOCHK) I
> see that 10 character format dates are copied to the flat file. There
> should have been no under-the-covers conversion in this case.
>
> If I create an RPG program defining my database file as a program
> described flat file and use it to read the file I can see that it is
> indeed getting 10 character representations of the date in the buffer
> position indicated by DSPFFD.
>
> If I use SQL to display my database file the date field is not
> displayable unless I use a function such as HEX, CHAR or DAYS to
> resolve it.
>
> All the above suggests to me that the physical representation in the
> database is not the internal date format but the character
> representation and DSPFFD is telling the truth about the buffer. It
> appears to me to be the human readable form that gets stored in the
> database.
>
> --
> Dave...
> --
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>

This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.