×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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
As an Amazon Associate we earn from qualifying purchases.
This thread ...
Re: CPF5035 used to be ignored, now causes SQL to fail, (continued)
This mailing list archive is Copyright 1997-2024 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.