1 INFO-VAX	Sun, 19 Sep 2004	Volume 2004 : Issue 520       Contents:, Re: a simple question: what the h*ll is MCR? Re: insufficient virtual memory  Re: insufficient virtual memory   Re: TCP/IP cluster interconnect?  Re: TCP/IP cluster interconnect?  Re: TCP/IP cluster interconnect?( Re: VAX 6000 replacement with CHARON-VAX( Re: VAX 6000 replacement with CHARON-VAX( Re: VAX 6000 replacement with CHARON-VAX( Re: VAX 6000 replacement with CHARON-VAX( Re: VAX 6000 replacement with CHARON-VAX( Re: VAX 6000 replacement with CHARON-VAX( Re: VAX 6000 replacement with CHARON-VAX1 Re: Where is the Process/Image dump information ?   F ----------------------------------------------------------------------  % Date: Sat, 18 Sep 2004 19:14:00 -0400 " From: Glenn Everhart <gce@gce.com>5 Subject: Re: a simple question: what the h*ll is MCR? 3 Message-ID: <414cc1d7$0$2672$61fed72c@news.rcn.com>   J The Monitor Console Routine concept was devised for RSX11D at least as far$ back as RSX11D V4, possibly earlier.  J In RSX, there is no notion of "process" as VMS folks are used to. What areN run are installed tasks; installing them puts a pointer to disk block and sizeK of the area to load into a system structure so that the task can be invoked D by doing a single I/O and starting the routine at its start address.  I Given this, there needed to be some entity which would dispatch commands, L a "shell" if you like, and MCR was it. It would among other things translateH 3 letter commands like "foo" to instructions to run task ...foo and passN it whatever command arguments had been typed. This was a very simple and quickK command dispatch system, though of limited flexibility. Even after multiple M layers of parsing were added and more elaborate script oriented commands were O also added, the MCR name was kept for RSX11M and M+ (it got superseded for IAS) L and was inherited by VMS, many of whose commands in V1 and V2 were in compatO mode, i.e., slightly warmed over RSX commands with the ELP$ directive replacing # some of the old RSX kernel munging.   L When in V3 it was decided that most all of the commands that had been uniqueH to compat mode code now had native mode VAX equivalents, compat mode wasK dropped and moved to the VAX/RSX product. By that time people realized that K "compatibility mode" was better named "rough similarity mode" in many cases M but the system still works and if you have VAX/RSX installed, the MCR command I brings up its variant of good old RSX11M MCR. It turned out that MCR mode L happens to fire up programs in sys$system if there is no compat mode programH to be run, as a last resort (which is along the RSX philosophy of tryingE various general ways to parse a command before giving up on it). That S behavior got kept so that even if no MCR was present, "MC command" or "MCR command" K is equivalent to run sys$system:command, but it also allows arguments to be L passed to the command given, so it's simpler than defining a foreign command and running it in many cases.    So that's what the heck MCR is.    Glenn Everhart   Paul Sture wrote:  > Marty O'Connor wrote:  > 5 >> "Dan O'Reilly" <dano@process.com> wrote in message > >> news:6.1.2.0.2.20040914090800.028a8560@raptor.psccos.com...E >> : Now on VMS, "MCR" is the same thing as saying "RUN SYS$SYSTEM:".  >> : >>C >> Not exactly. MCR runs an image found in SYS$SYSTEM as a foreign  # >> command (xx = $sys$system:image) C >> which will pass the remainder of the line to the image. The RUN  % >> command will not do that. MCR is a D >> quick way to run a program that takes command line input without  >> creating a DCL symbol.  >> > H > MCR uses SYS$SYSTEM as the default location. It is also possible to do > 4 > $ MCR my_dev:[my_dir]my_prog] parameter /qualifier   ------------------------------    Date: 18 Sep 2004 17:35:16 -07000 From: chris_doran@postmaster.co.uk (Chris Doran)( Subject: Re: insufficient virtual memory= Message-ID: <948f0720.0409181635.65ab8e4a@posting.google.com>   j John Forkosh <john@SeeSigForAddress.invalid.com> wrote in message news:<cihtfn$qbq$1@reader1.panix.com>... >... I've reproduced8 > the code along with a test driver below, and I've also) > left a copy at www.forkosh.com/md5str.c  >   > I originally got the code from/ >      http://www.cr0.net:8040/code/crypto/md5/ 6 > and I'd guess it's all the #undef's and re-#define's; > of F that's somehow causing decc grief.  Try it yourself.  > It should _easily_ compile as  >      cc/define=TEST md5str.c( > But that sends my VS4K/90 into a loop.  C Hmmm, no problem here, but I have an earlier VMS (6.2) and probably A DECC (5.2-003). I tried it on VAX-3100/40 and Alpha-3000/600 with ' PGFLQUOTA 100,000 (Alpha); 60,000 (VAX) , VIRTUALPAGECNT 800,000 (Alpha); 73,536 (VAX)  E Starting from the file at forkosh.com which I httped to W2K and FTPed B to VMS, I had to SET FILE/ATT=RFM:STMLF otherwise I got an EXQUOTAE when I tried to TYPE or EDT the file. C didn't EXQUOTA, but generated < a rubbish object file which turned out to be due to two junkA characters at the very start of the file. After removing these it A compiled in seconds and ran OK, though I got different numbers to - yours, probably due to messing with the file.   E The only case I can remember C running out of quota and/or hanging is A when you do something silly like a recursive #define, though it's D obviously not that simple here. CC/PREPROCESS_ONLY, ctrl/C, and look9 at the .i file might help you if it's got hung like that.   E The brute force method on problems like this is to keep removing bits D of code until the problem goes away, then stare at the line(s) which make it come back.   I hope this helps a bit.   Chris    ------------------------------  # Date: Sun, 19 Sep 2004 00:39:56 GMT 5 From: "Ed Vogel" <edward.vogel_stop_the_spam.@hp.com> ( Subject: Re: insufficient virtual memory1 Message-ID: <wz43d.11130$aB.443@news.cpqcorp.net>   C "John Forkosh" <john@SeeSigForAddress.invalid.com> wrote in message & news:cihtfn$qbq$1@reader1.panix.com...9 > However, it turns out that none of that is the problem. 7 > Instead, it's a new piece of code that calculates md5 0 > hashes which causes the decc compiler to hang./ > That same code compiles and runs fine on Unix 0 > (SunOS and NetBSD), Linux, and even on Windows: > (using both MinGW and djgpp compilers).  I've reproduced8 > the code along with a test driver below, and I've also) > left a copy at www.forkosh.com/md5str.c   6     This is a known problem with the Compaq C compiler6     on VAX.   It gets reported every few years.   This?     is a documented restriction in the latest release notes for      the VAX product.  8     The problem is in the code generator for the VAX.  A7     number of engineers have looked at the problem over :     the years, but the code generator code is very old and8     hard to understand and maintain.  We have never been=     able to develop a fix that did not contain too much risk.   1     Sorry that you have encountered this problem.        Ed Vogel     Hp/Compaq C Engineering.  7     Note that that Alpha version of the C compiler does      not have this problem.   ------------------------------  % Date: Sat, 18 Sep 2004 16:59:42 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>) Subject: Re: TCP/IP cluster interconnect? + Message-ID: <414CAFCD.BBB84058@comcast.net>    Jim Brankin wrote: > F > Is it not about time VMS could use TCP/IP as a cluster interconnect?C > Everything seems to be moving that way, for instance voice, SCSI.  > I > With the advent of TCP offload engines the communications stack will be M > available early in the boot sequence because it is on the card, so it ought  > to be doable.  >  > What do you think?  F Since an OpenVMS cluster can survive quite happily without ANY networkC stack loaded (not even DECnet or LAT), I'd have to say the issue is E irrelevant, and attempting to push cluster communications that far up D into network stack would only degrade the situation, not improve it.   So, no - I can't agree.    D.J.D.   ------------------------------  % Date: Sat, 18 Sep 2004 19:26:10 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ) Subject: Re: TCP/IP cluster interconnect? , Message-ID: <414CC40C.67589AF1@teksavvy.com>   David J Dachtera wrote: H > Since an OpenVMS cluster can survive quite happily without ANY networkE > stack loaded (not even DECnet or LAT), I'd have to say the issue is G > irrelevant, and attempting to push cluster communications that far up F > into network stack would only degrade the situation, not improve it.  K The original poster mentioned a hardware based IP stack. Think of a network I card that looks like an ethernet card to the host system, but which talks  TCPIP to the outside world.   N Consider modern DSL modems that have they own built-in IP stacks complete withI web server for configuration, telnet/snmp agents etc. So it isn't hard to N think of a much simpler network card that just does TCPIP and has a very basic0 configuration setup to define its IP parameters.   ------------------------------  % Date: Sat, 18 Sep 2004 19:02:11 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>) Subject: Re: TCP/IP cluster interconnect? + Message-ID: <414CCC82.689089A5@comcast.net>    JF Mezei wrote:  >  > David J Dachtera wrote: J > > Since an OpenVMS cluster can survive quite happily without ANY networkG > > stack loaded (not even DECnet or LAT), I'd have to say the issue is I > > irrelevant, and attempting to push cluster communications that far up H > > into network stack would only degrade the situation, not improve it. > M > The original poster mentioned a hardware based IP stack. Think of a network K > card that looks like an ethernet card to the host system, but which talks  > TCPIP to the outside world.  > P > Consider modern DSL modems that have they own built-in IP stacks complete withK > web server for configuration, telnet/snmp agents etc. So it isn't hard to P > think of a much simpler network card that just does TCPIP and has a very basic2 > configuration setup to define its IP parameters.  F Nonetheless, the issue remains transferring control from Layer 2 up toB layer 3 or higher. More chances for latency, dropped packets, etc.   The song remains the same...   D.J.D.   ------------------------------  % Date: Sat, 18 Sep 2004 15:03:07 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 1 Subject: Re: VAX 6000 replacement with CHARON-VAX , Message-ID: <414C8669.DC539BFF@teksavvy.com>   Antonio Carlini wrote:; > and a MicroVAX II differ considerably. VMS knows this and 9 > goes hunting for different devices in different places.   J Which is why I could take my all mighty microvax II's system disk, plug itN into a 6000 and boot. Sire, some device names would change (ethernet, serial),F but wouldn't the rest work fine ? (assuming proper licences of course)  = > But all you have done here is said that it is a MicroVAX II  > but with limited peripherals.   H But since wintel or alpha do not have q-bus, then it is a given that theL emulator can only "fake" a limited number of q-bus devices because each must be coded into the emulator.   ? > I expect the main difference with a VAX 6000 emulator will be ( > that fact that SMP support is present.  B Which brings up the interesting question: does the charon emulatorM specifically make use of multiple CPUs in the host machine to simulate SMP in L the emulated 6000 ? Or does it just have multiple threads which simulate theO various CPUs ? (allowing the host OS to decide on which CPU each thread runs) ?    F > The difference between a real VAX 6000-600 and a real MicroVAX II isB > that the 6600 will be considerably faster, can reasonably handle= > more disks (uVII has a qbus between it and any disks and no F > DEC CI interface) and has a much faster ethernet interface (in fact,* > IIRC the DEMNA has a uVII CPU on board).  J However, in an emulated environment, a Microvax II emulated on a 3ghz 8086M will be considerably faster than a 6000 emulated on a 500mhz 8086.  And since N the actual operations (such as addition) are performed by the underlying host,N then the specific features of the emulated CPU (pipelining, how many cycles itK takes to perform an addition etc) are probably totally irrelevant, right ?    F > Unless you are one of those customers that produced your own driversE > or OS, you may not care very much which variant you are running on.   L Question: for the charon vax emulator, is there some sort of "driver" pluginM that would allow a customer to take specific PCI hardware on the host 8086 or L alpha and make it appear as some Q-bus board in the emulated machine so that@ the VAX software would still see the devices it expects to see ?  G (for instance, some custom process control hardware that was iriginally / designed on Q-bus but is now available on PCI).     A > If you want to run older OS variants or run your own custom OS, ; > then the emulated hardware probably matters a great deal.   J But I still don't see why having a 16 meg limit on an emulated microvax II would make a difference.   ------------------------------  % Date: Sat, 18 Sep 2004 22:58:53 +0200 + From: Wilm Boerhout <w3.boerhout@planet.nl> 1 Subject: Re: VAX 6000 replacement with CHARON-VAX 5 Message-ID: <414ca190$0$8283$ba620dc5@nova.planet.nl>    JF Mezei wrote:   N > Question: for the charon vax emulator, is there some sort of "driver" pluginO > that would allow a customer to take specific PCI hardware on the host 8086 or N > alpha and make it appear as some Q-bus board in the emulated machine so thatB > the VAX software would still see the devices it expects to see ? > I > (for instance, some custom process control hardware that was iriginally 1 > designed on Q-bus but is now available on PCI).   F Few QBUS boards have their functionality transferred to PCI versions. E Serial lines are available, as are some process control devices. For  < other cases, a sort of "reverse" solution may be configured:  B You can take a real MicroVAX II, take out the processor board and H replace that by a board that connects to a PCI board in your Charon-VAX = host. The emulated VAX will then drive the real QBUS and its  G peripherals. This is useful when you have enough reasons in general to  I go with Charon-VAX, but the PCI version of your favorite QBUS peripheral  I is not available. Call it a hybrid... It can also be used as a quick way  G to transfer real QBUS disk contents to Charon-VAX disk containers. See  + your local Charon-VAX reseller for details.      --  
 Wilm Boerhout  Zwolle, The Netherlands    wilmOLD@PAINTboerhout.nl2    (remove OLD PAINT from this address before use)   ------------------------------  % Date: Sat, 18 Sep 2004 16:53:34 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>1 Subject: Re: VAX 6000 replacement with CHARON-VAX * Message-ID: <414CAE5E.2AA116A@comcast.net>   Wilm Boerhout wrote: > G > Few QBUS boards have their functionality transferred to PCI versions. F > Serial lines are available, as are some process control devices. For> > other cases, a sort of "reverse" solution may be configured: > C > You can take a real MicroVAX II, take out the processor board and I > replace that by a board that connects to a PCI board in your Charon-VAX > > host. The emulated VAX will then drive the real QBUS and itsH > peripherals. This is useful when you have enough reasons in general toJ > go with Charon-VAX, but the PCI version of your favorite QBUS peripheralJ > is not available. Call it a hybrid... It can also be used as a quick wayH > to transfer real QBUS disk contents to Charon-VAX disk containers. See- > your local Charon-VAX reseller for details.    Stan? Any comments?   F Also, is there a similar adapter for any bus that supports CI or DSSI?A (Acknowledged: CIPCA, but probably not supported by any PC BIOS).    D.J.D.   ------------------------------    Date: 18 Sep 2004 17:43:46 -0700) From: baby_p_nut2@yahoo.com (Baby Peanut) 1 Subject: Re: VAX 6000 replacement with CHARON-VAX = Message-ID: <96d83290.0409181643.39c71025@posting.google.com>   h "Stanley F. Quayle" <squayle@insight.rr.com> wrote in message news:<4149544F.28535.26DD78F@localhost>...C > I told you to stay tuned -- SRI announces today that you can now  D > replace your VAX 6610, 6620, and 6630's with CHARON-VAX.  Details: > 8 >     http://www.softresint.com/charon-vax/CHVX_66xx.htm > * > My web page is being updated, and is at: > * >     http://www.stanq.com/charon-vax.html > D > The 6630 product on a quad AMD Opteron will yield about ~230 VUPs. >  > @ > [This is a Shameless Plug (tm) from your CHARON-VAX reseller.] > --Stan Quayle  > Quayle Consulting Inc. >  > ----------/ > Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363 5 > 8572 North Spring Ct., Pickerington, OH  43147  USA 2 > stan-at-stanq-dot-com       http://www.stanq.com  > I just wanted to thank everyone involved with CHARON-VAX.  OldD minicomputers are the SUVs of electricity and we can't afford to not& attempt to conserve our way out of the   http://peakoil.net/  http://peakoil.org/  http://peakoil.com/  http://dieoff.org/   crisis.   D Ever VAX that gets disconnected is one less kick in the teeth to the worlds energy economy.   ------------------------------  % Date: Sat, 18 Sep 2004 21:44:03 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 1 Subject: Re: VAX 6000 replacement with CHARON-VAX , Message-ID: <414CE455.37E3DDCD@teksavvy.com>   Baby Peanut wrote:F > Ever VAX that gets disconnected is one less kick in the teeth to the > worlds energy economy.  M And every IA64 that gets plugged in will be one more kick in the teeth to the  world's energy problem.    ------------------------------  % Date: Sat, 18 Sep 2004 20:48:52 -0600 " From: GreyCloud <mist@cumulus.com>1 Subject: Re: VAX 6000 replacement with CHARON-VAX 0 Message-ID: <Q6WdnXnNRZ6RbtHcRVn-sw@bresnan.com>   JF Mezei wrote:    > Baby Peanut wrote: > F >>Ever VAX that gets disconnected is one less kick in the teeth to the >>worlds energy economy. >  > O > And every IA64 that gets plugged in will be one more kick in the teeth to the  > world's energy problem.   I I know that the P4 dumps about 54 watts, but what does the Itanium2 dump  	 in watts?    --  ! ---------------------------------  The Golden Years Sux.    ------------------------------  % Date: Sat, 18 Sep 2004 23:09:23 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 1 Subject: Re: VAX 6000 replacement with CHARON-VAX , Message-ID: <414CF84F.1E66A818@teksavvy.com>   GreyCloud wrote:J > I know that the P4 dumps about 54 watts, but what does the Itanium2 dump > in watts?   D 300 watts is the last figure I heard. Intel has plans to lower power consumption.   ------------------------------    Date: 18 Sep 2004 16:05:14 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) : Subject: Re: Where is the Process/Image dump information ?3 Message-ID: <MK30fuxgFtd4@eisner.encompasserve.org>   X In article <2r2u5rF14cgrlU1@uni-berlin.de>, Paul Sture <nospam@sture.homeip.net> writes: > Larry Kilgallen wrote:E >> Can someone tell me where in the documentation to find information L >> about the use of SS$_IMGDMP.  I am particularly interested on the logicalI >> names for controlling where the dumps go, whether privileged data gets  >> dumped, etc.  > > > http://h71000.www7.hp.com/doc/731FINAL/6017/6017pro_076.html  C Ah,  System Management.  To me it seems more related to programming  (like the debugger).   Thanks.    ------------------------------   End of INFO-VAX 2004.520 ************************