Chuck,
Yes, DSPFD is YMD, as opposed to DSPOBJD, which is MDY, mixed breed.
I'm still taking SQL 101, I need to step it up.
What is the system file for DPSOBJD?
Probably could do an SQL over this file, outputting the last use date from MDY to YMD, along with concatenating the century code, LUDCYMD.
Rob, have you already done something similar?
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, February 11, 2015 12:08 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Object Last Use Date MDY compare issue
On 11-Feb-2015 10:01 -0600, Steinmetz, Paul wrote:
I frequently need to compare object last use dates.
Some IBM output files QAEZDISK (use YMD while others (DSPOBJD,
DSPFD) use MDY.
FWiW: My recollection is that the OutFile fields for the Display File Description (DSPFD) feature, consistently have the date-like values stored as YYMMDD.
When MDY is used, I'm constantly breaking up the LUD into individual
work fields, MM, DD, YY and then concatenating them back together with
the century for the object date compare.
ODCDATCYMD ODCCEN || ODCDATY || ODCDATM || ODCDATD
Is there a better or easier way of accomplishing this?
The Create Logical File (CRTLF) from DDS and the SQL DDL CREATE VIEW can be used to give an alternate _logical_ presentation of the data [even omitting column data that is not of interest]. Each optionally allows for a keyed Access Path to be created on the derivation of the data if the /compare/ can take advantage of the Derived Key Index; the SQL would require a second DDL statement, CREATE INDEX, because a VIEW is not keyed.
Note: The derived key index can *not* refer to a UDF, so the expression must be something like the one shown for example, the result of concatenation of substring of the date-like field; I do not recall being able to do that easily or if at all using DDS, but IIRC there are some specific DDS logical mapping that involve the Date Format (DATFMT) specification.
Note: The Last Used Date supports a value of blanks; mapping the blanks to the NULL value may be an effective requirement, especially if the Date data type is the mapped-to\cast-to type. The OS also allows for some invalid leap dates to be stored for those date-like fields [because the QLEAPADJ value that was in effect when the /date/ information was stored is not included] that are normally just a string of digits or possibly blank [when a NULL value is probably more appropriate to represent a lack of a value being established for that particular attribute].
--
Regards, Chuck
--
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,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
