On 2014-03-31, at 22:19, Jon Perryman wrote: > Shmuel is correct. Having a PTF level can be misleading. You are only seeing > PTF numbers that IBM has chosen to display. If the C compiler consists of a > 100 modules, then there are 100 PTF levels which may or may not be important > to you. > (But think of "module" as more like "CSECT" than "load module".
> UNIX has this concept because the product is replaced as a whole. z/OS > updates are at the module level rather than product level. You may find the > release somewhat useful but rarely will you find that listing 4 PTF's as a > levelset being of much use. In addition, you have the various includes and > related products play a larger role than the compiler level. > 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. (Swedish chow mein?) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
