First introduced in May 1999, IBM’s AS/400 Client Access Express for Windows (Express client) just passed its second birthday with the release of its third official version, Express client V5R1M0. And like any two-year-old, Express client is finding itself in a lot more places than it did when it was initially introduced. As more people have migrated from the original Client Access for Windows 95/NT product (the Windows 95/NT client), there is more need for good, solid information on how to improve Express client performance on both the server and the client side than existed in 1999.
Given this, take a few minutes to look at some of the issues involved in tweaking Express client performance. Even though I’ll discuss some exciting new capabilities with Express client V5R1M0 and OS/400 V5R1, a number of the adjustments I’ll talk about here are base Express client capabilities that were built into the product in its original release in 1999, and haven’t changed much since. That means if you’re running any of the three Express client versions—V4R4M0, V4R5M0, or V5R1M0—you can find some valuable performance tips here.
Just Add an Upgrade or Service Pack
The most obvious Express client performance tip is to upgrade your installation. If your shop is still using the Windows 95/NT client, there are few excuses for not using Express client, provided your network is configured for TCP/IP (Express client’s only protocol). Express client does not support SNA or any other networking protocol, and that makes for a more stable product. And for desktop stability and performance, there are far fewer automatic daemons running in the Windows desktop background, such as the network printer redirection program that the Windows 95/NT client used for network drives and network printers. (Note, however, that this functionality can still be incorporated on Express client desktops through the use of the AS/400 NetServer; see www-1.ibm.com/ servers/eserver/iseries/netserver/index.html.)
Express client has matured to a nice, stable code base, and replacing the last holdout Windows 95/NT clients will result in an instant performance improvement on those desktops. Furthermore, IBM has been almost religious in putting out Express client Service
Packs, and each Service Pack delivers fixes to the product that are designed to make it more stable. For the most recent information on Express client Server Packs, see the Client Access Service Packs Web site (www-1.ibm.com/servers/eserver/iseries/clientaccess/ casp.htm).
Making the Right Connection
The first place to adjust Express client performance parameters is on the Express client Connections Properties panel, as pictured in Figure 1. The connection properties on this panel, accessed from within AS/400 Operations Navigator, are used by most Express client programs. To access your Express client connection properties, open Operations Navigator and right-click on your target iSeries or AS/400. From the pop-up menu that appears, select Properties and then click on the Connection tab on the Properties screen.
On this screen, you’ll see three parameters that can affect the desktop performance of Express client.
The first parameter, the Use Secure Sockets Layer (SSL) check box, is only in effect when you’re connecting to an OS/400 V4R4-or-above machine and SSL is enabled on that machine. If SSL is not enabled on the target iSeries or AS/400, this box will be grayed out. For Express client V5R1M0, this option has been migrated to a separate Secure Sockets tab on the Properties screen; this new V5R1M0 SSL properties screen contains more options than the Connection properties screen found in Express client V4R4 and V4R5.
When Use Secure Sockets Layer (SSL) is checked, your Express client connection is protected through the use of encryption technology. Encryption will slow down your connection somewhat, but IBM reports that the effect is not as noticeable as you think. But if you need encrypted sessions, then you have no choice but to live with the overhead.
The second parameter that can affect your Express client performance is IP address lookup frequency. This drop-down box specifies whether or not OS/400 should cache the IP address for your target machine and how often the cache should be refreshed. The options range from always to never, with additional options for refreshing the address after startup: once an hour, once a day, or once a week. For all options except Never, Express client will query a Domain Name System (DNS) server to resolve your iSeries or AS/400 IP address at the designated time. Selecting Always (which is the default value) means that for every connection attempt to the target iSeries or AS/400, including data transfer and ODBC, Express client will query the DNS server to resolve the IP address.
The IP address lookup frequency parameter can impact Express client desktop performance, but its effect on performance depends on which Express programs the user is running. If you specify Always and the user only connects to OpsNav once in the morning, the effect on performance is probably negligible, because it would only result in a single DNS query. However, if your Express client machine is running an ODBC application that is continually connecting and disconnecting ODBC sessions, the Always setting could have a significant impact on performance, because each DNS query to refresh the IP address could take several seconds to resolve (depending on your environment). Generally speaking, if your iSeries or AS/400 IP address rarely changes, then you should modify this property to contain a larger value, such as once a day or once a week.
If you set IP address lookup frequency to Never, you must also manually enter the target machine’s IP address in the associated IP address value on the Connection properties screen. This field is grayed out for all other lookup frequency settings (as shown in Figure
1). The Never setting completely eliminates the overhead associated with using a DNS server to resolve OS/400 IP addressing, because the address is hard-coded into your OpsNav configuration. Of course, if your OS/400 IP address actually does change—because of a change in subnets or a replaced network card, for example—then you would have to go to every machine and manually change the IP address again. So your best bet is to occasionally refresh the IP address cache on your Express client machines by
using a value that minimizes the impact on system performance. Therefore, changing this value to One Day or After Startup is best for meeting these goals.
One final note on this parameter: If you set IP address lookup frequency to Never, you may also need to add an entry to your Windows PC HOSTS file that associates the proper IP address with a host name. This is because the lookup frequency parameter has no effect on Express client’s PC5250 function, so an additional entry in the HOSTS file may be required for PC5250 support when this parameter is set to Never.
The third parameter that can affect your Express client performance is Where to look up remote port. This drop-down box specifies where Express client should retrieve the remote TCP/IP port number of any OS/400 server that your PC communicates with for a specific function. The choices are Server, Standard, and Local. The default is Server, which means that whenever Express client needs to connect to an OS/400 server, it first queries the Port Mapper (port 449) on your target iSeries or AS/400 to determine the port number for the server that it’s sending a request to. Like the IP address lookup query to a DNS server, this query could also add a few seconds to your processing time, depending on the type of connection you are attempting and the speed of your connection. If your iSeries or AS/400 is using the standard TCP/IP ports for all its servers, you can improve Express client performance by changing the default to Standard, which will eliminate the call to the Port Mapper and automatically map all IP requests to the standard OS/400 ports for each requested function.
You can also eliminate Port Mapper calls by changing the Where to lookup remote port parameter to Local. This accesses the Windows SERVICES file on the Express client PC to retrieve the target port numbers. This means that all your desired OS/400 port numbers must be entered in the Windows SERVICES file on the local PC, or the target Express client functions won’t be accessible to your user. Doing this would involve a maintenance penalty in keeping your SERVICES files in sync with your OS/400 ports.
A second problem with using either Standard or Local for the remote port parameter occurs when you change the port numbers on your iSeries or AS/400 to thwart hackers. If you do this and you’re using either the Standard of Local setting for the remote port parameter, then you might also need to change the port setting in your user’s SERVICES file or change the remote port settings value to Server to ensure your client could access the proper port.
The bottom line on this parameter is that, for best performance and lowest maintenance, it should usually be set to Standard. However, when standard TCP/IP port changes occur on your iSeries or AS/400, you may be forced to change this value to Server and endure the overhead associated with the change.
TCP/IP Settings in OpsNav and New Command-line Utility
As shown in Figure 2 (page 43), there is a Settings panel inside OpsNav that contains several different TCP/IP configuration settings that you can tune for overall performance of your Express client installations (note that this panel changed between Express client V4R4M0 and V5R1M0, so you may see some different options, depending on which client
you are using). To reach this panel, right-click on TCP/IP Configuration under your iSeries or AS/400 in OpsNav, select Properties from the pop-up menu, and then click on the Settings tab on the TCP/IP Configuration Properties screen. On this screen, you’ll find several important TCP/IP performance parameters, including TCP keep-alive time, TCP send-and-receive buffer sizes, IP reassembly timeouts, TCP R1 and R2 retransmission values, and timewait timeout value. You can experiment with these parameters to increase performance or decrease bandwidth requirements.
In addition to these settings, IBM is providing a new command-line (DOS prompt) utility tool called CwbCoPwr, which is now being shipped with Express client V5R1M0. CwbCoPwr allows you to tweak many of the same communications parameters that are available on the TCP/IP Configuration Properties screen, under the Settings tab.
However, CwbCoPwr allows you to tweak these parameters on a global basis or on an individual basis, for communicating with several different OS/400-based TCP/IP services, including the Central, File, Database, Data queue, ODBC, Management Central, and Telnet services.
The parameters you can control individually from the command line include many of the same TCP/IP parameters that you can configure globally from OpsNav. Using CwbCoPwr provides a twofold advantage. First, you can set global parameters for most TCP/IP applications and services and then tweak your TCP/IP performance parameters for only those individual services that need it. The CwbCoPwr utility gives you selective performance adjustment. The second advantage is that, since CwbCoPwr is a command- line utility, it can be included in Windows .BAT and scripting files. This means you can make temporary performance adjustments before an application starts and then set the server access parameters back to their default values after the application completes. Since it can be run independently of OpsNav, CwbCoPwr fits well into the batch file and scripting functionality of Windows.
There are a few caveats to be mentioned regarding CwbCoPwr. The first is that the initial release of the program, shipped with the Express client V5R1M0 GA version, contains a few small bugs, and it doesn’t have final product capability. If you’re planning on using CwbCoPwr, be sure to install the first Express client V5R1M0 Service Pack, to ensure that you have all the fixes and the final completed version. Also, be aware that there is a possibility CwbCoPwr can be used to tweak TCP/IP values in Express client V4R4M0 and V4R5M0 installations. However, if you decide to experiment with using CwbCoPwr in an Express V4RxMx environment, be aware that this capability is not officially supported by IBM, and there are no plans to release this tool for those products.
Improving ODBC Application Performance
Although OLE DB is becoming more popular in OS/400 shops, ODBC is still a preferred connection method of choice for Microsoft programmers writing applications that access OS/400 information. And there are several parameters you can tweak inside your ODBC data source name (DSN) configurations that can improve ODBC access speed and application performance. To view and change these parameters, open the ODBC Administration program on your desktop, select the Express client DSN you want to use for OS/400 access, click on the Configure button, and select the Performance tab on the screen that appears. Figure 3 shows the Express client V5R1M0 ODBC Performance screen. There are three parameters you can adjust to improve Express client ODBC performance.
Enable lazy close support has a default setting of on (checked), and it should be kept on for best performance. This option is used to control the way the SQL commands to free and close a file (the SQLFreeStmt with the SQL_CLOSE option) are handled by the Express client ODBC driver. If enabled, the file will not actually be closed until the next request is sent, which cuts down on PC-to-OS/400 communication. If this parameter is not enabled, it causes an extra communications flow to be sent to your iSeries or AS/400 to close the file, which adds time to the total operation.
Enable pre-fetch during EXECUTE is unchecked by default. However, in many cases, you can improve performance by setting this parameter on. Enable pre-fetch during EXECUTE combines the open and fetch operations when a SELECT statement is executed. This allows your applications to fetch the first block of data in advance (before the application needs it), which reduces communication between the PC client and the OS/400 server. However, it doesn’t help performance in all cases. IBM specifies that you should leave this option unchecked if your application uses SQLExtendedFetch or SQLFetchScroll, or if you are not sure whether you are using these options.
Enable data compression is unchecked by default, but it can be a definite ODBC performance improver. This option causes duplicated characters in your data—such as
sequential embedded blanks and zeroes—to be compressed. In Express client V4R4M0 and V4R5M0, ODBC data compression is only enabled with data being downloaded from your
iSeries or AS/400 to your PC. Data compression on uploads, when you are transferring data from the PC to your iSeries or AS/400, is not enabled for these products. However, with Express client V5R1M0 communicating with an OS/400 V5R1 machine, ODBC data compression works in both the upward and the downward directions, so that data streams being sent to your OS/400 machine will also be compressed.
The OS/400 V5R1 RUNRMTCMD Performance Bonus
If your shop is upgrading to OS/400 V5R1, there is an additional performance bonus you’ll receive when using Express client’s Incoming Remote Command (IRC) function. With IRC, you can set up an Express client machine to accept and execute authorized PC commands that are sent from your AS/400 via the OS/400 Run Remote Command (RUNRMTCMD) command. When you’re using OS/400 V5R1 to send commands to your Express client V5R1M0 PC via RUNRMTCMD, data compression is automatically enabled. No configuration is necessary; it will just happen once both components are upgraded to their V5R1 levels. IBM added this capability to reduce the bandwidth for OpsNav, which is heavily dependent on the remote command facility. As a bonus, you get to share in these performance improvements when upgrading to V5R1.
This Ain’t the End...
These are a few examples of the things you can do to improve Express client performance. Be sure to keep checking IBM’s documentation and future issues of Midrange Computing and its sister publication Midrange Network Expert for more tips and techniques on how to make Express client more efficient.
Figure 1: Express client performance tuning starts with the OpsNav Connection Properties panel.
Figure 2: You can configure global TCP/IP parameters to improve the performance of Express client.
Figure 3: When writing applications that use the Client Access ODBC driver, there are several parameters you can tweak to improve ODBC DSN performance.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online