Comparing SMP to git is like comparing a hammer to a screwdriver; each is good at what it is designed for and terrible at what the other does well.
SMP is designed to manage dependencies, and does that well. It does not have good support for multiple updates of the same element, while merging updates is common in the open source world. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Joel C. Ewing <jcew...@acm.org> Sent: Monday, May 20, 2019 11:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
