In a recent note, Clark F Morris said: > Date: Thu, 10 Aug 2006 13:03:52 -0300 > > Here I agree with the management that wants something simpler than > SMP/E for installation. I also believe that the overall design needs > a revisit given the following: > > 1. A RESTORE can be painful if it involves more than one SYSMOD or a > chain. I don't know if I ever did a restore, finding it simpler to go > back to a previous system or to move forward. > Agreed. A model to study here is VM/CMS/VMFMERGE. VMFMERGE is entirely devoid of (an analog of) the ACCEPT command. Rather, its (analog of) the RESTORE command retrieves all elements from (the analog of) the SMPPTS. If a redesigned SMP/E did likewise, ACCEPT would be optional or unnecessary, and RESTORE could become an "UNDO" of an arbitrary number of layers, and even done iteratively if desired.
> 2. SMP may still not cover all of the entities (I'm not certain if > the printer FCBs were covered for example) and still may not support > such things as panel compilation or prepping. > Agreed. The repertoire of utilities should not be a fixed handful, but extensible without limit by the user or ISV. This would require considerable extension of SMP/E's analysis of JCLIN in order properly associate libraries in the JCL with DDDEFS in SMP/E. It would no longer be possible to rely on a fixed set of DDNAMEs such as SYSLIB and SYSLMOD. > 3. The reporting, while probably improved still may need further work > for things such as system HOLDS, where grouping like reasons would > reduce the amount of review. > And here, SMP/E outshines VMFMERGE. > 4. The dependency maintenance must be difficult to keep straight and > any aids for this would be of use for all vendors. > No longer a concern for us since we have the process automated. But we stumbled repeatedly along the way, and would have appreciated an aid, even as SMP/E provides GIMZIP and GIMDTS to assist vendors in those packaging operations. This might take the form of an APPLY GENDEPEND operation, where the developer could supply to a fully populated and up-to-date target zone a partial SYSMOD, lacking PRE and SUP statements, and SMP/E could write to SMPRPT the suggested content of those statements. > 6. Having a common install process for all system related software > that both allows each vendor's code to be kept separate but also > checks for interdependencies would be extremely useful. Note this is > also needed for DB2, IMS and CICS. > And might require unprecedented coordination among the vendors. > 8. SMP should be able to control and run source modifications for any > language supported by the z series. This includes COBOL. After all > JARS (SMF reporting) was written in COBOL. If IBM would implement the > requirement to implement the bit and native binary data type in the > 2000 standard COBOL could work with any IBM defined data area. > Reference modification already makes it simple to rearrange the SMF > type 30 record. > Somewhat similar to (2. extending the utility set), isn't it. > It will be fun getting to a new or even noticeably improved system and > the definition of what new and improved should look like and do will > not be easy. However if it makes it easier to package code, install > same, update it and modify it with greater safety it will be well > worth the aggravation. > Yes. And here, as previously, I take issue with the view that each site should set its own conventions for data set names. Taking the "vendor knows best" view facilitates interoperability of products from different vendors (example: we learned by unpleasant experience that many vendor products work poorly or not at all unless TCPIP is the HLQ for IBM's TCPIP product). Likewise, it facilitates transfer of skills and JCL from site to site. (Imagine if a site were to use a local prefix instead of SYS1. In this respect, IBM is merely the biggest vendor among many and the same considerations that govern IBM's names should apply to other vendors.) Likewise, using the vendors' data set names allows the vendor-supplied documentation to be used without an errata sheet to correct for local names. It has been suggested here, in refutation, that installing the documentation could include tailoring for local naming conventions. Perhaps SMP/E should provide support for such a tailoring utility in the extended utility set in bullet (2). I know, it could be done with HLASM AREAD and PUNCH statements, but would you really want to? "Flexibility is not always a virtue: did you ever try to sit on a very flexible chair?" (Heard from Bill Waite; origin uncertain) OTOH, and before others take issue, the vendor _should_ provide a facility for installation with alternative data set name(s) to allow construction of test systems. -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- 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
