How to Peer Into TurboIMAGE databases

I am looking for a way to permit ordinary users (programmers and support staff) to see who is using a TurboIMAGE database, and what locks are in effect and are pending -- the information you would see with DBUTIL using SHOW ... USERS and SHOW ... LOCKS or SHOW ... ALL.

I have to work within these constraints:  (1) Can’t let them log on with SM capability.  (2) Can’t let them log on as the database creator.  (3) Can’t reveal the password on the MPEX GOD program.  (4) Can’t reveal the password on DBUTIL. Is there a utility to do this?

Eric Sand replies

To keep things simple, I would just create a “RELEASED” job that can execute DBUTIL with the proper passwords to the DB that you want to examine and direct the output to a file that anyone can read.

The job that wants the locking info would stream this DBUTIL job using the “COMMAND” intrinsic and then parse the output file. This could be done by the “CALLING” program repeatedly if needed and report its findings. Each file could be created unique by composing its name based on a sequential numbering scheme from the results of a LISTF.

Comments

How to Peer Into TurboIMAGE databases

I am looking for a way to permit ordinary users (programmers and support staff) to see who is using a TurboIMAGE database, and what locks are in effect and are pending -- the information you would see with DBUTIL using SHOW ... USERS and SHOW ... LOCKS or SHOW ... ALL.

I have to work within these constraints:  (1) Can’t let them log on with SM capability.  (2) Can’t let them log on as the database creator.  (3) Can’t reveal the password on the MPEX GOD program.  (4) Can’t reveal the password on DBUTIL. Is there a utility to do this?

Eric Sand replies

To keep things simple, I would just create a “RELEASED” job that can execute DBUTIL with the proper passwords to the DB that you want to examine and direct the output to a file that anyone can read.