Re: Screen Scraping and hoging system resources

Dave,

I think that you may be on the right track, but I caution you that when making
changes for performance purposes that you only change one thing at a time and
note what effect, if any, it has.

You may want to start with just changing the execution priority of the screen
scraper jobs and see if that minimizes the impact on the other interactive
users.

Having another subsystem that uses a shared memory pool (shared with the
interactive sessions) will probably not gain you anything.  Carving aside some
memory for a job that spends a chunk of time sleeping may seem wasteful, so I
would reserve that option until later.

Like so many other choices, what is the best strategy to do .... usually
includes the "it depends" warning label :)


> >
> > Hi Group,
> > We are running two of the largest's i series box's that IBM released
> > (installed early 2000.,)
> > They are soley used to run interactive green screen Rumba sessions
> > (maybe 3000 per day)
> > and I have 20 to 30 Screen Scraping app's (HLLAPI or Object X) than run
> > between 8am  to 5pm.They do a lot of fast reading and writing to the green
> > screens and then sleep for 3 min's in this cycle all day long.
> >
> > I believe Im somehow hoging system resources( even on the big iron !)
> > ie other users interactive reponse time slow down.
> > What can be done to reduce the load, not knowing anything aboubt
> > the AS/400 one thing that springs to mind is to create a subsystem
> > for the Screen Scraping interactive sessions and give them lower
> > priority.
> > Am I on the right track here, any ideas welcome.