> On Dec 6, 2017, at 11:57 PM, Andrew Rowley <[email protected]> > wrote: > > > 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
Andrew, We ran into a issue where the LE difference made the product not work. My boss picked the product up off of my desk and threw it in the garbage and I was told to leave it there. LE as I have said on here for years is a IBM fu** up and should never have seen an outside customer. Early on in a conversion we got the IBM manual out and we had 5 people shouting at each other what was being said and these people were good tech people. We opened a PMR with IBM and we asked them what this paragraph said as nobody agreed. I roped a lawyer (he was sorry he ever walked by the room) and we asked him to un-legalize the paragraph and he was frustrated as there were some terms he did not have a clue on and we gave him a 5 minute overview. He looked at the book again and said IBM needs to rewrite it to make sense. If the products needs LE then you need two have the product SMPE installable, in my mind. Ed ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
