BARR/RJE manual

BARR/RJE 802.2 Performance Tuning

Token Ring and Ethernet are common network topologies used with LANs and are also supported by IBM mainframes as means to connect to the mainframe. Ethernet and Token Ring both can pass IBM LLC (IEEE 802.2) traffic. For this reason Barr Systems supports 802.2 (Token Ring and Ethernet) as a possible communication link in the BARR/RJE and BARR/3270 products. Token Rings are rated at 4 or 16 Megahertz, which represent the ideal transmission rate of the physical medium. Ethernet typically functions at 10 Megahertz. These numbers, however, do not reflect the real world values you can achieve when transferring data over a network. The numbers you will get may vary widely because of many factors in your environment, such as the traffic on your ring and the type of LAN adapter you are using in your PC.

As a bottom line, we have concluded after years of testing and experience that you can reasonably expect between 300Kbps and 400Kbps on most any LAN, so that is what we advertise. It is possible to do better in some environments, but this is largely dependent on factors outside of our control, so we cannot guarantee it. There is also the special case of a multi-ring environment where the links between rings (usually routers over phone lines) can be significant bottlenecks. For instance, the host and the remote might be on two different Token Rings with routers and a 56Kbps line joining the two. In such a case, you clearly cannot expect more than 56Kbps of throughput.

With those thoughts in mind, here are some steps you can take to tune a Token Ring connection. They are divided into two categories, Host Tuning Parameters and PC Tuning Parameters. The most significant are the Host Tuning Parameters, which are almost always the key to maximizing performance.

• Host Tuning Parameters

• Match Host Parameters in Barr Software

• PC Tuning Parameters

Host Tuning Parameters

There are a couple of key parameters that affect most dramatically the performance of a 802.2 link. They are the Frame Size and Pacing parameters. These parameters have matching settings in the BARR/RJE software, but it is important to understand that they are not controlled by the BARR software. The host mainframe has absolute control over these settings and the remote software merely follows orders. The following table provides some information about these settings, including the default and recommended ideal values for them. Notice that neither of the parameters is set to its ideal value by default.

Because the BARR/RJE software does not control these settings, you cannot be sure that the values entered in the BARR software Installation Description really match the actual values at the host. The first thing you need to do, then, is investigate these parameters to find out how they are currently set. There are two good sources of information you can use, the host definitions and the BARR software run-time diagnostics. The host definitions actually control the outcome, but the BARR software run-time diagnostics are the best way to verify the outcome. This is important because at times something on the mainframe will override a setting that you thought was made. The run-time diagnostics will catch that kind of problem.

Once you have found the current settings, try to convince your host programmers to change them to match the recommended settings above. When the changes have been implemented, you also need to change the settings in the BARR/RJE software to match. The settings in the BARR software are found in the Installation Description (by typing BARRSNAR I) under the Communication Link menu. The Pacing related setting is actually called “MAXOUT.” The Frame Size setting is called “MAXDATA” and should be set to 1033 (actually 1024 + 9, for the 9-byte SNA header).

Obtaining Host Definitions

The settings we are interested in are stored in “Resource Definition Libraries” on the mainframe. You will need to ask your host communications programmer at the mainframe to send you printouts of these definitions, unless you have the ability

to obtain them yourself. Examples of these definitions can be found in the BARR/RJE manual (in the RJE Description and Communication Link chapters) and in the Installation Description of the software. The examples in the software, however, are not the real thing. For that, you need to go to the host. You need the following definitions:

• The NCP or VTAM definitions of your Group, Line and PU. For a 3725, 3745 or local 3174 connection, you need the VTAM definitions. For a remote 3174 you need the NCP definitions.

• The host JES2 Remote Definition for your remote (not necessary with JES3, VSE/POWER or VM/RSCS).

• The Logon Mode Table Entry that matches your LOGMODE from your host RJE system.

Following are samples of host definition printouts. The first is a VTAM definition, the second is an NCP definition, the third is a JES2 definition and the last is a Logon Mode Table Entry. In each case, you only need to look for the parameters that have been underlined in these examples. If a parameter cannot be found in your printouts, then it is probably defaulting to a less than ideal value. These examples show all the parameters explicitly set to their optimal values.

VTAM Definitions for 3725, 3745 or Local 3174

Source statements are in SYS1.VTAMLST(SWITCHED). Reference: VTAM Installation and Resource Definition (SC23-0111).

NCP Definitions for Remote 3174

The Source statements are in SYS1.VTAMLST (NCP). Reference: VTAM Installation and Resource Definition (SC23-0111), NCP Resource Definition Guide (SC30-3447), NCP Resource Definition Reference (SC30-3448).

JES2 Remote Definition (XA)

Source statements are in SYS1.PARMLIB(JES2PARM). Reference: JES2 Installation and Tuning (SC23-0065).

Logon Mode Table Entry

Source statements are in SYS1.VTAMLST(ISTINCLM). Reference: VTAM Customization (LY30-5614).

Host Parameter Location Summary

As you can see from the samples above, the settings we are looking for actually require more than one parameter entry each. The following listing sums up all the necessary parameters from the three screens above needed to get the desired results.

To get a Frame Size of 1024, you need:

in the PU macro of NCP/VTAM,

in the JES2 remote definition, and

in the Logon Mode Table Entry.

Finally, to get all Pacing related parameters of 7, you need:

in the PU macro of NCP/VTAM,

in the PU macro of NCP/VTAM,

in the PU macro of NCP/VTAM, and

in the Logon Mode Table Entry.

The Frame Size in the JES2 Remote Definition listing above (BUFSIZE) applies only to JES2. For the other host RJE systems (VSE/POWER, JES3 and VM/RSCS) that parameter is not supported or necessary.

Local 3174 Controller Settings

If you are connecting to a local 3174, there is one additional setting you need to check, and that is on the 3174 itself. A local 3174 controls its own frame sizes for downstream connections since it is not connecting through a front end processor. Therefore, the 3174’s configuration needs to be changed in order to achieve the desired frame size. This is done by setting the F parameter to a value of 3 in Question 941 of the 3174 configuration. See the section on “802.2 Connection with Local 3174” in the Communication Link chapter of the BARR/RJE manual for more details.

Checking the Bind Data Values

Fortunately, the host definitions are not our sole source of information for how these parameters are actually set. The run-time diagnostics of the BARR/RJE software provides a definitive check on these settings. This is possible because the host sends the remote information on these settings at Logon time in the form of a coded message called a BIND. The BARR/RJE software stores this message in memory and allows you to access it through the Diagnostic option called “Bind Data.”

To check the Bind Data, start the BARR/RJE software and wait for logon. Then select the Advanced menu, and from there select the Diagnostics menu. Under the Diagnostics menu you can see the Bind Data option, and when you select it you will get a screen something like this:

This screen shows the Binds for the logical units (LUs) that are currently in session with the LU numbers down the left side and column numbering on the top row from 0 to 25. Only a few of these numbers are relevant to this discussion.

Columns 10 & 11 represent Frame Size, and should both be 87. In this example, they are 86, which means only 512 instead of the recommended 1024.

Columns 8, 9, 12 and 13 represent various Pacing values, and should be 07 or 87. In this case, two are set to 07 and the other two to 00. That is actually OK, because 9 and 12 are the most important ones. Bytes 8 and 13 are used only for upstream traffic, so become important only if you are sending large files up to the host.

Match Host Parameters in Barr Software

You will find matching parameters for the three listed above in the Barr software configuration under the Communication Link menu. When you select the 802.2 connection, such as “3725 & 3745 Controllers,” you will see parameters for MAXDATA and MAXOUT. The MAXOUT parameter should be set to match all the pacing related parameters.

PC Tuning Parameters

802.2 performance is influenced by many different factors in the network environment. In the previous section we discussed the main parameters controlled by the host mainframe. In this section we will discuss a few things in the PC itself that affect performance. The two most obvious components of the PC that affect performance of 802.2 transmission are LAN adapter and the hard drive.

Use a Fast Network Adapter and PC

The speed of the network adapter you use can have a major impact on the performance of any protocol you run over the network, including the 802.2 LLC protocol. We recommend using an adapter conforming to the newer PCI bus standard, since these are faster than traditional ISA bus adapters. To get the most out of the latest PCI network adapters, a Pentium™ class PC (or equivalent) should also be used.

If the BARR software cannot write to the hard drive as fast as the link speed, then of course it will be forced to slow down the transmission. Listed below are two DOS features that you can use to enhance the performance of your hard disk if you think it might be the bottleneck. They are the VERIFY OFF command and the SMARTDRV command. The first can be set in the BARR software, and the second can be set in the PC’s AUTOEXEC.BAT file.

Use VERIFY OFF in BARR

The VERIFY function of DOS requires that data is read back immediately after it is written in order to verify that the data is correct. This feature is outdated and not necessary for modern hard drives. You can disable this feature in the BARR software Installation Description by setting an option under the Tuning Data, Additional Parameters menu. The option looks like this:

This option defaults to Yes as shown above, so it should already be set correctly. You may want to check it just to be sure it is set to Yes.

Use SMARTDRV in DOS

Both MS-DOS and PC-DOS offer a program called SMARTDRV that can help improve your hard disk performance by creating a disk cache. A disk cache is an area of memory used to buffer large amounts of data when reading from or writing to the hard disk. In the writing mode, it will collect a large amount of data before writing it all to the disk at once, thereby gaining better efficiency from the hard disk.

In order to turn on SMARTDRV for your PC, add the following line to AUTOEXEC.BAT:

This will set up a 2 megabyte cache for your C: drive and any floppy drives. If your PC has less than 4 megabytes of memory, you should reduce the number from 2048 to 1024. If you also have a D: drive that you want caching for, add a D+ to the line, like this:

One final note is to make sure the parameter /X is not on this line, because it disables write caching and would defeat the purpose of using SMARTDRV with the BARR software. For further information about SMARTDRV, consult your DOS manual or use the DOS on-line help feature.