Re: [External] Re: SMP/E receive order problem
All, Just to close this, I got a note back from SMP/E support today stating that all is well even though the ".ROOT.pax.Z" file didn't get created. The gentleman from SMP/E said that when the RESTORE job runs to build the actual system datasets, it would recognize that the ROOT.pax.Z file doesn't exist, find the components, and build the ROOT.pax.Z file at that time. I don't know if I'll test his response or if I'll just move forward with the install using the completed RECEIVE ORDER system. I know where assuming get me, but at this point I've got to assume that if the RESTORE job hits an out-of-space trying to build the ROOT.pax.Z file, it'll fail at that point. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Tuesday, March 10, 2020 9:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: SMP/E receive order problem All, In case anybody's interested in this, I have more information. The z/OS root filesystem is the file being transferred that is failing. I was able to recreate the problem in our sandbox. What appears to be happening is that the root filesystem pax.Z file is actually being sent in 11 pieces, each at 512 MB. The root is over 5 GB so the file is transferred in 11 chunks then assembled on site in the Unix filesystem. The assembly part is what appears to be failing so all the parts did get transferred successfully. I found all 11 chunks that make up the root filesystem. I'll be opening a PMR for this. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kurt Quackenbush Sent: Thursday, March 5, 2020 8:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: SMP/E receive order problem > GIM43501S ** THE CALL TO THE BPX1WRT SERVICE FAILED WHEN PROCESSING > /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z. THE RETURN > CODE WAS '0085'X AND THE REASON CODE WAS 'EF01604E'X. > GIM49011S ** AN ERROR OCCURRED WHILE CREATING ARCHIVE FILE > /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z FROM ITS > SEGMENTS. > GIM47601IPACKAGE OS240809.content WAS PARTIALLY STAGED TO THE SMPNTS. > > I added another mod27 volume to the storage group and restarted the job. > This run ended with RC=0 however, I got this in the output: > > GIM64700IFILE /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z ALREADY > EXISTS AND WILL NOT BE TRANSFERRED. > > I look in the filesystem and this pax file doesn't exist. How do I convince > SMP/E that the file isn't there and it needs to get it again from IBM. I > don't really want to delete the entire order and re receive it as the receive > job ran for 6 hours before failing. Hmmm... that is suspicious. Are you sure you're looking in the same directory and file system that SMP/E is looking in? Not only does SMP/E look to see if the file already exists before downloading, it also calculates and compares the hash value for the existing file to ensure it is complete and accurate. The GIM64700I message implies SMP/E both found the file and the calculated hash matches the expected value. If truly the file does not already exist, then open a Case with IBM Support against SMP/E. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on
Re: [External] Re: SMP/E receive order problem
On Tue, 10 Mar 2020 14:19:08 +, Pommier, Rex wrote: > >... the root filesystem pax.Z file is actually being sent in 11 pieces, each >at 512 MB. The root is over 5 GB so the file is transferred in 11 chunks then >assembled on site in the Unix filesystem. The assembly part is what appears >to be failing so all the parts did get transferred successfully. I found all >11 chunks that make up the root filesystem. > I'm curious. In POSIX https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_03 I see: A single archive can span multiple files. The pax utility shall determine, in an implementation-defined manner, what file to read or write as the next file. I can't find that implementation-definition in the Command Ref. Where is it? "shall" means a requirement, not a suggestion. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: SMP/E receive order problem
Hi David, Yep, I know that it is a space issue. I was going to follow up with your timely advice about how I needed to delete and recreate the filesystem dataset with multiple volumes up front. Trying to add a volume to an existing OMVS dataset didn't work as the filesystem didn't extend onto the second volume. Deleting the entire dataset and creating it as multi volume allowed me to rerun the entire RECEIVE ORDER process and the filesystem extended onto the second volume and the job completed successfully. However, that doesn't change the fact that after the first attempt failed, trying to rerun the RECEIVE ORDER process said it worked when it didn't. The missed failure is what I'm opening the PMR on. Had I not gotten suspicious and started poking around the filesystem, I could have easily missed the missing pax file until after the order had been deleted from IBM's web site and I would have had to then go through and reorder the upgrade. So, thank you for pointing out the inability to extend an existing OMVS VSAM dataset. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jousma, David Sent: Tuesday, March 10, 2020 9:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: SMP/E receive order problem Rex, Its good you are opening a ticket. My money is still on a space issue. You said you added additional -27 volume to the pool that you are using for your SMPNTS. My suggestion would be to just unmount/delete the ZFS you created, reallocate it to the size of both of the mod-27's, remount it, and start the download again. > GIM43501S ** THE CALL TO THE BPX1WRT SERVICE FAILED WHEN PROCESSING > /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z. THE RETURN > CODE WAS '0085'X AND THE REASON CODE WAS 'EF01604E'X. BPXMTEXT for EF01604E, refers to RC (133) which is the x'85' in the same error message. zFS Mon Dec 16 12:08:54 EST 2019 Description: General VM cache failure. Action: If the return code is ENOSPC (133), the file system or aggregate is full. If this is the case, make more space available. Otherwise, contact the service representative. These are the IDCAMS allocation statements I use to allocate, of course, you'd have to tailor to your site to have a dataclass that specifies extended format DEFINE CLUSTER(NAME(SMPE.SERVRPAC.DOWNLOAD.ZFS) - VOLUMES(PCS001 - PCS002 - PCS003) - LINEAR DATACLASS(DCEXTNOC) STORCLAS(SCSYSTEM) - MB(5) SHAREOPTIONS(3,3)) _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Tuesday, March 10, 2020 10:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: SMP/E receive order problem **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** All, In case anybody's interested in this, I have more information. The z/OS root filesystem is the file being transferred that is failing. I was able to recreate the problem in our sandbox. What appears to be happening is that the root filesystem pax.Z file is actually being sent in 11 pieces, each at 512 MB. The root is over 5 GB so the file is transferred in 11 chunks then assembled on site in the Unix filesystem. The assembly part is what appears to be failing so all the parts did get transferred successfully. I found all 11 chunks that make up the root filesystem. I'll be opening a PMR for this. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kurt Quackenbush Sent: Thursday, March 5, 2020 8:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: SMP/E receive order problem > GIM43501S ** THE CALL TO THE BPX1WRT SERVICE FAILED WHEN PROCESSING > /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z. THE RETURN > CODE WAS '0085'X AND THE REASON CODE WAS 'EF01604E'X. > GIM49011S ** AN ERROR OCCURRED WHILE CREATING ARCHIVE FILE > /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z FROM ITS > SEGMENTS. > GIM47601IPACKAGE OS240809.content WAS PARTIALLY STAGED TO THE SMPNTS. >
Re: [External] Re: SMP/E receive order problem
Rex, Its good you are opening a ticket. My money is still on a space issue. You said you added additional -27 volume to the pool that you are using for your SMPNTS. My suggestion would be to just unmount/delete the ZFS you created SMPNTS, reallocate it to the size of both of the mod-27's, remount it, and start the download again. > GIM43501S ** THE CALL TO THE BPX1WRT SERVICE FAILED WHEN PROCESSING > /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z. THE RETURN > CODE WAS '0085'X AND THE REASON CODE WAS 'EF01604E'X. BPXMTEXT for EF01604E, refers to RC (133) which is the x'85' in the same error message. zFS Mon Dec 16 12:08:54 EST 2019 Description: General VM cache failure. Action: If the return code is ENOSPC (133), the file system or aggregate is full. If this is the case, make more space available. Otherwise, contact the service representative. These are the IDCAMS allocation statements I use to allocate, of course, you'd have to tailor to your site to have a dataclass that specifies extended format DEFINE CLUSTER(NAME(SMPE.SERVRPAC.DOWNLOAD.ZFS) - VOLUMES(PCS001 - PCS002 - PCS003) - LINEAR DATACLASS(DCEXTNOC) STORCLAS(SCSYSTEM) - MB(5) SHAREOPTIONS(3,3)) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: SMP/E receive order problem
Rex, Its good you are opening a ticket. My money is still on a space issue. You said you added additional -27 volume to the pool that you are using for your SMPNTS. My suggestion would be to just unmount/delete the ZFS you created, reallocate it to the size of both of the mod-27's, remount it, and start the download again. > GIM43501S ** THE CALL TO THE BPX1WRT SERVICE FAILED WHEN PROCESSING > /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z. THE RETURN > CODE WAS '0085'X AND THE REASON CODE WAS 'EF01604E'X. BPXMTEXT for EF01604E, refers to RC (133) which is the x'85' in the same error message. zFS Mon Dec 16 12:08:54 EST 2019 Description: General VM cache failure. Action: If the return code is ENOSPC (133), the file system or aggregate is full. If this is the case, make more space available. Otherwise, contact the service representative. These are the IDCAMS allocation statements I use to allocate, of course, you'd have to tailor to your site to have a dataclass that specifies extended format DEFINE CLUSTER(NAME(SMPE.SERVRPAC.DOWNLOAD.ZFS) - VOLUMES(PCS001 - PCS002 - PCS003) - LINEAR DATACLASS(DCEXTNOC) STORCLAS(SCSYSTEM) - MB(5) SHAREOPTIONS(3,3)) _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Tuesday, March 10, 2020 10:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: SMP/E receive order problem **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** All, In case anybody's interested in this, I have more information. The z/OS root filesystem is the file being transferred that is failing. I was able to recreate the problem in our sandbox. What appears to be happening is that the root filesystem pax.Z file is actually being sent in 11 pieces, each at 512 MB. The root is over 5 GB so the file is transferred in 11 chunks then assembled on site in the Unix filesystem. The assembly part is what appears to be failing so all the parts did get transferred successfully. I found all 11 chunks that make up the root filesystem. I'll be opening a PMR for this. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kurt Quackenbush Sent: Thursday, March 5, 2020 8:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: SMP/E receive order problem > GIM43501S ** THE CALL TO THE BPX1WRT SERVICE FAILED WHEN PROCESSING > /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z. THE RETURN > CODE WAS '0085'X AND THE REASON CODE WAS 'EF01604E'X. > GIM49011S ** AN ERROR OCCURRED WHILE CREATING ARCHIVE FILE > /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z FROM ITS > SEGMENTS. > GIM47601IPACKAGE OS240809.content WAS PARTIALLY STAGED TO THE SMPNTS. > > I added another mod27 volume to the storage group and restarted the job. > This run ended with RC=0 however, I got this in the output: > > GIM64700IFILE /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z ALREADY > EXISTS AND WILL NOT BE TRANSFERRED. > > I look in the filesystem and this pax file doesn't exist. How do I convince > SMP/E that the file isn't there and it needs to get it again from IBM. I > don't really want to delete the entire order and re receive it as the receive > job ran for 6 hours before failing. Hmmm... that is suspicious. Are you sure you're looking in the same directory and file system that SMP/E is looking in? Not only does SMP/E look to see if the file already exists before downloading, it also calculates and compares the hash value for the existing file to ensure it is complete and accurate. The GIM64700I message implies SMP/E both found the file and the calculated hash matches the expected value. If truly the file does not already exist, then open a Case with IBM Support against SMP/E. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subsc
Re: [External] Re: SMP/E receive order problem
All, In case anybody's interested in this, I have more information. The z/OS root filesystem is the file being transferred that is failing. I was able to recreate the problem in our sandbox. What appears to be happening is that the root filesystem pax.Z file is actually being sent in 11 pieces, each at 512 MB. The root is over 5 GB so the file is transferred in 11 chunks then assembled on site in the Unix filesystem. The assembly part is what appears to be failing so all the parts did get transferred successfully. I found all 11 chunks that make up the root filesystem. I'll be opening a PMR for this. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kurt Quackenbush Sent: Thursday, March 5, 2020 8:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: SMP/E receive order problem > GIM43501S ** THE CALL TO THE BPX1WRT SERVICE FAILED WHEN PROCESSING > /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z. THE RETURN > CODE WAS '0085'X AND THE REASON CODE WAS 'EF01604E'X. > GIM49011S ** AN ERROR OCCURRED WHILE CREATING ARCHIVE FILE > /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z FROM ITS > SEGMENTS. > GIM47601IPACKAGE OS240809.content WAS PARTIALLY STAGED TO THE SMPNTS. > > I added another mod27 volume to the storage group and restarted the job. > This run ended with RC=0 however, I got this in the output: > > GIM64700IFILE /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z ALREADY > EXISTS AND WILL NOT BE TRANSFERRED. > > I look in the filesystem and this pax file doesn't exist. How do I convince > SMP/E that the file isn't there and it needs to get it again from IBM. I > don't really want to delete the entire order and re receive it as the receive > job ran for 6 hours before failing. Hmmm... that is suspicious. Are you sure you're looking in the same directory and file system that SMP/E is looking in? Not only does SMP/E look to see if the file already exists before downloading, it also calculates and compares the hash value for the existing file to ensure it is complete and accurate. The GIM64700I message implies SMP/E both found the file and the calculated hash matches the expected value. If truly the file does not already exist, then open a Case with IBM Support against SMP/E. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E receive order problem
GIM43501S ** THE CALL TO THE BPX1WRT SERVICE FAILED WHEN PROCESSING /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z. THE RETURN CODE WAS '0085'X AND THE REASON CODE WAS 'EF01604E'X. GIM49011S ** AN ERROR OCCURRED WHILE CREATING ARCHIVE FILE /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z FROM ITS SEGMENTS. GIM47601IPACKAGE OS240809.content WAS PARTIALLY STAGED TO THE SMPNTS. I added another mod27 volume to the storage group and restarted the job. This run ended with RC=0 however, I got this in the output: GIM64700IFILE /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z ALREADY EXISTS AND WILL NOT BE TRANSFERRED. I look in the filesystem and this pax file doesn't exist. How do I convince SMP/E that the file isn't there and it needs to get it again from IBM. I don't really want to delete the entire order and re receive it as the receive job ran for 6 hours before failing. Hmmm... that is suspicious. Are you sure you're looking in the same directory and file system that SMP/E is looking in? Not only does SMP/E look to see if the file already exists before downloading, it also calculates and compares the hash value for the existing file to ensure it is complete and accurate. The GIM64700I message implies SMP/E both found the file and the calculated hash matches the expected value. If truly the file does not already exist, then open a Case with IBM Support against SMP/E. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E receive order problem
Hi Dave, Thanks for the pointers. Responding to your questions individually. Did I actually enlarge the zFS? It appears not. Doing the df -vk shows me this: Mounted on FilesystemAvail/TotalFiles Status /Service (OMVS.SOFTWARE.SMPNTS.ZFS) 4133103/23544000 4294966285 Available ZFS, Read/Write, Device:27, ACLS=Y Filetag : T=off codeset=0 Aggregate Name : OMVS.SOFTWARE.SMPNTS.ZFS Which makes it appear that it didn't actually add a second volume to the zFS VSAM. I did not know of the limitation requiring a multi volume zFS being built that way at create time. Taking into account the size of the order, the note I got from IBM says it is 18,886 MB which roughly translates into 26450 cylinders *2 for unpacking. I typically define a separate filesystem for the SMPWORK (or whatever it is actually called) so the pax uncompress goes into this other filesystem, so my smpnts should have easily fit onto a mod27 volume. I do have a small directory tree for cobol 4.2 sitting there but thought I had enough room to squeeze z/OS onto there. I guess not. I'll move the cobol to a different filesystem to free up the space in my smpnts. However, I would have thought that running the "receive an order" process the second time would have tried to re-receive the missing pax.Z file and blown again with out of space being that the zFS wouldn't extend. That part still bothers me, considering the second run of the receive job said it ran successfully even though I'm missing a rather important part of my order. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jousma, David Sent: Wednesday, March 4, 2020 2:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: SMP/E receive order problem Rex, Did you actually enlarge the ZFS? Finally, the other part of this is that you have to take the size of your order, and almost double the size to have room for the pax files to decompress. I don’t think that a ZFS can grow to be multi-volume, unless initially allocated that way. When I order and download a serverpack, I allocate a 50Gb multivolume ZFS. My normal SMPNTS is usually much smaller, maybe 15Gb or so. You might navigate to the filesystem and issue a "df -vk ." and see how much space you actually have? Your RSN code of EF01604E zFS Mon Dec 16 12:08:54 EST 2019 Description: General VM cache failure. Action: If the return code is ENOSPC (133), the file system or aggregate is full. If this is the case, make more space available. Otherwise, contact the service representative. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Wednesday, March 4, 2020 1:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMP/E receive order problem **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Hi, I'm guessing this is a simple fix, but I'm not finding the solution and rather than spend 3 days looking, I thought if somebody knows the answer right off, I would save some time. The situation is I am trying to do a receive order for z/OS 2.4 and my SMPNTS ran out of space - filled up a 3390-27 even though my calculation said it should only take 2 cylinders. Anyway, it apparently failed getting the last pax.Z file from the IBM web site - the ROOT filesystem pax file. Here are the errors I got: GIM43501S ** THE CALL TO THE BPX1WRT SERVICE FAILED WHEN PROCESSING /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z. THE RETURN CODE WAS '0085'X AND THE REASON CODE WAS 'EF01604E'X. GIM49011S ** AN ERROR OCCURRED WHILE CREATING ARCHIVE FILE /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z FROM ITS SEGMENTS. GIM47601IPACKAGE OS240809.content WAS PARTIALLY STAGED TO THE SMPNTS. I added another mod27 volume to the storage group and restarted the job. This run ended with RC=0 however, I got this in the output: GIM64700IFILE /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z ALREADY EXISTS AND WILL NOT B
Re: [External] Re: SMP/E receive order problem
In the "ServerPac using the Installation Dialog" manual, in the "generating the receive job" section, it states this: If the RECEIVE job fails, you must go into the CustomPac Installation Dialog panels to regenerate and rerun the RECEIVE job. However, something got set wrong (apparently, at least to me) when the job failed, and it somehow thinks the file that didn't get successfully received, did, so when I tried to rerun the job after regenerating it, it bypassed the missing file, saying it was already downloaded from IBM. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Wednesday, March 4, 2020 2:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: SMP/E receive order problem Hi Kolusu, Thanks for the suggestion, but unfortunately this doesn't help. This document is for the "RESTORE" job that unpaxes the files as part of the install process. I'm not to that point. I'm trying to receive the package from IBM software manufacturing which pulls all the pax.Z files into my SMPNTS filesystem. My receive job failed the first time trying to get the ROOT filesystem pax.Z file from IBM. The second attempt skipped right past that file, saying the file was already received from IBM but the file doesn't exist in the smpnts filesystem. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sri h Kolusu Sent: Wednesday, March 4, 2020 2:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: SMP/E receive order problem >>THE RETURN CODE WAS '0085'X AND THE REASON CODE WAS 'EF01604E'X. Rex, Did you check if this link helps resolving your problem? https://www.ibm.com/support/pages/restarting-serverpac-restore-step1 Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E receive order problem
Rex, Did you actually enlarge the ZFS? Finally, the other part of this is that you have to take the size of your order, and almost double the size to have room for the pax files to decompress. I don’t think that a ZFS can grow to be multi-volume, unless initially allocated that way. When I order and download a serverpack, I allocate a 50Gb multivolume ZFS. My normal SMPNTS is usually much smaller, maybe 15Gb or so. You might navigate to the filesystem and issue a "df -vk ." and see how much space you actually have? Your RSN code of EF01604E zFS Mon Dec 16 12:08:54 EST 2019 Description: General VM cache failure. Action: If the return code is ENOSPC (133), the file system or aggregate is full. If this is the case, make more space available. Otherwise, contact the service representative. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Wednesday, March 4, 2020 1:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMP/E receive order problem **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Hi, I'm guessing this is a simple fix, but I'm not finding the solution and rather than spend 3 days looking, I thought if somebody knows the answer right off, I would save some time. The situation is I am trying to do a receive order for z/OS 2.4 and my SMPNTS ran out of space - filled up a 3390-27 even though my calculation said it should only take 2 cylinders. Anyway, it apparently failed getting the last pax.Z file from the IBM web site - the ROOT filesystem pax file. Here are the errors I got: GIM43501S ** THE CALL TO THE BPX1WRT SERVICE FAILED WHEN PROCESSING /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z. THE RETURN CODE WAS '0085'X AND THE REASON CODE WAS 'EF01604E'X. GIM49011S ** AN ERROR OCCURRED WHILE CREATING ARCHIVE FILE /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z FROM ITS SEGMENTS. GIM47601IPACKAGE OS240809.content WAS PARTIALLY STAGED TO THE SMPNTS. I added another mod27 volume to the storage group and restarted the job. This run ended with RC=0 however, I got this in the output: GIM64700IFILE /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z ALREADY EXISTS AND WILL NOT BE TRANSFERRED. I look in the filesystem and this pax file doesn't exist. How do I convince SMP/E that the file isn't there and it needs to get it again from IBM. I don't really want to delete the entire order and re receive it as the receive job ran for 6 hours before failing. TIA, Rex The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. --
Re: [External] Re: SMP/E receive order problem
Hi Kolusu, Thanks for the suggestion, but unfortunately this doesn't help. This document is for the "RESTORE" job that unpaxes the files as part of the install process. I'm not to that point. I'm trying to receive the package from IBM software manufacturing which pulls all the pax.Z files into my SMPNTS filesystem. My receive job failed the first time trying to get the ROOT filesystem pax.Z file from IBM. The second attempt skipped right past that file, saying the file was already received from IBM but the file doesn't exist in the smpnts filesystem. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sri h Kolusu Sent: Wednesday, March 4, 2020 2:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: SMP/E receive order problem >>THE RETURN CODE WAS '0085'X AND THE REASON CODE WAS 'EF01604E'X. Rex, Did you check if this link helps resolving your problem? https://www.ibm.com/support/pages/restarting-serverpac-restore-step1 Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E receive order problem
>>THE RETURN CODE WAS '0085'X AND THE REASON CODE WAS 'EF01604E'X. Rex, Did you check if this link helps resolving your problem? https://www.ibm.com/support/pages/restarting-serverpac-restore-step1 Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMP/E receive order problem
Hi, I'm guessing this is a simple fix, but I'm not finding the solution and rather than spend 3 days looking, I thought if somebody knows the answer right off, I would save some time. The situation is I am trying to do a receive order for z/OS 2.4 and my SMPNTS ran out of space - filled up a 3390-27 even though my calculation said it should only take 2 cylinders. Anyway, it apparently failed getting the last pax.Z file from the IBM web site - the ROOT filesystem pax file. Here are the errors I got: GIM43501S ** THE CALL TO THE BPX1WRT SERVICE FAILED WHEN PROCESSING /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z. THE RETURN CODE WAS '0085'X AND THE REASON CODE WAS 'EF01604E'X. GIM49011S ** AN ERROR OCCURRED WHILE CREATING ARCHIVE FILE /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z FROM ITS SEGMENTS. GIM47601IPACKAGE OS240809.content WAS PARTIALLY STAGED TO THE SMPNTS. I added another mod27 volume to the storage group and restarted the job. This run ended with RC=0 however, I got this in the output: GIM64700IFILE /Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z ALREADY EXISTS AND WILL NOT BE TRANSFERRED. I look in the filesystem and this pax file doesn't exist. How do I convince SMP/E that the file isn't there and it needs to get it again from IBM. I don't really want to delete the entire order and re receive it as the receive job ran for 6 hours before failing. TIA, Rex The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
