In <1318801164.28999.yahoomailmob...@web161422.mail.bf1.yahoo.com>, on
10/16/2011
at 02:39 PM, Ed Gould said:
>That
Please provide an attribution line and quote enough text to provide
context. An In-Reply-To: header fIeld wouldn't hurt either.
>is possible
If you're repsonding to Message-ID
That is possible bowser if DFDSS hands the record to the utility it Is entirey
possible
Ed
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INF
In <1318724543.9884.yahoomailmob...@web161403.mail.bf1.yahoo.com>, on
10/15/2011
at 05:22 PM, Ed Gould said:
>You have a point but the key word is encapsulate is it add a few
>records to it, or is wrapping the record output of IDCAMS surrounded
>by the data.
Well, if it's using both IEBCOPY
Shmuel,
You have a point but the key word is encapsulate is it add a few records to it,
or is wrapping the record output of IDCAMS surrounded by the data. I don't
have an answer. I would guess and it is a guess that DFDSS
would add records to the beginning.
I seem to recall something to that ef
In <1318554485.51049.yahoomailmob...@web161422.mail.bf1.yahoo.com>, on
10/13/2011
at 06:08 PM, Ed Gould said:
>It may well do so, however when invoked it must do so by not
>specifying by DSN. I honestly don't know the format of the the
>RMM dataset so unless it's some off the wall format (I su
Mike,
It may well do so, however when invoked it must do so by not specifying by DSN.
I honestly don't know the format of the the RMM dataset so unless it's
some off the wall format (I suspect it's VSAM), there is no reason it
can't be done by IDCAMS unless it's not really VSAM at all in which
Ed, As Shmuel Metz pointed out, dss can exploit other utilities. However, for
the rmm backup it is its (virtual) concurrent copy and similar capabilities
that are needed which requires dss to perform its own I/O.
--
For IBM-MA
In ,
on 10/11/2011
at 10:23 AM, "McKown, John" said:
>I am fairly sure that ADRDSSU is the "n"th grandchild of IEHDASDR
>(wasn't that the MVT disk dump/restore?).
IEHDASDR was an OS/360[1] utility, and there was a program product
derived from it, but AFAIK DSS[2] was a completely new utility.
I sent them the correction for their problem, there were actually several
issues, and I decided to give them the easiest one to fix the problem.
Brian
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email
nd Health Insurance Company.SM
>
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List
> > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Gould
> > Sent: Tuesday, October 11, 2011 10:23 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject:
ama.ua.edu
> Subject: Re: Automated SMFDUMP Job issue
>
> Mike,
>
> DFDSS is a fine utility. How ever from what I understand
> DFDSS just invokes the appropriate utility under covers. If
> it's aVSAM dataset it uses IDCAMS if it's PDS it uses
> IEBCOPY. The uti
Mike,
DFDSS is a fine utility. How ever from what I understand DFDSS just invokes the
appropriate utility under covers. If it's aVSAM dataset it uses IDCAMS if it's
PDS it uses IEBCOPY. The utilities are passed various parms or ddname
parameters like size and bufnd (and the like).
To make the
saurabh, Further to my earlier reply:
EDG4010D is issued only when you are using basic backup in rmm, and only when a
tape open/close has been delayed for around 10 minutes. This means the backup
of the CDS using IDCAMS via EDGHSKP/EDGBKUP is taking too long. Either the CDS
is very large or the
First,
The CONSOLxx member segment that you printed most likely has nothing to do with
the console that is trying to be used to issue the message. We are not talking
REAL consoles here, (Unless your REPLYTO utility is specifically using the
MASTER console, in which case you would not be gettin
Hello Brian,
Below is the output of the console member. We do have
Master authority.
BROWSESYS1.PARMLIB(CONSOL00) - 01.06 Line Col 001
080
Command ===> Scroll ===>
PAGE
*
The solution here is the same as the solution I provided you to the original
question.
Brian
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN IN
Hi,
The old AUTO program that you are using has long since been replaced by
SyzAUTO/z (I rewrote AUTO over 15 years ago to correct all of the issues and
add more functionality) available at http://syzygyinc.net/AUTOz.aspx , but AUTO
isn't the cause of your problem.
What has happened is that
Yes that is also a option. But this backup process is working in all other
systems. But I am not getting the reason for holding SMFDUMP job in this
system occasionally. Most of the time it works. But some time it doesnt. How
that is possible.
I tried comparing the Job log of the two system ( a) The
Yes that is also a option. But this backup process is working in all other
> systems. But I am not getting the reason for holding SMFDUMP job in this
> system occasionally. Most of the time it works. But some time it doesnt. How
> that is possible.
>
> I tried comparing the Job log of the two syste
saurabh, Rather than considering the problem to be making a reply to the
EDG4010D, why dont you try to avoid the EDG4010D message?
EDG4010D is issued only when you are using the basic, intrusive backup method
of rmm. If you switch to using a non-intrusive method, your SMFDUMP and any
other tap
Hello,
Today I am again facing this issue and two SMFDUMP job is waiting
in output queue and System is asking to reply .
SMFDUMP STC20050 SMFDUMP15 EXECUTION SYE1 SYE1
SMFDUMP STC20053 SMFDUMP15 EXECUTION SYE1 SYE1
A00 SYSE122.04.04 STC20050 *09 EDG
Hello,
The problem is in one of system where the automated response for a problem
with a tape mount, due to the RMM backup being in progress, is issued, but
rejected by zOS.
I am pasting the output of REPLYTO job. Where I had problem SYSE1 system
backup and I had to reply with 08.
IEFU29 HAS ISS
saurabh khandelwal wrote:
My note: You and Jake Anderson wrote the SAME post nearly word by word. Are you
colleagues?
> In one of our z/OS system the daily SMFDUMP that starts to run at
> 2200 hrs. bets a message from RMM due to the daily backup running.
"bets a message"? Could you b
Hello Group,
In one of our z/OS system the daily SMFDUMP that starts to run at
2200 hrs. bets a message from RMM due to the daily backup running. The
response to the message fails saying that "Reply xx was not requested from
this console". This process works on most other systems.
2200 is
24 matches
Mail list logo
