RE: Socket Listener Delay Issue

First, thank you for your response. I was unaware that there was a hidden
key to group the threads in the header of the emails. (sorry, I am an old
s/34 programmer, I typically do not use the Nom-du-jour of the 400)

I'll try to publish the additional information the next time it happens. I
will talk these changes over with the management to schedule when we can
implement them. Not allowed to touch the production box until every change
is thoroughly tested and I think changing the subsystem to use its own pool
requires a subsystem shutdown/restart which we cannot do but once a week, so
it may be a couple weeks? These listener programs are in use 27/7. (but
this issue is becoming a work stoppage issue so it might get a higher
priority) I'll ask if we can do it during the day as it will only be a
down for 10 seconds tops and will only effect the programs for these
devices.

Thank you very much. I appreciate all your comments.

Rich


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of DrFranken
Sent: Thursday, August 08, 2013 10:08 AM
To: Midrange Systems Technical Discussion
Subject: Re: Socket Listener Delay Issue

Ah so Kimmel is a Raspberry Pi guy while I prefer Arduino. But lets not
start a political war here. :-)

Second, I didn't see this thread initially since it was started by replying
to another thread so it has stacked up under an FTP heading.
You should ALWAYS Start a NEW thread with a NEW email, just sayin.....

In the past I used to be an RPG programmer. Some time back Susan Ganter
declared I was down to MQC and since then I program everything IN CL.
And I'm now one of the Hardware guys Dan refers too. I also teach work
management.

So you're hitting 20 seconds and timing out. Even for a non-real time system
20 seconds is 'FOR-EV-ER'. I have dealt with this all the way back to the
double digit cpw days.

You have taken a couple of steps in the right direction.
- Lowering the job priority number to increase it's priority is good.
- The Purge *NO is mostly not used at all any more but a nice try.

To truly keep the thing in memory you'll want to create a private memory
pool for these jobs to run in. That is use the CHGSBSD with the POOLS
parameter set like POOLS((3 1024 20)) to create pool 3 with 1M (yes MB, you
may want more...) of memory and an activity level of 20.

Then you'll need to route those jobs into that memory pool AND NOTHING ELSE!
This tactic will assure those jobs are always in memory. Your higher
priority will put them near the top of the queue for CPU so two things have
been solved.

What is the activity level in the pool? does WRKSYSSTS (F21 Advanced) show
any "Wait-Inel" or "Act-Inel" transitions? If so that's very bad in this
environment. You'll need a higher activity level in the pool.

A lot more needs to be known for sure. One is the network, is it solid?
Are there any retries happening? Can you PING the devices with a rock solid
(NO LOSS) ping in low double digit response times? Any packet loss will
cause retransmits which can clobber response times. You say the connections
are appearing in the comm trace so this may be OK, just askin.

What does the work management environment look like? Is the system heavily
busy? Are there a large number of Faults? Are the disks busy?
Doesn't sound like a lock issue but programs such as these need to be
written so they do not need to wait for locks on data.

You say you're on a 400 but on 7.1 and that's impossible. Last release
supported on AS/400 was 5.3 so you could be on a POWER5, 6, or 7 server.

My gut feel here is that this system may be overcommitted in some way.



- Larry "DrFranken" Bolhuis

www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com