Re: DDS Time vs. DDL Time -- MIDRANGE-L

I concur with Chuck. Let me put it another way. If you create a DDS file
with date or time fields and then use cpyf to copy a file of the same
length filled with all X's (or any other character) then it will abort.
If your dds file just has numbers (packed or otherwise) it will let the
cpyf complete successfully and you will have screwed up numbers. IBM did
this because many legacy fields were overwritten. For example, let's say
your ERP package had a numeric field in there for Mongolian currency
conversion. And you did no business there and decided that you wanted to
overwrite that field with an alpha code field you could do so with a data
structure in RPG. IBM figured with a new data type they didn't have to
worry about harming existing applications and did it right. So the
"verify on write" argument is only partially true. Now, if you redefine
that same all numbers file with DDL from SQL instead of DDS and try that
CPYF it will abort. IBM figuring that, again, you better just know that
if you're going to go whole hog and convert all your DDS to DDL.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
[1]http://www.dekko.com

-----midrange-l-bounces@xxxxxxxxxxxx wrote: -----

To: [2]midrange-l@xxxxxxxxxxxx
From: CRPence <crpbottle@xxxxxxxxx>
Sent by: [3]midrange-l-bounces@xxxxxxxxxxxx
Date: 10/20/2011 05:09PM
Subject: Re: DDS Time vs. DDL Time

On 20-Oct-2011 12:10 , Raul A. Jager W. wrote:
> There is a difference, in DDL (SQL) defined files, the data is
> validated when writing the record, in DDS files it is validated at
> read time. It is very likely that your application is trying to write
> a "wrong time".
>

FWiW that difference being alluded is unlikely to be an issue for
DATE, TIME, or TIMESTAMP data types. As I recall these types were
purposely not designed with the ability to so easily write\insert bad
data, since there was no compatibility concern for allowing the
deprecated practice of using EBCDIC blanks for missing values, as was
often done on the S/36. For example, an attempt to write bad data into
a TIME [or DATE or TIMESTAMP] field using the CPYF FMTOPT(*NOCHK) is
improbable to effect similar to what can be accomplished for a zoned
decimal or packed decimal numeric data type.

Also the oft cited "validated on read" is at least mildly overstated
if not generally misleading. While the claim "validated on write" is
sufficiently succinct and accurate, the quote "validated on read"
implies something less accurate for lacking elaboration on what the
database versus the reader provides with respect to validation. For
"direct map" requests the database may choose [or more implicitly simply
does not] provide any validation. The date\time types for the
implementation using implicit cast to character string representations
are limited for the opportunities of direct mapping of the internal
[representation of the] data.

Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: [4]MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: [5]http://lists.midrange.com/mailman/listinfo/midrange-l
or email: [6]MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at [7]http://archive.midrange.com/midrange-l.

</crpbottle@xxxxxxxxx>

References

Visible links
1. http://www.dekko.com/
2. mailto:midrange-l@xxxxxxxxxxxx
3. mailto:midrange-l-bounces@xxxxxxxxxxxx
4. mailto:MIDRANGE-L@xxxxxxxxxxxx
5. http://lists.midrange.com/mailman/listinfo/midrange-l
6. mailto:MIDRANGE-L-request@xxxxxxxxxxxx
7. http://archive.midrange.com/midrange-l