1 INFO-VAX	Wed, 06 Dec 2006	Volume 2006 : Issue 671       Contents:! Re: Alpha sales extended 6 months ! Re: Alpha sales extended 6 months ! Re: Alpha sales extended 6 months ! Re: Alpha sales extended 6 months ! Re: Alpha sales extended 6 months ! Re: Alpha sales extended 6 months  Re: Alternative to FTP Re: Alternative to FTP Re: Alternative to FTP DEC Educational Stuff ! Re: DECNET during SYSHUTDWN.COM ?  DWZZB-AA Homemaid keycap mnemonics ?  Mozilla  Re: Newbie needs advice  Re: Novice's questions Re: Novice's questions Re: Novice's questions Re: Novice's questions Re: Novice's questions Re: Novice's questions Re: recursive copy in VMS  Re: recursive copy in VMS K Re: Seemingly different results with backup of file in and out of procedure ' Re: Suggestion for TYPE (output pacing)  Re: VMS  Alpha  Console (VGA)   F ----------------------------------------------------------------------   Date: 6 Dec 2006 03:57:19 -0800 ! From: "Ian Miller" <gxys@uk2.net> * Subject: Re: Alpha sales extended 6 monthsB Message-ID: <1165406239.693554.133090@79g2000cws.googlegroups.com>   Paul Sture wrote:  > I > Did anyone else notice that the last set of VMS roadmaps mentioned 2013  > instead of the previous 2011?  >   G Basically they talk about things up to five years from when the roadmap D presentation is issued. The VMS Rolling roadmap gets updated and the dates on the right move later.   ------------------------------  % Date: Wed, 06 Dec 2006 14:31:48 +0800  From: prep@prep.synonet.com * Subject: Re: Alpha sales extended 6 months0 Message-ID: <87slftv8kr.fsf@k9.prep.synonet.com>  / JF Mezei <jfmezei.spamnot@teksavvy.com> writes:   B >  From HP's point of view, a customer not allowed to order enoughE > Alphas to last a number of years would be a customer migrating to a @ > non-HP solution sooner. Allowing them to buy Alphas makes that > customer stay with HP longer.   F I think enough people have told hp to go take a flying squirt in theirA ink, and everything else with hp one it, and never cross the door  again.   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.? ------------ And now a word from our sponsor ------------------ = For a quality usenet news server, try DNEWS, easy to install, ? fast, efficient and reliable. For home servers or carrier class ? installations with millions of users it will allow you to grow! ? ----  See http://netwinsite.com/sponsor/sponsor_dnews.htm  ----    ------------------------------  $ Date: Wed, 6 Dec 2006 09:51:43 -0500) From: "Neil Rieck" <n.rieck@sympatico.ca> * Subject: Re: Alpha sales extended 6 months; Message-ID: <4576d7f9$0$1606$9a6e19ea@news.newshosting.com>   6 "Bill Todd" <billtodd@metrocast.net> wrote in message A news:A66dnQ3A6_fTyevYnZ2dnUVZ_sCdnZ2d@metrocastcablevision.com...  > Neil Rieck wrote:  [...snip...] > K > Probably not:  HP mostly seems to be hoping that Alpha will just quietly  M > fade away, so there's no reason to call attention to it - especially after  M > they've stopped selling them.  VMS customers are seen as either captive or  K > already gone (no noticeable class of *new* customers), so there's little  $ > reason to waste much time on them. > I > Besides, VMS has been somewhat faster on Itanic for most workloads for  J > over three years now:  McKinley was not all that much slower than EV68, A > and Madison pulled somewhat ahead of EV7 in mid-2003 (save for  I > large-system workloads that didn't partition very well and, of course,  K > those exploiting EV7's extraordinary bandwidth capabilities).   That is,  H > after all, what tends to happen when you put 1998 processor design up I > against 2003 processor design, and then give the latter a full process   > generation advantage as well.  > L > Regardless of how thoroughly Alpha *could* have trounced Itanic had Alpha L > development continued, the fact is that Alpha development ceased 5+ years H > ago (though they fiddled around for another 17 months before actually I > shipping EV7) while Itanic development has been vigorously (some might  G > even say desperately) pursued since then.  True, HP chose to pin its  H > large-system hopes on warming over an already-trailing-edge Superdome K > design, and since they have been extremely coy about releasing benchmark  L > results for it one might suspect that they're getting exactly the kind of K > performance that they deserve for having adopted that 'strategy', but if  L > you want good performance in a large Montecito system (and are willing to L > run Linux...) you can get it from Fujitsu (which manages to eke out about K > the same TPC-C score from 32 1.6 GHz Montecito cores that HP got with 64  K > 1.6 GHz Madison cores - though it's still only 61% of the score that IBM  M > can manage with 32 POWER5+ cores), and HP's new 4-socket Montecito systems  K > seem to achieve respectable performance (equal to the best that Xeon and  M > Opteron systems of similar size can offer though, again, considerably less   > than POWER5+ can). > J > The reason that people aren't particularly enthusiastic about migrating I > from Alpha to Itanic is not because Itanic can't (in most cases) offer  J > equal or better performance, and not because it can't do so at equal or F > lower prices (HP can of course make sure of that, and has no reason D > whatsoever to try to keep Alpha pricing competitive), but because J > migrations are a real pain and make the options of either sticking with J > what you've got or biting the bullet and moving to a different platform K > from a less perfidious vendor a lot more attractive than would otherwise   > be the case. >  > - bill  K I agree with all your points but need to add something that happened to me  = which might explain some things going on in the market place.   J Back in 1999, there was an "old guard" at my employer's company that were J fans of VAX technology, but any thought of moving off of VAX caused these I people to run away while other "so-called experts" swooped in to promote  L their own favourite alternatives. (these people were probably looking for a  future meal ticket).  I The only way for my department to move to Alpha was to acquire some used  I Alphas from another department AND have Compaq help us out through their  L software loan program. Once we ported our code to Alpha, all the worries of M the nay-sayers were put to rest and we then quietly purchased a new AS-DS20e  G under the corporate radar. (software license trade-ins were also a key   factor)   H The whole point of all this is to recognize that our group was the only J group willing to give Alpha a chance. I'm assuming that I'll get the same J grief when I attempt to move to Itanium. (Unless the newer Itanium system I was real cheap). At this time, it might be easier for me to get money to  5 move to a larger Alpha platform than move to Itanium.   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.6 http://www3.sympatico.ca/n.rieck/docs/alpha_diary.html   ------------------------------   Date: 6 Dec 2006 10:39:39 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) * Subject: Re: Alpha sales extended 6 months3 Message-ID: <P47B7Obm9+n8@eisner.encompasserve.org>   g In article <4575faf1$0$1629$9a6e19ea@news.newshosting.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes:   J > 1) the new architecture was significantly more powerful than the old oneC > 2) the new architecture was cheaper (and thus worth doing a port)   C    There may be some application somewhere which didn't enjoy this, G    but both of these were true all the way back to beta-system shipment 
    of Alphas.    ------------------------------   Date: 6 Dec 2006 10:41:21 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) * Subject: Re: Alpha sales extended 6 months3 Message-ID: <QCel7CxMgSgJ@eisner.encompasserve.org>   r In article <A66dnQ3A6_fTyevYnZ2dnUVZ_sCdnZ2d@metrocastcablevision.com>, Bill Todd <billtodd@metrocast.net> writes: > J > The reason that people aren't particularly enthusiastic about migrating I > from Alpha to Itanic is not because Itanic can't (in most cases) offer  J > equal or better performance, and not because it can't do so at equal or F > lower prices (HP can of course make sure of that, and has no reason D > whatsoever to try to keep Alpha pricing competitive), but because J > migrations are a real pain and make the options of either sticking with J > what you've got or biting the bullet and moving to a different platform K > from a less perfidious vendor a lot more attractive than would otherwise   > be the case.  G    And because in real life the "Industry Standard" architecure is very "    much more similar to the 80386.   ------------------------------  % Date: Wed, 06 Dec 2006 09:28:17 -0800 * From: "Tom Linden" <tom@kednos-remove.com>* Subject: Re: Alpha sales extended 6 months) Message-ID: <op.tj5etfqctte90l@hyrrokkin>   K On Wed, 06 Dec 2006 01:22:52 -0800, Karsten Nyblad <nospam@nospam.nospam>    wrote:   > Bill Todd wrote: >> Neil Rieck wrote: >>  ...  >>K >>> I have no direct experience with Itanium but have been told by others   K >>> that large SMP-based Alpha systems easily out perform large SMP-based   I >>> Itanium systems.  If this is true, HP management would be insane to   L >>> prematurely kill off Alpha no matter what they have published in their   >>> road maps. >>> H >>> p.s. when OpenVMS on Itanium is faster than Alpha, you will see HP  L >>> publish product comparisons in VUPs or PERFs "at the HP we site" which    >>> will be something like this:6 >>> http://h18002.www1.hp.com/alphaserver/performance/F >>  Probably not:  HP mostly seems to be hoping that Alpha will just  F >> quietly fade away, so there's no reason to call attention to it -  K >> especially after they've stopped selling them.  VMS customers are seen   D >> as either captive or already gone (no noticeable class of *new*  C >> customers), so there's little reason to waste much time on them. L >>  Besides, VMS has been somewhat faster on Itanic for most workloads for  L >> over three years now:  McKinley was not all that much slower than EV68,  C >> and Madison pulled somewhat ahead of EV7 in mid-2003 (save for   K >> large-system workloads that didn't partition very well and, of course,   I >> those exploiting EV7's extraordinary bandwidth capabilities).   That   K >> is, after all, what tends to happen when you put 1998 processor design   F >> up against 2003 processor design, and then give the latter a full  ( >> process generation advantage as well.I >>  Regardless of how thoroughly Alpha *could* have trounced Itanic had   K >> Alpha development continued, the fact is that Alpha development ceased   J >> 5+ years ago (though they fiddled around for another 17 months before  H >> actually shipping EV7) while Itanic development has been vigorously  J >> (some might even say desperately) pursued since then.  True, HP chose  K >> to pin its large-system hopes on warming over an already-trailing-edge   C >> Superdome design, and since they have been extremely coy about   F >> releasing benchmark results for it one might suspect that they're  I >> getting exactly the kind of performance that they deserve for having   I >> adopted that 'strategy', but if you want good performance in a large   K >> Montecito system (and are willing to run Linux...) you can get it from   I >> Fujitsu (which manages to eke out about the same TPC-C score from 32   H >> 1.6 GHz Montecito cores that HP got with 64 1.6 GHz Madison cores -  H >> though it's still only 61% of the score that IBM can manage with 32  L >> POWER5+ cores), and HP's new 4-socket Montecito systems seem to achieve  E >> respectable performance (equal to the best that Xeon and Opteron   L >> systems of similar size can offer though, again, considerably less than   >> POWER5+ can).C >>  The reason that people aren't particularly enthusiastic about   H >> migrating from Alpha to Itanic is not because Itanic can't (in most  J >> cases) offer equal or better performance, and not because it can't do  I >> so at equal or lower prices (HP can of course make sure of that, and   L >> has no reason whatsoever to try to keep Alpha pricing competitive), but  F >> because migrations are a real pain and make the options of either  G >> sticking with what you've got or biting the bullet and moving to a   K >> different platform from a less perfidious vendor a lot more attractive   $ >> than would otherwise be the case.
 >>  - bill >  > Bill,  > L > Have you noticed that HP has announced a much better compiler for Itanic  C > on HP-UX?  That improvement should make HPs Itanic systems more   E > competitive when ISVs and customers recompile their applications.   K > Hopefully HP will port the new compiler to VMS, including porting it to    > BLISS and Macro32.  E Karsten, what you have written doesn't make any sense.  The article   
 presumablyI is referring to a better optimizer.  The compilers on Alpha and Itanium   	 interface I to the GEM backend, retargeting them to another backend would be foolish, K particularly since the improvement in the code, if any,  could at best be   	 marginal.    The article is mostly BS.  > L > http://news.com.com/HP+promises+Unix+improvements/2100-1016_3-6140107.html       --  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Wed, 06 Dec 2006 14:36:58 +0800  From: prep@prep.synonet.com  Subject: Re: Alternative to FTP 0 Message-ID: <87odqhv8c5.fsf@k9.prep.synonet.com>  9 Jan-Erik Sderholm <jan-erik.soderholm@telia.com> writes:   
 > Mike skrev: 
 >> Hi all,H >> I have a flat text file that gets ftp'd out of our Alpha to a WindowsH >> machine, gets processed and modified, and then gets ftp'd back to the	 >> Alpha. G >> The information in the flat text file is sensitive and confidential. E >> What is the best way to transfer the file that will work with both  >> Windows and VMS (7-3_2)? D >> We are using the DOS prompt to FTP because all the fancy .NET ftp >> stuff >> doesn't seem to like VMS.E >> Would Advanced Server help in this case or should we use something  >> like  >> SSH? 
 >> Thanks! >> Mike  >> > C > A SAMBA share where your Windows app can process the file without  > moving it around at all ?  > . > Move the "processing and modifying" to VMS ?  > (I guess not possible... :-) )  B Hey, its on a billbox, so confidential etc just went right out the door anyway.  E Part of you answer would be a locked down FPTD for windows so you can D controll the xfers from the vms end. If it is not too big, encryptedB e-mailing it to a robot mailbox works well, but I've lost track of' that stuff in either the m$ or vms end.    --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------   Date: 6 Dec 2006 10:16:23 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)  Subject: Re: Alternative to FTP 3 Message-ID: <DFa+Mk3Icq8p@eisner.encompasserve.org>   e In article <1165337010.585911.35230@j72g2000cwa.googlegroups.com>, "Mike" <mlpoole@gmail.com> writes: 	 > Hi all,  > D > What is the best way to transfer the file that will work with both > Windows and VMS (7-3_2)? > B    I'd use sftp or scp (SSH based utilities).  But check with yourF    security gurus first to find out what level of security is required%    to match the level of sensitivity.    ------------------------------   Date: 6 Dec 2006 10:18:28 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)  Subject: Re: Alternative to FTP 3 Message-ID: <85H6wVQTYFwj@eisner.encompasserve.org>   a In article <D5idh.25467$E02.10568@newsb.telia.net>, =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes:  > C > A SAMBA share where your Windows app can process the file without  > moving it around at all ?   A    I think that harly meet's the OP's need for security while the 5    data flows over the wire between the two machines.   . > Move the "processing and modifying" to VMS ?  > (I guess not possible... :-) )  A    Now that's a good solution.  The processing and modifying on a C    Windows system of sensitive data will always be a security issue 	    to me.         ------------------------------   Date: 6 Dec 2006 15:31:46 GMT ( From: bill@cs.uofs.edu (Bill Gunshannon) Subject: DEC Educational Stuff0 Message-ID: <4to632F14inevU1@mid.individual.net>  . I have the following available to a good home:  = OSF/MOTIF for the Non-Technical Professional (with Videotape) 9 Using teh VAX Language-Sensititve Editor (with TK50 tape) - Introduction to EVE (with small 9 Track tape) . VMS Utilities and Commandes I (with TK50 tape)6 Introduction to VMS Systems Operation (with TK50 Tape)  D All of these come in the original DEC box and some of them even have% stuff inside still in the shrinkwrap.   1 Anybody interested in saving thses from the skip?    billE (Keep watch, more to come, including some older CONDIST sets.  Spring ' cleaning is starting early this year!!)    --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 6 Dec 2006 10:44:44 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) * Subject: Re: DECNET during SYSHUTDWN.COM ?3 Message-ID: <qgZfVvBLuVvL@eisner.encompasserve.org>   w In article <el4o4c$sb4$2@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:  > I > I'm still coming to terms with the fact that one can log in via TELNET  G > and do a shutdown with reboot and the machine comes back up (even if  A > it is not set to reboot automatically at the console prompt).   K > Presumably this will work with DECnet as well.  Of course, TCPIP is also  K > shut down during the shutdown procedure.  Is there an exception made for  8 > the current process?  (SHUTDOWN.COM is quite cryptic.)  G    It worked with DECnet before it worked with TCP/IP.  There are hooks H    in VMS (SHUTDOWN.COM and elsewhere) that keep the current process and2    it's network stack around until the bitter end.   ------------------------------   Date: 6 Dec 2006 16:16:05 GMT ( From: bill@cs.uofs.edu (Bill Gunshannon) Subject: DWZZB-AA 0 Message-ID: <4to8m5F14qshgU1@mid.individual.net>  L Anybody interested in buying a couple of these?  Make me a reasonable offer.K If I get multiple offers, it goes to the highest.  And, no, I have no plans M to put them up on Ebay!!  I would rather take less and see them go to someone * here.  Or even to Island rather than Ebay.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Wed, 06 Dec 2006 03:33:56 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> $ Subject: Homemaid keycap mnemonics ?8 Message-ID: <16940$4576807e$cef8887a$13750@TEKSAVVY.COM>  A I miss my ALL-IN-1 LK201 keyboard, especially the numeric keypad.   K Does anyone know of some kits you can perhaps pass through a laser printer  < to generate high quality keycaps with the right text on it ?  L How are the letters/numbers deposited onto those el-cheapo Compaq keyboards L (LK46x series). ? It is just paint deposited on top ? or is there some form 3 of engraving to ensure the paint doesn't wash off ?   I Anyone know of an LK201->PS2 adaptor ? (so I could use a true blue LK201   keyboard on a DS10).   ------------------------------   Date: 6 Dec 2006 09:19:18 -0800   From: "Dona" <erminido@yahoo.it> Subject: MozillaB Message-ID: <1165425558.519806.13920@j44g2000cwa.googlegroups.com>   Hi,   F I'm sorry but I'm novice to OpenVMS.....I'm just starting to work with/ it and I obviously encountered some problems :( ) In particular, I tried to install Mozilla E "cswb-openvms-alpha-v1713.sfx_axpexe" and I followed the instructions ? issued in "Installation Guide and Release Notes" but, I already  encountered my first problem:   7 file #1:  bad zipfile offset (local header sig):  81921    (attempting to re-compensate) 7 file #1:  bad zipfile offset (local header sig):  81921 : file #2:  bad zipfile offset (local header sig):  36235368   (attempting to re-compensate) ;   inflating: cpq-axpvms-cswb-v0107-13-1.pcsi$compressed_esw 6   inflating: cpq-axpvms-gtk-v0102-10-1.pcsi$compressed:   inflating: cpq-axpvms-gtk-v0102-10-1.pcsi$compressed_esw7   inflating: cpq-axpvms-opl-v0100-0a9-1.pcsi$compressed ;   inflating: cpq-axpvms-opl-v0100-0a9-1.pcsi$compressed_esw   F Is there anyone who could be help me to understand what's happened and how to fix the problems?   Thank's in advance   ------------------------------   Date: 06 Dec 2006 16:13:33 GMT! From: Doc <doc@openvms-rocks.com>   Subject: Re: Newbie needs advice= Message-ID: <Xns9891AF3C79CCAdocopenvmsrockscom@195.238.0.34>   2 Paul Sture <paul.sture.nospam@hispeed.ch> wrote inC news:paul.sture.nospam-90A7A9.22312102122006@mac.sture.homeip.net:    ( >> > $MON SYSTEM or $MON PROCESS /TOPCPUG >> Turns out this isn't really necesary...I think I've found a very big B >> issue with a show queue command...The SMTP server queues aren'tE >> processing correctly.  As a result, that queue got very full, very  >> fast.    F > Beware that with Multinet you need to set up SMTP carefully - followE > the (detailed) instructions in the manuals, or spammers will try to E > use your system as an open relay, and your SMTP queues will quickly  > fill up.    @ Paul is probably bang on the money here, if you don't follow theC instructions for setting up SMTP for Multinet you'll end up an open / relay.  Your system disk will be full of spam.    D Disable SMTP, delete everything in MULTINET_SPOOL and go through the; SMTP configuration very carefully before you re-enable it.       Doc.   ------------------------------   Date: 6 Dec 2006 07:51:32 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)  Subject: Re: Novice's questions 3 Message-ID: <7pRWhYNFjCsN@eisner.encompasserve.org>   d In article <rMedh.25458$E02.10427@newsb.telia.net>, =?UTF-8?B?SmFuLUVyaWsgU8O2ZGVyaG9sbQ==?= writes: > B > A Serial cable with mathing connectors (depends on your system).7 > Use any VT-emulator. Even HyperTerm "works" for this.  >       Oh, ouch, ugh!   E    Please, please, download a copy of vtstar, personal use HyperTerm, :    ... instead of using the supplied version of Hyperterm.  9    "works" in the above sentence is much too lose a term.    ------------------------------   Date: 6 Dec 2006 07:59:38 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)  Subject: Re: Novice's questions 3 Message-ID: <SJujFXx0qpC0@eisner.encompasserve.org>   d In article <1165331145.325538.152140@79g2000cws.googlegroups.com>, "MZN" <MikeZmn@gmail.com> writes: >  > """Bob Koehler (): > """  >>E >>    Since the "patent" line is a valid comment, I suspect something F >>    has happened to the RMS attributes of files to make it look like6 >>    there's a line break in the middle of that line.H > How can I correct it on PC? I'm also suspect problem in license files,B > but saving them from e-mail message gives me 3 variants (in sizeH > terms). I checked 2 of them - no luck. The variant with bigger size is	 > remain.   B    You probably can't fix this from the PC side since Windows only!    understands byte stream files.    >>C >>    Try /undefined_fat options to see if you can get around this. ! > When (where) I should get this?       $ help mount /undefined_fat   >>C >>    We might be able to help you with the options of you can tell D >>    us what system you burned the CD on and what steps you took to >>    get the files there.G > On CD burned OpenVMS 8.3. I simply burned image, what I have in Nero. E > License files were burned by Nero with ISO9660 standard without any 
 > extensions.   G    How did you get the files into the image?  If you used Nero then you H    probably need to use the /undefined_fat options to set the RMS recordI    format to stream-cr.  I think this would be /undefined_fat=stream_cr .    ------------------------------   Date: 6 Dec 2006 07:56:11 -0800  From: "MZN" <MikeZmn@gmail.com>  Subject: Re: Novice's questions A Message-ID: <1165420571.059503.23490@f1g2000cwa.googlegroups.com>   6 """Bob Koehler =D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): """ L > In article <1165331145.325538.152140@79g2000cws.googlegroups.com>, "MZN" = <MikeZmn@gmail.com> writes:  > > : > > """Bob Koehler =C3=90=C3=89=C3=93=C3=81=C3=8C(=C3=81): > > """  > >>G > >>    Since the "patent" line is a valid comment, I suspect something H > >>    has happened to the RMS attributes of files to make it look like8 > >>    there's a line break in the middle of that line.J > > How can I correct it on PC? I'm also suspect problem in license files,D > > but saving them from e-mail message gives me 3 variants (in sizeJ > > terms). I checked 2 of them - no luck. The variant with bigger size is > > remain.  > D >    You probably can't fix this from the PC side since Windows only# >    understands byte stream files.    Yes, I tried, no luck. >  > >>E > >>    Try /undefined_fat options to see if you can get around this. # > > When (where) I should get this?  >   >    $ help mount /undefined_fat >  > >>E > >>    We might be able to help you with the options of you can tell F > >>    us what system you burned the CD on and what steps you took to > >>    get the files there.I > > On CD burned OpenVMS 8.3. I simply burned image, what I have in Nero. G > > License files were burned by Nero with ISO9660 standard without any  > > extensions.  > I >    How did you get the files into the image?  If you used Nero then you J >    probably need to use the /undefined_fat options to set the RMS recordL >    format to stream-cr.  I think this would be /undefined_fat=3Dstream_cr=  =2E  D I received files by e-mail, save them (by 3 ways), Then I create newE project in Nero (ISO9660 w/o any extensions), set "no multisession" , E "disk at once" and burned. That's all. CD reads under OpenVMS, but...   E If I resend these e-mails to somebody, who works under OpenVMS, is it $ possible to correctly extract files?  B And, I bought serial cable. So, wait for another stupid questions.G In order to set graphics display I should get >>>SET CONSOLE GRAPHICS ? A What happend with graphics display when I enter to serial console  (after >>>SET CONSOLE SERIAL)?   ------------------------------   Date: 6 Dec 2006 10:34:46 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)  Subject: Re: Novice's questions 3 Message-ID: <oV07E$GmLk8n@eisner.encompasserve.org>   c In article <1165420571.059503.23490@f1g2000cwa.googlegroups.com>, "MZN" <MikeZmn@gmail.com> writes:   F > I received files by e-mail, save them (by 3 ways), Then I create newG > project in Nero (ISO9660 w/o any extensions), set "no multisession" , G > "disk at once" and burned. That's all. CD reads under OpenVMS, but...  > G > If I resend these e-mails to somebody, who works under OpenVMS, is it & > possible to correctly extract files?  F    Yes.  But if you then transfer them to Windows and use Nero to makeD    the CD you'll be right back where you are because Windows doesn't    know any better.   F    It's also possible to copy the files on your VMS system from the CDI    to a hard drive and the use "set file/attribute" to fix them.  You'll  G    end up with the same effect as using the /undefined_fat option when      you mount the CD.  D    Another solution might be to only enter by hand the licenses you H    need to get TCP/IP working, and then do a TEXT (ASCII) mode transfer D    using FTP between the Windows and VMS box.  The FTP server on VMS;    properly follows the FTP standard for dealing with this.    ------------------------------   Date: 6 Dec 2006 08:54:09 -0800  From: "MZN" <MikeZmn@gmail.com>  Subject: Re: Novice's questions B Message-ID: <1165424049.138885.282920@f1g2000cwa.googlegroups.com>   """Bob Koehler (): """ e > In article <1165420571.059503.23490@f1g2000cwa.googlegroups.com>, "MZN" <MikeZmn@gmail.com> writes:  > H > > I received files by e-mail, save them (by 3 ways), Then I create newI > > project in Nero (ISO9660 w/o any extensions), set "no multisession" , I > > "disk at once" and burned. That's all. CD reads under OpenVMS, but...  > > I > > If I resend these e-mails to somebody, who works under OpenVMS, is it ( > > possible to correctly extract files? > H >    Yes.  But if you then transfer them to Windows and use Nero to makeF >    the CD you'll be right back where you are because Windows doesn't >    know any better.   4 I know that Gear for Windows keeps RMS attributes... > H >    It's also possible to copy the files on your VMS system from the CDJ >    to a hard drive and the use "set file/attribute" to fix them.  You'llH >    end up with the same effect as using the /undefined_fat option when >    you mount the CD.   OK, I'll do that > E >    Another solution might be to only enter by hand the licenses you I >    need to get TCP/IP working, and then do a TEXT (ASCII) mode transfer F >    using FTP between the Windows and VMS box.  The FTP server on VMS= >    properly follows the FTP standard for dealing with this. C Looks easier for them who knows how to do that. I leave it for last  case.    ------------------------------  # Date: Wed, 06 Dec 2006 18:36:13 GMT + From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?=  Subject: Re: Novice's questions 3 Message-ID: <x4Edh.25584$E02.10627@newsb.telia.net>    Now, about the split lines...   = The lines (which seems to only be the (longer) comment-lines) = was probably split in the mail transfer. And as such they are 9 now two independable lines in the file. *NO* file attribs 8 on VMS can do anything about that. You can probably just forget all post about that...   @ And, since it's only (?) the comment lines (that are in a single@ block at the start of the line) it's simple enought just to edit? them away before running the command file. The LICENSE commands  it selfs are just fine, not ?   	 Jan-Erik.    ------------------------------  # Date: Wed, 06 Dec 2006 14:05:12 GMT ' From: jls <jeffls-nospam@sbcglobal.net> " Subject: Re: recursive copy in VMS8 Message-ID: <sejdn2hj61rum7fa8k7oel7snksbbclqri@4ax.com>  E On 5 Dec 2006 08:18:55 -0600, koehler@eisner.nospam.encompasserve.org  (Bob Koehler) wrote:     > G >   I think that's exactly what he wants.  He's satisfied that he won't H >   lose his Mac's disk and his VMS system's disk at the same time, justH >   like I'm satisfied that I won't lose my VMS systems' disks and their" >   tape backups at the same time.   So then, what happens if:   ' 1.  he copies file X to the VMS system. " 2.  Along the way it gets deleted.3 3.  The VMS disk fails and is restored from backup. ! 4.  He finds that he needs file X    ------------------------------   Date: 6 Dec 2006 10:48:54 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) " Subject: Re: recursive copy in VMS3 Message-ID: <m0NC5hdmwbaZ@eisner.encompasserve.org>   b In article <sejdn2hj61rum7fa8k7oel7snksbbclqri@4ax.com>, jls <jeffls-nospam@sbcglobal.net> writes: >  > So then, what happens if:  > ) > 1.  he copies file X to the VMS system. $ > 2.  Along the way it gets deleted.5 > 3.  The VMS disk fails and is restored from backup. # > 4.  He finds that he needs file X   D    Just like when I do BACKUPs, I never do step 2.  Normally routineC    backups are to ensure there is a second copy of the file, not to     delete them.   B    And I've done what the OP is doing for years from a Mac withoutE    ever having a mysterious deletion of the original file on the Mac.   H    But if you have a file so precious that you need three, four, or evenE    more copies before you can be sure you can restore it, then by all -    means consider not doing what the OP does.    ------------------------------   Date: 6 Dec 2006 10:28:44 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) T Subject: Re: Seemingly different results with backup of file in and out of procedure3 Message-ID: <zSikuL85QuRU@eisner.encompasserve.org>   p In article <OF08BCF63F.CD2E3DEE-ON8525723B.00647925-8525723B.0064F9C6@metso.com>, norm.raphael@metso.com writes:  C > LOGINMESS.TXT;13           1  12-AUG-1998 12:37:27.98  [CINCOM,CO  > (RWED,RWED,,R)C > LOGINMESS.TXT;12           1  12-AUG-1998 12:37:27.98  [CINCOM,CO  > (RWED,RWED,,R)  : > $ delete_/nolog/before="today-8-" jam340:[copy.out]*.*;*  C    I don't know what calendar you're using, but on mine 12-AUG-1998 B    is before "today-8-" (that would be 28-NOV-2006), so this will D    delete both existing copies before BACKUP makes a single new one.  A    Since you used copy to make the files originally you could add H    /modified to the delete command.  Unlike BACKUP, COPY will change theE    modified date.  But then you should probably be consistent and use      COPY to make the new version.   ------------------------------   Date: 6 Dec 2006 08:40:29 -0800 < From: "Hein RMS van den Heuvel" <heinvandenheuvel@gmail.com>0 Subject: Re: Suggestion for TYPE (output pacing)C Message-ID: <1165423228.609947.118660@j72g2000cwa.googlegroups.com>   . Along the same lines as Fred (but shorter :-):   perl -pe "sleep 1"  file.txt  F Unfortunately the VMS port I use does not seem to have time::hires for: usleep or nanosleep, and sleep only takes integer seconds.  @ If you don't mind burning CPU, then you can throttle your output	 thusly...   ( $ perl  -pe "for (1..100000){}" file.txt   Grins, Hein.      Fred Bach wrote:; > To look at that animation on a fast Decterm I wrote this:  >  > $! SLOW_READ.COM > $! FORMAT:: > $!  SLOW_READ <filename> [delay time in decimal seconds]I > $!   where <filename> is the file you want to type slowly to the screen Q > $!   and the second arg is the delay time between lines, such as "0.1" or "0.2" 6 > $!   The second arg defaults to a tenth of a second.? > $! written by Fred Bach, TRIUMF Operations Friday 17-NOV-2006  > $! > $close/nolog infile  > $close/nolog infile  > $on warning then continue  > $on error then goto exit > $on severe_error then stop > $on control_y then goto exit > $  > $open/read infile 'p1' > $loop: > $ read/end=exit infile line  > $ write sys$output line " > $ if p2 .eqs. "" then p2 = "0.1" > $ wait 00:00:'p2' 
 > $ goto loop  > $EXIT: > $ close/nolog infile > $ exit >  > AEF wrote: > > JF Mezei wrote:  > >> Bob Koehler wrote: K > >>>    And of course, any real VT and most emulators have a smooth-scroll D > >>>    option which is just about exactly what you're looking for.N > >> A couple years ago, I put up a chistmas VT animation for people to telnetP > >> to. But unfortunatly many complained that it went too fast and you couldn't > >> see a thing.  > > ! > > Well why didn't you say so!!!  > > I > > You need to run the animation over a 9600 baud or similar connection, 6 > > preferably to a real VT terminal for best results. > > N > >> On my alpha, a more complex (adult) animation I got from an IBM mainframeN > >> is no longer viewable because it almost immediatly goes to the last frame& > >> (they were 3270 screen captures). > > 	 > > Same.  > > L > >> TYP/PAGE doesn't work in that case because there are no "pages". SmoothL > >> scroling doesn't work because no scrolling is necessary in those cases. > >>M > >> And type/page cannot be automated, it requires a human be there to press  > >> some key to continue. > > ; > > You need TYPE/THROTTLE. You need to write your own app.  > > > > > These animations were designed for VT terminals over "slowJ > > connections".  I'm afraid they're incompatible with telnet (unless youH > > run over a really slow WAN, and even then it might run erratically). > >  > > AEF  > >    ------------------------------  # Date: Wed, 06 Dec 2006 14:01:59 GMT # From: "FredK" <fred@nospam.dec.com> & Subject: Re: VMS  Alpha  Console (VGA)1 Message-ID: <r3Adh.3276$un4.794@news.cpqcorp.net>   ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  / news:3b6b$45764126$cef8887a$529@TEKSAVVY.COM...  > FredK wrote:I >> I don't know why you keep asserting that 680x480 is some magic number.  >  > E > OK Sorry, I was under the impression that VGA mode implied 640-480.  >   . This is just one of the early VGA resolutions.  H > 640-480 is what is used when the machine powers up. And it SEEMS (not E > sure) that during the booting process, when it switches to the VMS  0 > console, it remains at 640-480 (is that so ?). >    No.   J The BIOS on the graphics card initializes the resolution to "something" - L where that something is whatever the maker decides.  Typically it is one of J the "standard" VESA text modes.  The 9x16 character cell mode is probably K the most common which means 720x400 pixel resolution.  The graphics driver  D "saves" and then restores the current VGA state to try and make the : transition smooth and use the vendors preferred text mode.  M > The reason I mentioned this was that there have been times when, after the  M > decw server crashing (happens every few days for me), the NEC monitor gets  M > confused and seems to have some problems adjusting to what the VMS console   > is trying to do.  K A glitch in the save/restore on the Radeon is the likely culprit here as I   mentioned before.    ------------------------------   End of INFO-VAX 2006.671 ************************