Re: DDE bugs

Thanks for the reply, Barbara (and all others).

You are right, this thread is part of the progression from messages I left in
December.

Here's the thing.  I am trying to find a balance with trapping potential
errors that cause a problem with that little thing called DATA INTEGRITY (as I
emphasize to those who should, but don't, care [not a completely fair comment
- see "higher up" comment below]), especially where the data comes from
another system with which I have no knowledge or control and have seen bad
numeric data come over, with (back to the other side of the balance) a limited
amount of time, especially when working with a higher-up who has a lot of
confidence (much more than I do) that the data coming from the other system
will be O.K.

I will check out the resources you suggested.

Dan Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952

-------------------------- Original Message --------------------------

>Date: Tue, 2 Jan 2001 18:04:00 -0500
>From: D.BALE@handleman.com
>
>I've got a real head-scratcher here, folks.  In my attempt to avoid using
>TESTN for many numeric variables, I thought I'd be smart and just move an
>entire record to a data structure and let the *PSSR catch the DDEs.  Fat
>chance, as it turns out.
> ...
>Variable  . . . . . . . . . . . . . . . : DTLHI#
>  Type  . . . . . . . . . . . . . . . . :   ZONED
>  Length  . . . . . . . . . . . . . . . :   9 0
>  * . . . + . . . . 1 . . . . + .
>  F040F140F540F240F2
>
>Variable  . . . . . . . . . . . . . . . : HDLITM
>  Type  . . . . . . . . . . . . . . . . :   PACKED
>  Length  . . . . . . . . . . . . . . . :   9 0
>  * . . . + . . . . 1 . . . . + .
>  001050202F
>
>The HDLITM shown above is the result of a Z-ADD DTLHI#  HDLITM.

Dan, it looks like invalid zones don't count as invalid zoned decimal data
except where the zone is important (the last one that determines the sign).
I vaguely recall this behaviour from the early days of RPG IV when we were
getting RPG IV to behave like RPG III.  In your example, all the digits are
ok, and the final byte is ok.

A couple of suggestions:

1. If you just need to know whether the whole file is ok, you could do a
   CHGPF with new DDS that has the zoned fields defined as packed, and
   then another CHGPF with the original DDS.  If there is invalid decimal
   data in any of the zoned fields, the first CHGPF would fail.

   You get a message in the joblog for each bad field, something like
   "Error occurred for FLD1 record number 1".

   I just looked at the original message for this thread in the archive
   and I see that you've already tried something like this.  You need to
   have a conversion from zoned to packed to see the failure and for some
   reason, although CPYF puts the messages in the joblog, it doesn't fail
   the copy.

2. If you need to do this regularly, for many different files, you might
   consider writing a program that extracts the field definitions for the
   file (API QUSLFLD) and then loops through the records of the
   program-described file, testing all the zoned fields for valid data.

   From the archive, I see that you already thought of this. I don't recall
   seeing an example that does exactly what you need anywhere, but it's
   not really that hard to use QUSLFLD.  I just did a web search for
QUSLFLD,
   and I found a site that has a couple of programs using QUSLFLD that you
   could probably modify: http://earth.vol.com/~craigr/jcrcmd2.html

Barbara Morris
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---