Re: Socket Listener Delay Issue

[Michael Ryan <michaelrtr@xxxxxxxxx>]

Or nom-du-annee' as it were.


On Thu, Aug 8, 2013 at 9:01 PM, Rich Marion <DPCMarion@xxxxxxxxxxxxxxxxx>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
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.