Ref: Your note of Sun, 14 Nov 2021 16:02:43 -0700 gil writes: > Even less sensible is that SuperC comes with either ISPF or HLASM TK > with separate manuals. The M&C differ largely in messages prefixes > and degree of obsolescence. When I suggested in these lists that > SuperC be made a single dependent FMID, applicable to either product, > with a uniform component prefix, an IBM representative replied that > Would be contrary to Company Policy.
SuperC is maintained as part of the HLASM Toolkit using common source (including some conditional compilation) for MVS, VM and VSE, as for the rest of the Toolkit. The Toolkit version of the documentation applies to all three platforms. ISPF on MVS includes a copy of the current level of ASMFSUPC as ISRSUPC, and also has its own front-end logic which provides some ease-of-use support for search and compare processing. The documentation is based on the Toolkit documentation but has been modified to reflect that it is only for MVS and to focus on use from ISPF. When SuperC detects that it has been called by the name ISRSUPC, it uses the ISPF conventions for headings and messages. Whenever there is an APAR fix to the Toolkit version, the MVS PTF version of the changed object modules is sent to ISPF to repackage into an ISPF APAR and PTF. This situation has arisen for historical reasons and does lead to a few minor inconveniences for IBM, in that for example we have to maintain two versions of the documentation and have to convert every Toolkit SuperC fix into an ISPF SuperC Fix as well. However, the current scheme conforms to the standard IBM rules for shipping code and fixes, but any attempt to common up the copies would cause compatibility problems, for example by violating the unique component prefix rules for one copy or the other. Jonathan Scott, HLASM IBM Hursley, UK
