On Sep 17, 2007, at 8:25 AM, Chris Mason wrote:
Ed
I used to maintain a test/education environment for a number of
classes, some of them for colleagues, and at one point I despaired
of all the members in all the partitioned data sets for which I was
responsible. Probably matters came to a head when I, having spent
some time building up some customization members, found I had done
it all before.
My technique - not an application - was to create a member, $$
$INDEX, in each partitioned data set where the member name of each
member was followed by a short explanation of why it was there.
This applied, typically, to "card image" members. In the case of
partitioned data sets with load modules, I created a section in the
$$$INDEX of the partitioned data set where I kept the corresponding
source.
I believe - it's some time ago now - I also had a simple data set
where I kept a similar explanation of each of the partitioned data
sets - it's coming back to me now! - under the name <hlq>.£££INDEX.
Each set of classes had its own <hlq>. I dare say that maps more or
less to production environments.
I expect it might be possible to create some application which has
a hook into the process of editing a new or existing member which
sets up a structure similar to the one I just described and prompts
you to fill in or adjust the short description as you exit from the
editing. In other words, an application which attempts to impose
the discipline which I had to impose on myself to keep a tidy and
well-documented working space. This, of course, would be suitable
for "source" members; some other technique would be needed for load
and object modules.
-
At the time I was doing a consultancy which involved having a
couple of test systems all to myself much of the time, I imposed a
similar system on the partitioned data sets I created and slipped
in the trademark $$$INDEX member in common partitioned data sets
where I had to store some members. Additionally these members had a
"signature" which was the initials of whomever was responsible for
having created the member[1][2]. Keeping track of who is
responsible for members in a necessarily shared partitioned data
set, say the procedure partitioned data set, is just about
impossible without a similar system. I hoped I had set an example
from which the customer folk might benefit. I wasn't there long
enough to find out!
Chris Mason
[1] Of course this is also "documented" by the userid but to use
the userid would require looking up a code.
[2] As I was there only temporarily, I used the "signature" of the
permanent person most associated with the job with which I was
assisting. I guess a project code might be more appropriate in a
fully developed system which would map to the person currently
responsible for the project.
Chris:
Yes there is that manual way. But I believe the original poster
wanted an "automated way". That is where the rub comes in (I
think). There are just too many ways to do the same thing. Each
application might use repro (for VSAM) or EXPORT xxx temporary
or .... a program that was written just to do that. There has to be
at least 6 or 7 ways to do the same thing, mind you none of them are
probably wrong. How do you "report" a repro so there is a standard
way of talking about it. "Proc xyz (and stepxx) is doing a repro from
dataset A to dataset B " is that a back up or copying the dataset for
some other process to use. The same scenario gets worse when it comes
to say "copy". How do you tell the documentation package the
difference between SORT and IEBGENER (or IDCAMS or SORTGENER
or ....). The most you could do is proc step xyz is creating a new
dataset called z.x.c. I am not saying it can't be done it is just not
straightforward on how to do this so everyone (including the package)
could get the information (correctly) to the reporting process.
Ed
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
