/ INFO-VAX	Tue, 02 Jan 2001	Volume 2001 : Issue 4       Contents:6 Re: Bug - NLB0: crash, was: "NLA0: the null device..."6 Re: Bug - NLB0: crash, was: "NLA0: the null device..." Re: Giving up on VMS Re: Giving up on VMS Re: Happy New Years ' LPD or TELNET queue failover in cluster  Re: relocation Re: VR241 monitor and S-video   F ----------------------------------------------------------------------  + Date: Tue, 02 Jan 2001 10:23:28 +0100 (CET) : From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl>? Subject: Re: Bug - NLB0: crash, was: "NLA0: the null device..." I Message-ID: <Pine.LNX.4.21.0101021003470.7970-100000@irys.stanpol.com.pl>   # On 29 Dec 2000, Hoff Hoffman wrote:   = +In article <...>, Terry Kennedy <terry@gate.tmk.com> writes:  [...] N +:  Sure. But I don't think either of those apply here. If NLA0: is one of theP +:dedicated, sacred device names, then SYSGEN and friends should have a complete; +:set of "you can't do that" errors for trying to clone it.     Agree !   [...] I +  Um, it has been my experience that users are quite creative with their 9 +  approaches to things where "you can't do that".  [...]   
  Agree -:)   [...] I +  In this particular case, as has been discussed elsewhere, there exists F +  at least one product which (erroneously, IMO) loads a custom deviceJ +  driver under the NL prefix.  Consider that we could lock out all accessK +  to the "NL" prefix, but we would break this product.  (The most extreme  M +  approach, where all access to unregistered product device driver prefixes  5 +  is locked out, would definitely break things.  :-)  + J +  The null device itself is one of a few very special and select devices C +  on OpenVMS, as the driver is built directly into OpenVMS itself;   +  Hoff, here is the answer for proper check: ? - don't check the device name, loading OPG1: MBT6: and NLP0: is >  unimportant of us and no reason to prevent it is found (hm...  correction welcome !)= - don't check the "registered product" name, we will have the :  way to get sometime a freeware "loadable null driver" -;)@ - but check (and prevent !) "CONNECT" for any "inlined" drivers:=  probably simple check if the reported (saved in driver list) .  file name exist (before CONNECT) is enought !B  As have reported: all "compiled into" drivers (OP, MB, NL) rejectK  "second CONNECT" and the simple check is a resolution the word from Terry.   =   Preventing any CONNECT to any name (including NLB0) is IMHO "  a overkill and please don't that.A BTW: have check thet loading "anything" (in example SYS$TTDRIVER, A  the VT-terminal) under NLB0: doesn't go to problem; will suspect B  that also "anything" (a virtual/network driver !) will work; will<  check (if have time) and report (suspected: positive) here.  H +                                                                  it isJ +  not resident in a separately-loaded image.  In other words, this device& +  driver is already somewhat unusual.  ? ...as OP and MB, and that generates somewhere a bug. Isn't here 8 a internal intermediate "file not found" bug found -;) ?  K +  Yes, there are comparatively few "blade guards" within the device driver G +  subsystems of SYSGEN and SYSMAN IO.  That said, errors in the input  J +  specifications central to the correct and normal operation of the tool 3 +  are very difficult to detect and defend against.     Agree. =  But, IMHO, all virtual (="/NOADAPTER") drivers in most cases ? are a exception... Except the "compiled into", as have seen -:)    [...] J +  first-line protection against this particular potential OpenVMS system 6 +  crash is the CMKRNL privilege itself, of course...)    Och, yes, we all agree -:)   K +  I am certainly interested in suggestions around how we can improve upon  K +  the current integrity checks within the existing CONNECT/LOAD support...     -:)     Best regards in New Millenium !
  - Gotfryd   --  E ===================================================================== F $ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") - 		THEN EXCUSE/OBJECT=ME . $!                        GS@stanpol.zabrze.plE =====================================================================    ------------------------------  + Date: Tue, 02 Jan 2001 10:31:32 +0100 (CET) : From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl>? Subject: Re: Bug - NLB0: crash, was: "NLA0: the null device..." I Message-ID: <Pine.LNX.4.21.0101021024130.7970-100000@irys.stanpol.com.pl>   ( On Fri, 29 Dec 2000, Mark E. Levy wrote: [...] F +Ah, yes! A shadowed null device! That's just what OpenVMS needs to be +truly fault tolerant.  =  You ask more (shadowing) what sometime is nedded -;) (manual * switch-over, to be precise, see above) -:)  H +                          Having a null device go offline can cause allI +sorts of headaches. Being able to fail over to another null device would  +solve that problem.  C  Laught aloud - but I remember, here *was* one (yes, one in tens of ! years) report of OFFLINEd NLA0: !   -;>  ;  Och, the fact that reboot was necessary [for suspection of 6 kernel inconsistency] regardles of the NLB0: existence is a separate problem -:)   (  Best regards in New Millenium - Gotfryd --  E ===================================================================== F $ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") - 		THEN EXCUSE/OBJECT=ME . $!                        GS@stanpol.zabrze.plE =====================================================================    ------------------------------    Date: 02 Jan 2001 13:10:14 +0800, From: Paul Repacholi <prep@prep.synonet.com> Subject: Re: Giving up on VMS 0 Message-ID: <87vgrya6a1.fsf@k9.prep.synonet.com>  ) "Bill Todd" <billtodd@foo.mv.com> writes:   C > I think you may have misunderstood the context:  the 'poor' write H > performance is when compared to ext2fs on Linux, a very fast-and-looseN > approach.  Those safer systems (that avoid the need for fsck) can still lookO                                                                           ^^^^  B > good compared with VMS, since with a well-designed log-protectedN > implementation (I'm not privy to the internals of these products, but IRIX'sM > XFS seems very well-thought-of in this regard and indeed enjoys an enviable H > reputation for performance, including write performance) only a singleJ > synchronous log-disk write is required to attain all the safety of VMS'sJ > approach with in many cases significantly less operation latency (thoughJ > additional 'lazy' writes will eventually occur, with luck when the disksM > aren't otherwise busy and with at least the hope of coalescing many updates ' > to the same pages into a single one).   H I think you should put the glossies where they belong, and sit down with	 the code.   H Log based systems get their 'performance' by writeing a large contiguousG chunk of dta and meta data in one hit. However, to do this, you have to E have all reaads cached, the data in the cache, and the updates in the F cache, plus the extra overhead to the writelog, plus you must have theE extra free space on the disk. If you run short, things can go to hell  in a big way...   E When you get to play catchup, then you must re-read, merge and write. A The write phase is just what you had to do to start with. You can @ cross your fingers and do bulk, non-attomic uppdates, but if you@ take a power or other failure then, you are back where you whereD trying to get away from. Abiet, you can re-run the log if the designD garentees an exact repeatable output for a given log. Note, exact...C Otherwise you must do a roll-back, then an update. If you do things D like write coallesing, you loose the atomic, consistant state of the+ media, and can have to sort out the mess...   D Now if you want to try to transfer the wonders of these systems into= a cluster environment, best of british to you. And your data.   > PAy now, or pay (more) later. But you do not get a free lunch.? You can, however get most of the gain by either setting up your D app to 'do the right thing' with VMS, or setting the volume defaults# or fstune'ing to get what you need.   + BTW, requiring a UPS is admitting you lose.    --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------  % Date: Tue, 02 Jan 2001 10:47:59 +0100   From: Paul Sture <paul@sture.ch> Subject: Re: Giving up on VMS + Message-ID: <VA.00000201.25384c70@sture.ch>   9 In article <92qibd$jcg$1@pyrite.mv.net>, Bill Todd wrote: ) > From: "Bill Todd" <billtodd@foo.mv.com>  > Newsgroups: comp.os.vms  > Subject: Re: Giving up on VMS & > Date: Mon, 1 Jan 2001 13:33:22 -0500 >  > - > Paul Sture <paul@sture.ch> wrote in message ' > news:VA.00000200.20d1fb7d@sture.ch...  >  > .... > I > > Changing subject slightly, but still on topic, I found an interesting > > > article the other day discussing recovery on unix systems. > > 3 > > From http://www.daemonnews.org/200012/tram.html  > > J > > "Today, if your power supply fails, your computer may take a long timeC > > to fsck. What if that computer is the computer holding the main J > > database for your website? What if that is a large database on a large; > > 200 gigabyte raid? Clearly, this is a problem, and more I > > people would probably pay to have this solved, if it was inexpensive. A > > However, the solutions have generally been expensive, so most J > > people opt for the default 'fault-tolerance' that unix provides. OtherC > > possible solutions were Journaled Meta Data filesystems such as H > > the ones in AIX, IRIX, and a few others. These filesystems are stillJ > > not in most free unix's and definitely not in a production state. TheyI > > require major architectural changes to an OS to support them and they 0 > > still have serious write throughput issues.". > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > J > > So in spite of the complaints made in the past by folks here about theH > > poor I/O performance of VMS vs Linux, that performance advantage canJ > > have a significant cost elsewhere, or you can go the (expensive) route< > > of other systems which also have poor write performance. > C > I think you may have misunderstood the context:  the 'poor' write H > performance is when compared to ext2fs on Linux, a very fast-and-looseN > approach.  Those safer systems (that avoid the need for fsck) can still lookB > good compared with VMS, since with a well-designed log-protectedN > implementation (I'm not privy to the internals of these products, but IRIX'sM > XFS seems very well-thought-of in this regard and indeed enjoys an enviable : > reputation for performance, including write performance)  M What grabbed my attention was the problem of fsck-ing large volumes. From my  M admittedly small amount of experience with fsck on my home Linux box (cheap,  O hardly state of the art), when it kicks in I might as well take a lunch break.  F Extrapolate that to large systems and we are talking serious downtime.  L On the XFS front, I rather took the author's word for it, as I'm not a unix L expert. Re-reading in the light of your comments, I could deduce that he is M speaking in terms of free / low cost unix when he says these are "definitely   not in a production state"   > only a single J > synchronous log-disk write is required to attain all the safety of VMS'sJ > approach with in many cases significantly less operation latency (thoughJ > additional 'lazy' writes will eventually occur, with luck when the disksM > aren't otherwise busy and with at least the hope of coalescing many updates ' > to the same pages into a single one).  > G Which description reminds me of NTFS.  I'm honestly not sure where the  4 performance of that lies with respect to the others.   > > E > > With the recent announcements from OpenVMS Engineering of work to J > > improve caching and I/O performance I am hoping that we should be able% > > to enjoy the best of both worlds.  > K > Nope:  that would take a real log-protected approach on VMS as well.  But J > it'll be an improvement over the current state. Of course, Linux is alsoG > moving ahead:  it already has reiserfs, which IIRC is a log-protected L > implementation, SGI has open-sourced its XFS code and should have it fullyM > ported soon (at least one beta has been available for some time), and Peter I > Braam (whether still in cooperation with Stephen Tweedie or not I don't N > know) is creating another new file system which I think is log-protected and > clusterable to boot. > ( If you didn't read the complete article G http://www.daemonnews.org/200012/tram.html , I think you might find it  J interesting. The author, Dru Nelson, goes on to propose Transactional-RAM 1 (TRAM) as a method for addressing these problems.   L It made sense to me, although I haven't got my head around all the what-ifs  yet.   ___ 
 Paul Sture Switzerland    ------------------------------   Date: 2 Jan 2001 11:42:01 GMT / From: Hans.Bachner@altavista.net (Hans Bachner)  Subject: Re: Happy New Years( Message-ID: <92si80.5l.1@hans.myfqdn.de>  6 David J. Dachtera (djesys.nospam@earthlink.net) wrote:   <snip>< >> (remember, the internet is global in nature, SI rules...)  K May I help out with some numbers for the rest of us who are not really use   to inches and Fahrenheit?   = 70 degrees Fahrenheit ~ 21 degrees Celsius (do you call them   'centigrades'?)   K Pretty warm for this part of the season - here in Austria we're around the  F freezing point. I'd love to be back to San Diego... only seen it once.  J Regarding the snow in Chicago - 20 inches are 50.8 cm, 50 inches are 1.27  meters.   K Anyway, have a happy new millennium, regardless of units, scales, etc... -  " as long as you're running OpenVMS!   Hans.    ------------------------------  # Date: Tue, 02 Jan 2001 09:43:14 GMT  From: samalsson@my-deja.com 0 Subject: LPD or TELNET queue failover in cluster) Message-ID: <92s7rh$hgv$1@nnrp1.deja.com>   	 Hi Folks.   F How do I create a clusterwide LPD or TELNET queue using OpenVMS V7.2-16 and TCP/IP V5.0A on Alpha with failover capabilities ?: I am already using the autostart feature with DCPS queues.C I would like to have either an LPD or  TELNET queues with autostart 5 specified on both node in a cluster. Is it possible ?    Sam        Sent via Deja.com  http://www.deja.com/   ------------------------------  % Date: Tue, 02 Jan 2001 17:26:33 +0000   From: steven.reece@quintiles.com Subject: Re: relocation H Message-ID: <OF98A77728.2496514E-ON802569C8.005FA7C4@qedi.quintiles.com>  G I thought that addresses less than 200 were invalid anyway and would be  likely to cause ACCVIOs?  ? Bob Koehler (koehler at eisner dot decus dot org) wrote/quoted: 5 >>>Ashutosh Dhodapkar <dhodapka@ece.wisc.edu> writes:  > D > I needed some help on relocation of binaries. basically, i want toI > relocate a binary so that it occupies virtual address 0x00 however i am F > unable to do this on the alpha system that we have. any help will be > appreciated.  D You might be able to accomplish this with base=0 in the link optionsB file (or is that VAX only?).  You don't want to, I spent some timeF cleaning this out of an application a couple years ago, which would no7 longer build or run because someone used a base option.   H What are you trying to do?  There is probably a better way to do it than basing the image.<<<   ------------------------------  % Date: Tue, 02 Jan 2001 07:23:36 -0500 2 From: "Richard B. Gilbert" <DRAGON@compuserve.com>& Subject: Re: VR241 monitor and S-video7 Message-ID: <200101020724_MC2-C04B-CAAB@compuserve.com>   G         I missed the "S-video" part of your question!  What is S-video?     Message text written by JF Mezei >"Richard B. Gilbert" wrote:G >         I suspect that you could buy a 15" SVGA monitor for less than  whatH > it would cost you to cobble together something that would display on a > VR241!  J I know I can take composite video from my VCR and plug it into all three = R  G B J plugs of the VR241 and I get a nice black and white picture (since all R = G  and 5 B are equal). It gets its sync from the Green signal.   J So I was just wondering if S-video provides separate R B G signals I coul= dL@ feed into that monitor. It is after all just a Sony RGB monitor.     <N   ------------------------------   End of INFO-VAX 2001.004 ************************