> On Dec 7, 2017, at 11:33 AM, Paul Gilmartin > <0000000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > I believe that even some IBM products nowadays are SMP/E-installable, but > with required post-installation procedures. Is this a symptom of inadequacy > of SMP/E? Gil:
I will chime in here. JAVA has been and always will be a PITA because of some numnuts decision at IBM that JAVA is a HUGE amount of modules that (imo but I could be wrong) are really independent on others. So when you see a fix for JAVA it is for all intents purpose a replacement for all the JAVA modules, since I don’t know the product I could be wrong, HOWEVER who ever made the decision to package everything into one big mod should be sent over to STK land to graze in other pastures. Besides the Nuc, the largest IBM module (not JAVA) is/was IEFW21SD and it has worked out well about separate mods. The NUC is the one exception and that has grown throughout the years MVS has been in existence. But again individual modules are invariably hit by one or more PTF’s and again that has worked out well. My prime suspect in JAVA is the OE people that have never heard of a standard they couldn’t violate, since the OE people got away with violating IBM stands why not JAVA as well. The item you mentioned about it having certain items handled differently, is a hard call. Pretty much (AFAIK) they are the only ones to violate IBM’s methodology. I wish that these “special” items have been through an IBM specifications drill and really should never again have seen the light of day. I suspect and cannot prove that some of these silly items were because of the 100 byte parmlist limitations and if that was the reason there are other legit ways to have a list of constants GT 100 bytes. I can only hope that IBM goes back and fixes these oddities as I call them. Back before the SMPE rules quite a few products were packaged rather stupidly. But those were the days when DASD was expensive, so there is some forgiveness there although not much. When we first started to go TSO (years ago) each product that was used in TSO had their own command processor, i.e. ASM, COBOL, FORTRAN etc etc… and each one had to have defaults that were customized to each installation. And on top of it there was a monthly charge for it. My memory (iff here) it was $90 for asm and 120 for Cobol. The only two products that really needed special handling was COBTEST and FORTEST. Ed > > And I wonder why updates to the timezone database (Olson) used by Java > require an idiosyncratic administrative procecure rather than appearing as > PTFs in routine maintenance stream? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
