What PTF stands for (Program Temporary Fix) is of course no longer accurate -- as long as you stay on the same product release level they are neither "temporary" nor confined to "fixes". Many small functional enhancements are implemented using PTFs and such PTFs are also part of some RSU and PUT level, so maintenance to a PUT or RSU level is more than just fixes as well. Sometimes major functional enhancements may be added as sort of an intermediate release by installing a dependent function FMID that does some combination of adding new elements or taking over ownership and replacing some elements that were originally owned by the primary product FMID; other release changes may be regarded as significant enough for a new function FMID that completely deletes and replaces the FMID(s) and all asoociated components of a previous release. IBM or a 3rd party vendor could also decide to just parckage what would effectively be a new release as a massive PTF that changes everything belonging to the product but continues using the same FMID.
SMP/E has some support for maintenance of Assembler source code and other "text" elements, but support for source code maintenance is admittedly pretty rudimentary -- either complete replacement or record insertion/deletion based on embedded sequence numbers. This has historically not been a priority area for SMP/E enchancements because with rare exceptions (installation customizable exits, sample programs, and text configuration files), most z/OS system and product code from IBM has been Object-Code-Only for decades and is maintained by installation sites at the object module level. IBM obviously must use additional source code management tools internally for co-ordinating and properly sequencing updates to the source code behind the PTFs. Some other readers of this list may know what those tools are. Joel C. Ewing On 5/20/19 11:20 AM, Sankaranarayanan, Vignesh wrote: > Thanks for writing this up Joel! > Is it fair to say that SMP/E is not strictly error-fix anymore, since there > are now INCremental releases from CA (for example), which allow for the > introduction of product feature(s)? > If it's RSU1903 or PUT1903, sure, that's fixes, but with the growth of > Continuous Delivery, product development itself is being sped up due to > shortened release cycles (think MQ now does CD). > > On the other end, GitLab (a provider of Git) is now offering package > management. > > Are the 2 products/technologies converging? > Hypothetically, if they are, is Git better than SMP/E, or vice versa? > That is... is tomorrow's SMP/E going to be "Not Your Father's SMP/E", having > stood the test of time, and possibly better at version control / package mgmt > than Git? > > Again, I just want to hear folks' thoughts on this topic.. > > – Vignesh > Mainframe Infrastructure > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf Of > Joel C. Ewing > Sent: 20 May 2019 16:10 > To: [email protected] > Subject: [EXTERNAL] Re: Comparing SMP/E to Git > > My understanding of Git is fairly superficial, having only read about it and > not actually used it, but it would appear that the orientation of git is > primarily one of files/modules, tracking collections of those and the > assigning of versioning levels for the entire collection of files. > Distribution of a product involves selecting a version level from one of a > linear progression of versions and supplying all pieces of the product > corresponding to that version level. > > SMP/E on the other hand only deals with product versions at major version > levels in the form of supplying and new product FMID that supercedes the > FMIDs for earlier versions of the product. SMP/E has as its primary focus > fixes (PTFs) that resolve problems ( APARs) for specific FMID levels of a > product. Installing a singe PTF could change just a single file/module of a > product, or it could change many, even all, files in the product. SMP/E > manages the handling of interdependencies among PTFs, APARs, and FMIDs. You > can choose to distribute a product at a specific maintenance level as defined > by the set of libraries known to SMP/E and the associated SMP/E databases > that define what FMIDs and combination of PTFs are installed. > > The SMP/E approach appears much more powerful in that it can support the Git > approach as a subset by permitting "level set" PTFs which change so much of a > product as to be effectively a new sub-version level that is required for all > future updates. Some z/OS products, particularly some that are Unix-based, > follow that approach and tend to have massive-sized PTFs that resolve many > APARs. The normal PTF approach where one PTF resolves one APAR or a > relatively small number of APARs and affects a relatively small number of > files has the advantage that it allows more precise control over how much you > choose to perturb a functioning system just to resolve a specific critical > issue that is causing problems at your installation. That approach is > possible even with very complex applications in z/OS because the large load > modules of such applications are typically comprised of many linked modules > and SMP/E can perform updates at the level of individual modules. Although > it is typical to install many PTFs at a time during a regular planned > maintenance, the PTF approach allows a lot of flexibility if specific fixes > are known to create unresolved problems. The approach of tracking known > problems in the form of documented Error Holds against a PTF can even allow > an informed choice of whether it makes sense to install a PTF that fixes a > serious problem even though it may introduce some other unresolved problem > that might not be an exposure at your installation. > Joel C. Ewing > > On 5/20/19 8:28 AM, Sankaranarayanan, Vignesh wrote: >> ... in what ways are they similar, and what ways are they different? >> Is the world better off with SMP/E-like structure for code, or is z/OS etc. >> better off with Git-like structure? >> >> - Vignesh >> Mainframe Infrastructure >> >> ... > > -- > Joel C. Ewing > .... -- Joel C. Ewing ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
