1 INFO-VAX	Tue, 22 Aug 2006	Volume 2006 : Issue 467       Contents:% Re: ANN: DynDNS update client for VMS 1 DECwindows 1.3-1: Sporadic "backward arrow" issue  Re: Dibol programmers  MONITOR CLUSER - oddity  Re: MONITOR CLUSER - oddity  Re: On-chip, 7-way associativeA Re: openvms - java - timezone - daylight savings - what the heck! A Re: openvms - java - timezone - daylight savings - what the heck!  PDF parser on VMS ?  Re: Personal note - goodbye !  Re: Personal note - goodbye ! 4 Please participate in a non-profit academic research2 Re: SEPPUCLU bugcheck introducing new cluster node2 Re: SEPPUCLU bugcheck introducing new cluster node2 Re: SEPPUCLU bugcheck introducing new cluster node2 Re: SEPPUCLU bugcheck introducing new cluster node2 Re: SEPPUCLU bugcheck introducing new cluster node2 Re: SEPPUCLU bugcheck introducing new cluster node2 Re: SEPPUCLU bugcheck introducing new cluster node2 Re: VGA video adapter for Vaxstation 4000 model 602 Re: VGA video adapter for Vaxstation 4000 model 602 Re: VGA video adapter for Vaxstation 4000 model 602 Re: VGA video adapter for Vaxstation 4000 model 60  F ----------------------------------------------------------------------  % Date: Tue, 22 Aug 2006 17:05:38 +0930 * From: Mark Daniel <mark.daniel@vsm.com.au>. Subject: Re: ANN: DynDNS update client for VMS0 Message-ID: <12elgg73f5gn3a6@corp.supernews.com>   David J. Dachtera wrote: > Mark Daniel wrote: >  >>David J. Dachtera wrote: >> >>>Mark Daniel wrote:  >>>  >>> / >>>>Recent discussion of a DynDNS update client  >>>>0 >>>>  http://www.dyndns.com/services/dns/dyndns/ >>>>K >>>>in this forum prompted me to do something I'd been meaning to for years K >>>>- put together a native version for VMS and move the update duties from H >>>>my PC to my VMS system.  It has now been running for some four weeksJ >>>>without too many hiccoughs so you are welcome to give it a go as well.E >>>>It requires the HP [Open]SSL product to be installed and started.  >>>>H >>>>A complementary application included, DynDNSrpt, is a CGI Web serverH >>>>application that can be used as a basic reporting tool for the aboveH >>>>application (should be suitable for Apache, OSU, Purveyor and WASD). >>>>K >>>>Setup, build instructions and revision log for each may be found in the B >>>>source code each of the respective applications once restored. >>>>< >>>>A ZIPed source-code kit (it is assumed users will be VMSD >>>>enthusiasts/hobbiests with their own compiler) is available from >>>>" >>>>  http://wasd.vsm.com.au/wasd/ >>>> >>>>Hope it's useful.  >>>  >>> C >>>Just wondering if this has any advantage over the WGET approach?  >>F >>Don't know David.  I'm aware of the DCL-based utility that uses WGETH >>because of the recent discussion here that mentioned it.  I didn't useF >>it as a reference when putting together my own though and so I'm not% >>aware of what it can (or can't do).  >  > 1 > As I use it, the WGET approach works like this:  > J > 1. "Visit" a URL that returns "your" IP address as viewed by the outside > world (the internet).  > : > 2. "Visit" a second URL that causes the update to occur. > . > A little bit of DCL in between does the job.   That's the gist.  # There's a bit more to it of course.   B DynDNS' specifications have a number of policies regarding client C behaviour.  These, amongst other requirements, limit the number of  H accesses to their web-based client IP identification service in a given F period, and require that the update service only be accessed when the E client's IP address has actually changed.  Poor client behaviour can  C result in being blocked by DynDNS (someone has reported to me this  E happened to them when a local modification to their VMS-based client  G made it a little too eager to keep DynDNS informed :-)  Various DynDNS  A update service responses should be parsed and behaviour modified   appropriately.  And so forth.   A Of course there are other bells-and-whistles that make the basic  D functionality of any application more useful or pleasant to use and  DynDNSupd is no different.  = The 80-20 rule (or variant) applies here as much as anywhere.    ------------------------------    Date: 22 Aug 2006 06:24:11 -0700) From: "Joe Sewell" <ultrajoe@spamcop.net> : Subject: DECwindows 1.3-1: Sporadic "backward arrow" issueB Message-ID: <1156253051.632559.214010@i3g2000cwc.googlegroups.com>  C Ever since we upgraded to DECwindows/Motif V1.3-1, we've seen cases F where our application gets "stuck" with a "backward arrow," indicativeE of a passive grab that isn't being processed. Nobody has been able to A reproduce it reliably, but our customer tells us it happens "more $ often" with the most recent release.  H Is there anything I can look for that we may be doing wrong in our code?   ------------------------------    Date: 22 Aug 2006 07:56:06 -0700' From: "bclaremont" <msi1@earthlink.net>  Subject: Re: Dibol programmersB Message-ID: <1156258566.195579.95560@b28g2000cwb.googlegroups.com>  $ Warning: Shameless Self Promotion...  > I provide DIBOL consulting services.  I also sell a DIBOL to CC converter, should the need arise.  More information is available at  these links:  0 Home Page: http://www.migrationspecialties.com/. Programming Services: = http://www.migrationspecialties.com/Services.html#Programming B CBL: DIBOL Converter: http://www.migrationspecialties.com/CBL.html   ***  Improved with Age  - Wine - Wisdom	 - OpenVMS    Mr. Bruce Claremont  www.MigrationSpecialties.com   ------------------------------  % Date: Tue, 22 Aug 2006 09:43:05 -0500 + From: brandon@dalsemi.com (BRANDON, JOHN M)   Subject: MONITOR CLUSER - oddity1 Message-ID: <06082209430578@dscis6-0.dalsemi.com>   N I have a three node cluster - 2 each DS20 (2x CPU) and 1 each ES40 (4x CPU) - A call these nodes DS1, DS2, and ES1 - all three running VMS V7.2-1   M From each of these nodes I do a MONITOR CLUSTER - during peak processing time * when all servers are at 100% CPU capacity.  
 DS1 shows:   DS1 = 200%   DS2 = 200%   ES1 = 400%  
 DS2 shows:   DS1 = 200%   DS2 = 200%    ES1 = 200% <-- note the oddity  
 ES1 shows:   DS1 = 200%   DS2 = 200%   ES1 = 400%    C As expected, DS1 and ES1 show the capacity of each server properly. L For example, a 2x CPU is at 100% capacity it shows 200%, a 4x CPU is at 100% capacity it shows 400%.   E However DS2 shows ES1 at a peak of 200% when ES1 is actually at 400%.   P Any thoughts why DS2 mis-represents the peak of CPU activity for a 4 CPU server?       John "REBOOT" Brandon  VMS Systems Administrator * firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  # Date: Tue, 22 Aug 2006 15:11:23 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>$ Subject: Re: MONITOR CLUSER - oddity. Message-ID: <v8FGg.53$aC1.24@news.cpqcorp.net>   BRANDON, JOHN M wrote:  R > Any thoughts why DS2 mis-represents the peak of CPU activity for a 4 CPU server?  @    Three letters.  Another term for an insect.  Rhymes with mug.   ------------------------------  # Date: Tue, 22 Aug 2006 11:35:31 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) ' Subject: Re: On-chip, 7-way associative Z Message-ID: <rdeininger-2208060735400001@dialup-4.233.173.91.dial1.manchester1.level3.net>  G In article <EfadnZeFg-2t1nfZnZ2dnUVZ_s6dnZ2d@metrocastcablevision.com>, ) Bill Todd <billtodd@metrocast.net> wrote:    >BRANDON, JOHN M wrote: ; >> Can anyone explain what "On-chip, 7-way associative" is?  > E >It refers to the level of associativity of EV7's 1.75 MB on-chip L2  D >cache (in my foggy understanding, the number of different places a F >specific cache line can occupy without collision, depending upon the G >existence of other cache lines in the cache with addresses that would  * >otherwise map to the same cache address). >  >... > G >> From what I have read so far (various sites) is better performance - 	 however I L >> find it difficult to beleive that 1.75 cache per processor is better than >> 16-MB cache per processor.  > J >As usual, 'it depends'.  In fact, EV7 has slightly (but *only* slightly) F >worse performance than EV68 with 16 MB of fast board-level L2 at the G >same clock rate in SPECint:  having only about 1/9th as much cache is  H >significantly offset by the approximate halving in cache latency (to a F >latency of about 10 ns. for EV7, while the off-chip EV68 L2 was IIRC I >close to 20 ns. and also direct-mapped - single-way-associative - which  C >further decreased its relative effectiveness) and the approximate  J >halving of main-memory latency (from about 160 ns. with EV68 to about 80  >ns. with EV7 IIRC).   ES45 CPUs come in 2 flavors:F 1    GHz CPUs with  8 MB of L2 cache/CPU  (32 MB maximum system cache)F 1.25 GHz CPUs with 16 MB of L2 cache/CPU  (64 MB maximum system cache)G The ES45 L2 cache is on the CPU board, but not on the CPU chip.  Any of ; the CPUs can access the whole system's cache at full speed.   F I don't think the ES45 memory latency is as bad as you remember, but II don't have the numbers at my fingertips.  ES47 memory latency is slightly : better than ES45; I don't remember it being twice as fast.  I We've certainly seen workloads where ES45 beats ES47, and vice versa.  It F turns out a lot of real-world work fits in the ES45 cache, but not the ES47 cache.   C >While the effects of cache vary considerably with workload (e.g.,  H >workloads experience a step-function increase in performance when they J >fit *entirely* in cache or nearly so), on average the cache miss rate is F >roughly inversely proportional to the square root of the cache size. E >Thus one would expect on average (though not necessarily in SPECint  H >specifically) that EV7's miss rate would be about 3x that of EV68 with J >16 MB of off-chip L2, but that both EV7's L2 cache hits and its L2 cache J >misses to main memory (at least to local RAM) would be close to twice as  >fast. > C >Overall, EV7 was a tremendous improvement over EV68 despite using  @ >virtually the same core - primarily due to its vastly-superior J >large-system architecture (where even the worst-case latency to the most J >distant NUMA RAM was only about 1/3 the *average* latency in GS320-class H >systems, and the *average* EV7 large-system latency was of course even F >better).  Moving to that architecture pretty much required moving to F >on-chip caches, even though they had to be relatively small to start I >with (of course, had Alpha been shrunk as originally scheduled feasible  9 >on-chip cache sizes would have increased significantly).   H Yes, EV7 is optimized for large systems, and turned out beautifully.  It' isn't cost-effective for small systems.   C ES45 uses a chipset optimized for small systems and lower cost.  It F doesn't scale past 4 CPUs.  In this size system, large caches are very0 effective in terms of both cost and performance.  H GS320-class systems don't use the ES45 chipset, and they have much worse( memory performance at every system size.  D GS320-class systems don't use EV68 CPUs, BTW.  They use EV6 or EV67.  J >So for single-processor workloads which are 'cache-friendly' EV7 is only J >about on a par with EV68 plus 16 MB of off-chip L2 (though even there by I >virtue of eliminating a bunch of other board components EV7 is likely a  , >considerably more cost-effective design).    J Yes, ES45 has a few memory and cache ASICs that add up to perhaps a coupleI of hundred dollars of cost per system.  But EV68 CPUs are around half the I cost of EV7.  And the cables and connectors that link together EV7 system I boxes are FAR more expensive than the ES45 chipset.  Alpha system volumes F were never big enough to get significant economies of scale from stuff? like ASICs, where the development and test costs are huge.  The I low-hanging fruit for cost savings was usually stuff like power supplies, ! connectors, and cable assemblies.      >But for larger-system  J >workloads or those which depend much more on main-memory latency than on B >cache performance, EV7 is a *major* win.  Oh, yes - large-system D >workloads which depend upon system internal bandwidth are also far 5 >better addressed by EV7 than by EV68 system designs.   D Pretty much correct.  (Though there aren't any large EV68 systems.) J Design improvements and bug fixes between EV67 and EV68 would have allowedI a hypothetical EV68-based GS320 to outperform the existing one somewhat.  9 But still terrible memory performance compared to GS1280.    ------------------------------  % Date: Tue, 22 Aug 2006 06:57:28 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> J Subject: Re: openvms - java - timezone - daylight savings - what the heck!< Message-ID: <44eae1d5$0$24200$9a6e19ea@news.newshosting.com>  # <troy@makaro.com> wrote in message  ; news:1156217947.227394.37460@74g2000cwt.googlegroups.com... D > Please help, I have been searching on the internet all day for the: > answer to why java times are off by one hour on openvms. > + > Here is how my timezone is currently set:  > - > MAKAROSOFT>@sys$manager:utc$time_setup show  >   > AUTO_DLIGHT_SAV is set to "1".A > OpenVMS will automatically change to/from Daylight Saving Time. / > (in time zones that use Daylight Saving Time)  > A >    LOCAL TIME ZONE          = CANADA / PACIFIC -- DAYLIGHT TIME = >    LOCAL SYSTEM TIME        = 21-AUG-2006 20:21:20.07 (PDT) % >    TIME DIFFERENTIAL FACTOR = -7:00 = >    TIME ZONE RULE           = PST8PDT7,M4.1.0/02,M10.5.0/02 C >    Change PST to PDT on the First Sunday of April (2-Apr-2006) at  > 02:00 E >    Change PDT to PST on the Last Sunday of October (29-Oct-2006) at  > 02:00  >  > : > The above looks fine and when I enter 'show time' I get: >  > MAKAROSOFT>sh ti >  21-AUG-2006 20:24:27  > F > This time is correct too. But when I run my java test program I get: >  > MAKAROSOFT>java "Test"8 > Mon Aug 21 19:25:51 GMT-08:00 2006  ?????????????????? >  > My test program looks like:  >  > MAKAROSOFT>ty test.java  >  > import java.util.Date; > public class Test { 2 >        public static void main (String[] args) {0 >                System.out.println(new Date());
 >        } > }  >  > my java version is:  >  > MAKAROSOFT>java -version > java version "1.4.2"2 > Java(TM) 2 Runtime Environment, Standard EditionI > Fast VM (build 1.4.2-4.p5, build J2SDK.v.1.4.2:11/23/2005-04:19, native  > threads, jit_142)  > " > OpenVMS version is: OpenVMS V8.2 >   > So what the heck am I missing? > J It looks like your VMS date is currently displaying PDT (Pacific Daylight L Time) which will drop back an hour on 29-Oct-2006 when your system switches $ back to PST (Pacific Standard Time).   According to this reference:; http://java.sun.com/j2se/1.4.2/docs/api/java/util/Date.html F you need to run the output through method DateFormat.format(Date date)    
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada." http://www3.sympatico.ca/n.rieck/    ------------------------------    Date: 22 Aug 2006 07:41:19 -0700) From: "troy@makaro.com" <troy@makaro.com> J Subject: Re: openvms - java - timezone - daylight savings - what the heck!B Message-ID: <1156257679.525010.57650@h48g2000cwc.googlegroups.com>  E Unfortunately using SimpleDateFormat.format() still displays the time  off by one hour :(   ------------------------------  % Date: Tue, 22 Aug 2006 03:10:40 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>  Subject: PDF parser on VMS ?, Message-ID: <44EAADD8.A8A78B24@teksavvy.com>  E I'd like to stuff a whole bunch of PDF documents in a folder and have D some utility parse the PDF files to extract the document informationF (title, author, dates etc) and then index the documents in ALL-IN-1 soH that they can be accessed intelligently does ( EK-KA630-UG-001_Feb86.pdf)  really tell you what the contents are ?)   > Is this an easy task or does it require I worl with 90% of the3 GHOSTSCRIPT code to just extract that information ?    ------------------------------  + Date: Tue, 22 Aug 2006 10:22:03 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk& Subject: Re: Personal note - goodbye !, Message-ID: <ecelsb$mjv$1@south.jnrs.ja.net>  \ In article <44EA099B.6EBDEF4C@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: >Guy Peleg wrote: M >> I wanted to let you know that I have decided to leave HP (I chose to leave  >> on L >> my own). I have been part of DEC/CPQ/HP for almost 10 years, 6 of them in >> VMS engineering.  >  > * >How dare you leave us like this ????? :-) > G >Who will replace you to make all the updates to DCL that you have made  >over the years ?????????  > 6 >You'll be missed ! You are leaving big shoes to fill. >  > 1 >> I'm going to work with Bruce Ellis at BRUDEN.   > 3 >Well, at least you're staying in the VMS arena....  > F >BTW, if you ever meet Bruce's wife, tell her that JF from Canada says6 >hello ! (she used to be DECUS Canada office manager).   Guy,  7 Sorry to see you go. All your work is much appreciated.     
 David Webb Security team leader CCSS Middlesex University   ------------------------------  % Date: Tue, 22 Aug 2006 20:57:22 +1000 $ From: Phaeton <phaeton@iinet.net.au>& Subject: Re: Personal note - goodbye !I Message-ID: <44eae30f$0$4183$5a62ac22@per-qv1-newsreader-01.iinet.net.au>    Guy Peleg wrote: > Dear community,  > L > I wanted to let you know that I have decided to leave HP (I chose to leave > onK > my own). I have been part of DEC/CPQ/HP for almost 10 years, 6 of them in  > VMS engineering. > I > I want to thank this forum for all the feedback provided to me over the  > years.J > Look at recent VMS releases (V8.2 and upcoming V8.3) and I'm sure you'llH > be able to see the tremendous impact this forum had (especially in the > utilities  > area). > F > I'm going to work with Bruce Ellis at BRUDEN. The company is growingE > and I'll be responsible for the business in Europe. BRUDEN provides H > training, services and consulting for VMS and other O/S's (guess whichI > area I'll be working on ;-) so there is a good chance you'll be hearing  > more from me.  > C > My new email starting September 1st will be guy.pelegATbruden.com   < 	Thank you for all the excellent work, Guy ! All the best in> 	your future endeavours. Don't forget this group, drop in time! 	to time, for old time's sake :-) ?                                                Cheers,    Csaba   E --------------------------------------------------------------------- F   CSABA I. HARANGOZO  |d|i|g|i|t|a|l|  phaeton at iinet dot net dot auE --------------------------------------------------------------------- <     EARTH::AUSTRALIA:[SYDNEY]HARANGOZO.CSABA;1, delete? [N]:  <   Circumvent (n.), the opening in the front of boxer shorts.   ------------------------------    Date: 22 Aug 2006 03:49:43 -0700 From: cttvivi@hotmail.com = Subject: Please participate in a non-profit academic research B Message-ID: <1156243783.739891.317750@i3g2000cwc.googlegroups.com>  	 Dear all:   A We are researchers from Shih Hsin University and we are currently D launching the 2006 New Energy and Environmental Media Issues Survey,E this is a non-profit academic research. In this survey, we would like D to know your opinions about the topics of adoption and safety of new@ energy related technology, and your opinion about Kyoto ProtocolD related media issues. Your answers will produce valuable informationD for our researchers. Your personal details will not be made publicly  G available. You can find the URL as below:  http://www.e-mediasurvey.com     B As thanks for your participating in our survey, we will offer fourF screen savers for the interviewees who complete the questionnaire. TheE screen savers will be available for download on the final page of the C questionnaire. They include the photos of BMW H2R hydrogen vehicle, ? BMW hybrid car, Honda hybrid cars 2001-2006 and Honda fuel cell E vehicles. We appreciate BMW and Honda allowing us to use these photos B to produce screen savers to help this academic research. Would youF please complete the questionnaire as part of the survey? Thank you for your cooperation.       C Project Leader: Mavis Tsai, Ph.D.          Co-project Leader: Scott 
 Warren, Ph.D. 1 Researchers: PingYuan Sun, BiTing Qiou, YunZe Que  Sponsorship: UNIDO-ICHET  The CCS Global Group- Screen Saver photos authorized by BMW, Honda. E <Please complete the questionnaire as part of the survey, and help us , by forwarding this important survey message.   ------------------------------    Date: 21 Aug 2006 23:45:21 -07001 From: "Bart.Zorn@gmail.com" <Bart.Zorn@gmail.com> ; Subject: Re: SEPPUCLU bugcheck introducing new cluster node B Message-ID: <1156229121.024781.237160@i3g2000cwc.googlegroups.com>   Tom Wade wrote: J > >   What the bugcheck refers to isn't exactly "fun", and there are wordsJ > > around that slide that aren't included in the text of the presentation > > you've found.  > I > Sorry, I didn't mean to suggest that VMS engineering introduced a booby ) > trap :-)  I understand the name chosen.  > E > >   I'd be looking at the communications, connectivity, and at such I > > considerations as the allocation classes, and at mis-matched SCS node  > > identification settings. > A > The SCSNODE and SCSSYSTEMID parameters are unique to each node.  > I > The machines in the cluster use different alloclasses (this was because J > the DEVICE_NAMING took care of shared SCSI buses, and the different nodeG > alloclasses prevented multiple IDE DQA0 devices being confused).  The C > only shared bus now is the fiber array, which is always $1$DGAxxx  > I > An oddity is the output of the >>> SHOW DEVICE command.  Apart from the G > DGA101, the other DGAs don't exist (they also have $0$DGA which looks G > wrong).  Would these be causing confusion, or is this a red herring ?  >  >  > P00>>>show device F > dga101.1001.0.3.1          $1$DGA101                     HSG80  V87FF > dga101.1002.0.3.1          $1$DGA101                     HSG80  V87FF > dga12409.1.0.3.1           $0$DGA12409                   HSG80  V87FF > dga12409.2.0.3.1           $0$DGA12409                   HSG80  V87FF > dga12601.1.0.3.1           $0$DGA12601                   HSG80  V87FF > dga12601.2.0.3.1           $0$DGA12601                   HSG80  V87F  G You get this kind of output from show device after you have run wwidmgr D at least once. If you do an init and then repeat the show device you will get a more normal display.    HTH,  	 Bart Zorn    ------------------------------  % Date: Tue, 22 Aug 2006 09:41:29 +0100 ) From: Tom Wade <nospam@picard.eurokom.ie> ; Subject: Re: SEPPUCLU bugcheck introducing new cluster node 0 Message-ID: <44EAC339.2090409@picard.eurokom.ie>  2 I appreciate your taking the time to look at this.  C > If you provide the SDA> CLUE REGISTER output from the other node, & > additional analysis may be possible.  D This is the output of the SDA commands on the node that crashed with5 LOCKMGRERR (TROI - the node that SEPPUCLU'd is WORF).    SDA> clue register  M Current Registers:   Process index: 0000   Process name: NULL   PCB: 810CFDC0  (CPU 0) O -------------------------------------------------------------------------------  -  ------- L    R0  =  00000000.00000001   %SYSTEM-S-NORMAL, normal successful completion    R1  =  00000000.00000AE0     R2  =  00000000.00000000 D    R3  =  FFFFFFFF.817F0380   CLU_CSB  (CSID: 000100C9,  Node: WORF)E    R4  =  FFFFFFFF.81596830   SCS_PDT  (Port Type: NI,  Device PEA0:) "    R5  =  FFFFFFFF.81BBDB80   CDRPD    R6  =  FFFFFFFF.815A9880   SCS_CDT  (CSID: 000100C9,  Node: WORF)E    R7  =  FFFFFFFF.81596830   SCS_PDT  (Port Type: NI,  Device PEA0:) '    R8  =  FFFFFFFF.81597280   LAVC_PORT     R9  =  00000000.00000000     R10 =  00000000.00000002 D    R11 =  FFFFFFFF.817F0380   CLU_CSB  (CSID: 000100C9,  Node: WORF)    R12 =  FFFFFFFF.81D2ABA0 1    R13 =  FFFFFFFF.811666B0   CNX$PROCESS_RCV_MSG     R14 =  00000000.00000000     R15 =  FFFFFFFF.FFFFFFFF     R16 =  00000000.000005A4     R17 =  00000000.00000000 D    R18 =  FFFFFFFF.815A9880   SCS_CDT  (CSID: 000100C9,  Node: WORF)E    R19 =  FFFFFFFF.81596830   SCS_PDT  (Port Type: NI,  Device PEA0:)     R20 =  00000000.00000ADF     R21 =  00000000.00000000     R22 =  00000000.17A51EF0     R23 =  00000000.0CA9912D     R24 =  FFFFFFFF.975CACEC     AI  =  FFFFFFFF.817F04F0 9    RA  =  FFFFFFFF.8033660C   CNX$PROCESS_RCV_MSG_C+001AC 2    PV  =  FFFFFFFF.8116A2A0   SEND_FATAL_MSG+000202    R28 =  FFFFFFFF.8116A2A0   SEND_FATAL_MSG+00020    FP  =  FFFFFFFF.8B81BE60 4    PC  =  FFFFFFFF.80350290   SEND_FATAL_MSG_C+00110;    PS  =  28000000.00000804   Kernel Mode, IPL 8, Interrupt    SDA> format @r12/type=lkmsg < FFFFFFFF.81D2ABA0   LKMSG$B_FILL_1                        06#                     LKMSG$B_FILL_11 %                     LKMSG$R_DLCK_MSGS '                     LKMSG$R_EXTENSION_2 %                     LKMSG$R_LOCK_MSGS : FFFFFFFF.81D2ABA1                                   0ADF0A< FFFFFFFF.81D2ABA4                                   00000000< FFFFFFFF.81D2ABA8                                   00000402< FFFFFFFF.81D2ABAC   LKMSG$W_RSEQNUM                     00018 FFFFFFFF.81D2ABAE   LKMSG$W_DIRSEQNUM               0184%                     LKMSG$W_PARSEQNUM < FFFFFFFF.81D2ABB0   LKMSG$W_ACTIVITY                    A47B8 FFFFFFFF.81D2ABB2   LKMSG$B_TSLT                      02'                     LKMSG$W_P25_HASHVAL $                     LKMSG$W_PRIORITY6 FFFFFFFF.81D2ABB3                                   4F< FFFFFFFF.81D2ABB4   LKMSG$L_EPIDNEW                 00000000#                     LKMSG$L_MSTLKID $                     LKMSG$L_ORIGEPID< FFFFFFFF.81D2ABB8   LKMSG$L_ORIGLKID                00000000#                     LKMSG$L_PRCLKID < FFFFFFFF.81D2ABBC   LKMSG$L_CSID                    00000000%                     LKMSG$L_NEWMASTER $                     LKMSG$L_ORIGCSID                     LKMSG$R_DEQ %                     LKMSG$R_EXTENSION #                     LKMSG$R_LOCKQED #                     LKMSG$R_NEWLOCK "                     LKMSG$R_RESEND(                     LKMSG$R_RM_RBLD_DONE'                     LKMSG$R_RM_SHUTDOWN $                     LKMSG$W_EXP_DONE!                     LKMSG$W_FLAGS %                     LKMSG$W_LKBSTATUS "                     LKMSG$B_RQMODE%                     LKMSG$W_RSBSTATUS "                     LKMSG$B_GRMODE< FFFFFFFF.81D2ABC0   LKMSG$L_BLKASTFLG               00010002%                     LKMSG$L_REMTSKPID %                     LKMSG$L_VALBLKFLG &                     LKMSG$Q_BITMAP_EXP(                     LKMSG$W_ORIG_RSEQNUM"                     LKMSG$W_STATUS!                     LKMSG$B_STATE *                     LKMSG$W_ORIG_PARSEQNUM'                     LKMSG$W_RSP_RSEQNUM < FFFFFFFF.81D2ABC4   LKMSG$L_PARPRCLKID              00000001"                     LKMSG$Q_VALBLK)                     LKMSG$W_RSP_PARSEQNUM < FFFFFFFF.81D2ABC8   LKMSG$L_PARMSTLKID              00080020#                     LKMSG$L_VCTMPRI < FFFFFFFF.81D2ABCC   LKMSG$L_VCTMLKID                16000000!                     LKMSG$W_GROUP                       LKMSG$B_RMOD"                     LKMSG$B_RSNLEN< FFFFFFFF.81D2ABD0   LKMSG$L_VCTMCSID                42313146"                     LKMSG$T_RESNAM< FFFFFFFF.81D2ABD4   LKMSG$L_EPIDCVT                 59536124$                     LKMSG$L_NEXTLKID%                     LKMSG$L_VALSEQNUM #                     LKMSG$W_RQSEQNM < FFFFFFFF.81D2ABD8   LKMSG$L_DLCKPRI_CVT             53494453%                     LKMSG$L_ORGTSKPID < FFFFFFFF.81D2ABDC                                   2020314B< FFFFFFFF.81D2ABE0                                   56212020< FFFFFFFF.81D2ABE4                                   00000000< FFFFFFFF.81D2ABE8                                   00000000< FFFFFFFF.81D2ABEC                                   00000000< FFFFFFFF.81D2ABF0   LKMSG$L_DLCKPRI_NEW             00000000< FFFFFFFF.81D2ABF4   LKMSG$W_RQSEQALT                    00008 FFFFFFFF.81D2ABF6   LKMSG$W_LSTAT2                  0000< FFFFFFFF.81D2ABF8   LKMSG$Q_VALBLKALT               08014500< FFFFFFFF.81D2ABFC                                   287EFF00< FFFFFFFF.81D2AC00                                   000055DC< FFFFFFFF.81D2AC04                                   000100C9< FFFFFFFF.81D2AC08   LKMSG$L_VALSEQALT               00000000< FFFFFFFF.81D2AC0C   LKMSG$B_LSTATUS                       00: FFFFFFFF.81D2AC0D   LKMSG$B_RSTATUS                     008 FFFFFFFF.81D2AC0E   LKMSG$B_LCKSTATE                  036 FFFFFFFF.81D2AC0F   LKMSG$B_RBLD_STATUS             00< FFFFFFFF.81D2AC10   LKMSG$L_GRNTSRNG                01200022< FFFFFFFF.81D2AC14   LKMSG$L_GRNTERNG                00000000< FFFFFFFF.81D2AC18   LKMSG$L_RQSTSRNG                00000000< FFFFFFFF.81D2AC1C   LKMSG$L_RQSTERNG                00000000< FFFFFFFF.81D2AC20   LKMSG$L_HASHVAL                 4F02A47B(                     LKMSG$W_P25_PRIORITY#                     LKMSG$W_DIRHASH  SDA>  9 --------------------------------------------------------- @ Tom Wade                 | EMail: tee dot wade at eurokom dot ie3 EuroKom                  | Tel:   +353 (1) 296-9696 3 A2, Nutgrove Office Park | Fax:   +353 (1) 296-9697 L Rathfarnham              | Disclaimer:  This is not a disclaimer            G Dublin 14                | Tip:   "Friends don't let friends do Unix !"  Ireland    ------------------------------    Date: 22 Aug 2006 02:23:43 -0700/ From: "Volker Halle" <volker_halle@hotmail.com> ; Subject: Re: SEPPUCLU bugcheck introducing new cluster node C Message-ID: <1156238623.298735.287610@m79g2000cwm.googlegroups.com>    Tom,  ? thanks for the CLUE REGISTER data. By looking at the symbolized @ register values, you can see, that node TROI has received a lockG manager message from node WORF via the LAN (PEA0) and then sent a fatal  message to WORF.  C I need the SDA> format @r12/type=lkmsg data from WORF (the received F fatal message contains additional information about the reason why the SEPPUCLU is to be taken).    Volker.    ------------------------------  % Date: Tue, 22 Aug 2006 14:59:27 +0100 ) From: Tom Wade <nospam@picard.eurokom.ie> ; Subject: Re: SEPPUCLU bugcheck introducing new cluster node 0 Message-ID: <44EB0DBF.8000201@picard.eurokom.ie>  E > I need the SDA> format @r12/type=lkmsg data from WORF (the received H > fatal message contains additional information about the reason why the > SEPPUCLU is to be taken).   D Unfortunately, although WORF said it was writing a dump, it does not seem to have done so.    QUARK-# anal/crash sysdump.dmp  ' OpenVMS (TM) Alpha system dump analyzer 2 ...analyzing a compressed selective memory dump...  8 %SDA-W-NOTSAVED, global pages not saved in the dump file: %SDA-E-NOREAD, unable to access location FFFFFFFF.81020120    9 --------------------------------------------------------- @ Tom Wade                 | EMail: tee dot wade at eurokom dot ie3 EuroKom                  | Tel:   +353 (1) 296-9696 3 A2, Nutgrove Office Park | Fax:   +353 (1) 296-9697 L Rathfarnham              | Disclaimer:  This is not a disclaimer            G Dublin 14                | Tip:   "Friends don't let friends do Unix !"  Ireland    ------------------------------    Date: 22 Aug 2006 07:33:12 -0700/ From: "Volker Halle" <volker_halle@hotmail.com> ; Subject: Re: SEPPUCLU bugcheck introducing new cluster node B Message-ID: <1156257192.177867.37770@i42g2000cwa.googlegroups.com>   Tom,  F if you have the console output of node WORF available, you could check( for any errors while writing the dump...  ? To find out more information from the LOCKMGRERR crash, I need:   4 SDA> exa @r5+cdrp$l_val2 ! address of received LKMSG xxxxxxxx: yyyyyyyy   SDA> format yyyyyyyy/type=LKMSG   G This is the message received from WORF, on which TROI decided, there is G something severely wrong and sent WORF the fatal messge (leading to the  SEPPUCLU crash).   Volker.    ------------------------------  # Date: Tue, 22 Aug 2006 16:56:02 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>; Subject: Re: SEPPUCLU bugcheck introducing new cluster node . Message-ID: <CGGGg.60$eG1.54@news.cpqcorp.net>   Tom Wade wrote:   & > How do I preload the LKMSG symbols ?  9    With a little Macro32 file and the GLOBAL declaration.   D    Here's a version of this symbolic file that I was using recently:   ==    $KFEDEF GLOBAL     $WCBDEF GLOBAL     $FCBDEF GLOBAL     .end  ==  Q    Macro32 (compile/assemble) something similar (though obviously containing the  Q particular include definitions of interest), and then use SDA to READ the object   into the environment.    ------------------------------    Date: 22 Aug 2006 09:51:37 -0700/ From: "Volker Halle" <volker_halle@hotmail.com> ; Subject: Re: SEPPUCLU bugcheck introducing new cluster node B Message-ID: <1156265497.706567.173830@i3g2000cwc.googlegroups.com>   Tom,   > & > How do I preload the LKMSG symbols ? >   D Did you notice, that formatting the LKMSG had worked in the previousE example ? You had issued the SDA> CLUE REGISTER command before and it 5 had read in all important symbol table files for you.    Volker.    ------------------------------   Date: 22 Aug 2006 02:25:58 EDT) From: cook@wvnvms.wvnet.edu (George Cook) ; Subject: Re: VGA video adapter for Vaxstation 4000 model 60 ! Message-ID: <atNMQKiCbxRW@wvnvms>   Z In article <ecdf46$308$01$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes: > Steven M. Schweda schrieb:6 >> From: "Richard B. Gilbert" <rgilbert88@comcast.net> >>   >>>[...]  It has  A >>>a weird video connector; three coax type "pins" in a DB shell.  >>   >>  K >>    For the record, the same connector was also used by Apollo and by IBM   >> (on some RS/6000 machines).   > " > I'm not sure if this is correct.3 > But I have an ancient IBM RT sitting on the shelf + > which has exactly this kind of connector.   G The 3 pin connector is called a 3W3.  Some SUN and RS6000 (I don't know H about Apollo) machines used a 13W3 connector which has ten DB style pinsI between pin 1 and 2 of the three coax pins.  The one IBM 3W3 to BNC cable G I have (possibly came with an RT system) is non-standard in that it has  Red and Blue reversed.  K FWIW, the DEC 3000 I am writing this from uses a 3W3 to VGA cable connected G to a VGA to 13W3 cable to connect the 3W3 turbochannel video card to my 
 13W3 monitor.      George Cook  WVNET    ------------------------------  % Date: Tue, 22 Aug 2006 08:41:32 +0200 ( From: Michael Kraemer <M.Kraemer@gsi.de>; Subject: Re: VGA video adapter for Vaxstation 4000 model 60 / Message-ID: <ece8tv$d5s$02$2@news.t-online.com>    Tom Linden schrieb: I > This may seem odd but it works.  The cable referred to with the three    > moldedI > sma connectors at the 4000 end and the three bnc at the others can be    > connected M > to a cable which you can buy almost anywhere which has 5 bnc at one and and ? > d-sub at the other using 3 bnc couples costing about $1 each.  >               ---R  -C- R : > SMA -------------G  -C- G------------------------  D-SUB >               ---B  -C- B  >                     -- W >                     -- Bl  >   : this is the way I translate most of my strange workstation0 outlets to VGA to feed them into a Video switch.) And, as I have discovered a few days ago, * may also be used with a modern flatscreen.  An oldish DECstation PMAG-B card/ at an Eizo L66 works without apparent problems.    ------------------------------  % Date: Tue, 22 Aug 2006 08:58:18 +0200 ( From: Michael Kraemer <M.Kraemer@gsi.de>; Subject: Re: VGA video adapter for Vaxstation 4000 model 60 / Message-ID: <ece9td$ij4$03$1@news.t-online.com>    George Cook schrieb:\ > In article <ecdf46$308$01$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes: > I > The 3 pin connector is called a 3W3.  Some SUN and RS6000 (I don't know J > about Apollo) machines used a 13W3 connector which has ten DB style pins/ > between pin 1 and 2 of the three coax pins.     ' thanks for clarifying the nomenclature. + 3W3 certainly sounds more professional than & "that strange DEC-style connector" :-)   > The one IBM 3W3 to BNC cableI > I have (possibly came with an RT system) is non-standard in that it has  > Red and Blue reversed.  F Might give funny colours, but as long as the Green is not affected ...  M > FWIW, the DEC 3000 I am writing this from uses a 3W3 to VGA cable connected I > to a VGA to 13W3 cable to connect the 3W3 turbochannel video card to my  > 13W3 monitor.   B I sometimes wonder that gfx signals can travel so many transitions+ and still give some picture on the monitor.    ------------------------------    Date: 22 Aug 2006 01:45:33 -0700 From: etmsreec@yahoo.co.uk; Subject: Re: VGA video adapter for Vaxstation 4000 model 60 C Message-ID: <1156236333.355586.322060@i42g2000cwa.googlegroups.com>   @ Not sure about the PMAGD-AA in a VAXstation.  There were severalC variations on the Turbochannel card and the PMAGD-AA was in the DEC F 3000 series systems (I know because when mine blew, I got an incorrect replacement to start with!)    Caveat emptor.   Steve    Richard B. Gilbert wrote:   > intensifi@earthlink.net wrote: > 
 > > Hello, > > K > > I heard such an adapter existed.  Does anyone know where I can get one?  > > H > > 29-32549-01 is a part # I found while searching, but no luck finding > > one to buy.  > >  > > Thanks in advance! > >  > J > Hmmmm!   I have this dusty antique labeled "PMAGD-AA" which I believe isI > a turbo-channel video card which might work in your VAXstation.  It has @ > a weird video connector; three coax type "pins" in a DB shell. > C > I have no idea if it is in working condition and have no means of 7 > testing it.  My poor old 4000/VLC doesn't support it.  > E > If you think you might be able to use it, drop me an e-mail with an B > offer.  If it doesn't work you may return it and I'll refund the' > purchase price, but not the shipping.    ------------------------------   End of INFO-VAX 2006.467 ************************