I won't say that this is perfect, but it has worked in the rare cases that 
I needed to logoff/logon TCP on one system with no VTAM or alternate TCPIP 
stack.   I executed it from MAINT, with authorization changes any such 
authorized ID could execute it.

Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.

/* Usually run this from MAINT */ 
   address COMMAND 
   If 1=2 then trace i         /* An easy way to turn trace on|off  */
 
  'CP SPOOL CONSOLE * START'   /* Keep "hysterical" documentation   */
  'IDENTIFY'                   /* Show ID, node, date/time          */
  'CP DISC'                    /* MAINT probably loses access anyway*/
   msg='beginning TCPIP stack bounce.' 
   say time() msg 
  'CP MSG OP' msg 
  'CP MSG TCPIP' msg 
  'CP TERMINAL TIMESTAMP ON' 
  'CP SET OBSERVER TCPIP' userid()  /* So this ID logs what happens */
   cmd='EXEC NETSTAT CP EXTERNAL' 
   cmd                  /* 1st: EXEC NETSTAT CP EXTERNAL */ 
   say cmd 'rc='rc 
  'CP SLEEP  5 SEC'     /* Time for TCPIP to respond to CP EXTERNAL */
   say cmd 
   cmd                  /* 2nd: EXEC NETSTAT CP EXTERNAL */ 
   say cmd 'rc='rc 
  'CP QUERY NAMES'      /* Any effect yet? */ 
 
   cmd='CP FORCE TCPIP' 
   cmd 
   say cmd 'rc='rc 
  'CP SLEEP 5 SEC' 
  'CP QUERY TCPIP'      /* Prove TCPIP is fully off - or not        */
  'CP QUERY NAMES'      /* Prove TCPIP is fully off - or not        */
 
/* XAUTOLOG TCPIP requirement: In TCPIP direct: XAUTOLOG MAINT      */
/*                             or other ESM authorization.          */
   cmd='CP XAUTOLOG TCPIP' 
   cmd 
   src=rc 
   say cmd 'rc='src  
  'CP SLEEP 2 SEC'    /* Time for TCPIP stack to start?             */
  'CP QUERY NAMES'    /* Show: VSM - TCPIP                          */
Exit src                                                                   
 




"Kris Buelens" <kris.buel...@gmail.com> 

Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
07/30/2010 01:03 PM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: ipl tcpip






This may be a bit too easy.  I think I've been bitten by such a thing 
once: the fact that you FORCE TCPIP sets you "forced disconnect" and you 
may put your user in CP read or such... You better should be disconnected 
first:
So an EXEC:
 /* */ address command
 'CP DISC'
 'CP FORCE TCPIP'
 'CP SLEEP 2 SEC'
 'CP XAUTOLOG TCPIP'
You could test this first with for example EREP and than logon to EREP to 
see if if yet a Reconnected message (then a #CP IND USER EREP EXT to check 
the connect time: it should be very short.

And then, if you do it with TCPIP: keep your fingers crossed.

2010/7/30 Marcy Cortes <marcy.d.cor...@wellsfargo.com>
You can take your chances that the config is fine and tcp/ip will come 
back up and do this:

#cp force tcpip#cp sleep 2 sec#cp autolog tcpip

Most of us I think run a second stack for just such fun.  It's easy enough 
to set up.

Marcy

"This message may contain confidential and/or privileged information. If 
you are not the addressee or authorized to receive this for the addressee, 
you must not use, copy, disclose, or take any action based on this message 
or any information herein. If you have received this message in error, 
please advise the sender immediately by reply e-mail and delete this 
message. Thank you for your cooperation."


-----Original Message-----
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On 
Behalf Of Dave Jones
Sent: Friday, July 30, 2010 9:27 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] ipl tcpip

AUDITOR is documented here:

z/VM V5R4.0 CMS Commands and Utilities Reference
(
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HCSD8B30/CCONTENTS?SHELF=hcsh2aa1&DN=SC24-6073-03&DT=20080630160548
)



On 07/30/2010 11:27 AM, Dean, David (I/S) wrote:
> Thanks, I will take a look at auditor; the temporary TCPIP outage is not 
a problem.  I have no way other than TCPIP to connect without physically 
going into our Secure Area where the HMC lives.
>
> -----Original Message-----
> From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On 
Behalf Of Dave Jones
> Sent: Friday, July 30, 2010 12:16 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: ipl tcpip
>
> 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 your TN3270 session for the length of time it takes for TCPIP to
> come back up.
>
> Have a good one.
>
> On 07/30/2010 10:58 AM, Dean, David (I/S) wrote:
>> 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 the
>> following link for the BlueCross BlueShield of Tennessee E-mail
>> disclaimer:  http://www.bcbst.com/email_disclaimer.shtm
>>
>

--
Dave Jones
V/Soft
www.vsoft-software.com
Houston, TX
281.578.7544



-- 
Kris Buelens,
IBM Belgium, VM customer support



The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited. All messages 
sent to and from this e-mail address may be monitored as permitted by 
applicable law and regulations to ensure compliance with our internal policies 
and to protect our business. E-mails are not secure and cannot be guaranteed to 
be error free as they can be intercepted, amended, lost or destroyed, or 
contain viruses. You are deemed to have accepted these risks if you communicate 
with us by e-mail. 


Reply via email to