z/OS maintenance is a smorgasbord. Those 4 PTF's listed by C imply that all PREREQ's/COREQ's are installed and is what IBM considers a base level for C. I suspect this was done to appease UNIX guru's who want to know a level. For most products, IBM gives you a dotted release level. Additional PTF's can be installed but are not reflected in any level. Customers want to correct the problem they have and get unhappy when a PTF requires changes to a large portion of the product. They want to test the affected area and not test the entire product. Large PTF's and PTF's with large PTF pre/coreq chains violate this. As for the PTF number in the ASM header, that's useless because ASMA90 is 64K (definitely not one module).
Rarely will radical changes such as changing optimization algorithms be implemented thru a PTF, In general these types of changes occur at FMID level (Although there are exceptions). Jon Perryman. >________________________________ > From: Paul Gilmartin <[email protected]> > > > >If, as HLASM appears to do, there is a unique CSECT that is updated >by each PTF, then each PTF PREreqs its immediate predecessor, etc., >inductively. The graph of service is unbranched; you don't have the >Chinese menu smorgasbord of service, and the PTF level is definitive. >(But customers may be constrained to fix bugs not directly impacting >them. Sure makes problem analysis easier for Tech Support.) > >> What problem have you encountered that has you making the decision to >> include compiler level? >> >If code generation changes at some level, even if the service is not >corrective, it may be optimizing, so desirable. I can envision a >customer's desiring to audit for this. > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
