The best way to secure ODBC (and other services) is to secure your AS/400 objects using standard AS/400 security. Exit programs are nice for many things, but they aren't very good for security. There are two reasons for this: 1) They usually only secure a single method of accessing the database. For example, if you write an ODBC exit program, it does nothing to prevent access via Query/400, DFU, FTP, CA network drives, etc. 2) Most (if not all) third-party ODBC drivers don't use IBM's exit points. Further, you can download free trials of many of these drivers from the Web. A better solution (IMHO) is to grant your users the level of access you want them to have at their profile level (i.e. read-only) and then use AS/400 adopted authority to give them the access they need when they are running AS/400 apps that need to update data. If you need to update from ODBC, use stored procedures, which can use adopted authority.

---

I limited access to ODBC with an exit program at exit point QIBM_QZDA_INIT. This exit program retrieves info and checks whether a user is authorized to use ODBC or not. If the user is authorized to use ODBC we don't allow update, insert, create, delete or expand functions. An other exit program manages this on exit point QIBM_QZDA_SQL1. Whenever a violation is made (ODBC, RMTCMD etc.) a record is logged. However, keep in mind that by using exit programs (especially the SQL program I wrote, because every command is checked) doesn't contribute to performance... But I think security is more important. Tips: - Use WRKREGINF to define or change Exit points - Use DLTPGM to remove earlier versions of the Exit program. On V3R6 I had some problems with newer versions of the exit programs. Even when I deleted the exit program, the exit program was still functioning! The problem was solved when I first removed the program from QRPLOBJ. Afterwards I compiled the exit program. - Use *OWNER while compiling the exit program (adopted authority)

---