Admin Alert: When APPN Prevents You from Changing Network Attributes
September 19, 2007 Joe Hertvik
|
Recently, I was unable to use the i5/OS Change Network Attributes command (CHGNETA) to change i5/OS network attributes on my System i 550. The system wouldn’t take the change and I found that it was because I needed to temporarily vary off my partition’s Advanced Peer-to-Peer Network (APPN) controllers to complete the process. Here’s what happened and what I learned about how APPN can affect network attribute changes. The Problem The symptoms for this problem were that after executing the following CHGNETA command, the command would not change the system name on my system. CHGNETA SYSNAME(NEWNAME) LCLCPNAME(NEWNAME) The changes to the Local control point name attribute (LCLCPNAME) and the Default local name attribute (LCLLOCNAME) took, but the system would not accept the new System Name network attribute that I was trying to enter into the system. For background, the System Name network attribute (SYSNAME) specifies the name that i5/OS assigns to the system. It is used for System i identification, as well as for several other processes and applications. SYSNAME is a user-configurable value and by default, the system name is not set up on the partition. If a system name does not exist for your system, i5/OS defaults SYSNAME to the same value as the machine’s serial number. If the first character of the serial number is a digit (0-9), i5/OS changes that character to an alphabetic character when setting up SYSNAME. It’s also worth noting that you can only change the system name when you IPL your partition. In most cases, you change your System i or iSeries SYSNAME by using a CHGNETA command similar to the one listed above. If the change takes effect, the new name will be entered into the system’s network attributes as the Pending system name and the system name change will occur at the next IPL. There can only be one Pending system name listed for an i5/OS partition. To view your network attributes (including the Pending system name), you would then use the Display Network Attributes command (DSPNETA) like this. DSPNETA If you don’t see a Pending system name in DSPNETA or if you receive an error when running CHGNETA, i5/OS is not letting you change the system name. And that’s what happened in my case. The command was run but the change didn’t occur. The consultant that I was working with had a suspicion that the changes weren’t occurring because we still had a number of active controllers and jobs on the system, so we put the system into restricted state and manually varied off all the controllers and their devices. After doing that, the system allowed us to specify a new Pending system name and the system name change occurred after the partition’s next IPL. What happened After the fact, I found a possible explanation for what might have occurred in an iSeries Information Center entry that states that: ". . . An attempt to change the network attributes for * the local control point name, * the network ID, * HPR transport tower support or * the node type will fail if there are any APPC or HOST controllers active which have the APPN option set to *YES and a link type of anything other than *DLUR. If this failure occurs, no network attributes will change. Looking at this explanation, it appears that my CHGNETA command could have been protesting because my system was using active virtual APPN controllers, such as you might find in equipment that uses the LU 6.2 protocol to allow other Advanced Program to Program Communications (APPC) devices to communicate with the system i. After reading that entry, I located a second IBM Information Center entry for i5/OS V5R3 that discusses the proper way to change network attributes. In that document, it states that all APPC/APPN and host controllers should be varied off before changing system network attributes, which confirms our solution of manually shutting down controllers before changing our network attributes. The Right Way to Change Network Attributes Based on these two entries, the conclusion I came to was that there is a connection between i5/OS network attributes and APPN/APPC controllers and devices, and that the system may not allow network attribute changes when controllers with certain attributes are active. So if you have APPN or HOST controllers on your system and you want to change your network attributes, you should look at IBM’s procedure for changing network attributes. The procedure isn’t difficult but it does have a few bumps. If you run into this problem, here’s the gist of how IBM recommends that you can change network attributes, as well as a few items that they don’t mention in their procedure. 1. The Vary Configuration command (VRYCFG) has an option for automatically varying off all APPN controllers and their associated devices on your system. To perform this function, you would execute the following VRYCFG command. VRYCFG CFGOBJ(*APPN) CFGTYPE(*CTL)rn STATUS(*OFF) RANGE(*NET) There are two things to consider here. If you’re going to vary off these controllers, there may also a number of interactive jobs or printers attached to the controllers that are being varied off. So you may want to perform this configuration change during off-hours when it’s okay to shut down communications, jobs, and printers. And since the system name change will only take effect during an IPL, you may want to perform this command after taking your system down to restricted state and then IPL the system after performing the following steps. The second thing to consider is that as the VRYCFG command is varying off your controllers, the system may display an error message that reads ‘Controller not contacted’. This occurs if one of the controllers that the system is trying to vary off is in a failed state or if it has active devices attached to it. In that case, you can try answering the error message with a ‘G’ (GO) to force the controller to vary off. If that doesn’t work, you may need to display the problem controller and any attached devices and then manually vary them off, if necessary. 2. If the communications lines that the controllers are attached to are still active, there’s a trick to automatically varying off the APPC controllers. IBM notes that “. . . When using automatic creation of controllers on LANs and you vary off the controllers, you have approximately two minutes before the iSeries automatically varies on the controllers again.” This means that you either have to work fast and change your network attributes immediately after varying off the controllers or that you have to temporarily disable APPN controller auto-creation on the LAN (this shouldn’t be a problem if the system is in restricted state and the line is inactive). Disabling controller autocreation is done by using the Change Line Description command (CRTLINxxx), where xxx = the type of line you are changing (‘ETH’ = Ehternet, ‘FR’ = Frame Relay, etc.). You can use CRTLINxxx to turn off the Autocreate Controller parameter (AUTOCRTCTL) for any communication line(s) that your controllers are attached to. For example, to turn off AUTOCRTCTL for an Ethernet line called ETHERLINE, I would use the following Change Line Description (EHTERNET) command: CHGLINETH AUTOCRTCTL(*NO) This will disable my Ethernet line’s ability to automatically create or vary on controllers for devices that are trying to attach to this line. However, you should also note that your line description may need to be varied off in order to make this change. 3. Once the APPN controllers are turned off and there’s no danger that the system will automatically vary them on again, it’s time to change your network attributes. To do that, you would run the same CHGNETA command that you weren’t able to execute before. CHGNETA SYSNAME(NEWNAME) LCLCPNAME(NEWNAME) According to IBM, this should now change your Pending system name to the new name that will become your system name during the next IPL. 4. After successfully making the change, you need to turn back on the controllers that you varied off and you also need to re-enable the AUTOCRTCTL parameter on your communication lines. To vary on all the APPN controllers that you varied off in step one, you would execute the following VRYCFG command: VRYCFG CFGOBJ(*PRVCFGTYPE) To re-enable your communication’s line ability to automatically create and turn on controllers, execute a CRTLINxxx command that has the same AUTOCRTCTL parameter as this command: CHGLINETH AUTOCRTCTL(*YES) If you’re not IPLing your system, you can restart your communications lines here. 5. When you’re able to, IPL your system to change the system name. Please also note that because you are varying off live controllers and temporarily changing your communication parameters, you should only perform this procedure when the system is in restricted state or when you can stop APPN communication and communications lines without affecting your production users. This is definitely an off-hours configuration. About Our Testing Environment Configurations described in this article were tested on an i5 550 box running i5/OS V5R3. Most of these commands shown here are also available in earlier versions of the operating system running on iSeries or AS/400 machines. If a command or function is present in earlier versions of the i5/OS or OS/400 operating systems, you may notice some variations in the pre-V5R3 copies of these commands. These differences may be due to command improvements that have occurred from release to release. RELATED RESOURCES CHGNETA (Change Network Attributes) Command Description, IBM iSeries Information Center Version 5 Release 2 (V5R2) Change Network Attributes, IBM iSeries Information Center Version 5 Release 3 (V5R3)
|
