Re: Error apply ZAP
it was in this case far less writing to fix the bug in the code than it would have been to document the intricacies of the misbehavior I have a design mantra that is a corollary to what I wrote earlier: it's easier to code to good documentation than it is to document bad code. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, January 09, 2012 4:16 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Error apply ZAP On Mon, 9 Jan 2012 15:32:26 -0800, Charles Mills wrote: The resource spent on adding emphasis to the description of a deficiency would better have been used to repair it. LOL. Ain't it the truth! Every software team should have that on a plaque on the wall. I don't always do it, but I am happiest when I do: write the user documentation BEFORE you write the product. Then when you find yourself devoting three tedious paragraphs to explaining how something works, you have a chance to say to yourself Hmm. Maybe it shouldn't work that way. I once had a user (in-house), steeped in the MVS culture, come to me and complain that one of my programs was not operating as documented. He requested that I change the documentation (as he would have expected of IBM). I looked at it. The documentation expressed the intent of my design; the implementation was in error. I fixed the latter, and damned the impact on compatibility to users who had adapted to the misbehavior. And besides, it was in this case far less writing to fix the bug in the code than it would have been to document the intricacies of the misbehavior. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
Maybe I should quit butting in here, but these comments touch a nerve. That is not what SMP/E does, is not a refutation of Robert's complaints and mine, but a confirmation that it fails to support needed function. When I had a bunch of programmers working for me I would sometimes have conversations like the following: Programmer: You don't understand; that's not how the program works. Me: I understand that's not how the program works; I'm asking you to change the program. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Tuesday, January 10, 2012 8:24 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Error apply ZAP ... Let me give an example. Suppose after I have APPLYed PTFs A, B, and C in sequence I detect a bug. I'd like to isolate the causing PTF. So I do what is necessary to RESTORE C and test again. The bug is still there. So I'd like to RESTORE B and test yet again. But I can't because in order to RESTORE C I had to ACCEPT B, and now it can't be RESTOREd. This is terrible; it's a deficiency in design. Your assertion, That is not what SMP/E does, is not a refutation of Robert's complaints and mine, but a confirmation that it fails to support needed function. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills The resource spent on adding emphasis to the description of a deficiency would better have been used to repair it. LOL. Ain't it the truth! Every software team should have that on a plaque on the wall. I don't always do it, but I am happiest when I do: write the user documentation BEFORE you write the product. Then when you find yourself devoting three tedious paragraphs to explaining how something works, you have a chance to say to yourself Hmm. Maybe it shouldn't work that way. I'd be happy to second your nomination for a Nobel Prize in clear thinking, if there were such a prize. :-) -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
On Tue, 10 Jan 2012 00:11:52 -0500, Robert A. Rosenberg wrote: PTF1 with Elements A and B and PTF2 that PREs PTF1 which replaces PTF1's Element A. If you RESTORE PTF1 you must also have SMPE RESTORE PTF2 since you need to all back to the version of Element A that PTF1 replaced. I do not remember if this addition of a PTF that PRE'ed the PTF being RESTORE'd will be automatic or not It will if you specify GROUP. My issue is with the reverse case where you are RESTORE'ing PTF2. Right now this will ALSO restore PTF1 (and thus back out Element B from PTF1) and possibly other PTFs that PTF1 PREs. You can restore PTF2 if PTF1 has been ACCEPTed. If PTF1 has not been accepted, you have to RESTORE PTF1 too. SMP/E will not do it for you. To back out PTF2 ALL that is needed is to select Element A from PTF1 and ignore PTF1's Element B (since B is at PTF1 level even after PTF2 is APPLY'ed and thus there is no need to remove it to remove the PTF2 level of Element A). RESTORE does not take elements from PTFs. It takes them from the DLIB zone. The way it works currently, RESTORE'ing PTF2, RESTOREs PTF1 which triggers getting A and B from whoever PTF1 PRE'ed (who owned A and B before PTF1 was APPLY'ed). If that PTF contained any element other than A and B, IT gets added to the list of PTFs that will get RESTORE'ed SMP/E does not add prerequisites to the RESTORE group. This backtracking continues until you find a set of PTFs in the PRE/SUP chain that contains all the Elements (and only them) that is being backed out - These copies of the elements are what are used. Wrong again. There is no requirement that the elements that are replaced during RESTORE come from a PTF that contains exactly the same elements that are in the PTF being RESTOREd. Evidently you have not performed RESTORE processing recently. I have. Yesterday, in fact. It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so. - Mark Twain -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
On Tue, 10 Jan 2012 07:12:21 -0600, Tom Marchant wrote: On Tue, 10 Jan 2012 00:11:52 -0500, Robert A. Rosenberg wrote: To back out PTF2 ALL that is needed is to select Element A from PTF1 and ignore PTF1's Element B (since B is at PTF1 level even after PTF2 is APPLY'ed and thus there is no need to remove it to remove the PTF2 level of Element A). RESTORE does not take elements from PTFs. It takes them from the DLIB zone. That's exactly what Robert and I perceive as a deficiency in design. This backtracking continues until you find a set of PTFs in the PRE/SUP chain that contains all the Elements (and only them) that is being backed out - These copies of the elements are what are used. Wrong again. There is no requirement that the elements that are replaced during RESTORE come from a PTF that contains exactly the same elements that are in the PTF being RESTOREd. Read again. He didn't say a PTF; he said a set of PTFs. Evidently you have not performed RESTORE processing recently. I have. Yesterday, in fact. Got me there; for me it's been two days. His understanding is better than you credit him for; merely he doesn't accept IBM's unfriendly design as divinely ordained. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
On Tue, 10 Jan 2012 08:23:05 -0600, Paul Gilmartin wrote: On Tue, 10 Jan 2012 07:12:21 -0600, Tom Marchant wrote: On Tue, 10 Jan 2012 00:11:52 -0500, Robert A. Rosenberg wrote: This backtracking continues until you find a set of PTFs in the PRE/SUP chain that contains all the Elements (and only them) that is being backed out - These copies of the elements are what are used. There is no requirement that the elements that are replaced during RESTORE come from a PTF that contains exactly the same elements that are in the PTF being RESTOREd. Read again. He didn't say a PTF; he said a set of PTFs. Ok. He said a set of PTFs in the PRE/SUP chain that contains all the Elements (and only them). That is not what SMP/E does. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
On Tue, 10 Jan 2012 09:05:05 -0600, Tom Marchant wrote: On Tue, 10 Jan 2012 08:23:05 -0600, Paul Gilmartin wrote: On Tue, 10 Jan 2012 07:12:21 -0600, Tom Marchant wrote: On Tue, 10 Jan 2012 00:11:52 -0500, Robert A. Rosenberg wrote: This backtracking continues until you find a set of PTFs in the PRE/SUP chain that contains all the Elements (and only them) that is being backed out - These copies of the elements are what are used. There is no requirement that the elements that are replaced during RESTORE come from a PTF that contains exactly the same elements that are in the PTF being RESTOREd. Read again. He didn't say a PTF; he said a set of PTFs. Ok. He said a set of PTFs in the PRE/SUP chain that contains all the Elements (and only them). That is not what SMP/E does. He was elliptical as well as ungrammatical (there's no plausible antecedent for the pronoun that). I take at least the latter as an indication that he was struggling to express what he had correctly observed. Let me give an example. Suppose after I have APPLYed PTFs A, B, and C in sequence I detect a bug. I'd like to isolate the causing PTF. So I do what is necessary to RESTORE C and test again. The bug is still there. So I'd like to RESTORE B and test yet again. But I can't because in order to RESTORE C I had to ACCEPT B, and now it can't be RESTOREd. This is terrible; it's a deficiency in design. Your assertion, That is not what SMP/E does, is not a refutation of Robert's complaints and mine, but a confirmation that it fails to support needed function. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
On Tue, 10 Jan 2012 10:23:37 -0600, Paul Gilmartin wrote: Let me give an example. Suppose after I have APPLYed PTFs A, B, and C in sequence I detect a bug. I'd like to isolate the causing PTF. So I do what is necessary to RESTORE C and test again. The bug is still there. So I'd like to RESTORE B and test yet again. But I can't because in order to RESTORE C I had to ACCEPT B, and now it can't be RESTOREd. This is terrible; it's a deficiency in design. You didn't have to ACCEPT B or A. Indeed, in the example that you gave, it would be foolish to ACCEPT A or B. What you should have done in that instance, assuming that A, B and C all modified some of the same elements, is to RESTORE A, B and C, then apply A and B. Your assertion, That is not what SMP/E does, is not a refutation of Robert's complaints and mine, but a confirmation that it fails to support needed function. I made no comments about your or Mr. Rosenberg's complaints about the design of SMP/E. My comments were about his incorrect description of what SMP/E does during RESTORE processing. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
On Tue, 10 Jan 2012 12:37:42 -0600, Tom Marchant wrote: Let me give an example. Suppose after I have APPLYed PTFs A, B, and C in sequence I detect a bug. I'd like to isolate the causing PTF. So I do what is necessary to RESTORE C and test again. The bug is still there. So I'd like to RESTORE B and test yet again. But I can't because in order to RESTORE C I had to ACCEPT B, and now it can't be RESTOREd. This is terrible; it's a deficiency in design. You didn't have to ACCEPT B or A. Indeed, in the example that you gave, it would be foolish to ACCEPT A or B. What you should have done in that instance, assuming that A, B and C all modified some of the same elements, is to RESTORE A, B and C, then apply A and B. I would be ecstatic if I could tell SMP/E in a single brief command to do whatever is necessary to eliminate C but leave A and B in the status quo ante. And, by the way, optimize the aggregate operation so load modules affected by A or B but not by C were not relinked. If this were possible, I'd ACCEPT only the base FUNCTION and roll back to any service level I desired. And, by the way, it should be possible even if C has ++DELETE. Why not? Because the SMP/E Reference says you can't is not a satisfactory answer. Look; I could create a new target zone, and from the existing GLOBAL zone, assuming no required PTFs had been purged, install into that new target zone all the PTFs through A and B, omitting C: SET BOUNDARY (NEWTZON) . APPLY PTFS EXCLUDE( C ) . SMP/E has all the required data and metadata; it just stubbornly refuses to do it in the original zone. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
I believe it replaces the existing IDR record with a empty one snip If you relink as the AMA120I suggests/instructs the Binder adds another (empty) IDR record so you can use the IDENTIFY statement (think this is automatic although it may be triggered by supplying a Binder command to add more IDR Space). As you note, this allows you to track what ZAPs have been installed. If I remember IDR is ID Record. There are IDR records for each CSECT in the Load Module (they come from the Assembler) so you can see what the assembly date of the CSECT is (there is only one for the last linkedit). /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin [ snip ] It's a major design shortcoming that one can't REDO a ZAP. It would be so easy -- if PARM=REDO and the content of the module matches the REP, assume it's OK. And SMP/E should supply the REDO parm to AMASPZAP for APPLY REDO. (There should also be a PARM=UNDO.) How does RESTORE not accomplish an UNDO, aside from not recovering the victim(s) of a ++DELETE command? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
On Mon, 9 Jan 2012 10:01:43 -0600, Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin [ snip ] It's a major design shortcoming that one can't REDO a ZAP. It would be so easy -- if PARM=REDO and the content of the module matches the REP, assume it's OK. And SMP/E should supply the REDO parm to AMASPZAP for APPLY REDO. (There should also be a PARM=UNDO.) How does RESTORE not accomplish an UNDO, aside from not recovering the victim(s) of a ++DELETE command? In our development, we often do APPLY REDO (this is extraordinary in end customer environments; we never require it). REDO is incompatible with ++ZAP, even if the ZAP itself is unchanged. We rarely do ZAPs; we've learned our lesson. In the past, we've dealt with a vendor not using SMP/E who distributed service as reversible ZAPs with a proprietary zap utility which could zap not only load modules but also SYSPUNCH-format objects. I wonder why ++DELETE precludes RESTORE? It should be straightforward to rebuild program objects from parts in the DLIBs. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
I think that you answered your own question. aside from not recovering the victim(s) of a ++DELETE command? I could never understand why that is the case. RESTORE should restore everything. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chase, John Sent: Monday, January 09, 2012 11:02 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Error apply ZAP -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin [ snip ] It's a major design shortcoming that one can't REDO a ZAP. It would be so easy -- if PARM=REDO and the content of the module matches the REP, assume it's OK. And SMP/E should supply the REDO parm to AMASPZAP for APPLY REDO. (There should also be a PARM=UNDO.) How does RESTORE not accomplish an UNDO, aside from not recovering the victim(s) of a ++DELETE command? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
On Mon, 9 Jan 2012 11:54:45 -0500, Veilleux, Jon L wrote: I think that you answered your own question. aside from not recovering the victim(s) of a ++DELETE command? I could never understand why that is the case. RESTORE should restore everything. Yup. There's another one that's about as bad. When link edit JCLIN adds an INCLUDE statement, the load module is not necessarily relinked to add the MOD element mentioned. I know; this behavior is documented fully, even tediously. That doesn't alter the fact that the design is wrong. The resource spent on adding emphasis to the description of a deficiency would better have been used to repair it. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin [ snip ] I wonder why ++DELETE precludes RESTORE? It should be straightforward to rebuild program objects from parts in the DLIBs. I think ++DELETE also purges any meta-data associated with the deleted object(s). I.e., all that's left are the original parts; no instructions on how to assemble them into the desired object. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
RES: Error apply ZAP
All list, The Zaps already been applied. I came in contact with the support of the company and gave him some tips. Helio Jose Da Silva Esta mensagem pode conter informações confidenciais e/ou privilegiadas. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem, não pode usar, copiar ou divulgar as informações nela contidas ou tomar qualquer ação baseada nessas informações. Se você recebeu esta mensagem por engano, por favor, avise imediatamente o remetente, respondendo o e-mail, e em seguida apague-o. Agradecemos sua cooperação. This message may contain confidential and/or privileged information. If you are not the address or authorized to receive this for the address, you must not use, copy, disclose or take any action base on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation -Mensagem original- De: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] Em nome de Chase, John Enviada em: segunda-feira, 9 de janeiro de 2012 16:37 Para: IBM-MAIN@bama.ua.edu Assunto: Re: Error apply ZAP -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin [ snip ] I wonder why ++DELETE precludes RESTORE? It should be straightforward to rebuild program objects from parts in the DLIBs. I think ++DELETE also purges any meta-data associated with the deleted object(s). I.e., all that's left are the original parts; no instructions on how to assemble them into the desired object. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
In f255efe0ecf08c4a9c1db6aff4235417181f2...@ch2wpmail1.na.ds.ussco.com, on 01/09/2012 at 10:01 AM, Chase, John jch...@ussco.com said: How does RESTORE not accomplish an UNDO, The OP is talking about AMASPZAP, not SMP. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
On Mon, 9 Jan 2012 12:37:21 -0600, Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin [ snip ] I wonder why ++DELETE precludes RESTORE? It should be straightforward to rebuild program objects from parts in the DLIBs. I think ++DELETE also purges any meta-data associated with the deleted object(s). I.e., all that's left are the original parts; no instructions on how to assemble them into the desired object. Which is plainly a misdesign. ++DELETE should remove the load module and its meta-data from the target zone but leave in the distribution zone at least sufficient meta-data to rebuild the load module. Then to RESTORE the PTF to the ACCEPTed level would reinstate the load module. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
At 11:53 -0600 on 01/09/2012, Paul Gilmartin wrote about Re: Error apply ZAP: On Mon, 9 Jan 2012 11:54:45 -0500, Veilleux, Jon L wrote: I think that you answered your own question. aside from not recovering the victim(s) of a ++DELETE command? I could never understand why that is the case. RESTORE should restore everything. Yup. There's another one that's about as bad. When link edit JCLIN adds an INCLUDE statement, the load module is not necessarily relinked to add the MOD element mentioned. I know; this behavior is documented fully, even tediously. That doesn't alter the fact that the design is wrong. The resource spent on adding emphasis to the description of a deficiency would better have been used to repair it. -- gil RESTORE itself is BAD (Broken As Designed) since it removes SYSMODs that are not the SYSMOD being designated as being RESTORED. Instead of using ONLY the elements that are in the SYSMOD being RESTOREd (by using the copies that this SYSMOD replaced) it can remove additional SYSMODs (requiring a follow-up APPLY of the erroneously removed SYSMODs). After a RESTORE, I should be in the same state as I would be if I had not APPLY'ed the SYSMOD in the first place. Instead I can end up with other SYSMODs removed since the elements that were replaced by the SYSMOD were in another SYSMOD along with other elements NOT in the SYSMOD being RESTOREd. A RESTORE should be an APPLY of ONLY the elements that are in that SYSMOD even though there were other elements in the SYSMOD you are getting them from. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
The resource spent on adding emphasis to the description of a deficiency would better have been used to repair it. LOL. Ain't it the truth! Every software team should have that on a plaque on the wall. I don't always do it, but I am happiest when I do: write the user documentation BEFORE you write the product. Then when you find yourself devoting three tedious paragraphs to explaining how something works, you have a chance to say to yourself Hmm. Maybe it shouldn't work that way. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Robert A. Rosenberg Sent: Monday, January 09, 2012 1:51 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Error apply ZAP At 11:53 -0600 on 01/09/2012, Paul Gilmartin wrote about Re: Error apply ZAP: On Mon, 9 Jan 2012 11:54:45 -0500, Veilleux, Jon L wrote: I think that you answered your own question. aside from not recovering the victim(s) of a ++DELETE command? I could never understand why that is the case. RESTORE should restore everything. Yup. There's another one that's about as bad. When link edit JCLIN adds an INCLUDE statement, the load module is not necessarily relinked to add the MOD element mentioned. I know; this behavior is documented fully, even tediously. That doesn't alter the fact that the design is wrong. The resource spent on adding emphasis to the description of a deficiency would better have been used to repair it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
On Mon, 9 Jan 2012 16:51:06 -0500, Robert A. Rosenberg wrote: On Mon, 9 Jan 2012 11:54:45 -0500, Veilleux, Jon L wrote: I think that you answered your own question. aside from not recovering the victim(s) of a ++DELETE command? I could never understand why that is the case. RESTORE should restore everything. RESTORE itself is BAD (Broken As Designed) since it removes SYSMODs that are not the SYSMOD being designated as being RESTORED. Instead of using ONLY the elements that are in the SYSMOD being RESTOREd (by using the copies that this SYSMOD replaced) it can remove additional SYSMODs (requiring a follow-up APPLY of the erroneously removed SYSMODs). After a RESTORE, I should be in the same state as I would be if I had not APPLY'ed the SYSMOD in the first place. Instead I can end up with other SYSMODs removed since the elements that were replaced by the SYSMOD were in another SYSMOD along with other elements NOT in the SYSMOD being RESTOREd. A RESTORE should be an APPLY of ONLY the elements that are in that SYSMOD even though there were other elements in the SYSMOD you are getting them from. And here, I half strongly disagree with SMP/E; half agree. If the PTF being RESTOREd is a PRErequisite of subsequent APPLYed PTFs, it's a logical necessity that those should be RESTOREd also. (I don't know that this is automated.) ACCEPT is a kludge. I use VMFMERGE on CMS. It has no operation analogous to ACCEPT and no repository analogous to the distribution zone. The programmer may RESTORE any consistent collection of PTFs. VMFMERGE gets any needed elements from the DELTA directory, its equivalent of the GLOBAL zone. There's no firewall limiting you to RESTORE exactly to that point and never beyond. I consider it a far superior and more usable design. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
On Mon, 9 Jan 2012 15:32:26 -0800, Charles Mills wrote: The resource spent on adding emphasis to the description of a deficiency would better have been used to repair it. LOL. Ain't it the truth! Every software team should have that on a plaque on the wall. I don't always do it, but I am happiest when I do: write the user documentation BEFORE you write the product. Then when you find yourself devoting three tedious paragraphs to explaining how something works, you have a chance to say to yourself Hmm. Maybe it shouldn't work that way. I once had a user (in-house), steeped in the MVS culture, come to me and complain that one of my programs was not operating as documented. He requested that I change the documentation (as he would have expected of IBM). I looked at it. The documentation expressed the intent of my design; the implementation was in error. I fixed the latter, and damned the impact on compatibility to users who had adapted to the misbehavior. And besides, it was in this case far less writing to fix the bug in the code than it would have been to document the intricacies of the misbehavior. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
At 18:26 -0600 on 01/09/2012, Paul Gilmartin wrote about Re: Error apply ZAP: RESTORE itself is BAD (Broken As Designed) since it removes SYSMODs that are not the SYSMOD being designated as being RESTORED. Instead of using ONLY the elements that are in the SYSMOD being RESTOREd (by using the copies that this SYSMOD replaced) it can remove additional SYSMODs (requiring a follow-up APPLY of the erroneously removed SYSMODs). After a RESTORE, I should be in the same state as I would be if I had not APPLY'ed the SYSMOD in the first place. Instead I can end up with other SYSMODs removed since the elements that were replaced by the SYSMOD were in another SYSMOD along with other elements NOT in the SYSMOD being RESTOREd. A RESTORE should be an APPLY of ONLY the elements that are in that SYSMOD even though there were other elements in the SYSMOD you are getting them from. And here, I half strongly disagree with SMP/E; half agree. If the PTF being RESTOREd is a PRErequisite of subsequent APPLYed PTFs, it's a logical necessity that those should be RESTOREd also. (I don't know that this is automated.) In your case you have PTF1 with Elements A and B and PTF2 that PREs PTF1 which replaces PTF1's Element A. If you RESTORE PTF1 you must also have SMPE RESTORE PTF2 since you need to all back to the version of Element A that PTF1 replaced. I do not remember if this addition of a PTF that PRE'ed the PTF being RESTORE'd will be automatic or not My issue is with the reverse case where you are RESTORE'ing PTF2. Right now this will ALSO restore PTF1 (and thus back out Element B from PTF1) and possibly other PTFs that PTF1 PREs. To back out PTF2 ALL that is needed is to select Element A from PTF1 and ignore PTF1's Element B (since B is at PTF1 level even after PTF2 is APPLY'ed and thus there is no need to remove it to remove the PTF2 level of Element A). The way it works currently, RESTORE'ing PTF2, RESTOREs PTF1 which triggers getting A and B from whoever PTF1 PRE'ed (who owned A and B before PTF1 was APPLY'ed). If that PTF contained any element other than A and B, IT gets added to the list of PTFs that will get RESTORE'ed. This backtracking continues until you find a set of PTFs in the PRE/SUP chain that contains all the Elements (and only them) that is being backed out - These copies of the elements are what are used. EVEN WORSE -The only elements that are eligible to be used are from ACCEPT'ed PTFs not these that are only in APPLY status. RESTORE thus removes good PTFs in APPLY status since it removes all PTFs that replaced the ACCEPT'ed levels of the elements being backed out. Thus if PTF1 SUP'ed PTF0 (which only contained A and B), PTF0 would be added to the list to be restored unless it was already in ACCEPT status. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
Gerhard: I honestly don't remember ever having the issue with IBM module(s). I memory goes back to early MVS 2.0 and if we did have an issue it was because TMS or some other vendor code hit the same module (open). In the case of TMS it wasn't their fault so much as IBM didn't give exits at the right points . I am not defending TMS but they just happened to need the hooks in a popular spot. Although I do not like how CA (ie TMS) and other products now put zaps in on the fly (so to speak). I have been burned once or twice with on the fly zaps as IBM quickly found the finger prints and tossed me off the boat and I had to got to CA support begging because IBM washed their hands of the issue once or twice. CA (this does go back a few years) wanted to toss me back to IBM. I had to supply a bunch of trace and dumps before CA would listen to me again but even then I felt CA was trying to avoid the problem rather than working with IBM the customer to resolve the problem. The problem did get resolved but it took days (or was it a week?) to get the problem resolved. The biggest PITA was ACF2 (never a fan) and the way they handled problems with TSO Allocation. Of course the ACF2 person on our side was well lets say less than average. I had to get involved before the issue was resolved and I had to pound some manager at ACF2 to get them to listen. We got rid of ACF2 and never had an issue with security after that. Ed On Jan 7, 2012, at 4:15 PM, Gerhard Postpischil wrote: On 1/7/2012 2:31 PM, Ed Gould wrote: constant zap issue. I can't remember of ever having the issue with IBM as they send out module replacement (thanks!) I feel its important to maintain the IDR to find out what level the module is at. With the vendor I spoke of it was somewhat of an issue at times. That is why I am a strong supporter of module replacement and zaps are for emergency fixes only. I've had the issue with IBM modules a long, long time ago. Assuming ZAPs are sequential, I prefer putting an identifier, APAR or whatever, into the eyeball text at the beginning of the module. That way I can see in a dump how it's been updated, rather than having to run a report. Module replacements take more effort and disk space, so ZAPs are closer to being green g Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
Seymour: I didn't say anything about the IDR space (and indeed I relinked a few modules) to get the zap on. It was difficult with quantity of the zaps. I hated to get the mail opened daily as the number of envelopes with zaps was scary at times. One ugly day I had 5 envelopes with 5 separate zaps in each envelope. I had enough work without having to deal with the paperwork that went along with each. One nice thing I will admit very rarely did zaps go against multiple modules. Ed On Jan 7, 2012, at 7:17 PM, Robert A. Rosenberg wrote: At 13:31 -0600 on 01/07/2012, Ed Gould wrote about Re: Error apply ZAP: Robert: I used to have a vendor that would send out zaps almost weekly and IDR space was at a premium on the vendors modules. We dropped the vendor so I don't know how they did resolve the constant zap issue. I can't remember of ever having the issue with IBM as they send out module replacement (thanks!) I feel its important to maintain the IDR to find out what level the module is at. With the vendor I spoke of it was somewhat of an issue at times. That is why I am a strong supporter of module replacement and zaps are for emergency fixes only. As I noted, and someone here confirmed, doing a relink adds extra IDR room (if the current IDR Record is full). IOW: The AMA120I message by suggesting the relink would add another IDR record with room for another 19 IDENTIFY commands. The IDR record is on a per- loadmodule basis and thus is shared by all the CSECTs in the Load Module. In the case of your vendor, so long as the ZAPs came with IDENTIFY commands and you did not supply the PARM override, every 19 ZAPs (~5 months) a relink would be needed to add another IDR record to be used. Ed On Jan 6, 2012, at 11:54 PM, Robert A. Rosenberg wrote: At 14:29 -0600 on 01/06/2012, Staller, Allan wrote about Re: Error apply ZAP: First the IDR (forget what the acronym stands for) is an optional list of zaps applied to this module (load module?). Due to the structure of the directory, IIRC, you are limited to 19 IDR entries per module (load module?). The IDR data is set by an AMASPZAP control statement. IDENTIFY. The message AMA120I message below may be safely ignored. It is indicated that there is no space left to record additional IDR information. The only impact of this is that it will make it difficult to determine which zaps have already been applied. If you relink as the AMA120I suggests/instructs the Binder adds another (empty) IDR record so you can use the IDENTIFY statement (think this is automatic although it may be triggered by supplying a Binder command to add more IDR Space). As you note, this allows you to track what ZAPs have been installed. If I remember IDR is ID Record. There are IDR records for each CSECT in the Load Module (they come from the Assembler) so you can see what the assembly date of the CSECT is (there is only one for the last linkedit). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Shmuel Metz (Seymour J.) In f255efe0ecf08c4a9c1db6aff4235417181f2...@ch2wpmail1.na.ds.ussco.com, on 01/09/2012 at 10:01 AM, Chase, John jch...@ussco.com said: How does RESTORE not accomplish an UNDO, The OP is talking about AMASPZAP, not SMP. Context is everything. Try re-reading my reply (to Paul Gilmartin's lament) that you apparently cite, to which your reply seems to refer. Tourist Information: AMASPZAP can be invoked by GIMSMP. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
Robert: I used to have a vendor that would send out zaps almost weekly and IDR space was at a premium on the vendors modules. We dropped the vendor so I don't know how they did resolve the constant zap issue. I can't remember of ever having the issue with IBM as they send out module replacement (thanks!) I feel its important to maintain the IDR to find out what level the module is at. With the vendor I spoke of it was somewhat of an issue at times. That is why I am a strong supporter of module replacement and zaps are for emergency fixes only. Ed On Jan 6, 2012, at 11:54 PM, Robert A. Rosenberg wrote: At 14:29 -0600 on 01/06/2012, Staller, Allan wrote about Re: Error apply ZAP: First the IDR (forget what the acronym stands for) is an optional list of zaps applied to this module (load module?). Due to the structure of the directory, IIRC, you are limited to 19 IDR entries per module (load module?). The IDR data is set by an AMASPZAP control statement. IDENTIFY. The message AMA120I message below may be safely ignored. It is indicated that there is no space left to record additional IDR information. The only impact of this is that it will make it difficult to determine which zaps have already been applied. If you relink as the AMA120I suggests/instructs the Binder adds another (empty) IDR record so you can use the IDENTIFY statement (think this is automatic although it may be triggered by supplying a Binder command to add more IDR Space). As you note, this allows you to track what ZAPs have been installed. If I remember IDR is ID Record. There are IDR records for each CSECT in the Load Module (they come from the Assembler) so you can see what the assembly date of the CSECT is (there is only one for the last linkedit). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
I seem to remember (20+ years ago?) that re-linkediting the load module would preserve the existing IDR entries and allow for another 19 (but I could be mistaken on this) Chris hoelscher Database Administrator |Technical Services Humana 123 East Main Street |Louisville, KY 40202 T 502.476.2538 choelsc...@humana.com Humana.com Keeping CAS and Metavance safe for all HUMANAty -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Gould Sent: Saturday, January 07, 2012 2:32 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Error apply ZAP Robert: I used to have a vendor that would send out zaps almost weekly and IDR space was at a premium on the vendors modules. We dropped the vendor so I don't know how they did resolve the constant zap issue. I can't remember of ever having the issue with IBM as they send out module replacement (thanks!) I feel its important to maintain the IDR to find out what level the module is at. With the vendor I spoke of it was somewhat of an issue at times. That is why I am a strong supporter of module replacement and zaps are for emergency fixes only. Ed The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
On 1/7/2012 2:31 PM, Ed Gould wrote: constant zap issue. I can't remember of ever having the issue with IBM as they send out module replacement (thanks!) I feel its important to maintain the IDR to find out what level the module is at. With the vendor I spoke of it was somewhat of an issue at times. That is why I am a strong supporter of module replacement and zaps are for emergency fixes only. I've had the issue with IBM modules a long, long time ago. Assuming ZAPs are sequential, I prefer putting an identifier, APAR or whatever, into the eyeball text at the beginning of the module. That way I can see in a dump how it's been updated, rather than having to run a report. Module replacements take more effort and disk space, so ZAPs are closer to being green g Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
In ec61ef1aa63c694b8a23a9e1350cca22cf2...@dr000s061.sfr.net, on 01/06/2012 at 08:00 PM, Helio Jose Da Silva helio.si...@rural.com.br said: How can I resolve this error? !. Relink 2. Contact the vendor There are two separate issues. The AMA120I message means that you won't have an audit trail unless you relink. The AMA104I message means that either the zap is inappropriate or you already ran it. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
On Fri, 6 Jan 2012 14:29:12 -0600, Staller, Allan wrote: The real problem is the AMA104I message - VERIFY REJECT. The most likely cause is that this zap has already been applied. Another possibility that a pre-requisite zap is missing. The fastest way to determine this is to take a copy SYSIN and delete the VER statements. Change the REP statements to VER and run the JCL. If this zap has already been applied, you should get a return code of zero. It's a major design shortcoming that one can't REDO a ZAP. It would be so easy -- if PARM=REDO and the content of the module matches the REP, assume it's OK. And SMP/E should supply the REDO parm to AMASPZAP for APPLY REDO. (There should also be a PARM=UNDO.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
-snip-- I seem to remember (20+ years ago?) that re-linkediting the load module would preserve the existing IDR entries and allow for another 19 (but I could be mistaken on this) unsnip You are correct, but that won't fix the verify reject that is the real problem. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
In 4bbf0d2ae8a42b43b88ff0033094ed124c34e...@simmbxwpg02s02.rsc.humad.com, on 01/07/2012 at 08:44 PM, Chris Hoelscher choelsc...@humana.com said: I seem to remember (20+ years ago?) that re-linkediting the load module would preserve the existing IDR entries and allow for another 19 (but I could be mistaken on this) You are not mistaken in general, although I don't recall whether 10 is the correct number. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
At 13:31 -0600 on 01/07/2012, Ed Gould wrote about Re: Error apply ZAP: Robert: I used to have a vendor that would send out zaps almost weekly and IDR space was at a premium on the vendors modules. We dropped the vendor so I don't know how they did resolve the constant zap issue. I can't remember of ever having the issue with IBM as they send out module replacement (thanks!) I feel its important to maintain the IDR to find out what level the module is at. With the vendor I spoke of it was somewhat of an issue at times. That is why I am a strong supporter of module replacement and zaps are for emergency fixes only. As I noted, and someone here confirmed, doing a relink adds extra IDR room (if the current IDR Record is full). IOW: The AMA120I message by suggesting the relink would add another IDR record with room for another 19 IDENTIFY commands. The IDR record is on a per-loadmodule basis and thus is shared by all the CSECTs in the Load Module. In the case of your vendor, so long as the ZAPs came with IDENTIFY commands and you did not supply the PARM override, every 19 ZAPs (~5 months) a relink would be needed to add another IDR record to be used. Ed On Jan 6, 2012, at 11:54 PM, Robert A. Rosenberg wrote: At 14:29 -0600 on 01/06/2012, Staller, Allan wrote about Re: Error apply ZAP: First the IDR (forget what the acronym stands for) is an optional list of zaps applied to this module (load module?). Due to the structure of the directory, IIRC, you are limited to 19 IDR entries per module (load module?). The IDR data is set by an AMASPZAP control statement. IDENTIFY. The message AMA120I message below may be safely ignored. It is indicated that there is no space left to record additional IDR information. The only impact of this is that it will make it difficult to determine which zaps have already been applied. If you relink as the AMA120I suggests/instructs the Binder adds another (empty) IDR record so you can use the IDENTIFY statement (think this is automatic although it may be triggered by supplying a Binder command to add more IDR Space). As you note, this allows you to track what ZAPs have been installed. If I remember IDR is ID Record. There are IDR records for each CSECT in the Load Module (they come from the Assembler) so you can see what the assembly date of the CSECT is (there is only one for the last linkedit). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Error apply ZAP
All list, I'm applying some zaps and getting the following error: NAME NATURAL NATRGUI AMA120I NATURAL NO IDR SPACE - RE-LINK AMA128I UPDATES ENABLED BY OVERRIDE PARM VER 14BE 47F0,B69C,94C2,94C4,94C6,94C8,94CA,94CC AMA104I VERIFY REJECT - SET NO GO SWITCH The JCL is //ZA0JZAP JOB F02000,'SUPPORT',CLASS=S,TIME=(0004,00), // MSGCLASS=X,MSGLEVEL=(1,1),NOTIFY=SYSUID //STEP01 EXEC PGM=AMASPZAP,REGION=8M,PARM=IGNIDRFULL //SYSPRINT DD SYSOUT=* //SYSLIB DD DSN=SAG.NAT426.LOAD,DISP=SHR //SYSINDD DSN=NATURAL.ZAPS(NA77047),DISP=SHR How can I resolve this error? Thank very much Helio Jose Da Silva -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
You have two things going on here. 1st - the AMA120I message which you can ignore because you specified PARM=IGNIDRFULL 2nd - the AMA104I message. It's telling you that the data starting at 14BE in the csect NATRGUI does not match the value you specified (47F0,B69C,94C2,94C4,94C6,94C8,94CA,94CC). You mis-keyed the data or something else has altered this location. If you got this ZAP from a vendor you'll need to contact them for advice. Alan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Helio Jose Da Silva Sent: Friday, January 06, 2012 14:00 To: IBM-MAIN@bama.ua.edu Subject: Error apply ZAP All list, I'm applying some zaps and getting the following error: NAME NATURAL NATRGUI AMA120I NATURAL NO IDR SPACE - RE-LINK AMA128I UPDATES ENABLED BY OVERRIDE PARM VER 14BE 47F0,B69C,94C2,94C4,94C6,94C8,94CA,94CC AMA104I VERIFY REJECT - SET NO GO SWITCH The JCL is //ZA0JZAP JOB F02000,'SUPPORT',CLASS=S,TIME=(0004,00), // MSGCLASS=X,MSGLEVEL=(1,1),NOTIFY=SYSUID //STEP01 EXEC PGM=AMASPZAP,REGION=8M,PARM=IGNIDRFULL //SYSPRINT DD SYSOUT=* //SYSLIB DD DSN=SAG.NAT426.LOAD,DISP=SHR //SYSINDD DSN=NATURAL.ZAPS(NA77047),DISP=SHR How can I resolve this error? Thank very much Helio Jose Da Silva -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
On 01/06/12 15:00, Helio Jose Da Silva wrote: All list, I'm applying some zaps and getting the following error: NAME NATURAL NATRGUI AMA120I NATURAL NO IDR SPACE - RE-LINK AMA128I UPDATES ENABLED BY OVERRIDE PARM VER 14BE 47F0,B69C,94C2,94C4,94C6,94C8,94CA,94CC AMA104I VERIFY REJECT - SET NO GO SWITCH The JCL is //ZA0JZAP JOB F02000,'SUPPORT',CLASS=S,TIME=(0004,00), // MSGCLASS=X,MSGLEVEL=(1,1),NOTIFY=SYSUID //STEP01 EXEC PGM=AMASPZAP,REGION=8M,PARM=IGNIDRFULL //SYSPRINT DD SYSOUT=* //SYSLIB DD DSN=SAG.NAT426.LOAD,DISP=SHR //SYSINDD DSN=NATURAL.ZAPS(NA77047),DISP=SHR How can I resolve this error? Thank very much Helio Jose Da Silva It depends. The message is telling you that the contents of the specified csect at the offset indicated on the VER statement doesn't match what you had on the VER statement. Take a look at the contents of the csect from the listing and see what's there. You might have an incorrect zap, or you're pointing to the wrong load module/csect, or many other possibilities. -- Mark Jacobs Time Customer Service Tampa, FL Don't be too sweet lest you be eaten up; don't be too bitter lest you be spewed out. Yiddish Proverb -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Helio Jose Da Silva Sent: Friday, January 06, 2012 2:00 PM To: IBM-MAIN@bama.ua.edu Subject: Error apply ZAP All list, I'm applying some zaps and getting the following error: NAME NATURAL NATRGUI AMA120I NATURAL NO IDR SPACE - RE-LINK AMA128I UPDATES ENABLED BY OVERRIDE PARM VER 14BE 47F0,B69C,94C2,94C4,94C6,94C8,94CA,94CC AMA104I VERIFY REJECT - SET NO GO SWITCH The JCL is //ZA0JZAP JOB F02000,'SUPPORT',CLASS=S,TIME=(0004,00), // MSGCLASS=X,MSGLEVEL=(1,1),NOTIFY=SYSUID //STEP01 EXEC PGM=AMASPZAP,REGION=8M,PARM=IGNIDRFULL //SYSPRINT DD SYSOUT=* //SYSLIB DD DSN=SAG.NAT426.LOAD,DISP=SHR //SYSINDD DSN=NATURAL.ZAPS(NA77047),DISP=SHR How can I resolve this error? Thank very much Helio Jose Da Silva The VER does not match. This is used to VERify that the module is at the correct level. When it fais, that means the ZAP is not correct for your version of the module. You'll need to get a new ZAP. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
First the IDR (forget what the acronym stands for) is an optional list of zaps applied to this module (load module?). Due to the structure of the directory, IIRC, you are limited to 19 IDR entries per module (load module?). The IDR data is set by an AMASPZAP control statement. IDENTIFY. The message AMA120I message below may be safely ignored. It is indicated that there is no space left to record additional IDR information. The only impact of this is that it will make it difficult to determine which zaps have already been applied. To relink: //step1 exec pgm=iewl,parm=(MUST MATCH CURRENT attributes for this LMOD) e.g. RENT REUS REFR AC= AMODE RMODE,.. . . standard lked jcl . //SYSLMODDD DSN=target load library, disp=shr //SYSIN DD * include SYSLMOD(target lmod) alias x(zero or more depending if there are any aliaii currently assigned, optional) alias x Name(target lmod(r) /* The real problem is the AMA104I message - VERIFY REJECT. The most likely cause is that this zap has already been applied. Another possibility that a pre-requisite zap is missing. The fastest way to determine this is to take a copy SYSIN and delete the VER statements. Change the REP statements to VER and run the JCL. If this zap has already been applied, you should get a return code of zero. By all means, if you cannot determine if a particular zap has been applied or not , contact your vendor for assistance, HTH, snip I'm applying some zaps and getting the following error: NAME NATURAL NATRGUI AMA120I NATURAL NO IDR SPACE - RE-LINK AMA128I UPDATES ENABLED BY OVERRIDE PARM VER 14BE 47F0,B69C,94C2,94C4,94C6,94C8,94CA,94CC AMA104I VERIFY REJECT - SET NO GO SWITCH The JCL is //ZA0JZAP JOB F02000,'SUPPORT',CLASS=S,TIME=(0004,00), // MSGCLASS=X,MSGLEVEL=(1,1),NOTIFY=SYSUID //STEP01 EXEC PGM=AMASPZAP,REGION=8M,PARM=IGNIDRFULL //SYSPRINT DD SYSOUT=* //SYSLIB DD DSN=SAG.NAT426.LOAD,DISP=SHR //SYSINDD DSN=NATURAL.ZAPS(NA77047),DISP=SHR /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
At 14:29 -0600 on 01/06/2012, Staller, Allan wrote about Re: Error apply ZAP: First the IDR (forget what the acronym stands for) is an optional list of zaps applied to this module (load module?). Due to the structure of the directory, IIRC, you are limited to 19 IDR entries per module (load module?). The IDR data is set by an AMASPZAP control statement. IDENTIFY. The message AMA120I message below may be safely ignored. It is indicated that there is no space left to record additional IDR information. The only impact of this is that it will make it difficult to determine which zaps have already been applied. If you relink as the AMA120I suggests/instructs the Binder adds another (empty) IDR record so you can use the IDENTIFY statement (think this is automatic although it may be triggered by supplying a Binder command to add more IDR Space). As you note, this allows you to track what ZAPs have been installed. If I remember IDR is ID Record. There are IDR records for each CSECT in the Load Module (they come from the Assembler) so you can see what the assembly date of the CSECT is (there is only one for the last linkedit). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
