RE: Updating a Program using SETLL/READPE - Suggestions

Wow, thanks for the great responses, everyone.

I'm actually leaning towards moving this code to an SQL statement
instead.  I already have an index in-place, and I did some basic testing
with the SQL interpreter, and it seems to have significantly sped up the
process.

Again, thanks for the suggestions.

Brian.

-----Original Message-----
From: Lim Hock-Chai [mailto:Lim.Hock-Chai@xxxxxxxxxxxxxxx] 
Sent: Thursday, December 15, 2005 9:56 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: Updating a Program using SETLL/READPE - Suggestions

Can you multi thread this job by shipping doors?  
Instead of one job handle all, you will have 50 jobs and each handle a
particular shipping door.

If you think record lock might be the problem, you can override to
record lock wait to *immed.  Change the readpe to readpe(e) and skip
locked record.  Come back around to process later those locked record
after it reach eof.


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Brian Piotrowski
Sent: Wednesday, December 14, 2005 2:20 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Updating a Program using SETLL/READPE - Suggestions

Yes, but we have almost 50 shipping doors, which means almost 50
shipping requests may be done at any given time (so there could be 5,000
records being changed at once).

Also, our system is very heavily taxed with interactive jobs (which is
why I am petitioning the senior management for a new AS/400, as our box
usually hovers at or above 70% CPU usage at any given time), so this may
also be a contributing factor.  That, coupled with less than optimal
source code...

Brian.