DB2 at NWRDC
If you have any questions about the content of this page, please email DB2Request for clarification
This page covers the following topics:
- Current News and Projects
- Executing a Query from ISPF Edit
- Remote Access
- Subsystems
- Setting the Subsystem
- Naming Conventions
- Recommended Bufferpool Configuration
- Security
- Separation of Test and Production
- Version Notes
- Backup and Recovery
New Product Offering
NWRDC is now offering an in-house replacement for the now defunct DB/DASD product from IBM. The new product, called NW/DASD, provides similar functionality to DB/DASD. Please contact us with comments or suggestions on this new product.
If you have any questions please contact DB2 support at 850-245-3506 or email us at DB2Request.
Executing a Query from ISPF Edit
NWRDC created an edit macro that will allow you to run a query from an ISPF edit session. That way you don't have to back out and go through the DB2 main menu. Here's how it works:
Edit a member in a library and enter a query (no quotes, no semi-colon and nothing but a query), and then on the command line, enter DB2T for test (or DSN for production). Hit enter and your results will be displayed. PF3 to back out.
Keep in mind that if your result is very large, you will receive an out-of-space error. For queries that return a large result set, use SPUFI, QMF or some other method.
Remote Access
To set up a DRDA connection via TCP/IP, please email us at DB2Request.
Subsystems
Currently, there are two subsystems at NWRDC: one for test and one for production. The subsystem identifiers (SSID) for these subsystems are DB2T and DSN, respectively.
Setting the Subsystem
With the exception of SAS, the subsystem ID can be set at option 0.3 of the TSO/ISPF Information Center main menu, or at the DB2 Primary Option Menu, and this setting will carry forward to all interactive DB2-related products. These products include DB2I, BMC Tools, DASD, TMON for DB2, Access/Move, !DB/Workbench, and QMF. Once within some of these product sets, the subsystem can be changed for the duration of the product-related session. Batch jobs generated by these products will contain the applicable subsystem ID.
Batch jobs must specify the subsystem ID via the 'SYSTEM(xxxx)' parameter of the DSN command or other appropriate means. In addition, all batch jobs should contain two subsystem-specific libraries in the STEPLIB concatenation. In SAS, the subsystem is set via the 'SSID=xxxx' parameter (or the SSID field in windowing applications). Each test CICS environment will connect to the test DB2 subsystem and the production CICS environments will connect to the production DB2. Note: xxxx above equals DSN or DB2T.
Naming Conventions
Object naming conventions will follow the rules in the table below. The VCAT (VSAM Catalog) name is of particular importance. Each DB2 subsystem must have a unique VCAT name. If tablespaces and indexspaces are defined using stogroups, then customers can be assured of different VCAT names since NWRDC defines all stogroups. However, if you define your own spaces using IDCAMS, use extreme caution to ensure that the correct VCAT names are used.
Customers are encouraged to adopt their own standards for objects where user definition is permitted. The following standards are highly recommended: Object
| Type | NAMING STANDARDS |
| VCAT (prod) | iiiDB2P |
| VCAT (test) | iiiDB2T |
| DATABASE | iixxxxxx |
| STOGROUP | iixxxxxx |
| PLAN | iixxxxxx |
| COLLECTION | iixxx... |
| PACKAGE | xxxxxxxx |
| PROCEDURE | iixxx... |
| TABLESPACE | xxxxxxxx |
| TABLE | xxxxx... |
| INDEX | xxxxx... |
| VIEW | xxxxx... |
| SYNONYM | xxxxx... |
| ALIAS | xxxxx... |
i = institution code, x = user-defined, ... can be > 8 characters
Recommended Bufferpool Configuration
Please remember that it is up to you to maintain our recommendations for bufferpools.
BP0 - Catalog and Directory (NWRDC use only)
BP1 - Large tablespaces
BP2 - Large indexes
BP3 - Small tablespaces and indexes, such as code tables
BP4 - Primarily random-accessed data
BP5 - Reserved
BP6 - Reserved
BP7 – Workfiles (NWRDC use only)
Security
With the availability of test and production subsystems, it is strongly recommended that all database and application development be conducted on the test subsystem, then migrated to production.
Each organization will designate a primary database administrator. This DBADM will be granted the following authorizations in both test and production subsystems:
CREATEDBA WITH GRANT
BINDADD WITH GRANT
PACKADM WITH GRANT
USE OF STOSPACE UTILITY WITH GRANT
USE OF STOGROUP(S) WITH GRANT
Security/authority on the test subsystem should be somewhat unrestricted; however, it is recommended that security/authority on the production subsystem be restricted to the extent necessary for database security and integrity. Thus, database update and application plan bind/execute authority can be centralized and granted only to production accounts, DBAs and/or authorized and experienced users.
Separation of Test and Production
It is highly recommended that customers have both test and production versions of source, DBRM and load libraries with appropriate security and control over the production versions. With this setup, once an application has been successfully developed, tested and debugged, movement to production consists only of copying the source, DBRM and load modules from the test to the production libraries and then binding the plan and/or packages in the DB2 production subsystem. See ALTER for DB2 for considerations and recommendations regarding DB2 object migration between DB2 subsystems.
Version 10
Application and SQL incompatibilities between Version 8 and 10 can be found at IBM's web site.
Backup and Recovery
The DB2 log is maintained for 30 days. SYSCOPY entries are maintained for 60 days. Customers are responsible for image copy (full is recommended) and recovery procedures for their tablespaces.