That's very difficult to trap. Mark
It's a valid point and a common scenario. I've taken two approaches in the past: 1. Dynamic analysis This replaces certain constructs in the source code automatically with calls to subroutines or external functions that update the maps in real time. So for example every OPEN can be replaced with subroutine that writes the name of the program and the file opened to the audit files. However this is only under very controlled conditions, and never guaranteed to be complete - a particular file might only be opened as part of a year-end procedure for example and so the 'correctness' of dynamic analysis depends on the code coverage. 2. Manual Labour To accept that static analysis is always incomplete, but provide a way to identify where the incompleteness occurs (e.g. to log wherever there is an OPEN with a file name that cannot be determined) and provide a way for that link to be documented and completed manually so that eventually the map becomes as complete as possible. It's the down side of having such a flexible platform, that it can make any form of automated auditing and analysis far more difficult. Brian How does it work with parameter driven code. One of my clients has procs like this: HRUN BP SOP1500 STON HORDER< HCUSTOMER< HPRODUCT< HVENDOR< P whereby the program (BP SOP1500) has the corresponding INPUT statements for the file names and opens them as F1, F2, F3 which is a real bear when reading the code. Plus all of the bottom line field prompts are also tableized. Very klugy and not friendly at all. I tend to copy the program in question to another place and do a global replace of the R/F1/ORDER just to see the flow. Thanks Mark Johnson ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
