How do I determine if a job on the AS400 is passed through from another AS400?
I'm trying to prevent users from passing through from iSeries A to iSeries B and then passing through to iSeries A again. Is there a way that I can programmatically determine if the user is passed through from a remote iSeries so that if they are, I can display an error telling them to end their passthrough first?
ASKER
The problem is with general users. They have menu options that do a STRPASTHR to the other system. They initially only sign on to A and then pass through to B.
One thought:
On the target system(s), create a Device Selection Exit Point program that assigns identifiable names to pass-though jobs to differentiate them from TELNET jobs. For example if you assign TELNET jobs a TELN prefix and pass-through jobs a DSPT prefix, then you can easily determine how the user entered the system. You could then add a validity-checking program to the ENDPASTHR command (or create your own version of ENDPASTHR) that incorporates a job name check (RTVJOBA), and returns the proper message, if needed.
Since the advent of good Telnet support on the AS/400, I don't use pass-through much any more, and I can't think of an easy way to programmatically identify a pass-through job. Look at the top of the job log of a pass-through job. Is there a specific message that you might be able to retrieve that indicates a job came in as a pass-through request? If so, then you could just attempt to receive this message (RCVMSG command) in your validity-checking program or custom ENDPASTHR command processor.
- Gary Patterson
On the target system(s), create a Device Selection Exit Point program that assigns identifiable names to pass-though jobs to differentiate them from TELNET jobs. For example if you assign TELNET jobs a TELN prefix and pass-through jobs a DSPT prefix, then you can easily determine how the user entered the system. You could then add a validity-checking program to the ENDPASTHR command (or create your own version of ENDPASTHR) that incorporates a job name check (RTVJOBA), and returns the proper message, if needed.
Since the advent of good Telnet support on the AS/400, I don't use pass-through much any more, and I can't think of an easy way to programmatically identify a pass-through job. Look at the top of the job log of a pass-through job. Is there a specific message that you might be able to retrieve that indicates a job came in as a pass-through request? If so, then you could just attempt to receive this message (RCVMSG command) in your validity-checking program or custom ENDPASTHR command processor.
- Gary Patterson
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
With researching this problem on a variety of different forums, I was acutally in the process of testing a similar solution without any luck. The other idea I was testing was to use the 'QDCRDEVD' API to return information about the device the session is running on. I was looking at another part of the returned data structure, but it also returns the IP address, and, as you suggested, the IP address it returns is blank when the session is passed through from another system. Thanks for your help!
PS the sample code that I used came from the following article by Shannon O'Donnell:
http://www.itjungle.com/mpo/mpo011702-story02.html
PS the sample code that I used came from the following article by Shannon O'Donnell:
http://www.itjungle.com/mpo/mpo011702-story02.html
I tend to use the job info rather than device info for this because the same code can be used in any job, not just interactive jobs. (The sample code I supplied is only for test/verification.)
Regardless, actual "production" code needs to be more sophisticated. The first thing you might run into will probably be IPv6 connections. It might not matter now, but it will need to be considered probably Real Soon Now.
Tom
Regardless, actual "production" code needs to be more sophisticated. The first thing you might run into will probably be IPv6 connections. It might not matter now, but it will need to be considered probably Real Soon Now.
Tom
Also, do users initially sign on to both A and B and then pass-through to the other? Or do they always sign on to A first? (There are probably always a few special user profiles who are expected to sign on either way, but I assume that your problem is with general users.)
Tom