Do you remember what you were working on when suddenly everything you read in every trade publication focused on the Internet? How about when the new buzzwords were client/server? Fortunately for those of us who rely on the AS/400 to run our businesses and keep us competitive, IBM had already started opening up the AS/400 to participate in these new arenas. Anyone who worked on the older midrange equipment remembers an extremely rigid and closed system. Everything was proprietary, and trying to communicate with different hardware could be quite an undertaking. One of the first steps toward creating a more open system was the PC emulation card. It was great! Now you could attach something other than a dumb terminal to your hardware. Now you could download data from your S/34 or S/36 and give it to your users in Lotus 1-2-3 to manipulate in any way they desired.
Today’s AS/400 is a much more open system compared to older midrange hardware. You have the options of using SNA or TCP/IP when communicating with local or remote hardware.
The introduction of the AnyNet protocol was another advancement in AS/400 communications. AnyNet/400 has been included in OS/400 since V3R1, and it provides support for Advanced Program-to-Program Communications (APPC) over TCP/IP. With APPC over TCP/IP, applications written to communicate with the SNA protocol can run over a TCP/IP network.
The sockets over SNA support allows sockets application programs to communicate between systems in an SNA network. Both systems running the sockets application programs must have sockets over SNA support, unless there is an AnyNet gateway between them. With an AnyNet gateway, such as AnyNet/2 Sockets over SNA Gateway, between an SNA and a TCP/IP network, sockets application programs running on systems with sockets over SNA support can communicate with sockets application programs running on systems in the TCP/IP network. Several products are available to accomplish this task. A 1997 white paper published by Polaris Communications (now Crossroads Systems Inc.) and Microsoft is available at www.polariscomm.com/white/tcpip_sna.htm.
So How Can AnyNet Help Me?
One of the main advantages of AnyNet is that it allows machines on different hardware platforms to connect without a change in application software. AnyNet also allows you to use TCP/IP to communicate between AS/400s with the SNA configuration that you might already have set up. For example, if your AS/400s communicate using leased lines, and you want to install a WAN using a frame relay connection, AnyNet could be useful. Another example might be if you use Distributed Data Management (DDM) to perform file operations on remote systems. Prior to V4R4, DDM files could not be created using a TCP/IP address.
You could configure your routers to pass SNA traffic, but because SNA continuously polls to assure the connection is still alive, using SNA would cause unnecessary traffic on the WAN. If you have several AS/400s connected or a lot of users passing through from one machine to another, this traffic could add up. Instead, configure your connections on the AS/400 the same way you would for a leased line, but then configure AnyNet. This allows the AS/400 to communicate over the WAN using TCP/IP. You don’t have to buy special routers that perform SNA spoofing, which traps the polling by the AS/400 and responds without sending the traffic over the WAN. You also do not have to configure your routers to pass SNA traffic. “Talking Shop: SNA and TCP/IP: An Alliance Worth Considering,” (MC, September 1999) discusses the advantages of using both TCP/IP and SNA.
Now I will walk you through the steps required to configure AnyNet on the AS/400. The first requirement for using AnyNet is that your AS/400 has either an Ethernet or Token-Ring card attaching it to your network. Line, controller, and device descriptions must also be configured and active. To create the line and controller descriptions, you first need to determine the communication resource name assigned to the Ethernet or Token- Ring card. Use the Work with Hardware Resources (WRKHDWRSC) command with the CMN parameter as shown: WRKHDWRSC *CMN. This command will display a screen that lists the resource name, status, type of resource, and a text description. An Ethernet card will have two resources listed. Record the resource name listed with the text of Ethernet port. For this example, assume the resource name is CMN02. Use the following command to create the line description:
CRTLINETH LIND(ETHERLINE) RSRCNAME(CMN02) LINESPEED(100M) LINKSPEED(100M).
In this example, a 100 Mb Ethernet card is being used. If your card is 10 Mb, change the linespeed and link speed to 10 MB. At this point, you can either create the controller description or let the controller autocreate. The default for the Create Line Description (Ethernet) (CRTLINETH) command is to autocreate the controller. To manually create the Ethernet controller and device descriptions, use the following commands:
CRTCTLNET CTLD(ETHERCTL) LINE(ETHERLINE)
CRTDEVNET DEVD(EHTERDEV) TYPE(*TCPIP) CTL(ETHERCTL)
You also need the licensed program TCP/IP Connectivity Utilities for AS/400 (5763TC1 for V3R2 or 576TC1 for V4R1) and above. This product is free and ships with OS/400. You need a basic knowledge of TCP/IP and networking, as well as familiarity with networking terminology. Before adding the necessary entries to enable APPC over TCP/IP, you must have TCP/IP configured and active on the AS/400. You can use the OS/400 TCP/IP Configuration and Reference V4R4 manual to assist with this task. You can also refer to “SYSOP: AS/400 TCP/IP Basic Setup and Services,” MC, April 2000 and “Configuring Your AS/400 to Use TCP/IP,” MC, October 1997.
A Brief Overview
TCP/IP requires an association between the IP address and the host name assigned to the remote system. These associations are entered into the host table on the AS/400. APPC over TCP/IP uses a host name, but it must be entered in a long format with the network ID and the SNA domain name suffix. You must also create configuration lists that contain information about the local and remote systems. You must have a local and a remote location list on each system. And, you must create an AnyNet controller description on each AS/400. The parameters contained in the remote location list on the source system must be matched or paired with the parameters in the local location list on the remote system. These matching parameters are similar to the exchange identifier and station addresses that must be specified when creating an SDLC line description on the AS/400.
The parameters are matched for security purposes. Figure 1 shows the matching parameter list from the OS/400 Communications Configuration V4R1 manual.
Matching Parameters in Detail
Working from the matching parameter list in Figure 1 is the easiest way to set up and configure AnyNet. In this example, two AS/400s are being configured. One system is named Oslo, and the other is named Geneva. This name can be, but is not required to be, the system name as shown in the Display Network Attributes (DSPNETA) command.
The first section of the matching parameter list relates to the network attributes. To use AnyNet, the network attribute ALWANYNET must be set to YES. I recommend changing this first. If you create the AnyNet controller and vary it on before changing the ALWANYNET network attribute, you need to vary the controller off, change the setting, and then vary the controller back on. To configure AnyNet, either sign on as QSECOFR, or use an equivalent profile. You need *ALLOBJ and *IOSYSCFG authority. Use the following command to set the ALWANYNET attribute to yes: CHGNETA ALWANYNET(*YES). Retrieve the next two parameters, local location name (LCLLOCNAME) and local network ID (LCLNETID), using the DSPNETA command. The default network ID is APPN, but if you changed the network ID on your system, you need to retrieve it from the network attributes.
The next section of the list shows the entries required in the AS/400 host table. If you currently use TCP/IP on your AS/400, you may already have entries in the host table. You can associate up to four host names with each IP address in the AS/400 host table. I like to configure two entries for each IP address. I set the first entry as the system name, and the second entry is the long name required for AnyNet communications. The long name for AnyNet consists of three parts: the location name, the network ID, and the SNA suffix. These must be in the form system.appn.sna.ibm.com. The system name is the name you assign to the remote system and must be entered in the remote location list, which I will discuss later in detail. APPN is the local network ID from the network attributes. Sna.ibm.com is the SNA domain suffix required for AnyNet communications. It must be entered in this format. If, for some reason, it is absolutely necessary to change this, there are instructions in the Client Access for Windows 95/NT Setup V3R2M0 manual. I do not recommend changing this because the suffix is coded into the AS/400 operating system.
If you already have an entry in the host table, you cannot add another entry for the same IP address. To change the entry, use the Configure TCP/IP (CFGTCP) command. Then use option 10 from the CFGTCP menu and option 2 to change the host table entry to add the long host name.
If you do not have an entry in the host table, you can use the following command to add an entry for the Geneva system.
ADDTCPHTE INTNETADR(‘9.5.5.2’) HOSTNAME((GENEVA) +
(GENEVA.APPN.SNA.IBM.COM))
An entry must be made in the host table in this format for every remote AS/400 or PC you want to communicate with using AnyNet.
Creating the APPC Controller
I don’t really like the approach to creating the controller that is outlined in the table. In Figure 1, the remote control point name (RMTCPNAME) is different on both systems. The Oslo system is TCPIP1 and the Geneva system is TCPIP2. The remote control point ID in the controller matches up with the remote control point ID that is entered in the Advanced Peer-to-Peer Networking (APPN) remote location list. For every control point name you specify, you are required to create an APPC controller. If the Oslo system was able to connect with three systems with different control point names specified, you would need three APPC controllers on the Oslo system, because the remote control point ID is entered when the controller is created. If you had many systems, each able to connect to the other, you would end up with a spider web effect. I like to use one control point name for every system I connect to. This allows me to create an identical controller on each system, and it doesn’t matter which system I am connecting with because the remote control point name is always the same. To create the AnyNet controller, you could use the following command.
CRTCTLAPPC CTLD(ANYNETCTL) +
LINKTYPE(*ANYNW) RMTCPNAME(RMTCP)
You may name the controller anything you like, up to 10 characters. In this example, I used the name ANYNETCTL. The same is true for the remote control point name, which can be up to eight characters. By using the same remote control point name, you can then create the controller the same way on each of your AS/400 systems. When AnyNet was first announced, it was suggested that you use a different control point name for each system, but I have been using the same control point name for more than four years with no problems.
The final section of the matching parameter table describes the entries in the local and remote configuration lists. The local location list on the AS/400 defines the local system. The local location name entered in the local location list must also be entered in the local location field of the remote location list. The local location list must be named QAPPNLCL in library QSYS, and the remote location list must be named QAPPNRMT in library QSYS. There can be only one local location and one remote location list on the system. The APPN Support V4R2 reference manual describes how to create the local and remote location lists in detail in Chapter 4.
Use the Work with Configuration Lists (WRKCFGL) command to create or modify the remote and local location lists. If the location lists have not been created on your system, take option 1 to create it and then press enter. You are then required to enter the configuration list type. Use *APPNLCL for the local location and *APPNRMT for the remote location. You may key the text description for each list if you desire.
Figure 2 illustrates the local location list set up for the Oslo system. The Geneva system has a local location name of Geneva. You can have 476 local location names if you want, although only one is required.
Figure 3 shows how the remote location list is set up on the Oslo system to connect to systems Geneva, Shanghai, and Sydney. I entered RMTCP for the remote control point name because I created my AnyNet controller using RMTCP for the remote control point name. You can enter up to 1,898 remote locations in the remote location list.
Testing Your Connections
After you configure AnyNet on both systems, you can test your connections. You need access to all of the systems you are trying to connect to. First, make sure the AnyNet controller you created is varied on. I like to start by using the ping command to make sure
the destination can be reached. Type ping followed by the long host name, which is entered in the host table. For example, if you wanted to test the connection from the Oslo 400 to the Geneva 400, enter PING GENEVA.APPN.SNA.IBM.COM. If the reply returned is
“Unknown host,” GENEVA.APPN.SNA.IBM.COM, double-check the host table entry to ensure that the long name was entered correctly. If the reply returned is “No response from host with x Seconds,” you have a network configuration problem. Make sure the IP address is keyed correctly in the host table and verify that the remote 400 is running and TCP/IP is started on both systems.
Once you ping the remote system, try to attach using AnyNet. I use the Pass Through command for testing. To test the Geneva to Oslo connection, you enter STRPASTHR RMTLOCNAM(GENEVA) LCLLOCNAM(OSLO). A variety of errors may be returned if the connection is not configured properly. If you receive the error “Route to specified location not found,” either the remote or local location list is probably not set up properly. Double-check the entries in both lists to verify that the entries are correct according to the matching parameter table in Figure 1. If you receive an APPC failure, the system returns the failure code. Check the additional message text to determine the reason. Most of the return codes are explained in detail in the APPN Support V4R2 or the Problem Determination Guide manuals.
You should have the latest PTFs installed, especially if you are on V3R2. Occasionally, the job associated with APPC over TCP/IP does not start. Use the WRKSBSJOB QSYSWRK command to verify that a job named QAPPCTCP with a function of PGM-QZPAIJOB is active. If this job is not active in the QSYSWRK subsystem, use DSPNETA to verify that the ALWANYNET parameter is set to *YES. If the parameter is *YES, you must vary off any APPC over TCP/IP controllers, change the parameter to *NO, change it back to *YES, and then vary on the APPC over TCP/IP controllers. This should start the job in QSYSWRK.
Patience Is Its Own Reward
Be patient. You may not be able to connect the first time you set this up. The host table entries and the local list entries must match correctly. It’s easy to key the long name incorrectly, so double-check the entries in these tables if you have a problem. Once you get accustomed to setting up these tables, adding a new connection is a breeze.
REFERENCES AND RELATED MATERIALS
• APPN Support V4R2 (SC41-5407-02, CD-ROM QB3ANH02)
• Client Access for Windows 95/NT-Setup V3R2M0 (SC41-3512-05, CD-ROM QBKACN06)
• “Configuring Your AS/400 to Use TCP/IP,” Steve Gau, MC, October 1997
• OS/400 Communications Configuration V4R1 (SC41-5401-00, CD-ROM QB3ANB00)
• OS/400 TCP/IP Configuration and Reference V4R4 (SC41-5420-03, CD-ROM QB3ANL03)
• Problem Determination Guide (SC31-6156-00, CD-ROM CO6P3000)
• “SYSOP: AS/400 TCP/IP Basic Setup and Services,” Kevin Gerard, MC, April 2000
• “Talking Shop: SNA and TCP/IP: An Alliance Worth Considering,” Jim Scott, MC, September 1999
Figure 1: This is the matching parameter list from the OS/400 Communications Configuration V4R1 manual.
Figure 2: Here is the local location list set up for the Oslo system.
Figure 3: The remote location list on the Oslo system connects to systems Geneva, Shanghai, and Sydney.
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