RE: Error Handling (was WRKOBJLCK API)

How about an Error Message Subfile window that pops up a scrollable list of
errors? 

Eric DeLong
Sally Beauty Company
MIS-Sr. Programmer/Analyst
940-898-7863 or ext. 1863
 

<Very Big SNIP>
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
+---

+---
| 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
+---