Controlling the User Experience in IBM i Access Client Solutions

Nathan Williams, iTech Solutions

With Client Solutions now being the only IBM-supported client software for IBM i, quite a few organizations have made the switch from the old iAccess products or are in the process of doing so. ACS is as flexible as the old application was rigid, and there are many different ways to configure it on a PC. One of the recurring questions we get from clients who are planning the switch relates to controlling what the end-user can see and use within the application. To address this,  I’d like to discuss a bit about how ACS does configuration under the hood and how administrators can have some control over what can be accessed within the application.

The ACS Main Menu, a buffet of fun and foibles for your users.

Unless launched from a shortcut directly to one of its components, Client Solutions opens by default to a unified main menu that is drastically different from the experience found in the previous generation. Where Client Access simply relied on your PC operating system to present its components in whatever form (Start Menu, Applications folder, etc.) was available, ACS now provides easy and convenient links to all of its features from a single panel with tooltips and explanations for each. This can be both a blessing and a curse for users and administrators alike; while it is now much easier to find tools that you may not have even known were available, it is also easier to stumble upon features that may not be appropriate for all users or simply to become overwhelmed with all of the options presented. Fortunately, IBM has included a way to customize ACS’ behavior.

Questions, questions. This one seems important for some reason.

If you’ve ever run one of the provided ACS installation scripts on a Windows PC, you’ll probably recall being asked a ton of questions during the process. These questions correlate to each of the main components of ACS and your answers determine what options appear on the main menu once the product is set up. These settings are not just cosmetic—the configuration is checked even if the application is launched through a shortcut directly to an individual component and if that feature has been disabled then the shortcut won’t work. For example, if I were to answer “No” to the question about 5250 emulation during setup and then try to double-click a .hod file later on, I would receive an error message instead of a green screen. This is especially useful for components like console access or database tools, as these items are only intended for certain audiences.

So, what do you do if you want to change your configuration after the fact or customize it for deployment to a group of users? Easy! What the install script is actually doing in the background during “installation” is building a customized .properties file which is then read every time ACS is launched to configure the application. The resulting file, named, is stored in the same directory as the ACS application itself and can be examined with any text editor. There’s a lot more than just component customization in this file, but for now, we’ll focus on that section, which you’ll find about ⅓ of the way down from the top.

There are two properties we can manipulate here: and

The .properties file in its native habitat ExcludeComps is used to list any components that you want to disable, hiding from the GUI and preventing access on this PC. IncludeComps is used in the opposite case when you wish to enable only a specific set of components and disable everything else. Obviously, these settings are mutually exclusive—it only makes sense to use one or the other, not both. Below are two example configurations. The first one will allow the user access to all of ACS except for console functions, which is probably a useful starting point for a trusted developer. The second one will allow access only to the 5250 emulator and printer output, a restrictive setup representing an end-user with a very specific role or need.,HWCONSOLE,SPLF

More examples are included in the file itself, along with a list of common components and further explanation of how these properties actually work. For anyone unfamiliar with the structure of a .properties file, it is worth noting that any line that begins with a number sign (#) is a comment that won’t actually be interpreted when ACS launches. You may need to un-comment one of the examples or copy it to a blank line in order to actually use these settings.

This really just scratches the surface of what ACS can do on the customization front. The rest of the file is also well-documented and worth a read if you’re planning a complex deployment of ACS. Decisions can be made here about how the end-user PCs store their own settings and sessions, which can come in very handy if you decide to deploy ACS centrally rather than install it individually on each PC. By setting up multiple files and deploying them appropriately, the savvy administrator can provide a customized experience for each group of users that provides only the tools they need and restricts sensitive functions, all while only needing to maintain a single, centralized copy of the ACS software and system configuration files. This simplifies future client upgrades, increases security, and reduces maintenance complexity should configuration changes ever be needed.

Of course, if you find yourself still a little lost in all of this, iTech Solutions can always help. We’ve done countless ACS upgrades and deployments over the years and can help you construct a plan that works best for your environment.

Leave a Comment

Your email address will not be published. Required fields are marked *