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 '00000085'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(50000) 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 <[email protected]> On Behalf Of
Pommier, Rex
Sent: Tuesday, March 10, 2020 10:19 AM
To: [email protected]
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 <[email protected]> On Behalf Of
Kurt Quackenbush
Sent: Thursday, March 5, 2020 8:30 AM
To: [email protected]
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 '00000085'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.
> GIM47601I PACKAGE 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:
>
> GIM64700I FILE /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
[email protected] 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
[email protected] 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.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
