1 INFO-VAX	Sun, 18 Dec 2005	Volume 2005 : Issue 702       Contents:7 Re: illegal blowjobs by Ottawa pedophile Darrell Larose  Re: monitoring VMS log files MSCP transfer rates  Re: MSCP transfer rates  Re: MSCP transfer rates  Re: MSCP transfer rates  Re: MSCP transfer rates  Re: MSCP transfer rates  Re: MSCP transfer rates  QBUS DHV11 in VAX 4000-600/200" Re: QBUS DHV11 in VAX 4000-600/200" Re: QBUS DHV11 in VAX 4000-600/200 Re: Storageworks shelves  F ----------------------------------------------------------------------  % Date: Sat, 17 Dec 2005 17:30:59 -0500  From: GIGANEWS <grubb>@ Subject: Re: illegal blowjobs by Ottawa pedophile Darrell Larose8 Message-ID: <0c49q11bumgc65113669smd49b70hq0899@4ax.com>  E On 14 Dec 2005 07:06:22 -0800, "Nomen Nescio" <geoff_one@hotmail.com>  wrote:   >  >Nomen Nescio wrote: >>  $ >yawn, you really need to get a life     A life and a Doctor.   ------------------------------    Date: 17 Dec 2005 13:17:01 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) % Subject: Re: monitoring VMS log files 3 Message-ID: <+tgBcXqdjVa2@eisner.encompasserve.org>   ` In article <43A391E9.E15667DE@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> writes: > Jeff Cameron wrote:  >>  " >> On 12/15/05 8:25 AM, in articleG >> 1134663926.819306.74400@g49g2000cwa.googlegroups.com, "Ken Robinson"  >> <kenrbnsn@gmail.com> wrote: >>   >> > >> > tumblindice wrote: 	 >> >> Hi,  >> >> H >> >>    We would like to monitor our VMS logfiles, operator.log and theK >> >> security files to a machine that could send out email to notify us of L >> >> discrepancies. There are a few tools out there for UNIX but I have notB >> >> seen anything for VMS. Any help or pointers would be greatly >> >> appreciated. Thank you.  >> >L >> > There are a number of products like that. Two that come to mind are theK >> > Unicenter Console Management for OpenVMS from CA and ConsoleWorks from 1 >> > TECsys Developement <http://www.tditx.com/>.  >> > >> > Ken >> >L >> Both the OPCOM and The Security Auditor have a calling interface allowing, >> your process to intercept these messages. > F > A generic piece that would be useful to many ISVs would be simple toH > implement OPCOM listener/API. ConsoleWorks / ConsoleManager is just to > much for many applications.   D Calling the API is trivial.  Doing something with the results is theE hard part.  Separate callbacks for each possible event are one model, H with no callback when the client does not provide a callback entrypoint.F That approach, however, will waste a lot of cycles processing messagesC with which nothing is to be done.  So perhaps it would be better to D screen the binary messages to select only those of interest for someF particular site.  Perhaps a quick way to view all the messages as theyC are generated.  But wait !  That is exactly what the Audit Listener  Mailbox provides !   ------------------------------  % Date: Sat, 17 Dec 2005 13:47:10 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>  Subject: MSCP transfer rates+ Message-ID: <43A45D26.13C592B@teksavvy.com>   B I did a backup from a disk on my all mighty Microvax II to a bound6 volume set on DSSI disks running with a VAX4000-600A.   G During this time, the all mighty Microvax II was running at nearly 100% @ CPU (but usually not at 100%). The ethernet light on the hub wasC constantly on during disk transfers (not flashing). (This is 10mbps H ethernet). The 4000 was running at 4-8% CPU.  Disk activity was in largeH bursts. So I assume the BACKUP command could gather enough data from the? source disk and then write to the target disks in large bursts.    Forgetting overhead:  H For 10mbps ethernet, it should be able to do 1.25 mega bytes per second. (10 million / 8).   * For 4 gigs, it should take roughly 1 hour.  , My backup took over 4 hours. (disk to disk).  G doing MON MSCP didn't reveal any fragmented packets rates. MSCP BUFFERS @ is set to default 128. Would increasing it make any difference ?  E Would a microvax II really be too slow to MSCP serve at full ethernet C speed ?  Or did this backup take so long mostly because of ethernet G speed limitations combined with the BACKUP behaviour of reading a whole & chunk and then writing a whole chunk ?   ------------------------------  % Date: Sat, 17 Dec 2005 19:56:30 -0000 @ From: "Alex Daniels" <alexNOSPAMHERETHANKSdaniels@themail.co.uk>  Subject: Re: MSCP transfer rates6 Message-ID: <43a46d6b$0$29561$da0feed9@news.zen.co.uk>  ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  % news:43A45D26.13C592B@teksavvy.com...    > Forgetting overhead:  H I wouldn't, while you can drive FDDI to very high utilisation levels, I 7 wouldn't expect anywhere near wire speed from Ethernet.   G > Would a microvax II really be too slow to MSCP serve at full ethernet 	 > speed ?   G The I/O bus on the Microvax II can handle an all mighty 3.3 MB/s (max).    Alex     ------------------------------  + Date: Sat, 17 Dec 2005 21:44:22 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney)   Subject: Re: MSCP transfer rates( Message-ID: <do20rl$cia$1@pcls4.std.com>  / JF Mezei <jfmezei.spamnot@teksavvy.com> writes:   C >I did a backup from a disk on my all mighty Microvax II to a bound 7 >volume set on DSSI disks running with a VAX4000-600A.    6 On which system was the BACKUP command itself running?  H >During this time, the all mighty Microvax II was running at nearly 100%A >CPU (but usually not at 100%). The ethernet light on the hub was D >constantly on during disk transfers (not flashing). (This is 10mbps- >ethernet). The 4000 was running at 4-8% CPU.   E I'll have to guess the BACKUP was running on the microvax.  I bet the A CRC generation (which BACKUP does by default even when going from / disk to disk) sucks up lots of microvax II CPU.    >Forgetting overhead:   H Don't.  If I remember correctly, a 10Mbps Ethernet can only go to 80-90%E utilization (bitwise) except under unusual circumstances.  And of the J packets on the wire, you have SCS acknowledgement packets, plus normal SCSI traffic plus anything else (DECnet? TCPIP?) at low levels.  Of the actual I data transfer packets, you have 64 bits of ethernet preamble (= 8 bytes)  E plus 12 bytes ethernet address plus 2 bytes protocol plus 4 bytes CRC F leaving a max of 1500 bytes left for SCS, some of that is SCS overhead4 before you can figure out how much is left for data.  F And I'm not sure a DELQA can drive an ethernet at max capacity anyway.   ------------------------------  % Date: Sat, 17 Dec 2005 17:00:23 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>   Subject: Re: MSCP transfer rates, Message-ID: <43A48A61.E92DC77C@teksavvy.com>   Michael Moroney wrote:8 > On which system was the BACKUP command itself running?  < On the 4000-600.  So the MVII was handling only the MSCP and& SCS/ETHERNET to feed data to the 4000.  D I am doing a similar backup now running on the 4000 and pulling dataD from a disk served by a 3100. And it is sucking up much CPU from theG 3100 too (but not to 100%). It is interesting that MON SYS doesn't show E the "MSCP process" as the top CPU user. (is it CLUSTER_SERVER process  which handles this ?)   H > And I'm not sure a DELQA can drive an ethernet at max capacity anyway.  C Since QBUS is 3 megaBYTES per second, shouldn't a DELQUA be able to 0 handle 10 megabits (1.25 megabytes) per second ?   ------------------------------  # Date: Sat, 17 Dec 2005 22:42:27 GMT # From: nospam@nouce.bellatlantic.net   Subject: Re: MSCP transfer rates8 Message-ID: <9m49q1pkm8g1un59dk41smd9jgvi63rhjm@4ax.com>  , On Sat, 17 Dec 2005 17:00:23 -0500, JF Mezei% <jfmezei.spamnot@teksavvy.com> wrote:    >Michael Moroney wrote: 9 >> On which system was the BACKUP command itself running?  > = >On the 4000-600.  So the MVII was handling only the MSCP and ' >SCS/ETHERNET to feed data to the 4000.  > E >I am doing a similar backup now running on the 4000 and pulling data E >from a disk served by a 3100. And it is sucking up much CPU from the H >3100 too (but not to 100%). It is interesting that MON SYS doesn't showF >the "MSCP process" as the top CPU user. (is it CLUSTER_SERVER process >which handles this ?) > I >> And I'm not sure a DELQA can drive an ethernet at max capacity anyway.  > D >Since QBUS is 3 megaBYTES per second, shouldn't a DELQUA be able to1 >handle 10 megabits (1.25 megabytes) per second ?   F Not really.  Between overhead and transactions with the CPU I've neverD seen it exceed 400kb/S by much though burst traffic may hit the fullB speed.  Eithernet tends to have and need a bit of dead air to work best.   @ However.. allowing for DELQA, uVAX-II and Qbus you also have theD RQDXn.  The RQDX is SLOW with the RQDX3 version being the fastest of< the SLOW.    The data rate your seeing is result of Eithenet? limitations and RQDX speed with some amount of delays inbetween  from CPU, MEMORY and Q-BUS.   ? In the 3100 its'  the SCSI interface and the CPU speed that are - limiting factors with eithernet contributing.        Allison    ------------------------------  + Date: Sat, 17 Dec 2005 23:48:16 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney)   Subject: Re: MSCP transfer rates( Message-ID: <do2840$4ks$1@pcls4.std.com>  / JF Mezei <jfmezei.spamnot@teksavvy.com> writes:   H >3100 too (but not to 100%). It is interesting that MON SYS doesn't showF >the "MSCP process" as the top CPU user. (is it CLUSTER_SERVER process >which handles this ?)  J There is no "MSCP process".  The MSCP Server is implemented in an execlet : that runs entirely at interrupt level, much like a driver.  > You'd need something that monitors system PCs to see where theA system is spending its time.  There is something in VMS that does  this, but I forgot what.  D But who cares, you just proved a uVII is slow, which everyone knows.  I >> And I'm not sure a DELQA can drive an ethernet at max capacity anyway.   D >Since QBUS is 3 megaBYTES per second, shouldn't a DELQUA be able to1 >handle 10 megabits (1.25 megabytes) per second ?   K Not necessarily. It depends on the speed of the onboard processor, whether  D it can DMA data while transmitting at the same time, and a few other things.   E I do know there is a variant of the DELQA with upgraded firmware that " is faster than the standard DELQA.   ------------------------------  % Date: Sat, 17 Dec 2005 19:22:43 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>   Subject: Re: MSCP transfer rates, Message-ID: <43A4ABB3.2DD73EED@teksavvy.com>   Michael Moroney wrote:F > But who cares, you just proved a uVII is slow, which everyone knows.  F I didn't expect it to hit its CPU limit while doing just MSCP serving.   Out of curiosity:   C What I did: node2 uses BACKUP to pull data from a MVII served disk.   G What if I had setup a shadow set with the MVII's disk serving as source G and the node2 disk serving as target of the copy. Would this have ended + up being more efficient than BACKUP/IMAGE ?   F Is it the node that issues the MOUNT command which becomes responsibleH for the processing of the shadow copy ? Or is it the node which owns the
 source disk ?    ------------------------------  % Date: Sat, 17 Dec 2005 21:00:39 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ' Subject: QBUS DHV11 in VAX 4000-600/200 , Message-ID: <43A4C2C6.FE8FDB40@teksavvy.com>  : I tried to insert a spare DHV11 in my newly adopted VAXen.  C >>>CONFIGURE has no problem accepting "DHV11" and gives me standard  address/CSR (same as on MVII).  3 Once the board is added, SHOW QBUS sees the board.  % The board has a steady green light.     H Booting VMS, once it has done the AUTOCONFIGURE ALL, 8 TX devices TX0 to TX7 appear.   8 However, pressing return from a terminal yields nothing.C REPLY/TERM=TXA3 "hello" yields what appears to be just a CR/LF. (or  maybe just an LF).  F SET HOST/DTE TXA3 goes in and aborts within a couple of seconds with a DEVICE TIMEOUT. = COPY fsome_text.file TXA3: yields a DEVICE TIMEOUT very fast.   G However, SET TERM/PERM/MODEM TXA3  succeeds and I see the modem control   signals turning on on that line.  H Should I conclude anything from this ? Does this mean that it will never work ?    F Would I stand better odds with a DHQ11, a slightly younger clone (only9 half the width of DHV11) ? Or will this likely fail too ?   @ I was expecting incomatibility to result in the device not being@ accepted at all. Didn't expect VMS to be able to performs *some*- operations on it but not basic data transfer.     F It is interesting that for the supported devices (CXY08 for instance),F the boards are set to emulate a DHV11, but the real McCoy doesn't seem to work.  G Is there any way for me to debig what is going on to cause it to fail ?    ------------------------------  # Date: Sun, 18 Dec 2005 03:39:28 GMT   From: John Santos <john@egh.com>+ Subject: Re: QBUS DHV11 in VAX 4000-600/200 , Message-ID: <QR4pf.26638$Ht4.24272@trnddc08>   JF Mezei wrote: < > I tried to insert a spare DHV11 in my newly adopted VAXen. >  > D >>>>CONFIGURE has no problem accepting "DHV11" and gives me standard >   > address/CSR (same as on MVII).  A I forget if the DHV has hardware or software vector settings.  If B hardware, this sounds like you've got the vector wrong.  It should= probably be 300, depending on what other options are present.    > 5 > Once the board is added, SHOW QBUS sees the board.  ' > The board has a steady green light.    > J > Booting VMS, once it has done the AUTOCONFIGURE ALL, 8 TX devices TX0 to
 > TX7 appear.  > : > However, pressing return from a terminal yields nothing.E > REPLY/TERM=TXA3 "hello" yields what appears to be just a CR/LF. (or  > maybe just an LF). > H > SET HOST/DTE TXA3 goes in and aborts within a couple of seconds with a > DEVICE TIMEOUT. ? > COPY fsome_text.file TXA3: yields a DEVICE TIMEOUT very fast.  > I > However, SET TERM/PERM/MODEM TXA3  succeeds and I see the modem control " > signals turning on on that line. > J > Should I conclude anything from this ? Does this mean that it will never	 > work ?   > H > Would I stand better odds with a DHQ11, a slightly younger clone (only; > half the width of DHV11) ? Or will this likely fail too ?  > B > I was expecting incomatibility to result in the device not beingB > accepted at all. Didn't expect VMS to be able to performs *some*/ > operations on it but not basic data transfer.  >  > H > It is interesting that for the supported devices (CXY08 for instance),H > the boards are set to emulate a DHV11, but the real McCoy doesn't seem
 > to work. > I > Is there any way for me to debig what is going on to cause it to fail ?      --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  + Date: Sun, 18 Dec 2005 00:28:30 -0600 (CST) * From: sms@antinode.org (Steven M. Schweda)+ Subject: Re: QBUS DHV11 in VAX 4000-600/200 2 Message-ID: <05121800283035_2022C5B5@antinode.org>    From: John Santos <john@egh.com>  C > I forget if the DHV has hardware or software vector settings.  If D > hardware, this sounds like you've got the vector wrong.  It should? > probably be 300, depending on what other options are present.   G    It's been a while since I did this, and the problem I had was serial G ports going offline when I added a DU disk controller of some sort, but F my dim recollection is that if the vector is wrong, the devices appear offline.  F    It is critical, however, to have any cards with vector switches setH properly, and adding cards can easily change the floaters.  A reasonableE procedure is to do the CONFIGURE twice (before and after the change), H note all the CSR and vector data, see if anything changed for each card,D and for each card with a change, check to see if that change implies switch/jumper changes.  G    I don't do much with serial cards these days, and my supply of CXY08 E cards is adequate, so I can't say much about the specific behavior of  the older ones.   H ------------------------------------------------------------------------  4    Steven M. Schweda               (+1) 651-699-98183    382 South Warwick Street        sms@antinode-org     Saint Paul  MN  55105-2547    ------------------------------  % Date: Sat, 17 Dec 2005 21:30:18 +0100 & From: Paul Sture <paul.sture@decus.ch>! Subject: Re: Storageworks shelves , Message-ID: <40jaq3F1b10f8U1@individual.net>   Bill Gunshannon wrote:5 > In article <SBoziXkzvfIf@eisner.encompasserve.org>, 2 > 	Kilgallen@SpamCop.net (Larry Kilgallen) writes: >  >>In article <Bieof.21861$Y72.1770@bignews1.bellsouth.net>, "David Turner, Island Computers US Corp" <dbturner@icusc.com> writes:  >>3 >>>Perhaps someone can explain to me the following:  >>> F >>>Why, when SCSI was implemented, did it have the 7 drive limitation? >>>Why not 16 or 32? >>>Of course UW> is 14 but why?  >>> K >>>Did someone in the SCSI original design team think that noone would ever  >>>need more than 7 drives?  >>D >>No, they thought (correctly) that multiple SCSI busses were viable >>on a single system.  >  > L > But multiple SCSI busses doesn't have anything to do with the 7(15) deviceL > limit.   It has to do with the number of bits allocated for addressing andL > the real question is why did they only allow 3 originally and after seeingB > the way things were going, why only increase it by one more bit? >   D My guess is that SCSI stands for _Small_ Computer Systems Interface.   :-)    ------------------------------   End of INFO-VAX 2005.702 ************************