I might sound like a broken record but I'll say it again - If you don't already know how to use Naviquest, learn to use it - if you're going to re-write code, it will be your friend. Unless you have a test-plex or a 3rd party product, Naviquest will give you a safe way to test your code changes. There is a Redbook and a Naviquest User's Guide - I don't have the links handy.
Create a test case library. Create several test cases that exercise EVERY code segment. Use the comment lines to establish your expected results. Run your test cases against the current code. If you understand the code, your expected results will match your test results. This may also reveal code segments to you which are actually 'orphaned' meaning they never get exercised/executed. Make it a rule to never delete test cases. Modify them as little as possible - only what's needed to keep them current. If you need a new test case that is slightly different than an existing test case, copy the existing one & modify the new one as needed. Once your test cases are in place and you've ensured that every current code segment is tested, you've got a test-bed to use for regression testing. To me this means you can make code changes in a parallel environment, run the test cases through both the old & the new code & then compare the results - all of which you can do through the ISMF options or in batch (ISMF testing ties up your TSO session and with a large set of test-cases can take significant time). This should give you an exact understanding of what's changed. And I always advise people to use WRITE statements. In code I've written or modified, every EXIT statement is preceded by a WRITE statement. These WRITES identify the exit points and gives me helpful information or values used in that code segment. This is a huge time saver when you're trying to debug a problem and eliminates any lingering doubt as to where in the code the allocation fell out. Using DFP segments - I've only found them useful when identifying TSO users, but other than that I prefer the flexibility & control the SMS code gives me. Simple does not necessarily equal better. HTH's -\ ddk We have a rather "fragile" SMS environment at present. It has basically grown "ad hoc" over the course of almost 2 decades. I really need to document it very well. Once documented, I would like to use that in order to reengineer the environment. Any pointers would be greatly appreciated. -- John McKown This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
