MAINFRAME > Tips & Techniques > Miscellaneous

IMS Security Frequently Asked Questions

IMS is both a transaction and a database manager. IMS is used by most large corporations around the world for their primary day-to-day operations including core banking, package tracking, manufacturing parts inventory and ordering, insurance policy billing and claims, etc. You probably interacted with IMS today if you turned on a light, made a phone call or used an ATM or a credit card.

As businesses allow access to their IMS applications and data from anywhere including mobile platforms, securing IMS resources becomes even more important. In this article we’ll review some of the most frequently asked questions about security for an IMS online system.

In what follows, you will see references to the IBM security product RACF. Most of these RACF references also apply to ACF2, Top Secret and any other security product that conforms to the z/OS System Authorization Facility (SAF) interface specifications.

Securing the IMS House

To understand why IMS offers so many security parameters it may be helpful to picture the IMS online system as a house with many doors and windows. There are IMS resources like transactions, commands and data inside the house and a user gains access to the resources by entering through one of the windows or doors. For example, a user at a Virtual Telecommunications Access Method (VTAM) terminal enters through a different portal than an Open Transaction Manager Access (OTMA) client like IMS Connect. IMS offers a unique parameter to secure each point of entry and each parameter has several possible settings corresponding to the available security facilities like RACF and IMS exit routines.

You’ll want to identify the points of entry in your IMS system, decide which ones need to be secured and choose the method(s) to secure them. Each point of entry is secured independently of the others.

Figure 1 illustrates points of entry (the “windows”), the corresponding security parameter (the “locks”) and the location of the security parameter. All parameter values can be changed with an IMS warm start except the RCF parameter, which requires an IMS cold start to change.

Unauthorized Access Gatekeeper

Even before a user can get through a window in the IMS house, the user needs to pass through a gate leading to the house. You might think of it as an “APPL Gate” because it can be secured using the RACF APPL resource class.

When you request sign on verification for terminal users, IMS calls RACF to verify that the user ID and password are valid. This is called the RACINIT request. In this call, IMS identifies itself to RACF by passing an application identifier so RACF can check the user’s authorization to access the application identifier. The application identifier defaults to the IMS ID but you can define an alternate identifier using the IMS SAPPLID parameter. If you protect the application identifier in the RACF APPL class and the user is not authorized, sign on fails and the user does not get through the gate.

It is important to realize that dependent regions are not subject to any authorization checks unless you activate IMS Resource Access Security (RAS). Dependent regions include message processing program (MPP), batch message processing program (BMP), Java batch processing program, Java message processing program, IMS Fast Path regions, CICS, DB2 stored procedures, etc.

When you set the ISIS parameter to activate RAS, RACF checks whether a dependent region is authorized to connect to the IMS ID. Note that SAPPLID is not used for dependent regions. If you protect the IMS ID in the RACF APPL class and the dependent region is not authorized, dependent region start up fails and the region does not get through the gate.

If you specify a value for the SAPPLID parameter that is different from the IMS ID, you have the option to force terminal users and dependent regions to go through different gates. For example, you could authorize a user to submit a BMP but not to sign on to IMS.

How was an unauthorized user able to update a production database? A programmer testing a BMP accidentally submitted the BMP to the production IMS and RAS security was not active. Without RAS, no check was made to see if the BMP, submitted from Time Sharing Option (TSO) with the programmer’s user ID, was authorized to connect to the production IMS ID. RAS security or some other control like a z/OS exit, RACF Program Control or a job scheduling product can be used to help prevent jobs from connecting to the wrong IMS or running on the wrong LPAR.

Understand the User ID

SAF security products like RACF require a user ID for resource authorization checks. Sometimes you might see RACF security violation message ICH408I for a user ID you don’t expect and can’t explain. Let’s look at some examples.

Why is the user ID the IMS Control Region?

If a user does not sign on, IMS has no user ID to pass to RACF, and RACF will use the IMS Control Region user ID for the authorization check. To avoid this situation, you can specify automatic sign on for any static terminals that can’t or won’t sign on, including the IMS Master (MTO) and the System Console (WTOR).

Why is the user ID a Logical Terminal name (LTERM)?

When a transaction is successfully authorized and queued for processing, IMS puts a user ID in the message prefix to be carried along and used for any further resource authorizations like DL/I CHNG or AUTH calls. If the user didn’t sign on, IMS places the user’s LTERM in the prefix. To avoid this situation you can enforce sign on or you can define the LTERM to RACF as a user.

Why is the user ID a program specification block (PSB)?

If a non-message driven (NMD) BMP issues a CHNG call to spawn a new transaction, the user ID placed into the new message prefix will be the BMP’s PSBNAME. You can define the PSBNAME to RACF as a user or you can set BMPUSID=USER to tell IMS to take the user ID from the BMP JOB statement instead of the PSBNAME. The BMPUSID parameter applies only to NMD BMPs.

Why is the user ID the dependent region’s user ID?

If an IMS program calls DB2, IMS passes a user ID and group name to the DB2 sign-on exit. The DB2 exit can call RACF to verify the user ID. Alternatively, with DB2 enhancement PM27835 (RSU1112), DB2 can avoid the RACF verify call and instead directly access an already-verified user ID control block, the for Access Control Environment Element (ACEE), that was built in the IMS dependent region. However, the ACEE in the dependent region normally represents the dependent region’s user ID, not the end user’s ID. You can tell IMS to create an ACEE for the end user in the dependent region by setting Advanced Peer-to-Peer Communication (APPC) and OTMA security to FULL for transactions from OTMA or APPC (OTMASE=F or APPCSE=F). For all other transaction sources you can use the IMS DFSBSEX0 Exit routine to tell IMS to create an ACEE for the end user in the dependent region. (DFSBSEX0 Reg15=04)

Maida Snapper is an IMS Specialist at IBM and can be reached at

Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.

comments powered by Disqus



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.


The Importance of Business Rules Mining


Change Management: Approval Must Be Earned


Making Changes: Prudence and Discipline Always

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters