I should know better than to respond to one of your posts... but I already did. This will be my last response to you on this subject. Sometimes I find it hard to believe you were actually a sysprog.
On Mon, 14 Jan 2008 23:23:37 -0600, Ed Gould <[EMAIL PROTECTED]> wrote: > >Mark, I dislike to disagree with you but here is just (one) of the >time consuming issues I have run into with accepting PTFS. Maybe its >time to go PDSE with them (as much as I dislike it). But more often >than not (especially with product) that the dlib needs to have more >directory blocks than it has. You must manually increase them and >then restart the accept. Eh? Unless the apply has added elements there should be no reason to increase directory blocks. That does happen (more so in the past), but there is usually holddata to let you know the space requirement changes (at least there should be). If you read the holddata for APPLY (which is critical), then you can increase the dlib space / dir at that point. At least that is what I do. Either way... it's still a poor excuse not to run ACCEPT. >You also *MUST* look at the listing for >every little non zero return code. Some times 4 is OK and sometimes >its not . In any case it is time consuming. The last thing that I run >into quite a bit is any assemblies that are done must be triple >checked to make sure the correct macro's are picked up. I sort of >wish SMPe would use an alternate set for syslib for accepts. >> You do have to look at output. I guess that does mean doing some of that four letter word that starts with "W". But honestly, I can't remember the last time I ran into an RC4 not being ok on ACCEPT. How would the macros get picked up? Unless you have you SYSLIB concatenation wrong. Assemblies can happen during accept.. but most products / maintenance is not packaged that way these days. >>> 2. The proverbial it worked last year before you put the maintenance >>> on just go back the point and run my job. >> >> ?? Accept doesn't affect the running system / tgt libs. > >I guess I didn't put it distinctly enough. I know it does NOT affect >TGT libraries. But I was trying to say (and apparently >unsuccessfully) it does not work on the CURRENT system. In order to >make it work the manager tells you you *MUST* back off the apply (for >the modules not all) it can get dicey telling a manager that you >can't go back because a fix has been accepted, especially if the job >is extremely important. If you start talking about a separate LPAR >etc they go through the roof what they want is results not excuses >and trying to tell them it can't be done is like nailing a coffin >shut and your inside it. Managers don't like "no" and no amount of >excuse(s) is/are acceptable. The PC world can get away with it we >can't and don't you dare even bring up the PC world issue either >(they are gods gift to corporations). > > Which is why you don't ACCEPT until after you have been running on the current set (or copy of) target libraries for some period of time. That period of time depends on the product, shop, personal preference as to when you feel "comfortable" or just prior to the next APPLY run. The point is... you should do it!! I guess some of those sysprogs I mentioned in my last post that live by "don't ever accept" learned it from you. BTW, there is such a thing as backups. If you back up your target libs (or copies) even if you don't have an SMP/E environment to RESTORE a PTF that causes you grief, you can still restore a backup copy of the library. Also, for "MVS", I often clone the DLIB zone along with the target zone but admit I haven't done that at this shop (5 years now) but haven't run into a problem because of that either. For other products (ISV) there are usually installation standards that have the install set of libraries all under 1 or 2 HLQs (some shops use a different HLQ for the SMP/E related data sets from the TGT/DLIBs). I always run a backup to tape by HLQ prior to maintenance cycles. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html ---------------------------------------------------------------------- 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
