Re: GIM38201E and GIM31901I
I only bet on sure things. It could be a packaging error, a prior user error or (unlikely) an error in SMP/E. In all of those cases, however, it's best to consult with the vendors before doing anything that might mess things up more. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jesse 1 Robinson Sent: Monday, August 26, 2019 5:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GIM38201E and GIM31901I I really don't think this is a packaging error; as noted by Tom Conley, those are exceedingly rare. If one occurs, there should be a lightning quick HOLD record that would show up in any APPLY attempt. The date on the 'offending' PTF is mid 2017; we're not looking at something hot off the press. I'm convinced that this is a user error, perhaps from long ago. Go ahead and open a case, but my money is on a past APPLY failure. This sysmod BTW is TCP/IP HIP6220, SUP in z/OS 2.3 by HIP6230. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Monday, August 26, 2019 10:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: GIM38201E and GIM31901I It's been a while, but my default mode is to track down what's wrong with the packaging, contact the vendor and work with him to resolve it. Except in emergencies I don't develop my own workaround. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Lizette Koehler Sent: Sunday, August 25, 2019 9:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GIM38201E and GIM31901I When I have these types of issues, I go back to the vendor to find out what is needed to resolve the issue. This could be something in the way they coded the SMP/e fixes or in the way I am trying to apply maintenance. I do not do anything fancy with maintenance. If you could post your SMP/e control cards - there might be something we see in the way they are coded. I usually do a APPLY CHECK Bypass(HOLDSYS) S(x y z) . From what I have seen over the years, this usually will work. And I will tend to use the SMP/e panels in ISPF to build my JCL. Saves a lot of time in building the jobs. Lizette > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Peter > Sent: Sunday, August 25, 2019 12:21 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: GIM38201E and GIM31901I > > Hi > > I am apply RSU for our zOS system. I am receiving a error message > > GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD > UI34556 > > GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. > UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. > > GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. > > Does it mean the PTF UI46897 applied should be restored and modify its > MCS to add UI34556 as its PRE ? > > Is my understanding correct? > > Could someone please shed light on ? > > zOS 2.2 > > Peter > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIM38201E and GIM31901I
I really don't think this is a packaging error; as noted by Tom Conley, those are exceedingly rare. If one occurs, there should be a lightning quick HOLD record that would show up in any APPLY attempt. The date on the 'offending' PTF is mid 2017; we're not looking at something hot off the press. I'm convinced that this is a user error, perhaps from long ago. Go ahead and open a case, but my money is on a past APPLY failure. This sysmod BTW is TCP/IP HIP6220, SUP in z/OS 2.3 by HIP6230. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Monday, August 26, 2019 10:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: GIM38201E and GIM31901I It's been a while, but my default mode is to track down what's wrong with the packaging, contact the vendor and work with him to resolve it. Except in emergencies I don't develop my own workaround. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Lizette Koehler Sent: Sunday, August 25, 2019 9:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GIM38201E and GIM31901I When I have these types of issues, I go back to the vendor to find out what is needed to resolve the issue. This could be something in the way they coded the SMP/e fixes or in the way I am trying to apply maintenance. I do not do anything fancy with maintenance. If you could post your SMP/e control cards - there might be something we see in the way they are coded. I usually do a APPLY CHECK Bypass(HOLDSYS) S(x y z) . From what I have seen over the years, this usually will work. And I will tend to use the SMP/e panels in ISPF to build my JCL. Saves a lot of time in building the jobs. Lizette > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Peter > Sent: Sunday, August 25, 2019 12:21 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: GIM38201E and GIM31901I > > Hi > > I am apply RSU for our zOS system. I am receiving a error message > > GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD > UI34556 > > GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. > UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. > > GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. > > Does it mean the PTF UI46897 applied should be restored and modify its > MCS to add UI34556 as its PRE ? > > Is my understanding correct? > > Could someone please shed light on ? > > zOS 2.2 > > Peter > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIM38201E and GIM31901I
It's been a while, but my default mode is to track down what's wrong with the packaging, contact the vendor and work with him to resolve it. Except in emergencies I don't develop my own workaround. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Lizette Koehler Sent: Sunday, August 25, 2019 9:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GIM38201E and GIM31901I When I have these types of issues, I go back to the vendor to find out what is needed to resolve the issue. This could be something in the way they coded the SMP/e fixes or in the way I am trying to apply maintenance. I do not do anything fancy with maintenance. If you could post your SMP/e control cards - there might be something we see in the way they are coded. I usually do a APPLY CHECK Bypass(HOLDSYS) S(x y z) . >From what I have seen over the years, this usually will work. And I will tend to use the SMP/e panels in ISPF to build my JCL. Saves a lot of time in building the jobs. Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Peter > Sent: Sunday, August 25, 2019 12:21 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: GIM38201E and GIM31901I > > Hi > > I am apply RSU for our zOS system. I am receiving a error message > > GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD UI34556 > > GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. > UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. > > GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. > > Does it mean the PTF UI46897 applied should be restored and modify its MCS to > add UI34556 as its PRE ? > > Is my understanding correct? > > Could someone please shed light on ? > > zOS 2.2 > > Peter > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIM38201E and GIM31901I
Exclude should not be needed. A PMR should be opened so that the problem can be fixed correctly. Most often, users cause this error by specifying REDO but there are a few other rare causes that usually require PMR to fix the problem. Jon. On Monday, August 26, 2019, 05:54:33 AM PDT, Allan Staller wrote: You are trying to install a down-level PTF. Did your run an accept prior to the apply check? The best time to ran an accept, is just before the next apply. I suspect that UI46897 SUPS UI34556 (haven't checked). Running an successful accept prior to the apply will cause UI34556 to be deleted from the global zone and eliminate the error. The other choice us to exclude UI34556 from the apply. However, I suspect this will not be the only modid error that will be encountered. APPLY ,.. EXLCUDE(UI34556). Check the fine manuals for syntax. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIM38201E and GIM31901I
You are trying to install a down-level PTF. Did your run an accept prior to the apply check? The best time to ran an accept, is just before the next apply. I suspect that UI46897 SUPS UI34556 (haven't checked). Running an successful accept prior to the apply will cause UI34556 to be deleted from the global zone and eliminate the error. The other choice us to exclude UI34556 from the apply. However, I suspect this will not be the only modid error that will be encountered. APPLY ,.. EXLCUDE(UI34556). Check the fine manuals for syntax. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Sent: Sunday, August 25, 2019 2:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: GIM38201E and GIM31901I Hi I am apply RSU for our zOS system. I am receiving a error message GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD UI34556 GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. Does it mean the PTF UI46897 applied should be restored and modify its MCS to add UI34556 as its PRE ? Is my understanding correct? Could someone please shed light on ? zOS 2.2 Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIM38201E and GIM31901I
On 8/25/2019 3:21 AM, Peter wrote: Hi I am apply RSU for our zOS system. I am receiving a error message GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD UI34556 GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. Does it mean the PTF UI46897 applied should be restored and modify its MCS to add UI34556 as its PRE ? Is my understanding correct? Could someone please shed light on ? zOS 2.2 Peter Peter, You should open a PMR immediately with IBM to report a packaging error. They're rare, but they do happen. IBM will be able to tell you pretty quickly if it's a packaging error, or if you had an error in your SMP/E that caused this. Be sure to NEVER, NEVER, NEVER use BYPASS(ID). Good luck, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIM38201E and GIM31901I
This situation is 'normal' if a vendor-supplied sysmod hits a module that was last updated by an installation usermod. In this case, module EZBTCRDF was last updated by UI46897, which by all appearances is a PTF, not a usermod. So the question is, why does SMPE not recognize the history of EZBTCRDF? RETRY, as previously noted, should not be involved. I suggest looking at UI46897 to determine why SMPE does not understand its role here. Something went wrong sometime in the past...Hold the phone. I finally did what should always be done first: Googled 'ibm UI46897'. Found this hit: https://www-01.ibm.com/support/docview.wss?uid=isg3T1010412 "During the second APPLY the following week, PTFs containing the same parts as those that got missed when the spool filled up were hit by PTFs at a higher level resulting in the MODID errors being seen... Perform an APPLY REDO of all of the PTFs affected by the spool filling up. Then, re-do all of the applies that were done since the time that the spool filled up. Afterwards, a listing of all SYSMODs should show no PTFs are in ERRor status." . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Sent: Sunday, August 25, 2019 12:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):GIM38201E and GIM31901I Hi I am apply RSU for our zOS system. I am receiving a error message GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD UI34556 GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. Does it mean the PTF UI46897 applied should be restored and modify its MCS to add UI34556 as its PRE ? Is my understanding correct? Could someone please shed light on ? zOS 2.2 Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIM38201E and GIM31901I
Hi Lizette, I misspoke. You're right. Regards, David On 2019-08-25 10:04, Lizette Koehler wrote: > David > > I think RETRY(YES) is to recover from space abends. > > >From the manual > > RETRY > indicates whether SMP/E should try to recover from out-of-space errors > for utilities it calls. > > YES > indicates that SMP/E should try to recover and retry the utility if > a RETRYDDN list is available in the OPTIONS entry that is in effect. > RETRY(YES) is the default. > > If retry processing does not reclaim sufficient space and input to > the utility was batched (copy or link-edit utility only), SMP/E debatches the > input and retries the utility for each member separately. If this final > attempt fails, the resulting x37 abend is treated as an unacceptable utility > return code. In this case, processing continues for SYSMODs containing > eligible updates to other libraries, but processing fails for SYSMODs > containing unprocessed elements for the out-of-space library (and it fails > for any SYSMODs that are dependent on the failed SYSMODs). For guidance on > setting up the desired retry processing, see SMP/E for z/OS User's Guide. For > more information about OPTIONS entries, see SMP/E for z/OS Reference. > > If there is no RETRYDDN list, SMP/E does not try to recover from > out-of-space errors, even if you specify YES. > NO > indicates that SMP/E should not try to recover from the error. > > > Lizette > > >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of >> David Spiegel >> Sent: Sunday, August 25, 2019 7:01 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: GIM38201E and GIM31901I >> >> Hi Peter, >> Remove the RETRY(YES). >> This will stop SMP/e from APPLYing "old" PTFs. >> >> Regards, >> David >> >> On 2019-08-25 09:53, Peter wrote: >>> Here is the control statement : >>> >>> SMPCNTL DD * >>> SET BDY TZONE . >>> APPLY CHECK >>> GROUPEXTEND >>> BYPASS((HOLDSYSTEM)) >>> RETRY(YES) >>> . >>> >>> >>> On Sun, 25 Aug, 2019, 4:30 PM David Spiegel, >>> wrote: >>> >>>> Hi Peter, >>>> - Modifying vendor-supplied MCS is NEVER a good idea. >>>> - The messages means that you are trying to APPLY a lower-level PTF >>>> than is currently APPLYd. >>>> (Do you really want to back-level your software?) It would be helpful >>>> to supply your entire //SMPCNTL when asking questions of this nature. >>>> That is, there is not enough context to decipher what you're attempting. >>>> >>>> Regards, >>>> David >>>> >>>> On 2019-08-25 03:21, Peter wrote: >>>>> Hi >>>>> >>>>> I am apply RSU for our zOS system. I am receiving a error message >>>>> >>>>> GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD >>>> UI34556 >>>>> GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. >>>>> UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. >>>>> >>>>> GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. >>>>> >>>>> Does it mean the PTF UI46897 applied should be restored and modify >>>>> its >>>> MCS >>>>> to add UI34556 as its PRE ? >>>>> >>>>> Is my understanding correct? >>>>> >>>>> Could someone please shed light on ? >>>>> >>>>> zOS 2.2 >>>>> >>>>> Peter >>>>> >>>>> >>>>> -- For IBM-MAIN subscribe / signoff / archive access instructions, >>>>> send email to lists...@listserv.ua.edu with the message: INFO >>>>> IBM-MAIN . >>>>> >>>> - >>>> - For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email to lists...@listserv.ua.edu with the message: INFO >>>> IBM-MAIN >>>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, send >>> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . >>> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIM38201E and GIM31901I
David I think RETRY(YES) is to recover from space abends. >From the manual RETRY indicates whether SMP/E should try to recover from out-of-space errors for utilities it calls. YES indicates that SMP/E should try to recover and retry the utility if a RETRYDDN list is available in the OPTIONS entry that is in effect. RETRY(YES) is the default. If retry processing does not reclaim sufficient space and input to the utility was batched (copy or link-edit utility only), SMP/E debatches the input and retries the utility for each member separately. If this final attempt fails, the resulting x37 abend is treated as an unacceptable utility return code. In this case, processing continues for SYSMODs containing eligible updates to other libraries, but processing fails for SYSMODs containing unprocessed elements for the out-of-space library (and it fails for any SYSMODs that are dependent on the failed SYSMODs). For guidance on setting up the desired retry processing, see SMP/E for z/OS User's Guide. For more information about OPTIONS entries, see SMP/E for z/OS Reference. If there is no RETRYDDN list, SMP/E does not try to recover from out-of-space errors, even if you specify YES. NO indicates that SMP/E should not try to recover from the error. Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > David Spiegel > Sent: Sunday, August 25, 2019 7:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: GIM38201E and GIM31901I > > Hi Peter, > Remove the RETRY(YES). > This will stop SMP/e from APPLYing "old" PTFs. > > Regards, > David > > On 2019-08-25 09:53, Peter wrote: > > Here is the control statement : > > > > SMPCNTL DD * > > SET BDY TZONE . > > APPLY CHECK > > GROUPEXTEND > > BYPASS((HOLDSYSTEM)) > > RETRY(YES) > > . > > > > > > On Sun, 25 Aug, 2019, 4:30 PM David Spiegel, > > wrote: > > > >> Hi Peter, > >> - Modifying vendor-supplied MCS is NEVER a good idea. > >> - The messages means that you are trying to APPLY a lower-level PTF > >> than is currently APPLYd. > >> (Do you really want to back-level your software?) It would be helpful > >> to supply your entire //SMPCNTL when asking questions of this nature. > >> That is, there is not enough context to decipher what you're attempting. > >> > >> Regards, > >> David > >> > >> On 2019-08-25 03:21, Peter wrote: > >>> Hi > >>> > >>> I am apply RSU for our zOS system. I am receiving a error message > >>> > >>> GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD > >> UI34556 > >>> GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. > >>> UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. > >>> > >>> GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. > >>> > >>> Does it mean the PTF UI46897 applied should be restored and modify > >>> its > >> MCS > >>> to add UI34556 as its PRE ? > >>> > >>> Is my understanding correct? > >>> > >>> Could someone please shed light on ? > >>> > >>> zOS 2.2 > >>> > >>> Peter > >>> > >>> > >>> -- For IBM-MAIN subscribe / signoff / archive access instructions, > >>> send email to lists...@listserv.ua.edu with the message: INFO > >>> IBM-MAIN . > >>> > >> > >> - > >> - For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO > >> IBM-MAIN > >> > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIM38201E and GIM31901I
Hi Lizette, GROUPEXTEND (abbreviation GEXT) should always be coded. Regards, David On 2019-08-25 09:56, Lizette Koehler wrote: > When I have these types of issues, I go back to the vendor to find out what > is needed to resolve the issue. This could be something in the way they > coded the SMP/e fixes or in the way I am trying to apply maintenance. > > I do not do anything fancy with maintenance. > > If you could post your SMP/e control cards - there might be something we see > in the way they are coded. > > I usually do a > >APPLY CHECK Bypass(HOLDSYS) S(x y z) . > > >From what I have seen over the years, this usually will work. > > And I will tend to use the SMP/e panels in ISPF to build my JCL. Saves a lot > of time in building the jobs. > > Lizette > > >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of >> Peter >> Sent: Sunday, August 25, 2019 12:21 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: GIM38201E and GIM31901I >> >> Hi >> >> I am apply RSU for our zOS system. I am receiving a error message >> >> GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD UI34556 >> >> GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. >> UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. >> >> GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. >> >> Does it mean the PTF UI46897 applied should be restored and modify its MCS to >> add UI34556 as its PRE ? >> >> Is my understanding correct? >> >> Could someone please shed light on ? >> >> zOS 2.2 >> >> Peter >> > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIM38201E and GIM31901I
Hi Peter, Remove the RETRY(YES). This will stop SMP/e from APPLYing "old" PTFs. Regards, David On 2019-08-25 09:53, Peter wrote: > Here is the control statement : > > SMPCNTL DD * > SET BDY TZONE . > APPLY CHECK > GROUPEXTEND > BYPASS((HOLDSYSTEM)) > RETRY(YES) > . > > > On Sun, 25 Aug, 2019, 4:30 PM David Spiegel, > wrote: > >> Hi Peter, >> - Modifying vendor-supplied MCS is NEVER a good idea. >> - The messages means that you are trying to APPLY a lower-level PTF than >> is currently APPLYd. >> (Do you really want to back-level your software?) >> It would be helpful to supply your entire //SMPCNTL when asking >> questions of this nature. >> That is, there is not enough context to decipher what you're attempting. >> >> Regards, >> David >> >> On 2019-08-25 03:21, Peter wrote: >>> Hi >>> >>> I am apply RSU for our zOS system. I am receiving a error message >>> >>> GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD >> UI34556 >>> GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. >>> UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. >>> >>> GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. >>> >>> Does it mean the PTF UI46897 applied should be restored and modify its >> MCS >>> to add UI34556 as its PRE ? >>> >>> Is my understanding correct? >>> >>> Could someone please shed light on ? >>> >>> zOS 2.2 >>> >>> Peter >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> . >>> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIM38201E and GIM31901I
When I have these types of issues, I go back to the vendor to find out what is needed to resolve the issue. This could be something in the way they coded the SMP/e fixes or in the way I am trying to apply maintenance. I do not do anything fancy with maintenance. If you could post your SMP/e control cards - there might be something we see in the way they are coded. I usually do a APPLY CHECK Bypass(HOLDSYS) S(x y z) . >From what I have seen over the years, this usually will work. And I will tend to use the SMP/e panels in ISPF to build my JCL. Saves a lot of time in building the jobs. Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Peter > Sent: Sunday, August 25, 2019 12:21 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: GIM38201E and GIM31901I > > Hi > > I am apply RSU for our zOS system. I am receiving a error message > > GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD UI34556 > > GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. > UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. > > GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. > > Does it mean the PTF UI46897 applied should be restored and modify its MCS to > add UI34556 as its PRE ? > > Is my understanding correct? > > Could someone please shed light on ? > > zOS 2.2 > > Peter > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIM38201E and GIM31901I
Here is the control statement : SMPCNTL DD * SET BDY TZONE . APPLY CHECK GROUPEXTEND BYPASS((HOLDSYSTEM)) RETRY(YES) . On Sun, 25 Aug, 2019, 4:30 PM David Spiegel, wrote: > Hi Peter, > - Modifying vendor-supplied MCS is NEVER a good idea. > - The messages means that you are trying to APPLY a lower-level PTF than > is currently APPLYd. > (Do you really want to back-level your software?) > It would be helpful to supply your entire //SMPCNTL when asking > questions of this nature. > That is, there is not enough context to decipher what you're attempting. > > Regards, > David > > On 2019-08-25 03:21, Peter wrote: > > Hi > > > > I am apply RSU for our zOS system. I am receiving a error message > > > > GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD > UI34556 > > > > GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. > > UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. > > > > GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. > > > > Does it mean the PTF UI46897 applied should be restored and modify its > MCS > > to add UI34556 as its PRE ? > > > > Is my understanding correct? > > > > Could someone please shed light on ? > > > > zOS 2.2 > > > > Peter > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > . > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GIM38201E and GIM31901I
Hi Peter, - Modifying vendor-supplied MCS is NEVER a good idea. - The messages means that you are trying to APPLY a lower-level PTF than is currently APPLYd. (Do you really want to back-level your software?) It would be helpful to supply your entire //SMPCNTL when asking questions of this nature. That is, there is not enough context to decipher what you're attempting. Regards, David On 2019-08-25 03:21, Peter wrote: > Hi > > I am apply RSU for our zOS system. I am receiving a error message > > GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD UI34556 > > GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. > UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. > > GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. > > Does it mean the PTF UI46897 applied should be restored and modify its MCS > to add UI34556 as its PRE ? > > Is my understanding correct? > > Could someone please shed light on ? > > zOS 2.2 > > Peter > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
GIM38201E and GIM31901I
Hi I am apply RSU for our zOS system. I am receiving a error message GIM38201E ** THERE IS A MODID ERROR FOR MOD ENTRY EZBTCRDF IN SYSMOD UI34556 GIM31901I SYSMOD UI34556 DOES NOT SPECIFY UI46897 ON PRE OR SUP OPERAND. UI46897 IS THE RMID FOR MOD EZBTCRDF THAT IS CURRENTLY INSTALLED. GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI34556. Does it mean the PTF UI46897 applied should be restored and modify its MCS to add UI34556 as its PRE ? Is my understanding correct? Could someone please shed light on ? zOS 2.2 Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
