Re: Socket Listener Delay Issue

On the System/38 you had to shut down the subsystem to make changes. Today we can add pools and change routing steps on the fly. I certainly appreciate the desire to test things though!!

You mention CPU over 100% bit depending on the server that may be completely acceptable. Is this server partitioned into multiple LPARs? If ti is then with dynamic processor allocation and shared processors the CPU could go as high as 1000%. In that case 100% is a very low number and equates to only 10% which isn't busy at all! So to understand if 100% is high or not we'll need to know the allocation of the CPU in the profile. If the system is not partitioned then 100% is 100% and that means it IS very busy at that time!

Potentially more important though is the faulting statistics as well as the Transition data.

FYI I started on a S/34 (and still own it, it's truly a workbench now) but I have accepted the modernization of the platform! The last name change was more than 5 years ago - time flies when you're having fun! Those who insist on staying in the past "may be a 5250" ( http://www.frankeni.com/drsblog00fh.html )

- Larry "DrFranken" Bolhuis

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

On 8/8/2013 9:01 PM, Rich Marion wrote:

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