Restart of TCPIP function servers when TCPIP is recycled

[Colin Allinson]

Over the weekend a LAN problem resulted in TCPIP getting hung up on 3 of 
our systems and a recycle of TCPIP was necessary to resolve the issue.

On 2 of the systems we had no issue but, on a 3rd, we had a subsequent 
issue with NAMESRV needing a separate manual recycle of that server.

When I look at the console of TCPIP startup I see :-

DTCIPI030W StartANewLife: Victim NAMESRV, reason "Restarting you 
because TCP/IP has been restarted"
HCPLGA054E Already logged on disconnected

and, sure enough, NAMESRV was not restarted. I see the same for all 3 
systems but, I guess, NAMESRV survived without problems on the other 2 but 
got hung up on this system.

This leads me to the following questions:-
- Should TCPIP force it's application servers before starting them - and, 
if so, what might I have configured incorrectly?
- If not, what would be the best place to insert commands to force these 
off when TCPIP is started to ensure a clean start up?


Colin Allinson

Amadeus Data Processing GmbH

Re: Restart of TCPIP function servers when TCPIP is recycled

[Imler, Steven J]

I thought it/TCPIP did do a FORCE when it finds a server already logged
on when it tries to "StartANewLife"?

 

 

JR (Steven) Imler

CA

Senior Sustaining Engineer

Tel: +1 703 708 3479

[EMAIL PROTECTED]  

 

 

 

From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Colin Allinson
Sent: Monday, August 25, 2008 08:09 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Restart of TCPIP function servers when TCPIP is recycled

 


Over the weekend a LAN problem resulted in TCPIP getting hung up on 3 of
our systems and a recycle of TCPIP was necessary to resolve the issue. 

On 2 of the systems we had no issue but, on a 3rd, we had a subsequent
issue with NAMESRV needing a separate manual recycle of that server. 

When I look at the console of TCPIP startup I see :- 

DTCIPI030W StartANewLife: Victim NAMESRV, reason "Restarting you
because TCP/IP has been restarted" 
HCPLGA054E Already logged on disconnected 

and, sure enough, NAMESRV was not restarted. I see the same for all 3
systems but, I guess, NAMESRV survived without problems on the other 2
but got hung up on this system. 

This leads me to the following questions:- 
- Should TCPIP force it's application servers before starting them -
and, if so, what might I have configured incorrectly? 
- If not, what would be the best place to insert commands to force these
off when TCPIP is started to ensure a clean start up? 


Colin Allinson

Amadeus Data Processing GmbH

Installing z/VM 5.3

[Xavier Corray]

Hi Folks - Having laid off VM for 18 years, I would put myself back into the
ranks of a newbie.  So, please bear with me.

 

Am trying to load z/VM 5.3 - loading from DVD pointing to g:/530vm.ins.

After a status=SUCCESS is achieved, the Integrated 3270 Console remains
blank with

a green cursor at the top left corner.

 

Is there a further IPL step and if so, where is that issued from ?  Any help
is appreciated.

 

Regards 
Xavier Corray

Re: Restart of TCPIP function servers when TCPIP is recycled

[Schuh, Richard]

Is TCPIP properly authorized to force its friends? That is a class A
command.
 

Regards, 
Richard Schuh 

 

 




From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Imler, Steven J
Sent: Monday, August 25, 2008 5:15 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Restart of TCPIP function servers when TCPIP is
recycled



I thought it/TCPIP did do a FORCE when it finds a server already
logged on when it tries to "StartANewLife"?

 

 

JR (Steven) Imler

CA

Senior Sustaining Engineer

Tel: +1 703 708 3479

[EMAIL PROTECTED]  

 

 

 

From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Colin Allinson
Sent: Monday, August 25, 2008 08:09 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Restart of TCPIP function servers when TCPIP is
recycled

 


Over the weekend a LAN problem resulted in TCPIP getting hung up
on 3 of our systems and a recycle of TCPIP was necessary to resolve the
issue. 

On 2 of the systems we had no issue but, on a 3rd, we had a
subsequent issue with NAMESRV needing a separate manual recycle of that
server. 

When I look at the console of TCPIP startup I see :- 

DTCIPI030W StartANewLife: Victim NAMESRV, reason "Restarting
you because TCP/IP has been restarted" 
HCPLGA054E Already logged on disconnected 

and, sure enough, NAMESRV was not restarted. I see the same for
all 3 systems but, I guess, NAMESRV survived without problems on the
other 2 but got hung up on this system. 

This leads me to the following questions:- 
- Should TCPIP force it's application servers before starting
them - and, if so, what might I have configured incorrectly? 
- If not, what would be the best place to insert commands to
force these off when TCPIP is started to ensure a clean start up? 


Colin Allinson

Amadeus Data Processing GmbH

Re: Where Do I Go From Here?

[Edward M. Martin]

Should it really be Noli nothis permittere te terere

 

Ed Martin

Aultman Health Foundation

330-588-4723

ext 40441



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Schuh, Richard
Sent: Friday, August 22, 2008 2:24 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?

 

Dave Wade said "Illegitimi Non Carborundum"

 

After so many years of abrasion, your skin gets thinner. I do not suffer
fools nearly as well as I once did.

 

Regards, 
Richard Schuh 

 

 

Re: Restart of TCPIP function servers when TCPIP is recycled

[Kris Buelens]

If TCPIP were not authorized, he wouldn't have gotten: HCPLGA054E
Already logged on disconnected.

Maybe the server was being watched (and restarted) by some other
service machine.  I.e.  TCPIP forces it, the other watcher restarts it
before TCPIP does.  Check the system console.

2008/8/25 Schuh, Richard <[EMAIL PROTECTED]>
>
> Is TCPIP properly authorized to force its friends? That is a class A command.
>
>
> Regards,
> Richard Schuh
>
>
>
>
>
> 
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of 
> Imler, Steven J
> Sent: Monday, August 25, 2008 5:15 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Restart of TCPIP function servers when TCPIP is recycled
>
> I thought it/TCPIP did do a FORCE when it finds a server already logged on 
> when it tries to "StartANewLife"?
>
>
>
>
>
> JR (Steven) Imler
>
> CA
>
> Senior Sustaining Engineer
>
> Tel: +1 703 708 3479
>
> [EMAIL PROTECTED]
>
>
>
>
>
>
>
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of 
> Colin Allinson
> Sent: Monday, August 25, 2008 08:09 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Restart of TCPIP function servers when TCPIP is recycled
>
>
>
> Over the weekend a LAN problem resulted in TCPIP getting hung up on 3 of our 
> systems and a recycle of TCPIP was necessary to resolve the issue.
>
> On 2 of the systems we had no issue but, on a 3rd, we had a subsequent issue 
> with NAMESRV needing a separate manual recycle of that server.
>
> When I look at the console of TCPIP startup I see :-
>
> DTCIPI030W StartANewLife: Victim NAMESRV, reason "Restarting you because 
> TCP/IP has been restarted"
> HCPLGA054E Already logged on disconnected
>
> and, sure enough, NAMESRV was not restarted. I see the same for all 3 systems 
> but, I guess, NAMESRV survived without problems on the other 2 but got hung 
> up on this system.
>
> This leads me to the following questions:-
> - Should TCPIP force it's application servers before starting them - and, if 
> so, what might I have configured incorrectly?
> - If not, what would be the best place to insert commands to force these off 
> when TCPIP is started to ensure a clean start up?
>
>
> Colin Allinson
>
> Amadeus Data Processing GmbH


--
Kris Buelens,
IBM Belgium, VM customer support

Re: Restart of TCPIP function servers when TCPIP is recycled

[Schuh, Richard]

That has nothing to do with FORCE, it is a response to the XAUTOLOG
command. XAUTOLOG can be class A, B, or G, or it can be controlled by
the ESM. 


Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens
> Sent: Monday, August 25, 2008 8:47 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Restart of TCPIP function servers when TCPIP is recycled
> 
> If TCPIP were not authorized, he wouldn't have gotten: 
> HCPLGA054E Already logged on disconnected.
> 
> Maybe the server was being watched (and restarted) by some 
> other service machine.  I.e.  TCPIP forces it, the other 
> watcher restarts it before TCPIP does.  Check the system console.
> 
> 2008/8/25 Schuh, Richard <[EMAIL PROTECTED]>
> >
> > Is TCPIP properly authorized to force its friends? That is 
> a class A command.
> >
> >
> > Regards,
> > Richard Schuh
> >
> >
> >
> >
> >
> > 
> > From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED] 
> > On Behalf Of Imler, Steven J
> > Sent: Monday, August 25, 2008 5:15 AM
> > To: IBMVM@LISTSERV.UARK.EDU
> > Subject: Re: Restart of TCPIP function servers when TCPIP 
> is recycled
> >
> > I thought it/TCPIP did do a FORCE when it finds a server 
> already logged on when it tries to "StartANewLife"?
> >
> >
> >
> >
> >
> > JR (Steven) Imler
> >
> > CA
> >
> > Senior Sustaining Engineer
> >
> > Tel: +1 703 708 3479
> >
> > [EMAIL PROTECTED]
> >
> >
> >
> >
> >
> >
> >
> > From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED] 
> > On Behalf Of Colin Allinson
> > Sent: Monday, August 25, 2008 08:09 AM
> > To: IBMVM@LISTSERV.UARK.EDU
> > Subject: Restart of TCPIP function servers when TCPIP is recycled
> >
> >
> >
> > Over the weekend a LAN problem resulted in TCPIP getting 
> hung up on 3 of our systems and a recycle of TCPIP was 
> necessary to resolve the issue.
> >
> > On 2 of the systems we had no issue but, on a 3rd, we had a 
> subsequent issue with NAMESRV needing a separate manual 
> recycle of that server.
> >
> > When I look at the console of TCPIP startup I see :-
> >
> > DTCIPI030W StartANewLife: Victim NAMESRV, reason 
> "Restarting you because TCP/IP has been restarted"
> > HCPLGA054E Already logged on disconnected
> >
> > and, sure enough, NAMESRV was not restarted. I see the same 
> for all 3 systems but, I guess, NAMESRV survived without 
> problems on the other 2 but got hung up on this system.
> >
> > This leads me to the following questions:-
> > - Should TCPIP force it's application servers before 
> starting them - and, if so, what might I have configured incorrectly?
> > - If not, what would be the best place to insert commands 
> to force these off when TCPIP is started to ensure a clean start up?
> >
> >
> > Colin Allinson
> >
> > Amadeus Data Processing GmbH
> 
> 
> --
> Kris Buelens,
> IBM Belgium, VM customer support
> 

Re: Where Do I Go From Here?

[Phil Tully]

*http://en.wikipedia.org/wiki/Illegitimi_non_carborundum*

Edward M. Martin wrote:


Should it really be /Noli nothis permittere te terere/

 


Ed Martin

Aultman Health Foundation

330-588-4723

ext 40441



*From:* The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
*On Behalf Of *Schuh, Richard

*Sent:* Friday, August 22, 2008 2:24 PM
*To:* IBMVM@LISTSERV.UARK.EDU
*Subject:* Re: Where Do I Go From Here?

 


Dave Wade said "Illegitimi Non Carborundum"

 

After so many years of abrasion, your skin gets thinner. I do not 
suffer fools nearly as well as I once did.


 


Regards,
Richard Schuh

 

 



--
'in media stat virtus'
Virtue's in the middle

Re: Where Do I Go From Here?

[Schuh, Richard]

Depends on whether you are trying to be correct and not understood, or
just understood, by the masses who do not speak Latin. Who among those
of us who do not speak Latin would ever be able to decipher, "Noli
nothis permittere te terere"?   
 
Wasn't  "Illegitimi non Carborundum" originally intended to be humorous?

Regards, 
Richard Schuh 

 

 




From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin
Sent: Monday, August 25, 2008 8:37 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?



Should it really be Noli nothis permittere te terere

 

Ed Martin

Aultman Health Foundation

330-588-4723

ext 40441





From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard
Sent: Friday, August 22, 2008 2:24 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?

 

Dave Wade said "Illegitimi Non Carborundum"

 

After so many years of abrasion, your skin gets thinner. I do
not suffer fools nearly as well as I once did.

 

Regards, 
Richard Schuh 

 

 

Re: Where Do I Go From Here?

[David Boyes]

Who among those of us who do not speak Latin 

 

Bloody barbarians. They don't speak Greek either! 8-)

 

 

"So before you go on about the "bloody Romans", don't you forget...
you're one of 'em!"

   -- "Not the Messiah, He's a Very Naughty Boy!"

IUCV - What's wrong with this picture?

[Gary M. Dennis]

Assumptions:

0. A VM server machine

1. A cluster of client virtual machines (possibly thousands)

2. n buffers are allocated for each client virtual machine

3. Each buffer contains table elements that require
(a) Element ageing
(b) Element deletion when invalidated by:
1. lack of use
2. client machine request
(c) Compression as buffer fragmentation occurs

4. Each client virtual machine in the cluster is connected via IUCV to the
server virtual machine.

5. IUCV traffic between the server machine and client machine is extremely
low volume.  Initial call, termination call, intermittent statistics call.

6. After the initial call, the server virtual machine will maintain the
buffer table entries in each client virtual machine without additional IUCV
interaction.

Now the questions:

1. Does IUCV infrastructure overhead specifically associated with number of
connections become prohibitive at some well known point?

2. Has anyone had experience with an application having a high IUCV
connection count like this? If so, what was that experience?

Again, the traffic incidence per connection is very low but the number of
connections is potentially very high.


Thanks 


--.  .-  .-.  -.--

Gary Dennis

Re: Where Do I Go From Here?

[Dave Wade]

It still is... (meant to be humorous)

 

Dave Wade G4UGM

Illegitimi Non Carborundum

 

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Schuh, Richard
Sent: 25 August 2008 17:20
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?

 

Depends on whether you are trying to be correct and not understood, or just
understood, by the masses who do not speak Latin. Who among those of us who
do not speak Latin would ever be able to decipher, "Noli nothis permittere
te terere"?   

 

Wasn't  "Illegitimi non Carborundum" originally intended to be humorous?

Regards, 
Richard Schuh 

 

 

 


  _  


From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Edward M. Martin
Sent: Monday, August 25, 2008 8:37 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?

Should it really be Noli nothis permittere te terere

 

Ed Martin

Aultman Health Foundation

330-588-4723

ext 40441


  _  


From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Schuh, Richard
Sent: Friday, August 22, 2008 2:24 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?

 

Dave Wade said "Illegitimi Non Carborundum"

 

After so many years of abrasion, your skin gets thinner. I do not suffer
fools nearly as well as I once did.

 

Regards, 
Richard Schuh 

 

 

Re: Where Do I Go From Here?

[Schuh, Richard]

In fact it is not even real Latin, it is pseudo Latin.
 

Regards, 
Richard Schuh 

 

 




From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Dave Wade
Sent: Monday, August 25, 2008 10:49 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?



It still is. (meant to be humorous)

 

Dave Wade G4UGM

Illegitimi Non Carborundum

 

-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard
Sent: 25 August 2008 17:20
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?

 

Depends on whether you are trying to be correct and not
understood, or just understood, by the masses who do not speak Latin.
Who among those of us who do not speak Latin would ever be able to
decipher, "Noli nothis permittere te terere"?   

 

Wasn't  "Illegitimi non Carborundum" originally intended to be
humorous?

Regards, 
Richard Schuh 

 

 

 





From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin
Sent: Monday, August 25, 2008 8:37 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?

Should it really be Noli nothis permittere te terere

 

Ed Martin

Aultman Health Foundation

330-588-4723

ext 40441





From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard
Sent: Friday, August 22, 2008 2:24 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?

 

Dave Wade said "Illegitimi Non Carborundum"

 

After so many years of abrasion, your skin gets thinner.
I do not suffer fools nearly as well as I once did.

 

Regards, 
Richard Schuh 

 

 

Re: Where Do I Go From Here?

[Paul Raulerson]

High school latin 3 decades agao notwithsatanding, what the heck does that 
mean? None of those words translate or even transliterate inside my head.?
Most like a failure inside my head... :)?
-Paul
?
-Original Message-
From: Schuh, Richard [mailto:[EMAIL PROTECTED]
Sent: Monday, August 25, 2008 11:19 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?

Depends on whether you are trying to be correct and not understood, or just 
understood, by the masses who do not speak Latin. Who among those of us who do 
not speak Latin would ever be able to decipher, "Noli nothis permittere te 
terere"???
?
Wasn't? "Illegitimi non Carborundum" originally intended to be humorous?
Regards,
Richard Schuh
?

?



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of 
Edward M. Martin
Sent: Monday, August 25, 2008 8:37 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?



Should it really be Noli nothis permittere te terere
?
Ed Martin
Aultman Health Foundation
330-588-4723
ext 40441




From:The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of 
Schuh, Richard
Sent: Friday, August 22, 2008 2:24 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?

?
Dave Wade said "Illegitimi Non Carborundum"
?
After so many years of abrasion, your skin gets thinner. I do not suffer fools 
nearly as well as I once did.
?

Regards,
Richard Schuh
?
?

Re: Where Do I Go From Here?

[Thomas Kern]

"Illegitimi non Carborundum"

Loosely translated: "Don't let the b*st*rds grind you down"


On Mon, 25 Aug 2008 18:12:16 +, Paul Raulerson <[EMAIL PROTECTED]> 
wrote:

>High school latin 3 decades agao notwithsatanding, what the heck does th
at
mean? None of those words translate or even transliterate inside my head.
?
>Most like a failure inside my head... :)?
>-Paul

Re: Where Do I Go From Here?

[Wayne Driscoll]

Shuddering as I reply to this thread, but this is starting to closely
resemble an IBM-MAIN list thread, not a good thing!

Wayne Driscoll
Product Developer
NOTE:  All opinions are strictly my own.




-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Thomas Kern
Sent: Monday, August 25, 2008 1:25 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?

"Illegitimi non Carborundum"

Loosely translated: "Don't let the b*st*rds grind you down"


On Mon, 25 Aug 2008 18:12:16 +, Paul Raulerson <[EMAIL PROTECTED]> =
wrote:

>High school latin 3 decades agao notwithsatanding, what the heck does th=
at
mean? None of those words translate or even transliterate inside my head.=
?
>Most like a failure inside my head... :)?
>-Paul

Re: Where Do I Go From Here?

[LOREN CHARNLEY]

Paul,

 

Thanks for asking the question that most of would like to know the
answer to

 

Loren Charnley, Jr.

IT Systems Engineer

FAMILY DOLLAR

(704) 847-6961 Ext. 3327

(704) 814-3327

[EMAIL PROTECTED]

 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Paul Raulerson
Sent: Monday, August 25, 2008 2:12 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?

 

High school latin 3 decades agao notwithsatanding, what the heck does
that mean? None of those words translate or even transliterate inside my
head.?

Most like a failure inside my head... :)?

-Paul

?

-Original Message-
From: Schuh, Richard [mailto:[EMAIL PROTECTED]
Sent: Monday, August 25, 2008 11:19 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?




Depends on whether you are trying to be correct and not understood, or
just understood, by the masses who do not speak Latin. Who among those
of us who do not speak Latin would ever be able to decipher, "Noli
nothis permittere te terere"??? 

?

Wasn't? "Illegitimi non Carborundum" originally intended to be humorous?

Regards, 
Richard Schuh 

?

?

 





From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin
Sent: Monday, August 25, 2008 8:37 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?

Should it really be Noli nothis permittere te terere

?

Ed Martin

Aultman Health Foundation

330-588-4723

ext 40441





From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard
Sent: Friday, August 22, 2008 2:24 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?

?

Dave Wade said "Illegitimi Non Carborundum"

?

After so many years of abrasion, your skin gets thinner. I do
not suffer fools nearly as well as I once did.

?

Regards, 
Richard Schuh 

?

?

 



 NOTE:
This e-mail message contains PRIVILEGED and CONFIDENTIAL
information and is intended only for the use of the specific
individual or individuals to which it is addressed. If you are not
an intended recipient of this e-mail, you are hereby notified that
any unauthorized use, dissemination or copying of this e-mail or
the information contained herein or attached hereto is strictly
prohibited. If you receive this e-mail in error, notify the person
named above by reply e-mail and please delete it. Thank you.

Re: Where Do I Go From Here?

[Marty Zimelis]

Was I the only one who followed the link in Phil Tully's message of about
three hours ago?
 
http://en.wikipedia.org/wiki/Illegitimi_non_carborundum 
 
Marty
 
Martin Zimelis 
Principal 
maz/Consultancy 




  _  

From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of LOREN CHARNLEY
Sent: Monday, August 25, 2008 2:37 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?



Paul,

 

Thanks for asking the question that most of would like to know the answer
to..

 

Loren Charnley, Jr.

IT Systems Engineer

FAMILY DOLLAR

(704) 847-6961 Ext. 3327

(704) 814-3327

[EMAIL PROTECTED]

 


  _  


From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Paul Raulerson
Sent: Monday, August 25, 2008 2:12 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?

 

High school latin 3 decades agao notwithsatanding, what the heck does that
mean? None of those words translate or even transliterate inside my head.?

Most like a failure inside my head... :)?

-Paul

?

-Original Message-
From: Schuh, Richard [mailto:[EMAIL PROTECTED]
Sent: Monday, August 25, 2008 11:19 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?





Depends on whether you are trying to be correct and not understood, or just
understood, by the masses who do not speak Latin. Who among those of us who
do not speak Latin would ever be able to decipher, "Noli nothis permittere
te terere"??? 

?

Wasn't? "Illegitimi non Carborundum" originally intended to be humorous?

Regards, 
Richard Schuh 

?

?

 


  _  


From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Edward M. Martin
Sent: Monday, August 25, 2008 8:37 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?

Should it really be Noli nothis permittere te terere

?

Ed Martin

Aultman Health Foundation

330-588-4723

ext 40441


  _  


From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Schuh, Richard
Sent: Friday, August 22, 2008 2:24 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Where Do I Go From Here?

?

Dave Wade said "Illegitimi Non Carborundum"

?

After so many years of abrasion, your skin gets thinner. I do not suffer
fools nearly as well as I once did.

?

Regards, 
Richard Schuh 

?

?

 



  _  




 NOTE: This
e-mail message contains PRIVILEGED and CONFIDENTIAL information and is
intended only for the use of the specific individual or individuals to which
it is addressed. If you are not an intended recipient of this e-mail, you
are hereby notified that any unauthorized use, dissemination or copying of
this e-mail or the information contained herein or attached hereto is
strictly prohibited. If you receive this e-mail in error, notify the person
named above by reply e-mail and please delete it. Thank you. 

A brief comment from our moderator, Re: [IBMVM] Where Do I Go From Here?

[IBMVM Moderator]

Dearest friends and colleagues,

By my (very likely imprecise) count, the last ten posts in this thread 
have added little by way of technical content to the original topic.


I offer this comment as a gentle reminder that most - perhaps all - of 
the 881 current subscribers to our little kaffeeklatsch are very busy 
people.  Please be respectful of the time and attention each of our 
members requires in order to participate in the discussion by 
restraining the urge to take threads such as this one on a romp through 
the off-topic briar patch.


My friends, I beseech you:  Let it go.  Write it if you must, but then 
carefully step away from the "send" button and instead cache those 
sparkling gems of wit in the "drafts" folder for some other mailing 
list, on some other day.


With most kind regards,

-dan.

Daniel P. Martin -- IBMVM List Janitor
[EMAIL PROTECTED] / [EMAIL PROTECTED]

z9 BC HMC Find Bar

[Peter . Webb]

A little while ago, an orange 'find bar' started appearing just below
every window on our HMC. We tried clicking on the 'X' on the left to
make it go away, and this works, once, on the first window we try it on.
But the find bar keeps coming back, and we can't get it to go away. It
is a major nuisance since it will prevent HMC logon, or other data
entry, unless you know a little trick to get around it.

Can anyone tell me how to permanently get rid of this pain in the rear?


The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material.  Any 
review retransmission dissemination or other use of or taking any action in 
reliance upon this information by persons or entities other than the intended 
recipient or delegate is strictly prohibited.  If you received this in error 
please contact the sender and delete the material from any computer.  The 
integrity and security of this message cannot be guaranteed on the Internet.  
The sender accepts no liability for the content of this e-mail or for the 
consequences of any actions taken on the basis of information provided.  The 
recipient should check this e-mail and any attachments for the presence of 
viruses.  The sender accepts no liability for any damage caused by any virus 
transmitted by this e-mail.  This disclaimer is property of the TTC and must 
not be altered or circumvented in any manner.

Re: Restart of TCPIP function servers when TCPIP is recycled

[Alan Ackerman]

On Mon, 25 Aug 2008 14:08:59 +0200, Colin Allinson <[EMAIL PROTECTED]
m> wrote:

>Over the weekend a LAN problem resulted in TCPIP getting hung up on 3 of

>our systems and a recycle of TCPIP was necessary to resolve the issue.
>
>On 2 of the systems we had no issue but, on a 3rd, we had a subsequent
>issue with NAMESRV needing a separate manual recycle of that server.
>
>When I look at the console of TCPIP startup I see :-
>
>DTCIPI030W StartANewLife: Victim NAMESRV, reason "Restarting you
>because TCP/IP has been restarted"
>HCPLGA054E Already logged on disconnected
>
>and, sure enough, NAMESRV was not restarted. I see the same for all 3
>systems but, I guess, NAMESRV survived without problems on the other 2 b
ut
>got hung up on this system.
>
>This leads me to the following questions:-
>- Should TCPIP force it's application servers before starting them - and
,
>if so, what might I have configured incorrectly?
>- If not, what would be the best place to insert commands to force these

>off when TCPIP is started to ensure a clean start up?
>
>
>Colin Allinson
>
>Amadeus Data Processing GmbH
>

We ran into a similar problem, but the guest was SSLSERV. We IPLed VM. Th
en Dennis noticed he 
had forgotten some beta service for SSLSERV so he #CP EXT TCPIP. TCPIP ca
me down after bringing 
down it's guests. SSLSERV was shut down but (because it is a Linux guest?
) it did not log off. When 
TCPIP came back up it tried to AUTOLOG SSLSERV but failed because SSLSERV
 was still logged on.

We are planning to open an incident, but I don't see it open yet. 

Alan Ackerman
Alan (dot) Ackerman (at) Bank of America (dot) com 

Re: Restart of TCPIP function servers when TCPIP is recycled

[Schuh, Richard]

The answer is z/VM 5.4 :-)

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED] On Behalf Of Alan Ackerman
> Sent: Monday, August 25, 2008 5:05 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Restart of TCPIP function servers when TCPIP is recycled
> 
> 
>   SSLSERV was shut down but 
> (because it is a Linux guest?=
> ) it did not log off. When
> TCPIP came back up it tried to AUTOLOG SSLSERV but failed 
> because SSLSERV=  was still logged on.
> 
> We are planning to open an incident, but I don't see it open yet. 
> 
> Alan Ackerman
> Alan (dot) Ackerman (at) Bank of America (dot) com 
> 

Re: IUCV - What's wrong with this picture?

[dave]

Hi, Gary.


Well, there is no such thing as a free lunch, so
establishing *large* numbers of IUCV connections between
virtual machines does cost something. Control blocks must be
allocated, must be managed by CP, interrupts fielded, etc.
Off of the top of my head, I don't know how much storage
these control blocks take, but I would suspect that with CP
now being 64-bit, the amount of storage taken would not be a
significant issue.

Even if the amount of traffic between the clients and the VM
server is slight; the *timing* of the traffic might be a
concern.5000 clients all sending a short IUCV message at
the same time to the server, might cause problems. The
server would have to have enough resources available to
process all of the traffic in an acceptable amount of
time

Good luck.
- Original Message -
From: "Gary M. Dennis" <[EMAIL PROTECTED]>
To: IBMVM@LISTSERV.UARK.EDU
Subject: IUCV -  What's wrong with this picture?
Date: Mon, 25 Aug 2008 12:23:49 -0500

> Assumptions:
> 
> 0. A VM server machine
> 
> 1. A cluster of client virtual machines (possibly
> thousands)
> 
> 2. n buffers are allocated for each client virtual machine
> 
> 3. Each buffer contains table elements that require
> (a) Element ageing
> (b) Element deletion when invalidated by:
> 1. lack of use
> 2. client machine request
> (c) Compression as buffer fragmentation occurs
> 
> 4. Each client virtual machine in the cluster is connected
> via IUCV to the server virtual machine.
> 
> 5. IUCV traffic between the server machine and client
> machine is extremely low volume.  Initial call,
> termination call, intermittent statistics call.
> 
> 6. After the initial call, the server virtual machine will
> maintain the buffer table entries in each client virtual
> machine without additional IUCV interaction.
> 
> Now the questions:
> 
> 1. Does IUCV infrastructure overhead specifically
> associated with number of connections become prohibitive
> at some well known point?
> 
> 2. Has anyone had experience with an application having a
> high IUCV connection count like this? If so, what was that
> experience?
> 
> Again, the traffic incidence per connection is very low
> but the number of connections is potentially very high.
> 
> 
> Thanks 
> 
> 
> --.  .-  .-.  -.--
> 
> Gary Dennis

Re: IUCV - What's wrong with this picture?

[Barton Robinson]

Sounds like there is a need for decent performance monitoring.


dave wrote:


Hi, Gary.


Well, there is no such thing as a free lunch, so
establishing *large* numbers of IUCV connections between
virtual machines does cost something. Control blocks must be
allocated, must be managed by CP, interrupts fielded, etc.
Off of the top of my head, I don't know how much storage
these control blocks take, but I would suspect that with CP
now being 64-bit, the amount of storage taken would not be a
significant issue.

Even if the amount of traffic between the clients and the VM
server is slight; the *timing* of the traffic might be a
concern.5000 clients all sending a short IUCV message at
the same time to the server, might cause problems. The
server would have to have enough resources available to
process all of the traffic in an acceptable amount of
time

Good luck.
- Original Message -
From: "Gary M. Dennis" <[EMAIL PROTECTED]>
To: IBMVM@LISTSERV.UARK.EDU
Subject: IUCV -  What's wrong with this picture?
Date: Mon, 25 Aug 2008 12:23:49 -0500



Assumptions:

0. A VM server machine

1. A cluster of client virtual machines (possibly
thousands)

2. n buffers are allocated for each client virtual machine

3. Each buffer contains table elements that require
   (a) Element ageing
   (b) Element deletion when invalidated by:
   1. lack of use
   2. client machine request
   (c) Compression as buffer fragmentation occurs

4. Each client virtual machine in the cluster is connected
via IUCV to the server virtual machine.

5. IUCV traffic between the server machine and client
machine is extremely low volume.  Initial call,
termination call, intermittent statistics call.

6. After the initial call, the server virtual machine will
maintain the buffer table entries in each client virtual
machine without additional IUCV interaction.

Now the questions:

1. Does IUCV infrastructure overhead specifically
associated with number of connections become prohibitive
at some well known point?

2. Has anyone had experience with an application having a
high IUCV connection count like this? If so, what was that
experience?

Again, the traffic incidence per connection is very low
but the number of connections is potentially very high.


Thanks 



--.  .-  .-.  -.--

Gary Dennis

Re: IUCV - What's wrong with this picture?

[dave]

That advice goes without saying...any effort to develop a
sophisticated VM application demands a good monitor to help
the developers tune that application to meet performance
goals.

DJ
- Original Message -
From: Barton Robinson <[EMAIL PROTECTED]>
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: IUCV -  What's wrong with this picture?
Date: Mon, 25 Aug 2008 19:13:20 -0800

> Sounds like there is a need for decent performance
> monitoring.
> 
> 
> dave wrote:
> 
> > Hi, Gary.
> > 
> > 
> > Well, there is no such thing as a free lunch, so
> > establishing *large* numbers of IUCV connections between
> > virtual machines does cost something. Control blocks
> > must be allocated, must be managed by CP, interrupts
> > fielded, etc. Off of the top of my head, I don't know
> > how much storage these control blocks take, but I would
> > suspect that with CP now being 64-bit, the amount of
> > storage taken would not be a significant issue.
> > 
> > Even if the amount of traffic between the clients and
> > the VM server is slight; the *timing* of the traffic
> > might be a concern.5000 clients all sending a short
> > IUCV message at the same time to the server, might cause
> > problems. The server would have to have enough resources
> > available to process all of the traffic in an acceptable
> > amount of time
> > 
> > Good luck.
> > - Original Message -
> > From: "Gary M. Dennis" <[EMAIL PROTECTED]>
> > To: IBMVM@LISTSERV.UARK.EDU
> > Subject: IUCV -  What's wrong with this picture?
> > Date: Mon, 25 Aug 2008 12:23:49 -0500
> > 
> > 
> >>Assumptions:
> >>
> >>0. A VM server machine
> >>
> >>1. A cluster of client virtual machines (possibly
> >>thousands)
> >>
> >>2. n buffers are allocated for each client virtual
> machine >>
> >>3. Each buffer contains table elements that require
> >>(a) Element ageing
> >>(b) Element deletion when invalidated by:
> >>1. lack of use
> >>2. client machine request
> >>(c) Compression as buffer fragmentation occurs
> >>
> >>4. Each client virtual machine in the cluster is
> connected >>via IUCV to the server virtual machine.
> >>
> >>5. IUCV traffic between the server machine and client
> >>machine is extremely low volume.  Initial call,
> >>termination call, intermittent statistics call.
> >>
> >>6. After the initial call, the server virtual machine
> will >>maintain the buffer table entries in each client
> virtual >>machine without additional IUCV interaction.
> >>
> >>Now the questions:
> >>
> >>1. Does IUCV infrastructure overhead specifically
> >>associated with number of connections become prohibitive
> >>at some well known point?
> >>
> >>2. Has anyone had experience with an application having
> a >>high IUCV connection count like this? If so, what was
> that >>experience?
> >>
> >>Again, the traffic incidence per connection is very low
> >>but the number of connections is potentially very high.
> >>
> >>
> >>Thanks 
> >>
> >>
> >>--.  .-  .-.  -.--
> >>
> >>Gary Dennis
> > 
> > 
> > 

Re: IUCV - What's wrong with this picture?

[Jim Bohnsack]

The 5000 clients hopefully do not all do a "TIME IS 00:00:00" message or 
some kind of coordinated event with a signal coming from a common 
external source (CP), do they?  Something like that could overrun a lot 
of buffers.

Jim

dave wrote:

Hi, Gary.


Well, there is no such thing as a free lunch, so
establishing *large* numbers of IUCV connections between
virtual machines does cost something. Control blocks must be
allocated, must be managed by CP, interrupts fielded, etc.
Off of the top of my head, I don't know how much storage
these control blocks take, but I would suspect that with CP
now being 64-bit, the amount of storage taken would not be a
significant issue.

Even if the amount of traffic between the clients and the VM
server is slight; the *timing* of the traffic might be a
concern.5000 clients all sending a short IUCV message at
the same time to the server, might cause problems. The
server would have to have enough resources available to
process all of the traffic in an acceptable amount of
time

Good luck.
- Original Message -
From: "Gary M. Dennis" <[EMAIL PROTECTED]>
To: IBMVM@LISTSERV.UARK.EDU
Subject: IUCV -  What's wrong with this picture?
Date: Mon, 25 Aug 2008 12:23:49 -0500

  

Assumptions:

0. A VM server machine

1. A cluster of client virtual machines (possibly
thousands)

2. n buffers are allocated for each client virtual machine

3. Each buffer contains table elements that require
(a) Element ageing
(b) Element deletion when invalidated by:
1. lack of use
2. client machine request
(c) Compression as buffer fragmentation occurs

4. Each client virtual machine in the cluster is connected
via IUCV to the server virtual machine.

5. IUCV traffic between the server machine and client
machine is extremely low volume.  Initial call,
termination call, intermittent statistics call.

6. After the initial call, the server virtual machine will
maintain the buffer table entries in each client virtual
machine without additional IUCV interaction.

Now the questions:

1. Does IUCV infrastructure overhead specifically
associated with number of connections become prohibitive
at some well known point?

2. Has anyone had experience with an application having a
high IUCV connection count like this? If so, what was that
experience?

Again, the traffic incidence per connection is very low
but the number of connections is potentially very high.


Thanks 



--.  .-  .-.  -.--

Gary Dennis



  


--
Jim Bohnsack
Cornell University
(972) 596-6377 home/office
(972) 342-5823 cell
[EMAIL PROTECTED]

Re: IUCV - What's wrong with this picture?

[John P. Baker]

Since you indicate low traffic volume, maintaining a permanent connection
between the server and each client seems to me to be excessive.

Alternatively, I would propose a somewhat different approach.

The server should have configuration parameters specifying the maximum
number of concurrent connections, the statistical notification interval, as
well as other necessary information.

The server should maintain a list of all potential clients.  Each entry
should include a last connection timestamp.

Each client should have configuration parameters naming the server, the
statistical notification interval, as well as other necessary information.

If the server has a task to be distributed to a client for processing, it
should examine in client table for an available client, establish an IUCV
connection, and transfer to the client the information necessary to initiate
the transaction.  The connection should then be severed pending transaction
completion or an intermediate statistical report.  If a connection cannot be
established because too many connections are active, the event requirement
should be posted for retry after a specified interval.  If a connection
cannot be established because the client does not respond, some form of
recovery (i.e., FORCE/XAUTOLOG) sequence may be appropriate.

If a statistical report is required and has not been received by the server,
the server should attempt to establish an IUCV connection to the client for
that purpose, again following the general procedure outlined above.

On the client side, on a regular interval, the client should attempt to
establish an IUCV connection to the server for the purpose of reporting
statistical information, again following the general procedure outlined
above.

Maintaining thousands of IUCV connections may not have a significant impact
on real storage considering the vast amounts of memory now available on
zSeries processors.  However, searching through all of those linked lists
WILL have a performance impact, and is totally unnecessary.

John P. Baker

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Gary M. Dennis
Sent: Monday, August 25, 2008 1:24 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: IUCV - What's wrong with this picture?

Assumptions:

0. A VM server machine

1. A cluster of client virtual machines (possibly thousands)

2. n buffers are allocated for each client virtual machine

3. Each buffer contains table elements that require
(a) Element ageing
(b) Element deletion when invalidated by:
1. lack of use
2. client machine request
(c) Compression as buffer fragmentation occurs

4. Each client virtual machine in the cluster is connected via IUCV to the
server virtual machine.

5. IUCV traffic between the server machine and client machine is extremely
low volume.  Initial call, termination call, intermittent statistics call.

6. After the initial call, the server virtual machine will maintain the
buffer table entries in each client virtual machine without additional IUCV
interaction.

Now the questions:

1. Does IUCV infrastructure overhead specifically associated with number of
connections become prohibitive at some well known point?

2. Has anyone had experience with an application having a high IUCV
connection count like this? If so, what was that experience?

Again, the traffic incidence per connection is very low but the number of
connections is potentially very high.


Thanks 


--.  .-  .-.  -.--

Gary Dennis

Re: Where Do I Go From Here?

[Alan Ackerman]

On Thu, 21 Aug 2008 16:49:49 -0500, Karl Severson <[EMAIL PROTECTED]
ON.COM> wrote:

>Of my options, which would be the most efficient? The latest zVM with a 

>VM/ESA guest? The latest zOS with a VM/ESA guest? Some other combination
?  

>Karl Severson
>IBM VM System Administrator
>Raytheon Company
>El Segundo, California
>
=
==
=

z/OS doesn't run guests. Don't feel bad, I hear this all the time. Usuall
y as "Let's run Linux under 
z/OS". I don't know why z/OS doesn't run guests (but I can guess). z/OS d
oes everything else.

The simile I made up years ago (when z/OS was called MVS):

Solving things with MVS is like getting a bowling ball with the same diam
eter as the lane -- it my 
be huge and hard to roll, but it is guaranteed to knock down all the pins
.

Alan Ackerman
Alan (dot) Ackerman (at) Bank of America (dot) com 

Re: IUCV - What's wrong with this picture?

[Alan Ackerman]

On Mon, 25 Aug 2008 12:23:49 -0500, Gary M. Dennis <[EMAIL PROTECTED]
com> wrote:

>Assumptions:
>
>0. A VM server machine
>
>1. A cluster of client virtual machines (possibly thousands)
>
>2. n buffers are allocated for each client virtual machine
>
>3. Each buffer contains table elements that require
>(a) Element ageing
>(b) Element deletion when invalidated by:
>1. lack of use
>2. client machine request
>(c) Compression as buffer fragmentation occurs
>
>4. Each client virtual machine in the cluster is connected via IUCV to t
he
>server virtual machine.
>
>5. IUCV traffic between the server machine and client machine is extreme
ly
>low volume.  Initial call, termination call, intermittent statistics cal
l.
>
>6. After the initial call, the server virtual machine will maintain the
>buffer table entries in each client virtual machine without additional I
UCV
>interaction.
>
>Now the questions:
>
>1. Does IUCV infrastructure overhead specifically associated with number
 of
>connections become prohibitive at some well known point?
>
>2. Has anyone had experience with an application having a high IUCV
>connection count like this? If so, what was that experience?
>
>Again, the traffic incidence per connection is very low but the number o
f
>connections is potentially very high.
>
>
>Thanks
>
>
>--.  .-  .-.  -.--
>
>Gary Dennis
>
=
==
==

If the volume is that low, you could use the old paradigm used by many VM
 applications 
(OfficeVision, for example), use the virtual reader as a queue and the vi
rtual punch (or CMS 
SENDFILE) as the requester. Can go both ways, too. This is the ancestor o
f MQ. 

Alan Ackerman
Alan (dot) Ackerman (at) Bank of America (dot) com 

Re: IUCV - What's wrong with this picture?

[Alan Altmark]

On Monday, 08/25/2008 at 10:11 EDT, dave <[EMAIL PROTECTED]> wrote:

> Well, there is no such thing as a free lunch, so
> establishing *large* numbers of IUCV connections between
> virtual machines does cost something. Control blocks must be
> allocated, must be managed by CP, interrupts fielded, etc.
> Off of the top of my head, I don't know how much storage
> these control blocks take, but I would suspect that with CP
> now being 64-bit, the amount of storage taken would not be a
> significant issue.

The primary memory allocation for IUCV connections is sufficient, IIRC, 
for 256 connections.  On the 257th connection, another allocation for 256 
is made.  Access to those control blocks is fast due to the fact that they 
are not chained, but are maintained as an array of pointers (256 adjacent 
entries per pointer).  The control block for any path id is easy to 
locate.  No searching required.

I'm more concerned in how the SVM guest getting all those IUCV messages is 
handling *its* memory allocation.

Alan Altmark
z/VM Development
IBM Endicott