1 INFO-VAX	Fri, 24 Nov 2006	Volume 2006 : Issue 647       Contents:- Re: Batch Queue Jobs Stuck In Starting Status  Re: DECW$SERVER crashes (8.3)  Re: DECW$SERVER crashes (8.3) , Re: increase in spam and what to do about it, Re: increase in spam and what to do about it, Re: increase in spam and what to do about it	 Re: JBOSS - Re: Oracle 9i and VMS multihome configuration - Re: Oracle 9i and VMS multihome configuration ; Reloading Alpha drivers, was: Re: Mouse: thumbwheel support 1 Re: SYSTEM-F-INFSMEM, insufficient dynamic memory 1 Re: SYSTEM-F-INFSMEM, insufficient dynamic memory 1 Re: SYSTEM-F-INFSMEM, insufficient dynamic memory  Re: Testing for mobile device 4 Re: Thoughts on the book: DEC is dead, long live DEC4 Re: Thoughts on the book: DEC is dead, long live DEC4 Re: Thoughts on the book: DEC is dead, long live DEC4 Re: Thoughts on the book: DEC is dead, long live DEC  Tracking down a process in MUTEX$ Re: Tracking down a process in MUTEX  F ----------------------------------------------------------------------    Date: 24 Nov 2006 05:18:54 -0800 From: etmsreec@yahoo.co.uk6 Subject: Re: Batch Queue Jobs Stuck In Starting StatusB Message-ID: <1164374333.966573.19130@j72g2000cwa.googlegroups.com>  G I think Peter has it right.  Unless the job controller or queue manager G (or the system disk for that matter) has a problem, I'd expect the next : step to be sort out the queue managers so that there's oneG QMAN$MASTER.DAT and a different queue manager (which is a legal config) 
 on each node.   D That said, I've seen jobs sitting in a STARTING state before now andD can't quite remember what the problem was.  It may be worth checkingD system params such as maxprocesses to make sure you're not nearer to$ the limit than you thought you were.   Steve    Peter Weaver wrote:  > >...I > > We have two nodes in the cluster (production and test) but they don't 4 > > share queues or pass jobs back and forth at all. > >... > K > That may be part of your problem. According to section 11.4.2 of the V8.3 J > Guidelines for OpenVMS Cluster Configurations "Every OpenVMS Cluster hasL > only one QMAN$MASTER.DAT file. Multiple queue managers are defined throughK > multiple *.QMAN$QUEUES and *.QMAN$JOURNAL files." I would not want to try 5 > using different QMAN$MASTER.DAT files in a cluster.  >  > Peter Weaver > www.weaverconsulting.ca : > CHARON-VAX  CHARON-AXP DataStream Reflection PreciseMail   ------------------------------    Date: 24 Nov 2006 04:04:13 -0800 From: etmsreec@yahoo.co.uk& Subject: Re: DECW$SERVER crashes (8.3)B Message-ID: <1164369853.174675.91460@j72g2000cwa.googlegroups.com>  , Maybe it's the thumbwheel on your mouse? :o)   JF Mezei wrote: J > This is just an FYI. If others are also experienceing this perhaps there) > might be something worth investigating.  > F > I've had a number of DECW$SERVER crashes, all occuring when bringingB > mozilla back to the forefront. This isn't something that happensL > "frequently", but it has happened perhaps 4-5 times since I moved to Alph= a=2E > ) > On VAX, the DECW$SERVER was rock solid.  > L > Granted, Mozilla is probably giving the X server a much bigger workout th= anG > any app on VAX. But still, I would expect Mozilla to crash, not the X 7 > server (bringing down all other apps in the process).  >  > / > Here is what the decw$server_error.log shows:  > 
 > At the top: 0 > SYS$SYSROOT:[SYSMGR]DECW$SERVER_0_ERROR.LOG;30 > 4 > 17-NOV-2006 05:33:21.5 Hello, this is the X serverI > This is the DECwindows X11 display server for OpenVMS Alpha V8.3-060629 6 >                  compiled on Jun 29 2006 at 18:33:00 > Main address =3D 00038CB8 , > Activating extension image DECW$SVEXT_XIE,- > extension name: Xie, entry address 003D8700 2 > Activating extension image DECW$SVEXT_DEC_XTRAP,3 > extension name: DEC-XTRAP, entry address 004CA548 8 > Activating extension image DECW$SVEXT_MULTI_BUFFERING,9 > extension name: Multi-Buffering, entry address 0051C0A0 , > Activating extension image DECW$SVEXT_LBX,- > extension name: LBX, entry address 0056ED88 , > Activating extension image DECW$SVEXT_DBE,- > extension name: DBE, entry address 005D03C0 , > Activating extension image DECW$SVEXT_GLX,- > extension name: GLX, entry address 00622EF8 2 > DECW$XPORT_SERVICES image base address: 7C8620003 > DECW$TRANSPORT_LOCAL image base address: 00C84000 4 > DECW$TRANSPORT_DECNET image base address: 00CC6000< > %DECW-I-ATTACHED, transport DECNET attached to its network3 > DECW$TRANSPORT_TCPIP image base address: 00E74000 ; > %DECW-I-ATTACHED, transport TCPIP attached to its network E > DECWINDOWS Hewlett-Packard Development Company OpenVMS, Release 8.3 7 > Shareable Image DDX GH, InitOutput loaded at 00EB60A0 5 > Setting affinity to CPU 0 (active CPU mask =3D 0x1)  >  > Radeon Server DDX for OpenVMS  > D > Copyright =A9 2002, 2004 Hewlett-Packard Development Company, L.P. > 4 > -------------------------------------------------- >  > At the bottom: >  >  > ; > 23-NOV-2006 15:37:35.3 Access granted to: LOCAL 0 JFMEZEI % >      matched entry: LOCAL 0 JFMEZEI  > 23-NOV-2006 17:56:06.8, > 23-NOV-2006 17:56:06.9 Fatal server error: > 23-NOV-2006 17:56:07.0/ > 23-NOV-2006 17:56:07.2 %SYSTEM-F-ABORT, abort  > L > Unrecoverable server internal error (error code =3D 44) found, terminating	 > all con  > nections.  > Mapped Images... > 0 >    START       END        LENGTH    IMAGE NAME0 >    -----       ---        ------    ----------5 >     10000      301ff      201ff    DECW$SERVER_MAIN 4 >     32000     243dff     211dff    DECW$SERVER_DIX/ > 7c884000   7c88ffff       bfff    DECW$XAUSHR 5 > 7c87a000   7c883fff       9fff    DECW$SETSHODISSHR 1 >    244000     2d55ff      915ff    DECW$LBXUTIL ) > 7bf58000   7bfc9fff      71fff    TRACE 5 > 7bb08000   7bb39fff      31fff    DECW$SECURITY_VMS - > 7b8e8000   7b959fff      71fff    SECURESHR . > 7b3ac000   7b42dfff      81fff    SECURESHRP9 > 7c870000   7c879fff       9fff    DECW$TRANSPORT_COMMON 2 > 7c868000   7c86ffff       7fff    DECW$LCNLIBSHR7 > 7c85c000   7c867fff       bfff    DECW$XPORT_SERVICES 2 > 81824530   81839a20      154f0    SYS$BASE_IMAGE1 > 7beb2000   7bf57fff      a5fff    DECC$SHR_EV56 , > 7bb52000   7bb97fff      45fff    DPML$SHR/ > 7b96c000   7b97dfff      11fff    CMA$TIS_SHR * > 7b62a000   7b67bfff      51fff    LIBRTL* > 7b67c000   7b683fff       7fff    LIBOTS6 > 81804e18   818076a8       2890    SYS$PUBLIC_VECTORS3 >    3d8000     4c93ff      f13ff    DECW$SVEXT_XIE 9 >    4ca000     51a3ff      503ff    DECW$SVEXT_DEC_XTRAP ? >    51c000     56c3ff      503ff    DECW$SVEXT_MULTI_BUFFERING 3 >    56e000     5ce7ff      607ff    DECW$SVEXT_LBX 3 >    5d0000     6203ff      503ff    DECW$SVEXT_DBE : >    622000     903bff     2e1bff    DECW$SVEXT_GLX_RADEON4 >    b4c000     bfc7ff      b07ff    DECW$DRM_RADEON2 >    bfe000     c80270      82270    DECW$DRM_PRIV8 >    904000     9c49ff      c09ff    DECW$SERVER_DDX_XAA8 >    a38000     ac89ff      909ff    DECW$SERVER_DDX_CFB8 >    aca000     b4a7ff      807ff    DECW$SERVER_DDX_MFB7 >    9c6000     a365ff      705ff    DECW$SERVER_DDX_FB 9 >    c84000     cc43ff      403ff    DECW$TRANSPORT_LOCAL : >    cc6000     e479ff     1819ff    DECW$TRANSPORT_DECNET- >    e48000     e4bfff       3fff    DECC$MSG . >    e4c000     e529ff       69ff    SHRIMGMSG6 >    e54000     e641ff      101ff    DECW$TRANSPORTMSG. >    e66000     e739ff       d9ff    DBGTBKMSG9 >    e74000     eb43ff      403ff    DECW$TRANSPORT_TCPIP ; >    eb6000     f169ff      609ff    DECW$SERVER_DDX_RADEON 4 >   100c000    105c5ff      505ff    DECW$SERVER_DRI: >    f9a000    100a9ff      709ff    DECW$SERVER_DDX_CFB32: >    f18000     f989ff      809ff    DECW$SERVER_DDX_CFB162 >   b8a0000    b9415ff      a15ff    TCPIP$IPC_SHR5 >   b942000    b9e29ff      a09ff    TCPIP$ACCESS_SHR 0 >   ba5e000    baff5ff      a15ff    UCX$IPC_SHR- > 104de000   104f43ff      163ff    TCPIP$MSG  > $ > Exception Call stack dump follows: > # >       PC     IMAGE+offset of call # >       --     -------------------- ' >     e5e98     DECW$SERVER_DIX + b3e98 ' >     e59c4     DECW$SERVER_DIX + b39c4 ' >    12ea14     DECW$SERVER_DIX + fca14 ' >    12fae8     DECW$SERVER_DIX + fdae8 ( >    1321f8     DECW$SERVER_DIX + 1001f8( >    142fa4     DECW$SERVER_DIX + 110fa4' >   1040988     DECW$SERVER_DRI + 34988 ' >     dc37c     DECW$SERVER_DIX + aa37c ' >     916a4     DECW$SERVER_DIX + 5f6a4 ' >     90be8     DECW$SERVER_DIX + 5ebe8 ' >     d46c8     DECW$SERVER_DIX + a26c8  > : > ********** marking the end of call stack dump **********: > ********************************************************   ------------------------------    Date: 24 Nov 2006 05:06:15 -0800 From: etmsreec@yahoo.co.uk& Subject: Re: DECW$SERVER crashes (8.3)C Message-ID: <1164373575.199093.297240@j72g2000cwa.googlegroups.com>    It was a joke...  F I doubt that it's related to the hardware platform.  I've used variousF web browsers on various different AlphaServers/AlphaStations and neverE had any problems, other than the main window becoming pixellated when E running CSWB on just about any hardware platform that uses the native ? graphics on the Alpha - e.g. the VGA console on an AS1000A, the ! PMAGD-AA on a DEC 3000 model 600.   G I'd check your quotas and also check the PQLMx parameters on the system 7 to make sure that you're getting enough process quotas.    Steve    JF Mezei wrote:  > etmsreec@yahoo.co.uk wrote: 0 > > Maybe it's the thumbwheel on your mouse? :o) > M > Nop... not yet !  The crashes I reported happened before thumbwheel support F > was added. I'll keep my eyes opened to see if/when it happens again. >  > G > I think that this may be a taste of things to come with VMS hopefully K > moving to industry standard hardware where stability may not be something B > that is as easy to achieve as it was with good old VAX hardware.   ------------------------------  + Date: Fri, 24 Nov 2006 12:43:21 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)5 Subject: Re: increase in spam and what to do about it $ Message-ID: <ek6pd9$k46$1@online.de>  E In article <dt6dnSEDN-NS-vnYnZ2dnUVZ_rKdnZ2d@libcom.com>, Dave Froble  <davef@tsoft-inc.com> writes:   L > > Whether a PC running an OS which is so easily compromised is "innocent"  > > is a different question. > I > Sorry, while I may agree with the concept, I have to jump all over you   > on this one. > I > Just because you might look like an easy target, is that justification   > for you to be mugged?  > ? > If a young lady wears a miniskirt, is she asking to be raped?  > . > Blaming the victims really isn't the answer.  D I agree, of course.  On the other hand, I think it IS fair to blame 
 Microsoft.   ------------------------------    Date: 24 Nov 2006 06:17:36 -0800$ From: "AEF" <spamsink2001@yahoo.com>5 Subject: Re: increase in spam and what to do about it C Message-ID: <1164377856.802850.208350@h54g2000cwb.googlegroups.com>    Dave Froble wrote:1 > Phillip Helbig---remove CLOTHES to reply wrote: E > > In article <7d7b6$45639ef8$cef8887a$10159@TEKSAVVY.COM>, JF Mezei * > > <jfmezei.spamnot@teksavvy.com> writes: > > P > >> Researchers found evidence that about 73,000 computers in 166 countries areM > >> part of the SpamThru botnet, adding up to a mighty spam cannon. (This is L > >> some virus which transform an innocent PC in to a member of a centrallyM > >> controlled spamming network whene central servers provide templates etc.  > > K > > Whether a PC running an OS which is so easily compromised is "innocent"  > > is a different question. > >  > H > Sorry, while I may agree with the concept, I have to jump all over you > on this one. > H > Just because you might look like an easy target, is that justification > for you to be mugged?  > ? > If a young lady wears a miniskirt, is she asking to be raped?  > . > Blaming the victims really isn't the answer. >  > --6 > David Froble                       Tel: 724-529-0450@ > Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com > DFE Ultralights, Inc.  > 170 Grimplin Road  > Vanderbilt, PA  15486   E So if someone builds you a house with a defective roof, and it rains, G and the rain gets in your house, are you going to blame the rain? (Just : in case anyone is wondering, I'd blame the house builder.)  F If someone house-sits for you, and they leave the house for a few daysB with the front door wide open, and your house gets robbed, are youD going to hold the house-sitter *entirely* blameless? (I'd blame both" the house-sitter and the burglar.)  C It's easy to shoot anyone. But I wouldn't blame the victim of being & shot just for walking down the street.  + Three analogies -- three different answers.    AEF    ------------------------------  + Date: Fri, 24 Nov 2006 14:30:58 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk5 Subject: Re: increase in spam and what to do about it , Message-ID: <ek6vn2$i1u$1@south.jnrs.ja.net>  _ In article <06112208494376_2020028F@antinode.org>, sms@antinode.org (Steven M. Schweda) writes: Q >From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)  > 0 >> > >   Are the entries on the list only those P >> > > who have sent spam, or do they include for example ranges of volatile IP  >> > > addresses?  >> >  / >> >    Probably depends on whose list you use.  >>    >> Which lists do you recommend? > H >   I don't pay enough attention to _recommend_ any, but I'll admit that9 >I use these (from SYS$SPECIFIC:[TCPIP$SMTP]SMTP.CONFIG):  > ; >RBLs: relays.ordb.org, dnsbl.sorbs.net, combined.njabl.org  > G Be wary of using dnsbl.sorbs.net. This is an aggregation of a number of L sorbs lists. Those dealing with open-relays, open proxies, dynamic addressesF etc are reasonable however there is a problem with the anti-spam lists: (new.spam.dnsbl.sorbs.net, recent.spam.dsnbl.sorbs.net and0 escalations.dsnbl.sorbs.net) which are included.O A number of popular ISP's central mailhubs are listed and because SORBS insists I on companies paying a $50 fine (to a recognised charity) before they will ? remove them from the spam lists many don't seem to get removed.   G If your mail software can deal with the different codes returned by the F individual lists then it is easy enough to just ignore the spam lists L (which all return 127.0.0.6). If not then be prepared for lots of complaints that people can't send to you.      
 David Webb Security team leader CCSS Middlesex University        H >   These organizations tend to have Web pages which explain how they doH >what they do, and which server to specify to get which things blocked. 0 >"combined.njabl.org", for example, differs from: >"<other_things>.njabl.org".  See "http://www.njabl.org/". > I >------------------------------------------------------------------------  > 4 >   Steven M. Schweda               sms@antinode-org5 >   382 South Warwick Street        (+1) 651-699-9818  >   Saint Paul  MN  55105-2547   ------------------------------    Date: 24 Nov 2006 02:46:46 -0800  From: francesco.gennai@gmail.com Subject: Re: JBOSSC Message-ID: <1164365206.781458.172420@j72g2000cwa.googlegroups.com>    Arne Vajh=F8j ha scritto:   # > francesco.gennai@gmail.com wrote: 9 > > Is there any JBOSS working installation on VMS IA64 ?  >  > I do not have an IA64 box. > : > But why should there be any difference for JBoss whether > it is Alpha or IA64 ?  >   8 I agree.... but to be more precise I would know if there? are any JBOSS installations/experiences in OpenVMS environment.   ( Then... we will need to work on Itanium.  
 Thank you.	 Francesco    > Java should encapsulate that.  >=20 > Arne   ------------------------------    Date: 24 Nov 2006 07:29:52 -0800) From: "DaveG" <david.gudewicz@abbott.com> 6 Subject: Re: Oracle 9i and VMS multihome configurationB Message-ID: <1164382192.355000.183780@m7g2000cwm.googlegroups.com>   Syltrem wrote:H > "DaveG" <david.gudewicz@abbott.com> a =E9crit dans le message de news:: > 1164213396.764195.190120@j44g2000cwa.googlegroups.com...F > > We recently enabled and started failSAFE IP ( 2 NICs ) on an AlphaJ > > v7.3-2 (patches up to date) system.  This system runs Oracle 9i and itH > > seems that Oracle only sees one of the 2 active IP addresses on thisG > > system, as it did before we enabled the second NIC and failSAFE IP. I > > Seems like failSAFE IP is not the issue here, but I include it in the E > > description for completeness.  failSAFE IP seems to be working as J > > advertised (nice feature btw) and our DNS servers have been updated toJ > > include the second IP address.  The Oracle listener has been restarted2 > > and Oracle is not aware of the second address. > > G > > Other people here have a call in to Oracle support, but while we're I > > waiting for a reply, I thought I'd ask here and discover if anyone is I > > running a similar configuration.  My guess is that Oracle needs to be H > > configured in some way to see both NICs/ IP addresses, but not being9 > > Oracle savy, I haven't a clue how that might be done.  > >  > > Dave...  > >  > 3 > You say that Oracle does not see the 2nd address. 3 > In what is this a problem? Pls explain the issue.   G In this dual homed configuration, we simply want Oracle to utilize both 
 IP addresses.   # > Are you running on a single node?   ) Yes, single node for now.  Cluster later.   C > Are you trying to start the listener or connect to the database ?   F Starting the listener and connecting to the database (with original IP address) are working fine.  " > What kind of problem do you see?  F Original IP address connection is fine, second IP address seems not to; be working with Oracle, I'm told by our application people.   L > And also explain what you are trying to accomplish by having 2 IP address= es.   E Load balancing (use both IP address) and failSAFE IP, no single point  of failure.    >    ------------------------------  % Date: Fri, 24 Nov 2006 08:40:22 -0800 , From: "Malcolm Dunnett" <dunnett@mala.bc.ca>6 Subject: Re: Oracle 9i and VMS multihome configuration Message-ID: <45671ff4$1@flight>   5 "DaveG" <david.gudewicz@abbott.com> wrote in message  < news:1164382192.355000.183780@m7g2000cwm.googlegroups.com...# >> What kind of problem do you see?  > G >Original IP address connection is fine, second IP address seems not to < >be working with Oracle, I'm told by our application people. >   H   You would need to modify LISTENER.ORA (in ORACLE_HOME:[NETWORK.ADMIN])' to tell it about the second IP address.   F    I've not actually done this for two IP addresses, but it should go  something like this. Your  original entry will look like:   LISTENER = (ADDRESS_LIST=          (ADDRESS =           (PROTOCOL = TCP)"           (HOST = myhost.mydomain)           (PORT=1521)            (QUEUESIZE=200) 	         )    )   B You need to add another address block, so it looks something like:   LISTENER = (ADDRESS_LIST=          (ADDRESS =           (PROTOCOL = TCP)"           (HOST = myhost.mydomain)           (PORT=1521)            (QUEUESIZE=200) 	         )          (ADDRESS =           (PROTOCOL = TCP)#           (HOST = myhost1.mydomain)            (PORT=1521)            (QUEUESIZE=200) 	         )    )    ------------------------------    Date: 24 Nov 2006 06:52:30 -0600B From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley)D Subject: Reloading Alpha drivers, was: Re: Mouse: thumbwheel support3 Message-ID: <eWWVJ5A+04Em@eisner.encompasserve.org>   g In article <21583$4566462c$cef8887a$2446@TEKSAVVY.COM>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:  > Tim Sneddon wrote:J >> A driver was built (thanks Fred) and someone to host it was found. V8.3M >> and V7.3-2 versions of the mouse driver, as well as some instructions, are  >> now available at: >  >  > Many thanks !  > * > Now, the big question: *must* I reboot ? > L > (I ask this more with a goal of learning about managing drivers on Alpha, Q > aka: is there a way to reload a driver with a new version without rebooting ?).  >   M Later messages have pointed out that you need to reboot to reload the driver. H In case you are interested, the issue of reloading drivers under VMS has( been raised before, including by myself.   Search Google Groups for:   / 	group:comp.os.vms "simon clubley" alpha reload   # and read the threads if interested.   K BTW, reloading device drivers (if they are not compiled into the kernel) is  a standard capability in Linux.   E You would not believe how much time that saves when you are trying to 2 correctly interpret a badly written datasheet. :-)   Simon.   --  ; Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP K If Google's motto is "don't be evil", then how did we get Google Groups 2 ?    ------------------------------    Date: 24 Nov 2006 00:52:40 -0800! From: "Ian Miller" <gxys@uk2.net> : Subject: Re: SYSTEM-F-INFSMEM, insufficient dynamic memoryB Message-ID: <1164358360.766851.109390@45g2000cws.googlegroups.com>   interesting.B IIRC There is a difference on alpha  LDR$WRAPUP runs at the end of# startup and on itanium it does not.    ------------------------------    Date: 24 Nov 2006 06:09:30 -0800$ From: "AEF" <spamsink2001@yahoo.com>: Subject: Re: SYSTEM-F-INFSMEM, insufficient dynamic memoryB Message-ID: <1164377370.800385.133040@45g2000cws.googlegroups.com>   Malcolm Dunnett wrote:D > "Robert Deininger" <rdeininger@mindspringdot.com> wrote in messageW > news:rdeininger-2311060938380001@dialup-4.233.173.196.dial1.manchester1.level3.net...  > E > >>It doesn't seem to make much sense - maybe it's a bug in VMS 8.3?  > >  > > I'm starting to think so.  > > F > > This is the 3rd or 4th similar report I've heard, all on I64 V8.3.M > > SYSTEM-F-INSFMEM in every case, but different components have problems on M > > different systems.  If your system is having trouble with TCPIP, it would L > > be interesting to SET VERIFY before running the startup.  Can you narrowG > > down the point of failure?  The other instances I've seen have been B > > attempting a SYSMAN IO CONNECT to load a pseudo device driver. > >  > H >    I'VE FOUND THE PROBLEM (sorry, just had to shout - it's been 2 days
 > of work)  B No problem. I like upper case letters. An occasional burst of themA reduces the MONOTONY of endless lower case letters. BRAVO, I say! B Besides, you're "shouting" with joy, not scolding anyone! It's OK.   [...]    AEF    ------------------------------  % Date: Fri, 24 Nov 2006 08:14:20 -0800 , From: "Malcolm Dunnett" <dunnett@mala.bc.ca>: Subject: Re: SYSTEM-F-INFSMEM, insufficient dynamic memory Message-ID: <456719d9$1@flight>   ; "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message  - news:ZYVUt35do3e5@eisner.encompasserve.org... = >>>     I realize that, but I thought I should give it a try.  >>7 >> Now why would you have such a lapse in common sense?  >>H >> I realize there can be reasons to run Phase 5, but if you do not have5 >> one of these reasons,  my question is appropriate.  > I > Getting experience running it seems like a good reason, taking time now D > against the day when one of those business-critical needs arrives.  A That's pretty much my reason. These systems are development boxes F where I'm investigating porting our applications to Itanium. I thoughtC after all these years of  Phase V being out there I should see what I it's all about. I'm also cognizant of the fact that Phase IV is no longer A supported without a special support addendum, which I don't have. J I know it's very stable and that's not likely to be an issue, but still...  C Our network is not multiprotocol routing, it's IP only. The ability > to run DECNet over IP interests me - I currently have a couple7 of DECNet Phase IV nodes at another campus which I link 8 to using the DECNET over IP feature of Multinet, but I'm< interested in how that compares to the capability in Phase V  C In any case it appears in the end this is not specifically a DECNet > problem (see my last posting), it could potentially affect any= system code, it just happens to be the installation of DECNet  that triggered it here.    ------------------------------    Date: 24 Nov 2006 09:03:23 -0800- From: "Doug Phillips" <dphill46@netscape.net> & Subject: Re: Testing for mobile deviceB Message-ID: <1164387803.477706.190380@m7g2000cwm.googlegroups.com>   JF Mezei wrote:  > David Gray wrote: I > > Yes the users are connecting via Telnet and will be in a captive menu F > > environment.  Basically the users connecting via the handheld willF > > access a cutdown menu system which is designed for a small screen. > L > If the screen size is what counts, then SET TERM/INQUIRE *should* give youI > the device characteristics for page width and page size. But not all VT ! > emulators handle this properly.  > L > after SET TERM/INQUIRE, do a SHOW TERM and it will show you what it thinksM > your terminal size is. If one of the two devices does not respond properly, I > you can cue into this and assume the user is using such a device when a  > similar response come back.  > < > The lexical F$GETDVI("TT:","DEVBUFSIZ") gets you the witdh > K > The lexical F$GETDVI("TT:","TT_PAGE") gets you the page length (number of  > lines)  F Many of the small-screen handhelds with VT emulators hold a full 80x24F screen in memory, and allow you to pan the smaller display area aroundA the memory screen. On some, the pan will automatically follow the F cursor. Awkward for most applications. The emulators report back 80x24( even though the display area is smaller.  D For inventory or production related applications the small screen isA usually sufficient for operator prompting and most often input is E scanned rather than keyed. It's better to design this special purpose G program to use the small display area rather than pan the window around # a screen designed for a full 80x24.    ------------------------------  % Date: Fri, 24 Nov 2006 09:21:14 +0100 ( From: MIchael Kraemer <M.Kraemer@gsi.de>= Subject: Re: Thoughts on the book: DEC is dead, long live DEC / Message-ID: <ek6a0c$hl1$00$1@news.t-online.com>    William Pechter schrieb: > G > Unless you ran AT&T Unix boxes and needed TCP/IP which was extra from  > Lachman or whomever... > F > The 3B series charged $$$ for TCP/IP.  As did Concurrent's OS/32 and > Xelos. > H > The only folks who charged $0 for TCP/IP connectivity were workstation7 > users who got their start with the BSD distributions.    and that was when ? 197x ?> All major, economically relevant Unices have network (and gfx)4 as integral part of the OS since at least the 1990s.   ------------------------------   Date: 24 Nov 2006 11:54:31 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)= Subject: Re: Thoughts on the book: DEC is dead, long live DEC 0 Message-ID: <4so4rnF10e3ioU1@mid.individual.net>  / In article <ek6a0c$hl1$00$1@news.t-online.com>, + 	MIchael Kraemer <M.Kraemer@gsi.de> writes:  > William Pechter schrieb: >>  H >> Unless you ran AT&T Unix boxes and needed TCP/IP which was extra from >> Lachman or whomever...  >>  G >> The 3B series charged $$$ for TCP/IP.  As did Concurrent's OS/32 and 	 >> Xelos.  >>  I >> The only folks who charged $0 for TCP/IP connectivity were workstation 8 >> users who got their start with the BSD distributions. >  > and that was when ? 197x ?  G Hardly.  That was the case all the time the 3B series was sold.  (I got H mine in between 1981-1984.) And, it included the 3B1 which wasn't really a 3B at all.  @ > All major, economically relevant Unices have network (and gfx)6 > as integral part of the OS since at least the 1990s.   E Which is only a valid statement if you get to pick which are relevant D and which are not.  AT&T and Convergent were surely relevant and didC not include TCPIP with their products.   And in the case of AT&T it C was not only the 3B's, but the other versions of Unix as well, like  for the VAX.   bill     --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  # Date: Fri, 24 Nov 2006 17:20:02 GMT ' From: ChrisQuayle <nospam@devnul.co.uk> = Subject: Re: Thoughts on the book: DEC is dead, long live DEC 7 Message-ID: <6RF9h.20167$0x.12442@newsfe1-win.ntli.net>    Neil Rieck wrote:   F > I think some people in our industry might be missing the point. The J > internet, since 1995, is changing everything in ways many people in our N > business still don't understand. So since 1995 machines that don't have the N > potential of connecting to the internet (either directly or indirectly) are  > worthless. >   C Quite; A TCP/IP stack should be part of the base os for any modern  I operating system worthy of the name. Still, I guess the whole world must   still talk Decnet yes ?.  G Even Win95 had a usable tcp/ip stack included as standard and that was   over ten years ago.   ! Laughable, if it wasn't so sad...    Chris    ------------------------------  + Date: Fri, 24 Nov 2006 18:49:55 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) = Subject: Re: Thoughts on the book: DEC is dead, long live DEC ( Message-ID: <ek7esj$3ro$1@pcls6.std.com>  4 pechter@pechter.dyndns.org (William Pechter) writes:  , >In article <44F55360.7B68939@teksavvy.com>,0 >JF Mezei  <jfmezei.spamnot@teksavvy.com> wrote: >>I >>In the book, the image is given that DEC engineers had carte blanche to G >>develop superior products at any cost. I think that DSSI is a perfect D >>example of this. Instead of focusing on the existing SCSI standardJ >>(remember that SCSI was in widespread use by Apple back in 1984 when theH >>MAC was launched), they decided that SCSI was not perfect and designed+ >>their own "improved" version called DSSI.  >>  2 >I think DSSI was invented after SASI -- not SCSI.  A >I think RA8x drives before '84 and I think the UDA50 was earlier H >as well.  The UDA50 and RA stuff went through a serious period of ECO'sJ >and modifications  (IIRC) in the 84 timeframe as bugs were worked out andE >the newer boards hit the field when the stuff became more available.   I DSSI is electrically SCSI-1.  Signal levels and so forth were the same.   D DSSI and SCSI were so close that one of the earliest Alphas, the oneH codenamed "Cobra" had 5 SCSI/DSSI busses.  One was permanently SCSI, theD other 4 could be either DSSI or SCSI depending on which bulkhead wasG attached to them.  The firmware didn't even know if the bus was SCSI or K DSSI unless either a SCSI or DSSI device was attached to it!  The firmware  H called the ports Pxy0: where x was either "I" (DSSI), "K" (SCSI) or "_" $ (didn't know).  (y was a letter A-E)  H The DSSI protocol was different, it was Digital-specific, SCS sat on top? so VMS would talk to DSSI disks as if the drives has little HSx G controllers in them, and VMS could cluster over the DSSI bus just as it  could over CI.   ------------------------------  # Date: Fri, 24 Nov 2006 11:38:20 GMT + From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= ) Subject: Tracking down a process in MUTEX 2 Message-ID: <MQA9h.24162$E02.9644@newsb.telia.net>  $ Just a quick question on MUTEX'es...  . Is there any new "tools" in later VMS versions0 (8.2 Alpha in this case) to track down a process locked in MUTEX ?   . In this case it's a batch process that hanged.2 when doing a DEL/ENT the entry is removed from the- queue but the process remains in MUTEX and is 4 more or less "dead". Can't do a SHO PROC/CONT on it.  8 It *seams* as the process hanged on a TELNET REMOVE nnnn( command to remove a TNAnnnn device/port.  7 Just hoping for a "quick-start" on this, since hangs on ( MUTEX'es aren't that common after all...  
 Best Regards, 	 Jan-Erik.    ------------------------------    Date: 24 Nov 2006 09:14:10 -0800/ From: "Volker Halle" <volker_halle@hotmail.com> - Subject: Re: Tracking down a process in MUTEX C Message-ID: <1164388449.904560.247470@h54g2000cwb.googlegroups.com>   	 Jan-Erik,   < if this problem is somehow reproducable, you can trace MUTEX> allocations and de-allocations with the MTX$SDA SDA extension:  
 $ ANAL/SYS SDA> MTX ! to display HELP
 SDA> MTX LOAD  SDA> MTX START TRACE    wait until problem has happened.   SDA> MTX STOP TRACE  SDA> MTX SHOW TRACE  SDA> MTX UNLOAD   G If a process is hung in MUTEX state, the field PCB$L_EFWM in the PCB of F this process contains the address of the mutex it is waiting for. If aG process is waiting for a mutex, another process in the system should be F owning that mutex. To find that other process, you need to look at allE processes with prio 16 and Mutex count > 0. If you find one, you need E to find out, why that process does not make any progress. If there is G none, you've found a mutex allocation/de-allocation bug and you need to < apply the above tracing method to try to capture evidence...  B Ian Millers PWAIT$SDA extension will at least show the name of the MUTEX.   --- , Volker Halle, Invenate GmbH, OpenVMS Support  # An OpenVMS crashdump analysis a day $ makes the Windows headaches go away.   ------------------------------   End of INFO-VAX 2006.647 ************************