Re: I guess I don't know dates

I can confirm the internal representation that is used on disk - the folks on the MI list can probably tell how to see this stuff, if anyone is interested.

SST is where you can see it - I remember the knocking of the knees the first time an IBM support person told me to change a bit through SST - to make an object "damaged". Mucking about with data spaces is risky - you can directly modify the data anywhere. This is where you can undelete a record.

The upshot - dates are stored on disk with the "internal representation" as a 4-byte integer - we know that from Chuck's and Jon's posts.
2005-12-30 is stored as x'002570E7'

Times are stored in 3 bytes, with the HHMMSS digits in the nybbles.
15.23.56 is stored as x'152356'

Timestamps combine date and time, plus microseconds, the digits of which are also stored in 3 bytes. This gives a total of 10 bytes to store a timestamp on disk.
2005-12-30-15.23.56.543219 is stored as x'002570E7152356543219'

now if only I remembered how to find the auxiliary space where some values for varying fields is kept! It's been far too long!

Vern

On 6/28/2012 12:42 PM, Jon Paris wrote:

On 2012-06-28, at 12:36 PM, rpg400-l-request@xxxxxxxxxxxx wrote:

I think it's a little murky to use the word "stored" there. The
*internal* representation is a binary Lilian (or close enough) date.
By "internal", IBM means (approximately) "in memory".

Not so. It is the stored disk record that has the binary value. As the record is "surfaced" by the system's IO routines it is at that point that it is expanded into the 8 or 10 character form you see. From what Birgitta says the underlying SQL routines do not make that transform.

No utility software has to be fooled or take extraordinary measures because it is impossible to "see" the field in any other way. As far as I know only by dumping the disk to print can you observe the raw form. Probably some sst tool or whatever as well - but us mere mortals can't see it that way.

I believe external representations (which are formatted) include not
only displays, but storage in physical files (which is what I think of
when I see "stored"). As mentioned before in this thread, when you
specify DATFMT in the DDS, the field in the physical file will be
sized and formatted accordingly. (As far as I can tell, the
*physical* representation of a date in a PF is identical to the
appropriately edited character string. The only difference being that
the field is declared as type L instead of type A.)

If you do the math (records x length compared with actual storage usage) you will find that this is not the case. It is particulalrly obvious in a file with multiple 10 character date fields.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com