0 INFO-VAX	Sat, 14 Jan 2006	Volume 2006 : Issue 28      Contents: Re: DECnet: reconfigure TCPIP? Re: DECnet: reconfigure TCPIP? Re: DECnet: reconfigure TCPIP? Re: DECnet: reconfigure TCPIP? Re: DECnet: reconfigure TCPIP? Re: DECnet: reconfigure TCPIP?& Re: Farewell to a good reliable friend& Re: Farewell to a good reliable friend/ Re: foreign commands, .com files, and dcltables 2 Re: how to permanently reject this kind of address2 Re: how to permanently reject this kind of address2 Re: how to permanently reject this kind of address& looking for Force Flexor A264/500 docs$ Re: Technical Journal - Jan 06 Issue Re: TT_BRDCST? Re: TT_BRDCST? Re: TT_BRDCST? Re: TT_BRDCST? Re: TT_BRDCST?  F ----------------------------------------------------------------------  + Date: Sat, 14 Jan 2006 14:51:47 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)' Subject: Re: DECnet: reconfigure TCPIP? $ Message-ID: <dqb362$nf5$1@online.de>  D In article <dqb1d0$kc3$1@online.de>, helbig@astro.multiCLOTHESvax.de3 (Phillip Helbig---remove CLOTHES to reply) writes:    2 > I'm finally getting around to setting up DECnet.  H I notice that there is SYS$MANAGER: SYS$NET_SERVICES_TCPIP.COM which is G apparently called at some point during the DECnet setup and/or startup. G Is this something I have to be actively concerned about?  What does it  F do?  Presumably it is only called if DECnet is started.  Do I need to ? change anything in my TCPIP configuration and/or startup after   configuring DECnet?    ------------------------------  + Date: Sat, 14 Jan 2006 15:49:29 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)' Subject: Re: DECnet: reconfigure TCPIP? $ Message-ID: <dqb6i9$t3a$2@online.de>  D In article <dqb362$nf5$1@online.de>, helbig@astro.multiCLOTHESvax.de3 (Phillip Helbig---remove CLOTHES to reply) writes:    F > In article <dqb1d0$kc3$1@online.de>, helbig@astro.multiCLOTHESvax.de5 > (Phillip Helbig---remove CLOTHES to reply) writes:   > 4 > > I'm finally getting around to setting up DECnet.  % The following defaults are suggested:   > Do you want to operate as a router?         [NO (nonrouting)]:  J The network object database file is DISK$USER:[SYSTEM.EXE]NETOBJECT.DAT;1.  > Do you want to purge the object database?               [YES]:> Do you want a default DECnet account?                    [NO]:> Do you want a default account for the MAIL object?      [YES]:> Do you want a default account for the FAL object?        [NO]:> Do you want a default account for the PHONE object?     [YES]:> Do you want a default account for the NML object?       [YES]:> Do you want a default account for the MIRROR object?    [YES]:> Do you want a default account for the VPM object?       [YES]:  F Is there any conceivable reason not to go with the defaults in my caseG (hobbyist cluster, main reason for DECnet is to be able to run scripts  ' (efficiently) with the OSU web server)?    ------------------------------  + Date: Sat, 14 Jan 2006 17:30:22 +0000 (UTC) - From: klewis@OMEGA.MITRE.ORG (Keith A. Lewis) ' Subject: Re: DECnet: reconfigure TCPIP? . Message-ID: <dqbcfe$23v$1@newslocal.mitre.org>   helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes in article <dqb1d0$kc3$1@online.de> dated Sat, 14 Jan 2006 14:21:20 +0000 (UTC):1 >I'm finally getting around to setting up DECnet.  > F >I have not needed it up until now, since locally all nodes are in theF >same cluster and remotely it is not routed by my ISP (I haven't triedJ >it, but I'm pretty sure that it is not).  (Yes, I know that in principle 5 >it can be run over IP, but I have no need for that.)  > D >IIRC, it needs to be started before TCPIP since it "chances the MACG >address".  OK, no problem to have the startup in the correct sequence. @ >Since the TCPIP configuration contains "Ethernet_Addr" which isG >something like "08-00-2B-92-26-9D", i.e. a hardware address, does this ? >mean that I need to reconfigure TCPIP after setting up DECnet?   I What exactly contains "Ethernet_Addr"?  It's not part of the normal TCPIP G setup I go through for new nodes.  TCPIP does need to know its hardware L address so it can respond to ARPs.  It should retrieve it during startup (or interface addition).    I >I notice that there is SYS$MANAGER: SYS$NET_SERVICES_TCPIP.COM which is  H >apparently called at some point during the DECnet setup and/or startup.H >Is this something I have to be actively concerned about?  What does it G >do?  Presumably it is only called if DECnet is started.  Do I need to  @ >change anything in my TCPIP configuration and/or startup after  >configuring DECnet?  G SYS$MANAGER:SYS$NET_SERVICES_TCPIP.COM is used by the "START/NET TCPIP" L command, I think.  The alternative is "@SYS$MANAGER:TCPIP$STARTUP", just oneJ of them should be executed in SYSTARTUP_VMS.COM, and you already know that& it has to be after the DECNET startup.  & >The following defaults are suggested:  G The default values are pretty reasonable.  I'm assuming you don't allow L DECNET from outside your firewall.  There was a PHONE worm a few years back.  0 --Keith Lewis              klewis {at} mitre.org> The above may not (yet) represent the opinions of my employer.   ------------------------------  % Date: Sat, 14 Jan 2006 12:51:15 -0500 ' From: Dave Froble <davef@tsoft-inc.com> ' Subject: Re: DECnet: reconfigure TCPIP? 0 Message-ID: <11sieglntpfdh4f@corp.supernews.com>  / Phillip Helbig---remove CLOTHES to reply wrote: F > In article <dqb362$nf5$1@online.de>, helbig@astro.multiCLOTHESvax.de5 > (Phillip Helbig---remove CLOTHES to reply) writes:   >  > F >>In article <dqb1d0$kc3$1@online.de>, helbig@astro.multiCLOTHESvax.de5 >>(Phillip Helbig---remove CLOTHES to reply) writes:   >> >>3 >>>I'm finally getting around to setting up DECnet.  >  > ' > The following defaults are suggested:  > @ > Do you want to operate as a router?         [NO (nonrouting)]: > L > The network object database file is DISK$USER:[SYSTEM.EXE]NETOBJECT.DAT;1. > @ > Do you want to purge the object database?               [YES]:@ > Do you want a default DECnet account?                    [NO]:@ > Do you want a default account for the MAIL object?      [YES]:@ > Do you want a default account for the FAL object?        [NO]:@ > Do you want a default account for the PHONE object?     [YES]:@ > Do you want a default account for the NML object?       [YES]:@ > Do you want a default account for the MIRROR object?    [YES]:@ > Do you want a default account for the VPM object?       [YES]: > H > Is there any conceivable reason not to go with the defaults in my caseI > (hobbyist cluster, main reason for DECnet is to be able to run scripts  ) > (efficiently) with the OSU web server)?  >   G I say no for all the default accounts.  Unless you're going to use the  4 capability, why have the extra user accounts set up?   --  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: Sat, 14 Jan 2006 18:11:39 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)' Subject: Re: DECnet: reconfigure TCPIP? $ Message-ID: <dqbesr$d79$1@online.de>  E In article <dqbcfe$23v$1@newslocal.mitre.org>, klewis@OMEGA.MITRE.ORG  (Keith A. Lewis) writes:    F > >IIRC, it needs to be started before TCPIP since it "chances the MACI > >address".  OK, no problem to have the startup in the correct sequence. B > >Since the TCPIP configuration contains "Ethernet_Addr" which isI > >something like "08-00-2B-92-26-9D", i.e. a hardware address, does this A > >mean that I need to reconfigure TCPIP after setting up DECnet?  > K > What exactly contains "Ethernet_Addr"?  It's not part of the normal TCPIP I > setup I go through for new nodes.  TCPIP does need to know its hardware N > address so it can respond to ARPs.  It should retrieve it during startup (or > interface addition).    ) It shows up in TCPIP SHOW INTERFACE/FULL:    TCPIP> sh interf/full ze0   Interface: ZE0 M    IP_Addr: 192.168.1.120     NETWRK: 255.255.255.0     BRDCST: 192.168.1.255   ClusterM     C_Addr: 192.168.1.101   C_NETWRK: 255.255.255.0   C_BRDCST: 192.168.1.255 E                        Ethernet_Addr: 08-00-2B-92-26-9D    MTU:  1500 $      Flags: UP BRDCST RUN MCAST SMPX5                                   RECEIVE        SEND 5    Packets                         209641       22183 5      Errors                             0           0 )    Collisions:                          0   G Presumably, it picks it up during startup or during the configuration.  F Thus, once the system is up and running with TCPIP but with no DECnet,G presumably I would have to shutdown and restart TCPIP after starting up G DECnet or perhaps even reconfigure TCPIP---I don't know.  Maybe I have  : to stop TCPIP, get DECnet running, then get TCPIP running.   ------------------------------  + Date: Sat, 14 Jan 2006 18:12:42 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)' Subject: Re: DECnet: reconfigure TCPIP? $ Message-ID: <dqbeup$d79$2@online.de>  < In article <11sieglntpfdh4f@corp.supernews.com>, Dave Froble <davef@tsoft-inc.com> writes:   B > > Do you want a default account for the VPM object?       [YES]: > > J > > Is there any conceivable reason not to go with the defaults in my caseK > > (hobbyist cluster, main reason for DECnet is to be able to run scripts  + > > (efficiently) with the OSU web server)?  > I > I say no for all the default accounts.  Unless you're going to use the  6 > capability, why have the extra user accounts set up?  6 Don't I need VPM to run MONITOR CLUSTER without TCPIP?   ------------------------------  % Date: Sat, 14 Jan 2006 07:40:44 -0500 ) From: "Neil Rieck" <n.rieck@sympatico.ca> / Subject: Re: Farewell to a good reliable friend : Message-ID: <Ui6yf.23952$W03.853934@news20.bellglobal.com>  < "JF Mezei" <jfmezei.spamnot@vaxination.ca> wrote in message ' news:43C80E08.B44F7902@vaxination.ca... 
 > Mike wrote:  [...snip...] > I > Yep. I tried not to be emotional when I switched it off. The console is J > still on, showing its final shutdown message with a time stamp. I shouldD > connect the printer port to a computer and "print screen" the lastH > shutdown for posterity (I've preserved modparams.dat and other files). > F Something similar happened to me back in 2001 when I decommisioned my  VAX-6430J http://www3.sympatico.ca/n.rieck/docs/alpha_diary.html#decommissioning_vaxL as we were rolling it out to the loading dock I popped off the grey plastic H "DIGITAL" name plate which I still have on my desk and look at each day.  K p.s. I don't remember feeling this way after decommissioning all those PDP  M machines (which I loved) or all those previous VAXs. But in the end CISC was  I clobbered by "OOE S/S RISC" so it was illogical to cling to the past. At   least we've still got OpenVMS.  
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------  % Date: Sat, 14 Jan 2006 12:31:33 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>/ Subject: Re: Farewell to a good reliable friend + Message-ID: <43C94385.A24E6A87@comcast.net>    JF Mezei wrote:  > G > Tonight, after over 18 years of service, I switched off my all mighty J > MicrovaxII. This morning, the princess lea ears (side panels) were takenO > by the municipal rubbish removal folks. That signaled the point of no return.   A Aw, GEEZ! man! *NEVER* discard that kind of stuff! There's always % *SOME*one *SOME*where looking for it!   F There's such a thing as on-line auction "drop off" sellers to help youH protect your personal info. E-mail me privately if you need details, butD PLEASE! give the community a chance before consigning such things to oblivion, huh?   --   David J Dachtera dba DJE Systems  http://www.djesys.com/) (and "Champ's Trading Post", coming soon)   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/    Coming soon:& Unofficial OpenVMS Marketing Home Page   ------------------------------  % Date: Sat, 14 Jan 2006 12:15:35 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>8 Subject: Re: foreign commands, .com files, and dcltables+ Message-ID: <43C93FC6.8A120C46@comcast.net>    Ken Fairfield wrote: >  > David J Dachtera wrote:  > > Jeff Cameron wrote:  > > 
 > >>[snip]O > >>One other point; while you can change the actual system wide DCL tables, it P > >>is typically not a good idea. This is because when you upgrade or patch VMS,L > >>the kit my overwrite your changes. Instead (if you go the executable/CLDP > >>route) that you include your SET COMMAND in the system wide login procedure. > >  > > H > > OOOOOOOOOOOOHHHHHHHHHHHHHHH!!!!!!!!! *DEFINITELY* *NOT* a good idea! > > E > > The answer to the question why is (almost) your next paragraph...  > >  > > P > >>This is because each process that uses DCL copies the entire DCL tables intoL > >>the context of the process when the process is created, so that when youD > >>execute the SET COMMAND it only changes the process' DCL tables. > >  > > L > > Well, that's close. Your process's command table is mapped to the sharedL > > command table UNLESS you issue "SET COMMAND filespec", at which time theE > > command tables get copied into your process's address space which B > > reduces the amount of working set available for code and data. > > A > > I solved a heavy paging problem once (on VAX, I grant you) by G > > eliminating SET COMMANDS ins SYLOGIN and several proc.'s it invoked L > > becase they were no longer needed. Page faults went down and performance, > > increased much more than I had expected. > ? > Late to the discussion and agreeing with David, it's a really 9 > bad idea to do SET COMMAND unless you really need to...  > 3 > Here are two alternatives I didn't see mentioned.  > A > 1) For each command that is not in DCLTABLES, write a "wrapper" @ >     command file and define a global symbol to execute it with= >     the same name as the VERB in the .CLD.  On entry to the @ >     command file, do the SET COMMAND, DELETE/SYMBOL/GLOBAL theC >     symbol that invoked the command file, then invoke the command  >     verb with P1 through P8. > A >     The result is that the SET COMMAND only gets done for those A >     people who use it, and only when that actually have need to C >     use it.  Depending upon the complexity of the command syntax, C >     P1 through P8 will need to be properly handled when passed to ? >     the verb.   Also, you may need to add a "dummy P1" in the B >     orginal symbol definition, that you edit out before invokingA >     the verb, so that verb qualifiers don't get rejected by the 0 >     DCL "@" verb...  I've done something like, > * >         theverb == "@dev:[dir]theverb %" >  >     And in THEVERB.COM, I do,  >  >         $ P1 = P1 - "%"  > 
 >     etc.  A I'd add a caveat here that processing of quoted strings among the  parameters can get a bit hairy.   B > 2) Expanding on the idea of group-specific login procedures, youF >     can also create group-specific DCLTABLES.  This is potentionallyD >     a maintenance issue, as you'll see below, since after each VMSA >     product or operating system upgrade/install, you'll need to C >     upgrade each of the additional group-specific DCLTABLES.  But ? >     so long as that step is documented, and so long as you've A >     encapsulated creating the additional tables in some command 0 >     procedure, it shouldn't be too burdensome. > A >     For each UIC group that needs additional command verbs, for % >     this example, UIC group 44, do,  > 6 >         $ Set Command/Tables=Sys$Library:DCLTABLES -8 >              /Output=Sys$Common:[SYSLIB]DCLTABLES_44 -/ >              first.cld, second.cld, third.cld  > G >     This creates SYS$LIBRARY:DCLTABLES_44.EXE (in SYS$COMMON). Follow  >     this by the usual  > 4 >         $ INSTALL REPLACE SYS$LIBRARY:DCLTABLES_44 > 1 >     on all cluster nodes.  You'll also need an,  > D >         $ INSTALL ADD SYS$LIBRARY:DCLTABLES_44 /Open/Header/Shared > E >     somewhere early in your SYSTARTUP_VMS.COM.  The "REPLACE" above ' >     assumes that's already been done.  > " >     Next, go into AUTHORIZE and, > 3 >         UAF> Modify [44,*] /CliTable=DCLTABLES_44  > D >     Now every user in group 44 gets the additional verbs, but theyF >     all map to the same shared memory, and both you and they benefit? >     from not needing to pull a copy into process context. :-)  > D >     NOTE: You can also use this same technique to REMOVE access toE >           certain commands from groups of users.  We used to remove G >           interactive MAIL access from a "shared" application account  >          in this way.   G My preference would likely be to keep these private tables in a private F area, such on my cluster-common disk, and INSTALL them as known images at system startup time.   C Yes, maintenance can mean added work; so, work smarter, not harder. F You'll have to assess the changes in every VMS update, ECO and upgradeE and figure out how to bring your command tables up to the new rev. It F should be as simple a building a .COM proc. to take the base DCLTABLESD image, remove the commands that should be removed and add/modify theH commands that your user group(s) need added/modified. Then, you maintainE the proc., and it maintains the command tables every time to apply an G ECO, or install an upgrade or update. Also works for "cold" installs on  "new" systems.   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/    Coming soon:& Unofficial OpenVMS Marketing Home Page   ------------------------------    Date: 14 Jan 2006 05:50:48 -0800 From: bob@instantwhip.com ; Subject: Re: how to permanently reject this kind of address C Message-ID: <1137246648.619253.156070@o13g2000cwo.googlegroups.com>   ' guys, this is vms and ssh2?  Forget the ( worry, and do you have intrusion set for' three strikes and you are out, then why  bother?    ------------------------------  % Date: Sat, 14 Jan 2006 08:18:01 -0600 . From: Alphaman <alphaman-nix-spam@alphant.com>; Subject: Re: how to permanently reject this kind of address 7 Message-ID: <ea77a$43c90810$186088ed$14138@KNOLOGY.NET>    bob@instantwhip.com wrote:) > guys, this is vms and ssh2?  Forget the * > worry, and do you have intrusion set for) > three strikes and you are out, then why 	 > bother?  >   G Simple: they chew up memory.  Each attempt creates another process and  I wastes another couple hundred K on Alpha, and ties up an IP device.  And  E   I don't want them accessing *any* resource on my system if they're  F trying to break in via any other -- that's why setting the routing to L the bitbucket is so much better than other more focused methods, in my book.  E But you're right in that they won't be getting in anyways.  Oh, make  F sure you've got LGI_BRK_TERM set to 0 so that the IDS tracks their IP  and not a terminal device.   Aaron    ------------------------------  % Date: Sat, 14 Jan 2006 12:26:49 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>; Subject: Re: how to permanently reject this kind of address + Message-ID: <43C94268.CA2B6DFF@comcast.net>    Bill Gunshannon wrote: > [snip] > 2 > OrgName:    Grande Communications Networks, Inc. > OrgID:      GCNI > Address:    401 Carlson Cir  > City:       San Marcos > StateProv:  TX > PostalCode: 78666  > Country:    US > ) > NetRange:   24.155.0.0 - 24.155.255.255  > CIDR:       24.155.0.0/16  > NetName:    GRANDECOM-03 > NetHandle:  NET-24-155-0-0-1 > Parent:     NET-24-0-0-0-0 > NetType:    Direct Allocation  > NameServer: NS1.LSN.NET  > NameServer: NS2.LSN.NET 
 > Comment: > RegDate:    2000-04-03 > Updated:    2004-11-29 >  > OrgAbuseHandle: ABUSE153-ARIN  > OrgAbuseName:   Abuse ! > OrgAbusePhone:  +1-512-878-4000 % > OrgAbuseEmail:  abuse@grandecom.com  >  > OrgTechHandle: IPSER2-ARIN > OrgTechName:   IP Services  > OrgTechPhone:  +1-512-878-4000) > OrgTechEmail:  ipservices@grandecom.com    Folks,  F Bill wrote me privately that he got this info via "whois" on a FreeBSD box.  G Does anyone know of a way of getting this level of detail from WHOIS or 1 some other facility on UCX, Multinet or TCPware?    G All I seem to be able to get is usual Registrar and contact info. and a  bunch of legal blather.    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/    Coming soon:& Unofficial OpenVMS Marketing Home Page   ------------------------------   Date: 14 Jan 2006 16:27:24 GMT) From: Hans Bachner <Hans@Bachner.priv.at> / Subject: looking for Force Flexor A264/500 docs 0 Message-ID: <dqar78.81.1@usenet.bachner.priv.at>  J I recently acquired a Force Flexor A264/500 based computer, unfortunately F without any docs. All but one of the reasonable pointers turned up by J Google led to www.forcecomputers.com which is redirected to a page on the F Motorola website informing about the acquisition of force by Motorola.  J I'm particularly interested in the type/size of memeory the board accepts H and the pinout of the combined mouse/keyboard PS/2 connector (the usual 0 PS/2-Y-cables used with notebooks doesn't work).  # Thanks in advance for any pointers!    Hans.    ------------------------------  % Date: Sat, 14 Jan 2006 09:14:40 +0100 3 From: Michael Unger <spam.to.unger@spamgourmet.com> - Subject: Re: Technical Journal - Jan 06 Issue , Message-ID: <42rqhcF1kjik2U1@individual.net>  & On 2006-01-14 03:28, "JF Mezei" wrote:   > [...]  > F > As in previous version, some of the text is not quite readable on myF > MAC. So I'll have to select all text and paset it into a simple textC > editor to be able to read the text properly.  I am not sure it is  > missing fonts.  F Several "Arial", "Times New Roman", "Verdana", and "New Courier" fontsG are referenced but *not* embedded (as subsets); each "Futura Book" font A used in this document is an embedded subset so there should be no  problems with that font family.    > [...]  > F > Interestingly, if I print it to a postscript laser printer, the text > comes out fine.   C That might be an issue of the printer driver substituting fonts not C being embeded or trying a "best effort" replacement in the cases of F "Times" and "Courier" fonts (which are "standard" fonts for PostScript printers AFAIK).  E BTW: There are embedded PDF bookmarks too which is very convenient -- F but in the "Faking it with OpenVMS Shareable Images" chapter, Appendix< A, many *text* lines are erroneously converted to bookmarks.   Michael    --  ; Real names enhance the probability of getting real answers. 5 My e-mail account at DECUS Munich is no longer valid.    ------------------------------  + Date: Sat, 14 Jan 2006 12:51:37 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: TT_BRDCST? $ Message-ID: <dqas4p$b8l$2@online.de>  3 In article <maPO7K0aUJrI@eisner.encompasserve.org>, 0 Kilgallen@SpamCop.net (Larry Kilgallen) writes:   y > In article <dqara6$a1j$1@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:  > L > > While writing some DCL, I had occasion to use TT_NOBRDCST.  However, at M > > first I assumed there must be something called TT_BRDCST.  I see that of  J > > the arguments to F$GETDVI which start with TT_, there are three which % > > start with NO.  What's the point?  > C > So that when the feature is first introduced the default behavior  > is correct for existing code.   F I don't follow you.  Before the feature was introduced, no code could  have been relying on it.   ------------------------------    Date: 14 Jan 2006 06:43:49 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: TT_BRDCST? 3 Message-ID: <maPO7K0aUJrI@eisner.encompasserve.org>   w In article <dqara6$a1j$1@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:   J > While writing some DCL, I had occasion to use TT_NOBRDCST.  However, at K > first I assumed there must be something called TT_BRDCST.  I see that of  H > the arguments to F$GETDVI which start with TT_, there are three which # > start with NO.  What's the point?   A So that when the feature is first introduced the default behavior  is correct for existing code.    ------------------------------  + Date: Sat, 14 Jan 2006 15:13:46 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney)  Subject: Re: TT_BRDCST? ( Message-ID: <dqb4fa$s1h$1@pcls4.std.com>  R helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:  4 >In article <maPO7K0aUJrI@eisner.encompasserve.org>,1 >Kilgallen@SpamCop.net (Larry Kilgallen) writes:    z >> In article <dqara6$a1j$1@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: >>  M >> > While writing some DCL, I had occasion to use TT_NOBRDCST.  However, at  N >> > first I assumed there must be something called TT_BRDCST.  I see that of K >> > the arguments to F$GETDVI which start with TT_, there are three which  & >> > start with NO.  What's the point? >>  D >> So that when the feature is first introduced the default behavior  >> is correct for existing code.  G >I don't follow you.  Before the feature was introduced, no code could   >have been relying on it.   G No, "broadcast" is the default, and if the appropiate bit is clear, you H get the default.  To turn off broadcast you have to set the bit, and the4 best name to describe what it does is TT$x_NOBRDCST.  G It would be the ability to switch on/off a feature that was introduced, B the default must match "old" behavior so as not to break programs.   ------------------------------  + Date: Sat, 14 Jan 2006 15:47:16 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: TT_BRDCST? $ Message-ID: <dqb6e4$t3a$1@online.de>  H In article <dqb4fa$s1h$1@pcls4.std.com>, moroney@world.std.spaamtrap.com (Michael Moroney) writes:   T > helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: > 6 > >In article <maPO7K0aUJrI@eisner.encompasserve.org>,3 > >Kilgallen@SpamCop.net (Larry Kilgallen) writes:   > | > >> In article <dqara6$a1j$1@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: > >>  O > >> > While writing some DCL, I had occasion to use TT_NOBRDCST.  However, at  P > >> > first I assumed there must be something called TT_BRDCST.  I see that of M > >> > the arguments to F$GETDVI which start with TT_, there are three which  ( > >> > start with NO.  What's the point? > >>  F > >> So that when the feature is first introduced the default behavior" > >> is correct for existing code. > I > >I don't follow you.  Before the feature was introduced, no code could   > >have been relying on it.  > I > No, "broadcast" is the default, and if the appropiate bit is clear, you J > get the default.  To turn off broadcast you have to set the bit, and the6 > best name to describe what it does is TT$x_NOBRDCST.   OK, makes sense...  I > It would be the ability to switch on/off a feature that was introduced, D > the default must match "old" behavior so as not to break programs.  F ...but what would be an example of code which wouldn't work after the @ introduction of the new feature had it been TT_BRDCST instead of TT_NOBRDCST?  D I realise that broadcast was the default, but if in the old days it G couldn't be turned on and off, what code could possibly depend on this?    ------------------------------    Date: 14 Jan 2006 09:20:00 -0800 From: davidc@montagar.com  Subject: Re: TT_BRDCST? C Message-ID: <1137259200.194877.297260@o13g2000cwo.googlegroups.com>   B Old code that sets the bits, without knowing that your TT$M_BRDCSTG needed to be set as well.   The  "new feature" bits were presumed to be B MBZ (must be zero) or ignored.  Therefore, the default needs to beF "Broadcast", and be turned off.  OpenVMS is backward compatible to WAYD BACK.  VAX/VMS V1.0 binaries will still run on OpenVMS VAX V7.x, and< OpenVMS Engineering does an incredible job of insuring that.   ------------------------------   End of INFO-VAX 2006.028 ************************                                                                                                                                                                                                                                                                                                                                                                                                                                                                  ԯ8SOőIP?5ɓ &ȅ1;OӮ<_40z[,bnSĶf/J0aA{&a:]b&+aJb+ʃZIbSjWw=4hSmX2@%*

m>?$
|cT 	]Z"HI!@?!')?K0M1GMo?DՑq<5Sܞs@<e8,[yсIۊ~y+U1?Z5O)cgBqIټu3JgTjk``g-_/-4ʼ&G+EqXYOބ,צ<SGZ,peo}^cA6!!R]r,ԉGYb,R76w@}}/OO> r#]ߌ-S"E28+ɈrMѱ?[V}Mo'.Y7z8s.+lbr]^rtq:qZoJM8NNhFgvDwݢp0WK5ɫ;LRSN_>Pդ#uG55ՀUeʠ]CS14>;1mtP"`зow'!>E8 -lVɠnW{i=ǌK{qGV#*MĶ74
7jޭJԅYxO'ۛRJ߽cPY`/Y!mT"jgLHl"m),Hb
úfl_fN,l<.
#/$=
if>OP)eubZo"5{)GWFIz3Izb(k`f)EqcsY
-5"ĺRLPܩU
53~vL1d7eЈ>$[ l%@_^\	N{^\HolVS*#fu8tO=ZPh;{k;u+(%%AIb{a8Y[}pB6i7R
fȗ1>g%R&N2c;<GwV>*sgܥOmRP>TGe-ƣxXӯ*ծ鞠Ub\?
g\ʱ//p =Z).$+9wĦ%:\Qd3eվc DoLLd1Mf
+d6^N$=,XFG0̮o*L>1z+F q8jH|3B3/;9samW+xvr M1onSS.ٓۺ"dw휲9-q|h$L'`	®e'>zzl:!Sph hx\Qʶ)7%;0eīK
"_
^ZnOKpMqqxw$HXck?jASFz	G(SLk+Hhqfp_xdos}Zb ǭIY^hБ1+\Zuzꇹ?r0̫N7xf	~E° 3<yͪlݾddjEW,Fޡ+W&rR΁Pe}4s[RZ8&Oiȁڡ52"66X$@</cwD>4XE2#0tH?M|La 1TnQUGgz:e}Ǖq uGmQ!&Łj!Jj!d7GkGEf&g\^g'	';dT쵻t6s~!̸I\vv{5:^o~w{xhDKe:9,u}p^vVUŦ)7
ބR}i|@9nW0~a⍭],}[X,}wjF/WСQ-JQ0?"dO}̤^A7˺+E5я_!w)@IX`<Laֵi-{U* vnfU{٬!|˂%A+ZW~:ƵCjYi*Cl43ߊmΫυ'{\rC#$jnvKwqbNZO90o|ܺ8Oy}wxp$ѼDgZ;ކ(-Zw}'NDh'UD\
FWD4r]LO~hㇻMlhCUcOőd``P^_qpjAf}>??|K9k)-M	OxukʝƑCDį_Eޔ}rGng2GߍS
2Q
FYS"Cdnё1N=WB-}"
fH^e%c'ONʒrzՒK-?w@-C&:HF>
	zsuvi.AR.ncf#F/brxabTld	{eQTg"N2`b癢o%SŃg{'vj,j0qzGYu)*XBQ^:tRu6)SES>kF
5O8
NՏh+ዓ%<.w<@1٭Ud!,&jYC!@SIbL^f!t .1fS5ۙs,'unS2Y!pJzUï;pA|@ǚH@Y~5lK\4jK3&RB}u͛K㭄xW 2Ѽ?`ѥCDO:n9/o^6CMGfv6FlƓ]zL+_m)
^uK5p pB?&OrK_eG.-N4KVH Bu