1 INFO-VAX	Sat, 12 Jul 2003	Volume 2003 : Issue 382       Contents:& A cartoon about computers and religion Re: autogen question" Re: Disk Problem after 7.3 upgrade: Re: How to close and reopen detached process's Sys$Output?+ Re: HP World: Why Alpha's Omega Makes Sense + Re: HP World: Why Alpha's Omega Makes Sense + Re: HP World: Why Alpha's Omega Makes Sense = I stumbled across an interesting set of comments about VMS... % Re: New lexical function F$DELTA_TIME % Re: New lexical function F$DELTA_TIME % Re: New lexical function F$DELTA_TIME % Re: New lexical function F$DELTA_TIME  Re: PDP-11 OS Release Dates  Re: PDP-11 OS Release Dates  Re: PDP-11 OS Release Dates  Re: PDP-11 OS Release Dates  Re: Pearl Users  RE: Pearl Users[Scanned]) Re: Portents of itanium death - revisited  Re: PPPOE? When? How? = Re: Q: How to close and reopen detached process's Sys$Output? P Re: Redirecting screen output from FMS to files and displaying them  using an emP Re: Redirecting screen output from FMS to files and displaying them  using an em" VAXstation 4000m90 with no monitor& Re: VAXstation 4000m90 with no monitor vms 7.3.1 install problem  Re: vms 7.3.1 install problem  Re: vms 7.3.1 install problem ' Re: [spam] Looking for a DLT 7000 drive   F ----------------------------------------------------------------------    Date: 12 Jul 2003 06:02:58 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) / Subject: A cartoon about computers and religion 3 Message-ID: <JPh9P$TbY2RA@eisner.encompasserve.org>   > http://ars.userfriendly.org/cartoons/?id=20030711&mode=classic   ------------------------------   Date: 12 Jul 03 15:40:33 +0200) From: p_sture@elias.decus.ch (Paul Sture)  Subject: Re: autogen question ) Message-ID: <PimGkMtwUuRL@elias.decus.ch>   n In article <b096a4ee.0307111218.64111cac@posting.google.com>, spamsink2001@yahoo.com (Alan E. Feldman) writes:\ > p_sture@elias.decus.ch (Paul Sture) wrote in message news:<aX$hrnQLo1kP@elias.decus.ch>...   <snip>   >> >  4 >> > Autogen is trying to do stuff to the Pagefiles.E >> > Personally I don't like it doing that so I have the following in  >> > modparams.dat >> >  G >> > pagefile = 0            ! Do NOT Make changes to Page & Swap Files  >> > swapfile = 0  >> > dumpfile = 0  >> >   >>  D >> Same here. The fundamental problem is when you have, say, monthlyL >> jobs which use lots of page/swap file space. If you reboot for any reasonD >> and run Autogen before those jobs have run, it will try to shrink >> the page/swap files.  > E > So skip the GENFILES phase. Apparently, AUTOGEN assumes you can use H > extra disk space. In the case of a load reduction that is not followedF > later by an increased load, this makes sense. Otherwise people would= > complain the AUTOGEN is not shrinking a too-large pagefile.  > F > AUTOGEN cannot predict the future. It is up to the sysmgr to use his8 > knowledge of the system's workload when using AUTOGEN. >   D Understood. But Brad's mention of fragmentation is relevant here, as@ continually exanding then shrinking pagefiles will lead to that.  E Your suggestion to skip the GENFILES phase is perfectly valid, but it B is another step to remember to do. I prefer reduce the level whereA finger trouble or getting distracted by the phone can cause me to  make mistakes. KISS.  C >> > That way I'll make the changes to the Pagfiles if I think it's H >> > necessary.  Autogen advises me to shrink mine, I ignore that as I'm( >> > not that constrained by free space.I >> > I also don't like the fact it'll shrink them on one Autogen and then  >> > grow them.  >>  D >> That reminds me of the time I spent monitoring the non-paged poolF >> parameters (V6.2) on a cluster with 2 VAXes and 2 Alphas. (We had aJ >> weekly reboot in order to do standalone backups,  so I got to play withE >> this over several weeks.) Autogen was continually trying to adjust K >> NPAGEDYN up or down (by a different percentage on Alpha and VAX BTW), so  > E > It may be appropriate for different percetages on the two different  > architectures. > & >> after monitoring we nailed it down. > H > This oscillating of NPAGEDYN makes sense and is not a cause for worry.G > NPAGEDYN is only the initial size of the non-paged pool. The pool can G > be expanded dynamically by the system as needed, but there is a small F > penalty for this dynamic expansion, I think it's 4% of the amount of > expansion. > @ > So, if AG finds that the pool has been expanded, it will raiseC > NPAGEDYN most of the way to the new peak, in a compromise between D > trying to minimize the penalty and not to overshoot. If AG insteadH > finds the peak size of the pool was NPAGEDYN, it apparently can't tellD > if that full amount is needed or not (since the pool never shrinksD > dynamically), so it shrinks it by about 10% (on VAX). And that mayC > still be bigger than needed. So the next AG might shrink it about G > another 10%. So the normal mode is for it to oscillate slightly about E > the "real" optimum value, which really can't be pinned down exactly H > because the load will change at least slightly from AG to AG. And evenH > if you do have a perfectly steady load, NPAGEDYN will still oscillate, > but it is not a problem. > F > When run weekly on a system with a steady load, NPAGEDYN will settleH > down to near the "optimum value" and oscillate slightly about that. IfG > NPAGEDYN is initially way too large, it will slowly, week after week, B > settle down to near the "optimum value". This avoids huge single > changes in the parameter.  > 5 > This is normal behaviour and no cause for concern.   >   G All good and technically correct points. However, our aim was to reduce I the window of possible human error as much as we could. This was a highly G critical cluster, with downtime costing a _lot_, and not just on paper.   E Not only that pressure, but it was a highly political atmosphere - we E would be grilled even for an operator calling us out of hours because C he had forgotten the SYSTEM password. Witch hunts are not pleasant.    ------------------------------  % Date: Sat, 12 Jul 2003 11:47:49 +0200 + From: "Hans Vlems" <hvlems.nieuw@zonnet.nl> + Subject: Re: Disk Problem after 7.3 upgrade 9 Message-ID: <beolg9$7gv4r$1@ID-143435.news.uni-berlin.de>   B "Christoph Gartmann" <gartmann@immunbio.mpg.de> schreef in bericht* news:bemppp$h75$1@n.ruf.uni-freiburg.de... > Hello, > L > after I upgrade an old MicroVAX3100 to OpenVMS 7.3 I have a problem with aB > RZ23 disk drive. This drive became somewhat unrealiable. I can't
 initialize it  > from other cluster nodes:  > - > $ init/system/own=system MPI1$DKB500: disk6 # > %INIT-F-MEDOFL, medium is offline  > L > When I do the same on the node where the drive is physically connected to, I  > get: > , > %INIT-F-OPINCOMPL, operation is incomplete >  > Thus, what happened here?  > 
 > Regards, >    Christoph Gartmann  > 	 Christoph   L the RZ23 is probably dead. You could try and run ANALYZE/MEDIA on the deviceI and check for bad blocks. The RZ23 is probably more than 10 years old and B most disks that age from other manufacturers are long gone. My ownL collection had RZ23, RZ23L, RZ24L, RZ25L drives and I found that the RZ23L'sF tend to have a shorter lifespan. The RZ23 still lives, the RZ23L's all/ stopped working during last year's warm summer. H What happens if you turn the disk upside down and run it that way? I didG that to a 1 GB IBM OEM disk more than a year ago and it still works :-)    Hans   ------------------------------  + Date: Sat, 12 Jul 2003 06:20:39 +0000 (UTC) 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> C Subject: Re: How to close and reopen detached process's Sys$Output? 0 Message-ID: <beo9bm$i7h$1@sparta.btinternet.com>   Hi,   / You probably already know this but if not. .  .   J Could you change your DCL to run sys$system:loginout.exe as the image withL an input .COM file that runs your C program and an output .LOG file that VMSL will flush to disk periodically for you? (I think there's a SYSGEN parameter+ that controls how frequently this is done?)   J Then you can just do your standard DISPLAYs, PRINTs, fprint() (or whatever7 cryptic nonsense C requires) and it's all done for you.    Regards Richard Maher   7 Ken Fairfield <My.Full.Name@intel.com> wrote in message # news:3F0F3557.2750455D@intel.com... 2 > Using: Compaq C V6.5-001 on OpenVMS Alpha V7.3-1 > F > I'm trying to enhance an existing program, written in C and run as aC > detached process, to periodically close it's stdout/stderr (i.e., F > Sys$Output as specified in the /Output qualifier to RUN), and reopen > a new version of the file. > C > In order that the output (log) file be readable while the process @ > is running (and it may run for months at a time), I've alreadyC > added code to the beginning of main that looks roughly like this:  > C > -----------------------------------------------------------------  >             fclose(stderr);  >             fclose(stdout); ? >             stdout = fopen("sys$output", "w", "shr=get,put");  >             stderr = stdout;) >             fd_stdout = fileno(stdout); $ >             fd_stderr = fd_stdout;C > -----------------------------------------------------------------  > F > The points here being that (1) the "shr=get,put" in the fopen allowsE > the file to be read while open for write, and (2) that I wanted the G > stderr to write to the same file as stdout.  The last two lines allow I > me to call fflush and fsync after blocks of output to force that output B > to be written immediately to the file, but they are not strictly > necessary @ > if one is willing to wait for the C RTL to do its own periodic
 > flushing...  > B > I now find that if I do the above fclsoe's and fopen in a simple
 > for-loop= > with some output in the body, the loop executes (apparently  > successfully) G > but the behaviour is as if Sys$Output was opened for _append_, rather # > than a new version being created.  > G > What do I need to do to make successive executions of the above block E > of code (suitably modified) open a NEW version of the /Output file?  > 
 > Thanks, Ken  > --8 > I don't speak for Intel, Intel doesn't speak for me... >  > Ken Fairfield # > D1C Automation VMS System Support + > kenneth[dt]h[dt]fairfield[ta]intel[dt]com    ------------------------------  % Date: Sat, 12 Jul 2003 02:25:44 -0400   From: John Santos <JOHN@egh.com>4 Subject: Re: HP World: Why Alpha's Omega Makes Sense4 Message-ID: <1030712021941.410E-100000@Ives.egh.com>    On 11 Jul 2003, Rob Young wrote:  Y > In article <3F0F373B.5040302@tsoft-inc.com>, David Froble <davef@tsoft-inc.com> writes:  > > Rob Young wrote: > >  > > I > >> 	Server parts are much lower volume.  If Intel makes $10,$20,$30 per F > >> 	CPU selling desktop CPUs and sells 30 million a year, that is a M > >> 	sustainable business model.  If turning their attention to servers they M > >> 	made that amount, they are out of business.  The 2.8 GHz Xeon MP lists  D > >> 	for somewhere near $3000.  The Opteron $700 or so.  Large OEM J > >> 	discount should knock 50% off the list price.  A 4-way 2.8 GHz Xeon K > >> 	server from a large OEM would have somewhere around $6000 CPU profit  I > >> 	built-in.  Maybe more, maybe less.  Moving to Opteron, a large OEM  L > >> 	would have maybe $1400 in CPU profit built-in.  It makes little sense H > >> 	to change from 4-way Xeons to 4-way Opterons for large OEMs.  The D > >> 	financial planners won't let the engineers make that decision. > >  > > T > > This sounds way too much like DEC trying to hold up the margins on VAX systems, 5 > > and losing market share, and finally the company.  > > R > > If a thing is possible, and you won't do it because you will make less money, = > > someone else will do it, and you will not make any money.  > >  > D > 	A whole bunch of someone elses will do it, but they are nobodies. > ? > 	The large OEMs - HP, Dell, IBM are making boatloads of money @ > 	selling 4-way Xeons.  The only thing moving to 4-way OpteronsA > 	and pushing them would be to make less money - a lot less.  So ? > 	for the large OEMs that are getting big discounts on per-cpu H > 	pricing, they have a huge financial dis-incentive to move to Opteron.A > 	Again, mom and pops receive no such discount so those 1000 CPU A > 	prices make very good sense to go the Opteron route.  Dell and B > 	others - a totally different game.  High-rollers like Dell, HP,1 > 	IBM, get special 100000 CPU pricing discounts.  > T > > Do you really think that if some white box manufacturers are making and selling T > > Opteron based servers, for less than Dell can sell a Xeon based server, that it T > > will take Mikey more than 2 seconds to get moving on some Opteron based servers? > D > 	Absolutely no move to Opteron on 4-ways!  Mike Dell is all about B > 	business.  Making a whole lot less money selling 4-way OpteronsA > 	makes absolutely no business sense.  Last time I checked, nary B > 	a server out of the 200 Intel servers I walk past now and again? > 	were whitebox.  Mid-size and larger businesses generally buy E > 	quality, i.e. tier-1 OEM.  Besides, the first large OEM that truly H > 	makes a break to Opteron puts ALL their secret large Intel discounts H > 	at risk.  They wouldn't want to sell a lot less desktops, would they? > A > 	Perhaps if AMD had a good desktop solution, maybe someone gets ? > 	frisky.  AMD is rather moribound on the desktop - near death  > 	actually. > 	 > 				Rob   ? So in other words, sell all your Dell/HP/IBM stock, find one or < two Mom&Pops that are competently run and can scale up their? manufacturing, support, sales, etc. appropriately when the time < comes, and have a catchy logo, theme song, good ad agency or? whatever, and make a mint.  Because Dell, Compaq, DEC, Sun, and @ many more were all once Mom&Pops with nothing to lose, competing, against companies with high-margin products.     --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Sat, 12 Jul 2003 04:46:24 -0400 * From: "Bill Todd" <billtodd@metrocast.net>4 Subject: Re: HP World: Why Alpha's Omega Makes Sense2 Message-ID: <47udnZupb_d2V5KiXTWJjw@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:$HrnfjR6+4lM@eisner.encompasserve.org... @ > In article <EymdnW6gaLPYQ5OiXTWJig@metrocast.net>, "Bill Todd"  <billtodd@metrocast.net> writes: > J > > That might be significant if the CPUs were the dominant cost component of) > > large systems, Rob.  But they aren't.  > 7 > Sure they are.  Take the IBM high-end offering.  Each 3 > 8-way MCM lists for $375000.  There are 4 of them 9 > in this config, for a total list price of $1.5 million:  > J > http://www.tpc.org/results/individual_results/IBM/IBMp690es_06302003.pdf  G And the 64 1.5 GHz Itanic2 processors *alone* in the SuperDome list for I $1.28 million - nearly 5x what Intel charges everyone for them, let alone I any sweetheart deal HP may have.  So the processor *prices* you're citing J bear little resemblance to the processor *costs* that I referred to:  theyK include a mark-up designed to deliver a major portion of the overall system  profit.   K Also, you seem to need to refresh your memory of what each MCM *does*, Rob: ; it's a hell of a lot more than just a container for 8 CPUs.   K The MCM reduces external board complexity very much as the EV7 on-chip glue K does:  all you need externally in both single- and multi-MCM systems is RAM K and an I/O connection.  So the MCM substitutes non only for the (4 times as C many) processor chips in an equivalent SuperDome system but for the J 4-processor zx1000 modules (perhaps something like Wildfire's QBBs, and byI some appearances not much more impressive) that they live on and whatever I switching network connects those modules together; as a side-benefit, its G compact size also allows extremely dense packaging (over and above that I allowed by the fact that a single POWER4+ dual-core chip uses little more B power than a single Itanic2 chip while providing 4 times the TPC-C
 performance).   F If you don't need that heavy-duty a solution, IBM's lower-end p-SeriesK systems use something called an SCM.  Lower still you'll have single PPC970 K processors to work with.  But in the high end, what you're paying for in an K MCM is most of the system (aside from expandible components like memory and I disk), not just the processors - and the TPC-C results indicate that said G system is more than price/performance-competitive with a SuperDome (and G likely offers at least as much margin flexibility for IBM to be able to G remain price/performance-competitive regardless of how HP may choose to  price SuperDome).   L EV7 and EV8, of course, could offer far better price/performance than eitherH Itanic2 or POWER4+, since they're 'MCMs-on-a-chip' rather than expensiveI multi-chip components.  But cHumPaq didn't find that option attractive...    > < > The largest costing thing there in the system and overall. > A > Now maybe you are getting really cheeky and the wiggle language 9 > is "dominant cost", pointing out memory is also a large : > component and if you add up ALL the other compenents CPU > cost isn't dominant? > D > The major thing large system vendors on large systems have controlE > over is CPU costs/pricing.  So this is a significant issue.  Unless B > you have a different meaning of significant or something else in > mind?   K No, Rob:  I just understand the difference between 'cost' and 'price'.  The K *cost* to HP of the 64 Itanic2s in their $6 million system is at most $270K K at Intel's list price and quite likely considerably less than that, and the H *cost* to IBM of the 32 POWER4+s in their $6+ million system is likely aH similarly small percentage.  So it really wouldn't matter at all if eachH POWER4+ processor cost twice as much as an Itanic (though with dual-coreJ chips that's rather unlikely - in fact, each POWER4+ processor may well beH *less* expensive than Itanic) - because such differences will *still* be7 minor compared with the price of the system as a whole.    >  > 4 > >>  So Itanium begins to dominate the HPC space in@ > >> a year (and no - Opteron clock cranking up won't even bring& > >> it close to Deerfield in SpecFp). > I > > Do you even roughly estimate the numbers before spewing such garbage,  Rob? > - > Implying some sort of oversight on my part?   I I wasn't implying it, Rob:  I documented it.  As usual, you shot off your 9 mouth without having a clue and hit yourself in the foot.    > I > > Deerfield runs at the same speed as McKinley with half as much cache.  ThatF > > means that it will generate SPECfp scores in the 1260 - 1270 area, >  > Right.  I'm selling futures.  H No change there:  you've been doing that since well before Wildfire, andK with results that without exception have significantly under-performed your  projections.  +   I'm thinking 2nd/3rd quarter 2004.  Let's G > be generous and boost Opteron's speed 30% and compare those two then.   G Since that's after Opteron will have moved to its 90 nm process, you're L hardly being 'generous' there.  But even at 2.6 GHz Opteron should easily beL able to beat the daylights out of a Deerfield stuck in the same process thatI it's in now and with the same power envelope.  For that matter, it should A handily beat a full-fledged Madison as well in everything but FP.    >  > See slide 37:  > < > http://www.lanl.gov/orgs/ccn/salishan2003/pdf/golliver.pdf > - > Note also, the follow-on Deerfield in 2005.   L Indeed - Itanic's first opportunity to catch up again with Opteron, but onlyK if AMD has major problems increasing the clock rate after its move to 90 nm : (and with IBM's active help that seems somewhat unlikely).  E Don't count those chickens yet, Rob:  they may well mostly be in your H imagination, as most of your other predictions have been over the years.     Problem is, AMD doesn't  > have the resources.   J For what, Rob:  process shrinks and the resulting speed-ups and cache-sizeJ increases?  That's all I've heard planned through 2004, but it's enough toL keep ahead of Itanic (which of course is limited to exactly the same thing).  H If AMD waits for 65 nm to go to a new core then Montecito *may* start toB catch up in single-processor non-FP performance (and its DeerfieldI derivative *may* start to catch up in FP performance) late in 2005 (after H the 90 nm Opteron runs out of clock headroom, somewhere North of 3 GHz).I Beyond that, of course, all bets are off until the new Itanic and Opteron  core designs are revealed.  *   Maybe someday AMD turns a profit.  Maybe > not. >  > > I > >> By the way, why do IBM, Dell, HP, etc. insist on selling 4-way Xeons D > >> instead of 4-way Opteron's?  It isn't as if Opteron hasn't been > >> out for a while.  > > L > > Earth to Rob:  4-processor Opteron boxes (and the MPUs in them) appearedJ > > this month.  IBM announced its 2-processor 1U Opteron boxes last month for H > > shipment this year - which means they'll ship sooner after Opteron's launchF > > date than IBM's Itanic2 boxes shipped after Itanic2's launch date. > >  > - > Right.  Where is IBM's 4-processor Opteron?   J It can appear any time before next Spring and still beat the delay between+ Itanic2's debut and an IBM system using it.      Doesn't it make A > sense for IBM to offer a 4-processor Opteron to compete against  > a 4-processor Xeon?   L No:  it makes sense for IBM to offer a 4-processor Opteron to cut the groundH out from under 4-processor Itanics.  Whatever it may do against Xeons is0 just gravy for IBM (but certainly good for AMD).   - bill   ------------------------------  % Date: Sat, 12 Jul 2003 05:11:02 -0400 * From: "Bill Todd" <billtodd@metrocast.net>4 Subject: Re: HP World: Why Alpha's Omega Makes Sense2 Message-ID: <CmidnZksfN0sTZKiXTWJhQ@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:ywhFm9pIvP6r@eisner.encompasserve.org...    <lots of crap snipped>     The 2.8 GHz Xeon MP lists  > for somewhere near $3000.   < If you consider $3692 to be 'somewhere near $3000', I guess.   >  The Opteron $700 or so.  K Opteron's list for $229 - $2149, depending on model and speed.  The fastest 8 current 4-processor model is the high end of that range.     Large OEM / > discount should knock 50% off the list price.   F Given that so far you haven't had a clue about the actual numbers, why should we believe that one?      A 4-way 2.8 GHz XeonF > server from a large OEM would have somewhere around $6000 CPU profitD > built-in.  Maybe more, maybe less.  Moving to Opteron, a large OEMG > would have maybe $1400 in CPU profit built-in.  It makes little sense > > to change from 4-way Xeons to 4-way Opterons for large OEMs.  G In an environment where the major players agree not to compete, perhaps L (though I have an inkling that there may be some legal ramifications to such agreements).  I However, IBM has a very good reason to field 4-processor Opteron servers: H they make Itanic look fat and pricey (mainly because Itanic *is* fat andE pricey for the low end), and what's bad for Itanic is good for POWERx C (Itanic having deep-sixed most other POWERx competition).  Grabbing F additional market share in lower-end commodity servers would be a niceH side-benefit for them as well and help keep that uppity HP in its place.I Besides, remember the maxim:  if you don't cannibalize your own products,  someone else will.   - bill   ------------------------------  % Date: Sat, 12 Jul 2003 08:42:20 -0400 + From: Ken Robinson <kenrbnsn1@patmedia.net> F Subject: I stumbled across an interesting set of comments about VMS...> Message-ID: <5.2.1.1.2.20030712084213.04826e70@mail.rbnsn.com>  H Take a look at <http://www.osnews.com/comment.php?news_id=3992> and the H comments that follow. It looks like there might be some potential users  here....  
 Ken Robinson     ------------------------------  % Date: Sat, 12 Jul 2003 01:57:47 -0400   From: John Santos <JOHN@egh.com>. Subject: Re: New lexical function F$DELTA_TIME4 Message-ID: <1030712015244.410D-100000@Ives.egh.com>  - On Fri, 11 Jul 2003, David J. Dachtera wrote:    > John Santos wrote: > > 1 > > On Thu, 10 Jul 2003, David J. Dachtera wrote:  > >  > > > Jim Strehlow wrote:  > > > > X > > > > Guy Peleg <guy.peleg@hp.com> wrote in message news:<3F0D7BFC.383CB534@hp.com>...F > > > > ... with the next Alpha VMS version V7.3-2, we will ship a new) > > > > lexical function F$DELTA_TIME ...  > > > > & > > > > Having optional parameters for< > > > > (..., "day"|"hour"|"minute"|"second", variableName )B > > > > would be "nice" to save us from parsing the result string;- > > > > but we can parse if we have to do so.  > > > > \ > > > > It would save us from writing an extra couple of lines of code (our own subroutine). > > > ! > > > Just tried these for fun...  > > > A > > > DJAS01::DDACHTERA$ say f$cvtime( "0 01:23:45.67", "delta" )  > > > 0 001:23:45.67 > > ; > > $ write sys$output f$cvtime( "2 01:23:45.67", "delta" ) D > > %DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format > >  \2 01:23:45.67\ > 
 > Hhmmm... > = > DJAS01::DDACHTERA$ say f$cvtime( "1 23:45:67.89", "delta" ) B > %DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format >  \1 23:45:67.89\ > 0 > Well! Looks like we found a bug in F$CVTIME()! >  > V7.2-2, BTW. What's yours?  H Same on all systems I tried: Alpha V7.2-1, V7.3, V7.3-1, VAX V7.1, V7.3.  A It wants a dash on input, but produces a space on output.  So you / can't feed the output back into f$cvtime again.    --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------   Date: 12 Jul 2003 10:11 CDT ' From: carl@gerg.tamu.edu (Carl Perkins) . Subject: Re: New lexical function F$DELTA_TIME- Message-ID: <12JUL200310113260@gerg.tamu.edu>   \ In article <3F0F6573.D6BD3B9@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes... }John Santos wrote:  }>  0 }> On Thu, 10 Jul 2003, David J. Dachtera wrote: }>   }> > Jim Strehlow wrote: }> > >W }> > > Guy Peleg <guy.peleg@hp.com> wrote in message news:<3F0D7BFC.383CB534@hp.com>... E }> > > ... with the next Alpha VMS version V7.3-2, we will ship a new ( }> > > lexical function F$DELTA_TIME ... }> > >% }> > > Having optional parameters for ; }> > > (..., "day"|"hour"|"minute"|"second", variableName ) A }> > > would be "nice" to save us from parsing the result string; , }> > > but we can parse if we have to do so. }> > >[ }> > > It would save us from writing an extra couple of lines of code (our own subroutine).  }> >  }> > Just tried these for fun... }> >@ }> > DJAS01::DDACHTERA$ say f$cvtime( "0 01:23:45.67", "delta" ) }> > 0 001:23:45.67  }>  : }> $ write sys$output f$cvtime( "2 01:23:45.67", "delta" )C }> %DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format  }>  \2 01:23:45.67\  } 	 }Hhmmm...  } < }DJAS01::DDACHTERA$ say f$cvtime( "1 23:45:67.89", "delta" )A }%DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format  } \1 23:45:67.89\  } / }Well! Looks like we found a bug in F$CVTIME()!  }  }V7.2-2, BTW. What's yours?  }  }--  }David J. Dachtera  ) On 7.2-1, you see this interesting thing:   5 $ write sys$output f$cvtime( "01:23:45.67", "delta" ) 
 0 01:23:45.67 6 $ write sys$output f$cvtime( "001:23:45.67", "delta" ) 0 001:23:45.677 $ write sys$output f$cvtime( "0001:23:45.67", "delta" )  0 0001:23:45.67   @ The formatting of the output fields matches the number of digits9 in the input fields. It isn't just the hour field either:   : $ write sys$output f$cvtime( "0001:023:0045.67", "delta" ) 0 0001:023:0045.67  D You are allowed to have a space in the hour filed if the first digit is a 0, but not anything else:  ; $ write sys$output f$cvtime( "0 001:023:0045.67", "delta" )  0 0001:023:0045.67; $ write sys$output f$cvtime( "1 001:023:0045.67", "delta" ) @ %DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format  \1 001:023:0045.67\; $ write sys$output f$cvtime( "1-001:023:0045.67", "delta" )  1 001:023:0045.67    And finally:  B $ write sys$output f$cvtime( "0001-0001:00023:00045.67", "delta" ) 0001 0001:00023:00045.67  E You can add one more digit before it gives an IVDTIME error (I expect F it is from exceeding the maximum allowed string length for the input).   How strange is that?   --- Carl   ------------------------------   Date: 12 Jul 2003 11:11 CDT ' From: carl@gerg.tamu.edu (Carl Perkins) . Subject: Re: New lexical function F$DELTA_TIME- Message-ID: <12JUL200311113700@gerg.tamu.edu>   + carl@gerg.tamu.edu (Carl Perkins) writes... ] }In article <3F0F6573.D6BD3B9@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes...  }}John Santos wrote:1 }}> On Thu, 10 Jul 2003, David J. Dachtera wrote:  }}> > Jim Strehlow wrote:  }}> > > X }}> > > Guy Peleg <guy.peleg@hp.com> wrote in message news:<3F0D7BFC.383CB534@hp.com>...F }}> > > ... with the next Alpha VMS version V7.3-2, we will ship a new) }}> > > lexical function F$DELTA_TIME ...  }}> > > & }}> > > Having optional parameters for< }}> > > (..., "day"|"hour"|"minute"|"second", variableName )B }}> > > would be "nice" to save us from parsing the result string;- }}> > > but we can parse if we have to do so.  }}> > > \ }}> > > It would save us from writing an extra couple of lines of code (our own subroutine). }}> > ! }}> > Just tried these for fun...  }}> > A }}> > DJAS01::DDACHTERA$ say f$cvtime( "0 01:23:45.67", "delta" )  }}> > 0 001:23:45.67 }}> ; }}> $ write sys$output f$cvtime( "2 01:23:45.67", "delta" ) D }}> %DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format }}>  \2 01:23:45.67\ }}  
 }}Hhmmm... }}  = }}DJAS01::DDACHTERA$ say f$cvtime( "1 23:45:67.89", "delta" ) B }}%DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format }} \1 23:45:67.89\ }}  0 }}Well! Looks like we found a bug in F$CVTIME()! }}   }}V7.2-2, BTW. What's yours? }}   }}--   }}David J. Dachtera  } * }On 7.2-1, you see this interesting thing: } 6 }$ write sys$output f$cvtime( "01:23:45.67", "delta" ) }0 01:23:45.677 }$ write sys$output f$cvtime( "001:23:45.67", "delta" )  }0 001:23:45.67 8 }$ write sys$output f$cvtime( "0001:23:45.67", "delta" ) }0 0001:23:45.67 } A }The formatting of the output fields matches the number of digits : }in the input fields. It isn't just the hour field either: } ; }$ write sys$output f$cvtime( "0001:023:0045.67", "delta" )  }0 0001:023:0045.67  } E }You are allowed to have a space in the hour filed if the first digit  }is a 0, but not anything else:  } < }$ write sys$output f$cvtime( "0 001:023:0045.67", "delta" ) }0 0001:023:0045.67 < }$ write sys$output f$cvtime( "1 001:023:0045.67", "delta" )A }%DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format  } \1 001:023:0045.67\ < }$ write sys$output f$cvtime( "1-001:023:0045.67", "delta" ) }1 001:023:0045.67 } 
 }And finally:  } C }$ write sys$output f$cvtime( "0001-0001:00023:00045.67", "delta" )  }0001 0001:00023:00045.67  } F }You can add one more digit before it gives an IVDTIME error (I expectG }it is from exceeding the maximum allowed string length for the input).  }  }How strange is that?  } 	 }--- Carl   1 Following up my own post, since I made a mistake.   L Above I said "You are allowed to have a space in the hour filed if the first= digit is a 0, but not anything else" but that is not correct.   E You can have a space in the hour field, as long as removing the space  makes it a valid hour:  9 $ write sys$output f$cvtime( "1 1:023:0045.67", "delta" )  0 11:023:0045.67  9 $ write sys$output f$cvtime( "2 1:023:0045.67", "delta" )  0 21:023:0045.67  9 $ write sys$output f$cvtime( "3 1:023:0045.67", "delta" ) @ %DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format  \3 1:023:0045.67\  E This failed because there are not 31 hours in the day. In the various B examples with non-zero first dgits from other people up above theyA attempted 3 digit hours (with a space before the last two), which  is why they didn't work.  < $ write sys$output f$cvtime( "0002 1:023:0045.67", "delta" ) 0 00021:023:0045.67   J The space is not a separator for the day, it is a space in the hour field.  2 For that matter, you can have spaces in any field:  @ $ write sys$output f$cvtime( "0002 1:0 23:00  45. 67", "delta" ) 0 00021:023:0045.67   I However any space between a number and the following colon become a zero:   5 $ write sys$output f$cvtime( "1 :01:45.67", "delta" ) 
 0 10:01:45.67   6 $ write sys$output f$cvtime( "1 :01 :45.67", "delta" ) 0 10:010:45.67  4 Likewise for a number and a following decimal point:  6 $ write sys$output f$cvtime( "1 :01 :5 .67", "delta" ) 0 10:010:50.67  A You should note that in a combination time you can't have a spaceeB after the "+", but other than that one case spaces (and extraneous? leading zeros) in the delta portion don't seem to matter exceptWB that spaces between the number and the following colon are treated	 as zeros.o  H $ write sys$output f$cvtime("01-JAN-2222 +1-01 : 2 3: 45.67","absolute") 2-JAN-2222 10:23:45.67  I $ write sys$output f$cvtime("01-JAN-2222 +1-01 : 2 3 : 45.67","absolute")M& %DCL-W-IVATIME, invalid absolute time "  \01-JAN-2222 +1-01 : 2 3 : 45.67\  G $ write sys$output f$cvtime("01-JAN-2222 +1-01 : 2 : 45.67","absolute")  2-JAN-2222 10:20:45.67  K Leading zeros in the numeric parts of an absolute time don't matter either:   . $ write sys$output f$cvtime( "001-JAN-002222") 2222-01-01 00:00:00.009 $ write sys$output f$cvtime( "001-JAN-002222","ABSOLUTE")i 1-JAN-2222 00:00:00.00  F So it may be even stranger than it looked before, but it is strange inJ a very orderly way. A space after the "+" in a combination time is invaid.J Spaces between a number and a following punctuation mark (colon or decimalG point) are converted to zeros. All other spaces are removed. The number-J of digits remaining is the number of digits that will appear in the outputG and this can be influenced by adding leading zeros to increase the sizeeB of the field, or traling zeros in the hundredths of a second part.    1 $ write sys$output f$cvtime( "1:1:5.7", "delta" )&	 0 1:1:5.7c  ; $ write sys$output f$cvtime( "001 : 1 : 005.700", "delta" )+ 0 0010:10:005.700@   --- Carl   ------------------------------  % Date: Sat, 12 Jul 2003 17:11:05 +0200@$ From: Michael Unger <unger@decus.de>. Subject: Re: New lexical function F$DELTA_TIME9 Message-ID: <bepea6$7mf9m$1@ID-152801.news.uni-berlin.de>a  & On 10-Jul-2003 16:45, Guy Peleg wrote:   > Hello DCL gurus, > I > I thought you might be interested  to know that with the next Alpha VMSa$ > version V7.3-2, we will ship a new  > lexical function F$DELTA_TIME. > F > F$DELTA returns the difference between a beginning and end time. The% > first argument is an absolute time,>F > the second argument can be absolute or delta time. See the following
 > example. >  > BLUSKY> start=f$time() > BLUSKY> end=f$time() > BLUSKY> sh sym start% >   START = "10-JUL-2003 17:38:06.82"a > BLUSKY> sh sym end# >   END = "10-JUL-2003 17:38:30.64"h- > BLUSKY> write sys$output f$delta(start,end)h >    0 00:00:23.82 > * > No it won't be backported to VAX 5.5-2 . > & > As usual, your comments are welcome.  E Another question: are leap years taken into account? (Well, Y2k was aeA special case, the next one will be 2400; VMS 43.2 perhaps ... :-)a   Michaele   --    @ Please do *not* send "Security Patch Notifications" or "SecurityA Updates"; this system isn't running a Micro$oft operating system. = And don't annoy me <mailto:postmaster@[127.0.0.1]> please ;-)e   ------------------------------  ! Date: Sat, 12 Jul 03 08:08:20 GMT  From: jmfbahciv@aol.com $ Subject: Re: PDP-11 OS Release Dates+ Message-ID: <beon58$gl9$1@bob.news.rcn.net>I  , In article <benmcs028j6@enews2.newsguy.com>,6    "Zane H. Healy" <healyzh@shell1.aracnet.com> wrote:A >In vmsnet.pdp-11 Dennis Grevenstein <dennis@pcde.inka.de> wrote:i4 >> In alt.sys.pdp11 healyzh@noaracnetspam.com wrote: >>> K >>> Is OS-11 related to RT-11?  I think this is the first I've heard of it.  >>  2 >> It's mentioned in some RT-11 guide I have here. >> I don't know it myself. >mA >I just found the following post from Sept. 2002 from Tim Shoppa:-' >"The RT-11 Historical Overview states:s > B >  The year 1971 was an exciting time...A popular operating systemF >  for the PDP-8, called OS/8, was the design model for the new PDP-110 >  operating system, tentatively called OS-11... >EA >  ...in the fall of 1972...the groundwork was laid to make OS-11 & >  compatible with OS/8 and TOPS-10... > E >  OS-11 was renamed first to RTPS-11 (Real-Time Programming System),rF >  then to RT-11 (Real Time).  Version 1 of RT-11 was completed in the >  fall of 1973."o  ? Speculation:  I think it would have been difficult to trademark.  a generic name like OS-whatever.   /BAH  ' Subtract a hundred and four for e-mail.l   ------------------------------  # Date: Sat, 12 Jul 2003 12:06:19 GMTf) From: bob smith <sfmc68@bellatlantic.net>t$ Subject: Re: PDP-11 OS Release Dates6 Message-ID: <%QSPa.8057$C07.2723@nwrddc02.gnilink.net>   Zane H. Healy wrote:B > In vmsnet.pdp-11 Dennis Grevenstein <dennis@pcde.inka.de> wrote: > 3 >>In alt.sys.pdp11 healyzh@noaracnetspam.com wrote:  >>J >>>Is OS-11 related to RT-11?  I think this is the first I've heard of it. >> >> i1 >>It's mentioned in some RT-11 guide I have here.  >>I don't know it myself.  >  > B > I just found the following post from Sept. 2002 from Tim Shoppa:( > "The RT-11 Historical Overview states: > C >   The year 1971 was an exciting time...A popular operating systemcG >   for the PDP-8, called OS/8, was the design model for the new PDP-11 1 >   operating system, tentatively called OS-11...G > B >   ...in the fall of 1972...the groundwork was laid to make OS-11' >   compatible with OS/8 and TOPS-10...G > F >   OS-11 was renamed first to RTPS-11 (Real-Time Programming System),G >   then to RT-11 (Real Time).  Version 1 of RT-11 was completed in thee >   fall of 1973." > 	 > 			ZaneaH Thank you, the cobwebs were there in my memory and the dust covered the > boxes but I recall this is correct.  There may have been some H perturbance in the 8/11 tensions later when Don White and the boys of 8 F land put together that FPP8a thing and the bench marks made it fastet F (and more accurate) than certain mid range 11 models.  And then there < was the 8 with a cache that was faser than the fastest 11...   ------------------------------  # Date: Sat, 12 Jul 2003 12:08:06 GMTo) From: bob smith <sfmc68@bellatlantic.net>S$ Subject: Re: PDP-11 OS Release Dates6 Message-ID: <GSSPa.8089$C07.1838@nwrddc02.gnilink.net>   jmfbahciv@aol.com wrote:  . > In article <benmcs028j6@enews2.newsguy.com>,8 >    "Zane H. Healy" <healyzh@shell1.aracnet.com> wrote: > B >>In vmsnet.pdp-11 Dennis Grevenstein <dennis@pcde.inka.de> wrote: >>4 >>>In alt.sys.pdp11 healyzh@noaracnetspam.com wrote: >>>.K >>>>Is OS-11 related to RT-11?  I think this is the first I've heard of it.o >>>V >>> 2 >>>It's mentioned in some RT-11 guide I have here. >>>I don't know it myself. >>B >>I just found the following post from Sept. 2002 from Tim Shoppa:( >>"The RT-11 Historical Overview states: >>B >> The year 1971 was an exciting time...A popular operating systemF >> for the PDP-8, called OS/8, was the design model for the new PDP-110 >> operating system, tentatively called OS-11... >>A >> ...in the fall of 1972...the groundwork was laid to make OS-11t& >> compatible with OS/8 and TOPS-10... >>E >> OS-11 was renamed first to RTPS-11 (Real-Time Programming System), F >> then to RT-11 (Real Time).  Version 1 of RT-11 was completed in the >> fall of 1973."a >  > A > Speculation:  I think it would have been difficult to trademark " > a generic name like OS-whatever. >sH au contraire. Look in the front of most any book by digital and see the H trademearked names - Omnibus, Unibus, OS/8, PS/8. RTS8, RT11, and so on.! Oh, yeah and TOPS20, Tops10, etc.t   > /BAH > ) > Subtract a hundred and four for e-mail.    ------------------------------   Date: 12 Jul 03 14:36:46 +0200) From: p_sture@elias.decus.ch (Paul Sture)c$ Subject: Re: PDP-11 OS Release Dates) Message-ID: <N4EbaxEWIIox@elias.decus.ch>d  \ In article <110720032007475862%elliott@yrl.co.uk>, Elliott Roper <elliott@yrl.co.uk> writes:A > In article <bekbut$3m2$1@aton.pcde.inka.de>, Dennis Grevensteinu > <dennis@pcde.inka.de> wrote: > 4 >> In alt.sys.pdp11 healyzh@noaracnetspam.com wrote: >> > aL >> > Is OS-11 related to RT-11?  I think this is the first I've heard of it. >>  2 >> It's mentioned in some RT-11 guide I have here. >> I don't know it myself. > E > It has been a long time, so I might be wrong. ISTR there was not anrH > OS-11 but there was a DOS-11 in the very early PDP-11 days. There were! > remnants of it in the RSTS CIL.m > , > Yep. I found this on Deja-Google from 1994 > J > http://www.google.com/groups?q=DOS-11&start=10&hl=en&lr=&ie=UTF-8&safe=o2 > ff&selm=940927100650.62%40arisia.gce.com&rnum=13 > # > If Everhart said it, it is right.r > F > Show complete thread when you get there. Some famous names are still > around here.  G Thanks for that link. It brought back fond memories of RT-11, includingh2 ones of RSX feeling tardy at times in contrast :-)   ------------------------------   Date: 12 Jul 03 14:25:22 +0200) From: p_sture@elias.decus.ch (Paul Sture)o Subject: Re: Pearl Users) Message-ID: <yIQnNzpG8wqd@elias.decus.ch>-  U In article <3F0F03F7.2BC22B6A@pacbell.net>, Don Sykes <anonymous@pacbell.net> writes:  >  >  > Rob Young wrote: >> yX >> In article <3F0D9DFC.8CB8FA99@pacbell.net>, Don Sykes <anonymous@pacbell.net> writes: >> >H >> > I don't know Pearl at all, but it seems to be very popular with COV >> > folks.-@ >> > Can anyone give me a brief list of its advantages over DCL? >> > >> h4 >>         Pearl must be Perl's cousin or something. >>  I > I TOLD you I didn't know it at all!:) I assume is an acronym then. Whati > does it stand for? >  >    From:   2 http://practicalperl.com/slides/L01/slide_017.html   What does Perl stand for?b  3      Perl: Practical Extraction and Report Languagei        It's not PERL or P.E.R.L.  K      'Perl' refers to the language; 'perl' to the compiler/interpreter that &      runs the programs written in Perl   ------------------------------  % Date: Sat, 12 Jul 2003 01:37:28 -0400e  From: John Santos <JOHN@egh.com>! Subject: RE: Pearl Users[Scanned]s4 Message-ID: <1030712013706.410C-100000@Ives.egh.com>  ( On Fri, 11 Jul 2003, Steve Spires wrote:  B > Isn't Pearl a LISP implementation? ISTR it when I was 'Lisping'.  % Naw, it's Janice Joplin's last album.      >  > Steve Spires > Technical Consultant > Torex Health > [P](44)01295 274388s > [F](44)01295 275131e > www.torex.com  >  > > -----Original Message-----9 > > From: Larry Kilgallen [mailto:Kilgallen@SpamCop.net] - > > Sent: 11 July 2003 15:30 > > To: Info-VAX@Mvb.Saic.Comr% > > Subject: Re: Pearl Users[Scanned]: > >  > > @ > > In article <3F0EC2DA.DC7EAC9A@vcu.edu>, Jim Agnew - VCU/MCV * > > Neurosurgery <jpagnew@vcu.edu> writes: > > E > > > ok, I'll bite... what was it like? like perl, cobol, basic, or d > > > snobol4? > > J > > My familiarity with Pearl is seeing it on product lists, not using it. > >  > >  > >  >  >    -- 3 John Santos	 Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Sat, 12 Jul 2003 05:17:39 -0400 * From: "Bill Todd" <billtodd@metrocast.net>2 Subject: Re: Portents of itanium death - revisited2 Message-ID: <2rqcnZ0E_J6gT5KiXTWJhA@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:nQRo3fcy8Kuk@eisner.encompasserve.org...r   ...      So when do you expect we see/ > 100K tmpC with 4-way Xeons?  Sooner or later?r  G Not my problem, Rob:  *you* were the one claiming that they'd leave the4J 4-processor Opterons (which, by the way, aren't using the fastest RAM theyK support in the RackSaver TPC-C submission, and of course are also getting anK speed bump next month) in the dust, so now that your initial prediction has L fallen flat on its face I guess you've got some digging to do if you want to@ find another at least superficial basis for your preconceptions.   - bill   ------------------------------  # Date: Sat, 12 Jul 2003 16:45:30 GMTl1 From: Michael Austin <maustin@firstdbasource.com>  Subject: Re: PPPOE? When? How?2 Message-ID: <3F1033F1.C76EDC20@firstdbasource.com>   Didier Morandi wrote:  >  > Hello happy tax payers,  > * > I want to pppoe from my Alpha to my ISP.I > I found in the FAQ that there is no such PPP for the moment for obscuree > reasons (to me). > 8 > Did anyone succeed to do that with a particular tool ? > 	 > Thanks,  >  > D. > --/ > Didier Morandi sarl au capital de 8 000 euros  >                     Tout VMS/ >   19 chemin de la Butte 31400 Toulouse Francen/ >   Tl: 33(0)5 6120 1964 Fax: 33(0)5 6154 1928 ( >           http://www.didiermorandi.com& >             RCS Toulouse 448 694 851      / How do you put your VMS box on BroadBand?  see: , http://www.firstdbasource.com/vms-on-bb.html     -- l Regards,  6 Michael Austin            OpenVMS User since June 19847 First DBA Source, Inc.    Registered Linux User #261163e   ------------------------------  # Date: Sat, 12 Jul 2003 11:41:33 GMTm" From:   VAXman-  @SendSpamHere.ORGF Subject: Re: Q: How to close and reopen detached process's Sys$Output?0 Message-ID: <00A22BD1.7E1DAEF1@SendSpamHere.ORG>  X In article <3F0F3557.2750455D@intel.com>, Ken Fairfield <My.Full.Name@intel.com> writes:1 >Using: Compaq C V6.5-001 on OpenVMS Alpha V7.3-1s > E >I'm trying to enhance an existing program, written in C and run as aOB >detached process, to periodically close it's stdout/stderr (i.e.,E >Sys$Output as specified in the /Output qualifier to RUN), and reopens >a new version of the file.  >rB >In order that the output (log) file be readable while the process? >is running (and it may run for months at a time), I've alreadytB >added code to the beginning of main that looks roughly like this: >sB >----------------------------------------------------------------- >            fclose(stderr); >            fclose(stdout);> >            stdout = fopen("sys$output", "w", "shr=get,put");   Try:       char logfilenm[255];        fgetname(stdout, logfilenm);     fclose(stdout);   0     stdout = fopen(logfilenm,"w","shr=get,put");   >            stderr = stdout;a( >            fd_stdout = fileno(stdout);# >            fd_stderr = fd_stdout;6B >----------------------------------------------------------------- >0E >The points here being that (1) the "shr=get,put" in the fopen allows:D >the file to be read while open for write, and (2) that I wanted theF >stderr to write to the same file as stdout.  The last two lines allowH >me to call fflush and fsync after blocks of output to force that outputA >to be written immediately to the file, but they are not strictlyc >necessary e? >if one is willing to wait for the C RTL to do its own periodicn >flushing... > A >I now find that if I do the above fclsoe's and fopen in a simple.
 >for-loop < >with some output in the body, the loop executes (apparently >successfully)F >but the behaviour is as if Sys$Output was opened for _append_, rather" >than a new version being created. >eF >What do I need to do to make successive executions of the above blockD >of code (suitably modified) open a NEW version of the /Output file? >l
 >	Thanks, Kenn  @ You may need to massage the contents of logfilenm to get this to work as desired.   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMy            a5   "Well my son, life is like a beanstalk, isn't it?" l   ------------------------------  % Date: Sat, 12 Jul 2003 11:08:46 +0100 " From: "Rolona" <nospam@nospam.com>Y Subject: Re: Redirecting screen output from FMS to files and displaying them  using an emt< Message-ID: <TARPa.456$F33.132@news-binary.blueyonder.co.uk>  K I don't see the point of dumping VMS if you just want to do the same thing.o You wont get the reliability.o  E "Jim Agnew - VCU/MCV Neurosurgery" <jpagnew@vcu.edu> wrote in messagee! news:3F0EBBA2.13A94622@vcu.edu...m1 > sorry to hear that you company is that offbeat.  > I > however, you can write up "screen scrapers" in Kermit to download this.  >t$ > but, what do you mean by a "dump"? >tD > do you want to print off the screen to allow the new developers to > duplicate it?a >a. > do you need electronic copies of the screen? >4; > do you need "functional" electronic copies of the screen?c >h, > can you enlighten us with your wants, sir? >) > Jimf >u > Deepak wrote:h > >d > > Hi,u > > J > > The company I work for is shutting down their VMS system at the end ofJ > > the year. We use FMS for displaying online screens. We want to know if > > there is some way we can > >sI > > 1. Dump the FMS screen output from online applications to text files.k > >t2 > > 2. Display this screen dump using an emulator. > >tJ > > Is there any way we can do this? I would greatly appreciate if someone! > > could suggest some solutions.h > >iG > > Also, we are using VT400 7-bit emulators (Attachmate Enterprise andeJ > > WRQ Reflection) to diplay the VMS screens now. Is there any way we can? > > display the corresponding screen dumps in a VT220 emulator.n > >r4 > > Please post a reply if you have any suggestions. > >i > > Thank you. > >e
 > > Deepak >a > --H > "4,000 years ago I made a mistake."  Elrond Half-Elven, in "Fellowship > of the Ring" > H > "I try not to be right any more than necessary". -- Larry Wall, author > of the Perl Language   ------------------------------   Date: 12 Jul 03 15:49:21 +0200) From: p_sture@elias.decus.ch (Paul Sture)iY Subject: Re: Redirecting screen output from FMS to files and displaying them  using an em ) Message-ID: <sB2GjrJ2q2Fb@elias.decus.ch>g  e In article <38dea33f.0307111331.78eb07e1@posting.google.com>, deepakonline@myway.com (Deepak) writes: % >> but, what do you mean by a "dump"?n > F > They want to get rid of the VMS system, but still be able to see theF > static data in the online FMS screens exactly as they are doing now. > ForcC > this they want to dump all the screen views possible (millions ofs > them) G > into files. This dump should be in a format that is understandable to C > a screen emulator. So that when they need to see the screen for aaF > particular key, they can use the emulator to read the dump file and F > display the screen. So it will look as though they are seeing an FMS< > screen though the emulator will be running on Unix/Windows > E >> do you want to print off the screen to allow the new developers tod >> duplicate it? >  > No, that is not the idea.e > < >> do you need "functional" electronic copies of the screen? >  > Yes, that's the idea.e >   ? You could have a look at Cyrano's Test product, as described at   ( http://www.cyrano.com/support/downloads/* (Ugh! there's that damn legacy word again)   and.  ) http://www.telgen.co.uk/products/test.htm     F Disclaimer: I used that product myself over 10 years ago and I believeG it would extract the information you wish. I have not used it since, soi8 have no idea whether its functionality may have changed.   ------------------------------    Date: 12 Jul 2003 11:23:06 +02002 From: "Lars Holmstrm" <lars.holmstrom@flysta.net>+ Subject: VAXstation 4000m90 with no monitord( Message-ID: <3f0fd379$1@news.wineasy.se>  E I have a VAXstation 4000m90 and would like to use it with no monitor. . I connected a VT terminal to the console port.  J There is a switch at the fronpanel called S3. SHould this switch be in the up or down position ?u   Should the console be 9k6 8N1 ?s   /Larsb   ------------------------------  # Date: Sat, 12 Jul 2003 09:37:55 GMTt6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)/ Subject: Re: VAXstation 4000m90 with no monitor 4 Message-ID: <TFQPa.75191$1F6.1047662@news.chello.at>  ] In article <3f0fd379$1@news.wineasy.se>, "Lars Holmstrm" <lars.holmstrom@flysta.net> writes:fF >I have a VAXstation 4000m90 and would like to use it with no monitor./ >I connected a VT terminal to the console port.m  D You know which of the serial ports is the (alternate) console port ?' The DEC423 one with the printer icon...   K >There is a switch at the fronpanel called S3. SHould this switch be in they >up or down position ?   Up - Serial Consolet Down - Graphical Console    >Should the console be 9k6 8N1 ?   Yup.   -- u Peter "EPLAN" LANGSTOEGERr% Network and OpenVMS system specialistp E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  # Date: Sat, 12 Jul 2003 03:18:45 GMTf4 From: "Phillip R Sobottke" <psobottke@ameritech.net>" Subject: vms 7.3.1 install problem? Message-ID: <p6LPa.7809$Vx2.3832577@newssvr28.news.prodigy.com>*  K I'm trying to install 7.3.1 on an alphaserver 1200.  The install completed,uD but after running autogen..it hangs on the reboot and kicks out.  ItK mentions an error about unable to load the terminal.  I remember a year agorJ when installing 7.2.1 on this machine, I got a similar error..and fixed itD by modifing some parameters using sysgen.  Anyone have any idea what0 parameters I need to change, and to what values?   ------------------------------  % Date: Sat, 12 Jul 2003 02:43:09 -0400p  From: John Santos <JOHN@egh.com>& Subject: Re: vms 7.3.1 install problem4 Message-ID: <1030712023704.410B-100000@Ives.egh.com>  . On Sat, 12 Jul 2003, Phillip R Sobottke wrote:  M > I'm trying to install 7.3.1 on an alphaserver 1200.  The install completed,eF > but after running autogen..it hangs on the reboot and kicks out.  ItM > mentions an error about unable to load the terminal.  I remember a year agoeL > when installing 7.2.1 on this machine, I got a similar error..and fixed itF > by modifing some parameters using sysgen.  Anyone have any idea what2 > parameters I need to change, and to what values?  0 Please post the exact text of the error message.  / The error cited above is not meaningful in VMS.m    B I'm running V7.3-1 on an AS1200 with no problems.  It should work.    C Are you sure it isn't complaining about SYSGEN parameters being too:B small to start DECWindows-Motif?  At one time (not sure if this is> fixed now in V7.3-1), it offered to run AUTOGEN to bump up the@ parameters and reboot, but AUTOGEN either didn't change anything< or the changes it made were insufficient, and it went into a? seemingly infinite loop of REBOOT, AUTOGEN, REBOOT, AUTOGEN ...t  = The cure was to tell it not to run AUTOGEN, wait for the boots@ to finish, log in at the console (which was still possible, even@ with a graphics console, in glass-TTY mode), manually change the7 sysgen parameters it was complaining about, and reboot.a       --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------   Date: 12 Jul 03 16:24:15 +0200) From: p_sture@elias.decus.ch (Paul Sture)a& Subject: Re: vms 7.3.1 install problem) Message-ID: <1qUXjk+2eV7y@elias.decus.ch>f  W In article <1030712023704.410B-100000@Ives.egh.com>, John Santos <JOHN@egh.com> writes:e0 > On Sat, 12 Jul 2003, Phillip R Sobottke wrote: > N >> I'm trying to install 7.3.1 on an alphaserver 1200.  The install completed,G >> but after running autogen..it hangs on the reboot and kicks out.  ItaN >> mentions an error about unable to load the terminal.  I remember a year agoM >> when installing 7.2.1 on this machine, I got a similar error..and fixed ithG >> by modifing some parameters using sysgen.  Anyone have any idea whatr3 >> parameters I need to change, and to what values?o > 2 > Please post the exact text of the error message. > 1 > The error cited above is not meaningful in VMS.n >  > D > I'm running V7.3-1 on an AS1200 with no problems.  It should work. >  > E > Are you sure it isn't complaining about SYSGEN parameters being toodD > small to start DECWindows-Motif?  At one time (not sure if this is@ > fixed now in V7.3-1), it offered to run AUTOGEN to bump up theB > parameters and reboot, but AUTOGEN either didn't change anything> > or the changes it made were insufficient, and it went into aA > seemingly infinite loop of REBOOT, AUTOGEN, REBOOT, AUTOGEN ...l > ? > The cure was to tell it not to run AUTOGEN, wait for the bootmB > to finish, log in at the console (which was still possible, evenB > with a graphics console, in glass-TTY mode), manually change the9 > sysgen parameters it was complaining about, and reboot.H >   > I have the same feeling about this one, and here's my entry in MODPARAMS.DAT to cope with it:  B MIN_GBLSECTIONS=1000    ! get around DECwindows looping on startup   ------------------------------  % Date: Sat, 12 Jul 2003 17:56:43 +0200 8 From: "Tomasz Dryjanski" <tdryjanski.nospam@hotmail.com>0 Subject: Re: [spam] Looking for a DLT 7000 drive. Message-ID: <bepb58$68b$1@nemesis.news.tpi.pl>  L > > We need a DLT 7000 (IV) external tape drive. Unfortunately it is already > > unavailable on the market. > > Sorry for spamming >r0 > My inclination would not be to call that spam.! > But thank you for your concern.e  ; Well, this is not for an Alpha system, but for Intel NT. ;)nE But people here are known to me as having plenty of old equipment. :)r   T. D.e   ------------------------------   End of INFO-VAX 2003.382 ************************