Keep the following basic considerations in mind when using memorized transactions.
- Captured transactions are always for a specific user. You can change the server properties to capture transactions for the server. However, the user recorded in the captured transaction is the user who attempted the transaction, not *PUBLIC.
- Captured transactions are always specific for a server function. Many of the servers that Exit Point Manager protects have more than one function. For example, the FTP server has several functions including SENDFILE and RECVFILE. You can change the server properties of the FTP server to capture transactions, but when the transaction occurs, the captured transaction specifies the exact function that was requested.
- Exit Point Manager recognizes a transaction as matching a memorized transaction only if the transaction data strings match exactly (except for generic strings specified using the % character).
- For example, although the following SQL statements produce the same query, the requested transaction does not match the memorized transaction because the fields are specified in a different order.
- Requested transaction: SELECT custno, name, payrate from Production/PAYROLL01
- Memorized transaction: SELECT custno, payrate, name from Production/PAYROLL01
- You can enter memorized transactions manually. In addition to capturing and memorizing transactions, you can enter transactions by typing the transaction string using the green screen. However, because you are entering the entire transaction string, it is important that you double-check the string contents and spelling to make sure it is accurate. Exit Point Manager memorized transactions perform an exact string match, and thus rely on the quality of the memorized transaction string.
- Memorized transactions are case-sensitive. Because the comparison to a memorized transaction string must match exactly, it is case sensitive. If you are modifying a transaction string or entering a string manually, be aware of the case of the string contents. If the match isn't exact, the rule is ineffective.
- Capturing transactions for some servers doesn't make sense. Capturing and memorizing transactions for some servers doesn't provide any additional security than does a user, location, or object rule. In general, you don't need to capture transactions for servers that don't provide any user transaction data. For example, when a transaction occurs through the Signon Server, no transaction data is provided. All you can do is control whether a user or group is allowed to use the Signon Server. Thus, you do not need to use a captured/memorized transaction to control the Signon Server. You can control the following servers and functions effectively with a user or location rule instead of using a memorized transaction.
Server Function *SQL All *SIGNON All *FTPSIGNON All *REXEC_SO All QNPSERVR INIT *FTPCLIENT INIT *FTPSERVER INIT
Performance Considerations
Using memorized transactions may add some overhead to the authority checking routine performed by Exit Point Manager. However, performance is affected only while executing the specific function for the particular user or location. The extent to which performance is affected depends on a number of variables, including CPU utilization.
Previous 