Host Server Problems

Chad Young

unread,

Dec 9, 1997, 3:00:00 AM12/9/97

to

We are running TCP/IP and IPX direct connections with CA on our AS/400. We
are running V3R7. We seem to lose some host server jobs and it will not
allow new clients to connect. If you are already on you are O.K. Has
anyone seen this problem or have an idea of what might be going on?

Kay Healy

unread,

Dec 9, 1997, 3:00:00 AM12/9/97

to

Chad:

Check the QAUTOVRT system value to see if it is set too low. This would
prevent new sessions from starting. You should see a message in the
QSYSOPR msgq if the system value is being exceeded.

Regards,

Frank Healy

Chad Young

unread,

Dec 11, 1997, 3:00:00 AM12/11/97

to

It is set to 9999. I think we are fine there. It seems to blow one of the
Host Server jobs itself away. If we end Host Server and then restart them
the problem is fixed.
Kay Healy wrote in message <348E17...@encore.com>...

Christopher Rees

unread,

Dec 11, 1997, 3:00:00 AM12/11/97

to

I know this probably doesn't help, but the only way I have found to fix this
problem is to bounce the machine.

Javier Fernández

unread,

Dec 12, 1997, 3:00:00 AM12/12/97

to

Then probably you are issuing the STRHOSTSVR *ALL command very quickly after
the STRTCP. This will make some programs launched by STRTCP not finishing by
the time STRHOSTSVR starts. If you are in interective mode the final message
of STRTCP is not the end of the proccess.

In interactive or batch the way to run it save is run the STRTCP command and
then submit the STRHOSTSVR *ALL command to the jobq QSYSNOMAX. This will
work because STRTCP submit each job to that QUEUE, so STRHOSTSVR will not
start up to ALL the proccess of STRTCP is ended.

Try it and let me know.

Ah! Almost forget. If your are running all this from QSTRUP just remember
giving QPGMR user profile autorization of *USE on the STRHOSTSVR object.

Chad Young

unread,

Dec 15, 1997, 3:00:00 AM12/15/97

to

We can ENDHOSTSVR *ALL and then STRHOSTSVR *ALL and this fixes it. But it
happens frequently.
Christopher Rees wrote in message <66p89d$gtu$1...@ursa.smsu.edu>...

Frank Healy

unread,

Dec 15, 1997, 3:00:00 AM12/15/97

to

Chad,

It would be interesting to know the highest number QPADEVXXX device when
the problem appears. If it always the same number, it would indicate
that you are reaching some theshold somewhere. It could be that when
you end host servers you are knocking everyone off and then they have to
reconnect, which may take a period of time before that threshold is hit
again.

Are there any errors message appearing in QSYSOPR msgq?

Take care.

Frank Healy

Javier Fernández

unread,

Dec 16, 1997, 3:00:00 AM12/16/97

to

The problem is you run STRTCP and then very quickly you run STRHOSTSVR *ALL.

Do this:

1) Run STRTCP
2) Submit job STRHOSTSVR *ALL to the jobq QSYSNOMAX

This will work because STRTCP submit jobs to that queue. Jobs that must be
finish before STRHOSTSVR.

Just try.

Chad Young escribió en mensaje
<037BE8FC3B7ACE8A.BA791F30...@library-proxy.airnews.ne
t>...

Tony White

unread,

Dec 21, 1997, 3:00:00 AM12/21/97

to

That's one way to fix the problem, but IBM also has PTF's for it. We had
the same
problem and the PTF's fixed it!

You also have to watch out for the number of virtual devices on a virtual
controller. You
must have 250 virtual devices on the controller before it will automatically
roll to the next one.
Damage some device descriptions, or have some varied off and you don't reach
250 and you
don't roll to the next controller.

FWIW!

Javier Fernández wrote in message <34963...@news.arrakis.es>...