With full access to the switch, I shifted focus to the next problem: I was nearing the limit of my current power equipment. The next goal was to see what load I could reduce in the message switches. The biggest savings would come from reducing from two duplex planes to one simplex, but I could squeeze out a bit more by consolidating some cards and eliminating a few others. That would also give me a chance to familiarize myself with the maintenance and table editing interfaces
The inter-message-switch links are (apparently optional) links that connect the two message switch planes together to allow them to share load. Normally these links are created on different cards for what I assume are redundancy purposes, and in fact the switch will not allow you to create two on the same card.
On my switch, the inter-MS links were a pair of DS-30s crossing between the two MS shelves. I saw no reason not to keep one link, even if it was optional (a bit more on that later), so I decided to get rid of one link and leave the first.
I started by first busying the ports on each of the cards using the mapci interface. Then I edited the MSILINV table.
CI:
>table msilinv
JOURNAL FILE UNAVAILABLE - DMOS NOT ALLOWED
TABLE: MSILINV
>lis all
TOP
IMSL SHELFNO CARDNO INFO
----------------------------
0 0 20 DS30 2
1 0 21 DS30 3
BOTTOM
>lis
IMSL SHELFNO CARDNO INFO
----------------------------
1 0 21 DS30 3
>del
JOURNAL FILE UNAVAILABLE - DMOS NOT ALLOWED
ENTER Y TO CONTINUE PROCESSING OR N TO QUIT
>y
TUPLE TO BE DELETED:
1 0 21 DS30 3
ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT.
>y
TUPLE DELETED
JOURNAL FILE INACTIVE
WARNING: CURRENTLY NOT POSITIONED
>leave
CI:
>I listed all the records (knowing there were only a couple, so it wouldn't flood the terminal) and determined the last one was the one I needed to delete. since it was the most recently selected from the list command, all I had to do was delete it.
At this point, the card that the link was on now was empty, so I could remove that card as well. Back in the mapci interface, I busied and then offlined the cards in each shelf. Then I made my way back out to edit the MSCDINV table.
CI:
>table mscdinv
JOURNAL FILE UNAVAILABLE - DMOS NOT ALLOWED
TABLE: MSCDINV
>lis 9
TOP
MSCDKEY SLOTINFO
----------------------------------------------------------------------------
0 0 1 TBUSACC NT9X52AA NIL
0 0 2 CLOCK NT9X53AD NT9X54AC
0 0 3 MSP NT9X13DG NT9X26AB
0 0 5 MAPPER NT9X15AA
0 0 6 CHAIN DS512 NT9X17DA NT9X20BB $
0 0 8 CHAIN DS512 NT9X17DA NT9X20BB $
0 0 19 DS512 NT9X17AD NT9X62BA 2
0 0 20 DS30 NT9X17AD NT9X23AA
0 0 21 DS30 NT9X17AD NT9X23AA
>del
JOURNAL FILE UNAVAILABLE - DMOS NOT ALLOWED
ENTER Y TO CONTINUE PROCESSING OR N TO QUIT
>y
TUPLE TO BE DELETED:
0 0 21 DS30 NT9X17AD NT9X23AA
ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT.
>y
TUPLE DELETED
JOURNAL FILE INACTIVE
>lis 14
MSCDKEY SLOTINFO
----------------------------------------------------------------------------
0 0 22 DS30 NT9X17AD NT9X23AA
0 0 23 DS30 NT9X17AD NT9X23AA
0 0 24 CMIC NT9X17AD NT9X63AB
0 0 25 CMIC NT9X17AD NT9X63AB
0 0 26 PBUS NT9X49CB NIL
1 0 1 TBUSACC NT9X52AA NIL
1 0 2 CLOCK NT9X53AD NT9X54AC
1 0 3 MSP NT9X13DG NT9X26AB
1 0 5 MAPPER NT9X15AA
1 0 6 CHAIN DS512 NT9X17DA NT9X20BB $
1 0 8 CHAIN DS512 NT9X17DA NT9X20BB $
1 0 19 DS512 NT9X17AD NT9X62BA 2
1 0 20 DS30 NT9X17AD NT9X23AA
1 0 21 DS30 NT9X17AD NT9X23AA
>del
JOURNAL FILE UNAVAILABLE - DMOS NOT ALLOWED
ENTER Y TO CONTINUE PROCESSING OR N TO QUIT
>y
TUPLE TO BE DELETED:
1 0 21 DS30 NT9X17AD NT9X23AA
ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT.
>y
TUPLE DELETED
JOURNAL FILE INACTIVE
>leave
CI:
>From there, I removed the tuples for the cards that used to run the second inter-MS link.
The Link Interface Shelf or LIS contains Line Interface Units or LIUs used in the supernode architecture for communications like SS7 links, X.25, frame relay, and Ethernet. My switch has a single LIS with a single Ethernet Interface Unit (EIU). However, that feels like a lot of equipment to power up for just one 10Mbit/s ethernet port, especially when the XA-core has 10/100 ports on it already, so I never even bothered to wire power to that.
That said, the LIS shelf had a DS512 link back to the message switch and a whole card dedicated to it. Needless to say, that's another card I could eliminate to shave off some watts.
Before I could get rid of the LIS shelf, I had to get rid of the EUI. Firstly, I pulled up the EIU in the Peripheral Module (PM) section of the MAPCI. My first attempts to BSY the unit failed because it was already in the SysB state. However, this wasn't good enough to remove it, so I eventually figured out the 'force' option to force it busy and then OOS so I could remove it's tuples.
CI:
>table liuinv
JOURNAL FILE UNAVAILABLE - DMOS NOT ALLOWED
TABLE: LIUINV
>lis
TOP
LIUNAME LOCATION LOAD PROCINFO
CARDINFO
---------------------------------------------------------------
EIU 0 MS 19 0 1 8 ETC22BN NTEX22BB
NT9X84AA NT9X85AA NO 000075F0C0EE
>del
JOURNAL FILE UNAVAILABLE - DMOS NOT ALLOWED
ENTER Y TO CONTINUE PROCESSING OR N TO QUIT
>y
TUPLE TO BE DELETED:
EIU 0 MS 19 0 1 8 ETC22BN NTEX22BB
NT9X84AA NT9X85AA NO 000075F0C0EE
ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT.
>y
Warning: Previously modified tuple in table IPTHRON is deleted
TUPLE DELETED
JOURNAL FILE INACTIVE
WARNING: CURRENTLY NOT POSITIONED
>leave
CI:
>Once that was complete, I removed the EUI from table LIUINV. There were some IP-related tuples that had to be removed as well.
Next, the LIS itself would have to be removed. In order to do this, the FBUS needed to be placed out of service. Complicating matters, my LIS was directly connected to the message switches, rather than inside an LPP frame. Most of the documentation assumes you have an LPP frame, which contains LIS along with a Local Message Switch (LMS) where the LIS talks to the LMS, and the LMS talks to the MS.
The trick ended up being to get to the specific port on the message switch card in the MAPCI, then run Bsy 0 FBUS force to busy the fbus on that port on MS 0, for example. Then rinse and repeat for MS 1, and then similar to offline the FBUS, but without the force as that paramater isn't valid for offlining.
CI:
>table SUSHELF
TABLE: SUSHELF
>lis
TOP
SHELFKEY FLOOR ROW FRAMEPOS FRAMETYP FRAMENUM SHELFPOS SHELFPEC
CARDINFO
----------------------------------------------------------------------------
MS NIL 19 0 1 1 AA 2 MCNI 0 26 NT9X72CA
(7 NT9X96AA NT9X98AA) (30 NIL NTEX20AA) (1 NT9X31AB NIL)
(4 NT9X30AB NIL) $ (32 NT9X96AA NT9X98AA) (8 NIL NTEX20BA)
(33 NT9X31AB NIL) (36 NT9X30AB NIL) $
>del
TUPLE TO BE DELETED:
MS NIL 19 0 1 1 AA 2 MCNI 0 26 NT9X72CA
(7 NT9X96AA NT9X98AA) (30 NIL NTEX20AA) (1 NT9X31AB NIL)
(4 NT9X30AB NIL) $ (32 NT9X96AA NT9X98AA) (8 NIL NTEX20BA)
(33 NT9X31AB NIL) (36 NT9X30AB NIL) $
ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT.
>y
TUPLE DELETED
WRITTEN TO JOURNAL FILE AS JF NUMBER 7
WARNING: CURRENTLY NOT POSITIONED
>leave
>This finally allowed me to remove the LIS in table SUSHELF.
CI:
>table mscdinv
TABLE: MSCDINV
>lis 7
TOP
MSCDKEY SLOTINFO
----------------------------------------------------------------------------
0 0 1 TBUSACC NT9X52AA NIL
0 0 2 CLOCK NT9X53AD NT9X54AC
0 0 3 MSP NT9X13DG NT9X26AB
0 0 5 MAPPER NT9X15AA
0 0 6 CHAIN DS512 NT9X17DA NT9X20BB $
0 0 8 CHAIN DS512 NT9X17DA NT9X20BB $
0 0 19 DS512 NT9X17AD NT9X62BA 2
>del
TUPLE TO BE DELETED:
0 0 19 DS512 NT9X17AD NT9X62BA 2
ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT.
>y
TUPLE DELETED
WRITTEN TO JOURNAL FILE AS JF NUMBER 8
>lis 13
MSCDKEY SLOTINFO
----------------------------------------------------------------------------
0 0 20 DS30 NT9X17AD NT9X23AA
0 0 22 DS30 NT9X17AD NT9X23AA
0 0 23 DS30 NT9X17AD NT9X23AA
0 0 24 CMIC NT9X17AD NT9X63AB
0 0 25 CMIC NT9X17AD NT9X63AB
0 0 26 PBUS NT9X49CB NIL
1 0 1 TBUSACC NT9X52AA NIL
1 0 2 CLOCK NT9X53AD NT9X54AC
1 0 3 MSP NT9X13DG NT9X26AB
1 0 5 MAPPER NT9X15AA
1 0 6 CHAIN DS512 NT9X17DA NT9X20BB $
1 0 8 CHAIN DS512 NT9X17DA NT9X20BB $
1 0 19 DS512 NT9X17AD NT9X62BA 2
>del
TUPLE TO BE DELETED:
1 0 19 DS512 NT9X17AD NT9X62BA 2
ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT.
>y
TUPLE DELETED
WRITTEN TO JOURNAL FILE AS JF NUMBER 9
>leave
CI:
>The next thing I had on my list was to see if I could consolidate the message switch DS-30 links for the IOMs onto a single card. They were each on a separate card with just one port being used, I assume for redundancy reasons. I set out to move them both onto the same card as the remaining inter-MS link thus reducing the job of four cards in each message switch down to just 1. This is why I saw no need to get rid of the inter-MS link: so long as I'm running a four-port DS-30 card, I may as well use one port for the inter-MS link.
I would have to shuffle the IOMs around without taking the switch down. I knew it should be possible given I had two IOMs: I could just move one over at a time while using the other for terminal access.
As usual, the IOM needed to be offline before any changes could be made to it. This turned out to be quite a chore, as all the devices on the IOM had to be taken out of service (such as terminals and disk drives), followed by all the device adapters, and then finally the IOM itself. There was a bit of a special procedure for the disks, complicated by the fact that some random process was trying to use them while I was trying to take them offline. I ended up using the force parameter to force them offline.
CI:
>table ioc
TABLE: IOC
>lis all
TOP
IOCNO FRTYPE
FRNO SHPOS FLOOR ROW FRPOS MSCARD MSPORT PECINFO
----------------------------------------------------------------------------
0 MCAM
0 19 1 E 0 23 0 FX30AA MTM 16 3
IOMRBC01 F02LPMLD
1 MCAM
0 33 1 E 0 22 0 FX30AA MTM 17 3
IOMRBC01 F02LPMLD
BOTTOM
>replace
IOCNO:
>1
FRTYPE:
>mcam
FRNO:
>0
SHPOS:
>33
FLOOR:
>1
ROW:
>e
FRPOS:
>0
MSCARD:
>20
MSPORT:
>1
EQPEC:
>fx30aa
PMTYPE:
>mtm
PMNO:
>17
CARD_POSITION:
>3
DFILE:
>IOMRBC01
DEVNAME:
>F02LPMLD
TUPLE TO BE REPLACED:
1 MCAM
0 33 1 E 0 20 1 FX30AA MTM 17 3
IOMRBC01 F02LPMLD
ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT.
>y
TUPLE REPLACED
WRITTEN TO JOURNAL FILE AS JF NUMBER 11
> Then it was time to move the IOM to it's new port. The tuple was edited in table IOC, then I built a cable to allow me to split up the ports from the card being used for the inter-MS links to also attach the IOMs. The cabling was switched, followed by bringing the IOM totally back online.
From there, I switched terminals to the other IOM and repeated the process for the first one which had yet to be moved. Then I could finally busy out the MS port cards and remove their tuples.
With all the extra cards removed from the tables, I could now physically unslot the cards and their paddleboards from the message switch. I saved about 240W overall, though that is split between two message switches.
Cutting out one of the two message switches saved another 450W, so about 570W overall.
With some power budget won back, I could move on to getting more equipment powered.