What other issues might impact the use on an SJP approach?
One of the main ones relates to user profile and site security requirements.
You would probably not want the SJP program accessible to USERA (say) when he or she is using a normal 5250 screen.
Additionally most sites insist that USERA executes his/her IBM i job under the profile USERA so that audit, log and security information shows the "real" user (although this is disappearing as more and more "threaded" processes serving many concurrent users, such as HTTP web servers, are used on the System i server).
So how can a single user profile USERA support these different views of the world?
- When they sign on to a real 5250 session they get their normal sign-on menu.
- When they sign on via a RAMP script they get the SJP program as their main "menu"?
There are several solutions to this problem:
- Use the Program/Procedure option on the IBM i sign-on screen to specify the SJP program when logging in via a RAMP script. You would probably add some security logic to the JSP to prevent users doing this through a real 5250 interface (see point 2).
- If you use a common menu program you could alter it to detect that it is being called from a RAMP script and then call the SJP program. Equally you could display the common menu initially and use a special "hidden" menu option to call the JSP program. The JSP program could confirm that it is being accessed by a RAMP script by conducting, for example, an encrypted exchange with the RAMP script that is impossible for a real human user to perform.
- RAMP scripts could sign on initially as a generic "USERX" whose initial program is the SJP program. The SJP program then presents a screen asking for the real user profile and password, which the RAMP logon script fills in and sends back. An IBM API is then called to change the current job's user profile from generic USERX to the real user. Again an encrypted exchange that is impossible for a real user could be used to confirm access is from a RAMP script.