I checked with the consoles folks. Walt's surmise is correct.
The command will usually run in master or console address space (some do
run elsewhere) , but it is sent over the SSI in the space that
created/issued it (whether by MGCR(E) or via SDSF).
A ROUTEd command will run in the system
In
ofe0653aee.3d63bcdb-on85257bc8.0047b8fd-85257bc8.00480...@us.ibm.com,
on 08/15/2013
at 09:05 AM, Peter Relson rel...@us.ibm.com said:
whether by MGCR(E) or via SDSF
Doesn't SDSF issue an MGCR[E] to process /cmd?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2
On Tue, 13 Aug 2013 19:17:49 -0400, Peter Relson rel...@us.ibm.com wrote:
Route does little more than send the command to another system. On that
system that command may be processed by some number of system address
spaces (such as master, consoles). Each will use whatever its lnklst is.
I don't
It's surprising to me that simply routing the command causes
a different linklst to be used (guessing the old one).
It should be surprising. It is not possible.
With all due respect and my humble thanks for your input, for the record, this
is an inaccurate blanket statement. Someone may see
...I'm going to make a guess that the OP is using SDSF to issue the commands
Yes, all commands were done in SDSF.
-Jim
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu
In
of5b623f4f.38249aee-on85257bc6.007f6049-85257bc6.00800...@us.ibm.com,
on 08/13/2013
at 07:17 PM, Peter Relson rel...@us.ibm.com said:
It's surprising to me that simply routing the command causes
a different linklst to be used (guessing the old one).
It should be surprising. It is not
It's surprising to me that simply routing the command causes
a different linklst to be used (guessing the old one).
It should be surprising. It is not possible.
Route does little more than send the command to another system. On that
system that command may be processed by some number of
Thanks, Peter, The reason I didn't include that detail is because I didn't
think it was relevant to the question: Why does ROUTE change the results of
-DB2T,REFRESH,EARLY. This command executes on the same lpar after being
ROUTed from a remote lpar. It's surprising to me that simply routing
Sorry, I just noticed that I left out the commands we issued to STOP DB2 in my
scenario. There were issued 1) before the linklst UPDATE (that's why I said
they were terminating), and 2) before each REFRESH,EARLY command. And of
course, you can assume START DB2 commands were issued.
It would have been helpful to know what sort of approach you were taking
to create a new linklist.
If you simply defined one and activated it, then it would depend on
whether you activated it before or after the DB2 space started. Unless you
did an UPDATE in which case nothing can be stated or
Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of nitz-...@gmx.net
Sent: Monday, August 05, 2013 10:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MVS ROUTE command is a bad influence on DB2 ERLY code
The command char is registered with the subsystem
.
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of nitz-...@gmx.net
Sent: Monday, August 05, 2013 10:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MVS ROUTE command is a bad influence on DB2 ERLY code
The command char
Thanks Don and Elardus for your replies. I don't get a RACf msg during any of
this, so I don't think it's involved. We have a shared RACF DB. I use the same
logon id with the same authority on both lpars. I just get different results
when I issue it locally. As far as automation goes, we do
@LISTSERV.UA.EDU] On Behalf
Of Jim Mooney
Sent: Monday, August 05, 2013 2:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MVS ROUTE command is a bad influence on DB2 ERLY code
Thanks Don and Elardus for your replies. I don't get a RACf msg during any of
this, so I don't think it's involved. We have a shared
Thanks very much for the input. I can't get to our DR system today, but I
suspect it's similar to this, which I get on our prod system:
D OPDATA
IEE603I 16.32.21 OPDATA DISPLAY 529
PREFIX OWNER SYSTEM
] On Behalf
Of Jim Mooney
Sent: Monday, August 05, 2013 4:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MVS ROUTE command is a bad influence on DB2 ERLY code
Thanks very much for the input. I can't get to our DR system today, but I
suspect it's similar to this, which I get on our prod system:
D
The command char is registered with the subsystem definition - I suspect (but
don't know) that when you look at the OPDATA between the 2 systems (run the
command on each ) you will see a difference.
Why Route gets involved is each system is processing the command according to
what is
Is -DB2T a pseudo-command prefix intercepted and processed by an automation
package? If so, verify the details in automation to determine the actual
routing and scope of the command.
- Don Imbriale
On Fri, Aug 2, 2013 at 12:17 PM, Jim Mooney jmoo...@princesscruises.comwrote:
Hello list;
We
Jim Mooney wrote:
We are mystified by this, so I'd like to see if anyone else has had a similar
observation.
I have not experienced this specific ROUTE problem, but see my comments below.
(I have seen queer ROUTE problems, but that was solved by going in one SYSPLEX
and having ONE shared RACF
Hello list;
We are mystified by this, so I'd like to see if anyone else has had a similar
observation.
We have 2 active zOS113 lpars on our DR machine. DB2 V9R1m0 is only running on
one lpar.
We were trying to update DB2 ERLY code by inserting a dataset into a new
linklist and activating it.
20 matches
Mail list logo
