How do I interpret the DB00220I messages that are issued at startup?
search cancel

How do I interpret the DB00220I messages that are issued at startup?

book

Article ID: 14977

calendar_today

Updated On:

Products

Datacom DATACOM - AD CIS COMMON SERVICES FOR Z/OS 90S SERVICES DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS COMMON PRODUCT SERVICES COMPONENT Common Services CA ECOMETER SERVER COMPONENT FOC Easytrieve Report Generator for Common Services INFOCAI MAINTENANCE IPC UNICENTER JCLCHECK COMMON COMPONENT Mainframe VM Product Manager CHORUS SOFTWARE MANAGER CA ON DEMAND PORTAL CA Service Desk Manager - Unified Self Service PAM CLIENT FOR LINUX ON MAINFRAME MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME GRAPHICAL MANAGEMENT INTERFACE WEB ADMINISTRATOR FOR TOP SECRET Xpertware

Issue/Introduction

A CA Datacom Multi-User Facililty (MUF) can be secured by defining external security. There are 10 possible access paths to Datacom databases, and when external security is enabled access through all of these 10 paths is always turned on. The MUF parameter SECLVL allows users to specify different levels of granularity for that security, so that different authorizations can be specified if desired. 



How can I interpret the text of the DB00220I message that appear at MUF startup?

DB00220I EXTERNAL SECURITY ACTIVE FOR cxxname ON product WITH resource class

Environment

The DB00220I messages are issued in any CA Datacom MUF that has external security enabled.

Resolution

A client may not be aware of which security level they are running, so each path which is secured will be reflected in a DB00220I message. This would mean at LEVEL 01, where all paths are secured via the DTTABLE class, if you turn external security you will see ten messages, one for each path, each one indicating DTTABLE is being used to secure the path.

For example, external security at LEVEL01 indicates that a user ID will have the same access rights to a table regardless of the means of access. In other words, a user accessing a table using navigational requests had the same access rights using SQL. As the SECLVL gets higher, more granularity and a finer level of control is introduced. So the higher levels are not securing more entities, because all entities are secured whenever external security is enabled. The higher SECLVL values allow the client to define different authorizations for the different paths through which data can be accessed. 

LEVEL02 provides two security paths, one for navigational and one for SQL. Thus, a user could have different access rights to a table depending on the type of commands being used. LEVEL03 and LEVEL04 provide separate security rights for requests coming from Advantage CA-Dataquery for CA-Datacom, depending on whether the requests came through CICS or batch Advantage CA-Dataquery. The six path codes at LEVEL03 are: 

Path Code        Application         Command Type 
RCI                  CICS                  Navigational 
RSR                 Server               Navigational 
RAT                 Other                 Navigational 
SCI                  CICS                  SQL 
SSR                 Server                SQL 
SQL                 Other                 SQL 

LEVEL05 introduces 4 new paths to distinguish between whether a Dataquery (DQ) request is originating from Batch or CICS, and whether the query is navigational or SQL. Again, this is not where DQ security is introduced, but where it is refined. At lower levels (such as Level03), Dataquery requests are included in these 2 paths from the list shown above:

Path Code        Application         Command Type 
RAT                 Other                 Navigational 

SQL                 Other                 SQL 

So when security is implemented at LEVEL03, you will see the messages below indicating “SQL OTHER” and “RAT OTHER”, reflecting the Path Code and APplication from this table: 
DB00220I - EXTERNAL SECURITY ACTIVE FOR TST8CXX ON SQL OTHER DQ WITH DTTABLE 
DB00220I - EXTERNAL SECURITY ACTIVE FOR TST8CXX ON RAT OTHER DQ WITH DTTABLE 

This means that SQL other will use the same security for both DQ and non DQ paths. The DQ paths are secured at level 03, just not in separate resource classes. At LEVEL05, you can specify separate resource classes for these if you like because the following 4 additional paths were introduced:

Path Code        Application                         Command Type 
RAQ                Batch CA-Dataquery            Navigational 

RCQ                CICS CA-Dataquery             Navigational

SCQ                Batch CA-Dataquery            SQL 

SQQ                CICS CA-Dataquery             SQL

So with SECLVL=05, the messages could indicate 

DB00220I - EXTERNAL SECURITY ACTIVE FOR TST8CXX ON RAQ BATCH DQ WITH DGTABLE 
DB00220I - EXTERNAL SECURITY ACTIVE FOR TST8CXX ON SQQ CICS DQ WITH DQTABLE

Note the differences in Path name and security table classes reflected in these messages.

So, to summarize, all 10 security paths are always enabled whenever external security is enabled for a MUF. The contents of the DB00220I will specify the specific Path Code and Application used for the access, and the Security table Class that was used to process the request.  

 

 

 

 

 

 


Additional Information

Further information about CA Datacom security implementation can be found in Knowledge Document TEC355380.

Information on implementing security can be found in the CA Datacom Security Overview manual, which can be found on the CA DocOps site using this link: 

https://docops.ca.com/ca-datacom/15-1/en/administrating/security-overview