Need to find EP4101

TheOriginalOne

Active Member
Hi,

We have an issue where an object is updating files that are retired from use. The problem is that we have no idea which object is doing it. The only clue we have is that the object leaves behind a program ID of "EP4101".

Compounding the issue is that our object cross-reference is not maintained for all object/reference types. We checked XREF and sure enough, it was no help.

Would anyone know which object(s) leave a program ID of "EP4101"? Is there a Sherlock Holmes out there who could offer me a clue?

OneWorld B7334, SP 23 on System i.

Thanks,
-T.O.O.
 
That would/should be P4101.

Back in the co-existence days the E was to differentiate which system updated the table. E was for Everest; the codename of OneWorld (later E1).
 
Oh, but I wish that was the answer. P4101 is an app. We looked and you are correct about the stamp, but it seems that the files are being updated via a batch process. The question is: which one? (And yes, we are beginning to suspect a custom job, but we just can't prove it.)

Thanks for trying.
 
Well, if it is indeed the case that some batch job is updating the record, then they are not using the SL report name in the Program ID. Therefore, it is probably hardcoded. I would print the ER to a file and search for the Program ID.... hoping to find it in a ProgramID_szPID = "EP4101" statement. If that doesn't find anything then you might look for a TV that equals "EP4101". Two places to try, and that's my two cents worth.

Ben again
 
Those kind of stamps usually come from C++ or NER

Either search your debug log, and you may find it in an insert/update IO statement.

Do a find in files in your source for the offending EP4101
In C++, edit, find and replace, find in files

Id suspect it's N4101070.
 
Ben Again: "I would print the ER to a file and search for the Program ID": First you'll need to know which object to look in.

john Danter: "search your debug log": Same deal: First you'll need to know which process/object is responsible (or leave debug logging on all the time :)).

T.O.O.: try narrowing down your 'search area', for example by looking at the audit columns (time/date) in those files. For example: If it's everyday/week aroudn the same time, then it could be a scheduler batch job that runs nightly/weekly.

PS: Thanks WhippingBoy, now I finally know why they put an 'E' in there. I always wondered :)
 
[ QUOTE ]

john Danter: "search your debug log": Same deal: First you'll need to know which process/object is responsible

[/ QUOTE ] (or leave debug logging on all the time :)).


Quite right, sorry forgot that
smile.gif
 
I suggest you go back to basics
cool.gif

Refresh your Cross Reference, then find all the UBEs updating your tables (or files as you use an iSystem).
Next, follow the ER ...
grin.gif
 
Back
Top