How can I restrict access to users through Datacom Server?
search cancel

How can I restrict access to users through Datacom Server?

book

Article ID: 26873

calendar_today

Updated On:

Products

Datacom DATACOM - AD

Issue/Introduction

I have encountered situations in Datacom Server where user queries generate significant exclusive control conflicts and cause processing delays. How can I restrict access to users through Datacom Server?

Resolution

Datacom Server provides two user exits, CONEXIT and SECEXIT, which are invoked during a connection attempt and can be used to restrict access to Datacom Server. However, at this time the only information available to these exits is a userid and password. The application name or process name is not available as a connection parameter.

The Microsoft Driver Manager routes requests to Datacom Server, but it doesn't provide the origin of the request. We cannot distinguish the application from which it comes.

However, there is a way to manage unauthorized users from holding records for exclusive control, thus locking up your system. First, if you code LOGON=YES in the mainframe Server startup, Datacom Server issues calls to your external security package to validate the userid and password on a connection. This way, you can revoke their logon ID in your external security system or you can use one of the security exits mentioned earlier.

Another possibility is to direct these users to a read-only Datacom Server region. In the mainframe Datacom Server startup parameters, set ACCESS=R and ISOLEVEL=U. ACCESS=R designates the region as read-only such that any update request will be revoked by the mainframe Datacom Server region. ISOLEVEL=U sets the SQL Isolation Level to U for uncommitted data. No row-level data locks will be placed on requests from this region. In other words, the requests from this region will be allowed to make read accesses to uncommitted data, but it will not place any locks on the accessed rows. Normally, in SQL processing, if a task has a "read" lock on a row, another task will be prevented from updating that row until the "read" lock is released. Likewise, if a task has a row locked for update, a read-only task will not be able to read it until the lock is released by a commit or rollback. One warning is that with ISOLEVEL=U, a transaction can access data that includes non-committed updates. You must decide whether this is acceptable for your applications.