1 INFO-VAX	Tue, 18 Apr 2006	Volume 2006 : Issue 215       Contents:P AlphaStation XP1000 and Optical Bootstraps (was: Re: DSPP and OpenVMS media) med Re: DSPP and OpenVMS media Re: DSPP and OpenVMS media DSPP EMEA contact numbers  Re: DSPP EMEA contact numbers  Free rz26s and rz28s' IMCB$V_PARENT_PROT What is it good for? + Re: IMCB$V_PARENT_PROT What is it good for? + Re: IMCB$V_PARENT_PROT What is it good for? / Re: Is VMS Security being dumbed-down for Java? / Re: Is VMS Security being dumbed-down for Java?  Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet$ Re: SoyMail & insufficient privilege$ Re: SoyMail & insufficient privilege. Re: Strange behavior of DEFINE with equal-sign. Re: Strange behavior of DEFINE with equal-sign. Re: Strange behavior of DEFINE with equal-sign( TCPIP MTU settings on VAX/TCPIP Services, Re: TCPIP MTU settings on VAX/TCPIP Services, Re: TCPIP MTU settings on VAX/TCPIP Services" Re: What is wrong with my network?" Re: What is wrong with my network?" Re: What is wrong with my network?" Re: What is wrong with my network?" Re: What is wrong with my network?  F ----------------------------------------------------------------------  # Date: Tue, 18 Apr 2006 13:46:29 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>Y Subject: AlphaStation XP1000 and Optical Bootstraps (was: Re: DSPP and OpenVMS media) med 2 Message-ID: <V461g.6465$Og2.4756@news.cpqcorp.net>   Tom Linden wrote:   M > We upgaded a 7.3-1 to 8.2 off that drive, but haven't tried booting.  Would ) > you like me to try when I get a moment/   G    The AlphaStation XP1000 series boxes do not necessarily boot off of  G newer (and unsupported) ATAPI devices; I've seen problems with several  F recent DVD+R/RW drives within that particular configuration.  I don't I know that this has been officially reported, but (AFAIK) this limitation  = also does not affect any of the officially-supported storage  ! configurations for this platform.   I    Given various considerations involved with this specific box, I'm not  I expecting to see an SRM update for this particular Alpha system and thus  ; this limitation is comparatively likely to remain in place.   G    Older (and supported) ATAPI devices can and do bootstrap, of course.   E    If you should upgrade to a newer ATAPI drive, do first try a test  H bootstrap.  If it fails, then keep another bootable root around on some E local disk, or provide a path to removable storage to allow a system  C disk to be loaded (via the assistance of a disk transfered in from  H another OpenVMS system), configure a local cluster boot/disk server for G a satellite MOP bootstrap, or use a SCSI CD-ROM or CD-R/RW drive.  The   usual sequences.  I    No, I haven't localized this to the failing SCSI command sequence(s).  =   (ATAPI devices use what is basically the SCSI command set.)    ------------------------------  # Date: Tue, 18 Apr 2006 17:19:16 GMT  From: dittman@dittman.net # Subject: Re: DSPP and OpenVMS media % Message-ID: <oc91g.28$sh.13@trnddc07>    VAXman- wrote:c > In article <nsS0g.6441$gU1.6437@news.cpqcorp.net>, Hoff Hoffman <hoff-remove-this@hp.com> writes:  > >  > > # > >VAXman- @SendSpamHere.ORG wrote:  > > O > >> My only issue with this would be for the IA64 OpenVMS distro.  Presently,  N > >> this comes on a DVD.  What if one does not have a DVD burner to create an > >> OpenVMS IA64 DVD? > > K > >   If you're on the SDK for F8.3 and are willing to spend about US$100,  : > >you can cure that for a number of recent Alpha systems. > > L > >   I'm probably a little jaded, as I believe that every system should be C > >sold with or purchased with (depending on how you look at it) a   > >multi-format DVD burner.   G > Didn't have that luxury with the $2K Italium Developer Forum systems. H The current Itanium Developer Workshop systems have a DL DVD burner that does +/- R and RW.   --   Eric Dittman dittman@dittman.net    ------------------------------  + Date: Tue, 18 Apr 2006 17:38:58 +0000 (UTC) . From: klewis@LUMINA.MITRE.ORG (Keith A. Lewis)# Subject: Re: DSPP and OpenVMS media . Message-ID: <e2387i$4kl$1@newslocal.mitre.org>  t "Tom Linden" <tom@kednos.com> writes in article <op.s76gfgdrzgicya@hyrrokkin> dated Mon, 17 Apr 2006 17:17:30 -0700:5 >On Mon, 17 Apr 2006 14:13:31 -0700, Keith A. Lewis   ! ><klewis@LUMINA.MITRE.ORG> wrote:  > 4 >> "Tom Linden" <tom@kednos.com> writes in article  G >> <op.s74i4xqrzgicya@hyrrokkin> dated Sun, 16 Apr 2006 16:20:47 -0700: L >>> I bought a Plextor 716A off ebay for $42 and it works fine in an XP1000,	 >>> burns  >>> both CDs and DVDs. >>H >> Have you tried to boot an OpenVMS (or any bootable) CD on that drive?L >We upgaded a 7.3-1 to 8.2 off that drive, but haven't tried booting.  Would( >you like me to try when I get a moment/  K That's what I meant, booting a VMS install CD in order to upgrade VMS or do L other maintenance tasks such as standalone backup.  Since it worked for both7 you and Alan Frisbie, my question is answered.  Thanks.   0 --Keith Lewis              klewis {at} mitre.org> The above may not (yet) represent the opinions of my employer.   ------------------------------  % Date: Tue, 18 Apr 2006 21:20:09 +0800 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> " Subject: DSPP EMEA contact numbers1 Message-ID: <e22p0o$89s$1@news-02.connect.com.au>    Hi,   L I've tried +49 7031 468 3982 (from web) and +49 7031 269 4505 (redirect) and am having no joy :-(  @ Any other numbers? And why has it moved from Ireland to Germany?   Regards Richard Maher    ------------------------------  % Date: Tue, 18 Apr 2006 21:54:03 +0800 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> & Subject: Re: DSPP EMEA contact numbers1 Message-ID: <e22r0a$ash$1@news-02.connect.com.au>    Hi Ian,    Thanks for the reply.   ? It sounds like a fax to me or is it still too early over there?   J I also tried an old number for Jaclyn (don't think she does DSPP anymore?) but no answer either.    Cheers Richard Maher  A PS. Just remembered - big celebrations over there on the weekend.   + "Ian Miller" <ijm@uk2.net> wrote in message < news:1145366849.046793.80980@v46g2000cwv.googlegroups.com... > >From the UK I have  >  > Phone: + 800 100 92970 > Fax: + 353 91 75 4445  > Email: dspp.emea@hp.com  >    ------------------------------    Date: 18 Apr 2006 10:37:02 -0700' From: "syslost" <wm.reynolds@gmail.com>  Subject: Free rz26s and rz28s C Message-ID: <1145381822.272240.205390@v46g2000cwv.googlegroups.com>   E I have 20 rz26s and 130 rz28s, that for only the cost of shipping can ? be yours.  These are for Hobbyist use only.  eMail me if you're  interested.    ------------------------------  % Date: Tue, 18 Apr 2006 20:30:27 +0800 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> 0 Subject: IMCB$V_PARENT_PROT What is it good for?1 Message-ID: <e22m3g$4ev$1@news-02.connect.com.au>    Hi  L If someone out there has a copy of the Internals and Data Structures Manual,K could they please check to see if there is any info in there about the IMCB & and in particular the PARENT_PROT bit?  ? Any and all documentation would be useful. What's it all about?    Regards Richard Maher   = PS. This from lines 3334 to 3338 in SYSIMGACT.LIS 19-Nov-2004   H "Also set the PARENT_PROT bit to ensure subsequent activations of images$ references by this one are checked."  F PPS. Does anyone know if S. Davidson gets upset at unsolicited emails?   ------------------------------  % Date: Tue, 18 Apr 2006 22:51:42 +0800 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> 4 Subject: Re: IMCB$V_PARENT_PROT What is it good for?1 Message-ID: <e22ucc$fb2$1@news-02.connect.com.au>   	 Hi Steve,   L Ok! I don't like to send unsolicited e-mail to folks directly. But seeing as, how I've been asked :-) I take this offline.   Cheers Richard Maher.   9 "Hoff Hoffman" <hoff-remove-this@hp.com> wrote in message , news:ax61g.6469$dk2.5420@news.cpqcorp.net... > Richard Maher wrote: > I >    I think I know where you are heading with this discussion, and would 3 > prefer to see this discussion continued off-line.  > I >    With the source listings, the IDSM seems slightly unnecessary to the B > quest -- yes, it's certainly a nice introduction, but the sourceF > listings are the penultimate source of information on OpenVMS.  (The@ > full source code pool being the ultimate resource, obviously.) > H > > If someone out there has a copy of the Internals and Data Structures Manual, J > > could they please check to see if there is any info in there about the IMCB* > > and in particular the PARENT_PROT bit? > > C > > Any and all documentation would be useful. What's it all about?  >  > .... > J > > PPS. Does anyone know if S. Davidson gets upset at unsolicited emails? > B >    Stu is not an HP employee, and no longer works for nor at HP.H > Whether or not he's interested in receiving email on HP products or onH > the image activator itself, I don't know.  But I'd tend to assume thatA > he's not overly interested, at least until he states otherwise.  > H >    Unlike Stu, I do work for HP and I do work with OpenVMS itself, andG > am willing to discuss where I think this topic is headed.  Preferably I > off-line.  And I've just finished up some initial research on this bit, G > and will check further with a couple of other appropriate engineering  > folks Real Soon Now. >  >  >  >    ------------------------------  % Date: Tue, 18 Apr 2006 22:56:34 +0800 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> 4 Subject: Re: IMCB$V_PARENT_PROT What is it good for?1 Message-ID: <e22ulj$fp7$1@news-02.connect.com.au>    Hi Ian,    (But before I go :-)  3 > which is propagated to shareable images activated  > subsequently  G That simply cannot be! Wash your mouth out. What you are alluding to is ( clearly a pointless piece of redundancy.   Cheers Richard Maher  + "Ian Miller" <ijm@uk2.net> wrote in message = news:1145368839.130610.223730@i40g2000cwc.googlegroups.com... 	 > It says C > "If either IAC$V_PARANOID or IAC$V_PROTECTED was specified in the I > FLAGS argument, the image activator checks that the image was installed I > and, if not, returns the error status SS$_PRIVINSTALL to its requestor.  > IfH > IAC$V_PROTECTED was specified, the image must also have been installedH > /PROTECTED. If the image passes these checks, the image activator setsG > IMCB$V_PARENT_PROT, which is propagated to shareable images activated @ > subsequently to ensure that similar checks are made for them." >    ------------------------------  % Date: Tue, 18 Apr 2006 21:44:54 +0800 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> 8 Subject: Re: Is VMS Security being dumbed-down for Java?1 Message-ID: <e22qf4$a9m$1@news-02.connect.com.au>   	 Hi Steve,   
 Hoff wrote: -   ? > If it's loaded and activated separately or otherwise not part E > of the kernel, it's not necessarily safe to call it from inner-mode  : ;  > And in any event, inner-mode code cannot call RTL calls.  : - >   You can't call RTLs from inner-mode code.  : J >   You can't call user-mode code and user-mode RTLs from inner-mode code. : 6 >  You can't call user-mode code from inner-mode code.  I OK you couldn't have made it any clearer and I'm not trying to antagonize L you further by asking yet again. But I'd like to throw another question open to the floor if I may: -  F In the the $persona_create service, what are the "usrpro" argument and iss$v_noaccess flag for?  K The documentation I have says that iss$v_noaccess is "Only valid in exec or J kernel mode.". Doesn't $persona_create live in secureshr.exe? A run o' theD mill shareable image? Doesn't this very same routine facilitate (nayH encourage) the calling of  lib$get_vm and lib$free_vm at EXEC and KERNEL modes?  K I can't access EXEC mode-based RMS for the UAF from KERNEL mode so the kind L people at VMS let you create a user profile earlier and then pass it to this. *RTL from inner-mode*? Sounds very reasonable.  K How did this piece of filth get through QA? Pull the documentation from the 
 web quick!   Cheers Richard Maher  J PS. I'd like to see VMS engineering say "Unsupported" if a bug came in for that!       Date:  Tues, Mar 28 2006 4:31 am& Hoff Hoffman <hoff-remove-t...@hp.com>   Richard Maher wrote:D > Can I just pin you down on your definition of an RTL? Is a call toF > SYS$GETUAI or SYS$PERSONA_CREATE in sys$library:secureshp.exe a "RTL call"?J > So as not to try and trick you, when previously (couple of years ago?) IK > asked "Is it safe to call sys$getuai from a UWSS?" your answer was "AFAIK I > No.". I am now of the opinion that what we're walking away with here is  "It L > is safe to call other UWSS shareable images (including SECURESHRP) but not' > other user-mode RTLs." Is that right?     G    What I am referring to here as an RTL is anything not built into the F kernel.  If it's loaded and activated separately or otherwise not partC of the kernel, it's not necessarily safe to call it from inner-mode G code.  And AFAIK, it is not safe to call sys$getuai, since this call is G implemented as a UWSS and not as part of the kernel -- the LOADSS calls H needed to use outer-mode APIs as part of their operations, so the LOADSS* APIs are not directly part of the kernel.)    * >> But if problems do arise and the reportJ >>   gets to OpenVMS Engineering, my input is going to be "not supported".  J > You can't get much plainer than that, and I appreciate your candour. But the K > image I'm stuck with is that of the poor developer's face who, after just J > spending a big chunk of his life reinventing a new heap-managment wheel,C > stumbles across ACMS or Rdb (or PCA$COLLECTOR) code that's called E > LIB$GET_VM_PAGE from year dot and has had oodles of VMS engineering  > involvement. He's gutted!!!       E    I've extricated my share of locally-written memory management code L from existing applications.  Maintaining it was more work than replacing it.  G    And in any event, inner-mode code cannot call RTL calls.   There are C cases where it might work for some folks, but there are cases where A mixing the access modes and the memory heap page protections will A encounter failures -- or worse, you'll introduce a security hole.     F    If I'm coding in user-mode, I call the RTLs and set up what I need,H and pass it along to inner-mode code (where I then verify the memory viaC probes).  If I'm coding in inner-mode code, I use the kernel memory D management routines, and the kernel debugging routines (tr_print andG friends, for instance).  Or I expect the outer-mode code to have set up < the necessary memory, and I then probe it for access rights.    G    If working in this area, access to the source listings are required.       @ > But if the VMS documentation set did not consistently refer toJ > LIB$GET_VM_PAGE being called from inner mode then I suspect that support and H > engineering would not be hounded about it for all eternity. Will these) > references be removed from the doc set?     G    I can't say I've seen any documentation to inner-mode code referring H to the RTLs.  If it is, we'll either have to fix the existing RTLs to beC mode-sensitive or we'll have to fix the documentation, or both.  In G either case, the resolution doesn't immediately matter here as calls to # the RTL from inner mode don't work.   B   NOSHRIMG,  privileged shareable image cannot have outbound calls      F > When did it become legal to drop the /PROTECT qualifier on the $LINKF > command? Are we agreed that a re-visit of the relevant documentation should3 > have taken place at that time and, sadly, didn't?       ,    You can't call RTLs from inner-mode code.    ; >>   obviously the kernel-mode C library, are safe to call.   I > Once again, can you please tell me the file-spec for this library? (And  are H > the routines as well documented as the EXE$ routines) Are there kernel mode+ > equivalents of malloc, and realloc et al?       I    You can't call user-mode code and user-mode RTLs from inner-mode code.   C    The kernel C library is part of the kernel, and is callable from  inner-mode code.    H    Key here is the use of LINK/NOSYSLIB/SYSEXE.  If you have C calls andH use this command, per the driver documentation, you will get a subset ofH the standard C library calls resolved via the kernel C library.  (If youF have both the user-mode C library and the inner-mode C library, you'll get duplicate symbols.)       * >> Inner-mode calls to anything other thanE >> exec-based system services are not generally considered supported.   G > Anyone got just *one* example of a non exec-based system service call  being  > specifically supported?       F    You can't call user-mode code from inner-mode code.  If you need toF get out to user-mode to do something, you need to use an AST or an ACP9 or a connection to a remote server process or other such.   B    I can choose to use a pseudo device driver, too, as there are aH variety of constructs and APIs available that can make operations withinG a driver easier (and easier to secure) than those within a UWSS; within B a privileged shareable image.  And there is more documentation for
 drivers, too.     D    Anyone writing inner-mode code really needs access to the OpenVMS; source listings kit, too.  The part numbers are in the FAQ.    ------------------------------  # Date: Tue, 18 Apr 2006 14:26:21 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>8 Subject: Re: Is VMS Security being dumbed-down for Java?2 Message-ID: <hG61g.6470$6k2.3767@news.cpqcorp.net>   Richard Maher wrote:  K > OK you couldn't have made it any clearer and I'm not trying to antagonize " > you further by asking yet again.  F    (Antagonize me?  I've been active on Usenet for over fifteen years F now,  and have acquired a hide that could capably double as ballistic  armour.  :-)  E    I am not discussing this particular topic here in the newsgroups,  G beyond what I have already posted today, and in recent times.  This is  G NOT due to any antagonism you might think you have engendered, but for   technical and policy reasons.    ------------------------------  % Date: Tue, 18 Apr 2006 02:59:15 -0400 ' From: Dave Froble <davef@tsoft-inc.com> # Subject: Re: OT: Sparc not dead yet 9 Message-ID: <FISdnbbRsLQmENnZnZ2dnUVZ_sadnZ2d@libcom.com>    JF Mezei wrote: e > http://news.com.com/Sun+at+work+on+Niagara%2C+Rock+successors/2100-1006_3-6062008.html?tag=nefd.top  > F > Sun announces successors to Niagara and Rock successors, at first at" > 90nm process and later at 65nm . >  > H > "Niagara has eight processing cores, each able to handle four threads,> > enabling a total of 32 independent software sequences to run9 > simultaneously. Niagara II increases this limit to 64;"  >  > 2 > IA64 is "soon" getting to 2 processors per core. >  > I > Looks to me like Sun carefully edged its bets, with both Sparc and 8086 I > and isn't going to prematurely staop Sparc with its huge installed base & > until the 8086 has really scaled up.  ? There you go again.  Has Sun issued a statement that they will  I eventually give up on SPARC that I missed?  It would seem to me that Sun  F took a good look at what many of their customers do, and designed for I that type of work.  Web servers on the internet?  Nothing too demanding,  I except for the sheer volumn.  So multiple cores each capable of multiple  H threads.  Seems reasonable to me.  So why do you continue to spout that E garbage about everything being replaced by x86 as if it's inevitable?   H > The big difference with IA64 is that IA64 has no installed base, it is- > PaRisc and Alpha that have installed bases.   F While true, VMS still has some type of installed base, and their only G option going forward, at least visable today, is the good ship itanic,  ) may it acquire iceburg detection sensors.   H > So those who were saying that Sparc was dead were wrong. It isn't deadF > yet, even if it might be true that Sun intends to eventually replace > Sparc with the 8086.  I Sun rose and fell with the .COM adventure.  But they still have a rather  @ large existing base of customers.  Sun will have first crack at F retaining them if it continues to provide what they need.  Seems like < they intend to do just that.  Wish others would do the same.   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Tue, 18 Apr 2006 03:25:03 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> # Subject: Re: OT: Sparc not dead yet , Message-ID: <44449447.37A20891@teksavvy.com>   Dave Froble wrote:@ > There you go again.  Has Sun issued a statement that they will- > eventually give up on SPARC that I missed?      G No, they have not. But there has also been lots of speculation from the C press about Sun eventually going all 8086 once it scales to replace G Sparcs. HP has issued FUD about SPARC being abandonned eventually, just S like SUN has issued FUD about IA64 being stillborn and eventually to be abandonned.   E The difference here is that Sun is definitely countering that FUD and E providing confidence that the Sparc family still has plenty of growth B left, and won't consist solely of one chip. (Niagara, Rock and the
 Fujitsu one).   F And SUN provides confidence that when/if Sparc runs out of steam, theyC will have the 8086 solution available already with an already large % inventiry of software already ported.     J > Sun rose and fell with the .COM adventure.  But they still have a rather# > large existing base of customers.   F Your memory is short. Sun grew since the late 1980s when it started toH steal DEC's customer base one by one.  The .COM blip gave Sun artificialF unsustainable growth, but it already had a substantial installed base.D Don't underestimate Sun. They killed DEC once. They can kill what isB left of DEC (VMS) again. There is more SUN hardware in banks/stock exchanges than there is VMS.   ------------------------------    Date: 18 Apr 2006 05:49:06 -0700 From: bob@instantwhip.com # Subject: Re: OT: Sparc not dead yet C Message-ID: <1145364546.552083.297520@u72g2000cwu.googlegroups.com>   ; sun did not hurt DEC ... DEC hurt DEC with no marketing and > poor business and technology decisions ... and after comparing7 CERT counts with solaris and VMS, I do not know why any 2 bank or stock market anywhere would choose sun ...   ------------------------------    Date: 18 Apr 2006 09:14:35 -0700# From: "chaos" <dciobanu@rogers.com> - Subject: Re: SoyMail & insufficient privilege C Message-ID: <1145376874.986530.164730@i40g2000cwc.googlegroups.com>   9 Yep, that's the exact scenarion. I don't get prompted for ' authentication. Just the error message.    Mark Daniel wrote:   > Hello Dimitru. > G > Are you getting prompted with a browser username/password dialog when   > you access /cgi-bin/soymail/~? > C > If not then the server authorization is not correctly configured.    What do you mean by that. & I am loading the authorization module.  ; LoadModule auth_openvms_module modules/mod_auth_openvms.exe   ! Is there anything else required ?    Thanks,    Dumitru  > I > Otherwise the soyMAIL message HTML source should contain a comment that  > looks like > A >    <!-- *****  REPORTING MODULE:LINE IS xxxxxxx:nnnn  ***** -->  > = > which will give a clue.  See Admin and Install section 6.1.    ------------------------------    Date: 18 Apr 2006 09:33:09 -0700# From: "chaos" <dciobanu@rogers.com> - Subject: Re: SoyMail & insufficient privilege C Message-ID: <1145377989.204650.316240@u72g2000cwu.googlegroups.com>   & Hoping that this will bring more info.  9 <!-- ***** REPORTING MODULE:LINE IS REQUEST:124 ***** -->    It doesn't really for me :(    Dumitru    ------------------------------    Date: 18 Apr 2006 09:43:07 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 7 Subject: Re: Strange behavior of DEFINE with equal-sign 3 Message-ID: <XDVK0AjmJGrZ@eisner.encompasserve.org>   t In article <7dd80f60604051001u247dc01ev41d7d69954691125@mail.gmail.com>, "Ken Robinson" <kenrbnsn@gmail.com> writes:  ? > With a little trial and error I discovered that the following  > characters do the same thing:  > # > ? ] ^  > H > Now if anyone can figure out how these characters are related, perhaps4 > the solution to this mystery will become apparent.  F    The answer is:  DCL is full of strange and mysterious code that wasG    a real pain to port to Alpha.  What is documented to work will work. E    What is not documented to work is not guaranteed to fail.  In fact '    that's true for almost all software.   6    Try this (note the change from the previous posts):      $a = "hello how are you    $define test &a    $show logical a  B    In fact, what I've just shown you is a well known _unsupported_    "feature" of DCL.   ------------------------------    Date: 18 Apr 2006 09:48:03 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 7 Subject: Re: Strange behavior of DEFINE with equal-sign 3 Message-ID: <hRirVXbFExtb@eisner.encompasserve.org>   w In article <e16csb$t54$3@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:  > J > Easy.  None of them are in the FORTRAN 77 character set.  Which reminds I > me: is the limitation of node names to 6 characters in any way related  ; > to a similar restriction on variable names in FORTRAN 77?  >   E    I've never seen such a restriction in any Fortran 77 compiler, and     I'm not sure ANSI allows it.   F    6 character variable names were a common restriction in FORTRAN IV,    a.k.a. Fortran 66.       Ah, three sixes!    ------------------------------  # Date: Tue, 18 Apr 2006 16:10:02 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>7 Subject: Re: Strange behavior of DEFINE with equal-sign 2 Message-ID: <ub81g.6477$%h2.5012@news.cpqcorp.net>   Bob Koehler wrote:   > 8 >    Try this (note the change from the previous posts): >  >    $a = "hello how are you >    $define test &a >    $show logical a > D >    In fact, what I've just shown you is a well known _unsupported_ >    "feature" of DCL. >   H    Though ampersand-based symbol substitution itself is fully supported I and documented.  (I ended up having to add it into the DCL book, too, as  G that syntax became necessary when working with the context of the PIPE  G command.  I hadn't wanted to, as the addition required a corresponding  H discussion of the two passes that occur within DCL symbol substitution, I and I expected that would layer complexity and confusion into an already   baroque discussion.)   ------------------------------  % Date: Tue, 18 Apr 2006 03:02:51 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 1 Subject: TCPIP MTU settings on VAX/TCPIP Services , Message-ID: <44448F14.DD08C446@teksavvy.com>               +----[mac]
 [router]----+              +----[vax4000-200]
             +              +----[vax4000-600]
             + $             +----[vaxstation3100-30]    C Router is a NAT router. It has the WAN side MTU set to 1452 (MSS to $ 1412), as per the ISP configuration.  G The 3 vaxes have the same software (VMS 7.2, TCPIP services 5.3-2)  the " 2 4000s have the same system disk.    5 http://www.speedguide.net:8080  yields the following:   D (this page respondes with javascript which contains a URL containing? your parameters, and when that is submitted, the parameters are H formatted nicely, but you can read the javascript to see your parameters in the URL. MTU = MSS + 40)     0 mac,      it reports an MTU of 1452, as expected0 3100,     it reports an MTU of 1452, as expected0 4000-200, it reports an MTU of 1452, as expected  5 on the 4000-600, it reports an MTU of 576 (MSS = 536)   D The 4000-600 happens to have the cluster IP alias at the moment. TheF tests on the two 4000s were done from the same SYSTEM account from theE same UAF, and on the 4000-600, also from a more generous account with  greater quotas. Same results.      On the 4000-600:
 $ ifconfig -a A LO0: flags=100c89<UP,LOOPBACK,NOARP,MULTICAST,SIMPLEX,NOCHECKSUM> /      inet 127.0.0.1 netmask ff000000 ipmtu 4096   6 ZE0: flags=c43<UP,BROADCAST,RUNNING,MULTICAST,SIMPLEX>F      inet 10.0.0.11 netmask ffff0000 broadcast 10.0.255.255 ipmtu 1500E      inet 10.0.0.5 netmask ffff0000 broadcast 10.0.255.255 ipmtu 1500   6 When I had the MTU to 1452, the results were the same.    F Why would one node have such a different MTU ? The other nodes seem toH be able to find out what the MTU is because they are set to a default ofH 1500, but the link is established at 1452, but the 4000-600 negotiates a MUCH lower value of MTU.      ( Any hints/guesses on why that would be ?   ------------------------------  % Date: Tue, 18 Apr 2006 03:39:05 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 5 Subject: Re: TCPIP MTU settings on VAX/TCPIP Services , Message-ID: <44449790.3196E1CC@teksavvy.com>   Never mind.   D doing a diff on the output  of sysconfig -q inet on 2 nodes revealed@ that the 400-0600 had pmtu_enabled=0 when it should have been 1.E Probably leftovers from when I tested some SLIP settings with my PDA.   3 sysconfig -r inet pmtu+enabled=1 solved the problem    ------------------------------  % Date: Tue, 18 Apr 2006 03:52:42 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 5 Subject: Re: TCPIP MTU settings on VAX/TCPIP Services , Message-ID: <44449ABF.BB12709A@teksavvy.com>   Oh, one more thing I found out.     4 The "TCPIP Receive Window" (RWIN) setting on VMS is    sysconfig -q inet tcp_recvspace   7 (so to set it, sysconfig -r inet tcp_recvspace=newvalue   , This is definitely not an obvious parameter.  E (In fact, the TCPIP Services stack lacks proper documentation for the  sysconfig parameters)     E By increasing the RWIN setting, I was able to get that speedguide.net F report to show a theoretical throughout that was much higher. I've setG it at MSS * 46 * 2 ( 129904 for MSS of 1412). It was at 61440 before. I D have no idea what quota this impacts. And obviously autogen won't be automatically adjusting this.    ------------------------------  % Date: Tue, 18 Apr 2006 03:09:49 -0400 ' From: Dave Froble <davef@tsoft-inc.com> + Subject: Re: What is wrong with my network? / Message-ID: <vOadneSVEOOoDdnZRVn-uw@libcom.com>    Jeff Cameron wrote:  > My three VMS nodes are:  >   2 > AXPAXP  Alpha 2100       VMS 7.3-1  100Base-T2 > PELE   - Alpha DS10       VMS 7.3-2  100Base-T2 > SLTCRK  VaxStation 3100  VMS 6.1   -  10Base-T >   H > The three nodes are the only three nodes on a dedicated switch, with a: > single connection to the rest of our corporate intranet. >    > Using the Commands :' > $MCR DTSEND DATA/NODE=<nodename>/STAT F > I was able to get the following DECNET data throughput measurements: >   $ > AXPAXP to PELE   : 90.1 Kbytes/Sec% > AXPAXP to SLTCRK  : 57.1 Kbytes/Sec  >   $ > PELE to AXPAXP   :  9.9 Kbytes/Sec$ > PELE to SLTCRK   : 58.3 Kbytes/Sec >   % > SLTCRK to AXPAXP  : 57.5 Kbytes/Sec $ > SLTCRK to PELE   : 56.8 Kbytes/Sec >   L > I get very similar measurements using TCP/IP with FTP. The question is why# > is the PELE to AXPAXP so abysmal?  > M > Both AXPAXP and PELE have the console parameter ewa0_mode set to FastFD. So N > auto Negotiate is off. I have used a Cisco Switch and a small Linksys switch > with the same results.  F Ok, I may be off base here, because I'm not sure exactly how switches  work.  But I'll take a shot.  H There is no such thing as full duplex for the VAXstation.  It's 10baseT H and half duplex.  Possibly with a switch, the interface for each system E can be different, but having been bitten real hard by having systems  H mis-matched, if I have even one system incapable of full duplex, then I 6 run all systems at half duplex.  I mean bit REAL hard.  H A suggestion, rather easy, set all three half duplex and run the DTSEND  tests again.  G I've also had bad cables cause problems.  Just had to pull a new cable  E between two buildings several weeks ago.  Diagnosing it was fun, and  ! pulling cables is just so joyful.   J > My next test is to connect AXPAXP and PELE using a crossover cable. DoesC > anyone have any other suggestions for narrowing down the problem?   F You'll for sure have to have them running half duplex if you do that. I Sure is a good thing to do, for what it will rule out as much as what it   might show.    > Thank you in advance.  >  > Jeff Cameron > ' > PS : Here are the raw DTSEND results:  > AXPAXP[CAMERON]>mcr dtsend > 7 > DTS Version 3.00 initiated on  6-APR-2006 14:26:36.83  >  > _Test: data/node=pele/stat- > %NET-S-NORMAL, normal successful completion  >  > Test Parameters: >    Test duration (sec)  30  >    Target node          "PELE"! >    Line speed (baud)    1000000  >    Message size (bytes) 128  >  > Summary statistics: ' >    Total messages XMIT  21130  RECV 0 ! >    Total bytes XMIT     2704640   >    Messages per second  704.33 >    Bytes per second     90154   >    Line thruput (baud)  721232  >    %Line Utilization    72.123 >  > _Test: data/node=sltcrk/stat- > %NET-S-NORMAL, normal successful completion  >  > Test Parameters: >    Test duration (sec)  30" >    Target node          "SLTCRK"! >    Line speed (baud)    1000000  >    Message size (bytes) 128  >  > Summary statistics: ' >    Total messages XMIT  13387  RECV 0 ! >    Total bytes XMIT     1713536   >    Messages per second  446.23 >    Bytes per second     57117   >    Line thruput (baud)  456936  >    %Line Utilization    45.694 >  >  > PELE > PELE[CAMERON]>mcr dtsend > 7 > DTS Version 3.00 initiated on  6-APR-2006 14:34:05.34  >  > _Test: DATA/NODE=AXPAXP/STAT- > %NET-S-NORMAL, normal successful completion  >  > Test Parameters: >    Test duration (sec)  30" >    Target node          "AXPAXP"! >    Line speed (baud)    1000000  >    Message size (bytes) 128  >  > Summary statistics: & >    Total messages XMIT  2341  RECV 0  >    Total bytes XMIT     299648 >    Messages per second  78.03  >    Bytes per second     9988 >    Line thruput (baud)  79904  >    %Line Utilization    7.990    Similar to my bad cable tests.   > _Test: DATA/NODE=SLTCRK/STAT- > %NET-S-NORMAL, normal successful completion  >  > Test Parameters: >    Test duration (sec)  30" >    Target node          "SLTCRK"! >    Line speed (baud)    1000000  >    Message size (bytes) 128  >  > Summary statistics: ' >    Total messages XMIT  13662  RECV 0 ! >    Total bytes XMIT     1748736   >    Messages per second  455.40 >    Bytes per second     58291   >    Line thruput (baud)  466328  >    %Line Utilization    46.633 >  >  > SLTCRK > SLTCRK[SYSEXE]>mcr dtsend  > 7 > DTS Version 3.00 initiated on  6-APR-2006 14:33:48.13  >  > _Test: data/node=axpaxp/stat- > %NET-S-NORMAL, normal successful completion  >  > Test Parameters: >    Test duration (sec)  30" >    Target node          "AXPAXP"! >    Line speed (baud)    1000000  >    Message size (bytes) 128  >  > Summary statistics: ' >    Total messages XMIT  13468  RECV 0 ! >    Total bytes XMIT     1723904   >    Messages per second  448.93 >    Bytes per second     57463   >    Line thruput (baud)  459704  >    %Line Utilization    45.970 >  > _Test: data/node=pele/stat- > %NET-S-NORMAL, normal successful completion  >  > Test Parameters: >    Test duration (sec)  30  >    Target node          "PELE"! >    Line speed (baud)    1000000  >    Message size (bytes) 128  >  > Summary statistics: ' >    Total messages XMIT  13321  RECV 0 ! >    Total bytes XMIT     1705088   >    Messages per second  444.03 >    Bytes per second     56836   >    Line thruput (baud)  454688  >    %Line Utilization    45.469 >  >      --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Tue, 18 Apr 2006 10:18:41 +0200 ( From: "Rudolf Wingert" <win@fom.fgan.de>+ Subject: Re: What is wrong with my network? 7 Message-ID: <000201c662c0$b3fe7b00$994614ac@domina.fom>    Hello,C Jeff, it is difficult to write, what is wrong with your network. At A first, you should change the test environment. Add the following: F /SPEED=10000000 for transfer from or to SLTCRK and SPEED=100000000 for% the rest, /SIZE=4096 and /SECONDS=30. D If the results of test are as bad as you reported, you should have aG look to the PIPELINE QUOTA (Phase IV). The value should be smaller than F the buffer size of the switch. Also you should set the switchports andB Alphas fixed to 100Base-TX and full duplex (e.g. PELE console: SETH EWA0_MODE FASTFD). To set the port for SLTCRK to 10Base-T is also a good idea. ( Hope this helps. Best regards R. Wingert   ------------------------------  # Date: Tue, 18 Apr 2006 11:03:02 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) + Subject: Re: What is wrong with my network? [ Message-ID: <rdeininger-1804060703010001@dialup-4.233.173.122.dial1.manchester1.level3.net>   = In article <C069ACC9.1E506%roktsci@comcast.net>, Jeff Cameron  <roktsci@comcast.net> wrote:   >My three VMS nodes are: > 1 >AXPAXP  Alpha 2100       VMS 7.3-1  100Base-T 1 >PELE   - Alpha DS10       VMS 7.3-2  100Base-T 1 >SLTCRK  VaxStation 3100  VMS 6.1   -  10Base-T  > G >The three nodes are the only three nodes on a dedicated switch, with a 9 >single connection to the rest of our corporate intranet.  >  >Using the Commands : & >$MCR DTSEND DATA/NODE=<nodename>/STATE >I was able to get the following DECNET data throughput measurements:  > # >AXPAXP to PELE   : 90.1 Kbytes/Sec $ >AXPAXP to SLTCRK  : 57.1 Kbytes/Sec > # >PELE to AXPAXP   :  9.9 Kbytes/Sec # >PELE to SLTCRK   : 58.3 Kbytes/Sec  > $ >SLTCRK to AXPAXP  : 57.5 Kbytes/Sec# >SLTCRK to PELE   : 56.8 Kbytes/Sec  > K >I get very similar measurements using TCP/IP with FTP. The question is why " >is the PELE to AXPAXP so abysmal? > L >Both AXPAXP and PELE have the console parameter ewa0_mode set to FastFD. SoM >auto Negotiate is off. I have used a Cisco Switch and a small Linksys switch  >with the same results.     F Unless you can actively manage the network switch, and verify that theI speed and duplex settings match what you have configured for each system, B you should NOT assume that it auto-negotiated correctly.  100 MbitI autonegotiation is notoriously unreliable, with competing "standards" and G not-quite-compatible algorithms.  The duplex setting seems to give more  trouble than the speed.   D If you have an unmanaged switch, you probably can't control the portG settings and you might not even be able to tell what they are.  In that G case try chaning your alpha systems (one by one) to auto-negotiate, and 1 see if they find the right settings on their own.   H On recent VMS versions, you don't have to reboot to change LAN settings. $ RUN SYS$SYSTEM:LANCP is your friend.   D Your performance is about what I would expect if one node's LAN port* doesn't match the switch's duplex setting.     -- Robert    ------------------------------  % Date: Tue, 18 Apr 2006 12:26:56 +0100 * From: "Richard Brodie" <R.Brodie@rl.ac.uk>+ Subject: Re: What is wrong with my network? 2 Message-ID: <e22ie0$r4s$1@blackmamba.itd.rl.ac.uk>  6 "Jeff Cameron" <roktsci@comcast.net> wrote in message * news:C069ACC9.1E506%roktsci@comcast.net...  M > Both AXPAXP and PELE have the console parameter ewa0_mode set to FastFD. So  > auto Negotiate is off.  Q Robert Deininger made some relevant points about autonegotiate. He didn't mention W one important point: forcing full duplex at one end (of a segment) only is *guaranteed* N not to work properly. So if you connect via an unmanaged switch don't do that.   ------------------------------  # Date: Tue, 18 Apr 2006 13:54:27 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>+ Subject: Re: What is wrong with my network? 2 Message-ID: <nc61g.6467$eh2.2314@news.cpqcorp.net>   Jeff Cameron wrote:  > My three VMS nodes are:  >   2 > AXPAXP  Alpha 2100       VMS 7.3-1  100Base-T2 > PELE   - Alpha DS10       VMS 7.3-2  100Base-T2 > SLTCRK  VaxStation 3100  VMS 6.1   -  10Base-T  L > I get very similar measurements using TCP/IP with FTP. The question is why# > is the PELE to AXPAXP so abysmal?   I    I would first look after the duplex settings, ensuring that these are  F set correctly and consistently on both ends of the connection between  the switch and the host.  H    I have not encountered a VAX 10Base NIC that runs full duplex, and I I am aware of various compatibility problems with older NICs and automatic  C duplex detection.  I would definitely look to this first mismatch,  I obviously.  (With current OpenVMS versions, the network drivers now flag  % cases of apparent duplex mismatches.)    ------------------------------   End of INFO-VAX 2006.215 ************************