INFO-VAX Mon, 19 Feb 2007 Volume 2007 : Issue 99 Contents: Re: I lehrned it from a boook Re: Need a few cables hopefully cheap Re: Need a few cables hopefully cheap Re: Need a few cables hopefully cheap Re: Need a few cables hopefully cheap Re: Need a few cables hopefully cheap Re: Need a few cables hopefully cheap Re: TCPIP Performance Tuning on VMS ? Re: TCPIP Performance Tuning on VMS ? Re: TCPIP Performance Tuning on VMS ? Re: TCPIP Performance Tuning on VMS ? RE: TCPIP Performance Tuning on VMS ? Toliet Seat Secrets ---------------------------------------------------------------------- Date: Mon, 19 Feb 2007 07:13:09 +0800 From: "Richard Maher" Subject: Re: I lehrned it from a boook Message-ID: Hi Arne, Thanks for the reply. > > Q2) How can I make sure which JVM is running by default on my W2K box? > > http://www.vajhoej.dk/arne/eksperten/showversion/showversion.html Well, it says "Sun Microsystems Inc. Java HotSpot Client VM 1.6.0-b105" (It also says "Sun Microsystems Inc 1.6.0" No mention of Microsoft or MSJVM anywhere.) I'm guessing that means I'm running Sun's JVM. So, if it's not the browser (IE) that gets the archive file and then passes it on to the JVM, why would Sun's Appletviewer behave so differently (and much better) than it's own IE inspired JVM? (DLL,Plugin,. . .) Different code to do exactly the same thing in two sibling utilities? Cheers Richard Maher "Arne Vajhøj" wrote in message news:45d7a2b8$0$90267$14726298@news.sunsite.dk... > Richard Maher wrote: > > Q1) Who asks for the Applet archive file? Browser or JVM? > > I have never worked much with applets, but my understanding is that: > - the browser calls a Java plugin (DLL on Windows) that comes with Java > - the plugin creates a classloader based on info in the applet tag and > loads the applet class specified in the applet tag and calls > the init method etc. > > > Q2) How can I make sure which JVM is running by default on my W2K box? > > http://www.vajhoej.dk/arne/eksperten/showversion/showversion.html > > Arne ------------------------------ Date: Sun, 18 Feb 2007 13:52:54 -0500 From: Ben Myers Subject: Re: Need a few cables hopefully cheap Message-ID: Leave it to DEC to create a high-value proprietary solution, then wonder why the bottom dropped out with the personal computer revolution. It is true that proprietary SCSI hardware abounds in DEC, Sun, SGI, IBM and others who made lame attempts to protect their overpriced hardware... Ben Myers On Sun, 18 Feb 2007 11:37:16 -0500, JF Mezei wrote: >Ben Myers wrote: >> To paraphrase Gertrude Stein: "A SCSI is a SCSI is a SCSI." Even DEC SCSI. > >Not in a vaxstation 3100-30. > >The ribbon and disk connectors may have been standard, but both ends of the >ribbon came back to the motherboard and used a proprietary connector that >combined both ends (aka : more than 50 pins). ------------------------------ Date: Sun, 18 Feb 2007 22:11:24 GMT From: rdeininger@mindspringdot.com (Robert Deininger) Subject: Re: Need a few cables hopefully cheap Message-ID: In article , ben_myers_spam_me_not at charter.net wrote: >Leave it to DEC to create a high-value proprietary solution, then wonder why the >bottom dropped out with the personal computer revolution. The first VAXstation 3100 systems were designed before SCSI cables and connectors were particularly "standard". It's hardly surprising that the cabling was weird. IIRC, Later models in the VAXstation 3100 series used "normal" 50-pin cables and connectors, as did the VAXstation 4000 series. ... >On Sun, 18 Feb 2007 11:37:16 -0500, JF Mezei >wrote: > >>Ben Myers wrote: >>> To paraphrase Gertrude Stein: "A SCSI is a SCSI is a SCSI." Even DEC SCSI. >> >>Not in a vaxstation 3100-30. >> >>The ribbon and disk connectors may have been standard, but both ends of the >>ribbon came back to the motherboard and used a proprietary connector that >>combined both ends (aka : more than 50 pins). ------------------------------ Date: Sun, 18 Feb 2007 17:56:15 -0500 From: Ben Myers Subject: Re: Need a few cables hopefully cheap Message-ID: <9bmht2d2o5stkbpe2nipd02e40455iqqcr@4ax.com> IIRC, I found garden variety 50-pin cables in a Vaxstation 3100 I tore down some time ago... Ben Myers On Sun, 18 Feb 2007 22:11:24 GMT, rdeininger@mindspringdot.com (Robert Deininger) wrote: >In article , >ben_myers_spam_me_not at charter.net wrote: > >>Leave it to DEC to create a high-value proprietary solution, then wonder >why the >>bottom dropped out with the personal computer revolution. > >The first VAXstation 3100 systems were designed before SCSI cables and >connectors were particularly "standard". It's hardly surprising that the >cabling was weird. > >IIRC, Later models in the VAXstation 3100 series used "normal" 50-pin >cables and connectors, as did the VAXstation 4000 series. > > >... > >>On Sun, 18 Feb 2007 11:37:16 -0500, JF Mezei >>wrote: >> >>>Ben Myers wrote: >>>> To paraphrase Gertrude Stein: "A SCSI is a SCSI is a SCSI." Even DEC SCSI. >>> >>>Not in a vaxstation 3100-30. >>> >>>The ribbon and disk connectors may have been standard, but both ends of the >>>ribbon came back to the motherboard and used a proprietary connector that >>>combined both ends (aka : more than 50 pins). ------------------------------ Date: 18 Feb 2007 23:08:24 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Need a few cables hopefully cheap Message-ID: <53s4j8F1torvsU1@mid.individual.net> In article , rdeininger@mindspringdot.com (Robert Deininger) writes: > In article , > ben_myers_spam_me_not at charter.net wrote: > >>Leave it to DEC to create a high-value proprietary solution, then wonder > why the >>bottom dropped out with the personal computer revolution. > > The first VAXstation 3100 systems were designed before SCSI cables and > connectors were particularly "standard". It's hardly surprising that the > cabling was weird. > > IIRC, Later models in the VAXstation 3100 series used "normal" 50-pin > cables and connectors, as did the VAXstation 4000 series. None of my (many!) VAXStation 3100's have "standard" SCSI cables. All of them connect to the motherboard with a non-standard (read DEC specific) cable. As for others also using proprietary cables, I have also had HP boxes, Sun3's, Sun4's SGI's, Mac's, Sage's, and too many different PC's to even count. The only one that did not use standard 50 pin connectors was the external connector on the MAC which was a DB25. But even it used the same pinout as others that used DB25 for SCSI (like Parallel to SCSI adapters!). bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 18 Feb 2007 23:10:51 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Need a few cables hopefully cheap Message-ID: <53s4nrF1torvsU2@mid.individual.net> In article <9bmht2d2o5stkbpe2nipd02e40455iqqcr@4ax.com>, Ben Myers writes: > IIRC, I found garden variety 50-pin cables in a Vaxstation 3100 I tore down some > time ago... Ben Myers > Only on the disk end. I have never seen a 3100 motherboard with a standard 50 pin berg connector. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Sun, 18 Feb 2007 18:11:48 -0500 From: JF Mezei Subject: Re: Need a few cables hopefully cheap Message-ID: <4493c$45d8dd3b$cef8887a$15825@TEKSAVVY.COM> Ben Myers wrote: > IIRC, I found garden variety 50-pin cables in a Vaxstation 3100 I tore down some > time ago... Ben Myers The cable may be standard. The disk-side connectors may be standard. But check the connector that goes on the SCSI card/controller. It has 2 50 pin ribbons merging into a single connector. (the vaxstation has a loop that goes to drives and I assume handles all of the SCSI termination itself). ------------------------------ Date: Sun, 18 Feb 2007 11:24:54 -0800 From: "John Gemignani, Jr." Subject: Re: TCPIP Performance Tuning on VMS ? Message-ID: wrote in message news:1171821914.730766.83180@v33g2000cwv.googlegroups.com... > On Feb 18, 9:58 am, JF Mezei wrote: >> Does anyone know of any document which describes VMS' TCPIP Services >> performance tuning ? >> >> In particular, the send/receive windows, window scaling MTU discovery >> and >> all the other new bits that are supported in the rest of the world ? > > > Look at TCPIP HELP SYSCONFIG > > sysconfig is the facility used to tune all the little parameters > within the TCP/IP stack, amazingly enough in a similar way as you > might in Tru64. > Amazingly? I put a lot of effort into making all of those pieces work the same. The load and unload of subsystems actually works for those that support it (for example, net, inet, socket, iptunnel, ipv6 and snmpinfo are built into the monolithic TCPIP$SERVICES image and can't be loaded and unloaded separately). When you specify the subsystem, the name is edited into a TCPIP$%s_SERVICES string to form the image name. If you specify the name with a leading "*", then the edit isn't performed. This means that you can do things like load DEBUG.EXE to make your OS debuggable after reboot. I believe that the images always come from SYS$LOADABLE_IMAGES:. Unfortunately, I haven't used VMS in more than a year and a lot of the details are blurry. I know that there are a lot of parameters that are meaningless for the VMS stack and I don't know if anyone actually weeded these all out. I recall that we were talking about it about the time that I "left". There were new parameters that were added and they have the vms name in them (I think that it covers all of them). John ------------------------------ Date: 18 Feb 2007 13:12:33 -0800 From: davidc@montagar.com Subject: Re: TCPIP Performance Tuning on VMS ? Message-ID: <1171833153.366621.121100@h3g2000cwc.googlegroups.com> On Feb 18, 1:24 pm, "John Gemignani, Jr." wrote: > wrote in message > > Look at TCPIP HELP SYSCONFIG > > > sysconfig is the facility used to tune all the little parameters > > within the TCP/IP stack, amazingly enough in a similar way as you > > might in Tru64. > > Amazingly? I put a lot of effort into making all of those pieces work the > same. I should have put in a smiley. I know that when TCPIP migrated from V4 to V5 there was a lot of merging with Tru64, so the "amazingly" was sarcastic. Although, except for the shortening the timers to SO_KEEPALIVE causes faster timeouts (mainly to keep some firewalls from breaking an connection that's idle too long), I'm good with the defaults. ------------------------------ Date: 18 Feb 2007 13:39:08 -0800 From: davidc@montagar.com Subject: Re: TCPIP Performance Tuning on VMS ? Message-ID: <1171834748.444744.29620@p10g2000cwp.googlegroups.com> On Feb 18, 12:21 pm, JF Mezei wrote: > dav...@montagar.com wrote: > > Look at TCPIP HELP SYSCONFIG > > This tells me how to use SYSCONFIG. But it doesn't describe each possible > parameter, relationship between parameters, and various TCPIP bits such as > window scaling, MTU discovery etc. Nor does it explain how to maximise > performance between machines of a certain distance (eg: across continent), > and what impact on various SYSGEN parameters config changes might have (for > instance, increasing the send/recv windows takes memory from where , and > how much should be added ?) Many of these are documented in a variety of information about TCP/IP stacks (i.e. they are standard parameters shared by all reasonable stack implmentations, which probably negates MS's), so a good search on google for the parameter name will get you information. Which located me this technical journal item that describes how some of the parameters work: http://h71000.www7.hp.com/openvms/journal/v3/tcpip.html There are probably others available, as well. As for performance tuning, it's going to depend on a lot of factors (that really have nothing to do with OpenVMS specifically). You may need a good tutorial on TCP/IP stack implementations and general performance tuning suggestions. Everything will apply to OpenVMS (and Tru64 for that matter). An obvious document that will discuss all these parameters are the IETF RFC's which define the TCP/IP protocol, but may not approach the issue in a way that is helpful to you. Since you are dealing with a device driver, all memory is going to come from non-paged pool, so increasing buffers for instance is going to require more non-paged pool. ------------------------------ Date: Sun, 18 Feb 2007 16:17:05 -0800 From: "John Gemignani, Jr." Subject: Re: TCPIP Performance Tuning on VMS ? Message-ID: "Richard B. gilbert" wrote in message news:45D8CBE0.60407@comcast.net... > davidc@montagar.com wrote: >> On Feb 18, 9:58 am, JF Mezei wrote: >> >>>Does anyone know of any document which describes VMS' TCPIP Services >>>performance tuning ? >>> >>>In particular, the send/receive windows, window scaling MTU discovery >>>and >>>all the other new bits that are supported in the rest of the world ? >> >> >> >> Look at TCPIP HELP SYSCONFIG >> >> sysconfig is the facility used to tune all the little parameters >> within the TCP/IP stack, amazingly enough in a similar way as you >> might in Tru64. >> > > What's amazing? ISTR that TCP/IP Services and the Tru64 stack have a > common code base. IRRC it has been so for many years now; like since > v5.0 was released. > Having the common code base for the IP stack is one thing, but sysconfig is not part of that. It's an interface in the Tru64 kernel to control subsystems (akin to separately configurable VMS execlets). All of the necessary support was implemented as part of the BG QIO interface. A function modifier was used to change the meaning of all other functions, modifiers and parameters. They are part of an expanded management interface that goes beyond sysconfig and includes things like the ability to configure kernel mode (process-less) services (NFS, Telnet, Rlogin, proxy and so on). I added some things when we moved to using the Tru64 networking stack and others as requirements evolved (when I rewrote telnet/login, when I rewrote NFS, when we needed kernel proxy data, for performance tests and when I was experimenting with iSCSI). And yes, I believe that V5.0 was the first Tru64 common code base release. John ------------------------------ Date: Sun, 18 Feb 2007 20:01:25 -0500 From: "Main, Kerry" Subject: RE: TCPIP Performance Tuning on VMS ? Message-ID: > -----Original Message----- > From: JF Mezei [mailto:jfmezei.spamnot@vaxination.ca]=20 > Sent: February 18, 2007 10:58 AM > To: Info-VAX@Mvb.Saic.Com > Subject: TCPIP Performance Tuning on VMS ? >=20 > Does anyone know of any document which describes VMS' TCPIP Services=20 > performance tuning ? >=20 > In particular, the send/receive windows, window scaling MTU=20 > discovery and=20 > all the other new bits that are supported in the rest of the world ? >=20 TCPIP Tuning and Troubleshooting manual: http://h71000.www7.hp.com/doc/732final/6631/6631pro.html http://h71000.www7.hp.com/doc/732final/documentation/pdf/aa-rn1vb-te.pdf Other TCPIP doc`s: http://h71000.www7.hp.com/doc/tcpip56.html Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Sun, 18 Feb 2007 22:57:48 GMT From: Agent Orange Subject: Toliet Seat Secrets Message-ID: Toliet Seat - http://projectwiretap.blogspot.com/2007/02/toliet-seat-theater-presents.html Was Down apparently after Operations Hanger 36 unveiled its secret harrier stealth technology Feb, 18. approx 12:00 Thank you for another succesfull airshow says Kernel Clink. A 6 million dollar project amortization over 3 years. . ------------------------------ End of INFO-VAX 2007.099 ************************