This is very basic and simple but I can't seem to see the answer anywhere
(although it is probably staring me in face).
Once TCPIP has decided that it has tried to restart a server (FTPSERVE)
the maximum number of time and abandons further attempts - how can I reset
this once the problem has
On Wednesday, 07/06/2011 at 04:25 EDT, Colin Allinson
cgallin...@amadeus.com wrote:
This is very basic and simple but I can't seem to see the answer
anywhere
(although it is probably staring me in face).
Once TCPIP has decided that it has tried to restart a server (FTPSERVE
Very simple way: set up a small Linux instance and install Nagios on it.
Configure a FTP probe in Nagios, and configure a notification to a user on the
VM system. The Nagios system will test the FTP server by connecting and
attempting to transfer a small file periodically. If it fails, it sends
Alan,
Thanks - that is great. I can work from that.
Colin Allinson
VM Systems Support
Amadeus Data Processing GmbH
David Boyes dbo...@sinenomine.net wrote:-
Very simple way: set up a small Linux instance and install Nagios on it.
Configure a FTP probe in Nagios, and configure a notification to a user on
the VM
system. The Nagios system will test the FTP server by connecting and
attempting to transfer a
On Wed, Jul 6, 2011 at 4:35 PM, David Boyes dbo...@sinenomine.net wrote:
That approach tests not only whether the server is logged in, but whether
it’s actually functioning. Works well for lots of things, and is low-cost (no
cost if you run Debian or Fedora for Z).
Depending on how the FTP
Depending on how the FTP server fails, you might also see it in your
performance monitor...
Also true. OTOH, there are failure modes (such as the one Colin mentioned about
getting unhappy with a minidisk) that won't show up in the console log or will
show misleading symptoms (large buffer
David, I am afraid we are in lock down here (essential maintenance only) so no
chance of installing a new LINUX server. However, I could use your idea from an
existing hartbeat server between VM systems.
World work, I'd think. That'd also catch the socket timeout delay problem
if/when you
Subject: Re: Two simple TCPIP / FTPSERVE questions.
Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
Very simple way: set up a small Linux instance and install Nagios on
it. Configure a FTP probe in Nagios, and configure a notification to
a user on the VM system. The Nagios system
been wearing your Linux appliance hat too long. Much lighter-weight would be a
few lines of Rexx with or without Romney's FTP package, running periodically as
a task in your automation solution or a standalone (CMS) VSM.
Perhaps. OTOH, up and usefully running in less than 10 minutes with no
I guess some more testing is required. At least i'm not the only one to
be supprised. Indeed, a pmr sounds about right at this point.
I guess a test would be pretty easy, restart (logoff/logon) one of the
TCPIP stacks and see if it produces one record. Next fiddle with NETSTAT
OBEY and see
Alan,
I think so but I'm not quite sure. We use the NETSTAT OBEY sometimes,
usually for stop or start of a link. For instance NETSTAT OBEY START DEVHW1.
Regards, Berry.
Op 13-06-11 04:01, Alan Altmark schreef:
On Fri, 10 Jun 2011 09:43:52 -0500, Berry van Sleeuwen
Hi Berry, I'm out of ideas without looking at data. You
may want to open a PMR.
Bill Bitner - z/VM Customer Focus and Care - IBM Endicott - 607-429-3286
On Monday, 06/13/2011 at 07:46 EDT, Berry van Sleeuwen
berry.vansleeu...@xs4all.nl wrote:
I think so but I'm not quite sure. We use the NETSTAT OBEY sometimes,
usually for stop or start of a link. For instance NETSTAT OBEY START
DEVHW1.
The only way I could think of to get the same record
On Fri, 10 Jun 2011 09:43:52 -0500, Berry van Sleeuwen
berry.vansleeu...@xs4all.nl wrote:
The IP stack hasn't been stopped, at least as far as I know. The last ti
me
the stacks were stopped was due to a VM IPL.
If indeed multiple buffers were created, would it make sense that the sa
me
data is
If these are the result of multiple links, I would think the link
names would be different. This is a long shot, but is it possible
that this TCP/IP stopped unexpectedly at some point in time and
was restarted without an IPL or Logoff/Logon?
The Stack identifies which buffers the CP monitor will
Hi Bill,
The IP stack hasn't been stopped, at least as far as I know. The last tim
e
the stacks were stopped was due to a VM IPL.
If indeed multiple buffers were created, would it make sense that the sam
e
data is reported in all buffers? I would expect, if new buffers were crea
ted
for the
Hi listers,
I am looking at processing the userrecords in the CP MONITOR for the TCPI
P
stacks. These are in CP MONITOR domain 0A record 02. The data is collecte
d
though a STARMON stage, basically PIPE STARMON | locate selection |
fielid.
Most LPARs have records like I'd expect them but I have
Sleeuwen
berry.vansleeu...@xs4all.nl wrote:
Hi listers,
I am looking at processing the userrecords in the CP MONITOR for the TCPIP
stacks. These are in CP MONITOR domain 0A record 02. The data is collected
though a STARMON stage, basically PIPE STARMON | locate selection |
fielid.
Most
are truly identical. That leads me to believe that these are seperatly
created records.
The record produced by the TCPIP stack contains data from the OSA
device, we are interested in the number of bytes in and out for the
device during the minute interval.
As I understand it there is a buffer
Hmmm.. some questions then:
- Are the z/VM and TCPIP levels all the same?
- Are the OSA's attached to TCPIP the same way (DEDICATE in directory, via
a DTCPARMS, or?)
- Are the OSA cards the same.. defined the same?
- Any NICDEF's defined to TCPIP on this LPAR? (though I would think
On Thursday, 06/09/2011 at 10:06 EDT, Berry van Sleeuwen
berry.vansleeu...@xs4all.nl wrote:
What can cause the CP monitor to have these duplicate records?
A type 0x05 record is, I think, produced for each LCB (Link Control Block)
in the stack. Does the OSA device have multiple LINKs?
Alan
. But for these records CPU is not an issue.
Regards, Berry.
Op 09-06-11 21:38, Scott Rohling schreef:
Hmmm.. some questions then:
- Are the z/VM and TCPIP levels all the same?
- Are the OSA's attached to TCPIP the same way (DEDICATE in
directory, via a DTCPARMS, or?)
- Are the OSA cards the same
Multiple links? You mean on the OSA or within the IP stack?
Yes, multiple links on an OSA. In LPAR1 we have one IP stack (EE00-EE02)
and a VSWITCH (EE04-EE06) on the OSA. In LPAR2 we have two IP stacks on
the same OSA (EE00--EE06). The customer stack also has a backup on a
second OSA
Hi list
I have a consistent problem starting TCPIP after a VM cold start.
As far as I can understand it's about initializing the OSA connection (cuu =
500-501)
I get
DTCPC3080I PCCA3 initializing:
DTCPRI385I Device LCS1:
DTCPRI386I Type: LCS, Status: Not started
DTCPRI387I Envelope
Are you sure that TCPIP gets its OSA addresses attached after that VM
start? (I can imagine for example that during the IPL the OSA addresses
500-501 are attached at some other guest, preventing TCPIP from getting
them).
2011/4/14 ssda...@jerusalem.muni.il
Hi list
I have a consistent problem
Hi
The addresses are dedicated in the directory.
USER TCPIPxx 32M 128M ABG
MACH ESA
OPTION QUICKDSP DIAG98 SVMSTAT APPLMON MAXCONN 1024
SHARE ABSOLUTE 15%
IPL CMS
IUCV ALLOW
IUCV ANY PRIORITY
IUCV *CCS PRIORITY MSGLIMIT 255
DEDICATE 0500 0500
DEDICATE 0501 0501
David
The DEDICATE will fail if the OSA addresses are either offline, either
already attached to some other guest.
That's why I say that you should try to know what's the status is of 500 and
501 when TCPIP doesn't start.
2011/4/14 ssda...@jerusalem.muni.il
*Hi *
*The addresses are dedicated
I then bring down TCPIP and bring it up again and it works .
This remember me a similar problem some years ago. Looks like the OSA LCS
startup needs a time to become operational greather than the TCPIP ipl.
Supposing this running on one 9672...
One circumvention was delay the TCPIP ipl
Hi David
I had those problems with RA6. It takes OSA time to load after IML. You
shuold wait till OSA is ONLINE.
Oded
בתאריך 14 באפריל 2011 10:38, מאת ssda...@jerusalem.muni.il:
Hi list
I have a consistent problem starting TCPIP after a VM cold start.
As far as I can understand it's about
XA subchan id for 500 or
0501
DTCPC3082E PCCA3 shutting down:
DTCPRI385IDevice LCS1:
DTCPRI386I Type: LCS, Status: No status available
DTCPRI387I Envelope queue size: 0
DTCPRI388I Address: 0500
I then bring down TCPIP and bring it up again and it works
/ 24 | cms | console
ping 127.0.0.1 (T 100
My goal is to verify TCPIP is up and running before I continue.
Is there a better way?
Technically, no, they are not the same. In the first example you are
pinging the primary interface. In the second case, you are pinging the
loopback address
Alan:
I have moved the COMMAND statements to the top before the INCLUDE TCPCMSU
which has DEV type statements like SPOOL, CONSOLE, LINK and it IPLs CMS.
Hopefully this is correct now.
USER TCPIP TCPIP 128M 256M ABG
COMMAND ATTACH 9400 TO * 9000
COMMAND ATTACH 9401 TO * 9001
COMMAND
TCPIPO DATA T1 V 73474 5 1/15/09
12:31:27
Hope this does not bring Chuckie out.
You're killing me, George. You're just killing me. Someone bring me my
pills.
There's nothing like having copies of config files on your own A-disk
(TCPIP
ever again touch TCPIP
PROFILE EXEC or mess with IBM DTCPARMS.
Education should not be, but often is, a painful process.
Your counsel and advice are beyond measure.
tyvm
Alan Altmark alan_altm...@us.ibm.com
Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
02/23/2011 01:15 PM
Alan:
OSAs 9000,1,2 are changing to OSAs 9400,1,2.when we install the z196.
To restore our TCPIP PROFILE EXEC to its original state we should delete
all the attaches, not just the 9000,1,2 which are changing and put them
all in either the TCPIP DIRECTORY entry or DTCPARMS.
A question came up
On Wednesday, 02/23/2011 at 05:11 EST, George Henke/NYLIC
george_he...@newyorklife.com wrote:
OSAs 9000,1,2 are changing to OSAs 9400,1,2.when we install the z196.
To restore our TCPIP PROFILE EXEC to its original state we should delete
all
the attaches, not just the 9000,1,2 which
I have to change some DEV ATTACHes in our TCPIP PROFILE Exec in
preparation for new OSA ADDRs in our IODF for our new z/196.
What is the best way to implement this?
I suppose I can logon to TCPIP AC ( noprof and create a backup copy of the
PROFILE EXEC and then change the original DEV ADDRs
ATTACHES can be done in file yournode DTCPARMS or SYSTEM DTCPAMRS on
TCPMAINT 198.
*They shall never modify a PROFILE EXEC on TCPIP 191, it's IBM property;-)*
And, for dynamic changes there is the CP ATTACH command and an OBEYFILE
command.
2011/2/22 George Henke/NYLIC george_he
On Tuesday, 02/22/2011 at 04:59 EST, George Henke/NYLIC
george_he...@newyorklife.com wrote:
I have to change some DEV ATTACHes in our TCPIP PROFILE Exec in
preparation for
new OSA ADDRs in our IODF for our new z/196.
What is the best way to implement this?
I suppose I can logon
tyvm, Alan and Kris, once again for saving my neck.
DEV 9000, 9001, 9002 are changing to 9400, 9401, 9402
Here is what I have now:
TCPIP: PROFILE EXEC
'Access 198 D'
'Access 591 E'
'Access 592 F'
ATT 9000 TCPIP 9000
ATT 9001 TCPIP 9001
ATT 9002 TCPIP 9002
ATT 9100 TCPIP 9100
ATT 9101
On Tuesday, 02/22/2011 at 06:00 EST, George Henke/NYLIC
george_he...@newyorklife.com wrote:
DEV 9000, 9001, 9002 are changing to 9400, 9401, 9402
Here is what I have now:
TCPIP: PROFILE EXEC
'Access 198 D'
'Access 591 E'
'Access 592 F'
ATT 9000 TCPIP 9000
ATT
You probably have those :owner. tags in there for the console log. Do
yourself a favor and just put a TCPRUNXT EXEC on TCPMAINT 198 that defines a
common owner. Then you can remove those extra entries. Here is an example:
/* TCPIP Startup Exit TCPRUNXT EXEC
Jones d...@vsoft-software.com
wrote:
Yes, it can, George, no problem.
DJ
On 10/11/2010 8:36 AM, George Henke/NYLIC wrote:
Can TCPIP and VSWITCH, though isolated from Level 1, (as indicated by
Brian Nielsen below) still be functional at Level 2 to shake down TCP
IP
maintenance before
Can TCPIP and VSWITCH, though isolated from Level 1, (as indicated by
Brian Nielsen below) still be functional at Level 2 to shake down TCPIP
maintenance before rolling it up to Level 1?
Everything at Level 2 is a clone except VOLSERs.
Brian Nielsen wrote:
For TCP, what happens depends
Yes, it can, George, no problem.
DJ
On 10/11/2010 8:36 AM, George Henke/NYLIC wrote:
Can TCPIP and VSWITCH, though isolated from Level 1, (as indicated by
Brian Nielsen below) still be functional at Level 2 to shake down TCPIP
maintenance before rolling it up to Level 1?
Everything at Level 2
Just attach a set of OSA triplets to your 2nd level guest for the VSWITCH.
On Mon, Oct 11, 2010 at 9:41 AM, Dave Jones d...@vsoft-software.com wrote:
Yes, it can, George, no problem.
DJ
On 10/11/2010 8:36 AM, George Henke/NYLIC wrote:
Can TCPIP and VSWITCH, though isolated from Level 1
Greetings,
Is there a way to dynamically refresh the definitions in the PROFILE TCPI
P
file without bouncing the TCPIP address space on z/VM 5.4 with TCPIP 5.4?
In particular, I want to activate and setup the MONITORRECORDS statement.
Thanks.
Regards,
Steve.
On Mon, 27 Sep 2010 17:42:11 -0500, Steve Perez sspe...@corelogic.com w
rote:
Greetings,
Is there a way to dynamically refresh the definitions in the PROFILE TCP
IP
file without bouncing the TCPIP address space on z/VM 5.4 with TCPIP 5.4
?
Yes, read up on the TCP/IP OBEYFILE command
AMEN. My father is retired IBMer and we moved a lot.
My stint with IBM was to short to have been moved.
On Wed, Sep 15, 2010 at 11:16 PM, Jim Bohnsack jab...@cornell.edu wrote:
IBM-I've Been Moved---even if not relocated.
Jim
On 9/15/2010 9:28 PM, Chip Davis wrote:
And I guess Scott
] On
Behalf Of Scott Rohling
Sent: Wednesday, September 15, 2010 7:30 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VSM - TCPIP
Ok - #1 helps a little (but I'm assuming a real user can end up by
itself on a line too) - #2 a bit more (yes, sneaky) - #3 even more, but
probably going a little far unless
.
--
*From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On
Behalf Of *Scott Rohling
*Sent:* Wednesday, September 15, 2010 7:30 PM
*To:* IBMVM@LISTSERV.UARK.EDU
*Subject:* Re: VSM - TCPIP
Ok - #1 helps a little (but I'm assuming a real user can end
Of *Scott Rohling
*Sent:* Wednesday, September 15, 2010 7:30 PM
*To:* IBMVM@LISTSERV.UARK.EDU
*Subject:* Re: VSM - TCPIP
Ok - #1 helps a little (but I'm assuming a real user can end up by itself
on a line too) - #2 a bit more (yes, sneaky) - #3 even more, but probably
going a little far unless
You should use nfind VSM_- to make sure you don't match a userid that
starts with VSM that happens to be logged in via a VSM machine. Remember
that pipeline find uses a blank to match any character, and an underscore
to match a blank. In this case, you want to make sure blanks follow VSM.
Part of my LISTSG tool is USERLIST, displays the user of users in a FILELIST
fashion
http://www.vm.ibm.com/download/packages/descript.cgi?LISTSG
*USERLIST * -- list everyone
*USERLIST LIN** -- list users starting with LIN
*USERLIST CP Q NSS USERS CMS|drop 2|Split* -- lists all users that use
Just wondering if anyone else sees the value in finding VSM - TCPIP as
an entry when doing a 'CP QUERY NAMES'. This is described as being the
users of the VTAM service machine ... As someone who often writes system
utilities which do a QUERY NAMES to find the active users - this is always
the value in finding VSM -
TCPIP as an
entry when doing a 'CP QUERY NAMES'.
I do, I do!
This is described as being the users of
the VTAM service machine ... As someone who often writes system
utilities
which do a QUERY NAMES to find the active users - this is always
something I
On Wednesday, 09/15/2010 at 07:46 EDT, Scott Rohling
scott.rohl...@gmail.com wrote:
Ok - so this is about linemode sessions. And yeah - I get the crickets
- who
the heck uses linemode? I suppose it fits. I always have a grin on
my face
when I explain virtual reader/punch/printer to
On 09/15/2010 05:57 PM, Alan Altmark wrote:
Alan Altmark
z/VM Development (T minus 05h 05m 42s and counting...)
IBM Endicott
Hours? How time flies...
--
Rich Smrcina
Velocity Software, Inc.
Mobile: 414-491-6001
Office: 262-392-3717
http://www.velocitysoftware.com
Catch the WAVV!
Ok - #1 helps a little (but I'm assuming a real user can end up by itself on
a line too) - #2 a bit more (yes, sneaky) - #3 even more, but probably
going a little far unless I'm going for 6 Sigma or something :-)
Probably will stick with tossing VSM user cuz I'm a lazy old cuss.
The good news
And I guess Scott has the honor of the last IBMVM problem solved by
Alan as a developer... :-/
I hope Alan enjoys the deeper, more direct experience he's going to
have with us. If it weren't for all the traveling...
-Chip-
On 9/16/10 00:30 Scott Rohling said:
Ok - #1 helps a little (but
IBM-I've Been Moved---even if not relocated.
Jim
On 9/15/2010 9:28 PM, Chip Davis wrote:
And I guess Scott has the honor of the last IBMVM problem solved by
Alan as a developer... :-/
I hope Alan enjoys the deeper, more direct experience he's going to
have with us. If it weren't for all the
I'm creating a second TCPIP machine and am having trouble accessing the 191
mdisk to format it from MAINT.
My USER DISKMAP is updated and active:
TCPIPV 191 3390 08222 08226 5
I'm able to link to it using: LINK TCPIPV 191 291 SR, but the access command
returns
: Second TCPIP MDISK 191 Format
Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
I?m creating a second TCPIP machine and am having trouble accessing
the 191 mdisk to format it from MAINT.
My USER DISKMAP is updated and active:
TCPIPV 191 3390 08222 08226
Has the minidisk been formatted?
On Wed, Sep 1, 2010 at 12:39 PM, Lesseg, Jon jon.les...@pacificorp.comwrote:
I’m creating a second TCPIP machine and am having trouble accessing the
191 mdisk to format it from MAINT.
My USER DISKMAP is updated and active:
TCPIPV 191 3390
: Wednesday, September 01, 2010 9:44 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Second TCPIP MDISK 191 Format
Need to do the FORMAT 291 R command.
Can't access a minidisk if it hasn't been formatted.
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 09/01/2010
12:39:50 PM:
From
Scott,
If you have permissions, you could
NETSTAT CP SPOOL CONSOLE CLOSE
The reason what you tried didn't work is that you should have specified
CP SEND CP TCPIP SPOOL CONSOLE CLOSE
Mark Wheeler
UnitedHealth Group
--
Excellence. Always. If Not Excellence, What? If Not Excellence
Hi,
I use 'CP SEND CP TCPIP CLOSE CONS'
No need to set SECUSER.
It was configured into PROP as part of the Midnight process (HCPMID6001I
msg) , to close all consoles daily.
Regards, Clovis.
|
| From
See FOR command.
Frank M. Ramaekers Jr.
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf
Of Wandschneider, Scott
Sent: Wednesday, August 18, 2010 2:21 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Closing the console on TCPIP
Does
What about FOR TCPIP CMD CP CLOSE CON? No need for SET SECUSER.
Frank M. Ramaekers Jr.
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of gclo...@br.ibm.com
Sent: Wednesday, August 18, 2010 2:36 PM
To: IBMVM
Perfect Mark – That’s what I needed – Thank you!
Thank you,
Scott
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf
Of Mark Wheeler
Sent: Wednesday, August 18, 2010 2:37 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Closing the console on TCPIP
Scott
Thank you to all who responded – I do appreciate it.
Thank you,
Scott
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf
Of Miguel Delapaz
Sent: Wednesday, August 18, 2010 2:37 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Closing the console on TCPIP
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Closing the console on TCPIP
What about FOR TCPIP CMD CP CLOSE CON? No need for SET SECUSER.
Frank M. Ramaekers Jr.
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf
Of gclo
Frank:
FOR needs an aditional setup. Or you will get the HCP070E msg.
My test:
FOR TCPIP CMD CP CLOSE CON
HCPFOR070E You are not authorized to act FOR TCPIP
Maint(00070); T=0.01/0.01 17:09:42
m op cmd for TCPIP CMD CP CLOSE CON
Maint; T=0.01/0.01 17:09:49
HCPFOR070E You are not authorized
] On Behalf
Of gclo...@br.ibm.com
Sent: Wednesday, August 18, 2010 1:06 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Closing the console on TCPIP
Frank:
FOR needs an aditional setup. Or you will get the HCP070E msg.
My test:
FOR TCPIP CMD CP CLOSE CON
HCPFOR070E You are not authorized to act
On Wednesday, 08/18/2010 at 04:04 EDT, Schuh, Richard rsc...@visa.com
wrote:
All of the commands except for NETSTAT require command class
authorization,
class C is the common denominator.
Not quite true. If you have RACF, then all you need to use the FOR
command is LOGON BY authority to
: Wednesday, August 18, 2010 1:59 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Closing the console on TCPIP
On Wednesday, 08/18/2010 at 04:04 EDT, Schuh, Richard
rsc...@visa.com
wrote:
All of the commands except for NETSTAT require command class
authorization,
class C is the common
Hello, Everyone.
We are in the planning stages for the first disaster recovery test of our
new z/VM environment. This test will be done at an offsite vender
location. While discussing our requirements, the topic of TCPIP addresse
s
came up. Since the addresses at the offsite location
The DR vendor should provide you with some 3270 terminals where you
can logon as TCPMAINT (Or whatever user id you use) and then make
changes to the TCPIP Profile.
Billy
On 12 Aug 2010 at 10:13, McDonough, George wrote:
Hello, Everyone.
We are in the planning stages for the first
OSA's for test and real DR. For the stack, it copies a DR
version of PROFILE TCPIP to TCPIP 191. For MPROUTE, it returns :Config. with
the name of the appropriate MPROUTE CONFIG file. We don't use SYSTEM NETID or
SYSTEM CONFIG to change the node name for DR, because we have things
-Original Message-
From: David Boyes [mailto:dbo...@sinenomine.net]
Sent: Thursday, August 12, 2010 11:34 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Disaster Recovery TCPIP Address Issue
location. While discussing our requirements, the topic of TCPIP addresses
came up. Since the addresses
All fine ideas that will work for a DR test running with DR test IP
addresses (from the DR vendor's LAN?) whilst your real system remains up.
If the disaster happens, will your real DR invocation system run with the DR
vendor's LAN addresses? If so, how will your live TCPIP clients find your
employer's.
Bauer, Bobby (NIH/CIT) [E] baue...@mail.nih.gov
Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
08/12/2010 11:10 AM
Please respond to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: Disaster Recovery TCPIP Address
Would this be done with the SYSTEM_IDENTIFIER statement in the SYSTEM CONFIG
For the SYSTEM CONFIG changes, yes. for SYSTEM NETID, you need to make the
changes on MAINT 490 and then DDR 490 to 190. Note: disruptive, so do during a
maintenance window.
and if so, how do I find my current
: |
|
--|
|Re: Disaster Recovery TCPIP Address Issue
Why should changing the SYSTEM NETID on 190 have to be disruptive? Make
the change to that file only and do a SAVESYS CMS. To keep things in
step, copy the new SYSTEM NETID to 490 with OLDD. Anything that's using
SYSTEM NETID will still be seeing the old info but that old file
relates to
On Thursday, 08/12/2010 at 05:14 EDT, Jim Bohnsack jab...@cornell.edu
wrote:
Why should changing the SYSTEM NETID on 190 have to be disruptive? Make
the change to that file only and do a SAVESYS CMS. To keep things in
step, copy the new SYSTEM NETID to 490 with OLDD. Anything that's using
Yeah, I know he said DDR, but note that I said Make the change to that
file only. Maybe I should have said Make the change to that file only
rather than using DDR, but I figured that David's a big boy now. Glad
to hear that there is to be an expected improvement to PUT2PROD.
Jim
On
Alan is easily distracted... it's almost like someone else was at the
keyboard...
On 08/12/2010 04:26 PM, Alan Altmark wrote:
Pt. Hey, Buddy. Over here. No, over *here*. It' me. Yes, you know
who. Wanna know a secret? They (please, no names) are planning to update
PUT2PROD in the
Hi,
I have defined my TCPIP over an Layer2 VSWITCH and it is working,
but the netstat home command doesnt show the connected VSWITCH.
netstat home
VM TCP/IP Netstat Level 610 TCP/IP Server Name: TCPIP
IPv4 Home address entries:
Address Subnet Mask Link VSWITCH
Hi Alexander,
I noticed that as well. I found out that the NETSTAT HOME will only display
the switch name if it has coded on the relevant HOME statement in your TCPIP
profile.
Regards,
Paul Garment
_
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu
information, see Configuring an SNMP Subagent for a
Virtual Switch in z/VM: Connectivity.
Ciao,
Stefan
On 08/11/2010 10:55 AM, Riedel, Alexander wrote:
Hi,
I have defined my TCPIP over an Layer2 VSWITCH and it is working,
but the netstat home command doesnt show the connected VSWITCH
Can anyone share their profile tcpip and dtcparms file to accomplish this two
stack setup? Can I share the same OSA address 9800-9802 or do I have to define
3 more? And any holes I am going to fall in?
-Original Message-
From: The IBM z/VM Operating System [mailto:ib
...@bcbst.comwrote:
Can anyone share their profile tcpip and dtcparms file to accomplish this
two stack setup? Can I share the same OSA address 9800-9802 or do I have to
define 3 more? And any holes I am going to fall in?
-Original Message-
From: The IBM z/VM Operating System [mailto:ib
Also, if the VSwitch is participating in failover that capability is automatically
available to the TCP/IP stack.
On 08/03/2010 02:21 PM, Mark Pace wrote:
You can not share the same triplet, you will need another triplet. However, I would
suggest putting your stacks on a vswitch and giving
How can I remotely bounce TCPIP without using by HMC? I want to send a
command, say from maint, that would shut it down and subsequently bring it back.
David M. Dean
Information Systems
BlueCross BlueShield Tennnessee
-
Please see
2074 or OSA-ICC access?
On Fri, Jul 30, 2010 at 11:58 AM, Dean, David (I/S) david_d...@bcbst.comwrote:
How can I remotely bounce TCPIP without using by HMC? I want to send a
command, say from maint, that would shut it down and subsequently bring it
back.
David M. Dean
Information
OSA
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf
Of Mark Pace
Sent: Friday, July 30, 2010 12:00 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ipl tcpip
2074 or OSA-ICC access?
On Fri, Jul 30, 2010 at 11:58 AM, Dean, David (I/S
If I need to get on our system without TCPIP I connect via the OSA-ICC, then
I look like a local-nonsna terminal. Bounce TCPIP and then reconnect using
TCPIP.
On Fri, Jul 30, 2010 at 12:02 PM, Dean, David (I/S) david_d...@bcbst.comwrote:
OSA
--
*From
I think you have two choices here, David.
1) log onto your z/VM system via another path other than TCP/IP, e.g., a
locally attached 3270 or OSA ICC.
2) use a utility like AUDITOR (included with z/VM) to automatically
xautolog TCPIP after you have forced it off. Of course, this will
disrupt
1 - 100 of 485 matches
Mail list logo
