SWXCRMGR Update

SWXCRMGR Update

Post by Adrian Birket » Fri, 27 Jun 2003 00:51:51



All,

Thaks for your replies to an earlier post. The raid initialization
procedure has now been going for 8 days with 3 sets still outstanding
(2*4disk sets and 1*3disk set - each disk = 2GB) with 72, 78 and 96%
completion status at the time of writing.

I agree with the customer that this cannot be normal behaviour, however,
I am using TNG Console Manager with the serial line connected into a
terminal server and over the network as the box is in Holland and I'm in
the UK.

Can anyone give me some 'real-world' examples of having used this
procedure and give me an idea of the times involved. The customer is
getting (quite rightly) a bit p****d off as we still have to instal VMS
and suchlike once this is completed.

aTdHvAaNnKcSe

Ade

 
 
 

SWXCRMGR Update

Post by mckinn.. » Thu, 26 Jun 2003 19:59:53



> All,

> Thaks for your replies to an earlier post. The raid initialization
> procedure has now been going for 8 days with 3 sets still outstanding
> (2*4disk sets and 1*3disk set - each disk = 2GB) with 72, 78 and 96%
> completion status at the time of writing.

> I agree with the customer that this cannot be normal behaviour, however,
> I am using TNG Console Manager with the serial line connected into a
> terminal server and over the network as the box is in Holland and I'm in
> the UK.

> Can anyone give me some 'real-world' examples of having used this
> procedure and give me an idea of the times involved. The customer is
> getting (quite rightly) a bit p****d off as we still have to instal VMS
> and suchlike once this is completed.

> aTdHvAaNnKcSe

> Ade

fwiw...

My experience (long ago) using the command line SWXCRMGR on a 3 channel
EISA controller was that initializing units similar to yours took hours -
many hours - but fewer than 24 hours - when initializing as many as
15 physical disks simultaneously. I think that my case was 3 raid sets -
6 disks, 6 disks, and 3 disks (but my memory could be faulty); and the
disks may have been 4Gb RZ29s.

--
- Jim

 
 
 

SWXCRMGR Update

Post by David B Sneddo » Fri, 27 Jun 2003 20:19:07



> All,

> Thaks for your replies to an earlier post. The raid initialization
> procedure has now been going for 8 days with 3 sets still outstanding
> (2*4disk sets and 1*3disk set - each disk = 2GB) with 72, 78 and 96%
> completion status at the time of writing.

> I agree with the customer that this cannot be normal behaviour, however,
> I am using TNG Console Manager with the serial line connected into a
> terminal server and over the network as the box is in Holland and I'm in
> the UK.

> Can anyone give me some 'real-world' examples of having used this
> procedure and give me an idea of the times involved. The customer is
> getting (quite rightly) a bit p****d off as we still have to instal VMS
> and suchlike once this is completed.

> aTdHvAaNnKcSe

> Ade

I remember my first use of the swxcrmgr utility running on a VT terminal.
After about the 10% stage you could see what it was doing to update
the screen which must have been doing an update after every I/O.  It
got slower and slower.  You could see the cursor going crazy all over
screen.  Doing the same thing using a graphics monitor the time was
about 40 minutes as opposed to about 12 hours on the VT.
An absolutely dreadful piece of software.

Regards,
Dave.
--

Sneddo's quick guide ...          http://www.users.bigpond.com/dbsneddon/
DBS freeware at ...   http://www.users.bigpond.com/dbsneddon/software.htm
"Life is what happens to you while you're busy making other plans" Lennon

 
 
 

SWXCRMGR Update

Post by Carl Perki » Sat, 28 Jun 2003 03:41:00




}> All,
}> I agree with the customer that this cannot be normal behaviour, however,
}> I am using TNG Console Manager with the serial line connected into a
}> terminal server and over the network as the box is in Holland and I'm in
}> the UK.
}>
}> Ade
}
}I remember my first use of the swxcrmgr utility running on a VT terminal.
}After about the 10% stage you could see what it was doing to update
}the screen which must have been doing an update after every I/O.  It
}got slower and slower.  You could see the cursor going crazy all over
}screen.  Doing the same thing using a graphics monitor the time was
}about 40 minutes as opposed to about 12 hours on the VT.
}An absolutely dreadful piece of software.
}
}Regards,
}Dave.

Which brings up the question of what communication speed his terminal
is set to use.

If it is something unusually slow, like 4800 bps or lower since 9600 bps
is generally the "normal" speed, then that (in conjuntion with the very
poor design of the software) could explain why it is taking him even longer
than everybody else.

Simply doubling the communication speed setting of the terminal could
cut the time in half, unless there are serious bottlenecks in his
network connection as well. Likewise for quadrupling it to cut the time
by a factor of 4.

--- Carl

 
 
 

SWXCRMGR Update

Post by Adrian Birket » Sat, 28 Jun 2003 19:34:22





> }> All,
> }> I agree with the customer that this cannot be normal behaviour, however,
> }> I am using TNG Console Manager with the serial line connected into a
> }> terminal server and over the network as the box is in Holland and I'm in
> }> the UK.
> }>
> }> Ade
> }
> }I remember my first use of the swxcrmgr utility running on a VT terminal.
> }After about the 10% stage you could see what it was doing to update
> }the screen which must have been doing an update after every I/O.  It
> }got slower and slower.  You could see the cursor going crazy all over
> }screen.  Doing the same thing using a graphics monitor the time was
> }about 40 minutes as opposed to about 12 hours on the VT.
> }An absolutely dreadful piece of software.
> }
> }Regards,
> }Dave.

> Which brings up the question of what communication speed his terminal
> is set to use.

> If it is something unusually slow, like 4800 bps or lower since 9600 bps
> is generally the "normal" speed, then that (in conjuntion with the very
> poor design of the software) could explain why it is taking him even longer
> than everybody else.

> Simply doubling the communication speed setting of the terminal could
> cut the time in half, unless there are serious bottlenecks in his
> network connection as well. Likewise for quadrupling it to cut the time
> by a factor of 4.

> --- Carl

The console port is set to the usual 9600. Unfortunately, I would have to stop
the procedure to change it - not an option at this stage.

By the way, we're almost there now with the last two sets reporting 92 and 85%.

Cheers,

Ade

 
 
 

1. How to run SWXCRMGR.EXE

I started a new system management position and inherited a RAID set.

I wish to run the SWXCRMGR.EXE utility for the first time, but don't
know what I am doing wrong. If you can tell via my commands below,
please enlighten me.

$ run sys$sysdevice:[sys0.syscommon.sysexe]swxcrmgr.exe
X Toolkit Error: Can't open display:
%DWT-F-NOMSG, Message number 03AB8204
%TRACE-F-TRACEBACK, symbolic stack dump follows
  image    module    routine             line      rel PC           abs
PC
                                            0 FFFFFFFF8078E2D8
FFFFFFFF8078E2D8
                                            0 FFFFFFFF8078DECC
FFFFFFFF8078DECC
                                            0 FFFFFFFF8078E108
FFFFFFFF8078E108
                                            0 FFFFFFFF8078C8B4
FFFFFFFF8078C8B4
                                            0 FFFFFFFF80798FCC
FFFFFFFF80798FCC
 SWXCRMGR  MAIN  main                   23834 00000000000017EC
0000000000037AAC
 SWXCRMGR  MAIN  __main                     0 0000000000000088
0000000000036348
                                            0 FFFFFFFF8697F0D8
FFFFFFFF8697F0D8
$

2. *********** Pro*C Question *********

3. Storage Works: SWXCRMGR access from VMS

4. GPFs in Developer/2000 - Component Integration

5. update: DFWDAYS, A Compaq Update Weekend June 2nd, 3rd, and 4th

6. Linpack (9/28) c.be FAQ

7. MadGoat FTP update, KILL update

8. FILESERV@WKU: Updated PROBE, new TESTDEV, updated VMSTAR

9. Vienna and London Technical UPdate days

10. Updated DII-COE Web Pages for OpenVMS

11. OT: killfile updates

12. updating BIND?