Just a thought, is the target dataset of the transmit catalogued and
archived and unable to recall? catalogue orphan? or otherwise in error? If
so, then I would expect these messages. You might try a different target
dataset name and see if that works?
Chip Grantham | Ameritas | Sr. IT
That almost sounds like an IODF change that removed an esoteric that IEBCOPY is
using.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Thomas David Rivers
Sent: Tuesday, May 10, 2011 11:56 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEBCOPY
I attempted a little test and was able to see the allocations and related
SMS message under my TSO is in SDSF. There might be a clue for you there.
Speaking of SMS, is SMS allocating temporary datasets to a separate pool
that might be full and unable to allocate the IEBCOPY dataset? I would
My guess would be that XMIT is trying to allocate a temporary dataset, and
if your SMS rules don't point temp datasets to an SMS pool, then it is
trying to find a disk volume mounted as STORAGE or PUBLIC. Check to see if
there has been a change to your SMS config that might have affected temp
Just to follow up...
As every good programmer knows; when the user asserts
that nothing has changed - it's clear something *has* changed.
In fact, the SBSYS1 volume was full of junk; and I suppose IEBCOPY
couldn't mount whatever-was-next and so reported it was unable
to mount (instead of
If that is a non-sms volume, check SYS1.PARMLIB(VATLSTxx).
If that is a sms volume, check you ACS routines.
On Tue, May 10, 2011 at 3:07 PM, Thomas David Rivers riv...@dignus.com wrote:
Just to follow up...
As every good programmer knows; when the user asserts
that nothing has changed - it's
6 matches
Mail list logo
