On Tue, 12 Jun 2007 06:55:29 -0500, Russell Witt wrote:
>
>The entire question of how well should we document IBM utilities and
>procedures was discussed just today regarding GDG's. We have some utilities
>(such as TMSCOPY to backup the TMC) were we recommend creating GDG's to keep
>some number of backup copies. It was asked if we should give examples of how
>to define GDG's in our manuals for those system-programmers that have never
>defined a GDG. This morning, I stood on the "NO" side but am starting to
>wonder if that was correct.
>
Stick to your knitting. As an example, it's tedious how the Rexx RM
repeatedly steps outside its jurisdiction to document the syntax of
TSO commands.
>To answer your question about IEBUPDTE; to apply the CL05205 USERMOD you
>concatenate two members together. Barry sent the CL05205S member from our
>PPOPTION PDS which is the SMP/e control statements; you also have the
>CL05205 member of PPOPTION. By default, the CL05205 member contains the
>following IEBUPDTE control statements;
>
>./ CHANGE NAME=TMSUX2E
> SSI=CL05205 CL05205 00038000
>* PLACE USER CODE HERE CL05205 00053000 <== this will replace
>the existing line
>
This appears to be a skeleton, to be customized by the customer. I'd
suggest a few things when a supplier does this sort of thing:
o Supply a couple lines of context, before and after, so the customer
can readily spot what ISPF/PDF autonumbering does, and perhaps
to guide ISPF concerning what numbers to use:
./ CHANGE NAME=TMSUX2E
SSI=CL05205 00038000
* 00052000
* PLACE USER CODE HERE 00053000 <== this line will be replaced
* 00054000
o Given ISPF's technique of using 79-80, this only allows 19 lines of
insertions before a line number collision happens. I'd suggest
that the initial development (too late now) insert several dozen
dummy lines; renumber the file, then delete the dummies to leave a
wide number gap.
>What IEBUPDTE does is to replace or insert lines based on the line sequence
>numbers (column 73-80). Why do this instead of simply replacing the entire
>module? Because we (CA-1 support) might be forced to make some changes to
>the entry or exit logic, or some USING in the middle of the sample exit and
>then you would have to re-write the exit. Using IEBUPDTE with the same
>sequence numbers (and we try very hard not to modify those sequence numbers
>
Sequence numbers can often be repaired by the sequence of operations:
SuperC with the UPDMVS8 option, followed by
IEBUPDTE
But I have found UPDMVS8 to be permeated with bugs. When I do this, I
use UPDCMS8 (works on MVS) followed by a Rexx filter to convert to
IEBUPDTE commands.
>though accidents do happen) allows an existing exit to be applied, and
>re-applied over and over and over again without having to go and re-write
>any code. Many clients are running with CA-1 exits that haven't been touched
>in many-many years (read decades).
>
There is an SMP/E programming technique:
o Never ACCEPT USERMODs.
o If a vendor PTF updates the source file (or replaces it, with sequence
numbers stable), RESTORE the USERMOD; APPLY the vendor PTF, then
re-APPLY the USERMOD.
It's a shortcoming that SMP/E does not support source updates for data
element types other than ++MAC and ++SRC. It's a shortcoming that
SMP/E does not support patch(1) as a utility alternative to IEBUPDTE
for source updates to HFS files and data element types which may be
not FB80 or may lack standard sequence numbers. (Shmuel needn't
reiterate his distrust of patch.)
-- gil
----------------------------------------------------------------------
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
