A date field is always stored as 4 Byte Integer Value (scaliger number).
The "external" length depends on the date format used within the job where
the data is accessed, which can be 6 (Julian Date Format) , 8 (*DMY, *MDY,
*YMD), or 10 (*ISO, *EUR, *USA, *JIS).
Mit freundlichen Grüßen / Best regards
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Buck Calabro
Gesendet: Wednesday, 06.2 2013 17:54
Betreff: Re: QADBIFLD versus DSPFFD OUTPUT(*OUTFILE)
On 2/5/2013 6:22 PM, John Yeung wrote:
On Tue, Feb 5, 2013 at 5:59 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
Is it possible that decimal place is given a different name? Like
It's exceptionally unlikely. Python makes it very easy to introspect
(such as getting a list of all an object's attributes) and I haven't
found anything. I've asked on the iSeries Python forum, but I don't
expect to hear back. (There are not many of us!)
I'll check out that forum.
As for SYSCOLUMNS / QADBFILD, none of the columns there reflect the external
buffer length. I'm not sure I want them to, as I tend to use this for
directly processing a swath of data off of disk, and I'd rather know how
much room a date field occupies there (4 bytes) rather than in the external
buffer as seen by HLLs like RPG.
However, having said that, I completely understand why that's frustrating,
because it'd be very cool to know the external buffer length for more
typical processing chores. The QUSLFLD API returns the expected external
buffer length of 10 for date fields (I just checked it).
Not being an IBM Python-er (yet) I don't know how to package the output of
an API for Python to consume. My very wild guess is to put the API in an
RPG program that creates a result set of the columns and then Python
traverses the result set. Might be a ridiculous idea, who knows?
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l