Re: To Date or Not to Date... that is the question

Dave,

I wouldn't recommend that :-)

There are effectively two MI interfaces on the system. The external (user) MI and the internal (IBM i5/OS developers) MI. To directly access the database requires the use of blocked MI (or generally undocumented i5/OS system state interfaces utilizing the blocked MI) which is part of the "internal" MI definition. You will definitely be "on your own".

I realize that there are users that know how to acquire system state, how to access blocked MI, and the like. That ability however is not supported by IBM and, per notes I sent out a few years back while still at IBM, quite likely to be a real pain in V6R1 to replicate. In fact some companies, that were directly accessing database files in previous releases, found their approach stopped working on V5R4...

And if you do decide to develop some "throw away" code in this area and directly access the underlying data then you're going to find that there is more going on in the database support then just mapping of Date fields :-)

Bruce Vining

Dave Kahn <dkahn400@xxxxxxxxxxxxxx> wrote:
On 19/12/2007, Bruce Vining wrote:

The internal format, as stored below MI, is a 4-byte integer representing a
Scaliger value for the date. When using above MI interfaces, such as the i5/OS
commands DSPFFD and DSPPFM or above MI database operations such as
reading a record, you generally see a formatted 10-character date value
representing the "physical" buffer layout. The "physical" record you are seeing
is an above MI view of the world. SQL can bypass this mapping of internal
to "physical" using functions such as HEX. But actually stored on disk, in what
you think of as a file, is a 4-byte integer value.

OK, thanks Bruce. I stand corrected. Sounds like I need to create an
MI program to try to peek at my database directly.