I'm trying to build utility routines that can work through a trigger buffer - or journal image and identify the individual fields that have been modified.

I used the term table because even if created with DDS it is still a table that can be accessed with SQL. It's origin is irrelevant to my purpose.

On Nov 25, 2019, at 11:11 PM, John Yeung <gallium.arsenide@xxxxxxxxx> wrote:

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.

It sounded like you wanted to look at things from an SQL point of view
(you mentioned "table" rather than "file" for example). From that
point of view, a date is a date is a date. My understanding is that
there isn't such a thing as defining a date format *in the table*,
even though you can do it in a file with DDS.

Of course, I think it would be conceptually possible for IBM to
provide more SQL exposure to DDS-specific features, but so far I don't
think they've done it for this, and I wouldn't expect them to.

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.

What does being utility software have to do with anything? One of the
benefits of using SQL is that you have the flexibility to introspect
and compose at run time. That actually strikes me as one of the
primary purposes of SYSCOLUMNS in the first place.

John Y.
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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.