Jon,
Just create a table as follows:
A R DDSDATEF
*
A DDSYMD L COLHDG('DATE *YMD') DATFMT(*YMD)
A DDSISO L COLHDG('DATE *ISO') DATFMT(*ISO)
A DDSMDY L COLHDG('DATE *MDY') DATFMT(*MDY)
A DDSUSA L COLHDG('DATE *USA') DATFMT(*USA)
A DDSDMY L COLHDG('DATE *DMY') DATFMT(*DMY)
A DDSEUR L COLHDG('DATE *EUR') DATFMT(*EUR)
A DDSJUL L COLHDG('DATE *JUL') DATFMT(*JUL)
Insert a few dates and then run it through SQL (Select * from YourDate).
You'll see all dates are returned in the same format. If you change the
format in your environment, the changed format is used to show the dates.
RPG converts the dates into character representations of the dates depending
on the date format in DDS or in the H-Specs and converts them back.
BTW it is even possible to insert dates with SQL that are outside the valid
range for the date format (without any problem) - even into a DDS described
physical file.
When accessing this file with native I/O you may get trouble in the moment
when the scaliger no is converted and brought into the RPG structure.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"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!"
?Train people well enough so they can leave, treat them well enough so they
don't want to.? (Richard Branson)
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Jon
Paris
Sent: Dienstag, 26. November 2019 00:47
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: SYSCOLUMNS & SYSCOLUMN2
Comments in-line John.
On Nov 25, 2019, at 5:58 PM, John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:
I notice that if you have a date in a table that the reported length is 4
- which while technically accurate is fundamentally useless as a program can
never see it as that length.
I disagree with you on the "fundamentally useless" part. It could be
useful to know how much raw storage something takes up, and in the
past I have been frustrated at not being able to get this information
easily.
I'm normally interested in the storage taken up by a row or the whole table.
Not an individual field - but maybe you have a use for it.
<snip>
I will say that if it were up to me, I would not have the LENGTH of a
date "depend on the format" any more than the length of a numeric
field depends on commas or decimal points. I would accept an argument
for it always being 8 (with the rationale that a date is ultimately
numeric, and *ISO dates have 8 "human readable" digits) or always
being 10 (with the rationale that the string representation of an *ISO
date uses 10 printable characters).
But it DOES depend on the format. And I don't control that. If the date was
defined as *MDY in the table (yes I know that is foolish but people do it)
then in the program it occupies 8 bytes. If it is *ISO or *USA then it is 10
bytes.
Is there another table or a column in either SYSCOLUMNS or SYSCOLUMN2
that does accurately represent the size of the column or do I have to
calculate it?
I am pretty sure you have to calculate it. But it's not hard. I think
what you are after is simply LENGTH(CHAR(my_date_field)).
Not quite that easy - remember i said it was a utility function - so the
name of the field is not known at compile time.
Jon Paris
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
