"The problem with applying fixes a la carte is that you end up with so many combinations that virtually no-one is running the same combination, let alone a comprehensively tested combination."
At least they *can* install the service in a timely fashion. With level sets so many things break that there is a lwngthy period before you can fix what doesn't work and go to the new service level. "SMP/E does not work well with products that are written in modern languages (and by modern, I mean languages with optimizers or even just compilers that check parameters on calls to routines). SMP/E works best for languages like assembler, where the programmer needs to track their own dependencies," WTF? The whole point of SMP is that *SMP* tracks dependencies. "When developing a product in a higher level language, the compiler does much of the work that SMP/E would do tracking interface changes." It's trivial to take interface changes into account. Of course, that5 takes proper packaging, but you don't blame the hammer when someone uses it do drive in a screw. CVS, git, SMP, subversion, etc., are not magic bullets and should not be judged based on how people who don't understand them might misuse them. " On the other hand, if you do a whole product replacement the need to keep track of requisites essentially goes away, it is handled as part of the build." The same bookkeeping needed to avoid a bad build gives you the information that you need for SMP packaging. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of Andrew Rowley <and...@blackhillsoftware.com> Sent: Thursday, December 7, 2017 12:57 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: SFTP On 7/12/2017 4:37 AM, Seymour J Metz wrote: > The point to requiring use of SMP is not to satisfy a checklist, but to > provide certain capabilities, e.g., tracking changes, installing fixes > without having to do a "level set", backing off bad fixes, suspending the > application of fixes with errors or requiring customer action. The problem with applying fixes a la carte is that you end up with so many combinations that virtually no-one is running the same combination, let alone a comprehensively tested combination. SMP/E does not work well with products that are written in modern languages (and by modern, I mean languages with optimizers or even just compilers that check parameters on calls to routines). SMP/E works best for languages like assembler, where the programmer needs to track their own dependencies, and products like the operating system where you have a lot of components developed separately with loose relationships. When developing a product in a higher level language, the compiler does much of the work that SMP/E would do tracking interface changes. As a developer you want to minimize public exposure of internal interfaces, to simplify future changes and development. If you allow components to be maintained individually, every interface becomes quasi-public, in that you don't know how it might be called in the future. Any change requires careful research of upstream and downstream effects and writing PRE/IF/COREQs to match. On the other hand, if you do a whole product replacement the need to keep track of requisites essentially goes away, it is handled as part of the build. To get an idea of the problems you could run into, have a play with the refactoring tools available in modern IDEs and try to figure out how you could package the changes in SMP/E, other than product replacement. Individual fixes also prohibit a lot of the optimization that the compiler can perform. The compiler can look at the program and inline routines, throw away code that has no effect etc. To do that it has to be able to examine the program as a whole. If you reserve the right to replace individual modules then you limit the optimization the compiler can do. That's not to say that vendors can't provide a single fix to a specific problem - they probably can. In many cases they would be able to check out a specific version from source-control and provide a full replacement with a single fix. How difficult that is would depend how different the specific version was to the regular version containing the fix. (Of course, if offered it might be a premium service at a corresponding price.) It's the same as a site's application code - I doubt there are any sites that package their applications using SMP/E and migrate fixes from development to production relying on PREREQs and COREQs to manage dependencies. -- Andrew Rowley Black Hill Software ---------------------------------------------------------------------- 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
