I agree with Darth, except I don't like EXIT. My routines all leave via the bottom. My last statement is a write of what the routine set.
Dave Gibney Information Technology Services Washington State University > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Darth Keller > Sent: Thursday, August 23, 2012 11:30 AM > To: [email protected] > Subject: Re: Documenting SMS environment & ACS routines. > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
