Magda, have you found what you need, yet?
I did this many years ago. It is simple… the 2nd time you do it!
Exit points are simply “interrupts” that IBM supplies. You can attach programs to them, and the programs will automatically run at that point. For setting your AS/400 up to accept FTP logons, for example, the exit point is:
QIBM_QTMF_SVR_LOGON and the format you wil use is: TCPL0100.
A program inserted there can control WHO can log on, and when.
To control WHAT they can do, you use another exit point, QIBM_QTMF_SERVER_REQ and use format VLRQ0100.
My notes (from 1999) say I used the IBM TCP manual to get this info, specifically: TCP/IP manual SC41-5420-01 page I-14.
I do not know if it will allow me to post code here, it is long and complex due to the number of variables and some of them being in hex.
Write me (firstname.lastname@example.org) if you would like me to email you my program code.
WAXIE Sanitary Supply
San Diego, CA
This is a link for <a href=”https://addons.mozilla.org/en-US/firefox/”>Add-ons for Firefox</a>. These are programs written by users or developers that the browser knows how and when to call. The developers of Firefox designed it to allow external programs to be hooked in by users of the browser.
IBM did something similar for a lot of the TCP/IP and other server functions. (And a lot of other things.) When you connect to the FTP server for example, the server checks to see if a program has been registered to process FTP logon requests. The registered program is an ‘exit program’.
Browser add-ons get an entry added to a file someplace within the browser directory structure. In your iSeries, the entry would be added to the Registration Facility. (Not always, but that’s the commonly recognized object for exit points and programs.) Use WRKREGINF to review your registration facility.
To create an exit program, you need to know the parameter list that will be passed to your program and the exit protocol. To find the parameter list, you should start looking at the documentation for the server the exit program will be associated with. The protocol, the meanings of the parms and what to with them, is also there.
A FTP exit program would be structured after documentation within the <a href=”http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzaiq/rzaiqreferenceexit.htm”>File Transfer Protocol exit programs</a> topic of the Information Center for your release.
Once registered, a server logon exit program (for example) would be called just before the server decides whether or not to accept the logon. Your exit program directly influences that decision by returning an ‘accept or reject’ parameter. It chooses based on examination of the input parms.
The exit program may control who can and cannot logon, where they may logon from, what times of day logons are accepted, or it might accept all logons — its purpose can be simply to write all logons to a log file or to send a message when particular logons happen. Your exit program can do whatever it is programmed to do at that point in the logon process.
It doesn’t have to be a ‘security’ function. It’s whatever you want it to be.
For the FTP server, there are two general exit points. One is just before a logon is accepted. The other is just before each transaction in a session is processed. You can control individual transactions just as you can logons. (FTP client has its own exit points.)
Most other exit programs work on similar principles.
A few issues complicate things.
<li>An exit program needs enough authority to do whatever it needs to do; it can’t always rely on the authority of the session user.</li><li>An exit program shouldn’t unduly delay transactions; there’s no way to know how often an exit program may be called, so you don’t want it slowing down every single transaction.</li><li>Exit programs may be called by many instances of a server at the same time; it shouldn’t be locking things that are needed by a different instance.</li><li>IBM changes the interfaces at times and the servers themselves can get PTFs; regular, on-going maintenance can be needed — keep the programs direct with little complication.</li><li>There are other issues, but those are enough to consider.</li>
Code a very simple exit program that accepts the parms and returns an ‘Accept’ indication. Don’t have it do anything except maybe send a message to a message queue. That lets you see how the registration facility works and how the parms work. It also gives you a program that you can register and deregister in the future to check whether or not the server is stilling calling your program correctly. (Problems can happen.)