Re: Error Handling (was WRKOBJLCK API)

Thanks Jim & Joe

I knew some of this stuff in theory but you inspired me to look up some 
specifics in the RPG manual to try to figure out exactly what you talking 
about.  It is apparent to me that INFSR subroutine calls for more complexity 
than I want to get into at the moment, but while reviewing the program tha 
one of my users had difficulties with yesterday, I did locate some problems 
in modifications that some consultants did for us a few years ago & I am now 
in process of fixing what I found.

The modification tracks usage of factory tools, machines, applicators, molds, 
etc, by having fields added to the labor input screen identifying tools used, 
then they get updated with machine cycles involved.

However, the architecture involves a ton of validation of fields individually 
& in combination, then only if all validation comes up clean is the update 
done.
They were using the same logical for validation as for update, and were not 
releasing the logical after validation access, so this contributing to 
unneccessary excess file conflicts.  If I use one logical read only for 
validation & another logical for update, the whole thing should invite less 
file access conflicts.

Another problem - what I call BAD CODE with ***** (bad words) for the 
consultants who did this & also for me for not spotting this sooner, where

READ    EOF flag only instead of
READ ER EOF immediate discovery

No wonder user screens were locking up so long ... it fails a read then reads 
every record until end-of-file of 45,000 recoird file.

The validation has some logic ... 
if error it must be a bad record & there is a relevant error message.

The update has no such logic ... I need to add something similar ... 
if error it must be that someone has locked this record
instead of the ugly they now get from OS/400

But I may need more than that - I do not know if I can assume the error is 
the kind that I am expecting.

I have got another "think about" after I get done fixing the obvious ***** 
(bad words)

In the current reality the user is keying into a busy screen then presses 
enter.
There can be several problems with the data (not user fault, just nature of 
the data)
Validation part of program as soon as it finds a problem
returns screen with message about ONE PROBLEM.
user fixes that one problem & presses enter.
User gets screen back with message about ANOTHER PROBLEM
cycle repeats until no problems left

I do not feel this is an efficient use of our people, resources, etc.

You know that if you put cursor on error message line at bottom of screen & 
F1 (help) it expands the story into a chunk more text.

You know that.
Most of our users forget that.

So I was thinking that when there is more than one error in actuality, 
I want text along bottom of screen to say (1st level message)
something that fits on the line like

"Put cursor on this line & F1 for details"

so they do not have to remember how to get to 2nd level

then when they get there the text is populated

story on one problem
story on another problem
story on third problem

I need to figure out naming of where this is so that I can populate it 
accordingly.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
RPG/400 Programmer but NOT a Jedi Master of this stuff.

> From: jimlangston@conexfreight.com (Jim Langston)
>  
>  I used to do something almost exactly like what you want to do,
>  Al, but it was on a PC in dBase.  Basically, any call to read a
>  record went through a subprocedure.  The subprocedure would try
>  to read the record, setting on locking or not as it was called.
>  
>  At any time the record was retrieved, the subprocedure would
>  return with a success flag (0).  If the record was locked, the
>  subprocedures would display a message to the user such as,
>  "Record in use, retrying.  Press <Esc> to abort..." and in one
>  second it would try to read the record again.  The user could
>  hit <Esc> to abort the try which would return a failure status
>  to the calling program (1).
>  
>  I've tried to think of ways to implement this in RPG, and can
>  think of a few ways, but the biggest problem I see is how to trap
>  the error condition in the RPG program itself.  I can now see
>  how to do this pretty much.  Use the error Subroutine to trap
>  the error condition.  SNDPGMMSG to send a message to the user
>  that it is retrying.
>  
>  Things I haven't figured out yet:
>  
>  How to get the user input to abort the read attempt without 
>  modifying the program extensively.
>  
>  What to do in batch jobs if the record remains locked after
>  an excessive amount of time ( over 1 minute? ).  Thinking of
>  sending an inquiry message to QSYSOPR waiting for a reply.
>  Doing this would be a bit of work and would definitely go into
>  my service programs.  Send message, then loop waiting for 
>  reply whether to try again or not.
>  
>  All this could be done in RPG, but it would be a bit of work.  Once
>  it's written, however, and all the fine points are worked out it
>  is something that could quickly be added to new programs and even
>  introduced to old ones.
>  
>  Also, it would be possible, I assume, to use the APIs to display
>  what user has the record locked if the user wants to know (perhaps
>  "Record locked, retrying... Press <F12> to abort, Press <F1) to 
>  display lock...".  I guess you could always find out who has the
>  record locked before you even display the message, "User SOANDSO
>  has record locked..." but I'm not sure I would want to add that
>  additional processing time to the program if there are going to
>  be a lot of records locked.
>  
>  HTH
>  
>  Jim Langston


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---