Before You Begin
Keep the following in mind before you begin setting up and administering Infor Lawson System Foundation with DB2 for OS/390:
User Naming Conventions
On OS/390, IBM DB2 allows a maximum of seven characters in a user or group name. The first character of user IDs must be A-Z, # (X'7B') $ (X'5B'), or @ (X'7C'). For more information on user naming conventions, see the IBMÂ DB2 Security Administrator's Guide.
OS/390 Limits
The complete listing of IBM DB2 limits for OS/390 is available in the DB2 for OS/390 SQL Reference Guide.
OS/390 Locking Issues
Only one of the dbcreate, dbreorg, and buildibmddl commands can be run against an OS/390 database at any given time. If multiple people concurrently run these commands against a single database, they encounter deadlock. Because of this problem, Lawson recommends that you use a different OS/390 database for each productline.
EDM Pool Sizing
Lawson recommends ensuring that the EDM pool is large enough to handle DBDs. Any DBD which is more than 25% of the size of the EDM pool fails to load. You can also receive failures if other applications are sharing the EDM pool. This sizing is dependent upon the number of installed Lawson products that you are utilizing. For EDM pool size calculation formulas and for more information on EDM pool sizing, see the DB2 for OS/390 Installation Guide.
Dynamic SQL Caching
Dynamic SQL caching stores prepared SQL statements in the EDM pool and searches for a match with subsequent prepares, reducing the cost of the prepare if it is found. If it is not found, a prepare is done and the pool is flushed on an LRU algorithm to make room for the new skeleton package. The SQL statement must match exactly to take advantage of the caching functions. To enable dynamic SQL caching, the DSNZPARM CACHEDYN=YES parameter must be defined.