Topic
4 replies Latest Post - ‏2012-04-13T15:21:27Z by barbara_morris
egower
egower
7 Posts
ACCEPTED ANSWER

Pinned topic Need Open Access Help Please

‏2012-04-12T03:51:03Z |
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
    barbara_morris
    382 Posts
    ACCEPTED ANSWER

    Re: Need Open Access Help Please

    ‏2012-04-12T15:21:04Z  in response to egower
    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
    
  • egower
    egower
    7 Posts
    ACCEPTED ANSWER

    Re: Need Open Access Help Please

    ‏2012-04-13T03:40:37Z  in response to egower
    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.
  • egower
    egower
    7 Posts
    ACCEPTED ANSWER

    Re: Need Open Access Help Please

    ‏2012-04-13T03:44:39Z  in response to egower
    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.

    Thanks again.
    • barbara_morris
      barbara_morris
      382 Posts
      ACCEPTED ANSWER

      Re: Need Open Access Help Please

      ‏2012-04-13T15:21:27Z  in response to egower
      Ya, I've always thought it was a strange feature to have those non-error conditions cause the INFSR to get called.

      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.