-----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Marchant Sent: Tuesday, August 08, 2006 11:42 AM To: [email protected] Subject: Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On Tue, 8 Aug 2006 10:03:24 -0400, Thompson, Steve (SCI TW) <[EMAIL PROTECTED]> wrote: > >And then the idea that ISVs don't know SMP/E is a bit out there -- well >I'd hope that ISVs know SMP/E. I'd hope so too, but some vendors consistently do it wrong. Some examples: Providing PTFs without proper PREs Providing PTFs that don't SUP when they should Routinely asking a customer to use BYPASS ID PTF A has a PRE on FMID B, but FMID B has a SUP on PTF A Failure to provide UCLIN to create DDDEFs I'm sure others will chime in with their pet peeve of the day. <snip> You have a point there. If they actually don't have SMP/E knowledgeable people. But sometimes the internal system that is used to generate APAR/PTFs gets screwed. And it takes a while to fix it. It even happened at IBM. But I have experienced this with some small ISVs where it takes them a while to get it all together. <snip> >But the reason for autocurst was to allow >the customer to immediately install AutoOPERATOR and then install the >SMP/E stuff later (basically the system came "pre-installed" you loaded >the SMP/E files/system later so you could put on maint). So I get a product that may match what SMP/E has. No, thanks. A properly built SMP/E install doesn't take much longer than just unloading data sets and then I *know* that they are in sync. The total amount of work is typically less to set up the SMP/E environment properly and then install. <snip> Ok, let's try this again. You get two tapes. First tape is an IEBCOPY install so that you can get the product up and running NOW. The second (which is overflow from the first actually) is ALL the SMPE files (kind of a snapshot of the system that was used to produce these tapes). This means that you have a RUNNING system that MATCHES the SMP/E files (including the CSI). The first files unloaded were the TARGET files of the SMP/E system that you haven't yet unloaded from the tape. And when I say RUNNING, it was a copy of an installed system where the install had been started and run (as part of the QA process). And, BTW, Boole & Babbage didn't exactly dream that one up. I believe that actually came from a user group meeting where it was requested. It allowed a new install to be done immediately -- some customers apparently decided that they would re-order the product and use this method to install thereby offloading ALL the SMP/E work to Boole & Babbage. Of course, best laid plans of mice and men and all that, there would eventually be a HiPER... <snip> > >So there are lots of things that vendors have to take into >consideration, and the biggest one today are the Sr. Systems Programmers >who don't know what a USERMOD is or a JES exit. > Now there's a statement that I think is "a bit out there." <snip> You should take some of the calls I have had to handle. Or wind up doing sysprog contract work (I have off and on for the past 7 years). You would be astonished at how depleted of skills some shops are after their management decided that the mainframe is dead. So people with 3 years experience are suddenly a Sr. Systems Programmer. A few of those shops that tried to kill their mainframe I've had the last laugh as I watched a CEO and a CIO get shown the door while the BOD was scrambling to re-hire the old mainframers (one of those companies was involved in bringing you the NE Blackout a few years ago). Later, Steve Thompson <snip> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
