Re: CPF5035 used to be ignored, now causes SQL to fail

Exactly. Change the offending blanks to zeros within the trigger so that
the data in the file is not corrupt. Then log the offending program in a
file. Your data stops being corrupted and you know what programs are
causing the problem so they can be fixed. Once all programs are fixed,
remove the trigger since it will cause a minor amount of overhead on
inserts.

Brian May
Project Lead
Management Information Systems
Garan, Incorporated
Starkville, Mississippi



rob@xxxxxxxxx
Sent by: midrange-l-bounces@xxxxxxxxxxxx
01/20/2011 08:47 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: CPF5035 used to be ignored, now causes SQL to fail






Interesting idea Brian. Even if it is only for a short term. Like, log
the offending program to a log file to be fixed later.

One option to fix the file is to generate it with DDL instead of DDS. DDL

will not allow the corrupted data into the file in the first place. I can

dig up examples of how that is true if needed.

Of course, you still have to fix the program because now it will abort on
the WRITE or UPDATE when it tries to put corrupted data into the file. One

way to look at this is you can bypass the trigger because, by Golly, the
program will stop cold. The downside is you'd better be prepared to drop
what you are doing and fix the program as needed.

If you are journalling your data then it shouldn't be too hard to see who
is writing the offending data into the file. (Providing your journals go
back far enough to that program that is only ran at month end.) We keep
our journals for a length of time which always ensures that it has two
month ends. But our journal library is 11 times the size of our biggest
data library.
PRTDSKINF *LIB
% of Size in
Library Owner Disk 1000 bytes Description
#MXJRN MIMIXOWN 18.77 1191615143.9 MIMIX - BLDJRNENV
QGPL QSYS 1.73 109729472.5 General Purpose
Library
GDIDIVF SSA 1.44 91496685.6 Old 405CD data
ROUTINES ROB 1.32 83697569.8 Common routines
GDIDIVFBK DARREN 1.02 64974397.4 GDIDIVF temp/backup
data
ERPLXF SSA .98 62324822.0 Live Infor LX data
...

When you WRITE or UPDATE corrupted data with RPG does it log so much as an

informational message? If so, is there a way to percolate the job log
message into another message queue, QHST, something so you can spot these?

Then there's using some documentation tool to list all the places which
update fields. A bit more proactive. Not fool proof though. It wouldn't

catch CPYF ran from the command line. A program without source. Updated
via QUERY output file. An internally defined O spec which writes out all
blanks for just one big record length field. And a host of other
loopholes.


Rob Berendt