How to block IMS TP transactions from being queued?
Select messages from
# through # FAQ
[/[Print]\]

MVSFORUMS.com -> Database

#1: How to block IMS TP transactions from being queued? Author: mvsmlk PostPosted: Tue Mar 01, 2016 4:36 pm
    —
Hello all,
How do you block or lock selected IMS TP programs from all users so that when they are invoked, they receive a message to the effect that they are not allowed to invoke the screen and the user’s screen does NOT lock up?
We do not want to encounter the situation where the /FOR tran command can be successfully issued, and that format screen is returned to the user. We also do not want a transaction to be queued on the message queue.
We have already tried /STO and /LOCK commands, and these do not seem to be the solution for us. When the format is invoked, a message is placed on the message queue and the user’s screen hangs until the transaction is /STArted or /UNLOCKed.

Thanks for your ideas.

#2:  Author: kolusuLocation: San Jose PostPosted: Tue Mar 01, 2016 5:00 pm
    —
mvsmlk,

How are you determining the users to lockout? Based on RACF or do you maintain a list of block user ids?

You may want to read the excellent article about IMS SECURITY BASICS

#3:  Author: mvsmlk PostPosted: Wed Mar 02, 2016 7:55 am
    —
Thanks for your response.
I am an IMS DBA, and not familiar with RACF security, although I know we do use it. Our IMS security is outsourced and apparently they are looking for an IMS based solution if there is one. The goal is to block all current IMS users from accessing a transaction without locking up their screen. One way I considered this was to have the transaction assigned to a different class which was not assigned to a message region, but that would queue up transactions and probably lock their screen, as they would be awaiting a response. Another more invasive solution might be to rename the transaction member in LOADLIB, so a S-806 abend might be generated. My thought is that this approach would not lock the user's screen or enqueue a message. I will forward your link on IMS security basics to them. In the meantime, if someone can come up with an IMS command based solution, that would be great.

#4:  Author: kolusuLocation: San Jose PostPosted: Wed Mar 02, 2016 10:33 am
    —
mvsmlk wrote:
Thanks for your response.
I am an IMS DBA, and not familiar with RACF security, although I know we do use it.


I would be surprised if IMS transactions did not use the RACF authority.

mvsmlk wrote:

Our IMS security is outsourced and apparently they are looking for an IMS based solution if there is one.


I am confused, if you are the IMS DBA wouldn't you be in charge of setting up the access?

mvsmlk wrote:

The goal is to block all current IMS users from accessing a transaction without locking up their screen. One way I considered this was to have the transaction assigned to a different class which was not assigned to a message region, but that would queue up transactions and probably lock their screen, as they would be awaiting a response. Another more invasive solution might be to rename the transaction member in LOADLIB, so a S-806 abend might be generated. My thought is that this approach would not lock the user's screen or enqueue a message. I will forward your link on IMS security basics to them. In the meantime, if someone can come up with an IMS command based solution, that would be great.


Look up /SECURE command and see if you can use it.

#5:  Author: mvsmlk PostPosted: Wed Mar 02, 2016 11:26 am
    —
Security is not handled by DBA in our shop. We have a security group which administers that for both IMS and for DB2. In addition, the IMS Security gens (new transaction and DB requests) are performed by a tech support group, and not by DBA. I will check the /SECURE command to see its uses. Thank you very much.



MVSFORUMS.com -> Database


output generated using printer-friendly topic mod. All times are GMT - 5 Hours

Page 1 of 1

Powered by phpBB © 2001, 2005 phpBB Group