Pinned topic Need Open Access Help Please
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
We have an open access handler for communicating display file i/o to a java client over sockets. This service program was developed in house. We recently started to add a *PSSR routine to our converted rpg programs to capture abends which would then notify the java client of the problem. After adding the PSSR subroutine we have discovered that when paging a subfile and control is returned to the rpg program the PSSR traps some problem. I can find no information on the error being trapped in the program status data structure. Error ID and Error Message are both empty. Is there some other place I should be looking for error information. The weird thing is this program works fine without the *PSSR subroutine.
Updated on 2012-04-13T15:21:27Z at 2012-04-13T15:21:27Z by barbara_morris
barbara_morris 120000DX5W515 Posts
Re: Need Open Access Help Please2012-04-12T15:21:04ZThis is the accepted answer. This is the accepted answer.Did you add the INFSR keyword to your F specs? INFSR(*PSSR)?
If so ...
The INFSR gets called for 6 non-error events associated with HELP, PRINT, ROLLUP, ROLLDOWN, CLEAR, HOME. There would be nothing in the PSDS about these events because they are not errors.
Instead of using a *PSSR to trap errors, consider wrapping your entire logic in a MONITOR. All unhandled errors would go to the ON-ERROR section, but the HELP, PRINT etc events would not cause an error, so your programs would work the same as before.
MONITOR; all the existing code in your procedure except for subroutines ON-ERROR; what you had in your *PSSR ENDMON; errors in subroutines are handled by the MONITOR for the procedure
Re: Need Open Access Help Please2012-04-13T03:40:37ZThis is the accepted answer. This is the accepted answer.Yes we do have the INFSR(*PSSR) on the F spec. It would not trap an error thrown from our handler without it. We wanted to use the *PSSR subroutine as we have a few thousand programs to modify and just thought it would be simpler to change the F spec when we added the handler and drop a copybook of the *PSSR at the end of the C specs. Guess that's not going to work. We'll probably take your suggestion and use a monitor.
I have to say that I do think it's odd that the *PSSR subroutine traps those keys. Honestly I could count the number of times I've used *PSSR subroutine on one hand but it just seemed like the easiest solution to our problem. Guess not.
Thank you for your help.
Re: Need Open Access Help Please2012-04-13T03:44:39ZThis is the accepted answer. This is the accepted answer.The light just went on... it's not the *PSSR that's trapping the keys. It's the fact that it's bound to the INFSR. So I guess that makes a little more sense.
barbara_morris 120000DX5W515 Posts
Re: Need Open Access Help Please2012-04-13T15:21:27ZThis is the accepted answer. This is the accepted answer.
- egower 2700058NCW
I think it makes the INFSR very confusing. For normal errors, when the INFSR hits the ENDSR statement, it causes an inquiry message to be displayed. But with those 6 non-errors, control just returns to the statement after the I/O statement.
Another reason to use MONITOR instead of INFSR is that a file defined with INFSR has to have all its I/O operations in the main procedure. If there was any I/O to that file in a subprocedure, you'd get a compile error.