0 INFO-VAX	Fri, 17 Feb 2006	Volume 2006 : Issue 95      Contents: $Monitor average question  Re: 4000 vlc motherboard8 553  %TCPIP-E-SMTP_COMMANDERR, SMTP command error <host>4 Re: ANN: yahMAIL is dead - long live son of yahMAIL!4 Re: ANN: yahMAIL is dead - long live son of yahMAIL! Re: Boy, do I like VMS humor!  Re: Boy, do I like VMS humor!  Re: Boy, do I like VMS humor!  Re: Checking for a DCL verb  Re: Hobbyist storage solutions0 Re: impenetrable Mac OS X virus found by Sophos!0 Re: impenetrable Mac OS X virus found by Sophos!0 Re: impenetrable Mac OS X virus found by Sophos!" Re: Inline FTP command from a .CMD6 Re: LD devices in shadowsets on fault tolerant cluster6 Re: LD devices in shadowsets on fault tolerant cluster6 Re: LD devices in shadowsets on fault tolerant cluster6 Re: LD devices in shadowsets on fault tolerant cluster Re: MOSAIC problem (GIF image) Re: MOSAIC problem (GIF image) Re: MOSAIC problem (GIF image). Re: OpenVMS needs biometric/smart card logins!1 Re: Updated OpenVMS Information - OK for external 1 Re: Updated OpenVMS Information - OK for external   F ----------------------------------------------------------------------  % Date: Thu, 16 Feb 2006 20:05:02 -0500 ) From: "Neil Rieck" <n.rieck@sympatico.ca> " Subject: $Monitor average question9 Message-ID: <0j9Jf.3827$_D5.333723@news20.bellglobal.com>   B Does anyone know what kind of averaging is used in a command like L "$mon/cluster/average"? Is this a running average which begins with command  invocation?   K If not, it would be nice if HP added a few DCL switches to this command to  G convert the current averaging routines into one which would sample and  H average over the size of an adjustable window. How about something like:  * $mon/cluster/average/interval=1/samples=60  E Samples would default to zero which would select the legacy behavior.   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------    Date: 16 Feb 2006 13:11:58 -0800" From: chris_doran@postmaster.co.uk! Subject: Re: 4000 vlc motherboard C Message-ID: <1140124318.241791.117520@f14g2000cwb.googlegroups.com>    Cliff Miller wrote: " > Don't know if this helps, but... > < > http://deathrow.vistech.net/~cvisors/dec94mds/v48vbsv1.pdf >  > Service Manual...   B Thanks for that link. I note that p2-4 says the H7109-00 PSU has aB +3.3V output, but I've now double-checked two VLCs and neither hasG +3.3V (on load). The PSUs are H7109-C, so perhaps there's a later model C that doesn't need it. I suggest examining the power connector leads + against my diagram when you get your board.    Chris    ------------------------------  + Date: Thu, 16 Feb 2006 20:17:41 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)A Subject: 553  %TCPIP-E-SMTP_COMMANDERR, SMTP command error <host> $ Message-ID: <dt2ml5$n4s$2@online.de>  D I've seen this once or twice in the last couple of years, but don't  remember asking about it here.   I've seen this error:   ;    553  %TCPIP-E-SMTP_COMMANDERR, SMTP command error <host>   E a few times today.  I didn't see it with EVERY email sent, just with  @ some.  For those which produced the error, resending was always 0 successful, but not always on the first attempt.  I I probably need to define some logicals to get more verbose logging.  On  ? my long list of things to do is to investigate TCPIP debugging.   G However, in this case, since the problem is transient and my system is  D stable, I suspect that the problem is elsewhere.  Other TCPIP stuff 6 (HTTP, TELNET, FTP, receiving email) seems to work OK.  9 Could it be an intermittent problem with my mail gateway?    ------------------------------    Date: 16 Feb 2006 10:59:48 -0800( From: "Rich Jordan" <jordan@ccs4vms.com>= Subject: Re: ANN: yahMAIL is dead - long live son of yahMAIL! C Message-ID: <1140116388.282994.321300@g44g2000cwa.googlegroups.com>    Mark, A      it sounds (and looks in the docs) great.  I'm really looking , forward to trying it as soon as work allows.   Rich   ------------------------------  % Date: Fri, 17 Feb 2006 06:27:08 +1030 * From: Mark Daniel <mark.daniel@vsm.com.au>= Subject: Re: ANN: yahMAIL is dead - long live son of yahMAIL! 0 Message-ID: <11v9l3f243qnl32@corp.supernews.com>  I Hi Dave.  If Bob's environment needs or would profit from having soyMAIL  E in place of it's current yahMAIL (and they really can't be compared)  I then the post is pertinent.  If Bob was just throwing away a line then I  4 agree my three course meal was a waste of resources.   David B Sneddon wrote:# > Mark Daniel was overheard to say:  >  >> bob@instantwhip.com wrote:  >>- >>> what about Purveyor??????????????????????  >> >> >>H >> My initial impulse to a terse demand is to make be a correspondingly : >> abbreviated response.  I have some suggestions instead. >  > + > [...lots of interesting stuff snipped...]  > & > My initial response would have been: >   > Yes boob, what about Purveyor? >  > (Do not feed the troll!) > 
 > Regards, > Dave.    ------------------------------    Date: 16 Feb 2006 18:27:48 -0800$ From: "AEF" <spamsink2001@yahoo.com>& Subject: Re: Boy, do I like VMS humor!C Message-ID: <1140143268.101995.147010@g44g2000cwa.googlegroups.com>   
 AEF wrote: > Martin Vorlaender wrote: > > All, > > 7 > > on several occasions, I've had reason to ROTFL when : > > tripping over some comment or built-in gimmick in VMS. > > 8 > > Seems the documentation department also falls in the > > same category: [...]  > G > Another example, possibly only in a v4.4 manual, includes a directory > > called [MEATBALL.SUB]. Someone was looking forward to lunch! [...] 7 > I'll post more if I think of any more examples later.  >   # Check out another oldie but goodie:   B To leap or not to leap: Stan Rabinowitz's response to an SPR whichF "claimed the LIB$DAY Run-Time Library service assumed incorrectly that the year 2000 was a leap year."   > http://h71000.www7.hp.com/openvms/products/year-2000/leap.html   AEF    ------------------------------  % Date: Fri, 17 Feb 2006 14:00:00 +1100 $ From: Phaeton <phaeton@iinet.net.au>& Subject: Re: Boy, do I like VMS humor!J Message-ID: <43f53c2c$0$17129$5a62ac22@per-qv1-newsreader-01.iinet.net.au>  
 AEF wrote:% > Check out another oldie but goodie:  > D > To leap or not to leap: Stan Rabinowitz's response to an SPR whichH > "claimed the LIB$DAY Run-Time Library service assumed incorrectly that! > the year 2000 was a leap year."  > @ > http://h71000.www7.hp.com/openvms/products/year-2000/leap.html   	Or another funny one, the :  ! 	"Achtung Alles Lookenpeepers !!"  	.....   						:-)  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]:     Willy-nilly (adj.), impotent.    ------------------------------  % Date: Thu, 16 Feb 2006 22:26:50 -0500 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>& Subject: Re: Boy, do I like VMS humor!- Message-ID: <43F54274.3D31F1C0@vaxination.ca>   
 AEF wrote:@ > http://h71000.www7.hp.com/openvms/products/year-2000/leap.html  C Does anyone know what the board number and model name for the Q-BUS   atomic clock option for VAX is ?  F In that SPR, it is mentioned that they doN't yet have it, so I have to" assume that it eventually came :-)  H If the nuclear clock produces enough power, it might be able to power myF power hungry RF drives as well as the air conditioning unit as well as* keeping better time than the TOY clock :-)   ------------------------------  % Date: Thu, 16 Feb 2006 20:06:25 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>$ Subject: Re: Checking for a DCL verb+ Message-ID: <43F52FA0.AFE89E54@comcast.net>    Martin Vorlaender wrote: > - > "Rudolf Wingert" <win@fom.fgan.de> wrote... G > > a few people wrote about a command called VERB. I did not find this E > > command under my OpenVMS 7.1-2 and 7.3-1. Is this any freeware or  > > layered product? >  > It's on Freeware CD #55 > http://h71000.www7.hp.com/freeware/freeware50/verb/  > as well as on Hunter's site ; > http://vms.process.com/scripts/fileserv/fileserv.com?VERB " > (which probably is more recent).  4 ...and neither of those contains support for /CHECK.  A If someone has suh a version, please pass it along to both Hunter  Goatley and Steve Hoffman.   Thanx!   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------   Date: 16 Feb 2006 23:07:08 GMT From: healyzh@aracnet.com ' Subject: Re: Hobbyist storage solutions + Message-ID: <dt30is2rkr@enews4.newsguy.com>   . JF Mezei <jfmezei.spamnot@teksavvy.com> wrote:G > My "new" RX400 storage cabinet with 5 RF disks is turning out to be a E > great space heater. So migrating to a more energy efficiant storage 3 > medium is not something I want to delay too much.   H > I would very much like to stay away from a solution that locks me into( > hardware which is no longer available.  M Since you're looking for Narrow SCSI that makes things a bit more difficult.  K One thought is an Acard EIDE to SCSI converter (I personally don't have any I experience with these).  The other is a 3rd party JBOD solution that uses K SCA disks, this is the route that I've taken for my PWS 433au.  I can just  * get cheap SCA SCSI HD's and plug them in.   G OTOH, my VAXstation 4000/vlc and most any test VMS system I build has a H BA350 shelf, but I've got a bunch of shelves and drives that I picked upF years ago.  I really can't recommend sinking money into a BA350.  Even2 though I ran my primary system with one for years.  I If you can get a BA356 that uses the canisters that take SCA drives, that G *might* be a good solution, plus you can get an 8-bit interface for it.    		Zane   ------------------------------  % Date: Thu, 16 Feb 2006 15:11:26 -0700 " From: GreyCloud <mist@cumulus.com>9 Subject: Re: impenetrable Mac OS X virus found by Sophos! 0 Message-ID: <_ZadnU0boKLYZGneRVn-rw@bresnan.com>   bob@instantwhip.com wrote:  ; > so Mac OS X is virus proof like OpenVMS?  Not anymore ...  > + > http://www.theinquirer.net/?article=29753  >   E I don't use ichat, but by setting up OS X according to NSA standards  F (throwing out the apps they deem hazardous to security), then you are H still safe.  Lets see how Tru-64 UNIX will fare if you park ichat on it.  6 It isn't the os so much as the apps are quite suspect.   --   Where are we going?   And why am I in this handbasket?   ------------------------------    Date: 16 Feb 2006 15:21:43 -0800, From: "rcyoung" <rcyoung@aliconsultants.com>9 Subject: Re: impenetrable Mac OS X virus found by Sophos! C Message-ID: <1140132103.006734.249770@g47g2000cwa.googlegroups.com>   E There have always been Mac viruses. Back in the early 1990s they were @ quite prevalent. They just "went under the radar" as the writers< concentrated on Windows. However, I can live with the 1 or 2E Mac-centric ones that seem to pop up each year....My firewall filters ! out 5-6 Windows viruses EACH DAY!    ------------------------------   Date: 16 Feb 2006 22:59:48 GMT From: healyzh@aracnet.com 9 Subject: Re: impenetrable Mac OS X virus found by Sophos! + Message-ID: <dt30541rkr@enews4.newsguy.com>    bob@instantwhip.com wrote:; > so Mac OS X is virus proof like OpenVMS?  Not anymore ...   + > http://www.theinquirer.net/?article=29753   J It's not a Virus, it is a Trojan, and you have to be stupid enough to type; in the machines Administrator password when it asks for it.   	 		   Zane    ------------------------------  # Date: Thu, 16 Feb 2006 22:51:13 GMT # From: hoff@hp.nospam (Hoff Hoffman) + Subject: Re: Inline FTP command from a .CMD 1 Message-ID: <Bl7Jf.3276$mw7.984@news.cpqcorp.net>   \ In article <1140108432.855200.254860@z14g2000cwz.googlegroups.com>, kerowo@gmail.com writes:G :Hello, I'm trying to inline an FTP statement in a .CMD and am having a B :hard time finding documentation about what to do syntatically. My! :current attempt looks like this:   >   The DCL command COPY/FTP is likely a whole lot easier here, >   and allows you to use the DCL symbol substitition mechanisms=   you want here.  You can easily embed this command within a  (   DCL .COM command procedure, of course.  >   COPY/FTP, DIRECTORY/FTP and various other commands have been=   around since V6.2 -- you don't cite the version, however -- <   so long as you have a V6.2-compliant TCP/IP installed.  Or
   later IP...   @   The usual problem within command procedures using utilities isA   that DCL symbol substitution only occurs when it is DCL that is >   reading the commands.  Within a command utility, the utility>   itself is reading and processing commands.  FTP doesn't know   from DCL symbols, after all.   	--   D   (The file extension .CMD is more commonly seen on other platforms,   and not on OpenVMS, FWIW.)      N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------G        Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[\0100]hp.com    ------------------------------  + Date: Thu, 16 Feb 2006 18:33:42 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)? Subject: Re: LD devices in shadowsets on fault tolerant cluster $ Message-ID: <dt2gi6$8cm$1@online.de>  C In article <1140109201.407295.165200@g14g2000cwa.googlegroups.com>, ( "Chris" <catsoup57@hotmail.com> writes:   I > Here as Jaguar cars we are trying to deploy a new VMS cluster. We use a C > three member shadowset for our application database.  The cluster I > consists on 3 OpenVMS7.3-2 nodes, running on 2 DS25's and a DS15 quorum 	 > keeper.  > D > The database fits quite easily in 2Gb. Unfortunately, the smallestG > disks we were able to get were 36Gb. This causes us problems with the 1 > time taken to do shadow copy/merge and backups.   H How often ar copies/merges needed?  Why not minicopy/minimerge?  As far H as backup, that depends on the amount of data, not the size of the disk E (unless you are doing backup/physical).  Or are you splitting shadow  I sets for backups?  If so, then, this being a controlled process, you can  
 use minicopy.    ------------------------------  + Date: Thu, 16 Feb 2006 20:08:56 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) ? Subject: Re: LD devices in shadowsets on fault tolerant cluster ( Message-ID: <dt2m4n$nm9$1@pcls4.std.com>  ' "Chris" <catsoup57@hotmail.com> writes:      >$ set noon   * >$ reply/term=opa0 "Mounting DSA1 members"    >$ mount /system $1$dka100 data1    >$ mount /system $1$dkb100 data2    >$ mount /system $3$dka100 data3  2 >$ reply/term=opa0 "Connecting DSA1 Logical disks"  : >$ ld connect /share /log $1$dka100:[000000]data1.dsk lda1 >/alloclass=100   : >$ ld connect /share /log $1$dkb100:[000000]data2.dsk lda2 >/alloclass=100   : >$ ld connect /share /log $3$dka100:[000000]data3.dsk lda3 >/alloclass=100   " >$ reply/term=opa0 "Mounting DSA1"  B >$ mount /system dsa1 /shadow=($100$lda1,$100$lda2,$100$lda3) data  ( >$ reply/term=opa0 "Finished DSA1 mount"  D Ugh.  This is ugly.  The way shadowing is designed, each member mustF be accessible to all nodes mounting the set, either directly connectedE or MSCP served to it.  But if you think about this carefully, this is F really not the case.  LDA1: on Node 1 is a different device than LDA1:E on Node 2.  However, since they are mapped to the same container file I each LDA1: will contain the same data.  So they are the same, yet not the , same.  Maybe this is the problem, maybe not.  G Another issue is whether the file system tries to cache the data on the G container files.  I'm not familiar with how LD drivers work and if they E know to disable the caching on the container files.  If the container F files are cached, the following can happen:  Shadowing on Node 1 readsB data from LDA1:  That block read on data1.dsk is cached on Node 1.G Node 2 writes the same block with different data.  The data on the disk K (both the LD disk and on the physical disk) is the new data.  Shadowing on  F Node 1 reads the same block again, but because it's still in Node 1's K container file cache, it gets the _old_ data.  I will tell you that if the  E SCB on the LD drives get cached like this, shadowing will get _real_  	 confused.    ------------------------------  # Date: Thu, 16 Feb 2006 22:41:32 GMT # From: hoff@hp.nospam (Hoff Hoffman) ? Subject: Re: LD devices in shadowsets on fault tolerant cluster 2 Message-ID: <wc7Jf.3273$mw7.1792@news.cpqcorp.net>  k In article <1140109201.407295.165200@g14g2000cwa.googlegroups.com>, "Chris" <catsoup57@hotmail.com> writes: C :The database fits quite easily in 2Gb. Unfortunately, the smallest F :disks we were able to get were 36Gb. This causes us problems with the0 :time taken to do shadow copy/merge and backups.  F   I would be interested in why the configuration is encountering theseG   merges and these copies; I'd not expect these to be arising in normal E   operations.  Are nodes crashing, or are the nodes hard-halting, or  %   are there network stability issues?   4   I'd also be looking at host-based mini-merge, too.  E :After hunting around I discovered the accepted way of 'partitioning' F :VMS disks is to use LD devices. I have installed LD version 8 on eachG :node. Each node then creates 3 LD devices using files from MSCP served G :disks, and mounts a cluster wide shadowset using them. Here is the DCL  :they each run :  >   Use of LD for shadowing as a way to avoid shadowing copy and=   shadowing merge times is probably not the approach I'd have    first chosen.     N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------G        Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[\0100]hp.com    ------------------------------  % Date: Thu, 16 Feb 2006 17:37:06 -0500 - From: William Webb <william.w.webb@gmail.com> ? Subject: Re: LD devices in shadowsets on fault tolerant cluster I Message-ID: <8660a3a10602161437q77eb0c34p184885e3c64ae23a@mail.gmail.com>   C On 16 Feb 2006 09:00:01 -0800, Chris <catsoup57@hotmail.com> wrote: I > Here as Jaguar cars we are trying to deploy a new VMS cluster. We use a C > three member shadowset for our application database.  The cluster I > consists on 3 OpenVMS7.3-2 nodes, running on 2 DS25's and a DS15 quorum 	 > keeper.  > D > The database fits quite easily in 2Gb. Unfortunately, the smallestG > disks we were able to get were 36Gb. This causes us problems with the 1 > time taken to do shadow copy/merge and backups.  >   0 I'll trade you some fours for some thirty-sixes.# Dead serious.  Any day of the week.   $ I've even got some of the blue ones.   How many do you want to trade?   : ^  )   WWWebb   --C NOTE: This email address is only used for noncommerical VMS-related  correspondence. C All unsolicited commercial email will be deemed to be a request for 8 services pursuant to the terms and conditions located at# http://bellsouthpwp.net/w/e/webbww/    ------------------------------   Date: 16 Feb 06 14:11:45 EST) From: cook@wvnvms.wvnet.edu (George Cook) ' Subject: Re: MOSAIC problem (GIF image) ! Message-ID: <NvTVD0vJQyGq@wvnvms>   \ In article <43F403B0.9E85E38B@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:2 > FYI, this is what decw$utils:xdpyinfo.exe says:  >  > $ run xdpyinfo > name of display:    _WSA1: > version number:    11.0 8 > vendor string:    DECWINDOWS DigitalEquipmentCorp. VAX  > vendor release number:    70015 > maximum request size:  4096 longwords (16384 bytes)  > motion buffer size:  06 > bitmap unit, bit order, padding:    32, LSBFirst, 32 > image byte order:    LSBFirst * > number of supported pixmap formats:    4 > supported pixmap formats: 0 >     depth 1, bits_per_pixel 1, scanline_pad 320 >     depth 4, bits_per_pixel 8, scanline_pad 320 >     depth 8, bits_per_pixel 8, scanline_pad 322 >     depth 24, bits_per_pixel 32, scanline_pad 32* > keycode range:    minimum 8, maximum 255 > number of extensions:    8 >     MIT-SUNDRY-NONSTANDARD >     DEC-Server-Mgmt-Extension  >     ServerManagementExtension  >     Adobe-DPS-Extension 
 >     X3D-PEX 	 >     Xie  >     DEC-XTRAP  >     Multi-Buffering  > default screen number:    0  > number of screens:    1  >  > screen #0:9 >   dimensions:    1280x1024 pixels (433x346 millimeters)   A Obviously the screen dimensions are not the limit.  Unfortunately C I don't have a clue as to how to determine what the limits actually @ are (if there even is a way to do so).  My next shot in the darkB would be to guess that the lowest resolution supported by the cardB is the limiting factor.  I suspose Mosaic could incrementally down@ scale failing images until they are displayable, but the code isA not currently structured in a way which would make that easy (the E failure occurs well after the point where rescaling normally occurs).   C BTW, I believe xv works because it doesn't use a pixmap to draw the  image on the display.      George Cook  WVNET    ------------------------------  % Date: Thu, 16 Feb 2006 22:08:54 -0500 * From: "FredK" <fred.nospam@nospam.dec.com>' Subject: Re: MOSAIC problem (GIF image) , Message-ID: <43f53e47$1@usenet01.boi.hp.com>  B I don't know all the strings.  Just make sure it doesn't match the Alpha/Itanium strings.  L As to your follow up to JF about size... in fact I think you *can* depend onK the server to be able to handle a pixmap the same size as the resolution as L a minimum (the rule of thumb was enough offscreen memory to support a pixmapE equal to the sie of the onscreen display).  So if it says 1024x768 or K 1280x1024 - you *should* be able to count on the ability to create a pixmap : of that size.  What you can't predict is the maximum size.  A Most VAX workstations had a very limited set (if not a single) of  resolutions.    6 "George Cook" <cook@wvnvms.wvnet.edu> wrote in message news:eam0lys4hj8v@wvnvms... 6 > In article <43f37ef1$1@usenet01.boi.hp.com>, "FredK"$ <fred.nospam@nospam.dec.com> writes:: > > "George Cook" <cook@wvnvms.wvnet.edu> wrote in message > > news:cIeyPZoRhAEw@wvnvms... 7 > >> In article <43F31CEA.6D37E8A3@teksavvy.com>, JF Me * > > <jfmezei.spamnot@teksavvy.com> writes:; > >> > http://www.nwtel.ca/images/operatingArea/mapFull.gif  > >> >L > >> > On Mosaic 3.8 VAX, the image doesn't show, I get a rectangle with theB > >> > mosaic logo and the name of the sys$scratch temporary file. > >> >E > >> > Any reason why Mosaic can't handle this particular GIF image ?  > >>B > >> Works fine for me, but its size (1200x780) may be causing theA > >> problem.  Mosaic has both automatic (hardware) and parameter C > >> image size limits.  What display card are you using?  What are D > >> the preference settings for MAXPIXMAPWIDTH and MAXPIXMAPHEIGHT?B > >> If MAXPIXMAPWIDTH and MAXPIXMAPHEIGHT are both zero, then theB > >> automatic hardware limits have kicked in.  Some display cards@ > >> limit the size of pixmaps to the dimensions of the display. > >>F > >> Unfortunately the documention (from HP/Compag/DEC) on which cardsG > >> are limited this way doesn't exist as far as I can tell, so Mosaic 5 > >> has to attempt to detect the problem on the fly.  > >> > > L > > The limit for all VAX graphics except the LCG (VS4000 built-in graphics) isH > > the amount of available offscreen memory, which since this varies by deviceI > > and by resolution settings isn't easy to be specific about.  The rule  for I > > VAX graphics was there had to be enough offscreen memory available to I > > allocate a pixmap of the same size as the screen.  The VS4000 can use  "real"K > > system memory as offscreen memory, so on it the size can be adjusted by  some > > obscure logical name.  > > I > > The historical reason for this was the belief that drawing to PIXMAPs  neededC > > to be fast (as fast as drawing to the screen) by the DECwindows 
 developersG > > (during X11R1-beta timeframes).  The rest of the world decided that  using J > > CFB for PIXMAPS was good enough - which makes the limit server virtualI > > memory address space.  When we ported to Alpha, we joined the rest of  the 
 > > world. > J > Would I be going too far wrong if I used the following code to determineI > if a display is one which needs its pixmaps limited to the screen size? F > The code is used by Mosaic to determine if a server needs a limit on > image clipping transitions.  > - >         Display *dsp = XtDisplay(toplevel); / >         char *serverName = ServerVendor(dsp);  > F >         /* Force enable of max_clip_transitions if a VAX X-server */2 >         if ((strstr(serverName, "DECWINDOWS") &&+ >                strstr(serverName, "VAX")) I >         /* Force enable of max_clip_transitions if a Multia X-server */ 4 >            || (strstr(serverName, "DECWINDOWS") &&1 >                strstr(serverName, "eXcursion")) J >         /* Force enable of max_clip_transitions if a VXT2000 X-server */4 >            || (strstr(serverName, "DECWINDOWS") &&0 >                strstr(serverName, "VXT 2000"))K >            || (!strcmp(serverName, "DECWINDOWS DigitalEquipmentCorp.") && / >                (VendorRelease(dsp) == 11))) {  >  >             ...  >         }  >  > 
 > George Cook  > WVNET    ------------------------------  % Date: Thu, 16 Feb 2006 23:50:48 -0500 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>' Subject: Re: MOSAIC problem (GIF image) - Message-ID: <43F5561C.832E5ED9@vaxination.ca>    FredK wrote:* > As to your follow up to JF about size...  0 Don't they always say that size doesn't matter ?    G > equal to the sie of the onscreen display).  So if it says 1024x768 or M > 1280x1024 - you *should* be able to count on the ability to create a pixmap < > of that size.  What you can't predict is the maximum size.    A That particular image is 1200*780, my screen is bigger than that. 5 However, I did have other windows opened at the time.    OK, just did another test:  G For my problem, MOSAIC was running as a spwn/nowait subprocess of a job H that also ran allin1 as well as a DCL process running on a 4000-600 with* the decw$display set to a VAXstation 3100.  F I just tried to run it as a detached process on the 3100 (displayed on) the 3100) and the image came up properly.   G And at the same time, ran it as a detached process on the 4000-600 with G the target to the 3100 and it also ran properly with the same image now E displayed twice (once by the window controlled by the 4000 and one by # the window controlled by the 3100).   D So looks to me like not a pixmap issue but lack of available process quota/virtual memory.    ------------------------------    Date: 16 Feb 2006 14:29:27 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) 7 Subject: Re: OpenVMS needs biometric/smart card logins! 3 Message-ID: <3F$8bR2yrZuF@eisner.encompasserve.org>   V In article <45jph3F74r6iU1@individual.net>, Paul Sture <paul.sture@bluewin.ch> writes: > Larry Kilgallen wrote:_ >> In article <43F41BD3.BD1FC103@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:  >>   >>  C >>>Cloning your debit card only causes you (or bank) loss of money. H >>>Fraudulent use of your fingerprints can frame you for crimes and land >>>you in jail.  >>   >>  L >> If you trust the laws in some countries less than others, don't go there. >> Just like car dealers.  > F > Cough. Splutter. Have you actually found a car dealer you can trust?  2 Actually, yes.  It controlled the choice of brand.   ------------------------------    Date: 16 Feb 2006 12:06:21 -0800) From: "Sue" <susan_skonetski@hotmail.com> : Subject: Re: Updated OpenVMS Information - OK for externalC Message-ID: <1140120381.658935.112510@g47g2000cwa.googlegroups.com>   - No he is still here alive and well and coding    sue    ------------------------------    Date: 16 Feb 2006 14:05:20 -0800* From: "Alan Greig" <greigaln@netscape.net>: Subject: Re: Updated OpenVMS Information - OK for externalC Message-ID: <1140127520.144449.265530@g47g2000cwa.googlegroups.com>   
 Sue wrote:/ > No he is still here alive and well and coding    Good to hear!!   Thanks Sue.    --  
 Alan Greig   ------------------------------   End of INFO-VAX 2006.095 ************************                    Tqnmoz4W4T/is(ɦ4"gw˝4
h&\i&"Yr%+MaFnhfFZ\
p7.~JBul!4B+sIv	b6nIAoQVD>))O2/O*jq¥W4QJthoo~LGXUHO~/
_A=#Ray, 'NeO<f
y1Y:Ѵu.K$^4vnAs{Hkv^nBXO|AX+w4iOsϳB	d8Hmx|;,Ow²jI{DZ&Mn*$4=6OAY**?Y?3rg-.L"&B6JãG0`S9>QBx^qu{
Cw)lo -vi"N!Jxt]x_ޏY|1(+?Bx"O5&U?c)R8{JqC0:nV#zaA<&L蔚vlGȃmWLy˺?ϨR:,;UBA-2hqN9ͩ>=KwfIYv3(gxނ:L|"FwPe.S-;(ٍ(/o+O]<H 7Fu78	>Uj<]o!O<y:r3D\1pa#RoLOZ-s~:Qnsbʂ]c G>._z9Q63([a}id[&9-SS1ʞfk<o2▹2%겸\
3Dh7PSS#<pyo?Ό)^Z֍83SKcdPR#mCR}nBH&y#"gKΏ_b׊LtdF Z76힎GHw9|D2ۓ
EM$U\`qoT"U	'(6Xa2hAV pKRYrG/tgf"
O*>-A4"z$Dmq4Iqٸ^I(ݾ=m$$y5?gzg-÷R'.IC%6Gr
.YUKvd[#_$_aVS6a~_Q9/\}%BO[?0X\:c׆hOVĀʖK
O6ݬnuQ}n;ň>ĺŏ(4J`xDﺛlW\4GE1|{thk"$ՐI'GT&l.Kz\-ESlfGS&b?Z,LI`6<@1CDĝ+CE'^!f81ZOj-XL:xZ`/,+K>\v;uK6V77;kf4VtU1Q]z
R
,H{y2qz>1ޝ˧NCXX_"_\N[&i)l=>U	V򜴒XY"B(./ӕ&ĂwE<<ݛl_[뮭zrb ޖܷPAʁKlD.մ;߄_|f:PHPsT*{v`@lrƄ`:AH9~lO6H!=酲E{-SĂB)kx<-yEJjs[i/
=KVg|$scI#$&MFb
biw˙@IBܤ	890ɪ
eJf:w%A1s{4<P./xjKIYp}9#bn(dV~ђRx4ǥ{4CznBrӇ\K
<Smrg4^0*$qC3z})rIky44#Wz
zigScJvmܓ+n	6eeyw7̭"}psA-
q\ݠgANrNP8aƀ|3_qZTBhxB˾|':ȃ]pY_zggߎ<,򶥎(hrUow閫h'̵T38	ثC1]O*7ߏ{п,Z0^w
;+,"~Vb,¦$+gJ4!
"@ѰQQ3{9g~hA]ƛ8ܞ*ѭ&cpAPSy(!Ϝc3BD	܏uR#h}_ZM㥣凔hڛ'f5[T:^(i;+v f9}+<8-&]L&' <+sHHͤ\r
GRېØa҂{n=*V	6⤅(
Ԇ|FKIŖMt%<1'QAw
ёXQ,>j"h%2%FGxemW|5ku٭**bb)ŪVjVIVI_-+BctSq )[~M8tMi{CwO9Qb< NB
I{[T2mK3[SWrAsjbyƍuQIV`rF<hl,kkmǔulBޒ0*S
:o#m
+Vd{[MF_Lά
c~l q9Kάgә.ۅFӷ-V]lE*j5+j9ɬfӊ
Y&/G=bv!#,k0TݦxDBk9QNinяATِGS{V tL 844id4=	QiY$w1Qך~ch%q6*m')tf7NO*VF@lM/';H
&svK,<Ⳟ_+rK"&mo+g[H2)eJ.i-s0l5:1׶&;BwimZ}+.ߋ
1mp)rp5hqIJ|خ|^mjl&	B*%z o9%b-`kx}'8@XvB~.<4
Ts &F44}k%Ɋ+oc;d\b#[~}VOxojF.SߩtԈ!bJ0GLpKCԸHwD