Restoring 128-Port Devices After a mksysb System Restore


Contents

About this document
    Related documentation
Overview of 128-port devices
What are the potential problems
Preventing mksysb problems
Collecting data prior to making a mksysb tape
Restoring devices using collected data
Restoring the tty
Automating the restoration (includes an automation script)
Restoring when no data was collected

About this document

This document describes how to restore tty and printer devices attached to 128-port adapters using the Remote Asynchronous Nodes (RAN) after restoring a system with mksysb. Upgrading hardware using a mksysb tape from another system is also discussed. The procedures covered in this document and the accompanying script have been minimally tested.

This document applies to AIX Versions 4.2.1 or later

Related documentation

The product documentation library is available:
http://www.rs6000.ibm.com/resource/aix_resource/Pubs/index.html

Overview of 128-port devices

Devices are numbered in the order in which they are added to the operating system. The system administrator can maintain a logical order to devices, or can choose to add devices in a random order. Problems can be avoided by maintaining a logical order to devices. This is discussed in the section "Preventing mksysb problems" later in this document.

128-port adapter numbering

128-port adapters are numbered in the order in which they are added to the system. If more than one adapter is added at the same time, the order will be dependent on the order in which the bus is walked during the next boot sequence. The device name will be dependent on the type of bus.

BUS                             Device Names
Microchannel          cxma0, cxma1, ..
ISA                               cxia0, cxia1, ..
PCI                               cxpa0, cxpa1, ..

Bus walk order

The order of walking the bus is dependent on the model. For the models H50 and H70 the order is:

  H50 order          H70 order
--------------------------------------
  PCI slot 3         PCI slot 3
  PCI slot 4         PCI slot 4
  PCI slot 5         PCI slot 1
  PCI slot 1         PCI slot 2
  PCI slot 2         PCI slot 7
  PCI slot 6         PCI slot 8
  PCI slot 7         PCI slot 5
  PCI slot 8         PCI slot 6
  PCI slot 9
  ISA card 1
  ISA card 2

To see the 128-port adapter locations in your system, enter:

lsdev -Cc adapter | grep cx
cxpa0   Available 10-70    IBM 128-Port Async (PCI) Adapter
cxpa1   Available 30-60    IBM 128-Port Async (PCI) Adapter

The information returned by the lsdev command indicates the adapter name, the status of the adapter, the location of the adapter, and the type of adapter. If the status of an adapter reads Defined instead of Available, this indicates that an adapter has been removed without removing the device, or that the adapter card is not operational.

The location code is dependent on the model and bus type.

Possible 128-port adapter locations on the RS/6000 F50 and F70 are shown in this table:

RS/6000 H50 RS/6000 H70
Slot Number LocationParent LocationParent
PCI slot 1 20-58pci1 20-58pci1
PCI slot 2 20-60pci1 20-60pci1
PCI slot 3 10-68pci0 10-68pci0
PCI slot 4 10-70pci0 10-70pci0
PCI slot 5 10-78pci3 40-58pci3
PCI slot 6 30-60pci3 40-60pci3
PCI slot 7 30-68pci2 30-68pci2
PCI slot 8 30-70pci2 30-70pci2
PCI slot 9 30-78pci2 NANA
First ISA card01-01isa1 NANA
Second ISA card01-02isa2 NANA

Add the -F flag to the lsdev command to show the parent in the output.

lsdev -Cc adapter -F"name location parent description" | grep cx
cxpa0   10-70    pci0    IBM 128-Port Async (PCI) Adapter
cxpa1   30-60    pci2    IBM 128-Port Async (PCI) Adapter

Based on this information, cxpa0 is the adapter in slot 4, and cxpa1 is the adapter in slot 6.

Ideally, the lower numbers will be located earlier in the sequence of walking the bus.

RAN numbering

RANs are also numbered in the order in which they are added. This order has nothing to do with the adapter on which they are located. RANs are included among async adapters and are named sa3, sa4, sa5, etc. The starting sa number for the first RAN will be dependent on the model and the adapters that have been installed or found earlier in the boot sequence. In the boot sequence, the order in which the RANs are found is based first on the sequence in which the adapters are found, and then in the sequence of the line number and note number of the individual RANs that are turned on during the boot. If a previously defined RAN is turned off during bootup, it will display a status of Defined.

Issue the lsdev command to see the association between the RAN and the parent 128-port adapter.

lsdev -Cc concentrator
sa3 Available 10-70-11 16-Port RAN EIA-232 for 128-Port Adapter
sa4 Available 10-70-22 16-Port RAN EIA-232 for 128-Port Adapter
sa5 Available 30-60-21 16-Port RAN EIA-232 for 128-Port Adapter

This listing shows RANs that are located on two different adapters. The first and second two-byte sequences of the location code indicate the adapter location code. The third two-byte sequence shows the 128-port line number and RAN node number. On an F50, line 1 is the top 15-pin connector on the adapter, and line 2 is the lower connector.

LocationAdapter Location LineRAN Node
10-70-1110-70, Slot 4 11
10-70-1210-70, Slot 4 12
10-70-2110-70, Slot 4 21
10-70-2210-70, Slot 4 22
30-60-1130-60, Slot 6 11
30-60-2130-60, Slot 6 21
30-60-2430-60, Slot 6 24

Again, add the -F flag to the lsdev command to include the parent adapter in the output.

lsdev -Cc concentrator -F"name location parent description"
sa3 10-70-11 cxpa0 16-Port RAN EIA-232 for 128-Port Adapter
sa4 10-70-22 cxpa0 16-Port RAN EIA-232 for 128-Port Adapter
sa5 30-60-21 cxpa1 16-Port RAN EIA-232 for 128-Port Adapter

tty and printer device numbering

The first three two-byte sequences of the tty or lp location indicate the location of the parent RAN, while the last two-byte sequence indicates the port of the RAN.

To see the tty devices issue the lsdev command as shown below:

lsdev -Cc tty
tty0 Available 01-S1-00-00 Asynchronous Terminal
tty1 Available 10-70-11-00 Asynchronous Terminal
tty2 Available 10-70-11-01 Asynchronous Terminal
tty3 Available 10-70-11-02 Asynchronous Terminal
tty4 Available 30-60-21-15 Asynchronous Terminal
tty5 Available 30-60-21-00 Asynchronous Terminal
tty6 Available 10-70-22-00 Asynchronous Terminal
tty7 Available 10-70-22-08 Asynchronous Terminal

To see the printer devices issue the lsdev command as shown below:

lsdev -Cc printer
lp0 Available 10-70-11-05 Lexmark 4039 plus LaserPrinter
lp1 Available 10-70-22-04 IBM 4039 LaserPrinter
lp2 Available 30-60-21-09 Lexmark Optra laser printer

The following table shows more details on the description of the tty and printer device location.

LocationAdapter Location LineRAN NodeRAN Port
10-70-11-0010-70, Slot 4 110
10-70-12-0110-70, Slot 4 121
10-70-21-0210-70, Slot 4 212
10-70-22-0310-70, Slot 4 223
30-60-11-0830-60, Slot 6 118
30-60-21-1030-60, Slot 6 2110
30-60-24-1530-60, Slot 6 2415

Wiring diagram

Based on the previous information, construct a wiring diagram for your 128-port devices. For the sample configurations shown, the diagram may look something like this:

DeviceLocationAdapter Location LineRAN NodeRAN Port
tty001-S1-00-00System Board NANANA
tty110-70-11-0010-70, Slot 4 110
tty210-70-11-0110-70, Slot 4 111
tty310-70-11-0210-70, Slot 4 112
lp010-70-11-0510-70, Slot 4 115
tty610-70-22-0010-70, Slot 4 220
lp110-70-22-0410-70, Slot 4 224
tty710-70-22-0810-70, Slot 4 228
tty530-60-11-0030-60, Slot 6 110
lp230-60-21-0930-60, Slot 6 219
tty430-60-24-1530-60, Slot 6 2415

Device major and minor numbers

To list the major and minor numbers for tty and lp devices, issue a directory listing of the /dev directory. 128-port adapters and RANs do not have major and minor numbers and do not have accessible special device files.

List the device files with the command ls -l /dev as shown below. The two numbers before the date are the major and minor numbers. The major number is operating system dependent, while the minor number is based on the location of the tty or lp device.

ls -l /dev/tty*
crw-rw-rw-   1 root     system     1,  0 Apr 05 10:40 /dev/tty
crw--w--w-   1 root     system    16,  0 Apr 05 10:41 /dev/tty0
crw-------   1 root     system    36,  0 Apr 02 17:13 /dev/tty1
crw-------   1 root     system    36,  1 Apr 02 17:13 /dev/tty2
crw-------   1 root     system    36,  2 Apr 02 17:13 /dev/tty3
crw-------   1 root     system    36,335 Apr 02 17:13 /dev/tty4
crw-------   1 root     system    36,320 Apr 02 17:13 /dev/tty5
crw--w--w-   1 root     system    36, 80 Apr 05 10:41 /dev/tty6
crw-------   1 root     system    36, 88 Apr 02 17:13 /dev/tty7
ls -l /dev/lp*
crw-rw-rw-   1 root     system    36,  5 Apr 02 17:13 /dev/lp0
crw-rw-rw-   1 root     system    36, 84 Apr 02 17:13 /dev/lp1
crw-rw-rw-   1 root     system    36,329 Apr 02 17:13 /dev/lp2

With the PCI bus 128-port cards, the device numbers can be related as follows:

Adapter nameLine No.RAN NodePort Number Minor Number
cxpa01100
cxpa01111
cxpa0110-150-15
cxpa0120-1516-31
cxpa0130-1532-47
cxpa0140-1548-63
cxpa0210-1564-79
cxpa0220-1580-96
cxpa1110-15256-271
cxpa1210320
cxpa1211321


What are the potential problems

When a system is restored from a mksysb tape, the device numbering for some devices such as 128-port adapters and RANs is based on the order in which they are found while walking the bus. Problems occur when the restored assigned numbers differ from the numbers assigned during the original configuration of these devices. Additionally, tty and lp devices attached to a RAN are not renumbered during the mksysb. Instead they are numbered based on the parent name (for example, the RAN sa number) which may also create problems.

Example

This problem is illustrated in the following example. Assume there is only one 128-port adapter. At the beginning, there is only one RAN which is placed on line 2 of the adapter. The RAN becomes sa3 because sa0, sa1, and sa2 are already used by the integrated serial ports on the H50. This RAN will likely have a node number of 1, so the location for sa3 will be xx-yy-21.

If a new RAN is added to accommodate new users, it may be added on line 1. This new RAN becomes sa4 at location xx-yy-11. tty and lp devices have already been added to the first RAN, and will also be added to this new RAN. To simplify the example, lets work with only the two devices that are attached to port 0 on each RAN. On the first RAN, an IBM3151 terminal was added on the first port of the RAN. A Lexmark Optra printer was added on the new RAN on port 0. The device list now shows these devices as:

  tty0 Available 01-S1-00-00 Asynchronous Terminal
  tty1 Available 10-70-21-00 Asynchronous Terminal
  lp0  Available 10-70-11-00 Lexmark Optra laser printer

The terminals and printers are operating normally. Now, a mksysb is used to create a backup of the system. In the event the disk is completely destroyed, restoring the system from this previously created mksysb tape will cause problems. Users may not get a login prompt or may not be able to find print jobs.

The reason for this is that during the mksysb restoration the RAN that was formerly known as sa4 was found earlier in the restoration process than the previous sa3. Since there were only two RANs, sa3 became sa4 and sa4 became sa3. The list of devices after the restoration would display:

  tty0 Available 01-S1-00-00 Asynchronous Terminal
  tty1 Available 10-70-11-00 Asynchronous Terminal
  lp0 Available 10-70-21-00 Lexmark Optra laser printer

The remainder of this document describes how to prevent this problem, and how to fix the problem if it occurs.


Preventing mksysb problems

If there is no change in the RAN sa numbers, there will be no problems with tty or printer devices. To prevent mksysb problems, start on the first day of installation planning for the mksysb.

The following recommendations should prevent mksysb restoration problems with devices attached to 128-port adapters.


Collecting data prior to making a mksysb tape

At the time that you create the mksysb tape, use a script to save information about all your 128-port related devices. The following script will save the necessary information to successfully restore your system.

#!/bin/ksh
# Get customized attributes (lsattr info)
# Useful for restoring devices
odmget -q "name like tty*" CuAt > CuAt.tty
odmget -q "name like lp*" CuAt > CuAt.lp
odmget -q "name like sa*" CuAt > CuAt.sa
odmget -q "name like cx*" CuAt > CuAt.cx
# Get customized device info.  Contains location and sa
# Useful for restoring devices
odmget -q "name like tty*" CuDv > CuDv.tty
odmget -q "name like lp*" CuDv > CuDv.lp
odmget -q "name like sa*" CuDv > CuDv.sa
odmget -q "name like cx*" CuDv > CuDv.cx
# Get customized driver info. Contains device minor number
# Useful for restoring devices
odmget -q "value3 like tty*" CuDvDr > CuDvDr.tty
odmget -q "value3 like lp*" CuDvDr > CuDvDr.lp
odmget -q "value3 like sa*" CuDvDr > CuDvDr.sa
odmget -q "value3 like cx*" CuDvDr > CuDvDr.cx
# Get device status info 
# Useful for determining which devices need modification.
lsdev -Cc tty -F"name status location parent description" > lsdev.tty
lsdev -Cc printer -F"name status location parent description" > lsdev.printer
lsdev -Cc adapter -F"name status location parent description" > lsdev.adapter
lsdev -Cc concentrator -F"name status location parent description" >  lsdev.concentrator
# Get dev directory info
# Show the major and minor numbers of devices
ls -l /dev/tty* > ls.tty
ls -l /dev/lp* > ls.lp
ls -l /dev/cx* > ls.cx
# Use snap to collect all async and printer information
snap -A
snap -p
# Move snap information to current directory
cp /tmp/ibmsupt/printer/*.snap .
cp /tmp/ibmsupt/async/*.snap .

Create a tar file with the information and save to a tape or diskette. Also leave a copy on the system on which the mksysb tape is created.


Restoring devices using collected data

Collected post mksysb data

Create a base directory for the restoration such as /tmp/128port. Change to this directory and create three subdirectories pre, post, and working. Change to the pre directory and restore the data collected prior to creating the mksysb tape. Change to the post directory and run the get128.sh script to collect data after the mksysb restoration. Change to the working directory to evaluate the problem and begin the fix.

Evaluating the problem

To evaluate if there is a problem, and the extent of the problem, you can look at devices in order from adapter to RAN to tty or printer.

The steps to evaluate the problem are:

Check if the adapters moved locations

To see if the adapters have moved to new slots, check the differences in the device files saved from the pre and post installation. If the diff command shown below returns nothing or if the device numbers have not changed for the adapters, there should be no problems. If they have not been moved, it is not necessary to use the adapter information in restoring the terminal and printer devices. This is typical when restoring the mksysb on the same system from which the tape was made. For example:

# diff ../pre/lsdev.adapter ../post/lsdev.adapter | grep cx
> cxpa0   Available 10-70    IBM 128-Port Async (PCI) Adapter
< cxpa0   Available 10-70    IBM 128-Port Async (PCI) Adapter
> cxpa1   Available 30-60    IBM 128-Port Async (PCI) Adapter
< cxpa1   Available 30-60    IBM 128-Port Async (PCI) Adapter

NOTE: It is not necessary for the adapters to keep the same device numbers.

On the other hand, if the listing indicates that one or more of the adapters is in a new slot, this information will be necessary when restoring the printer and terminal devices. In this example, one of the 128-Port adapters is in a new slot:

# diff ../pre/lsdev.adapter ../post/lsdev.adapter | grep cx
new cxpa1   Available 10-70    IBM 128-Port Async (PCI) Adapter
old cxpa0   Available 10-70    IBM 128-Port Async (PCI) Adapter
new cxpa0   Available 10-60    IBM 128-Port Async (PCI) Adapter
old cxpa1   Available 30-60    IBM 128-Port Async (PCI) Adapter

When changes are made to the configuration files, remember that the location and the minor number of the tty and lp devices are based on the location and name of the adapter.

Check if the RANs moved locations

The tty and printer assignments are based on the RAN sa number, not on their original location. If the RAN gets a new sa number, the tty and printer definitions will be associated with the RAN that gets the same sa number after the mksysb restore. To see if any RANs changed sa numbers use the diff command as shown in the following example:

# diff ../pre/lsdev.concentrator ../post/lsdev.concentrator
1,4c1,3
PRE
< sa3 Available 10-70-22 16-Port RAN EIA-232 for 128-Port Adapter
< sa4 Available 30-60-21 16-Port RAN EIA-232 for 128-Port Adapter
< sa5 Available 10-70-11 16-Port RAN EIA-232 for 128-Port Adapter
---
POST
> sa3 Available 10-70-11 16-Port RAN EIA-232 for 128-Port Adapter
> sa4 Available 10-70-22 16-Port RAN EIA-232 for 128-Port Adapter
> sa5 Available 30-60-21 16-Port RAN EIA-232 for 128-Port Adapter

Based on this example, and what was discussed earlier about locations, tty devices previously on sa3 at location 10-70-22, which were on node 2 of line 2 on this 128-port adapter, are now on sa3 at location 10-70-11, or on line 1 node 1. Moving the RJ45 connectors from the 10-70-22 RAN to the 10-70-11 RAN in corresponding ports should allow the devices to work. With three RANs, this may be simple, but not with a half a dozen fully populated 128-port adapters. In the preceding case, all of the adapters have changed locations. To correct the problem, the configuration files for all of the devices attached to these RANs will have to change.

Check if the tty/lps moved location

Based on what was learned about RANs, it can be concluded that tty and lp devices will change locations. To confirm this, use the diff command on the example files:

# diff ../pre/lsdev.tty ../post/lsdev.tty                  
< tty1 Available 10-70-22-00 Asynchronous Terminal
< tty2 Available 10-70-22-01 Asynchronous Terminal
< tty3 Available 10-70-22-02 Asynchronous Terminal
< tty4 Available 10-70-11-15 Asynchronous Terminal
< tty5 Available 10-70-11-00 Asynchronous Terminal
< tty6 Available 30-60-21-00 Asynchronous Terminal
< tty7 Available 30-60-21-08 Asynchronous Terminal
---
> tty1 Available 10-70-11-00 Asynchronous Terminal
> tty2 Available 10-70-11-01 Asynchronous Terminal
> tty3 Available 10-70-11-02 Asynchronous Terminal
> tty4 Available 30-60-21-15 Asynchronous Terminal
> tty5 Available 30-60-21-00 Asynchronous Terminal
> tty6 Available 10-70-22-00 Asynchronous Terminal
> tty7 Available 10-70-22-08 Asynchronous Terminal
and
# diff ../pre/lsdev.printer ../post/lsdev.printer
< lp0 Available 10-70-22-05 Lexmark 4039 plus LaserPrinter
< lp1 Available 30-60-21-04 IBM 4039 LaserPrinter
< lp2 Available 10-70-11-09 Lexmark Optra laser printer
---
> lp0 Available 10-70-11-05 Lexmark 4039 plus LaserPrinter
> lp1 Available 10-70-22-04 IBM 4039 LaserPrinter
> lp2 Available 30-60-21-09 Lexmark Optra laser printer

Example of restoring a single tty

Although it would be easier to just remove and re-add this tty, it will be used as an illustration of how the process can be automated for a group of ttys. To restore a tty, correct the Object Data Manager (ODM) entries in the customized databases. In the collection script, information was gathered from all of the associated customized data bases. This section discussed how the entries that were retrieved can be used to create a working tty at the original location.

First find the location of the original tty7 from the pre lsdev.tty file.

 tty7 Available 30-60-21-08 sa4 Asynchronous Terminal

Next find the RAN sa that matches this location after the mksysb restore from the post lsdev.concentrator file.

 sa5 Available 30-60-21 16-Port RAN EIA-232 for 128-Port Adapter

The CuDv Database contains the base location, status and parent information for a tty or printer device. The entry from this database should be corrected so that it matches the information that is obtained when adding a new tty at the desired location.

The following shows the information from this database as obtained from the pre and post directories and then shows the correct value for a new tty added at this location after the mksysb.

Pre mksysbPost mksysbCorrected for restore
CuDv:
        name = "tty7"
        status = 1
        chgstatus = 1
        ddins = ""
        location = "30-60-21-08"
        parent = "sa4"
        connwhere = "8"
        PdDvLn = "tty/rs232/tty"
CuDv:
        name = "tty7"
        status = 1
        chgstatus = 1
        ddins = ""
        location = "10-70-22-08"
        parent = "sa4"
        connwhere = "8"
        PdDvLn = "tty/rs232/tty"
CuDv:
        name = "tty7"
        status = 1
        chgstatus = 1
        ddins = ""
        location = "30-60-21-08"
        parent = "sa5"
        connwhere = "8"
        PdDvLn = "tty/rs232/tty"

Take the location information from the original tty, and the sa information that matches that for the post install to get a new parent. To create a file that can be used to add the tty back, change the status to 0. Doing so will give the device the status of defined and not available after it is added. After making these changes, create a file with the following information. The name of the file in the example is CuDv.tty7:

The CuDvDr Database contains the information for setting the minor number for the device file in the /dev directory.

NOTE: This database is rebuilt by mkdev during the re-add of the tty and so does not need corrections. This information is only provided for your information, but is not needed for reinstalling the tty.

Again, compare the entries from pre, post, and fixed for this tty7 example.

Pre mksysbPost mksysbCorrected for restore
CuDvDr:
        resource = "devno"
        value1 = "48"
        value2 = "328"
        value3 = "tty7"
    CuDvDr:
            resource = "devno"
            value1 = "36"
            value2 = "88"
            value3 = "tty7"
    
    CuDvDr:
            resource = "devno"
            value1 = "36"
            value2 = "328"
            value3 = "tty7"
    

NOTE: The value1 value or major number comes from the post file, and the value2 or minor number comes from the pre file.

This is the second file, or CuDvDr.tty7:

The CuAt Database contains the device attributes and will be the same for both the pre and post. Extract this information from the CuAt.tty file from either directory. This contains changes made during or subsequent to creating the tty. All of the ODM stanzas for tty7 can be extracted into a file that, in the example, will be called CuAt.tty7.


Restoring the tty

Once the configuration files to restore the tty have been created, the tty can be removed and re-added as follows:

  1. Remove the current tty7 definition from the database.
      pdisable tty7
      rmdev -l tty7 -d
    
    This removes all of the ODM entries without issuing an odmdelete. It also removes the special devices file /dev/tty7.

  2. Make sure that there are no tty or lp devices at the new location in the CuDv.tty7 file.
      lsdev -Cc tty | grep 30-60-21-08
      lsdev -Cc printer | grep 30-60-21-08
    
  3. Add the new tty7. This can be done with the mkdev command or by adding the corrected stanzas to the ODM with the odmadd command.
      odmadd CuDv.tty7
      odmadd CuAt.tty7
    
    Adding stanzas with the odmadd command can cause problems if the command is run twice or if it is run while a device is still defined. For this reason, it is better to add the devices with the mkdev command. The new parent and the PdDvLn information will be needed for the mkdev command. The PdDvLn field of the ODM provides the information for the -c -s and -t flags of the mkdev command.
            PdDvLn = "tty/rs232/tty"
            -c tty -s rs232 -t tty
    
    The syntax of the mkdev command is:
      mkdev -l $tty -c $c1 -s $s1 -t $t1 -p $p1 -w $w1
    

  4. Verify that the new device has been added with the lsdev command. Enter lsdev -Cl tty7.
    If you use odmadd:
     
         tty7 Defined 30-60-21-08 Asynchronous Terminal
     
    If you use mkdev:
     
         tty7 Available 30-60-21-08 Asynchronous Terminal
  5. Configure the device with mkdev to add the /dev/tty7 file, to change the status in the CuDv database, and to add an entry in the /etc/inittab file if you used odmadd.
      mkdev -l tty7
    
  6. Verify that the device is now available. Try to log in to the tty.
      lsdev -Cl tty7
      tty7 Available 30-60-21-08 Asynchronous Terminal
    
  7. If you used mkdev, then run a chdev for each device based on the CuAt attribute and value fileds.
      chdev -l $tty -a "attribute=value"
    
    Example:
      chdev -l tty4 -a "login=enable"
      chdev -l tty4 -a "term=ibm3151"
    

Automating the restoration

Looking at the process in the previous example, the conclusion may be drawn that it would be easier to remove and re-add all the tty devices. While this is possible, keeping the ttys assigned to the right location would be difficult to account. This section describes a solution that may help restore all of the tty and lp devices in a single step. This procedure assumes that cables have not been moved and that all 128-port adapters are in the same previous slot.

The steps for automation are:

  1. Extract the ODM information for only those devices into new working files.
  2. Make sure the same number of RAN and 128-port adapters still exist.
  3. Identify any 128-port adapter cards that have changed location.
  4. Identify any RAN that have changed locations.
  5. Identify only the tty and lp devices that have change parent (sa) names.
  6. Remove the old tty and lp devices that have changed names.
  7. Re-add the new tty and lp devices to the correct parent.
  8. Re-add the old attributes to the tty and lp devices.
  9. Test the new devices.

Automation script

Click here to download the script as a tar file rebuild.tar.

This tar file contains two files:

Copy this file to a working directory on the restored system and unpack the file. Enter:

  tar xvf rebuild.tar

This script is designed to aid in a migration from an H50 to an H70, but will also work for restoring an H50 or H70 or other systems after mksysb restoration.

NOTE: An assumption made in this script is that 128-port cards or RAN are not added or removed during the migration.

The script rebuild has the following functions:

Running the script

Before running the script, log in to ttys that you suspect may have problems. Enter tty to determine the tty number. Once the script has finished running, repeat this exercise to determine if it is the desired tty name.

The script can be run from any directory. Use something like /home/restore. Once it has completed, everything can be cleaned up with the following commands:

  rm -R /home/restore
  rm -R /tmp/etc

Make sure the script has permissions for executions. Run the script as root user. Enter ./rebuild to start the script. The following shows the dialog from a test run.

In this example, since the script has been run, things are already cleaned up. To run through the script again, answer n. If this was the first time, it would have asked to have the mksysb tape placed in the tape drive and to hit enter. If no local data was collected, it would not prompt.

The previous section confirmed that there were no hardware changes to the system.

The script now looks at the locations of the RAN. In this case, there were no adapters at location 30-60, but it recognizes that if this is a migration to an H70 that 40-60 is an equivalent adapter location. If the card was moved, it would have prompted for possible matches.

This second RAN was found to exist on the same card as previously, but during the rebuild the RAN node number changed from 2 to 1. This might be an indication that sometime previously a RAN was removed from the old configuration, or the node number was set wrong during installation. Again, after looking at the files in ../pre and ../post, respond with y to this question.

This is the more normal sequence where the RAN has maintained the same location, but simply changed names creating the problem. The script here shows you the re-assignments that will be made between the two systems. Since the information is correct, enter y to continue. Entering n stops the script, letting you gather more information before running it again. The next output, shows which ttys will be moved during the rebuild process. In this case tty2, tty3, and lp1 are on the correct sa# and will not be removed and re-added. tty1, tty2 and lp0 were on the RAN in slot 6 on the H50 before migration, but are now assigned to the 128-port adapter in slot 4 of the H70. The process will move them back to the slot 6 adapter at location 40-60 after the rebuild.

tty5, tty6, and lp2 were moved from the adapter in slot 4 of the H50 to slot 6 on the H70, and will be moved back by the script to slot 4 of the H70.

After confirming this information is correct, press Enter to continue. If the information is not correct, press ctrl-C to break out of the script, gather information and rerun the script.

This shows that all the devices were removed successfully. If some of the devices were busy, you would have been asked to close the task and press Enter to continue. To break out from the script at this time, answer n when asked to get new information from the system in the first stage of the script.

This shows that the tty and lp devices were re-added successfully. This shows that the devices are now available.

Look for errors in the rebuild.log shown here for this successful run.

The remap.list file shows the RAN mappings between systems. The chtty.list file shows the ttys that were moved and the locations before and after the move.

Rerunning the script

The ../post directory information was moved and saved. The script was rerun to see what new changes it would find.

This shows information for all tty and lp devices on all 128-port adapters. The example shows that the questions were still asked. Entering new answers would re-arrange the ttys again. Since they are in the right place, no new changes are made. The log this time shows: Remember to check the tty names on your terminals.


Restoring when no data was collected

The script above collects data from the mksysb tape and the rebuilt system. It requires no other data except a knowledge of the system.


[ Doc Ref: 92713993111490     Publish Date: Oct. 19, 2000     4FAX Ref: 6489 ]