1 INFO-VAX	Fri, 19 May 2000	Volume 2000 : Issue 278       Contents: Re: "Modern" OpenVMS?  Re: "Modern" OpenVMS?  Re: "Modern" OpenVMS?  Re: "Modern" OpenVMS?  Re: "Modern" OpenVMS?  Re: "Modern" OpenVMS?  Re: "Modern" OpenVMS?  Re: "Modern" OpenVMS?  Re: "Modern" OpenVMS?  Re: "Modern" OpenVMS?  Re: "Modern" OpenVMS?  Re: "Modern" OpenVMS?  Re: "Modern" OpenVMS?  Re: "Modern" OpenVMS? + ANNOUNCEMENT: MegaPOV-Ray v0.5 For OpenVMS.  Re: Backup image problem Re: big Fortran data file  Re: CPU Temperature from DCL RE: EDT macros Re: Error on SMTP A Re: Geting Temperature from CA (was Re: CPU Temperature from DCL)   Re: How do you search for files? Re: I can no longer backup Re: LAT over fiber problemH LINKING F90 programs leads to "multiply defined" and "undefined" CMA$TIS Re: Linux ==> Free VMS Re: Linux ==> Free VMS- Re: Linux port question. $QIOW() to sendto(). - Re: Linux port question. $QIOW() to sendto(). 2 Re: Linux, Unix to VMS VT220 emulation - solution. login.com and FTP? Re: login.com and FTP? Re: MicroVAX, MS and RD53 disks  Re: MicroVAX, MS and RD53 disks  Re: MicroVAX, MS and RD53 disks  Re: multia communication port  Re: PTD's on VMS 5.x Re: Ultrix for mVax3100 ?  Re: Ultrix for mVax3100 ? " Re: Utility to track device errors" Re: Utility to track device errors" Re: Utility to track device errors" Re: Utility to track device errors+ Re: VMS 5.2 DCL treats &symbol unexpectedly ) Re: VMS and Ole for Process Control (OPC)  Re: VMS File Modes VMS for a rack-mount cluster Re: VMS on the desktop?  Re: VMS on the desktop?  Re: VMS on the desktop?  Re: VMS on the desktop?  Re: VMS on the desktop?  Re: VMS on the desktop?  Re: VMS on the desktop?  Re: VMS on the desktop?  Re: VMS on the desktop?  Re: VMS on the desktop?  Re: VMS on the desktop?  Re: VMS on the desktop?  Re: VMS on the desktop?  Re: VMS on the desktop?  Re: VMS on the desktop?  Re: VMS on the desktop?  Re: VMS on the desktop? = Re: Wildfire Announcement: Michael Capellas, can you say VMS? = Re: Wildfire Announcement: Michael Capellas, can you say VMS? = Re: Wildfire Announcement: Michael Capellas, can you say VMS? = Re: Wildfire Announcement: Michael Capellas, can you say VMS? = Re: Wildfire Announcement: Michael Capellas, can you say VMS? = Re: Wildfire Announcement: Michael Capellas, can you say VMS? ! Re: Windows 98 Vs. Windows NT 4.0 . Re: Windows Front End to VT Based Applications  F ----------------------------------------------------------------------  % Date: Thu, 18 May 2000 15:05:25 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>  Subject: Re: "Modern" OpenVMS?( Message-ID: <8g1eoj$p4j$1@pyrite.mv.net>  = David Mathog <mathog@seqaxp.bio.caltech.edu> wrote in message & news:8g16cv$4h9@gap.cco.caltech.edu...E > Having just been bitten on the butt AGAIN by a 16 bit limit ( DEC C  write() I > won't move >64K worth of data over TCP/IP due to some funky interaction H > with a QIO) I'm beginning to wonder if we're ever going to see OpenVMSH > dragged into the 21st century.  I know we're going to hear the refrainL > about resources being limited, but near as I can tell that's still becauseE > most of the money taken in on OpenVMS products is being diverted to  support J > development elsewhere in the company.   We'll also hear that "not enoughI > people asked for this", which more than anything else suggests that the F > "suggestion box" funneling requests into OpenVMS engineering is well	 > hidden.   J Or that people have just given up:  'the patience of Job' is a phrase that comes to mind.  @ A change in mindset at Compaq is likely the only hope.  But moreI encouragement from the user base might increase the probability of such a  change.    > A > Be all of that as it may, can any of the folks at Compaq answer  officially, C > or at least speculate wildly, on the chances that we'll ever see:  > I > 1.  RMSng  (64 or at least 32 bit records).  RMSng is long overdue - it H > should have been phased in circa 1990, and its absence in 2000 is justH > ridiculous.  This would be a backwards compatible change - new systemsK > could read older RMS16 files, but older systems would not need to be able I > to read RMSng files.  I would accept having to relink or even recompile E > everything on my system to obtain this functionality, so long as it 5 > requires no additional compiler switches.  That is:  >  > $ cc program > $ link program > H > and PROGRAM is now rid of QIOs (unless they were called explicitly, of
 > course.)  J Since record-oriented operations tend to require that the entire record beH present in memory, the need for 64-bit records seems questionable in theJ foreseeable future, and, even now, the current 15-bit size limit for fixedL and variable record formats seems likely only occasionally inconvenient saveL perhaps in sequential files (and for such cases, block I/O usually isn't allB that hard to substitute, though admittedly perhaps annoying).  ButF eliminating any limit on *stream* format 'record' lengths shouldn't beE horrendously difficult, and might address the most pressing concerns.    > I > Among the obvious benefits this would (finally!) result in a completely L > Unix compatible streamlf file.  It would offer an opportunity to introduce% > the missing "streamcrlf" file type.  > L > RMSng would also be a good place to phase in file caching in memory, whichH > would greatly improve the performance of OpenVMS systems in the common > processing modes like: > L >   $! require that all data be written to disk within 3 minutes of enteringL >   $!   the cache, but wait at least 2 minutes, if possible, before writing >   $!   anything B >   $ set rms/cache=(maxholdtime=00:03:00.00,waittime=00:02:00.00) >   $ cc module.c % >   $ lib/object mylib.olb module.obj  >   $ delete module.obj. >   $! etc.  > I > In this instance file caching would eliminate entirely the write of the K > small temporary file "module.obj" file to disk.  This would speed up this K > particular process and would not slow down others which really do need to E > get their data out onto disk.   That is, this type of optional file  caching G > is a win/win option for performance on OpenVMS systems as the process  using J > it goes faster, and processes contending with it for disk access also goK > faster. (Setting maxholdtime to 0 would disable the cache, leaving things L > exactly as they are in current versions of OpenVMS, for applications which1 > really need to get their data onto disk "now".)   L I doubt that it is possible to incorporate the above feature into RMS (whichH uses process-level rather than kernel buffering and has no way pass fileG content information from one file open to the next without sending that L information to the XQP):  it would likely have to be implemented in the XQP,I possibly with parallel RMS enhancements to avoid having to buffer at both  levels to achieve its benefits.   I My own belief is that considerably more sweeping enhancements to both RMS J and the XQP will be required to maintain a lead over the rest of the worldH for a significant period of time.  It would be nice to be able to retainE existing facilities so that the new ones could be unburdened with the I barnacles accumulated over the past 2+ decades, but there may be a lot of J people who would prefer more than mere 'cultural compatibility' in the new	 versions.    - bill   ------------------------------  % Date: Thu, 18 May 2000 15:28:29 -0400 " From: Dan Sugalski <dan@sidhe.org> Subject: Re: "Modern" OpenVMS?8 Message-ID: <4.3.1.0.20000518152658.021b51a0@24.8.96.48>  . At 04:39 PM 5/18/00 +0000, David Mathog wrote:L >Having just been bitten on the butt AGAIN by a 16 bit limit ( DEC C write()H >won't move >64K worth of data over TCP/IP due to some funky interaction >with a QIO)  G No offense, but so what? There isn't a wire protocol out there that'll  K support packets even close to 64k that I know of, so its not like there'll   be UDP splitup issues.  J If it'll help, I can throw together a quick piece of wrapper code that'll L give you a write that looks like it sends any size of data but chunks it up @ anyway. (I need it for perl, so no reason not to make it public)   					Dan  I --------------------------------------"it's like this"------------------- 2 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and even ;                                       teddy bears get drunk    ------------------------------  # Date: Thu, 18 May 2000 20:18:58 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)  Subject: Re: "Modern" OpenVMS?0 Message-ID: <009EA46D.3C204C4E@SendSpamHere.ORG>  ] In article <4.3.1.0.20000518152658.021b51a0@24.8.96.48>, Dan Sugalski <dan@sidhe.org> writes: / >At 04:39 PM 5/18/00 +0000, David Mathog wrote: M >>Having just been bitten on the butt AGAIN by a 16 bit limit ( DEC C write() I >>won't move >64K worth of data over TCP/IP due to some funky interaction 
 >>with a QIO)  > H >No offense, but so what? There isn't a wire protocol out there that'll L >support packets even close to 64k that I know of, so its not like there'll  >be UDP splitup issues.  > K >If it'll help, I can throw together a quick piece of wrapper code that'll  M >give you a write that looks like it sends any size of data but chunks it up  A >anyway. (I need it for perl, so no reason not to make it public)   H Whah, whah!  Mommy, it doesn't look or feel or smell or work *just* like) unix so VMS is defective and neanderthal.   H Dan, it's not worth it.  You will never please some folks unless VMS wasH to be spelled unix, all of its vowels were removed, and help was uselessH unless you knew exactly what you needed help on, but then that's sort of* self-defeating of help's purpose isn't it?  I When the unix (and NT) crowd can show me a "cluster" of more than 2 nodes I and both of them are actually doing something, then I might be more open  8 to the belly-aching anout VMS not having unixy features.   --N VAXman- OpenVMS APE certification number: AAA-0001           VAXman@TMESIS.COM  L GNU Freeware -- What does the GNU *really* stand for?  Garbage!  Not Usable!   ------------------------------  % Date: Thu, 18 May 2000 16:33:22 -0400 " From: Dan Sugalski <dan@sidhe.org> Subject: Re: "Modern" OpenVMS?8 Message-ID: <4.3.1.0.20000518162818.021c0bc0@24.8.96.48>  ? At 08:18 PM 5/18/00 +0000, Brian Schenkenberger, VAXman- wrote: G >In article <4.3.1.0.20000518152658.021b51a0@24.8.96.48>, Dan Sugalski   ><dan@sidhe.org> writes:1 > >At 04:39 PM 5/18/00 +0000, David Mathog wrote: O > >>Having just been bitten on the butt AGAIN by a 16 bit limit ( DEC C write() K > >>won't move >64K worth of data over TCP/IP due to some funky interaction  > >>with a QIO)  > > I > >No offense, but so what? There isn't a wire protocol out there that'll M > >support packets even close to 64k that I know of, so its not like there'll  > >be UDP splitup issues.  > > L > >If it'll help, I can throw together a quick piece of wrapper code that'llN > >give you a write that looks like it sends any size of data but chunks it upC > >anyway. (I need it for perl, so no reason not to make it public)  > I >Whah, whah!  Mommy, it doesn't look or feel or smell or work *just* like * >unix so VMS is defective and neanderthal.  L No, more like "Stupid machine! Do what the heck I want!" Limits suck. While C I personally dislike the C I/O system (it's pretty pathetic--fully  G synchronous I/O is for weenies) it's something I have to work with, so  ( making it work better's not a bad thing.  E Some day I might go so far as to make it really async under the hood  L (queueing up reads and writes when buffers drain or fill too much), but not K this week. Be cool to watch all the Unix folk boggle at exactly how fast a  C simple perl program can sling data around... (The C RTL is the big  2 bottleneck here, as it is in so many other places)  I >Dan, it's not worth it.  You will never please some folks unless VMS was I >to be spelled unix, all of its vowels were removed, and help was useless I >unless you knew exactly what you needed help on, but then that's sort of + >self-defeating of help's purpose isn't it?   E Well, far be it for me to stop a good bitter rant (quite fond of 'em  K personally... :), in this case it's not that unreasonable. And, as I said,  < I need the code *anyway*, so there's no reason not to share.   					Dan  I --------------------------------------"it's like this"------------------- 2 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and even ;                                       teddy bears get drunk    ------------------------------   Date: 18 May 2000 21:26:54 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog) Subject: Re: "Modern" OpenVMS?, Message-ID: <8g1n6u$isd@gap.cco.caltech.edu>  ] In article <4.3.1.0.20000518152658.021b51a0@24.8.96.48>, Dan Sugalski <dan@sidhe.org> writes: / >At 04:39 PM 5/18/00 +0000, David Mathog wrote: M >>Having just been bitten on the butt AGAIN by a 16 bit limit ( DEC C write() I >>won't move >64K worth of data over TCP/IP due to some funky interaction 
 >>with a QIO)  > H >No offense, but so what? There isn't a wire protocol out there that'll L >support packets even close to 64k that I know of, so its not like there'll  >be UDP splitup issues.   D The "what" is that write() on other OS's when presented with a largeC buffer writes out as much as it can and returns the number of bytes C written, so you can go around again in a loop until it's all sent.  D That's exactly what netpipe does, here's the relevant code section:    void SendData(ArgStruct *p)  {       int bytesWritten, bytesLeft;     char *q;       bytesLeft = p->bufflen;      bytesWritten = 0;      q = p->buff;     while (bytesLeft > 0 && ?            (bytesWritten = write(p->commfd, q, bytesLeft)) > 0)        { "         bytesLeft -= bytesWritten;         q += bytesWritten;       }      if (bytesWritten == -1)        { G         printf("NetPIPE: write: error encountered, errno=%d\n", errno);          exit(401);       }  }   F On  OpenVMS write() is broken at the QIO limit - it bombs out when theC buffer size is >64k.  If it just sent 64k, or 32k, or hell, 2k, and E returned with that value everything would be hunky dory and the code  8 listed above would work. Instead it comes back with -1.   . So I guess there are really two problems here:  I 1.  The QIO limit is only 64k (which is small enough that it's likely to  A     trigger this problem with normal sorts of data, for instance,      a DNA sequence.)E 2.  decc$write() is brain damaged and doesn't know how to write a big      buffer given the QIO limit.   $ 1. is an inconvenience, 2. is a bug.   Regards,   David Mathog mathog@seqaxp.bio.caltech.edu ? Manager, sequence analysis facility, biology division, Caltech  J **************************************************************************J *                                RIP VMS                                 *J **************************************************************************   ------------------------------  # Date: Thu, 18 May 2000 21:56:19 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)  Subject: Re: "Modern" OpenVMS?0 Message-ID: <009EA47A.D5BB5D73@SendSpamHere.ORG>  ] In article <4.3.1.0.20000518162818.021c0bc0@24.8.96.48>, Dan Sugalski <dan@sidhe.org> writes: @ >At 08:18 PM 5/18/00 +0000, Brian Schenkenberger, VAXman- wrote:H >>In article <4.3.1.0.20000518152658.021b51a0@24.8.96.48>, Dan Sugalski  >><dan@sidhe.org> writes: 2 >> >At 04:39 PM 5/18/00 +0000, David Mathog wrote:P >> >>Having just been bitten on the butt AGAIN by a 16 bit limit ( DEC C write()L >> >>won't move >64K worth of data over TCP/IP due to some funky interaction >> >>with a QIO) >> >J >> >No offense, but so what? There isn't a wire protocol out there that'llN >> >support packets even close to 64k that I know of, so its not like there'll >> >be UDP splitup issues. >> >M >> >If it'll help, I can throw together a quick piece of wrapper code that'll O >> >give you a write that looks like it sends any size of data but chunks it up D >> >anyway. (I need it for perl, so no reason not to make it public) >>J >>Whah, whah!  Mommy, it doesn't look or feel or smell or work *just* like+ >>unix so VMS is defective and neanderthal.e >SM >No, more like "Stupid machine! Do what the heck I want!" Limits suck. While  D >I personally dislike the C I/O system (it's pretty pathetic--fully H >synchronous I/O is for weenies) it's something I have to work with, so ) >making it work better's not a bad thing.   . ... as do I and its degenerate bretheren, C++.  H Still, instead of griping about a bit of unix code that doesn't port un-H changed into the VMS space, just change the code.  Or better yet, modifyI the code to really make use of VMS features which are lacking in the unixa realm.  H I have been dicking for months with some GNU code (sic?).  I've come to G the realization that if C had a *real* macro language instead of brain-=G damaged token substitution, much of the psychosis surrounding unix codeeG and build procedures would not exist.  If this be how the unix crowd is H building applications then so be it.  I'll stick to a sane and organizedI build environments and code that doesn't require preprocessor/substitute/eH preprocessor/substitute/preprocessor/substitute and finally a compile to	 be built.   F >Well, far be it for me to stop a good bitter rant (quite fond of 'em L >personally... :), in this case it's not that unreasonable. And, as I said, = >I need the code *anyway*, so there's no reason not to share.   E Share away.  I didn't want to come off as if that aspect of your post 
 was an issue.d --N VAXman- OpenVMS APE certification number: AAA-0001           VAXman@TMESIS.COM  L GNU Freeware -- What does the GNU *really* stand for?  Garbage!  Not Usable!   ------------------------------  % Date: Thu, 18 May 2000 18:31:31 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>e Subject: Re: "Modern" OpenVMS?( Message-ID: <8g1qqu$7lo$1@pyrite.mv.net>  H Brian Schenkenberger, VAXman- <system@SendSpamHere.ORG> wrote in message* news:009EA46D.3C204C4E@SendSpamHere.ORG...   ...d  K > When the unix (and NT) crowd can show me a "cluster" of more than 2 nodesnJ > and both of them are actually doing something, then I might be more open: > to the belly-aching anout VMS not having unixy features.  J While I realize that your ignorance may be a great comfort to you, it getsJ tedious correcting it.  However, I will take you at your word above:  if aI turkey can be transformed into a productive member of society, it will be 	 worth it.s  L For starters, you set your bar 'way too low:  even pathetic 2-node fail-overJ NT/W2K 'clusters' (and they'd be pathetic w.r.t. the state of the art evenF if that state had never heard of VMS) can have both nodes doing usefulJ work - they just can't be accessing the same disks (unless they're runningH Oracle Parallel Server, but in that case NT has to share the credit withL Oracle, so it really doesn't count).  One node fails, the other picks up itsL disks (and its work, under application control similar to that required whenD a VMS node fails and other nodes can cover for it); fail-over can beJ relatively quick (a minute or so - unimpressive but generally adequate) asK long as NTFS is used as the file system so no lengthy file system integrityp" scan is required on the take-over.  L Linux cluster approachs abound, but aren't really aimed at high availabilityI (yet), so, while they definitely allow multiple nodes to do useful work -aB and even cooperate on a specific problem - I won't present them as* satisfying what I tend to think you meant.  I Sun clusters come somewhere near competing with VMS clusters on features, K though fall considerably short in elegance and performance.  They share the E same data throughout the cluster, but using NFS (which I likely don't G appreciate any more than you do, but functionally it gets the job done) J rather than a real cluster file system.  Among other things, this severelyF limits their ability to cache data locally in shared-update situationsJ (unlike VMS, though even VMS's ability to cache in a distributed manner isH far from optimal).  They do, however, have effective file and byte-rangeF distributed lock management which can ride through failure of the lockJ server and reestablish the lock context on a new server, so *functionally*C they don't look too bad.  Their file system (which may be a VeritasaK derivative; I'm pretty sure HP's cluster file system is) can be broken into D pieces (which the Unix 'mount' mechanism allows to be reassembled asI sub-trees of a single system-wide directory structure), each managed by aiK single serving node on private disks which can fail over to another node if,L necessary (fail-over takes about a minute - less if it's a planned fail-overJ for, e.g., maintenance purposes).  Until recently I think cluster size wasI limited to 4 nodes, but it may have just increased; in either case, sinceaH each node can be up to a 64-processor SMP, that's perfectly adequate forI server configurations, though doesn't support workgroup-style workstationn clustering as VMS does.   L Tru64 clusters in their newest release (5.0A) ported over a good deal of theG base VMS cluster implementation to replace the considerably less robustsJ prior (V4) approach.  Their file system is home-grown (AdvFS, a journalingH file system written by Chris Saether, one of the primary creators of theE XQP, headed the design and implementation, along with Debbie Girdler, E another long-time DECcie and still, last I knew, Cutler's significantnE other), but was not designed for clustering, so Tru64's 'cluster file L system' is a served, fail-overable design rather than shared-disk (though itJ may just serve meta-data and allow direct shared-disk access to user data:K if anyone happens to know, I'd appreciate details, since information on theiJ system does not seem to be readily available).  Under the file system is aK cluster-aware version of Veritas' Logical Volume Manager, which gives AdvFS K facilities (e.g., on-line capacity increases, transparent data-shuffling to F alleviate hot spots) that ODS-x may lack, and the VMS Distributed LockK Manager was ported largely as-is to allow distributed caching (and the manyaL other non-file-system-related jobs it also does).  And since the platform is3 Alpha, you already know its range and capabilities.g  K If you're looking for clustering implementations more than a few years old,aG try AIX on IBM's RS/6000 SP:  they used to call it a massively-parallel L architecture until 'clustering' became respectable.  It started out aimed atJ high-end scientific applications, and the largest cluster in the field hasJ (I believe) 512 nodes, each of which is an SMP, but it works just fine forJ commercial applications too.  The traditional file system on it (JFS) is aJ journaling, served-data, fail-over implementation, but recently they addedI GPFS, which supports shared-disk access (actually, 'virtual shared disk',eL which is pretty much identical to a private VMS disk that its host serves toF the rest of the cluster at the disk-access level as a 'cluster disk').  B Or for clustering arguably older than VMS's, there's Tandem:  it'sF 'loosely-coupled' multi-processor availability environment effectivelyK constitutes a cluster, in which all nodes can perform productive work whilevF remaining ready to pick up that of a failed comrade, and over time theG emphasis on scalability has come to equal that devoted to availability.i  J How about third-party implementations?  Veritas markets a suite of clusterG products that can make just about anyone's Unix clusterable (I think HPsL pretty much relies on them instead of any home-grown code, and it's possibleE that Sun may at least in part as well; don't know much about SCO Unix F clustering, but it could too).  IBM sells 'extensions' for Microsoft'sJ cluster products that may significantly extend them (my impression is thatJ they may be in part based on IBM's portable 'Phoenix' cluster architectureJ that it developed a few years ago).  Compaq/Digital used to sell something- called clustering on NT, but that's now gone.c  L And since imitation is the sincerest form of flattery, it would be negligentL to leave out IBM's System/390 Parallel Sysplex, a shared-disk implementationJ every bit as much as VMS's is, though in the mainframe idiom (hey, RMS was8 modeled in many ways on VSAM, so it can't be *all* bad).  J And yes, all of the above examples save for NT/W2K and maybe Linux supportB multiple nodes concurrently reading and updating the same data andI cooperating on the same workload.  W2K, Sun, and Tru64 cluster facilities E (don't know about the others) support IP address take-over to providec5 transparent service continuation to external clients.E  L Do I think that any of the above implementations is superior to VMS's in anyL significant way?  No I do not.  Do I think that many, maybe most of them canL satisfy most customer needs in the area of clustering, albeit perhaps not asK well as VMS can?  Yes I do - and so apparently does most of the rest of theeL world.  *That's* why it's important for VMS to be able to beat them at their= own game:  if it can't, for most purposes it will be ignored.a   - bill   >  > --4 > VAXman- OpenVMS APE certification number: AAA-0001 VAXman@TMESIS.COMo >oF > GNU Freeware -- What does the GNU *really* stand for?  Garbage!  Not Usable!    ------------------------------  % Date: Thu, 18 May 2000 18:35:09 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>h Subject: Re: "Modern" OpenVMS?, Message-ID: <3924700D.692BE930@videotron.ca>  & "Brian Schenkenberger, VAXman-" wrote:J > Whah, whah!  Mommy, it doesn't look or feel or smell or work *just* like+ > unix so VMS is defective and neanderthal.   H Actually, his request isn't so off the wall. Think of the example of theH fellow not being able to print his file because it was stream-lf and oneL record was too large to be printed. Think of the times when you're trying to5 type a file and you get the BUFQUO exceeded message. p  J Wouldn't it be nice if the underlying QIO and RMS stacks would handle suchK situations gracefully  ? A read would provide you with as much data as your K buffer allows, and a write would split your IO request into multiple ones ?-  L I don't think that the 16*32*64 bit is the problem, but rather the quotas on the account.   ------------------------------   Date: 18 May 2000 23:21:33 GMT1 From: JONESD@er6.eng.ohio-state.edu (David Jones)/ Subject: Re: "Modern" OpenVMS?: Message-ID: <8g1ttt$h4f$1@charm.magnus.acs.ohio-state.edu>  , In message <8g16cv$4h9@gap.cco.caltech.edu>,6   mathog@seqaxp.bio.caltech.edu (David Mathog) writes:H >Among the obvious benefits this would (finally!) result in a completelyK >Unix compatible streamlf file.  It would offer an opportunity to introducek$ >the missing "streamcrlf" file type.  H There already is a "streamcrlf" file type, they just called it "stream".  K >RMSng would also be a good place to phase in file caching in memory, which G >would greatly improve the performance of OpenVMS systems in the commonr >processing modes like:   M At the last DECUS they demoed the new file caching system they are working onhH for VMS.  The new system can use any amount of memory (the current cacheF is limited to 2 GB) and the caching policy is highly customizable on aJ per-volume, per-directory, or per-file basis.  One of the options is givesK you is write-back versus write-through caching.  I don't recall if there isd per-process control not.      < David L. Jones               |      Phone:    (614) 292-6929- Ohio State University        |      Internet:oL 140 W. 19th St. Rm. 231a     |               jonesd@er6s1.eng.ohio-state.edu: Columbus, OH 43210           |               vman+@osu.edu  + Disclaimer: Dogs can't tell it's not bacon.s   ------------------------------  # Date: Fri, 19 May 2000 01:43:14 GMT 9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)t Subject: Re: "Modern" OpenVMS?+ Message-ID: <6qs2GS77LGQl@eisner.decus.org>t  \ In article <3924700D.692BE930@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes:( > "Brian Schenkenberger, VAXman-" wrote:K >> Whah, whah!  Mommy, it doesn't look or feel or smell or work *just* likes, >> unix so VMS is defective and neanderthal. > J > Actually, his request isn't so off the wall. Think of the example of theJ > fellow not being able to print his file because it was stream-lf and oneN > record was too large to be printed. Think of the times when you're trying to7 > type a file and you get the BUFQUO exceeded message. - > L > Wouldn't it be nice if the underlying QIO and RMS stacks would handle suchM > situations gracefully  ? A read would provide you with as much data as your M > buffer allows, and a write would split your IO request into multiple ones ?   > I realize you want to either send the excess characters at the; printer or dump them on the floor (I don't care which), butc: you are quite wrong to blame QIO or RMS.  The error quoted9 was an RMS error saying that the data was too big for the4: buffer.  Making the buffer larger is a simple bit of print7 symbiont work, and since lines of characters are rarelyt7 longer than 132 bytes I strongly doubt that the messages8 proves the defective file had a record longer than 327677 bytes, since at the time the print symbiont was written  memory was not that cheap.   ------------------------------  # Date: Fri, 19 May 2000 00:55:29 GMTs= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)i Subject: Re: "Modern" OpenVMS?0 Message-ID: <009EA493.DCF9875E@SendSpamHere.ORG>  a In article <8g1n6u$isd@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu (David Mathog) writes:s^ >In article <4.3.1.0.20000518152658.021b51a0@24.8.96.48>, Dan Sugalski <dan@sidhe.org> writes:0 >>At 04:39 PM 5/18/00 +0000, David Mathog wrote:N >>>Having just been bitten on the butt AGAIN by a 16 bit limit ( DEC C write()J >>>won't move >64K worth of data over TCP/IP due to some funky interaction >>>with a QIO) >>I >>No offense, but so what? There isn't a wire protocol out there that'll =M >>support packets even close to 64k that I know of, so its not like there'll " >>be UDP splitup issues. >;E >The "what" is that write() on other OS's when presented with a largeoD >buffer writes out as much as it can and returns the number of bytesD >written, so you can go around again in a loop until it's all sent. E >That's exactly what netpipe does, here's the relevant code section:    E Well then David, it's not so much a VMS limitation as perhaps a poor iC implementation of the write() in the support run-time.  If write oneE another platform can't output a bazillion bytes in one fell swoop, ituC says it wrote out x and you subtract x from the overall size of thetC data transfer and call it again.  Thus, there may be underlying I/O D size restriction on these other platforms.  You're just experiencing a poorly written C support RTL.c   --N VAXman- OpenVMS APE certification number: AAA-0001           VAXman@TMESIS.COM  L GNU Freeware -- What does the GNU *really* stand for?  Garbage!  Not Usable!   ------------------------------  # Date: Fri, 19 May 2000 00:56:37 GMT*= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)e Subject: Re: "Modern" OpenVMS?0 Message-ID: <009EA494.053FD793@SendSpamHere.ORG>  a In article <8g1n6u$isd@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu (David Mathog) writes:n^ >In article <4.3.1.0.20000518152658.021b51a0@24.8.96.48>, Dan Sugalski <dan@sidhe.org> writes:0 >>At 04:39 PM 5/18/00 +0000, David Mathog wrote:N >>>Having just been bitten on the butt AGAIN by a 16 bit limit ( DEC C write()J >>>won't move >64K worth of data over TCP/IP due to some funky interaction >>>with a QIO) >>I >>No offense, but so what? There isn't a wire protocol out there that'll >M >>support packets even close to 64k that I know of, so its not like there'll > >>be UDP splitup issues. >fE >The "what" is that write() on other OS's when presented with a largeuD >buffer writes out as much as it can and returns the number of bytesD >written, so you can go around again in a loop until it's all sent. E >That's exactly what netpipe does, here's the relevant code section: a  E Well then David, it's not so much a VMS limitation as perhaps a poor nC implementation of the write() in the support run-time.  If write onhE another platform can't output a bazillion bytes in one fell swoop, itsC says it wrote out x and you subtract x from the overall size of theiC data transfer and call it again.  Thus, there may be underlying I/OlD size restriction on these other platforms.  You're just experiencing a poorly written C support RTL.a   --N VAXman- OpenVMS APE certification number: AAA-0001           VAXman@TMESIS.COM  L GNU Freeware -- What does the GNU *really* stand for?  Garbage!  Not Usable!   ------------------------------  + Date: Thu, 18 May 2000 22:52:01 -0400 (EDT)e" From: Dan Sugalski <dan@sidhe.org> Subject: Re: "Modern" OpenVMS?G Message-ID: <Pine.LNX.4.10.10005182248480.1351-100000@tuatha.sidhe.org>o  # On 18 May 2000, David Mathog wrote:   _ > In article <4.3.1.0.20000518152658.021b51a0@24.8.96.48>, Dan Sugalski <dan@sidhe.org> writes:u1 > >At 04:39 PM 5/18/00 +0000, David Mathog wrote:lO > >>Having just been bitten on the butt AGAIN by a 16 bit limit ( DEC C write()aK > >>won't move >64K worth of data over TCP/IP due to some funky interactiona > >>with a QIO)n > >qJ > >No offense, but so what? There isn't a wire protocol out there that'll N > >support packets even close to 64k that I know of, so its not like there'll  > >be UDP splitup issues.o > F > The "what" is that write() on other OS's when presented with a largeE > buffer writes out as much as it can and returns the number of bytes E > written, so you can go around again in a loop until it's all sent. s  F You'd be amazed at how much code freaks out or breaks if write doesn'tF dump its whole contents out in one write. Or, maybe, you wouldn't. :( F Sounds like time for a bug report. (Which reminds me, it's time for myI semi-annual "assle the C RTL people" mail message, I think...) Though I'dvI bet that the standard, whichever standard defines this stuff, doesn't say.J anything about this case. (If it does that wuld be a good incentive to get them to fix it)6  H Just out of curiosity, have you upgraded to the latest C RTL? That thingH seems to change functionality every release, sometimes in a big way, and2 write may well be fixed in its latest incarnation.   				Danh   ------------------------------  % Date: Fri, 19 May 2000 00:56:00 -0400a* From: David A Froble <davef@tsoft-inc.com> Subject: Re: "Modern" OpenVMS?- Message-ID: <3924C960.1CBE95D1@tsoft-inc.com>k   David Mathog wrote:n > M > Having just been bitten on the butt AGAIN by a 16 bit limit ( DEC C write() I > won't move >64K worth of data over TCP/IP due to some funky interactionaH > with a QIO) I'm beginning to wonder if we're ever going to see OpenVMS  > dragged into the 21st century. <snip>I > Among the obvious benefits this would (finally!) result in a completely'L > Unix compatible streamlf file.  It would offer an opportunity to introduce% > the missing "streamcrlf" file type.u  L Gotta point out that it's not VMS or QIO that's chomping on your butt.  It'sP 'C', the language from hell, and apparently rather poor C RTL coding.  So what'sI all that have to do with VMS?  Also, there is already a stream file type.s  L What you can do is write your own library routines, working the way you likeM them to, and link them into your programs.  Don't like the C I/O routines, doeO your own.  One hint, you can determine the quota, write that much with the QIO,eO and return the byte count.  Or, use a better language than C, which is probably  most of the others available.e  L > RMSng would also be a good place to phase in file caching in memory, whichH > would greatly improve the performance of OpenVMS systems in the common > processing modes like: > L >   $! require that all data be written to disk within 3 minutes of enteringL >   $!   the cache, but wait at least 2 minutes, if possible, before writing >   $!   anything B >   $ set rms/cache=(maxholdtime=00:03:00.00,waittime=00:02:00.00) >   $ cc module.cr% >   $ lib/object mylib.olb module.objd >   $ delete module.obj. >   $! etc.  > I > In this instance file caching would eliminate entirely the write of theyK > small temporary file "module.obj" file to disk.  This would speed up this K > particular process and would not slow down others which really do need tooM > get their data out onto disk.   That is, this type of optional file cachingsM > is a win/win option for performance on OpenVMS systems as the process usingyJ > it goes faster, and processes contending with it for disk access also goK > faster. (Setting maxholdtime to 0 would disable the cache, leaving things)L > exactly as they are in current versions of OpenVMS, for applications which1 > really need to get their data onto disk "now".)o  P Not a bad idea.  I do understand that this is already in the works, or something similar.  5 > 2.  Transition from $QIO to $IO_PERFORM everywhere.m > 5 > If this leaves the VAXes out in the cold, so be it.a  4 Easy for you to say!  Bet you're not using VAXs. :-)   Dave   -- n4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.come Vanderbilt, PA  15486e   ------------------------------  % Date: Thu, 18 May 2000 22:45:43 -0500h1 From: Robert Alan Byer <byer@mail.ourservers.net> 4 Subject: ANNOUNCEMENT: MegaPOV-Ray v0.5 For OpenVMS.3 Message-ID: <39247297.3ED15363@mail.ourservers.net>e  ( Announcing MegaPOV-Ray v0.5 For OpenVMS.  H I have completed my port of MegaPOV-Ray for v0.5 for OpenVMS.  CurrentlyH only the Alpha platform is supported as the VAX version of DEC C doesn'tE support the IEEE FLOAT mode.  I am working on a VAX version, but it'su# not top on my list of things to do.h  H In this release there are some speed improvements and new features.  The8 macro code has been fixed and is now working on OpenVMS.  G You can download the OpenVMS version as well as installation directionsf at..  ( 	http://www.ourservers.net/openvms_ports  8 I welcome all e-mail on bugs, problems and improvements.  E (I will be away from Friday till Monday manning a booth at the DaytonMB Hamvention so if there is a problem, I can't fix it until Monday.)   -- a  F  +--------------------------+----------------------------------------+F  | Robert Alan Byer         | "I don't want to take over the world,  |F  | byer@mail.ourservers.net |  just my own little part of it."       |F  | Phone: (317)357-2724     | http://www.ourservers.net/~byer        |F  | PhoneFREE I.D.# 1385299  |                                        |F  +--------------------------+----------------------------------------+F  | Send an E-mail request to obtain my PGP key.        ICQ #65926579 |F  +-------------------------------------------------------------------+   ------------------------------  % Date: Thu, 18 May 2000 20:39:59 -0500e) From: Mike Drabicky <drabicky#dallas.net>h! Subject: Re: Backup image problemt8 Message-ID: <eg69isc3cdj90fnk18hsqt3tnol7u7cirf@4ax.com>  0 On Thu, 18 May 2000 08:52:49 +0000, ezzaoudi med! <m.ezzaoudi@digitem.co.ma> wrote:-  ? >When I try to boot with the target disk , I have the message :d+ >"... block 0 is not a valid boot block..".y? >I have the same message when I put the disk in  another Alpha.o >iH >3- Is there a procedure to make the bloque 0 as " a valid boot block" ?  D The WRITEBOOT.EXE filel will write to boot block out to a given diskE for you. It's the same one that the upgrade/install procedure uses to C do the same thing. I don't remember the syntax exactly but usage iscE easy enough to determine (e.g., search through CLUSTER_CONFIG.COM fort an example).  C As to why BACKUP didn't write a boot block for you, I can't say foreA sure. I've never had a case where a BACKUP/IMAGE of a system diskUD failed to make a bootable system disk. I suppose it could happen but it would be rare.d  
 Mike Drabickyn   ------------------------------   Date: 18 May 2000 21:06:47 GMT0 From: "Dale A. Dellutri" <ddellutr@enteract.com>" Subject: Re: big Fortran data file, Message-ID: <8g1m17$hfg$1@news.enteract.com>  X On 16 May 2000 07:45:26 GMT, in comp.os.vms, Phillip Helbig <helbig@astro.rug.nl> wrote:> > In article <39208048.3AD2E6E3@tsoft-inc.com>, David A Froble  > <davef@tsoft-inc.com> writes: P >>While most of this discussion is far from what I'm used to, now you've asked aH >>question I can help with.  An RMS Indexed Variable file will do what I" >>understand you are asking for.  E > As others have pointed out as well, VMS has long had the solution, nH > albeit non-standard Fortran.  I can't imagine that my need here is so B > specialised; shouldn't F2K+N have indexed variable-length files?  C Some posters have suggested ISAM or indexed variable files for this A use.  I don't think that either is suitable or necessary for youroC problem.  (Wouldn't you have to store the keys in the file for eacht- value, thus increasing the size of the file?)   " You're computing f = f(v,w,x,y,z).  8 You've said that the first four indices, with dimensions= vmax = 200, wmax = 100, xmax = 10 and ymax = 60, are all used'< (like a rectangular array).  The dimension of the last index> is "proportional" to the value of the fourth index.  Two cases> (I'm assuming the dimensions are all 1:max for this analysis):  C Case 1. z's dimension is "proportional" to, but not a simple linearND function of, the fourth index value.  In this case, write two files.D In the first file, the first record is a pointer to the beginning ofC all the results for the f(1,1,1,1,*) values, the second record is ag? pointer to the beginning of the f(2,1,1,1,*) values, and so on.VA The second file contains these values as individual records.  YoueD write them (both fixed record length, unformatted) sequentially like this:l   	i = 1 	do y = 1, ymaxf 	 do x = 1, xmax 	  do w = 1, wmaxe 	   do v = 1, vmax# 	    write (unit=11) i	! First files 	    do z = 1, zmax(y)0 	     write (unit=12) f(v,w,x,y,z)	! Second file 	     i = i + 1 
 	    enddo	 	   enddo  	  enddo 	 enddoe 	enddo  ? When you use the values, you open both files for direct access.wB You get the required value by first computing the record number of" element v,w,x,y in the first file:; 	RN1 = (((y-1)*xmax + (x-1))*wmax + (w-1))*vmax + (v-1) + 1o8 You read this record, which gives you the value i. Then: 	RN2 = i + (z-1)> is the record number of the required value in the second file.  > The first file is probably small enough to keep in memory as a& page-file or disk-file global section.  > Case 2. The dimension of z is a linear function of the value y= (zmax(y) = m*y + b).  You only need one file, which you writex sequentially like this:M   	do y = 1, ymaxo 	 do x = 1, xmax 	  do w = 1, wmaxi 	   do v = 1, vmax 	    do z = 1, m*y + b" 	     write (unit=12) f(v,w,x,y,z)
 	    enddo	 	   enddod 	  enddo 	 enddo" 	enddo  D Again, when you use the values, you open the file for direct access.G Now the record number (RN) of the required value is computed like this:c9 	i = (((y-1)*xmax + (x-1))*wmax + (w-1))*vmax + (v-1) + 1m. 	RN = vmax*wmax*xmax*(m*(y-1)*y/2 + (y-1)*b) +7 	  (i - (y-1)*vmax*wmax*xmax - 1)*(m*y + b) + (z-1) + 1   D Of course, for both of these cases, 4 byte records are too short for? good performance, and, if you are using the full amount of datan@ (3.6e+9 values!), they produce record numbers that are too large@ for FORTRAN direct access (I think).  I'd use 32256 byte records> and use integer division by 32256 and modulo 32256 to find the) record number and offset into the record.i   -- n& Dale Dellutri -- ddellutr@enteract.com   ------------------------------  % Date: Thu, 18 May 2000 16:48:56 -0400m/ From: "Paul A. Jacobi" <Paul.Jacobi@compaq.com>s% Subject: Re: CPU Temperature from DCL|+ Message-ID: <8g1l0r$8r8$1@lead.zk3.dec.com>o  A "Bob Kaplow" <kaplow_r@eisner.decus.org.spamnot> wrote in messagea% news:hnBuwjU7c3c1@eisner.decus.org...mK > Perhaps you can explain something else about the temperature vector. I've H > got an 8400 with 8 5/440 CPUs and a GS140 with 8 6/525 CPUs. Each onlyJ > returns 2 temperatures. They seem to correspond to CPU 3 and 4. WHy only > two, and why these two?V  I I have no explaination for the missing data.  It could be due to either arD hardware or a software bug.  You might try comparing the result fromC DCL to information obtained from the console >>>show power command.e       Paul A. Jacobi Compaq Computer Corporation ! OpenVMS Systems Group, ZKO3-4/U14w 110 Spitbrook Road Nashua, NH 03062-2698m Email: Paul.Jacobi@compaq.come   ------------------------------  # Date: Fri, 19 May 2000 00:19:18 GMTn8 From: DCantor@remove.three.words.shore.net (Dave Cantor) Subject: RE: EDT macros ; Message-ID: <aM%U4.87392$hT2.369659@news1.rdc1.ct.home.com>f  ~ In article <1137A4A23A51D311B2D600105A1D5213019AEE1A@seantexch.unitedad.com>, Terry Marosites <TMarosites@unitedad.com> wrote:J > Does anyone know how to define a gold key  C as  that will insert some aL > line line of text and the date and time  ( example: $! Changed by Terry on- > 16-MAY-2000 14:40:08) .This has me stumped.M  6 Here are 3 differently formatted date insertion codes.% ! Insert date as 29-Jul-1988 14:49:05e> DEF KEY GOLD \     AS 'DATE D-1C SEL -CHGL-16C -1W D-1C +SR.'  ! Insert date as 29-Jul-1988 a> DEF KEY GOLD |     AS 'DATE D-10C SEL -CHGL-7C -1W D-1C +SR.'  ! Insert date as 29-Jul 15:01wF DEF KEY GOLD ~     AS 'DATE D-4C SEL -6C D-5C -CHGL-2C -1W D-1C +SR.'    Dave C.5   ------------------------------  # Date: Thu, 18 May 2000 22:35:08 GMT ' From: nickerson@pundit.ds.boeing.com ()D Subject: Re: Error on SMTP( Message-ID: <Fus1EK.BwA@news.boeing.com>  * In article <8g0vrj$7fb$1@nnrp1.deja.com>, ) Roose Chua <roose_chua@yahoo.com> writes:1  D |>I have been trying to resolve a problem on SMTP and had no luck inE |>looking under DSNlink. Basically, the problem is that when I try tobE |>send an email through SMTP from one of the node in a 2-node clustertG |>(VAX, OpenVMS 7.1, UCX 4.2 ECO 2), the mail is not sent and I get thet |>following error: |>) |>---- Transcript of session follows ----l< |>501  %UCX-E-SMTP_COMMANDERR,  Smtp command error intel.com |>E |>Anybody who had experience this and/or had any solution? Any advise" |>would be highly appreciated! |>	 |>Thanks,t |>Roose   H your writing seems to imply that it works on one node and not the other;E if so I'll give a guess that the 2 have different UCX configurations; B 1) do a check of the smtp configuration on both nodes and compare;J 2) compare the DNS configurations (??? maybe you are gating to intel.com);   $ ucxn > sho config smtp(
 > sho name   --bn (Bart Nickerson)o nickerson@pundit.ds.boeing.com (206) 662-0183   ------------------------------  % Date: Thu, 18 May 2000 16:55:13 -0400 / From: "Paul A. Jacobi" <Paul.Jacobi@compaq.com>gJ Subject: Re: Geting Temperature from CA (was Re: CPU Temperature from DCL)+ Message-ID: <8g1lck$ar6$1@lead.zk3.dec.com>w  8 "Peter Weaver" <peter.weaver@stelco.ca> wrote in message( news:si648b628ta12@corp.supernews.com...F > > How do you get this information from Compaq Analyze? I have playedG > with CA as much as possible and I do not recall seeing anything about02 > temperature in any output that I managed to get.  @ When a threshold has been reached, an interrupt is generated amd? environmental information is logged to the system errorlog filedE That is the only time the information is available to Compaq Analyze.t     Paul A. Jacobi Compaq Computer Corporation0! OpenVMS Systems Group, ZKO3-4/U14h 110 Spitbrook Road Nashua, NH 03062-2698, Email: Paul.Jacobi@compaq.com    ------------------------------  % Date: Thu, 18 May 2000 19:50:41 -0400n# From: sol gongola <sol@adldata.com>P) Subject: Re: How do you search for files?I' Message-ID: <392481D1.7EB6@adldata.com>i   something like  $Dir $4$DRA0:[000000...]*what*.* or4 $search  $4$DRA0:[000000...]*.*;* string1,"string 2"   sol gongolae   Andrew3748 wrote:  > K > How do you search for files AND include the subdirectories in the search.e > 4 > i.e. I would issue '$find . -name *.sql'  in unix. >  >w   ------------------------------   Date: 18 May 2000 19:54:26 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)# Subject: Re: I can no longer backup,6 Message-ID: <8g1hpi$p4m$1@mailint03.im.hou.compaq.com>  d In article <EkEU4.17149$nb2.349445@vixen.cso.uiuc.edu>, j-sivier@uiuc.edu (Jonathan Sivier ) writes:( :   ...I can no longer make tape backups@ :on my VAX...  During the repair process the tape drive was alsoG :replaced.  Now whenever I try to do a backup a get an error saying theeD :expiration date of the tape is in the future and so it won't let me :write to the tape.t     Details, please?     Specific OpenVMS VAX version?A     Specific tape device used?     Specific BACKUP command used?   #   Specific full error message text?U  D   Have any BACKUP ECOs -- ECOs are available for various OpenVMS VAX   versions -- been applied?u  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Thu, 18 May 2000 21:31:14 -0400S$ From: "Ray T." <lists@aik.tec.sc.us># Subject: Re: LAT over fiber problemg- Message-ID: <39249962.47881817@aik.tec.sc.us>t  	 Hi Peter,1  B I think I also did the servers.  Log into the server, set priv and: change some things.  It will probably be different then ;)   Ray T.   >SET Subtopic? server  >' >DEFINE/SET/CHANGE SERVER  >tQ >Use DEFINE SERVER to change the server characteristics that take effect when you Q >next initialize the server.  Use SET SERVER to change the server characteristicsrM >that you wish to take effect immediately.  Use CHANGE server to perform bothb >DEFINE and SET SERVER.s >o) >{DEFINE} SERVER server-characteristic(s)a	 >{SET   } 	 >{CHANGE}a >e >Additional help available for:b >kD >ANNOUNCEMENTS       BROADCAST           CIRCUIT TIMER       CONSOLEM >DUMP                HEARTBEAT           IDENTIFICATION      INACTIVITY TIMERsQ >KEEPALIVE TIMER     LOCK                LOGIN PASSWORD      MAINTENANCE PASSWORD C >MULTICAST TIMER     NAME                NODE LIMIT          NUMBERoH >PASSWORD LIMIT      PRIVILEGED PASSWORD PROMPT              QUEUE LIMITE >RETRANSMIT LIMIT    SERVICE GROUPS      SESSION LIMIT       SOFTWAREd   ------------------------------    Date: 18 May 2000 23:05:53 -0500/ From: jlauret@?.chem.sunysb.edu (Jerome LAURET) Q Subject: LINKING F90 programs leads to "multiply defined" and "undefined" CMA$TIS-. Message-ID: <3924af91_3@dilbert.ic.sunysb.edu>  K        I don't know when this happened but recently, I recompiled a programgQ with the F90 compiler and everything went OK as before. However, the LINK command   P LINK/EXE=[.exe.VMS_ALPHA]thermalmodel.EXE [.obj.VMS_ALPHA]thermalmodel.OBJ ,[.liP b.VMS_ALPHA]libfreezer/LIB,[.lib.VMS_ALPHA]libhydro/LIB ,CERN_ROOT:[LIB]MATHLIB.& OLB/LIB,CERN_ROOT:[LIB]KERNLIB.OLB/LIB  ? 	where libfreezer, libhydro are libraries I compiled myself andi6 the cern lib, a version taken since OpenVMS6.2 Alpha. E 	In anycasethe above command leads to zillion of messages like below.i  # 	Any idea of why I have this now ? l  H 	If I compile and LINK one source code only (using ALLOCATE for example) and LINK, it is fine.    	My platform   OpenVMS 7.2l Compaq Fortran V7.3-965-44A1I   
 	Any ideas ??h      5 %LINK-W-MULDEF, symbol DFOR$ALLOCATE multiply definede>         in module FOR_VM file SYS$COMMON:[SYSLIB]STARLET.OLB;4> %LINK-W-MULDEF, symbol DFOR$ALLOC_ALLOCATABLE multiply defined>         in module FOR_VM file SYS$COMMON:[SYSLIB]STARLET.OLB;47 %LINK-W-MULDEF, symbol DFOR$DEALLOCATE multiply defined >         in module FOR_VM file SYS$COMMON:[SYSLIB]STARLET.OLB;4@ %LINK-W-MULDEF, symbol DFOR$DEALLOC_ALLOCATABLE multiply defined>         in module FOR_VM file SYS$COMMON:[SYSLIB]STARLET.OLB;4; %LINK-W-MULDEF, symbol DFOR$SET_REENTRANCY multiply defined F         in module FOR_REENTRANCY file SYS$COMMON:[SYSLIB]STARLET.OLB;4' %LINK-W-NUDFSYMS, 18 undefined symbols:g- %LINK-I-UDFSYM,         CMA$DECC$G_REENTRANCYe. %LINK-I-UDFSYM,         CMA$TIS_ERRNO_GET_ADDR. %LINK-I-UDFSYM,         CMA$TIS_ERRNO_SET_ADDR/ %LINK-I-UDFSYM,         CMA$TIS_ERRNO_SET_VALUE * %LINK-I-UDFSYM,         CMA$TIS_KEY_CREATE/ %LINK-I-UDFSYM,         CMA$TIS_KEY_GET_CONTEXTn/ %LINK-I-UDFSYM,         CMA$TIS_KEY_SET_CONTEXTe, %LINK-I-UDFSYM,         CMA$TIS_MUTEX_CREATE, %LINK-I-UDFSYM,         CMA$TIS_MUTEX_DELETE* %LINK-I-UDFSYM,         CMA$TIS_MUTEX_LOCK- %LINK-I-UDFSYM,         CMA$TIS_MUTEX_TRYLOCKo, %LINK-I-UDFSYM,         CMA$TIS_MUTEX_UNLOCK$ %LINK-I-UDFSYM,         CMA$TIS_ONCE1 %LINK-I-UDFSYM,         CMA$TIS_VMSERRNO_GET_ADDRs1 %LINK-I-UDFSYM,         CMA$TIS_VMSERRNO_SET_ADDRt2 %LINK-I-UDFSYM,         CMA$TIS_VMSERRNO_SET_VALUE2 %LINK-I-UDFSYM,         DFOR$$FILE_INFO_HASH_TABLE' %LINK-I-UDFSYM,         DFOR$$LUB_TABLEi   -- O6                   Jerome LAURET S.U.N.Y. @ Stony Brook$        ,,,,,      Dept. of Chemistry+       ( o o )     Stony Brook NY 11794-3400 ;   ---m---U---m--------------------------------------------- &   E-mail: jlauret@mail.chem.sunysb.edu<   URL   : http://nucwww.chem.sunysb.edu/jlauret/jlauret.html   ------------------------------  # Date: Thu, 18 May 2000 22:39:06 GMTb9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)e Subject: Re: Linux ==> Free VMS5+ Message-ID: <Ou7tKJJVb$5P@eisner.decus.org>a   In article <Pine.LNX.4.05.10005181547480.18134-100000@Mufasa.pubserv.com>, Christopher Smith <chriss@Mufasa.pubserv.com> writes:  E > This is a more or less common mistake, and DEC didn't help by usingyJ > DECStation to identify not only some alphas, but some mips machines, and > some peesee type computers.   . What Alpha models were labeled as DECstation ?  ; Certainly the DEC 2000, DEC 3000 and DEC 4000 do not count.s   ------------------------------  + Date: Thu, 18 May 2000 21:19:30 +0000 (   )w3 From: Christopher Smith <chriss@Mufasa.pubserv.com>t Subject: Re: Linux ==> Free VMSeJ Message-ID: <Pine.LNX.4.05.10005182117250.18134-100000@Mufasa.pubserv.com>  + On Thu, 18 May 2000, Larry Kilgallen wrote:o   > In article <Pine.LNX.4.05.10005181547480.18134-100000@Mufasa.pubserv.com>, Christopher Smith <chriss@Mufasa.pubserv.com> writes: > G > > This is a more or less common mistake, and DEC didn't help by using L > > DECStation to identify not only some alphas, but some mips machines, and > > some peesee type computers.   0 > What Alpha models were labeled as DECstation ?  = > Certainly the DEC 2000, DEC 3000 and DEC 4000 do not count.n  I I honestly don't know, however it's either that, or "decstation alpha" isn a very common misnomer.   F I'm not completely fammiliar with dec's alpha line, so that seemed the more likely case.#   I've been wrong before. :)   Regards,   Chris|  O ===============================================================================n@ "My two cents"			(http://rootworks.com/twocentsworth.cgi?128562)= Christopher Smith(chriss@pubserv.com)			Prgramer^W Programmer- Prime Synergy of Champaign, IL.-% -------------------------------------0I "Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and H weighs 30 tons, computers in the future may have only 1,000 vacuum tubes; and weigh only 1.5 tons." -- Popular Mechanics, March 1949 iO -------------------------------------------------------------------------------g   ------------------------------  % Date: Thu, 18 May 2000 19:59:00 +0000e# From: mark <mark@mxnet.demon.co.uk>a6 Subject: Re: Linux port question. $QIOW() to sendto().1 Message-ID: <39244B84.277198A1@mxnet.demon.co.uk>    David Jones wrote:  E > >> My question is: When I use the Alpha implementation there are nolH > >> collosion problems. It only occurs using Linux. Both boxes have DECJ > >> tulip PCI cards. Does anyone have any suggestions as to what might beK > >> causing this? Does $QIO do anything different. I can't see why becausey  > >> it's really up to the card. > >h >a > > @ > >However, 50% collisions is way, WAY too high and implies thatH > >some hardware somewhere is not working right, or that the software is- > >interpreting some hardware status wrongly.e >8K > You can get lots of collisions if a the NIC is set to full duplex and thej7 > swtich port it is connected to isn't (or vice versa).@  M In my case it's Test Generator NIC -> HUB <- Test System NIC. Does this still $ apply with the hub interfacing them?   Thanks   Mark     >s> > David L. Jones               |      Phone:    (614) 292-6929/ > Ohio State University        |      Internet:IN > 140 W. 19th St. Rm. 231a     |               jonesd@er6s1.eng.ohio-state.edu< > Columbus, OH 43210           |               vman+@osu.edu >s- > Disclaimer: Dogs can't tell it's not bacon.h   ------------------------------  % Date: Thu, 18 May 2000 15:22:28 -0400 " From: Dan Sugalski <dan@sidhe.org>6 Subject: Re: Linux port question. $QIOW() to sendto().8 Message-ID: <4.3.1.0.20000518152148.021ab100@24.8.96.48>  & At 07:59 PM 5/18/00 +0000, mark wrote: >David Jones wrote:y >rG > > >> My question is: When I use the Alpha implementation there are nocJ > > >> collosion problems. It only occurs using Linux. Both boxes have DECL > > >> tulip PCI cards. Does anyone have any suggestions as to what might beM > > >> causing this? Does $QIO do anything different. I can't see why because " > > >> it's really up to the card. > > >s > >p > > >lB > > >However, 50% collisions is way, WAY too high and implies thatJ > > >some hardware somewhere is not working right, or that the software is/ > > >interpreting some hardware status wrongly.o > >eM > > You can get lots of collisions if a the NIC is set to full duplex and ther9 > > swtich port it is connected to isn't (or vice versa).  > N >In my case it's Test Generator NIC -> HUB <- Test System NIC. Does this still% >apply with the hub interfacing them?   L I don't think it applies with 10Mb ethernet period, though I could be wrong L with that. I've not ever seen any issues like this with anything other than  100Mb.   					Dan  I --------------------------------------"it's like this"-------------------r2 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and even ;                                       teddy bears get drunk,   ------------------------------  % Date: Thu, 18 May 2000 20:13:04 -0500s* From: Keith Brown <kbrown780@usfamily.net>; Subject: Re: Linux, Unix to VMS VT220 emulation - solution. , Message-ID: <39249520.39DF6D02@usfamily.net>   Erik Ahlefeldt wrote:u > I >  There have been a few requests in this group for a good VT220 terminal K >  emulation when connecting to a VMS host from Linux or Unix. Having neveraJ >  found a satisfactory emulation myself, I have taken and comprehensivelyF >  modified a script for VT100 and VT220 emulation from the Xterm faq.H >  The script "vmsterm" is ideal for connecting from a Linux computer toH >  a VMS computer, because it provides a full emulation of the auxiliaryJ >  numeric keypad so that you can use EDT, TPU and other apps that rely onM >  the proper functioning of the numeric keypad. I have not posted the scriptaM >  in comp.os.vms because it is about 150 lines long, but "vmsterm" is avail-c6 >  able from http://www-personal.une.edu.au/~oahlefel/ >  >  Erik Ahlefeldt.  > Thanks Erik, it works great.  I use Linux at home to access my OpenVMS systems at work. This really makes life easier. -- y Keith Browne kbrown780@usfamily.net   ------------------------------  % Date: Thu, 18 May 2000 22:09:17 +0200 ) From: Cleo Rasvreer <nospam@tack.here.no>r Subject: login.com and FTP? , Message-ID: <39244DED.1F1B7BF2@tack.here.no>    Dear VMS group,A I'm setting up way for a "untrusted" system to retrieve an export ? file, using FTP. The basic idea is, in login.com copy this file-5 to the login directory and let the user get the file.1  <  1. Since the file (and file creator) group UIC is different? from the ftp user's, how would you give the user read access to$= only this file. I'm pondering on using some file ACL or maybe.2 use privs and remove the privs in the login.com...  <  2. Can you adjust a UCX FTP server user's rights, commands,: etc. somehow (other than by Authorize and login.com)? How?9 Can the login.com be used to do ftp commands on behalf ofp, the user (sort of an automated ftp session)?  ;  3. Errors and other informational message is output to thei: ucx$ftpserver.log file, is this file correct for this sort$ of use or should you leave it alone?   Thanks for listening...  F.   ------------------------------  # Date: Thu, 18 May 2000 22:50:33 GMTa, From: koehler@eisner.decus.org (Bob Koehler) Subject: Re: login.com and FTP? + Message-ID: <HZm54egFw2ab@eisner.decus.org>m  X In article <39244DED.1F1B7BF2@tack.here.no>, Cleo Rasvreer <nospam@tack.here.no> writes: >  Dear VMS group,C > I'm setting up way for a "untrusted" system to retrieve an exportcA > file, using FTP. The basic idea is, in login.com copy this file 7 > to the login directory and let the user get the file.a   And hopefully clean up?   > >  1. Since the file (and file creator) group UIC is differentA > from the ftp user's, how would you give the user read access tof? > only this file. I'm pondering on using some file ACL or maybe 4 > use privs and remove the privs in the login.com...  H Use the ACL.  You can't really turn off privs in login.com in a way thatC the user can't get them back.  If it's not too dangerous your could C simply set the file world readable to begin with, else an ACL like:-     (IDENTIFIER=user,ACCESS=READ)   : Make sure the user has at least E access to the directory.  > >  2. Can you adjust a UCX FTP server user's rights, commands,< > etc. somehow (other than by Authorize and login.com)? How?; > Can the login.com be used to do ftp commands on behalf of . > the user (sort of an automated ftp session)?  E Current versions of VMS support the copy/ftp command, but where wouldoF you keep the password?  You can write and install a privileged programE which (if you code carefully) only does the one privileged action for 	 the user.t  = >  3. Errors and other informational message is output to the < > ucx$ftpserver.log file, is this file correct for this sort& > of use or should you leave it alone? >    You have some better place?f  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences CorporationA= Hubble Space Telescope Payload  | Federal Sector, Civil GroupoE  Flight Software Team           | please remove ".aspm" when replyingh   ------------------------------  % Date: Thu, 18 May 2000 15:12:19 -0400o- From: JF Mezei <jfmezei.spamnot@videotron.ca>n( Subject: Re: MicroVAX, MS and RD53 disks, Message-ID: <39244091.9FE67629@videotron.ca>   Bill Gunshannon wrote:G > Is there a utility in VMS that can format RD53/RD54 disks??  I have adH > MicroVAXII which does not have the format command in the Monitor and IG > have two disks I could use on the MicroVAX if I could only find a wayqH > to format them.  I have an older version of VMS on TK50's that I could0 > install on this machine if this was an option.  D On the MVII, the disk formatter utility came on a TK50 ("Microvax IIN diagnostics"). Took forever to boot but worked. (This was a low level format).  I Note that you may not need to format the drives. When you restore the VMS M saveset B with the standalone backup, it will initialise the drive (setup theh ODS-2 file structure) for you.   ------------------------------   Date: 18 May 2000 19:46:44 GMT& From: Cthulhu <cthulhu@kadath.deep.it>( Subject: Re: MicroVAX, MS and RD53 disks( Message-ID: <8g1hb4$o2$1@kadath.deep.it>  & Chris Scheers <asi@airmail.net> wrote:  E > To format on a MVII, you need a diagnostic tape that has the formatP$ > capability.  (Not all of them do.)  F There is absolutely no 'clean' way to obtain an image of that tape, or> to get the formatter program included in the Hobbyist project?  
 	unformatted,  	   Cthulhu6   -- a  G        Ph'nglui mglw'nafh Cthulhu http://www.rlyeh.it wgah'nagl fhtgan!$% 		       <cthulhu at flashnet dot it>"   ------------------------------  # Date: Thu, 18 May 2000 22:44:54 GMT ( From: Terry Kennedy <terry@gate.tmk.com>( Subject: Re: MicroVAX, MS and RD53 disks' Message-ID: <Fus1uu.MKs@spcuna.spc.edu>-  / JF Mezei <jfmezei.spamnot@videotron.ca> writes:GF > On the MVII, the disk formatter utility came on a TK50 ("Microvax IIP > diagnostics"). Took forever to boot but worked. (This was a low level format).  H   There are 2 flavors of this tape - "Customer" and "Field Service". TheG customer version can only format RD-series disks if they already have aV' valid format on them (silly, but true).   G   You can put the drive in a MV/VS2000 and format there, or you can user: a PDP-11 with an RQDX3 and the ZRQC formatter (from XXDP).  - 	Terry Kennedy             http://www.tmk.com 5         terry@tmk.com             Jersey City, NJ USA    ------------------------------  % Date: Fri, 19 May 2000 00:28:54 -0500f) From: "John E. Malmberg" <wb8tyw@qsl.net>B& Subject: Re: multia communication port7 Message-ID: <10f801bfc153$20aba770$020a0a0a@xile.realm>-  G The serial ports on the Multia are non-functional under OpenVMS at thisH time.e  K I do not know where the information is that is needed to write a driver for- them.-   -John- wb8tyw@qsl.network   ------------------------------  % Date: Thu, 18 May 2000 18:47:07 -0400L5 From: Forrest Kenney <Forrest.Kenney@compaq.com.doom>a Subject: Re: PTD's on VMS 5.x / Message-ID: <392472EB.6FB69C56@compaq.com.doom>v  H     Actually, FTA's showed up in Version V5.4.  I wrote the code back in( Septermber of 1989, almost 11 years ago.     Forrest Kenney   ------------------------------  # Date: Thu, 18 May 2000 22:36:59 GMTt, From: koehler@eisner.decus.org (Bob Koehler)" Subject: Re: Ultrix for mVax3100 ?+ Message-ID: <zfbkka7Wva6y@eisner.decus.org>e  X In article <VXTU4.74$s07.24452157@news.odn.de>, winfried.bergmann@frankendata.de writes: > Hello,L > I have an old mVax 3100 currently running OpenVMS 7.x. I'd like to replaceJ > this with Ultrix (I'm not interrested in NetBSD or Linux) for nostalgic K > reasons. Where can I get Ultrix for this machine (version not important, T > maybe 4.5) ? >   D ULTRIX was copyright DEC, and listed in the software catalogs CompaqF shipped shortly after they bought DEC.  It's retired but you may still be able to buy a copy.  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporation-= Hubble Space Telescope Payload  | Federal Sector, Civil GrouplE  Flight Software Team           | please remove ".aspm" when replying    ------------------------------  + Date: Thu, 18 May 2000 17:31:09 -0400 (EDT)b2 From: "Douglas S. Meade" <vaxboy@inforum2.umd.edu>" Subject: Re: Ultrix for mVax3100 ?G Message-ID: <Pine.LNX.4.20.0005181728340.11001-100000@inforum2.umd.edu>e   Nope,N  E I already tried that.  It was surprising how few people I got bouncedhE to at Compaq had even heard of Ultrix, but the man who finally calledrG me back described it as "not saleable".  I asked him: do you still have E copies of media in stock?  He said that may be so, but it was on the eD list of items that is not saleable.  I think part of the problem mayE have been that Ultrix was encumbered by licenses DEC had bought from ID ATT.  This may now not be as much of a problem, as SCO has announcedG they will release their Unix for free.  It may be time to call somebodyM at DEC, er, Compaq again.-  
 Doug Meade    ' On Thu, 18 May 2000, Bob Koehler wrote:D  Z > In article <VXTU4.74$s07.24452157@news.odn.de>, winfried.bergmann@frankendata.de writes:
 > > Hello,N > > I have an old mVax 3100 currently running OpenVMS 7.x. I'd like to replaceL > > this with Ultrix (I'm not interrested in NetBSD or Linux) for nostalgic M > > reasons. Where can I get Ultrix for this machine (version not important, 4 > > maybe 4.5) ? > >  > F > ULTRIX was copyright DEC, and listed in the software catalogs CompaqH > shipped shortly after they bought DEC.  It's retired but you may still > be able to buy a copy. > H > ----------------------------------------------------------------------A > Bob Koehler                     | Computer Sciences CorporationE? > Hubble Space Telescope Payload  | Federal Sector, Civil Group-G >  Flight Software Team           | please remove ".aspm" when replyingR >    ------------------------------  % Date: Thu, 18 May 2000 12:37:19 -0400   From: norm.raphael@jamesbury.com+ Subject: Re: Utility to track device errors 4 Message-ID: <C22568E3.005A7961.00@jklh22.valmet.com>   @dcl_check check_device.comE  @ -*- Charlie Hammond's unsupported DCL checker (Version V2.0) -*-: Checking file SYS$COMMON:[SYSMGR.COMMAND]CHECK_DEVICE.COM;  . Starting Pass 1 -- 18-MAY-2000 12:19:17.93 .... Starting Pass 2 -- 18-MAY-2000 12:19:19.17 .... Starting Pass 3 -- 18-MAY-2000 12:19:19.38 ...  & Procedure contains:     69 total linesE                         40 code lines (including 4 lines w/ comments)E8                          2 additional continuation lines5                          0 lines w/i $DECK/$EOD pairs -                         20 comment only lines &                          7 blank lines  #  LINE  CODE  --DIAGNOSTIC MESSAGE---J    49  LNF  label "L1000" not found   <==============================Oops!0 -*- END OF LISTING -*-   18-MAY-2000 12:19:19.67        1 TMcGrath@cendant.com.au on 05/17/2000 11:21:55 PMb  ) Please respond to TMcGrath@cendant.com.aur   To:   Info-VAX@mvb.saic.comn cc:>, Subject:  Re: Utility to track device errors        1 On Mon, 15 May 2000 08:45:55 -0400, "AndradeJA-A"4$ <andradeja@npt.nuwc.navy.mil> wrote:  J >Considering the fact that our cluster doesn't go down and considering the
 >fact thatM >device errors can accumulate in such a way as to make their analysis a minortL >headache at best and overly time consuming at worst.  Does anyone know of aK >utility that regularly logs changes in SHOW ERROR and sends resulting data  >tot >an output file/email account. >-! >Jay Andrade - VMS System Manager:   Hi Jay, - Here's what I've been using for many years...p@ It sits in a queue, runs every day, just before I get it at 9am.   Cheers from Oz,7    Tony-  = $!  CHECK_DEVICE.COM          Tony McGrath,  3-MAR-1993 10:03n< $   SAVE_VER = 'F$VERIFY( F$TRNLNM( "CHECK_DEVICE_VERIFY"))'I $!-----------------------------------------------------------------------iF $! Issue the "SHOW ERROR" command and send a mail message to me if any $! new errors are detected. I $!-----------------------------------------------------------------------  $   ON   ERROR   THEN GOTO EXITm $   ON CONTROL_Y THEN GOTO EXIT? $! $   DEBUG     = 0 " $   SAY      := "WRITE SYS$OUTPUT"0 $   DSAY     := "IF DEBUG THEN WRITE SYS$OUTPUT"4 $   ERR_FILE  = "SYS$SCRATCH:SHOW_ERROR_OUTPUT.LIST"4 $   MAIL_FILE = "SYS$SCRATCH:SHOW_ERROR_OUTPUT.MAIL"4 $   DIFF_FILE = "SYS$SCRATCH:SHOW_ERROR_OUTPUT.DIFF"C $   DIF$_SAMEFILE  = %X006C8009    ! from SYS$MESSAGE:PRGDEVMSG.EXE= $   DIF$_FILAREDIF = %X006C8013=C $   SHOW$_NOERRORS = %X107880A1    ! from SYS$MESSAGE:CLIUTLMSG.EXEe/ $   THIS_FILE      = F$ENVIRONMENT("PROCEDURE")bF $   WHERE = F$ELEMENT(0,"]",F$PARSE(F$ENVIRONMENT("PROCEDURE"))) + "]", $   SAVE_LOCATION = F$ENVIRONMENT("DEFAULT") $!. $!   IF F$MODE() .EQS. "BATCH" THEN SET VERIFY $   SET DEFAULT 'WHERE' I $!-----------------------------------------------------------------------n8 $! Check for new errors that weren't reported last time.C $! Do an initial check to see if there really is an error to report-E $! If there is do it again sending the output to a file. Then compare . $! this file with a previous version to see if& $! (a) the is a new device in the list< $! (a) one of the counters for a device already reported has incrementedoI $!-----------------------------------------------------------------------e $   FOUND_ERROR = 0i $   SHOW ERROR" $   IF $STATUS .NE. SHOW$_NOERRORS $   THEN# $     SHOW ERROR /OUTPUT='ERR_FILE'e $     PURGE 'ERR_FILE' /KEEP=2< $     DIFFERENCES 'ERR_FILE' /OUTPUT='DIFF_FILE' ! /PARALLEL0 $     FOUND_ERROR = ($STATUS .NE. DIF$_SAMEFILE)	 $   ENDIF I $!-----------------------------------------------------------------------  $!I $!-----------------------------------------------------------------------t( $   IF .NOT. FOUND_ERROR THEN GOTO L1000 $!A $   CREATE 'MAIL_FILE' ! For user-friendly file/record attributes % $   OPEN /APPEND TMP_FILE 'MAIL_FILE' 2 $   WRITE TMP_FILE "ERROR Report from ", THIS_FILE? $   WRITE TMP_FILE "The system has detected a new device error"i $   WRITE TMP_FILE ""t $   CLOSE TMP_FILE $!' $   APPEND /LOG 'DIFF_FILE' 'MAIL_FILE' ' $   APPEND /LOG  'ERR_FILE' 'MAIL_FILE'e $! $   MAIL 'MAIL_FILE' TONY -t7      /SUBJECT="There is a device reporting errors !!" -@&      /PERSONAL_NAME="CHECK_DEVICE.COM" $! $EXIT: $   SET DEFAULT 'SAVE_LOCATION'u= $   IF F$SEARCH(MAIL_FILE) .NES. "" THEN DELETE 'MAIL_FILE';*-= $   IF F$SEARCH(DIFF_FILE) .NES. "" THEN DELETE 'DIFF_FILE';* % $   EXIT $STATUS+0*F$VERIFY(SAVE_VER)u    C Tony McGrath, Systems Administrator, British Airways Executive Club0N Cendant Membership Services, 596 North Road, Ormond, Victoria, 3204, Australia- Phone : 61 3 9578 8233   Fax : 61 3 9578 6326:   ------------------------------   Date: 18 May 2000 20:48:53 GMT* From: bleau@umtof.umd.edu (Lawrence Bleau)+ Subject: Re: Utility to track device errorsa) Message-ID: <8g1kvl$53g$2@hecate.umd.edu>   h In article <2000May15.084737.309@npt.nuwc.navy.mil>, "AndradeJA-A" <andradeja@npt.nuwc.navy.mil> writes:J >Considering the fact that our cluster doesn't go down and considering the
 >fact thatM >device errors can accumulate in such a way as to make their analysis a minorfL >headache at best and overly time consuming at worst.  Does anyone know of aK >utility that regularly logs changes in SHOW ERROR and sends resulting datah >to  >an output file/email account.   Jay,  I I designed a DCL procedure to handle this several years ago.  It works byhK maintaining a database (really just an indexed file) of device names, errorwK counts, and date/time stamps.  Every time you run the procedure it gets thesM current error counts, and for each device where the count increased a line is-O written into a text file.  When done the text file is emailed to SYSTEM and theiM database is updated.  If the count decreased, that means the system rebooted,a# so this fact is noted in the email.   K If you want a copy, use anonymous ftp to the site umdsp.umd.edu and get the-O files REPORT_ERROR.COM, ERROR_DATABASE.FDL, and ERROR_DATABASE.DAT (a sample). lJ I'd post it, but it's >400 lines, and I never cared for huge Usenet posts.  N The procedure is also cluster ready, in that it can properly track identicallyH named devices that are on different cluster members.  The database is in SYS$COMMON:.   Lawrence Bleau University of Maryland" Physics Dept., Space Physics Group 301-405-6223 bleau@umtof.umd.educ   ------------------------------   Date: 18 MAY 2000 21:57:42 GMT6 From: greenwoodde@feda34.fed.ornl.gov (Dave Greenwood)+ Subject: Re: Utility to track device errorsS2 Message-ID: <18MAY00.21574222@feda34.fed.ornl.gov>  + bleau@umtof.umd.edu (Lawrence Bleau) wrote: j > In article <2000May15.084737.309@npt.nuwc.navy.mil>, "AndradeJA-A" <andradeja@npt.nuwc.navy.mil> writes:L > >Considering the fact that our cluster doesn't go down and considering the > >fact thatO > >device errors can accumulate in such a way as to make their analysis a minor N > >headache at best and overly time consuming at worst.  Does anyone know of aM > >utility that regularly logs changes in SHOW ERROR and sends resulting datai > >to   > >an output file/email account. >  e > Jay, >   K > I designed a DCL procedure to handle this several years ago.  It works bygM > maintaining a database (really just an indexed file) of device names, erroruM > counts, and date/time stamps.  Every time you run the procedure it gets thesO > current error counts, and for each device where the count increased a line isaQ > written into a text file.  When done the text file is emailed to SYSTEM and thesO > database is updated.  If the count decreased, that means the system rebooted,y% > so this fact is noted in the email.  >  AM > If you want a copy, use anonymous ftp to the site umdsp.umd.edu and get the Q > files REPORT_ERROR.COM, ERROR_DATABASE.FDL, and ERROR_DATABASE.DAT (a sample). rL > I'd post it, but it's >400 lines, and I never cared for huge Usenet posts. >  pP > The procedure is also cluster ready, in that it can properly track identicallyJ > named devices that are on different cluster members.  The database is in > SYS$COMMON:.  K Well - my .COM is only 143 lines ;-)  But it only prints the results rather-I than emails them (running it is part of my morning routine).  I just DIFF@J a current SHOW ERROR output against the previous output, parse the resultsD and show a brief display.  It also recognizes when a system has beenJ rebooted.  Requires OPER because it uses SYSMAN.  I don't have an ftp site) but I'll email it if anyone's interested.s   Dave --------------9 Dave Greenwood                Email: Greenwoodde@ORNL.GOV H Oak Ridge National Lab        %STD-W-DISCLAIMER, I only speak for myself   ------------------------------  # Date: Thu, 18 May 2000 23:22:56 GMTI, From: TMcGrath@cendant.com.au (Tony McGrath)+ Subject: Re: Utility to track device errorst3 Message-ID: <392479ac.1565020@news.mel.aone.net.au>b  E On Thu, 18 May 2000 12:37:19 -0400, norm.raphael@jamesbury.com wrote:    >@dcl_check check_device.com >lA >-*- Charlie Hammond's unsupported DCL checker (Version V2.0) -*-t; >Checking file SYS$COMMON:[SYSMGR.COMMAND]CHECK_DEVICE.COM;t >e/ >Starting Pass 1 -- 18-MAY-2000 12:19:17.93 ...r/ >Starting Pass 2 -- 18-MAY-2000 12:19:19.17 ... / >Starting Pass 3 -- 18-MAY-2000 12:19:19.38 ...t >U' >Procedure contains:     69 total lines F >                        40 code lines (including 4 lines w/ comments)9 >                         2 additional continuation linesr6 >                         0 lines w/i $DECK/$EOD pairs. >                        20 comment only lines' >                         7 blank linesr > $ > LINE  CODE  --DIAGNOSTIC MESSAGE--K >   49  LNF  label "L1000" not found   <==============================Oops!t1 >-*- END OF LISTING -*-   18-MAY-2000 12:19:19.67  >p   Hi Norm,  D You're not the only one to spot the error. Sorry everyone. I removed9 some code from the command file just prior to posting it.a   Two things:-" (1) To fix my command file, change( $   IF .NOT. FOUND_ERROR THEN GOTO L1000  to ' $   IF .NOT. FOUND_ERROR THEN GOTO EXITo  < (2) I'd love to get a copy of Charlie Hammond's DCL checker.   Cheers from Down Under,     Tony  ---eC Tony McGrath, Systems Administrator, British Airways Executive ClubaN Cendant Membership Services, 596 North Road, Ormond, Victoria, 3204, Australia- Phone : 61 3 9578 8233   Fax : 61 3 9578 6326    ------------------------------  % Date: Thu, 18 May 2000 14:03:01 -0400s* From: Chuck Chopp <ChuckChopp@rtfmcsi.com>4 Subject: Re: VMS 5.2 DCL treats &symbol unexpectedly+ Message-ID: <39243055.355F87A3@rtfmcsi.com>    Joseph Ballantyne wrote:  E > I originally had a need to SEARCH for the DEL (%X7F) character in anE >    file, and that worked as expected.  Then the application changed E >    slightly, and I needed to SEARCH for two consecutive DELs.  Thato' >    turned up an apparent DCL anomaly.oH > I have no easy way to test-run this file on a more modern VMS version.; >    There is no SPR or other Compaq support on the system.MF > Because DCL expands apostrophes before logging the command line, andJ >    because DEL has no graphic, I have lightly edited the following batchI >    log.  Commands that included apostrophes have trailing comments with C >    the apostrophes shown as plus signs.  DELs are shown as stars.d@ >    (There is no apparent significance to the %X7F value of theI >    symbol--that just happens to be the value I needed when I discoveredy >    the anomaly.)I > The test data file JUNK.0 contains four lines, with 0 to 3 DELs between  >    the parens.* > $ show syst ! many output lines omitted.I > VAX/VMS V5.2  on node V7  18-MAY-2000 14:56:14.49   Uptime  25 00:19:03t9 > $ anal/imag sys$system:dcl ! many output lines omitted.uO > Analyze Image                                18-MAY-2000 14:56:15.66   Page 10 > SYS$COMMON:[SYSEXE]DCL.EXE;1* >         Image Identification Information# >                 image name: "DCL" 3 >                 image file identification: "X-20"m9 >                 link date/time: 10-MAY-1989 18:00:50.77e0 >                 linker identification: "05-05" >         Patch Informationu4 >                 There are no patches at this time.# > The analysis uncovered NO errors.  > $ x7f[0,8]=%x7f. > $ sear junk.0 &x7f > has 1: (<DEL>) > has 2: (<DEL><DEL>)a > has 3: (<DEL><DEL><DEL>) > $ sear junk.0 &x7f&x7fP > %DCL-W-VALREQ, missing qualifier or keyword value - supply all required values3 > $ sear junk.0 "**" ! $ sear junk.0 "++x7f+++x7f+"P > has 2: (<DEL><DEL>)  > has 3: (<DEL><DEL><DEL>)- > $ sear junk.0 ** ! $ sear junk.0 +x7f++x7f+, > has 2: (<DEL><DEL>)- > has 3: (<DEL><DEL><DEL>)/ > $ sear junk.0 &x7f* ! $ sear junk.0 &x7f+x7f+MP > %DCL-W-VALREQ, missing qualifier or keyword value - supply all required values/ > $ sear junk.0 *&x7f ! $ sear junk.0 +x7f+&x7f ) > %SEARCH-I-NOMATCHES, no strings matcheda > $ defi &x7f junk > $ show tran &x7f# >   * = "JUNK"  (LNM$PROCESS_TABLE)a > $ defi &x7f&x7f junkP > %DCL-W-VALREQ, missing qualifier or keyword value - supply all required values/ > $ defi "**" junk ! $ defi "++x7f+++x7f+" junk  > $ assi junk &x7f; > %DCL-I-SUPERSEDE, previous value of * has been superseded / > $ assi junk "**" ! $ assi junk "++x7f+++x7f+" < > %DCL-I-SUPERSEDE, previous value of ** has been superseded
 > $ deas &x7fe > $ deas &x7f&x7flP > %DCL-W-VALREQ, missing qualifier or keyword value - supply all required values% > $ deas "**" ! $ deas "++x7f+++x7f+"o > $ defi junk &x7f > $ defi junk &x7f&x7fB > %DCL-W-NULFIL, missing or invalid file specification - respecify > $ requ &x7f&x7feP > %DCL-W-VALREQ, missing qualifier or keyword value - supply all required valuesH > So--how have I misunderstood the effect of ampersand-controlled symbolH >    expansion?  If adjoining a &symbol with a non-blank string preventsD >    recognition of the symbol, I would expect the &symbol to eitherG >    remain literally in the command (which apparently happens when the F >    non-blank string precedes the &symbol), or to be replaced with anD >    empty string, and the command to be diagnosed accordingly.  Or,< >    alternatively, UNDSYM.  I don't understand the VALREQs.  N The ampersand & symbol is used for indirect symbol substitution.  Refer to the
 following:   $ X = "ABC"e $ Y = "XYZ"i $ 	 $ Z = "X"i $  $ WRITE SYS$OUTPUT &Z  ABCa $r	 $ Z = "Y"m $h $ WRITE SY$OUTPUT &Z XYZ- $- $-  O You should be useing the single quote character for symbol substitution in this" case as follows:  & $ SEARCH some-file-spec "''X7F'''X7F'"  R Note that the the substituted values are placed inside of double quotes and that aO pair of single quotes precede the symbol name and just one single quote follows  the symbol name.  K Read your DCL User's Guide.  It has a really nice section on using symbols.l     Chucka -- Chuck Chopps  8 ChuckChopp@rtfmcsi.com            http://www.rtfmcsi.com0                                   ICQ # 22321532@ RTFM Consulting Services Inc.     864 801 2795 voice & voicemail2 103 Autumn Hill Road              864 801 2774 fax4 Greer, SC  29651                  800 400 4935 pagerC                                   8004004935@alphapage.airtouch.comt   ------------------------------  % Date: Thu, 18 May 2000 18:07:49 -0700M& From: Jerry Hudgins <jerry@e-farm.com>2 Subject: Re: VMS and Ole for Process Control (OPC)* Message-ID: <392493E5.1BB43A2E@e-farm.com>  % "DECHAIZE Thierry (Dir INFRA)" wrote:n > A > Where, on WEB, the specification of the OLE for Process ControleH > (OPC) specification, "OPC Data Access Automation Specification, V2.02"* > (dated February 3, 1999) are available ?  G The last OPC Custom DA spec that I saw was V2.03.  OPC documentation is . available from:  http://www.opcfoundation.org/   -jch   ------------------------------  % Date: Fri, 19 May 2000 12:31:44 +1000 / From: "Phil Howell" <howellp@snowyhydro.com.au>- Subject: Re: VMS File Modeso3 Message-ID: <mI1V4.37061$PL4.756068@ozemail.com.au>p  I If your product didn't have to run on those 'other' operating systems you 7 could just use rms.h and the 'spool on close' qualifierh Phil   4.17 FAB$L_FOP Field  L FAB$L_FOP is the symbolic offset value for the FAB's file-processing optionsD (FOP) field. This field specifies which of the various optional file1 operations are to be implemented for the process.d  D The FOP is a 32-bit field in which each file-processing option has aJ corresponding bit assignment to let you specify multiple options (multipleK bits can be set), when applicable. Each option has a unique symbolic offset1H value and mask value, but you need only specify the appropriate 3-letterL mnemonic when coding a function. For example, the spool-file-on-close optionL has a symbolic offset value of FAB$V_SPL, but to specify the option, you use the following MACRO statement:     FOP=SPLl          K <carends@evisions.com> wrote in message news:8fv3dt$4t3$1@nnrp1.deja.com...  > All, > E > Forgive me for my ignorance but I am having a tough time overcomingeI > what SHOULD be a simple problem IMO.  My company has developed a cross-IF > platform product that sends a file that we have created to a printerG > using whatever command the user would like to use.  Currently, in our " > tests, this is just using PRINT. >:9 > The program is written in C and creates the file using:y >    fopen("filename", "w");! > This file is a binary PCL file.l >rG > When we send the file to the print queue using PRINT the queue cannote; > understand the file and does not print it to the printer.  > H > The problem I am having is that I do not know enough about VMS to knowH > where the problem lies.  Do I need to create the file differently?  IsG > there a flag to pass to PRINT to let it know that the file is Binary?c8 > Is there a configuration problem with the print queue? >eF > I have attempted to create the file using different file modes like:% >    fopen("filename", "w, recfm=A"); F > ...among others but the file is never created so I obviously have no > clue what I'm doing. > D > Anyone who has sufficient knowledge of this problem please help meF > out.  I am desperate and have exhausted my knowledge of VMS.  If youH > could please send a copy of your response to my email address it would > be appreciated.  >- > Thank you, > Clayton M. Arends- > carends@evisions.com >- >-( > Sent via Deja.com http://www.deja.com/ > Before you buy.O   ------------------------------  # Date: Fri, 19 May 2000 01:48:59 GMT 9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) % Subject: VMS for a rack-mount cluster + Message-ID: <2y0mvySgPN+P@eisner.decus.org>T  N In article <8g1pjk$khm@fidoii.CC.Lehigh.EDU>, "dls2" <dls2@Lehigh.EDU> writes:> > "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote:# >> "dls2" <dls2@Lehigh.EDU> writes:S? >> > Why has Compaq seen fit to release the DS10L machines with = >> > two 10/100Mbps ethernet connecters?  These machines seem,C >> > to be marketed as ideal for clustering, yet from what has justI@ >> > been stated about latency, the DS10L machines seem terribly >> > suited for clustering.  >>G >> That is the entry level current generation machine.  Certainly it is H >> not going to have everything built in that you might want on a largerF >> machine. I don't know what you mean by "what has just been stated".C >> There are people on this group who have a standalone workstationtD >> and people on this group who support E*Trade.  You have to decideF >> what _your_ requirements are and buy the machine that matches them. > > > The DS10L is rackmountable.  If it is rackmounted, it is NOT@ > sitting on a desk, and it is NOT functioning as a workstation.  < Then it is off topic in this thread. I will change the name.  = > Why have multiple DS10Ls rackmounted together, if not to be'A > clustered?  And if they are clustered together, then what about = > the latency from using ethernet for cluster communications?-  = If you want a rack-full of Alpha to work on the same project,-: you will get better performance in most cases with several$ ES40s than a larger number of DS10s.  6 The original market for the DS10s was ISPs and Telcos,9 where independent machines can be the goal, but workunitsT* per square foot of floorspace is critical.  9 If you insist on clustering other than on Ethernet, buy ar; PCI adapter for the network of your choice, but don't forceD9 those for whom Ethernet is perfectly adequate to pay more 8 by having Compaq make the more expensive choice built-in to the motherboard.e   ------------------------------   Date: 18 May 2000 12:51 CST ' From: carl@gerg.tamu.edu (Carl Perkins)N  Subject: Re: VMS on the desktop?- Message-ID: <18MAY200012512560@gerg.tamu.edu>C  + "Bill Todd" <billtodd@foo.mv.com> writes... ; }Nigel Arnot <sysmgr@maxwell.ph.kcl.ac.uk> wrote in messagey2 }news:009EA44E.F405F53D.31@maxwell.ph.kcl.ac.uk...J }> Get the word out: reading any .doc file is like unsafe sex, it could beD }> lethal (to your PC, your business, your continued employment ...) } I }A while ago, my impression was that the only threat in reading a .doc MSLJ }file was macro viruses, which could only affect other Word documents thatI }you created or edited.  If so, using Word only to read such things wouldaM }seem relatively safe.  Has this changed (e.g., are there now embedded-scriptf7 }facilities that execute without warning and without an $ }appropriately-restrictive sandbox)? }  }- bill    Bingo.  G The current (and one previous, I think) version of MS Word (and all thetG other Office applications) has full access to everything via the VisualHL Basic for Applications scripting - exactly the same scripting Outlook (which2 is part of MS Office) used in the recent problems.   --- Carl   ------------------------------  # Date: Thu, 18 May 2000 18:00:43 GMT 2 From: malmberg@eisner.decus.org (John E. Malmberg)  Subject: Re: VMS on the desktop?' Message-ID: <Furop7.Dyr@news.decus.org>o  , Phillip Helbig <helbig@astro.rug.nl> writes:  / >Art Rice <arice@ue.itug.organization> writes: i >iI >>>I consider it common (maybe it's not common) curtesy to work out which I >>>formats your intended recipient can read before sending anything asidef" >>>from human-readable ascii text. >tH >Well-meaning employee:  Boss, I consider it common courtesy to work outH >                        which formats your intended recipient can read K >                        before sending anything aside from human-readable  $ >                        ascii text. >tD >Boss:                   Who cares about common courtesy?  The only C >                        question is whether or not it is industry h" >                        standard.  F Customer #1:             I can not read this document on the corporateE                          standard E-MAIL client.  It requires a later M                          version of a viewer than we have.  So I guess I will28                          not be purchasing this product.  G Customer #2:             We have traced a MacroVirus to a document that"J                          you E-mailed us.  Expect no further business fromI                          us until you have compensated us for the damage.cM                          This matter has been turned over to our legal staff.a  N From a business risk perspective, it is a bad idea to send anything other thanG plain text to a customer with out pre-arrangements, and never send HTML  formatted messages.l     Also be aware:  P Some of the anti-virus methods in use for Macro-viruses do not kill the things. N They only make the client look like it is already infected so the payload does
 not activate.o  M Using an infected document as a template on such a client can infect a remoter site.o     -Johnn wb8tyw@qsl.network   ------------------------------  % Date: Thu, 18 May 2000 14:57:15 -0400t From: "dls2" <dls2@Lehigh.EDU>  Subject: Re: VMS on the desktop?- Message-ID: <8g1efu$fs6@fidoii.CC.Lehigh.EDU>   2 "Nigel Arnot" <sysmgr@maxwell.ph.kcl.ac.uk> wrote:L > Indeed. I'll accept .pdf files (reluctantly), but if I find a website withH > a .doc file and an identifiable web-manager, I make a point of sendingF > a mail explaining why the .doc file will not be viewed by anyone whoJ > knows and cares about security, and that therefore using .doc is harming > his business.a >iC > Some companies do respond! I've seen .doc pages disappear and gethI > replaced by .htm or .pdf. (Usually the horrid .htm that Word emits, butuG > mostly it's viewable with Netscape and the rest of the time I dig outt> > another standard letter for the Webmin about the evils of MS supposedly-html.  7 Would you consider posting those two form letters here? C I am sure that I am not the only one curious to see their contents?b     appreciatively,. Derrick Shearer  dls2@Lehigh.EDUl   ------------------------------  % Date: Thu, 18 May 2000 14:53:37 -0400  From: "dls2" <dls2@Lehigh.EDU>  Subject: Re: VMS on the desktop?- Message-ID: <8g1e94$cmq@fidoii.CC.Lehigh.EDU>e  * "John E. Malmberg" <wb8tyw@qsl.net> wrote:> > Local observations show that it seems to take 30 Pentium Mhz) > to equal 1 VUP.  Your mileage may vary.    What is a VUP?     Derrick Shearer5 dls2@Lehigh.EDUn   ------------------------------  + Date: Thu, 18 May 2000 17:07:20 +0000 (   )e3 From: Christopher Smith <chriss@Mufasa.pubserv.com>H  Subject: Re: VMS on the desktop?J Message-ID: <Pine.LNX.4.05.10005181650510.18134-100000@Mufasa.pubserv.com>    On Wed, 17 May 2000, dls2 wrote:  7 > I now think that standalone VMS machines are not very18 > good as desktop machines.  They lack the graphical and= > audial capability of other offerings, such as Irix, or even 
 > Windows.  G I'd have to argue that a standalone VMS machine is much better for your C desktop than windows.  I even personally prefer the GUI to windows.   H On the other hand, I can't argue about IRIX -- I even recently purchasedJ an SGI for my personal use, but it takes a lot to compete with them in the8 realm of GUI.  I don't know anyone else who comes close.  F The thing that would kill VMS on the desktop is that you can't run theJ latest microshaft garbage on it. (Well, ignoring the price, which it seems we're doing...)   J This isn't a problem for me, of course, but the average pointy-haired typeD will explode if you tell them they can't waste their cpu cycles with lookout and exploder.R  3 > Is VMS any better for the desktop when clustered?r  I The advantage you'd get for being able to centralize administration wouldM
 be wonderful.   F Of course, you'd still have the same application availability problem.  H Honestly, to do what people want from a desktop computer, you need aboutG the equivelant of a commodore 64.  Anything more is just extra, and VMS1I has as much extra in the realm of gui and user-friendliness as most otherj* systems -- more extra in some other areas.   Regards,   Chris2  O ===============================================================================e@ "My two cents"			(http://rootworks.com/twocentsworth.cgi?128562)= Christopher Smith(chriss@pubserv.com)			Prgramer^W Programmerh Prime Synergy of Champaign, IL.w% ------------------------------------- I "Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and H weighs 30 tons, computers in the future may have only 1,000 vacuum tubes; and weigh only 1.5 tons." -- Popular Mechanics, March 1949 iO -------------------------------------------------------------------------------t   ------------------------------  % Date: Thu, 18 May 2000 15:32:54 -0400l" From: Dan Sugalski <dan@sidhe.org>  Subject: Re: VMS on the desktop?8 Message-ID: <4.3.1.0.20000518153202.021a96e0@24.8.96.48>  & At 02:53 PM 5/18/00 -0400, dls2 wrote:+ >"John E. Malmberg" <wb8tyw@qsl.net> wrote:n@ > > Local observations show that it seems to take 30 Pentium Mhz+ > > to equal 1 VUP.  Your mileage may vary.  >  >What is a VUP?   H Vax Unit of Processing, IIRC. Basically the amount of work a VAX 11/780 F (the original VAX system) could do. If you have a 10 VUP machine it's $ allegedly 10x faster than an 11/780.     					Dan  I --------------------------------------"it's like this"-------------------E2 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and even ;                                       teddy bears get drunke   ------------------------------  % Date: Thu, 18 May 2000 22:09:12 +0200"= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>p  Subject: Re: VMS on the desktop?) Message-ID: <39244DE8.B331A934@gtech.com>.   dls2 wrote:., > "John E. Malmberg" <wb8tyw@qsl.net> wrote:@ > > Local observations show that it seems to take 30 Pentium Mhz+ > > to equal 1 VUP.  Your mileage may vary.  >  > What is a VUP?   VUP = Vax Unit of Processing  9 It is a CPU speed benchmark scaled with a VAX 78 as 1.0 !(   Arne   ------------------------------  + Date: Thu, 18 May 2000 19:48:49 +0000 (   ) 3 From: Christopher Smith <chriss@Mufasa.pubserv.com>   Subject: Re: VMS on the desktop?J Message-ID: <Pine.LNX.4.05.10005181943430.18134-100000@Mufasa.pubserv.com>    On Thu, 18 May 2000, dls2 wrote:  , > "John E. Malmberg" <wb8tyw@qsl.net> wrote:@ > > Local observations show that it seems to take 30 Pentium Mhz+ > > to equal 1 VUP.  Your mileage may vary.D   > What is a VUP?   A "VAX Unit of Performance"u  % To paraphrase something from a FAQ...u  E One VUP is the amount of force (measured in dynes) it takes to draw a I round ball weighing e Troy Ounces down a tube it fits exactly (in air) at") a speed of pi attoparsecs/microfortnight.s  ( Or.. well, that's for the _other_ VAX ;)  G This VUP, I believe is a messure of system performance based on the VAXu 11-780 (which was 1 VUP).u   Regards,   Chris   O ===============================================================================m@ "My two cents"			(http://rootworks.com/twocentsworth.cgi?128562)= Christopher Smith(chriss@pubserv.com)			Prgramer^W Programmery Prime Synergy of Champaign, IL.a% -------------------------------------aI "Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes andaH weighs 30 tons, computers in the future may have only 1,000 vacuum tubes; and weigh only 1.5 tons." -- Popular Mechanics, March 1949 pO -------------------------------------------------------------------------------    ------------------------------  % Date: Thu, 18 May 2000 15:29:17 -0400i From: "dls2" <dls2@Lehigh.EDU>  Subject: Re: VMS on the desktop?- Message-ID: <8g1gc0$csg@fidoii.CC.Lehigh.EDU>d  % "Dan Sugalski" <dan@sidhe.org> wrote: ( > At 01:52 AM 5/18/00 -0400, dls2 wrote:; > >"David J. Dachtera" <djesys.nospam@earthlink.net> wrote:YJ > > > With each other? You do sometimes see this, though the usefulness isH > > > debatable since the cluster communications medium for both SCS and MSCP2 > > > traffic would be the ethernet (10/100Mbits). > >i: > >Are ethernet and fast ethernet really so inadequate for4 > >relaying (SCS & MSCP?) messages between machines? >eC > Under any sort of load, yes. It's not so much that their speed iseL > inadequate (though the alternative to ethernet is either CI running a pairL > of 70Mb/sec channels, fibre running lots more than that, or Memory ChannelL > which just cruises) though it is the slowest medium. The bigger problem is
 > latency.   "Memory Channel?"n  G > The distributed lock manager does all its communication via SCS. When G > you're exchanging locks around you want the response to be as fast aseK > possible. A 100 Mb/sec channel with five times the latency of a 70 Mb/sec: > channel is suboptimal.  9 Does all (VMS?) clustering make use of distributed locks?e  L > You will (and people have) see significant performance boosts in clustered4 > apps just by switching to a lower-latency channel. >a) > >How, then, are server clusters linked?C >pK > In the "old" days it was CI for the bigger machines. Nowadays it seems touJ > be switching over to glass, fast ethernet, or memory channel. I think itL > might be worthwhile, in clusters using SCSI to get to storage and ethernetJ > for cluster communications, to throw in some used CI controllers just to2 > get a lower-latency channel between the systems.  : Why has Compaq seen fit to release the DS10L machines with8 two 10/100Mbps ethernet connecters?  These machines seem> to be marketed as ideal for clustering, yet from what has just; been stated about latency, the DS10L machines seem terriblyF suited for clustering.     appreciatively,v Derrick Shearers dls2@Lehigh.EDUo   ------------------------------   Date: 18 May 2000 21:18:01 GMT) From: leslie@clio.rice.edu (Jerry Leslie)f  Subject: Re: VMS on the desktop?' Message-ID: <8g1mm9$s12$1@joe.rice.edu>   4 Christopher Smith (chriss@Mufasa.pubserv.com) wrote:   : A "VAX Unit of Performance"   ' : To paraphrase something from a FAQ...i  G : One VUP is the amount of force (measured in dynes) it takes to draw apK : round ball weighing e Troy Ounces down a tube it fits exactly (in air) at + : a speed of pi attoparsecs/microfortnight.c  * : Or.. well, that's for the _other_ VAX ;)  % The other "VAX" is still available...t  <   http://www.vax.co.uk/pages/navigation/mainfr_navigator.htm4   vacuum cleaners, carpet cleaners, hoovers from Vax    4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------  # Date: Thu, 18 May 2000 23:13:55 GMTd9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)a  Subject: Re: VMS on the desktop?+ Message-ID: <2TIY4PFHsrsE@eisner.decus.org>   N In article <8g1gc0$csg@fidoii.CC.Lehigh.EDU>, "dls2" <dls2@Lehigh.EDU> writes:  < > Why has Compaq seen fit to release the DS10L machines with: > two 10/100Mbps ethernet connecters?  These machines seem@ > to be marketed as ideal for clustering, yet from what has just= > been stated about latency, the DS10L machines seem terribly  > suited for clustering.  D That is the entry level current generation machine.  Certainly it isE not going to have everything built in that you might want on a largersC machine. I don't know what you mean by "what has just been stated".i@ There are people on this group who have a standalone workstationA and people on this group who support E*Trade.  You have to decideaC what _your_ requirements are and buy the machine that matches them.   A If your requirements are "priced below 5 million dollars" you cans$ aspire to the big 32-CPU GS machine.  > There has been a _serious_ effort amongst the customer base to< convince Compaq to also build machines for "the rest of us".   ------------------------------  % Date: Thu, 18 May 2000 18:06:57 -0400y From: "dls2" <dls2@Lehigh.EDU>  Subject: Re: VMS on the desktop?- Message-ID: <8g1pjk$khm@fidoii.CC.Lehigh.EDU>-  < "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote:" > "dls2" <dls2@Lehigh.EDU> writes:> > > Why has Compaq seen fit to release the DS10L machines with< > > two 10/100Mbps ethernet connecters?  These machines seemB > > to be marketed as ideal for clustering, yet from what has just? > > been stated about latency, the DS10L machines seem terribly: > > suited for clustering. >rF > That is the entry level current generation machine.  Certainly it isG > not going to have everything built in that you might want on a larger E > machine. I don't know what you mean by "what has just been stated". B > There are people on this group who have a standalone workstationC > and people on this group who support E*Trade.  You have to decideaE > what _your_ requirements are and buy the machine that matches them.   < The DS10L is rackmountable.  If it is rackmounted, it is NOT> sitting on a desk, and it is NOT functioning as a workstation.  ; Why have multiple DS10Ls rackmounted together, if not to be ? clustered?  And if they are clustered together, then what aboutq; the latency from using ethernet for cluster communications?h  ? I was referring to what Dan Sugalski had written about latency,n) when I wrote "what has just been stated."   C > If your requirements are "priced below 5 million dollars" you cann& > aspire to the big 32-CPU GS machine.  ? If I had anywhere near 5 million dollars to spend, I think thate? I would be looking into buying an island in the Bahamas, rather  than a computer from Compaq. :)f  @ > There has been a _serious_ effort amongst the customer base to> > convince Compaq to also build machines for "the rest of us".   ....     Derrick Shearer  dls2@Lehigh.EDUe   ------------------------------  % Date: Thu, 18 May 2000 18:29:30 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>p  Subject: Re: VMS on the desktop?, Message-ID: <39246EBA.3D03FB4E@videotron.ca>   dls2 wrote: ; > Does all (VMS?) clustering make use of distributed locks?E  N All VMS clusters do. But not all clusters do. It is one aspect where VMS still0 have leadership over the other cluster wannabes.  < > Why has Compaq seen fit to release the DS10L machines with: > two 10/100Mbps ethernet connecters?  These machines seem@ > to be marketed as ideal for clustering, yet from what has just= > been stated about latency, the DS10L machines seem terriblyx > suited for clustering.    E It all depends on what you're doing.  In many instances, ethernet forwN clustering is just fine. Also, having 2 ethers allows your machine to act as aK router/firewall/proxy server. Or you could use one ether for clustering andp0 the other for other networking (TCP/DECNET etc).   ------------------------------  % Date: Thu, 18 May 2000 18:43:37 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>d  Subject: Re: VMS on the desktop?, Message-ID: <39247208.3E2B09D4@videotron.ca>   Jerry Leslie wrote:d' > The other "VAX" is still available...t > > >   http://www.vax.co.uk/pages/navigation/mainfr_navigator.htm    I Hey, wait a minute, when I got a "I <love> my VAX" sticker from a DigitaldO employee, was that a sticker designed for Digital's VAX, or VAX's VAX ? ? ? ? ?V   ------------------------------  + Date: Thu, 18 May 2000 20:48:04 -0400 (EDT)i" From: Dan Sugalski <dan@sidhe.org>  Subject: Re: VMS on the desktop?F Message-ID: <Pine.LNX.4.10.10005182036170.990-100000@tuatha.sidhe.org>    On Thu, 18 May 2000, dls2 wrote:  > > "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote:$ > > "dls2" <dls2@Lehigh.EDU> writes:@ > > > Why has Compaq seen fit to release the DS10L machines with> > > > two 10/100Mbps ethernet connecters?  These machines seemD > > > to be marketed as ideal for clustering, yet from what has justA > > > been stated about latency, the DS10L machines seem terriblya > > > suited for clustering. > >yH > > That is the entry level current generation machine.  Certainly it isI > > not going to have everything built in that you might want on a larger G > > machine. I don't know what you mean by "what has just been stated". D > > There are people on this group who have a standalone workstationE > > and people on this group who support E*Trade.  You have to decide G > > what _your_ requirements are and buy the machine that matches them.  > > > The DS10L is rackmountable.  If it is rackmounted, it is NOT@ > sitting on a desk, and it is NOT functioning as a workstation.  ; The DS10L is a single-processor machine that'll always be aeI single-processor machine. (I think--maybe it goes to two) No offense, buttD that's about as low-end a box as you're going to get. Sure it's rackF mountable, but so are a lot of Pentium boxen, and they're low-end too.   = > Why have multiple DS10Ls rackmounted together, if not to beh > clustered?  J They appear to be targeted at Linux installs. Honestly if I were going forJ boxes I'd go for the ES40s or, at worst, the DS20s. They're rack-mountable as well.  5 > And if they are clustered together, then what about = > the latency from using ethernet for cluster communications?   I Just because you *can* cluster these things via ethernet doesn't mean youyJ *have* to. They have PCI slots in 'em, as do all the DS, ES, and GS boxes.J If I wanted to cluster them and had any sort of latency issues I'd throw aJ fibrechannel adapter or Memory Channel adapter in them. (Maybe a CIPCA, if they'll fit)  -A > I was referring to what Dan Sugalski had written about latency,g+ > when I wrote "what has just been stated."s  G Sure, but you're also looking at the current lowest-end machine, in its.> base config. Throwing a CI adapter, memory Channel adapter, orB fibrechannel adapter in just raises the cost for everyone, and not everyone needs the speed.n  H Remember, *low end*. For comparison, the cluster I do most of my work onI is four 8400s with 8-12G and 8-10 processors each. For those we don't usesD ethernet to cluster. For DS10s, well, they're rinky-dink machines. ID probably would use fast ethernet unless I saw a latency issue in the cluster.  H Sometimes the latency you get with ethernet's OK, or not annoying enoughH to be worth dropping an extra 5-10K per machine to fix. Sometimes it is. Depends on your problem domain.    					Dan   ------------------------------  % Date: Fri, 19 May 2000 01:30:46 -0400 * From: David A Froble <davef@tsoft-inc.com>  Subject: Re: VMS on the desktop?- Message-ID: <3924D186.DDB673A2@tsoft-inc.com>-   Nigel Arnot wrote: > I > Get the word out: reading any .doc file is like unsafe sex, it could be C > lethal (to your PC, your business, your continued employment ...)   P Actually, I prefer to equate it with Russian Roulette.  In both the disaster canK be quite sudden.  Strange, and sad, how many people are clueless about this?N problem.  Oh, I understand, they've been listening to billie-boy.  Some recentK rumors are that billie-boy got a rather good taste of his own medicine. :-)u   Dave   -- m4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.comt Vanderbilt, PA  15486s   ------------------------------  % Date: Fri, 19 May 2000 01:35:41 -0400 * From: David A Froble <davef@tsoft-inc.com>  Subject: Re: VMS on the desktop?- Message-ID: <3924D2AD.F4CEE5D6@tsoft-inc.com>s   "John E. Malmberg" wrote:o > N > Local observations show that it seems to take 30 Pentium Mhz to equal 1 VUP. > Your mileage may vary. >  > -Johne  L I've gotta guess that you're kidding a bit here.  Still, it is a bit amusingO that today's 1 GHz processor has finally matched, say, a MicroVAX 3100 model 90 O or maybe a model 95, some 10 years later?  But they still can't cluster them asa well as the 10 year old VAX.   Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.com  Vanderbilt, PA  15486d   ------------------------------  # Date: Thu, 18 May 2000 17:52:42 GMTt= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)MF Subject: Re: Wildfire Announcement: Michael Capellas, can you say VMS?0 Message-ID: <009EA458.CD18374F@SendSpamHere.ORG>  _ In article <3923D5A3.64F02E1D@trailing-edge.com>, Tim Shoppa <shoppa@trailing-edge.com> writes:u% >Brian Schenkenberger, VAXman- wrote:n >> r\ >> In article <FuqAA4.BBH@world.std.com>, "Terry C. Shannon" <shannon@world.std.com> writes: >> >{...snip...}M >> >Apparently you were not in NYC yesterday. Rich Marcello spent a half hour=O >> >talking to customers (nope, not the press/analyst folks, who probably can'tp> >> >even spell VMS) about OpenVMS. Did a pretty good job, too. >>  P >> Reality check.  Torquemada didn't invade the Vatican to convert the faithful! >> EP >> Compaq needs to have an Alpha and VMS inquisition to convert the billyheathen >> sinners.e >lF >         NOBODY expects the Spanish Inquisition!  Our chief weapon isF >         suprise...surprise and fear...fear and surprise....  Our twoF >         weapons are fear and surprise...and ruthless efficiency.... > >         Our *three* weapons are fear, surprise, and ruthlessG >         efficiency...and an almost fanatical devotion to the Pope....6D >         Our *four*...no...  *Amongst* our weapons....  Amongst our> >         weaponry...are such elements as fear, surprise....   >         I'll come in again.  >  >Tim.e  B I was awaiting a quote from that wonderful Monty Python schetch.  B Somehow, I expected Shane would have provided it...  Oh well, back= the "argument" in progress (or is it merely contradiction? ;)i --N VAXman- OpenVMS APE certification number: AAA-0001           VAXman@TMESIS.COM  L GNU Freeware -- What does the GNU *really* stand for?  Garbage!  Not Usable!   ------------------------------   Date: 18 May 2000 12:39 CSTe' From: carl@gerg.tamu.edu (Carl Perkins) F Subject: Re: Wildfire Announcement: Michael Capellas, can you say VMS?- Message-ID: <18MAY200012394466@gerg.tamu.edu>   ; "Arthur E. Ragosta" <ragosta@merlin.arc.nasa.gov> writes...  }"Terry C. Shannon" wrote:I }> Oh, by the way, WildFire is NT-capable (the microcode is there, a beta.N }> release booted, etc), but it ain't gonna happen. That was decided back lastK }> August 23. Microsoft dearly wanted to showcase NT on a 32-way enterprisetN }> server, but Compaq sorta kinda got sick and tired of paying $150M per annum }> in fealty to MisterBill.r } C }The proper use for $150M per year would be to fund lost-sole Decus0J }alumni to develop high-quality free software for VMS and distribute it in+ }the face of some other, unnamed companies..  I Perhaps they could send half a years worth of it to Corel. They could usedI the money and we could use a complete port of Corel WordPerfect Office invF its current version (even at just the "standard" level - that would beG WordPerfect, Quattro, Presentations, and Trellix, and probably the SDK,uM and perhaps CorelCENTRAL (for synchronizing your Palm PDA), but they probablyeI have little control over a port of the Adobe Acrobat Reader and MS Visualn Basic for Applications Tools).   --- Carl   ------------------------------  % Date: Thu, 18 May 2000 15:06:26 -0400A- From: JF Mezei <jfmezei.spamnot@videotron.ca>tF Subject: Re: Wildfire Announcement: Michael Capellas, can you say VMS?, Message-ID: <39243F31.EEBD09DD@videotron.ca>   Nigel Arnot wrote:J > Several reports of this launch suggest that VMS enjoyed a reasonably hi= ghJ > profile, but the press still report it as the launch of a Unix platform= =2Em  4 Depends on how you define "reasonable high profile".  J In Montr=E9al, the local Compaq "alpha" expert used past tense when refer= ring toaJ VMS and pushed True64 big time.  Yes, VMS was mentioned, but because they=  J *had* to mention it to prevent accusations of continuing Palmer "kill VMS=  J strategies". But Unix was PUSHED. There is a big difference between pushi= ng a product a mentioning it.  J And during the never ending boring Capellas speech, VMS was mentioned a f= ewJ times, but again, the focus was on Unix. ("The fastest Unix server in the=  J industry" to quote him). The Oracle guy didn't know nor mention VMS. At l= eastJ he did not publicly acknowledge that the "tier one" relationship applied = onlyJ to Compaq's proprietary Unix and did not apply to VMS, although it was cl= early implied.  H The article you read may have had a more balanced slant on it, but I sawJ nothing really positive about that extravaganza that wasn't. Perhaps only=  theJ question about the aeronautics industry which stomped Capellas who didn't=  seem'J aware that it was a market worth vying for (and his response, after a ver= yeJ long silence was the standard "we'll only sell to our existing niche mark=
 ets" policy).,  J This was Capellas' chance to prove himself. This was Compaq's chance to s= hineJ in the public media. This was Compaq's opportunity to show that VMS was a= liveJ and well and make some "wow" factor into the media and anlysts, both with=  this J alpha based product and with its operating systems.  Compaq acheived none=  oftH this, and this event didn't register in many/most media. HP's financials( released on the same day made more news.  J My expectations for VMS presence were low to begin with, but the delivere= d ' presentation was below my expectations.    ------------------------------  % Date: Thu, 18 May 2000 15:25:15 -0400"- From: JF Mezei <jfmezei.spamnot@videotron.ca>yF Subject: Re: Wildfire Announcement: Michael Capellas, can you say VMS?, Message-ID: <39244398.DBBC31F9@videotron.ca>   Carl Perkins wrote:gK > Perhaps they could send half a years worth of it to Corel. They could useeK > the money and we could use a complete port of Corel WordPerfect Office in   M And Corel would say YES in a minute. Because the merger with Borland has justrK fizzled, Corel won't have access to the cash it was expecting to get out of K Borland's coffers and as a result, unless new cash is found QUICK, Corel isrE expected to declare bankrupcy within 90 days if I remember correctly.   L If Compaq were to come and save Corel now, Corel would be eternally grateful to Compaq's Unix and VMS.e   ------------------------------  # Date: Thu, 18 May 2000 20:14:30 GMTm0 From: "Terry C. Shannon" <shannon@world.std.com>F Subject: Re: Wildfire Announcement: Michael Capellas, can you say VMS?& Message-ID: <FuruvL.89H@world.std.com>  / "Dan Sugalski" <dan@sidhe.org> wrote in messagei2 news:4.3.1.0.20000518120127.021a1e70@24.8.96.48.../ > At 12:16 PM 5/18/00 +0000, Nigel Arnot wrote:  > > >fK > > > But from what I've seen of the "technical press" in the UK (the likes) ofL > > > Computing, Computer Weekly, TheRegister and so on), they are generally asK > > > clueless as any other interviewer unless you're talking of billyboxes 
 > > and Intele > > > based systems. > > >y > >w& > >The technical press needs handling.  H There ya go! Note that most of the "technical press" that handles thingsI Compaq-related are peecee mavens. These folks do not grep Tru64, WildFireF3 (er, GS-Series), OpenVMS, or much of anything else.d  D Case in point... I palavered with a second-echelon CPQ person at theK WildFire launch (second echelon being one level below Michael C). We sharedcJ the opinion that CPQ is being covered/evaluated by peecee folks, not folks/ who are cognizant of true enterprise computing.e  K But there is some Good News. I will write it up and post it on the acersofteK site. In short, we can expect Really Good Stuff from the OpenVMS Group Realg	 Soon Now!h   cheers,t   terry sl$ OpenVMS Ambassador Without Portfolio   ------------------------------  % Date: Fri, 19 May 2000 00:24:01 -0500h) From: "John E. Malmberg" <wb8tyw@qsl.net> F Subject: Re: Wildfire Announcement: Michael Capellas, can you say VMS?7 Message-ID: <10ca01bfc152$738cce70$020a0a0a@xile.realm>y  . JF Mezei <jfmezei.spamnot@videotron.ca> wrote:   > Carl Perkins wrote:hI > > Perhaps they could send half a years worth of it to Corel. They couldu userJ > > the money and we could use a complete port of Corel WordPerfect Office in >-J > And Corel would say YES in a minute. Because the merger with Borland has justJ > fizzled, Corel won't have access to the cash it was expecting to get out ofJ > Borland's coffers and as a result, unless new cash is found QUICK, Corel isG > expected to declare bankrupcy within 90 days if I remember correctly.e >eE > If Compaq were to come and save Corel now, Corel would be eternallyc grateful > to Compaq's Unix and VMS.   : Compaq having it's own office suite for it's product line?  C That would make it like IBM with Lotus, or Sun with Star Office, or ! Microsoft with it's Office suite.n   Why would they want that?n   -John  wb8tyw@qsl.network   ------------------------------  + Date: Thu, 18 May 2000 17:11:49 +0000 (   )t3 From: Christopher Smith <chriss@Mufasa.pubserv.com>r* Subject: Re: Windows 98 Vs. Windows NT 4.0J Message-ID: <Pine.LNX.4.05.10005181710380.18134-100000@Mufasa.pubserv.com>  $ On Thu, 18 May 2000, Art Rice wrote:  3 > On Thu, 18 May 2000 11:19:52 +0200, Arne Vajh=F8jr! > <arne.vajhoej@gtech.com> wrote:, > >Joe Thomas wrote:L > >> What is the key differences in the Windows 98 system and the Windows N= T? ItmL > >> would just be for home use not for a business. I know it costs more bu= thL > >> still. Is there any hardware you need, and is there any specifications=  that  > >> need to be made?u > >????d1 > >Why do you post this question to comp.os.vms ?s  A > Maybe he's hoping someone will recommend a DS10 and TRU64 Unix.nH > Although that would still be the wrong news-group, it would be closer., > And, there would be another Alpha convert.  I Well, It's certainly common knowledge that if you have a windows box, youn* need something else to do all the work. ;)   Regards,   Chrisr  L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3DF "My two cents"=09=09=09(http://rootworks.com/twocentsworth.cgi?128562)C Christopher Smith(chriss@pubserv.com)=09=09=09Prgramer^W Programmerg Prime Synergy of Champaign, IL. % -------------------------------------tI "Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes anduH weighs 30 tons, computers in the future may have only 1,000 vacuum tubes= and weigh only 1.5 tons." -- Popular Mechanics, March 1949=20mL ---------------------------------------------------------------------------= ----   ------------------------------  # Date: Thu, 18 May 2000 20:43:58 GMT * From: Steven Whatley <swhatley@blkbox.com>7 Subject: Re: Windows Front End to VT Based ApplicationsA0 Message-ID: <958682638.53861@newstest.texas.net>  . Phil Howell <howellp@snowyhydro.com.au> wrote:0 > I believe Reflection can do something similar.  H I was going to suggest Reflection.  I've used it before to connect to anI HP3000.  I had some fancy scripts set up.  Initially, My terminal sessionaJ had function buttons at the bottom to login to various systems (expect forC passwords).  Then it owuld change to the proper terminal emulations.J depending on which system and then bring up buttons for common apps.  WhenH I started the apps, buttons would change to common actions for that app.  F I had some scripts on the HP3000 what would start to compile a programJ then via an escape sequence would execute a macro in Reflection that wouldI bring up WordPerfect than get info from the HP3000 and then pass the info J via DDE on to WP to fill out a templete form.  All I had to do was to save and print the document in WP.   I The current telnet client that I'm using in windows is TeraTerm Pro which H does some scripting.  It doesn't have the onscreen labels of the buttonsF nor the remote macro execution escape sequence.  But it is much better? than the default Windows telnet.  You can find TeraTerm Pro at:   7 	http://www.vector.co.jp/authors/VA002416/teraterm.htmle   Later, Steven   ------------------------------   End of INFO-VAX 2000.278 ************************