🚀 go-pugleaf

>AKornelis wrote:
>>You also mentioned SMP/E packaging. As far as I know there are no
>>coding standards at the assembler or macro source level for
>>packaging. I would mainly say to avoid collisions of names for
>>modules or macros. [snip]
>
>CCraddock wrote:
>You're correct that the main consideration is naming. You cannot
>have two elements with the same name in the same zone.
>
>The main way to avoid this is to select a three letter acronym (TLA)
>prefix for the elements you plan to distribute and then use that as
>the first three characters of each element (member) name. IBM
>provides a service for vendors to register product TLAs, which means
>you can be fairly sure your names won't collide with other vendors
>names - and can therefore be installed in the same zone.

With z/XDC, I take a different approach (to the names conflict
problem) that allows me to disregard having to use a unique "TLA".

One of the main purposes of SMP/E is to maintain an inventory of all
of a product's elements, and then use that inventory information to
manage the application of updates and fixes. I find this to be very beneficial.

Another major purpose of SMP/E is to manage the resolution of system
release dependencies at product installation time, such that
different elements are installed depending upon the system (and
product) release level.

Well, z/XDC development takes the approach of resolving system
dependencies at execution time, not at installation time. A major
benefit of this is that there remains little reason for XDC to be
managed by the same SMP/E that manages the MVS system.

Consequently:

   - Because I do find SMP/E inventory management capabilities
     to be of significant benefit for maintenance management,
     I do distribute z/XDC with SMP/E packaging.

   - On the other hand, because I do NOT need SMP/E to manage
     dependencies between z/XDC and MVS, I require my customers
     to create a *private* set of z/XDC SMP/E control libraries
     (CSI etc.), entirely separate from their other SMP/E
     libraries.

For me (and my customers), the benefits are significant:

   - First, I don't need to worry about name conflicts.
     Example, part of the z/XDC distribution includes a MACLIB
     containing 194 macros having names that are mnemonically
     meaningful. I would not want to have to burn 3 of a name's
     available 8 characters to use as a "TLA".

   - Second, I can impose my own SMP/E definition conventions
     upon the installation process without concern for
     conflicting with IBM's or someone else's conventions.
     (Examples:
       - Making RC=4 (instead of =0) from IEBCOPY and
         AMASPZAP the highest acceptable completion code.
       - Defining a default PARM for assemblies that is
         specifically suitable for z/XDC assemblies.
       - Defining PARM=IGNIDRFULL as the default for AMASPZAP.
         (This, and permitting RC=4, are particularly important
         to me because most of z/XDC's maintenance is
         distributed as zaps.)
     etc.)

     Doing this helps standardize the z/XDC installation
     process, and that results in a tremendous reduction in
     tech calls at installation time!

   - Third, because I can impose a standard installation
     process, I can provide my customers with a "black box"
     installation job stream that will always work without
     requiring any SMP/E expertise whatsoever on my customers'
     part.

Still, some people might think that having separate SMP libraries is
wasteful of disk space. It makes me sort of smile when I hear
that.  (see:? [:)] )



Dave Cole              REPLY TO: dbcole@colesoft.com
Cole Software          WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road    VOICE:    540-456-8536
Afton, VA 22920        FAX:      540-456-6658