1 INFO-VAX	Mon, 06 May 2002	Volume 2002 : Issue 249       Contents:3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix - Re: EDT or EVE (and a fine DCL hack, also...) E Re: How to rotate Apache/CSWS log files under VMS, without a restart? E Re: How to rotate Apache/CSWS log files under VMS, without a restart? E Re: How to rotate Apache/CSWS log files under VMS, without a restart?  Listing updated files. Re: Listing updated files. Re: Revisionist history  Re: Revisionist history  Re: Revisionist history  Re: Revisionist history  Re: Revisionist history  Re: Revisionist history  Re: Revisionist history  Re: Revisionist history ' Re: SKC Morphs Again... We're Now SKHPC ' Re: SKC Morphs Again... We're Now SKHPC  Re: USB on OpenVMS Re: USB on OpenVMS Re: USB on OpenVMS Re: Vax emulator for PC ( Re: VMS Bigots Unite To Form New Company VT-s ( was Re: New to VAX )  X-Win32  Re: X-Win32 / Re: ZIPped .PCSI container arrives OK on VMS??? / Re: ZIPped .PCSI container arrives OK on VMS??? / Re: ZIPped .PCSI container arrives OK on VMS??? / Re: ZIPped .PCSI container arrives OK on VMS???   F ----------------------------------------------------------------------   Date: 5 May 2002 21:23:24 GMT & From: peter@abbnm.com (Peter da Silva)< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix- Message-ID: <ab47sc$9du@web.eng.baileynm.com>   ' In article <3CD47FEF.76D3F72F@gce.com>, ) Glenn Everhart  <Everhart@gce.com> wrote: C > Linux is unix-like, certainly, but there are differences here and * > there owing to its independent ancestry.  M There are differences between different UNIX systems, whether they're derived E from the source tree owned by... whoever owns it this week... or not.    > For example, in unix oneF > has raw and cooked devices, under different names, so that one mightD > access a disk partition as /dev/hda3 to do normal file operations,H > or as /dev/rhda3 to access it as a nonfile structured device. In LinuxA > the same name does for both and the distinction comes with use,  > not with name.    H And in recent versions of FreeBSD this distinction has been removed. How about that?   G > Linux is not descended from ATT code, is as entitled to say it is not " > unix as Gnu (Gnu's Not Unix) is.  L The only way Linux isn't UNIX is a way that simply doesn't matter. There areJ so many source trees, some of which can be traced back to AT&T and some ofJ which can't. NT has code in it that can be traced back to an AT&T licensed; UNIX, so does that mean it gets to call itself UNIX or not?   K > The defining of a standard API with remarks like "anything that satisfies 2 > this API is Unix" has been interesting to watch.  J Some of us have been defining UNIX that way for twenty years or more. It'sG not a new thing... it's been going on since the reverse-engineered UNIX * ports like Regulus back in the early '80s.   > However, it has comeJ > very close (and may reach the point) to allowing one to say VMS is Unix,= > which those familiar with the systems would find a tad odd.   I It's not the native API, but I would be quite willing to describe OpenVMS I or Interix as hosted implementations of UNIX. For that matter, AIX has at ? times been more like a hosted implementation than a native one.   H UNIX is anything that looks like UNIX, except in a sense that is utterly% irrelevant to anyone but a historian.    --  O I've seen things you people can't imagine. Chimneysweeps on fire over the roofs O of London. I've watched kite-strings glitter in the sun at Hyde Park Gate.  All L these things will be lost in time, like chalk-paintings in the rain.   `-_-'K Time for your nap.  | Peter da Silva | Har du kramat din varg, idag?    'U`    ------------------------------  # Date: Mon, 06 May 2002 00:57:09 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> 6 Subject: Re: EDT or EVE (and a fine DCL hack, also...)' Message-ID: <3CD5D7E0.C6026DDF@fsi.net>    Jan-Erik Sderholm wrote:  >  > Hi. 2 > Regarding the "batch" capability of EDT vs. TPU,0 > I just happend to think of the VMS_SHARE tool. > 2 > Any file(s) are coded and included in a COM file1 > that, when executed, runs an embeded TPU script 5 > which recreates the files on a target system. Nice,  > no 3'rd part tools needed.  A Granted, it *CAN* be done. The issue is the effort involved to do 3 something as simple as a global search and replace.   * EDT? Fairly simple. One line-mode command:  7 S/string_to_find/strimg_to_replace_it_with/WHOLE/NOTYPE   F TPU? Hours, possibly days of studying syntax and functions, and hours,, possibly days more of testing and debugging.  = Even using EDLIN with stdin redirected is rather more simple.   9 > The VMS_SHARE.COM itself is a 275 block/4000+ lines DCL ; > script written by Andy Harper at Kings College in London.  > A > VMS_SHARE can be find (of course :-) ) on Hunter's archive at : + > http://www.process.com/openvms/index.html   F This was useful sometime back. An excellent piece of work, really. Not? sure how many folks need it or would find it useful these days.    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Mon, 06 May 2002 00:40:54 GMT ) From: rob.buxton@wcc.govt.nz (Rob Buxton) N Subject: Re: How to rotate Apache/CSWS log files under VMS, without a restart?1 Message-ID: <3cd5cfca.591996305@news.wcc.govt.nz>   F On 5 May 02 09:32:28 +0200, p_sture@elias.decus.ch (Paul Sture) wrote:  M >Subject says it all, really. From the documentation on www.apache.org, I can @ >find out how to do this on a *n*x system, but how to do on VMS? > O >Sure I can drop and restart Apache, but in my netblock I am 3rd after a couple P >of Linux boxes in uptime ratings. It's quite nice to see OpenVMS sitting there,% >and I'd like to keep it that way :-)  >  >__  >Paul Sture  >Switzerland  & I think this came in with 1.2 of CSWS.  @sys$manager:apache$config flush and  @sys$manager:apache$config new  B I schedule these for a weekly job to flush the Access Logs & Error Logs and then create new ones.   Rob.   ------------------------------  # Date: Mon, 06 May 2002 00:41:42 GMT ) From: rob.buxton@wcc.govt.nz (Rob Buxton) N Subject: Re: How to rotate Apache/CSWS log files under VMS, without a restart?1 Message-ID: <3cd5d122.592340540@news.wcc.govt.nz>   @ On 5 May 2002 08:31:39 -0700, bob@instantwhip.com (Bob Ceculski) wrote:  [ >p_sture@elias.decus.ch (Paul Sture) wrote in message news:<d5S5NQ5j+iHQ@elias.decus.ch>... O >> Subject says it all, really. From the documentation on www.apache.org, I can B >> find out how to do this on a *n*x system, but how to do on VMS? >>  Q >> Sure I can drop and restart Apache, but in my netblock I am 3rd after a couple R >> of Linux boxes in uptime ratings. It's quite nice to see OpenVMS sitting there,' >> and I'd like to keep it that way :-)  >>   >> __ 
 >> Paul Sture  >> Switzerland > @ >on Purveyor you set your logs to be created on a daily, weekly,= >or monthly basis and don't even worry about that ... I don't  >know about Apache ...  3 So why reply to a message asking about CSWS/Apache?    ------------------------------   Date: 6 May 02 07:27:17 +0200 ) From: p_sture@elias.decus.ch (Paul Sture) N Subject: Re: How to rotate Apache/CSWS log files under VMS, without a restart?) Message-ID: <sN8BxJ3gjf1h@elias.decus.ch>   ` In article <3CD541B3.2B076D57@digital.com>, Mike Rechtman <michael.rechtman@digital.com> writes:   Many thanks for this.   7 > From a .COM-file that runs WUSAGE on the apache logs: 	 > <start>  > $!G > $ @sys$startup:apache$config.com NEW    <<-- Requires CSWS 1.1 or 1.2  > $ !  > $ wait 00:00:15 
 > $ loop1:< > $ if f$search("APACHE$ROOT:[LOGS]ACCESS_LOG.;-1") .nes. "" > $ then6 > $       rename/lo APACHE$ROOT:[LOGS]ACCESS_LOG.;-1 -4 >                 APACHE$ROOT:[LOGS]ACCESS_LOG.old;0 > $       goto loop1	 > $ endif * > $ purge/lo APACHE$ROOT:[LOGS]ACCESS_LOG., > $ rename/lo APACHE$ROOT:[LOGS]ACCESS_LOG.;! > APACHE$ROOT:[LOGS]ACCESS_LOG.;0  > $!
 > $ loop2:; > $ if f$search("APACHE$ROOT:[LOGS]ERROR_LOG.;-1") .nes. ""  > $ then5 > $       rename/lo APACHE$ROOT:[LOGS]ERROR_LOG.;-1 - 3 >                 APACHE$ROOT:[LOGS]ERROR_LOG.old;0  > $       goto loop2	 > $ endif ) > $ purge/lo APACHE$ROOT:[LOGS]ERROR_LOG. J > $ rename/lo APACHE$ROOT:[LOGS]ERROR_LOG.; APACHE$ROOT:[LOGS]ERROR_LOG.;0 > $!
 > $ loop3:A > $ if f$search("APACHE$ROOT:[LOGS]SSL_REQUEST_LOG.;-1") .nes. ""  > $ then; > $       rename/lo APACHE$ROOT:[LOGS]SSL_REQUEST_LOG.;-1 - 9 >                 APACHE$ROOT:[LOGS]SSL_REQUEST_LOG.old;0  > $       goto loop3	 > $ endif / > $ purge/lo APACHE$ROOT:[LOGS]SSL_REQUEST_LOG. 1 > $ rename/lo APACHE$ROOT:[LOGS]SSL_REQUEST_LOG.; & > APACHE$ROOT:[LOGS]SSL_REQUEST_LOG.;0 > $! > <end>  > Paul Sture wrote:  >>  O >> Subject says it all, really. From the documentation on www.apache.org, I can B >> find out how to do this on a *n*x system, but how to do on VMS? >>  Q >> Sure I can drop and restart Apache, but in my netblock I am 3rd after a couple R >> of Linux boxes in uptime ratings. It's quite nice to see OpenVMS sitting there,' >> and I'd like to keep it that way :-)  >>   >> __ 
 >> Paul Sture  >> Switzerland >  > --  G > --------------------------------------------------------------------- G > Usual disclaimer: All opinions are mine alone, perhaps not even that. A > Mike Rechtman                            *rechtman@tzora.co.il* H > Kibbutz Tzor'a.                          Voice (home): 972-2-9908337  D >   "20% of a job takes 80% of the time, the rest takes another 80%"G > --------------------------------------------------------------------- ! > -----BEGIN GEEK CODE BLOCK-----  > Version: 3.1< > GCM/CS d(-)pu s:+>:- a++ C++ U-- L-- W++ N++ K? w--- V+++$8 > PS+ PE-- t 5? X- tv-- b+ DI+ D-- G e++ h--- r+++ y+++@! > ------END GEEK CODE BLOCK------  --   __
 Paul Sture Switzerland    ------------------------------   Date: 5 May 2002 15:49:54 -0700 , From: JohnEllicottington@lycos.co.uk (Johno) Subject: Listing updated files. = Message-ID: <10822590.0205051449.3d4ae1bc@posting.google.com>    HiE Each week my command procedure backs up a specific directory. I would B like to include during the running of the procedure details of anyE file that has been updated since the last time the procedure was run. + Whats the easiest way of implementing this?  Johno    ------------------------------  # Date: Mon, 06 May 2002 02:11:01 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> # Subject: Re: Listing updated files. ' Message-ID: <3CD5E931.A4618C85@fsi.net>    Johno wrote: >  > HiG > Each week my command procedure backs up a specific directory. I would D > like to include during the running of the procedure details of anyG > file that has been updated since the last time the procedure was run. - > Whats the easiest way of implementing this?  > Johno   D I would have the proc. write a small scratch file at the end of eachG run, containing perhaps the date of the last run, and create a new file H on each run, purging the old one(s) and RENAME-ing the remaining versionD to ;1. Then, at the beginning of each run, look for the old file andB either use its contents or its creation date (today if the file isB missing, as it will be on the initial run) as the date to use withB /SINCE on a DIRECTORY command or any other (inlcuding BACKUP) that accepts /SINCE with a date.    YMMV...    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Sun, 05 May 2002 20:35:59 GMT 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>   Subject: Re: Revisionist history8 Message-ID: <PIgB8.3$0s3.128119@cacnews.cac.cpqcorp.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in message 8 news:haGA8.1527$M7.211119@bin7.nnrp.aus1.giganews.com... > B > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message5 > news:A2EA8.35$FY2.677920@cacnews.cac.cpqcorp.net...  >  > ...  >   J I started to respond to your response, but decided that it isn't worth theH time.  Fortunately, you have pretty much nothing to do with any chip, orH their future - other than being a critic (who somehow has found a way toK apply "revisionism" to future predictions).  We'll all just have to see how & it plays out over then next few years.   ------------------------------  # Date: Sun, 05 May 2002 20:44:47 GMT 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>   Subject: Re: Revisionist history8 Message-ID: <3RgB8.4$rJ4.134268@cacnews.cac.cpqcorp.net>  5 "Russell Wallace" <spam@devnull.com> wrote in message * news:3cd535a9.266834656@news.eircom.net...6 > On Sat, 04 May 2002 15:46:10 GMT, "Terry C. Shannon"! > <terryshannon@attbi.com> wrote:  > I > >Almost certainly the case. So, why did they do what they did when they  did F > >it, rather than announce IPF as a "complementary" architecture? Not everyoneL > >at CPQ is stupid, particularly the technology types who made the decision to > >"abandon chip." > G > But the final decision to abandon chip was made by senior management,  > not the technology types.  >   E What does this mean?  Do you know any company that delegates critical J business decisions to "technology types"?  Several important technologistsL were part of the decision process.  The fact that not everyone is happy withA the decision, doesn't mean that it was an arbitrary PHB decision.   : > >Seems to me CPQ thought it could get more leverage withJ > >Intel by effectively taking Alpha off the microprocessor playing field. > E > *nod* That may very well have been one of the reasons on paper. The E > impression I get, though (admittedly without anything even remotely C > resembling inside information) is that their real reason was they E > didn't want to be in the business of developing technology, only of ? > packaging and supporting it. They (Compaq management, not the G > engineers) then started looking for excuses to support this, and soon 
 > found some.  >   I The decision was made to not stay in the CPU development business.  Since H Intel is in the CHIP business, and not in the system business - it would; seem to me to make much better sense than the alternatives.    ------------------------------  # Date: Sun, 05 May 2002 20:46:19 GMT 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>   Subject: Re: Revisionist history8 Message-ID: <vSgB8.5$qJ4.133243@cacnews.cac.cpqcorp.net>  9 "Paul Repacholi" <prep@prep.synonet.com> wrote in message ' news:87d6wblfyv.fsf@prep.synonet.com... 9 > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:  > G > > But it is acedemic.  The decision, like it or not, was to not build H > > EV8, and to concentrate on building platforms and not chips.  And toD > > be able to have a single server platform strategy for all O/S's. > 9 > So ComHP is dumping x86 for servers? No more Proliants?  >   I Compaq's (RIP) strategy was x86 for the desktop, and small servers.  IA64  for enterprise servers.    ------------------------------  # Date: Sun, 05 May 2002 20:48:08 GMT 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>   Subject: Re: Revisionist history8 Message-ID: <cUgB8.6$QO4.189554@cacnews.cac.cpqcorp.net>  5 "Russell Wallace" <spam@devnull.com> wrote in message * news:3cd5343a.266466870@news.eircom.net...G > On 05 May 2002 06:12:56 +0800, Paul Repacholi <prep@prep.synonet.com>  > wrote: > : > >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes: > > H > >> But it is acedemic.  The decision, like it or not, was to not buildI > >> EV8, and to concentrate on building platforms and not chips.  And to E > >> be able to have a single server platform strategy for all O/S's.  > > : > >So ComHP is dumping x86 for servers? No more Proliants? > G > I got the impression their plan was to dump x86 ultimately when IA-64  > replaced it. >   G Not in any near term future.  x86 is cheap and fast for the desktop and  small servers.  H > Now that IA-64 seems unlikely to outlive Alpha let alone x86, probablyH > their only option will be to switch to x86-64. It'll be interesting to( > see how late they leave it to do this. >   L Only if you are listening to Bill Todd.  Intel hasn't backed away from IA64, and I don't think they will.   ------------------------------  # Date: Sun, 05 May 2002 23:28:32 GMTl# From: "John Smith" <a@nonymous.com>$  Subject: Re: Revisionist historyH Message-ID: <AejB8.25834$wSM1.5484@news02.bloor.is.net.cable.rogers.com>  D Intel is the largest 'white box' server manufacturer/supplier in the	 business.h    @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message2 news:3RgB8.4$rJ4.134268@cacnews.cac.cpqcorp.net...7 > "Russell Wallace" <spam@devnull.com> wrote in message$, > news:3cd535a9.266834656@news.eircom.net...8 > > On Sat, 04 May 2002 15:46:10 GMT, "Terry C. Shannon"# > > <terryshannon@attbi.com> wrote:a > >uK > > >Almost certainly the case. So, why did they do what they did when theyw > dideH > > >it, rather than announce IPF as a "complementary" architecture? Not
 > everyoneE > > >at CPQ is stupid, particularly the technology types who made thet decision > to > > >"abandon chip." > >aI > > But the final decision to abandon chip was made by senior management,e > > not the technology types.  > >P > G > What does this mean?  Do you know any company that delegates critical-L > business decisions to "technology types"?  Several important technologistsI > were part of the decision process.  The fact that not everyone is happy* withC > the decision, doesn't mean that it was an arbitrary PHB decision.o >:< > > >Seems to me CPQ thought it could get more leverage withL > > >Intel by effectively taking Alpha off the microprocessor playing field. > >-G > > *nod* That may very well have been one of the reasons on paper. The/G > > impression I get, though (admittedly without anything even remotely-E > > resembling inside information) is that their real reason was they-G > > didn't want to be in the business of developing technology, only of A > > packaging and supporting it. They (Compaq management, not thecI > > engineers) then started looking for excuses to support this, and soon5 > > found some.t > >o >eK > The decision was made to not stay in the CPU development business.  Since J > Intel is in the CHIP business, and not in the system business - it would= > seem to me to make much better sense than the alternatives.s >n >  >t >h >a   ------------------------------  % Date: Sun, 05 May 2002 22:07:01 -0400 ( From: David Froble <davef@tsoft-inc.com>  Subject: Re: Revisionist history, Message-ID: <3CD5E545.2050703@tsoft-inc.com>   John Smith wrote:3  F > Intel is the largest 'white box' server manufacturer/supplier in the > business.b >  > B > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message  D >>The decision was made to not stay in the CPU development business.    P Now this is a statement that cannot be argued with.  Many have seen through all O the BS, and plainly Compaq didn't want to be in the CPU business, even if they u5 had and would continue to have the best in the world.a  " But then one more rationalization:  	 >>  Since J >>Intel is in the CHIP business, and not in the system business - it would= >>seem to me to make much better sense than the alternatives.c    M And as with every other rationalization that has come out of Compaq, as seen h9 above, this one like all others cannot withstand reality.h  P Why can't these people just come out and say that they didn't want to be in the P chip business, and quit trying to justify their actions with any other reasons. Q   There are no other reasons.  Treating their customers as if they were gullable -L idiots (not mentioning anyone specific) is almost, but not quite as bad, as  breaking commitments.j   Dave   ------------------------------  % Date: Sun, 05 May 2002 22:13:15 -0400e( From: David Froble <davef@tsoft-inc.com>  Subject: Re: Revisionist history, Message-ID: <3CD5E6BB.9000207@tsoft-inc.com>   Fred Kleinsorge wrote:  7 > "Russell Wallace" <spam@devnull.com> wrote in message$  H >>Now that IA-64 seems unlikely to outlive Alpha let alone x86, probablyH >>their only option will be to switch to x86-64. It'll be interesting to( >>see how late they leave it to do this. > N > Only if you are listening to Bill Todd.  Intel hasn't backed away from IA64, > and I don't think they will.  M If they're like Compaq management, the announcement will be rather sudden. IfeL they're unlike Compaq management, they'll have a 'proven' alternative before they make that move.    Q It's not only Bill.  There are others who think that IA-64 will crater.  Most of 3Q us have indicated our opinions.  I for one will not belabor the issue endlessly. w6 It's now time to wait and discover tomorrow's reality.     Dave   ------------------------------  # Date: Mon, 06 May 2002 02:53:22 GMT.* From: "Bill Todd" <billtodd@metrocast.net>  Subject: Re: Revisionist history@ Message-ID: <CemB8.95983$Lj.7462982@bin4.nnrp.aus1.giganews.com>  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message2 news:PIgB8.3$0s3.128119@cacnews.cac.cpqcorp.net... >"7 > "Bill Todd" <billtodd@metrocast.net> wrote in messageh: > news:haGA8.1527$M7.211119@bin7.nnrp.aus1.giganews.com... > > D > > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message7 > > news:A2EA8.35$FY2.677920@cacnews.cac.cpqcorp.net...l > >r > > ...n > >s > L > I started to respond to your response, but decided that it isn't worth theJ > time.  Fortunately, you have pretty much nothing to do with any chip, orJ > their future - other than being a critic (who somehow has found a way to- > apply "revisionism" to future predictions).i  G Wrong again, Fred.  The statement I called revisionist was not that EV8 B *would have* encountered significant problems in the future due toJ underestimation of the complexity of SMT (a statement which made by anyoneJ other than those intimately involved in the realization of the product, orK another similar product, seems presumptuous to the point of idiocy), it was)I that EV8 *was* encountering significant unexpected problems in this area. G Since that flies in the face of what the EV8 group has been saying, and.I since they far better than anyone else were in a position to know, I callt2 that revisionism (of the best evidence available).  G Whether it's indeed fortunate that I have nothing to do with any chip's2K future is debatable, I guess:  I certainly wouldn't have thrown Alpha away,cG and I suspect some here would have preferred that outcome to what thosep9 bright lads who *did* control the situation came up with.e   - bill   ------------------------------   Date: 5 May 2002 20:54:05 -0000e= From: Doc.Cypher <Use-Author-Supplied-Address-Header@[127.1]> 0 Subject: Re: SKC Morphs Again... We're Now SKHPC6 Message-ID: <20020505205405.27718.qmail@gacracker.org>  K On Sun, 05 May 2002, "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote: ; >"JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in messageo' >news:3CD33DC4.C4E3C02B@videotron.ca...a   <snip>  M >> So, in my opinion, the "status quo" is really an expectation that VMS will-6 >> die not long after HP starts to ]ush IA64 machines. >>L >> A strong public commitment and serious marketing is needed to counter theK >> ill effects of the port to an inferior platform and the mayhem that willl >> result from the merger. w >e8 >We'll see.  The next few months may give an indication.  F Ah, I hope that is some indication you know about a top-secret planned marketing stategy for VMS :)     Doc.   ------------------------------  # Date: Sun, 05 May 2002 20:51:56 GMTi5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>o0 Subject: Re: SKC Morphs Again... We're Now SKHPC8 Message-ID: <MXgB8.7$7O4.185484@cacnews.cac.cpqcorp.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3CD33DC4.C4E3C02B@videotron.ca... > "Terry C. Shannon" wrote: I > > I'd give pretty good odds on the survival of OpenVMS, Marvel/EV7, ande evenE > > Tru64-on-Alpha well beyond May 7. VMS is IMHO more exposed to ISVo	 attrition4 > > than to merger-day culling.l >a >eC > If HP chooses to keep VMS in status quo mode (total obscurity, nol
 marketing,L > VMS never mentioned in public), isn't that tantamount to signing its death0 > warrant, but expecting VMS to slowly die off ? >o  ? If it's in total obscurity, how did you find this newsgroup ;-)s  J > With the forced port to IA64, and no serious public commitment to VMS by HP,oH > and with VMS relegated to only large boxes running a slow chip, can we reallyJ > expect the small medium ISVs to continue to support VMS ? I realise that someD > of the big guys such as Oracle said that they would continue theirJ > "commitment" to VMS, but these same people's definition of commitment isI > different since they don't port all of Oracle to VMS, only the database  backend. >n  F You don't have to listen exclusively to Bill.  It's not all that slow,2 especially if you are currently using Sun systems.  L > So, in my opinion, the "status quo" is really an expectation that VMS will diee1 > not long after HP starts to ]ush IA64 machines.m >wK > A strong public commitment and serious marketing is needed to counter theC illnF > effects of the port to an inferior platform and the mayhem that will result > from the merger.  7 We'll see.  The next few months may give an indication.r   ------------------------------  # Date: Sun, 05 May 2002 18:25:33 GMT-5 From: Forrest Kenney <Forrest.Kenney@compaq.com.doom>r Subject: Re: USB on OpenVMS / Message-ID: <3CD577AD.18FC0B25@compaq.com.doom>l  D     The history of USB and OpenVMS where it has been and where it is+ going.  There has been an ongoing effort to H get USB into OpenVMS.  The original plan was to support it with the DS10' ES40 platform.  As part of this work we E built and for a limited time supplied a USB kit for a V7.2 code base.f0 This code was also demonstrated at the San DecusH in 1999.  At that time the plan was to ship full support for USB as part+ of V7.3.  But plans changed for a number ofd% reasons and the work was put on hold.o  J     When it was obvious that some of the new  platforms would not have any& of the legacy ISA I/O devices work wasI restarted and the code was dug out of mothballs.  We recently finished upi( all the work that we know of to make USB@ viable on these new platforms.  Officially only the embedded USB0 controllers on these platforms are supported andG only for keyboards and mice.  All of the supported code is checked intou, the version that is presently in field test.  H     In addition support for keyboards, mice, we are shipping drivers for, printers and cables that conform the the USBF printer standard.  We also have support for modems that conform to the- communications class standard.  These are notlH going to be listed as supported because we did not have the resources to1 test and qualify devices for this relase.  PleaseaG feel free to use them and report problems but don't be surprised if youa- get a these are not supported answer from then support organizations.  .     What is not supported at the present time:  9               1) UHCI controllers, or USB 2.0 controllersyG               2) Any random OHCI based controllers.  We have tested andh$ had good luck with ones based on theJ                   Lucent USS344 chip and Symbios 6080.  We have tried some& other with varying degrees of success.)               3) Customer written driverse   Forrest Kenney OpenVMS USB project leader   ------------------------------  % Date: Sun, 05 May 2002 14:29:50 -0400,1 From: Michael Austin <maustin@firstdbasource.com>n Subject: Re: USB on OpenVMS 2 Message-ID: <3CD57A1E.E6CABC90@firstdbasource.com>   statzerj@bellsouth.net wrote:f > H > Thank you Michael for both responses.  They have been very helpful.  IH > agree about Ethernet being a preference to USB, but it might not be anG > option for my DSL provider and me right now.  I was not aware of that?D > option for the router that utilizes a USB DSL modem.  Might do theH > firewall activity via that and an old Pentium box with Linux or NT and, > then VMS/Linux the Alphas behind all that. > G > Just had to check as I like the VMS security set-up and fiddling with ) > the Alphas - even as a bit of a novice.o > B > FWIW - my USB modem has been a bit flaky at times, but mostly isD > reliable under my current one computer/one connection mdoel.  Only? > when looking to network the others has it become problematic.t2 > Anyhow, you have given me a direction to pursue. >  > Thank you, > 4 > On Sun, 05 May 2002 07:52:34 -0400, Michael Austin% > <maustin@firstdbasource.com> wrote:p >  > >Dirk Munk wrote:p > >>" > >> statzerj@bellsouth.net wrote:L > >> > Are there drivers available to support USB devices under OpenVMS?  MyL > >> > initial web seach was not promising, but I have a USB DSL modem and II > >> > have seen it possible to set up Linux to run this modem, but would M > >> > like to experiment with VMS as well if my Multia or Alphastation couldb > >> > handle it.n > >> > > >> > Thanks, > >> > > >> > > >>M > >> I have asked similar questions before about the use of USB. According tovJ > >> Hoff Hoffman there was some work done on enabling USB support on VMS,J > >> however only on built-in USB adapters, not on extra USB cards. At theK > >> time he replied that the quality of the USB chipsets wasn't very good,n4 > >> so lots of trouble designing a reliable driver. > >>K > >> Now even if we have a driver for enabling the interface, we will still0P > >> need drivers for network over USB, or printers over USB or ..... and so on. > >>J > >> But I would like to see that. We can be sure that parallel interfacesL > >> and serial interfaces will be replaced by USB in most cases. Connecting8 > >> a low cost printer to a USB port would be nice .... > >>
 > >> Regards,. > >>	 > >> Dirk  > >nE > >Having been helping out in an ADSL Support group the #1 problem is G > >trying to get USB DSL modems to work reliably i.e. a LOT of constant G > >disconnects.  I think it will be a VERRY long time before USB is anynD > >good for anything other than printers and scanners -- and that isE > >debatable.  Ethernet is still the better way to go - and is usallyrH > >included in all hardware configs.  Even if you did have a USB NetworkC > >device, in the data center you would need to convert from USB to I > >ethernet any way. So why bother?  More opportunity for troubleshooting  > >:)2 > >1 > >--  > >Regards,u > >w: > >Michael Austin            Registered Linux User #261163: > >First DBA Source, Inc.    http://www.firstdbasource.com > >Sr. Consultante > >704-947-1089 (Office) > >704-236-4377 (Mobile) > >t  F Th good thing about most SOHO routers, is the fact that the router canF provide very good firewall support - that is, unless you start opening; specific ports for things like gaming and SMTP/Telnet/FTP.      C I will be leaving shortly to go get on a plane and hope to have the E requested DSL/Cable config done shortly..  I will do some of it on mydE Handspring (Palm) PDA.  It will give me something to do on the plane.t   -- p Regards,  7 Michael Austin            Registered Linux User #261163 7 First DBA Source, Inc.    http://www.firstdbasource.comy Sr. Consultant 704-947-1089 (Office)l 704-236-4377 (Mobile)    ------------------------------  # Date: Sun, 05 May 2002 21:06:32 GMT.5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>  Subject: Re: USB on OpenVMS-7 Message-ID: <s9hB8.8$sp3.57401@cacnews.cac.cpqcorp.net>a  L "Dirk Munk" <munk@home.nl> wrote in message news:3CD50C00.4090403@home.nl... > statzerj@bellsouth.net wrote:-I > > Are there drivers available to support USB devices under OpenVMS?  My.I > > initial web seach was not promising, but I have a USB DSL modem and IoF > > have seen it possible to set up Linux to run this modem, but wouldJ > > like to experiment with VMS as well if my Multia or Alphastation could > > handle it. > >  > > Thanks,0 > >   H USB support will arrive with V7.3-1 and Marvel.  I believe that there isH printer support, as well as keyboard and mouse support.  But as far as IL know, there aren't plans yet for user/3rd party USB decoders.  The USB has aI port driver that knows how to talk to the USB bus, and configure devices.]G But each device type needs a small driver that knows about the specificfB device types.  I don't know if there is a modem driver, I know the! developers had talked about them.h   > >y >l > J > I have asked similar questions before about the use of USB. According toG > Hoff Hoffman there was some work done on enabling USB support on VMS,sG > however only on built-in USB adapters, not on extra USB cards. At thenH > time he replied that the quality of the USB chipsets wasn't very good,1 > so lots of trouble designing a reliable driver.c >m  L The support was done for the built in controllers, however, there are only aK couple of them anyway, so add-in cards *do* work (you'd have to ask someoneeE like Forrest for the controller "type" you need).  I debugged the USBoE keyboard and mouse support using a PCI card on the DS10 (the built-inh% controller on it has a few problems).i  H > Now even if we have a driver for enabling the interface, we will stillI > need drivers for network over USB, or printers over USB or ..... and soh on.y >p  G Printers are there.  I would expect over time to see LAN and hard drivei support happen.b  G > But I would like to see that. We can be sure that parallel interfaces I > and serial interfaces will be replaced by USB in most cases. Connectingi5 > a low cost printer to a USB port would be nice ....v >l  * Check the release notes when V7.3-1 ships.   ------------------------------  # Date: Mon, 06 May 2002 01:13:45 GMTi1 From: "David J. Dachtera" <djesys.nospam@fsi.net>i  Subject: Re: Vax emulator for PC' Message-ID: <3CD5DBC9.8BBE032D@fsi.net>    Steve Pfister wrote: > R > > There is a Hobbyist version. This product is definitely the N 1 VAX emulator,: > > and it is also a real product for VAX/VMS development. > A > Where can I get the OpenVMS media? The online order form on theiF > www.montgar.com website shows the VAX version as being sold out. Are > there other sources?  F E-mail me privately... (how to demung the reply-to should be obvious).   -- a David J. Dachtera  dba DJE Systemse http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/w   ------------------------------  # Date: Mon, 06 May 2002 01:05:39 GMTi1 From: "David J. Dachtera" <djesys.nospam@fsi.net> 1 Subject: Re: VMS Bigots Unite To Form New Companyt' Message-ID: <3CD5D9E1.ABACC2E3@fsi.net>a   Terry C Shannon wrote: > % > On Sat, 4 May 2002, JF Mezei wrote:  >  > > Paul Repacholi wrote:eH > > > Let me give you a slight clue; bussinesses don't give a shit aboutI > > > 'standard' they want 'work. They have 'standard' and have found outtK > > > about the quality and reliability that you get from Redmond, and felti > > > it in the hip pocket!d > >m > > I woud rephrase that as: > >nR > > Businesses have come to realise that using "standard" (aka: Microsoft)  is notN > > the great cost saver that they all thought it would when you factor in theW > > increased support and decreased employee productivity, and now, the virus problems.e > >bP > > Presenting a robust solution that is in the same ballpark price as MicrosoftD > > would stand much greater chances now than it would in the 1990s. > > R > > The love virus was a big hit on corporations, but they may have figured it wasL > > a once in a lifetime issue. But they keep coming and coming and now that] > > corporations are realising this, they are no longer so comfortable with wintel solutions.d > >a > L > Hmmm... might this be one reason why Compaq's mantra recently changed from# > "Windoze" to "Windoze AND LINUX?"r  F Indeed. Perhaps the beginning of a turning away from Bill Gates (can'tF come any too soon, that for sure!). Maybe this is that glimmer of hopeC that will keep VMS alive: the hope that someday, BG's death-grip on D those who control VMS's purse strings will finally be broken and tenF years of stagnation will be ended, and the release will provide such aH recoil that VMS will be catapulted back to the forefront where it should have been all these years.  G Yes, I'm a dreamer - (almost) everyone here knows that, anyway - no big> revelation, eh?    --   David J. Dachtera. dba DJE Systemst http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/l   ------------------------------   Date: 5 May 2002 17:13:57 -0700t. From: csabah@zipworld.com.au (CSABA HARANGOZO)$ Subject: VT-s ( was Re: New to VAX )= Message-ID: <df779b76.0205051613.6f848041@posting.google.com>o  Z Jim Agnew <agnew@mail2.vcu.edu> wrote in message news:<3CD28779.C669C66A@mail2.vcu.edu>... > David Froble wrote:h > >  > > Steve wrote: >  IA > > VT52 - A rather large box introduced in the mid to late 1970sw > 3 > there was a VT55, a graphics version of the vt52.- > C > 	It had a lovely buzzer instead of a beep that I could hear emaill	 > come...lI > 	The vertical sweep finally died.  I remember warming up my food on the9
 > heatsink > 	on the back.. ;-D >  > jim   J  Also, today as I was looking at the ( nostalgic ) photos of old computersD  at http://simh.trailing-edge.com, I saw a VT78. It looked... heavy.G  Various old consoles were in the photos as well, like a DECscope, etc.u  L  Just mention, that the photo of the 11/44 seems to be reversed, if you lookL  at the keyboards there you could see that the numbers keypad is on the left=  side :-) Maybe this computer was made for left-handers 8-) ?b  J  Mentioning the SIMH projects, is there any plan to issue an RSX-11M one ('  if one is not already made ) ? Thanks. F                                                       Cheers,    Csaba   ------------------------------  * Date: Sun, 5 May 2002 15:18:46 -0300 (BRT) From: valdemir-@uol.com.br Subject: X-Win324 Message-ID: <200205051818.PAA09670@wilde.uol.com.br>   Hello VMS gurus:  ?  In my job we are using X-Win32 to connect in our Sun machines,e=  and I=B4d like know if I can use X-win32 to connect with ouru@  VAXes machines. Reading X-win32 help I didn=B4t find references  about VMS systems.h  Thanks in advance...n   ------------------------------  % Date: Mon, 06 May 2002 07:42:09 +0930a/ From: Mark Daniel <Mark.Daniel@wasd.vsm.com.au>i Subject: Re: X-Win32. Message-ID: <3CD5AE39.4050803@wasd.vsm.com.au>   valdemir-@uol.com.br wrote:s > Hello VMS gurus: > A >  In my job we are using X-Win32 to connect in our Sun machines,c= >  and Id like know if I can use X-win32 to connect with oure@ >  VAXes machines. Reading X-win32 help I didnt find references >  about VMS systems.h >  Thanks in advance...d   Yes.  We use it via 'rexec'.  L It's fonts do not include some required to support all DECterm requirements I so we specify our local X Font Server.  I really should take the time to jJ find out how to install these fonts locally so that it can be used on our / laptops more transparently (any advice anyone?)"  6 X-Win32 seems to perform and behave itself quite well.   ------------------------------  # Date: Mon, 06 May 2002 01:16:59 GMT41 From: "David J. Dachtera" <djesys.nospam@fsi.net>y8 Subject: Re: ZIPped .PCSI container arrives OK on VMS???' Message-ID: <3CD5DC8B.BAB0A66A@fsi.net>    sms@antinode.org wrote:  > H > From: "David J. (Just-can't-give-up) Dachtera" <djesys.nospam@fsi.net> > > [drool deleted]  > G >    The original question was why BACKUP was fussy about save-set filerD > attributes, while a PCSI kit was accepted with altered attributes.  ' ...which is, I believe what I answered.o   --   David J. Dachterad dba DJE Systemsg http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/m   ------------------------------  # Date: Mon, 06 May 2002 01:53:55 GMTh1 From: "David J. Dachtera" <djesys.nospam@fsi.net>48 Subject: Re: ZIPped .PCSI container arrives OK on VMS???& Message-ID: <3CD5E52F.2A387F6@fsi.net>   sms@antinode.org wrote:r > H > From: "David J. (Just-can't-give-up) Dachtera" <djesys.nospam@fsi.net> > > [drool deleted]a > G >    The original question was why BACKUP was fussy about save-set fileeD > attributes, while a PCSI kit was accepted with altered attributes.   So far, we agree.e  H >    You "explained" this by stating that "[...] Everything else is someG > form of stream file (Stream, Stream_CR or Stream_LF). .ZIPs, .TARs, >b9 > .TGZs, etc. ...", which was clearly wrong, as I showed.l  @ Well, no you didn't. You only showed that on VMS, ZIP and VMSTARF produced an archive with Fixed-512 attributes, while GZIP produces one with Stream_LF attributes.  C You failed to show that UNZIP will also accept a .ZIP archive whoseu attributes are Stream_LF:r  % DJAS01::DDACHTERA$ dir/fu vdstep2.zipg   Directory DKA0:[DDACHTERA]  > VDSTEP2.ZIP;1                 File ID:  (3598,5,0)            . Size:           84/84         Owner:    [30,1]" Created:    9-SEP-1999 17:42:35.32& Revised:    9-SEP-1999 17:43:02.85 (1) Expires:   <None specified>n Backup:    <No backup recorded>l Effective: <None specified>o Recording: <None specified>t File organization:  Sequential Shelved state:      Online pE File attributes:    Allocation: 84, Extend: 0, Global buffer count: 0a$                     No version limit1 Record format:      Fixed length 512 byte recordsC Record attributes:  None RMS attributes:     None Journaling enabled: None= File protection:    System:RWED, Owner:RWED, Group:RE, World:  Access Cntrl List:  None   Total of 1 file, 84/84 blocks.% DJAS01::DDACHTERA$ unzip/test vdstep2 ' Archive:  DKA0:[DDACHTERA]VDSTEP2.ZIP;1a    H VDSTEP2  [20-AUG-1994] --  A virtual disk driver for OpenVMS AXP V6.1 or later.3 Written by Glenn Everhart <everhart@arisia.gce.com> 6 Packaged by Hunter Goatley <goathunter@WKUVX1.WKU.EDU>  " Runs on OpenVMS AXP V6.1 or later.  ? (VMS file attributes saved---use UnZip V5.x+ on VMS to restore) (     testing: aaareadme.txt            OK(     testing: asnvdm6.cld              OK(     testing: asnvdm6.mar              OK(     testing: asnvdm6.opt              OK(     testing: asnvdm6_cld.cld          OK(     testing: build.com                OK(     testing: descrip.mms              OK(     testing: vddriver.mar             OK(     testing: vddriver.opt             OKG No errors detected in compressed data of DKA0:[DDACHTERA]VDSTEP2.ZIP;1.sH DJAS01::DDACHTERA$ set file/attr=(rfm=stmlf,mrs=0,lrl=32767) vdstep2.zip% DJAS01::DDACHTERA$ dir/fu vdstep2.zipl   Directory DKA0:[DDACHTERA]  > VDSTEP2.ZIP;1                 File ID:  (3598,5,0)            . Size:           84/84         Owner:    [30,1]" Created:    9-SEP-1999 17:42:35.32& Revised:    5-MAY-2002 20:24:27.29 (3) Expires:   <None specified>a Backup:    <No backup recorded>s Effective: <None specified>t Recording: <None specified>  File organization:  Sequential Shelved state:      Online eE File attributes:    Allocation: 84, Extend: 0, Global buffer count: 0 $                     No version limitC Record format:      Stream_LF, maximum 0 bytes, longest 32767 bytesl Record attributes:  None RMS attributes:     None Journaling enabled: None= File protection:    System:RWED, Owner:RWED, Group:RE, World:  Access Cntrl List:  None   Total of 1 file, 84/84 blocks.% DJAS01::DDACHTERA$ unzip/test vdstep2o' Archive:  DKA0:[DDACHTERA]VDSTEP2.ZIP;1H    H VDSTEP2  [20-AUG-1994] --  A virtual disk driver for OpenVMS AXP V6.1 or later 3 Written by Glenn Everhart <everhart@arisia.gce.com>e6 Packaged by Hunter Goatley <goathunter@WKUVX1.WKU.EDU>  " Runs on OpenVMS AXP V6.1 or later.  ? (VMS file attributes saved---use UnZip V5.x+ on VMS to restore)-(     testing: aaareadme.txt            OK(     testing: asnvdm6.cld              OK(     testing: asnvdm6.mar              OK(     testing: asnvdm6.opt              OK(     testing: asnvdm6_cld.cld          OK(     testing: build.com                OK(     testing: descrip.mms              OK(     testing: vddriver.mar             OK(     testing: vddriver.opt             OKG No errors detected in compressed data of DKA0:[DDACHTERA]VDSTEP2.ZIP;1.a  F I don't use VMSTAR or G[UN]ZIP enough to be worthwhile for me to test,0 so I'll leave that as an exercise to the reader.  H >    I then stated that some programs, like BACKUP, care more about file > attributes than others.  > 1 >    You apparently felt compelled to reply with:s > - > > [This portion of quote added back by me.] I > > I would say that BACKUP is no different from any other application orrJ > > program that expects the RMS attributes to actually reflect the formatJ > > of the data in the file. *ANY* program that expects the RMS attributesI > > to accurately reflect the format of the file contents will choke whenh/ > > there's a mistmatch. It's just that simple.p > > [End Restoration]eE > > Some programs don't care: as long as record I/O returns data thata6 > > matches the program's expectations, they're happy. > H >    Does that differ in any significant way from what I stated?  (OtherF > than tossing in "record I/O", which is, again, irrelevant, that is.)  A Well, no it isn't "irrelevant". Some programs (see the Port PrintoC Facility archive at http://www.djesys.com/vms/freeware.html#ppf012, E especially PPF.BAS) aren't written with record attributes hard-coded.A> They'll handle some of what's "thrown" at them, within limits.  G Others expect a hard-coded record size and/or blocking factor (on thosenG media where that matters), and will reject files that don't match theirB@ expectations (usually to the shagrin and consternation of junior
 programmers)..  - So, yes, RMS *IS* the answer, like it or not.b  L > > When you get down to the fundamental level of the question, RMS is *THE* > > answer.U > G >    When you figure out what "the question" is, please don't bother mer > about it.e  F That answer (above) again raises another question, however: since PCSIH archives are (were?) previously expected to be Fixed-8192, has PCSI beenD revised to accept "corrupted" (essentially, attribute-less) files inF anticipation of the loss of RMS attributes due to file transfer stagesE which lack RMS support - which is expected to be the norm rather thant the exception?  E That is, perhaps, the kernel of Didier's question. However, in askingnG the question the way he did, he was comparing an RMS-dependent facilitytH (BACKUP, for savesets on disk, at least) to one which - I believe he mayF suspect - perhaps has had its RMS dependency removed (PCSI) or perhaps siginficantly reduced.  B ...and by the way, I was unable to duplicate Didier's observation:  ' DJAS01::DDACHTERA$ dir *decnet*.pcsi/fus   Directory DKA0:[DDACHTERA]  * DEC-VAXVMS-DECNET_PHASE_IV-V0702--1.PCSI;1>                               File ID:  (745,5,0)             . Size:          800/804        Owner:    [30,1]" Created:   16-DEC-1998 14:24:13.63& Revised:   16-DEC-1998 14:24:15.20 (1) Expires:   <None specified>y Backup:    <No backup recorded>  Effective: <None specified>c Recording: <None specified>m File organization:  Sequential Shelved state:      Online gF File attributes:    Allocation: 804, Extend: 0, Global buffer count: 0$                     No version limit2 Record format:      Fixed length 8192 byte records Record attributes:  None RMS attributes:     None Journaling enabled: None? File protection:    System:RWED, Owner:RWED, Group:RE, World:REb Access Cntrl List:  None    Total of 1 file, 800/804 blocks.% DJAS01::DDACHTERA$ prod list *decnet*-  -( The following product has been selected::     DEC VAXVMS DECNET_PHASE_IV V7.2        Layered Product  j  Do you want to continue? [YES] y   I -------------------------------------------------------------------------w Files in@ _DJAS01$DKA0:[DDACHTERA]DEC-VAXVMS-DECNET_PHASE_IV-V0702--1.PCSII -------------------------------------------------------------------------S  M4 [000000]DEC-VAXVMS-DECNET_PHASE_IV-V0702--1.PCSI$TLB [SYS$LDR]NDDRIVER.EXEo [SYS$LDR]NETDRIVER.EXE! [SYS$LDR]SYS$NETWORK_SERVICES.EXEe [SYSEXE]NCP.EXE  [SYSEXE]NET$NAME_SERVER.EXEs [SYSEXE]NETACP.EXE [SYSEXE]NETSERVER.COM  [SYSEXE]NETSERVER.EXE  [SYSEXE]NICONFIG.COM [SYSEXE]NICONFIG.EXE [SYSEXE]NML.COMv [SYSEXE]NML.EXEa [SYSLIB]XTI$DNETSHR.EXEr [SYSMGR]LOADNET.COMd [SYSMGR]NETCONFIG.COMt [SYSMGR]STARTNET.COM [SYSUPD]NETCONFIG_UPDATE.COM< [000000]DEC-VAXVMS-DECNET_PHASE_IV-V0702--1.PCSI$DESCRIPTION  w End of listh< DJAS01::DDACHTERA$ set file/attr=(rfm=stmlf,mrs=0,lrl=32767)
 *decnet*.pcsi ' DJAS01::DDACHTERA$ dir *decnet*.pcsi/fup   Directory DKA0:[DDACHTERA]  * DEC-VAXVMS-DECNET_PHASE_IV-V0702--1.PCSI;1>                               File ID:  (745,5,0)             . Size:          800/804        Owner:    [30,1]" Created:   16-DEC-1998 14:24:13.63& Revised:    5-MAY-2002 20:44:28.02 (2) Expires:   <None specified>a Backup:    <No backup recorded>  Effective: <None specified>t Recording: <None specified>s File organization:  Sequential Shelved state:      Online  F File attributes:    Allocation: 804, Extend: 0, Global buffer count: 0$                     No version limitC Record format:      Stream_LF, maximum 0 bytes, longest 32767 bytesr Record attributes:  None RMS attributes:     None Journaling enabled: None? File protection:    System:RWED, Owner:RWED, Group:RE, World:REl Access Cntrl List:  None    Total of 1 file, 800/804 blocks.% DJAS01::DDACHTERA$ prod list *decnet*s %PCSI-E-READERR, error reading1 _DJAS01$DKA0:[DDACHTERA]DEC-VAXVMS-DECNET_PHASE_In V-V0702--1.PCSI;1a# -DDIS-E-TNF, invalid element syntaxo" %PCSI-E-S_OPFAIL, operation failedC %PCSIUI-E-ABORT, operation terminated due to an unrecoverable errorl	 condition   E I'm running OpenVMS Alpha V7.1-2 and whatever version of PCSI shippednH with it, no patches. Behavior of PCSI on later (or earlier) versions may differ.    -- h David J. Dachtera  dba DJE Systems- http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/t   ------------------------------  # Date: Mon, 06 May 2002 01:59:27 GMTn1 From: "David J. Dachtera" <djesys.nospam@fsi.net>b8 Subject: Re: ZIPped .PCSI container arrives OK on VMS???' Message-ID: <3CD5E67B.BFDD17C1@fsi.net>    "David J. Dachtera" wrote: >  > sms@antinode.org wrote:e > >TJ > > From: "David J. (Just-can't-give-up) Dachtera" <djesys.nospam@fsi.net> > > > [drool deleted]e > >hI > >    The original question was why BACKUP was fussy about save-set fileoF > > attributes, while a PCSI kit was accepted with altered attributes. >  > So far, we agree.i > J > >    You "explained" this by stating that "[...] Everything else is someI > > form of stream file (Stream, Stream_CR or Stream_LF). .ZIPs, .TARs, >J; > > .TGZs, etc. ...", which was clearly wrong, as I showed.  > B > Well, no you didn't. You only showed that on VMS, ZIP and VMSTARH > produced an archive with Fixed-512 attributes, while GZIP produces one > with Stream_LF attributes. > E > You failed to show that UNZIP will also accept a .ZIP archive whose  > attributes are Stream_LF:h > ' > DJAS01::DDACHTERA$ dir/fu vdstep2.zip  >  > Directory DKA0:[DDACHTERA] > 4 > VDSTEP2.ZIP;1                 File ID:  (3598,5,0)0 > Size:           84/84         Owner:    [30,1]$ > Created:    9-SEP-1999 17:42:35.32( > Revised:    9-SEP-1999 17:43:02.85 (1) > Expires:   <None specified>t! > Backup:    <No backup recorded>y > Effective: <None specified>  > Recording: <None specified>p  > File organization:  Sequential > Shelved state:      OnlineG > File attributes:    Allocation: 84, Extend: 0, Global buffer count: 0o& >                     No version limit3 > Record format:      Fixed length 512 byte recordsa > Record attributes:  None > RMS attributes:     None > Journaling enabled: None? > File protection:    System:RWED, Owner:RWED, Group:RE, World:t > Access Cntrl List:  None >   > Total of 1 file, 84/84 blocks.' > DJAS01::DDACHTERA$ unzip/test vdstep2h) > Archive:  DKA0:[DDACHTERA]VDSTEP2.ZIP;1c > J > VDSTEP2  [20-AUG-1994] --  A virtual disk driver for OpenVMS AXP V6.1 or > later 5 > Written by Glenn Everhart <everhart@arisia.gce.com>s8 > Packaged by Hunter Goatley <goathunter@WKUVX1.WKU.EDU> > $ > Runs on OpenVMS AXP V6.1 or later. > A > (VMS file attributes saved---use UnZip V5.x+ on VMS to restore)f* >     testing: aaareadme.txt            OK* >     testing: asnvdm6.cld              OK* >     testing: asnvdm6.mar              OK* >     testing: asnvdm6.opt              OK* >     testing: asnvdm6_cld.cld          OK* >     testing: build.com                OK* >     testing: descrip.mms              OK* >     testing: vddriver.mar             OK* >     testing: vddriver.opt             OKI > No errors detected in compressed data of DKA0:[DDACHTERA]VDSTEP2.ZIP;1.-J > DJAS01::DDACHTERA$ set file/attr=(rfm=stmlf,mrs=0,lrl=32767) vdstep2.zip' > DJAS01::DDACHTERA$ dir/fu vdstep2.zipo >  > Directory DKA0:[DDACHTERA] > 4 > VDSTEP2.ZIP;1                 File ID:  (3598,5,0)0 > Size:           84/84         Owner:    [30,1]$ > Created:    9-SEP-1999 17:42:35.32( > Revised:    5-MAY-2002 20:24:27.29 (3) > Expires:   <None specified>r! > Backup:    <No backup recorded>  > Effective: <None specified>s > Recording: <None specified>I  > File organization:  Sequential > Shelved state:      OnlineG > File attributes:    Allocation: 84, Extend: 0, Global buffer count: 0m& >                     No version limitE > Record format:      Stream_LF, maximum 0 bytes, longest 32767 bytesc > Record attributes:  None > RMS attributes:     None > Journaling enabled: None? > File protection:    System:RWED, Owner:RWED, Group:RE, World:i > Access Cntrl List:  None >   > Total of 1 file, 84/84 blocks.' > DJAS01::DDACHTERA$ unzip/test vdstep2h) > Archive:  DKA0:[DDACHTERA]VDSTEP2.ZIP;1m > J > VDSTEP2  [20-AUG-1994] --  A virtual disk driver for OpenVMS AXP V6.1 or > laterb5 > Written by Glenn Everhart <everhart@arisia.gce.com> 8 > Packaged by Hunter Goatley <goathunter@WKUVX1.WKU.EDU> > $ > Runs on OpenVMS AXP V6.1 or later. > A > (VMS file attributes saved---use UnZip V5.x+ on VMS to restore) * >     testing: aaareadme.txt            OK* >     testing: asnvdm6.cld              OK* >     testing: asnvdm6.mar              OK* >     testing: asnvdm6.opt              OK* >     testing: asnvdm6_cld.cld          OK* >     testing: build.com                OK* >     testing: descrip.mms              OK* >     testing: vddriver.mar             OK* >     testing: vddriver.opt             OKI > No errors detected in compressed data of DKA0:[DDACHTERA]VDSTEP2.ZIP;1.: > H > I don't use VMSTAR or G[UN]ZIP enough to be worthwhile for me to test,2 > so I'll leave that as an exercise to the reader. > J > >    I then stated that some programs, like BACKUP, care more about file > > attributes than others.u > > 3 > >    You apparently felt compelled to reply with:  > >n/ > > > [This portion of quote added back by me.]2K > > > I would say that BACKUP is no different from any other application or.L > > > program that expects the RMS attributes to actually reflect the formatL > > > of the data in the file. *ANY* program that expects the RMS attributesK > > > to accurately reflect the format of the file contents will choke whenl1 > > > there's a mistmatch. It's just that simple.s > > > [End Restoration]nG > > > Some programs don't care: as long as record I/O returns data that-8 > > > matches the program's expectations, they're happy. > > J > >    Does that differ in any significant way from what I stated?  (OtherH > > than tossing in "record I/O", which is, again, irrelevant, that is.) > C > Well, no it isn't "irrelevant". Some programs (see the Port PrintDE > Facility archive at http://www.djesys.com/vms/freeware.html#ppf012,iG > especially PPF.BAS) aren't written with record attributes hard-coded.s@ > They'll handle some of what's "thrown" at them, within limits. > I > Others expect a hard-coded record size and/or blocking factor (on thosegI > media where that matters), and will reject files that don't match their/B > expectations (usually to the shagrin and consternation of junior > programmers).2 > / > So, yes, RMS *IS* the answer, like it or not.p > N > > > When you get down to the fundamental level of the question, RMS is *THE*
 > > > answer.F > >.I > >    When you figure out what "the question" is, please don't bother me)
 > > about it.s > H > That answer (above) again raises another question, however: since PCSIJ > archives are (were?) previously expected to be Fixed-8192, has PCSI beenF > revised to accept "corrupted" (essentially, attribute-less) files inH > anticipation of the loss of RMS attributes due to file transfer stagesG > which lack RMS support - which is expected to be the norm rather thanc > the exception? > G > That is, perhaps, the kernel of Didier's question. However, in askingVI > the question the way he did, he was comparing an RMS-dependent facilityIJ > (BACKUP, for savesets on disk, at least) to one which - I believe he mayH > suspect - perhaps has had its RMS dependency removed (PCSI) or perhaps > siginficantly reduced. > D > ...and by the way, I was unable to duplicate Didier's observation: > ) > DJAS01::DDACHTERA$ dir *decnet*.pcsi/fu  >  > Directory DKA0:[DDACHTERA] > , > DEC-VAXVMS-DECNET_PHASE_IV-V0702--1.PCSI;13 >                               File ID:  (745,5,0) 0 > Size:          800/804        Owner:    [30,1]$ > Created:   16-DEC-1998 14:24:13.63( > Revised:   16-DEC-1998 14:24:15.20 (1) > Expires:   <None specified>a! > Backup:    <No backup recorded>d > Effective: <None specified>  > Recording: <None specified>m  > File organization:  Sequential > Shelved state:      OnlineH > File attributes:    Allocation: 804, Extend: 0, Global buffer count: 0& >                     No version limit4 > Record format:      Fixed length 8192 byte records > Record attributes:  None > RMS attributes:     None > Journaling enabled: NoneA > File protection:    System:RWED, Owner:RWED, Group:RE, World:REs > Access Cntrl List:  None > " > Total of 1 file, 800/804 blocks.' > DJAS01::DDACHTERA$ prod list *decnet*u > * > The following product has been selected:< >     DEC VAXVMS DECNET_PHASE_IV V7.2        Layered Product > " > Do you want to continue? [YES] y > K > ------------------------------------------------------------------------- 
 > Files inB > _DJAS01$DKA0:[DDACHTERA]DEC-VAXVMS-DECNET_PHASE_IV-V0702--1.PCSIK > -------------------------------------------------------------------------  > 6 > [000000]DEC-VAXVMS-DECNET_PHASE_IV-V0702--1.PCSI$TLB > [SYS$LDR]NDDRIVER.EXE  > [SYS$LDR]NETDRIVER.EXE# > [SYS$LDR]SYS$NETWORK_SERVICES.EXEe > [SYSEXE]NCP.EXEd > [SYSEXE]NET$NAME_SERVER.EXEZ > [SYSEXE]NETACP.EXE > [SYSEXE]NETSERVER.COMt > [SYSEXE]NETSERVER.EXEe > [SYSEXE]NICONFIG.COM > [SYSEXE]NICONFIG.EXE > [SYSEXE]NML.COMD > [SYSEXE]NML.EXE. > [SYSLIB]XTI$DNETSHR.EXEI > [SYSMGR]LOADNET.COM  > [SYSMGR]NETCONFIG.COM  > [SYSMGR]STARTNET.COM > [SYSUPD]NETCONFIG_UPDATE.COM> > [000000]DEC-VAXVMS-DECNET_PHASE_IV-V0702--1.PCSI$DESCRIPTION > 
 > End of list > > DJAS01::DDACHTERA$ set file/attr=(rfm=stmlf,mrs=0,lrl=32767) > *decnet*.pcsid) > DJAS01::DDACHTERA$ dir *decnet*.pcsi/fu  >  > Directory DKA0:[DDACHTERA] > , > DEC-VAXVMS-DECNET_PHASE_IV-V0702--1.PCSI;13 >                               File ID:  (745,5,0)d0 > Size:          800/804        Owner:    [30,1]$ > Created:   16-DEC-1998 14:24:13.63( > Revised:    5-MAY-2002 20:44:28.02 (2) > Expires:   <None specified> ! > Backup:    <No backup recorded>W > Effective: <None specified>e > Recording: <None specified>k  > File organization:  Sequential > Shelved state:      OnlineH > File attributes:    Allocation: 804, Extend: 0, Global buffer count: 0& >                     No version limitE > Record format:      Stream_LF, maximum 0 bytes, longest 32767 bytesl > Record attributes:  None > RMS attributes:     None > Journaling enabled: NoneA > File protection:    System:RWED, Owner:RWED, Group:RE, World:REa > Access Cntrl List:  None > " > Total of 1 file, 800/804 blocks.' > DJAS01::DDACHTERA$ prod list *decnet*K  > %PCSI-E-READERR, error reading3 > _DJAS01$DKA0:[DDACHTERA]DEC-VAXVMS-DECNET_PHASE_I  > V-V0702--1.PCSI;1 % > -DDIS-E-TNF, invalid element syntaxm$ > %PCSI-E-S_OPFAIL, operation failedE > %PCSIUI-E-ABORT, operation terminated due to an unrecoverable errorr > conditioni > G > I'm running OpenVMS Alpha V7.1-2 and whatever version of PCSI shipped J > with it, no patches. Behavior of PCSI on later (or earlier) versions may	 > differ.t  E ...and yes, Fixed-512 *DOES* work! Stream_LF does not, as shown aboverH (although technically, "MAC format" files are Stream_CR, not Stream_LF).  H DJAS01::DDACHTERA$ set file/attr=(rfm=fix,mrs=512,lrl=512) *decnet*.pcsi' DJAS01::DDACHTERA$ dir *decnet*.pcsi/fun   Directory DKA0:[DDACHTERA]  * DEC-VAXVMS-DECNET_PHASE_IV-V0702--1.PCSI;1>                               File ID:  (745,5,0)             . Size:          800/804        Owner:    [30,1]" Created:   16-DEC-1998 14:24:13.63& Revised:    5-MAY-2002 20:57:42.49 (3) Expires:   <None specified>u Backup:    <No backup recorded>a Effective: <None specified>' Recording: <None specified>  File organization:  Sequential Shelved state:      Online hF File attributes:    Allocation: 804, Extend: 0, Global buffer count: 0$                     No version limit1 Record format:      Fixed length 512 byte records) Record attributes:  None RMS attributes:     None Journaling enabled: None? File protection:    System:RWED, Owner:RWED, Group:RE, World:REs Access Cntrl List:  None    Total of 1 file, 800/804 blocks.% DJAS01::DDACHTERA$ prod list *decnet*t  w( The following product has been selected::     DEC VAXVMS DECNET_PHASE_IV V7.2        Layered Product  e Do you want to continue? [YES]    eI -------------------------------------------------------------------------c Files in@ _DJAS01$DKA0:[DDACHTERA]DEC-VAXVMS-DECNET_PHASE_IV-V0702--1.PCSII -------------------------------------------------------------------------i   4 [000000]DEC-VAXVMS-DECNET_PHASE_IV-V0702--1.PCSI$TLB [SYS$LDR]NDDRIVER.EXEi [SYS$LDR]NETDRIVER.EXE! [SYS$LDR]SYS$NETWORK_SERVICES.EXEo [SYSEXE]NCP.EXEa [SYSEXE]NET$NAME_SERVER.EXEc [SYSEXE]NETACP.EXE [SYSEXE]NETSERVER.COMe [SYSEXE]NETSERVER.EXEh [SYSEXE]NICONFIG.COM [SYSEXE]NICONFIG.EXE [SYSEXE]NML.COMr [SYSEXE]NML.EXE  [SYSLIB]XTI$DNETSHR.EXEo [SYSMGR]LOADNET.COMd [SYSMGR]NETCONFIG.COMg [SYSMGR]STARTNET.COM [SYSUPD]NETCONFIG_UPDATE.COM< [000000]DEC-VAXVMS-DECNET_PHASE_IV-V0702--1.PCSI$DESCRIPTION  e End of listr  q -- o David J. Dachteran dba DJE Systemst http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/t   ------------------------------  % Date: Mon, 06 May 2002 07:52:51 +0200y From: Dirk Munk <munk@home.nl>8 Subject: Re: ZIPped .PCSI container arrives OK on VMS???& Message-ID: <3CD61A33.2070809@home.nl>   Paul Sture wrote:nY > In article <3CD30061.3416057D@Free.fr>, Didier Morandi <Didier.Morandi@Free.fr> writes:  > R >>Could someone explain to me why a Backup saveset sent via the Internet has to beR >>reset under VMS (via the reset_backup_saveset_attributes.com procedure availableQ >>from the VMS freeware CD) and not a .PCSI container zipped on an Alpha, UNZIPedt" >>on my Mac and FTPed to my Alpha? >> >  > N > Neither UNZIP nor the RUN command (for self-extracting files) appear to care! > much about the file attributes.   G If a file has been zipped on VMS, and the VMS qualifier has been used, :G then you will get the original file attributes when you unzip the file b5 on VMS. A self-extracting .exe file will do the same.o     > O > BACKUP does care. Also note that CHECKSUM givies the wrong answer if the file1- > downloaded is not of the format it expects.  >  > Paul   ------------------------------   End of INFO-VAX 2002.249 ************************   Layered Product  j  Do you want to continue? [YES] y   I -------------------------------------------------------------------------w Files in@ _DJAS01$DKA0:[DDACHTERA]DEC-VAXVMS-DECNET_PHASE_IV-V0702--1.PCSII -------------------------------------------------------------------------S  M4 [000000]DEC-VAXVMS-DECNET_PHASE_IV-V0702--1.PCSI$TLB [SYS$LDR]NDDRIVER.EXEo [SYS$LDR]NETDRIVER.EXE! [SYS$LDR]SYS$NETWORK_SERVICES.EXEe [SYSEXE]NCP.EXE  [SYSEXE]NET$NAME_SERVER.EXEs [SYSey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    ey    