1 INFO-VAX	Fri, 11 Aug 2006	Volume 2006 : Issue 445       Contents: Re: Alpha remembrance day  Re: Alpha remembrance day  Re: CFD - software RE: CFD - software Re: CFD - software% Re: Clients using a GUI to access FTP % Re: Clients using a GUI to access FTP % Re: Clients using a GUI to access FTP % Re: Clients using a GUI to access FTP % Re: Clients using a GUI to access FTP % Re: Clients using a GUI to access FTP % Re: Clients using a GUI to access FTP % Re: Clients using a GUI to access FTP % Re: Clients using a GUI to access FTP % Re: Clients using a GUI to access FTP % Re: Clients using a GUI to access FTP % Re: Clients using a GUI to access FTP % Re: Clients using a GUI to access FTP % Re: Clients using a GUI to access FTP % Re: Clients using a GUI to access FTP   Re: DECnet-IV strangeness in NCP  Re: DECnet-IV strangeness in NCP Re: Enabling SMTP in VAX/VMS# Re: HP Test Drive sub-network dead? & Re: LAT to SSH(or Telnet even) tunnel?& Re: LAT to SSH(or Telnet even) tunnel?& Re: LAT to SSH(or Telnet even) tunnel?& Re: LAT to SSH(or Telnet even) tunnel?! Re: TCPIP$TELNETSYM_SYSTARTUP.COM - Re: VMS 7.3 vs 8.x - java in HTML files, Hmm.   F ----------------------------------------------------------------------    Date: 11 Aug 2006 05:24:08 -0700 From: etmsreec@yahoo.co.uk" Subject: Re: Alpha remembrance dayB Message-ID: <1155299048.027589.230250@74g2000cwt.googlegroups.com>   Agreed Mike.  = Plus, I guess the VAX 9000 and the Alpha did kill Digital.  I E understand there were only about 425 VAX 9000 systems sold.  Not very 0 many considering the R&D that must have gone on.   Steve    flatts1 wrote: > Hello, > I > It has been about 5 years since I have done any meanifngful work on VMS I > (Vax or Alpha).  Interestingly, this discussion is centered around that I > timeframe and the events preceeding it.  The last version of VMS that I ! > worked on was 7.1, as I recall.  > G > It has probably been almost equally as long since I have visited this F > newsgroup.  This morning, for old time's sake, I decided to see whatG > was going on in VMS land these days and this thread really picqued my  > interest.  > H > When I virtually stopped working on VMS, I would say that I was at theE > top of my game while supporting VMS and UNIX at about 80/20 percent I > respecively.  I used to joke to folks that I could probably forget more H > about VMS than I would ever learn about UNIX.  I'm rethinking that nowH > that I wave been working on Solaris/Windows since (about 70/30 percent > respectively). > H > I thank JF Mezie for initiating this thread.  While on the one hand itE > is depressing, it is also bringing back some very good memories and 5 > experiences that I have had in the "good old days".  > I > While it might appear that there has been some rigorous disagreement on I > this topic, I think folks actually agree with each other more than they E > don't.  In other words, I think folks tend to agree on the numerous F > tactical and strategic misteps that occured along the way with AlphaG > and VMS.  The disagreement seems to lay in pointing the finger at who  > is responsible.  > G > Regardless, I think it is just sad that DEC never could get their act H > together which resulted in everyone else's OS reinventing the wheel toG > become as robust as VMS was (is) on such things as clustering, system = > auditing, system accounting, etc.  Yes, you too can build a F > blisteringly fast OS if you don't have to worry about all that fancy* > overhead with each image activation :-). >  > C > Throughout this discussion, I think Andrew nailed it best with...  > * > ======================================== > Andrew wrote:  > G > The sad reality is that Alphas woes and eventual demise may have been F > exacerbated or at least allowed to get worse by Palmer/Curly etc but@ > the seeds for Alphas decline were sown by DEC and their seniorF > management in the 80's before any of your favourite culprits were in > the frame.* > ======================================== >  > 
 > And also...  >  > * > ======================================== > Andrew wrote:  > E > 4. DEC started out as an alternative to IBM but ended up becoming a C > mini IBM without the deep pockets or market share. DEC history is F > littered with strategies that apparently had nothing to do with whatF > customers were asking for and everything to do with what DEC thought > customers wanted. * > ======================================== > F > This last excerpt is so true.  Even after Compaq bought DEC, it tookC > them forever to rename all of the DECthis and DECthat proprietary H > verbiage.  The DECnet Phase V example was excellent and I'll mention aG > few more examples on where DEC missed the boat and/or just didn't get  > it.  >  > A > - DCL:  One shell and only one shell - and it could only handle @ > integers.  While a great "command" language with great lexicalI > functions, it had nothing on the native UNIX shells that supported real ! > number processing, arrays, etc.  > A > - DSSI:  Aptly a four letter word.  The first time I saw a SCSI F > connection on a DEC computer was on one of the first Alphas.  It wasH > the very early '90s.  Around 1992 or whenever Alpha "AXP 1.5" came outE > (we were a Beta guinea pig).  The rest of the world, of course, had E > embraced SCSI much earlier.  And let's face it, DEC would have much F > preferred to still keep charging $400 for DSSI cables if they could.F > It is this type of gouging that really left a sour taste in not only: > managment's mouth but in system administrators' as well. > H > - UCX:  In any of the other Operating systems that I can think of, youF > get a network stack out of the box at no additional charge.  SomeoneI > correct me if I'm wrong but didn't DEC even charge for DECnet (and even D > the "edt" editor)?  I only installed the net-app-supp licences.  IG > never had to buy them.  Anyway, when the rest of the world was moving I > forward with free TCP/IP, DEC decided to charge it's customers for UCX. F >  I don't know about your experiences with UCX, but I think it says aF > lot when a third party vendor can create a better and cheaper TCP/IPG > interface that they don't even control the drivers to.  I'm referring A > to "Multinet" which was much easier to administer than UCX was. G > Unfortunately, it did still rely on the native UCX drivers which left I > Multinet and DEC pointing fingers at each other when something broke on  > Multinet.  > / > - PATHWORKS anyone:  I still have nightmares.  > G > - Polycenter:  This was actually a very useful suite of tools (system F > watchdog, performance analayizer, remote system managment, etc).  ItG > worked like a champ.  The support was top notch and they could really ? > speak the same language as you.  Then DEC sold it to Computer I > Associates who couldn't even spell VMS who then assimilated it to their 9 > Unicenter.  Now that was a bonehead move on DEC's part.  > E > - ALL-IN-ONE:  I don't know how this ever made DEC money.  The only H > time I ever saw it in use was when I worked at DEC and also at College! > where I presume it was donated.  > E > - Perl, Apache, and other GNU stuff:  They all had caveates when it F > came to VMS ports AND EVEN WHEN IT CAME TO THE DEC UNIX PORTS.  WhenH > DEC did finally decide to port some of these themselves, it was alwaysI > way behind their UNIX counterparts that could simply install the latest  > versions at will.  >  > * > ========================================) > Bill Todd wrote (while quoting Andrew):  > E > > 2. Having belatedly realised that VAX wasn't going to survive the G > > onslaught of the RISC processors DEC initiated the short lived MIPS I > > platform running Ultrix a plaform seriously hampered by the fact that I > > DEC had not only missed catching the RISC wave but had also failed to J > > catch the UNIX wave as well. DEC sales people prefered selling VMS/VAXH > > and senior management openly denigrated UNIX while funding a product+ > > division to develop it. Sounds mad now.  >  > F > > This lost DEC market share to Sun, HP, IBM and SGI who had no such > > qualms about selling UNIX. >  >  > @ > But (yet again) this couldn't possibly have contributed to the > *decline* C > of a product which had not even been introduced yet.  In fact, if I > anything it gave Alpha a lower starting point from which regaining lost  > E > market share might have been easier than beginning with more of it. * > ======================================== > E > I agree with Andrew.  Do you recall the book, "UNIX For DCL Users". A > This was the one from "Digital Press". Very watered down and it ) > confused folks more than informed them.  > F > Bill, much of your perspective does have merit but it is lost withinC > your bitterness in how things turned out.  C'mon, do you think we E > really care if someone makes a post with typos?  It's sad but I can I > relate.  I used to be in your shoes and I went kicking and screaming to G > UNIX/Solaris.  But I'm I over it now and I'm better for it.  You need 0 > to move on, dude.  It's best for everyone. :-) > I > Also Bill, they're not called "Legacy Systems" for nothing.  You're not D > buying a computer, you're buying into a company for the long haul.F > Andrew was right to point out all of the earlier blunders by DEC didF > little to instill confidence in Alpha or anything else down the pike > for that matter. >  > * > ======================================== > Andrew wrote:  > H > The initial Alpha sucess, replacing the VAX cluster ended in a Solaris > migration F > because the components the bank wanted simply did not exist on Alpha > for either Tru64 or OpenVMS.* > ======================================== > F > This happened EVERYWHERE and, as mentioned earlier, was probably theI > single most important factor why VMS died.  Although the decision by SW H > vendors not to port to VMS had many other underpinnings!  What good isG > all that great reliability and performance of Alpha/VMS clusters when A > the newest version of your critical app isn't available for it.  > D > I once worked for a large bank in the "Midrange Group".  They tookD > their system security very seriously.  We had comprehensive auditsF > twice a year.  On the VMS side we maintened very detailed reports ofE > VMS' auditing trails and a litany of sysgen parameters were set and F > verified.  When it came time to audit the IBM AIX systems, they justD > wanted to make sure there were no generic accounts and that strongF > passwords were used.  There were simply no functional equivilents inF > security (at the time) for the AIX boxes.  I always wondered how AIXG > even got its foot in the door there but management didn't really seem F > to care because the app they needed to run wasn't avaialable on VMS. > D > I worked at DEC for 4.63 years.  That is what it said on my layoffC > package - which meant that I was conveniently not vested (under 5 E > years).  While I was there, I saw the introduction of the VAX 9000. H > This was the one that was supposed to make or break the company.  ThenD > there was the Alpha chip.  Again, this too was supposed to make orA > break the company.  Then the sell out to Compaq and the rest is I > history.  Just another example of a great product with crappy marketing  > and management.  >  > Best, 	 > Mike F.  >  > P.S.E > Not sure if this is old hat to everyone but a DEC sales person once 6 > told me that OSF stood for "O"ppose "S"un "F"orever.   ------------------------------    Date: 11 Aug 2006 08:27:18 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayC Message-ID: <1155310038.363828.242110@p79g2000cwp.googlegroups.com>    Bill Todd wrote: > flatts1 wrote: >  > ...  > + > > Bill Todd wrote (while quoting Andrew):  > > F > >> 2. Having belatedly realised that VAX wasn't going to survive theH > >> onslaught of the RISC processors DEC initiated the short lived MIPSJ > >> platform running Ultrix a plaform seriously hampered by the fact thatJ > >> DEC had not only missed catching the RISC wave but had also failed toK > >> catch the UNIX wave as well. DEC sales people prefered selling VMS/VAX I > >> and senior management openly denigrated UNIX while funding a product , > >> division to develop it. Sounds mad now. > >  > > G > >> This lost DEC market share to Sun, HP, IBM and SGI who had no such  > >> qualms about selling UNIX.  > >  > >  > > B > > But (yet again) this couldn't possibly have contributed to the
 > > *decline* E > > of a product which had not even been introduced yet.  In fact, if K > > anything it gave Alpha a lower starting point from which regaining lost  > > G > > market share might have been easier than beginning with more of it. , > > ======================================== > >  > > I agree with Andrew. > J > Then you're as analytically-incompetent as he is:  try reading the aboveI > more carefully until you understand what it says - it's a very specific D > refutation of a very specific assertion, not some kind of nebulous2 > 'denial' that you seem to confuse it with below. >  > ...  > H > > Bill, much of your perspective does have merit but it is lost within- > > your bitterness in how things turned out.  > H > Horseshit.  My primary concern is that people who refuse to learn fromG > experience are condemned to repeat it - and that's especially true of C > the stalwarts here who in some ways are the blindest of the blind 3 > (everyone with better sight having left already).  > J > Of course, many of them have perfectly valid reasons and/or actual needsF > for having stuck with VMS:  the problem is that many of them, havingB > perpetuated this in some ways personal investment, resist seeing5 > surrounding circumstances for what they really are.  > G > So realistic evaluations of exactly how things came to be as they are F > today are important to me, and in this particular case evaluation ofF > what potential Alpha actually had and what specifically prevented itF > from realizing that potential.  To suggest that it was doomed due toF > decisions made before it even shipped, as Andrew has done, is flatlyF > contradicted by the acceptance and growth that it enjoyed during itsH > lifetime prior to being officially axed 5 years ago, *despite* for the9 > most part conspicuous lack of commitment by its owners.  >   0 Why keep repeating the same sorry tired mantra ?  E Alpha grew initially because it was new, it was quick and with things F like the VEST program it was relatively easy to move apps from VAX/VMSC to Alpha/OpenVMS. It died because the mistakes made by DEC prior to D Alpha's introduction created a climate in which it could not attractD enough software or market share to sustain it after the honeymoon of the initial introduction.   B Alpha sales initially went up to a pretty reasonable 10-12% marketA share, fell in the latter half of the 1990's to below 5% and then F started to rise. By the time Alpha did start to claw back share it wasC too late, consolidation, industry standard platforms were the watch G word, competitors like MIPS that made the Alpha share of the server and G workstation market look good were also exiting the market and ISV's had E lost their appetites for supporting loads of hardware platforms. When C you are 3rd or 4th in a market which has 5 or 6 vendors things look + much better than when you are 4th out of 4.   G The idea that Palmer killed Alpha is attractive but challenged. Palmers A mistake was in not reversing immediately some of the decisions he A inherited. Axing NT on Alpha for example which was never going to A suceed would have simplified the Alpha message to ISV's, freed up G valuable resources to do other aspects of Alpha better like the woefull F server plafroms it was shoed into it also might have saved All in One.E Without the carrot of NT/Alpha platform sales to host Exchange etc it , is doubtfull that DEC would have dropped it.  C But by the time Palmer took over the reins Alpha was allready being G touted as the Intel replacement the plafrom for all, the Hudson fab was @ built and running and Alpha was a late processor whose only real selling point was its speed.  C The history of computing is littered with failed CPU's that were as E fast or faster than the competition but which had no strenghts in any @ other dimension. Alpha was no different  just the most prominent example.  E Don't let the fact that other people understand this perfectly get in ( the way of your incomprehension though.      regards  Andrew Harrison    ------------------------------  % Date: Fri, 11 Aug 2006 07:51:12 -0400 3 From: "Richard B. Gilbert" <rgilbert88@comcast.net>  Subject: Re: CFD - software : Message-ID: <JI-dnVZ9Rqmu8kHZnZ2dnUVZ_smdnZ2d@comcast.com>   BRANDON, JOHN M wrote:  $ > CFD (Computational Fluid Dynamics) > + > We are looking to analyze our datacenter.  > D > Anyone have or know of CDF software that will allow us to do that? >  >  >  > John "REBOOT" Brandon  > VMS Systems Administrator , > firstname.lastname.spam.me.not@dalsemi.com  F The last time I encountered CFD (Princeton University, 1994) it was a H black art and there was no commercial software to speak of.  It was all C research.  Turbulent flows are governed by a truly hairy system of  E coupled, non-linear, differential equations called the Navier-Stokes  I equations.  Solving the Navier-Stokes equations for any non-trivial case  C requires far more computing power than was available in those days.   I You might want to contact Professor Daniel Mark Nosenchuck at Princeton.  I He would probably be aware of any commercial CFD software that might now   exist.   ------------------------------  % Date: Fri, 11 Aug 2006 08:28:42 -0400 # From: "Dan Allen" <dallen@nist.gov>  Subject: RE: CFD - software : Message-ID: <JFEPKAPBPMDFDBOIANGDEENCHLAA.dallen@nist.gov>   >  > BRANDON, JOHN M wrote: > & > > CFD (Computational Fluid Dynamics) > > - > > We are looking to analyze our datacenter.  > > F > > Anyone have or know of CDF software that will allow us to do that? > >  > >  > >  > > John "REBOOT" Brandon  > > VMS Systems Administrator . > > firstname.lastname.spam.me.not@dalsemi.com > G > The last time I encountered CFD (Princeton University, 1994) it was a I > black art and there was no commercial software to speak of.  It was all D > research.  Turbulent flows are governed by a truly hairy system ofF > coupled, non-linear, differential equations called the Navier-StokesJ > equations.  Solving the Navier-Stokes equations for any non-trivial caseE > requires far more computing power than was available in those days.  > J > You might want to contact Professor Daniel Mark Nosenchuck at Princeton.J > He would probably be aware of any commercial CFD software that might now > exist.  M The Hydromechanics group at my old place of employment with the Navy has been L heavily involved in this area for decades. The two names that popped up in aK brief fact finding phone call to an old collegue who helps administer their P computing center were Fluent and CFD++. He gave me Wesley.M.Wilson@navy.mil as aN possible source of additional info. I'm sure the folks there are very familiar8 with lots of commercial and academic codes in this area.   HTH,   Dan    ------------------------------  % Date: Fri, 11 Aug 2006 05:52:34 -0700 * From: "Tom Linden" <tom@kednos-remove.com> Subject: Re: CFD - software ) Message-ID: <op.td4d1wj9tte90l@hyrrokkin>   8 On Fri, 11 Aug 2006 04:51:12 -0700, Richard B. Gilbert   <rgilbert88@comcast.net> wrote:    > BRANDON, JOHN M wrote: > % >> CFD (Computational Fluid Dynamics) - >>  We are looking to analyze our datacenter. F >>  Anyone have or know of CDF software that will allow us to do that? >>    John "REBOOT" Brandon  >> VMS Systems Administrator- >> firstname.lastname.spam.me.not@dalsemi.com  > I > The last time I encountered CFD (Princeton University, 1994) it was a   K > black art and there was no commercial software to speak of.  It was all   F > research.  Turbulent flows are governed by a truly hairy system of  H > coupled, non-linear, differential equations called the Navier-Stokes  L > equations.  Solving the Navier-Stokes equations for any non-trivial case  E > requires far more computing power than was available in those days.   I Actually they are linear and yes it takes a fair amount of power to solve F them numerically,  We did this at Boeing in the late 60's on a CDC6600J and created film loops of the output on a Stromberg Carlson 35mm microfilm6 Of course we were limited in the fineness of the grid.- BTW, the equations were first derived in 1822   D John,  why do you need CFD to analyze the computer center,  if it isI airflow, temp and humidity  there are plenty of programs out there I am    sure.    > L > You might want to contact Professor Daniel Mark Nosenchuck at Princeton.  L > He would probably be aware of any commercial CFD software that might now   > exist.       --  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Fri, 11 Aug 2006 05:04:43 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> . Subject: Re: Clients using a GUI to access FTP, Message-ID: <44DC482A.6304E346@teksavvy.com>   "Steven M. Schweda" wrote:C >    I don't need any convincing on these points.  But none of it's G > particularly relevant to the original question.  The UNIX "ls" format ( > doesn't need to be good to be popular.  B The RFCs have always been clear that the output from "LIST" is not- computer parsable, and the output of NLST is.   A Microsoft still chose to use LIST  *and* try to parse the output.   G Perhaps they need to change the RFC to accomodate Microsoft software so H that LIST produces a "readable" format that is well defined (directoriesJ sepatated by "/" and a data/size fields in specific positions and formats.    F Then, VMS engineers could update the FTP server to produce such output from a LIST command.  F But until the format of the LIST command output is defined in the RFC,% what should VMS really change it to ?    ------------------------------   Date: 11 Aug 2006 11:15:16 GMT( From: bill@cs.uofs.edu (Bill Gunshannon). Subject: Re: Clients using a GUI to access FTP+ Message-ID: <4k3764Fab6avU1@individual.net>   3 In article <2z3xASIqK9Kt@eisner.encompasserve.org>, ! 	briggs@encompasserve.org writes: X > In article <4k0vudF9v06bU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:4 >> In article <1QGCg.1833$lL6.724@news.cpqcorp.net>,2 >> 	Hoff Hoffman <hoff-remove-this@hp.com> writes:J >>>    And as for mapping OpenVMS names into Unix names (or the other way K >>> 'round), there are a gazillion obvious filename translations, and some  L >>> really ugly ones.  What's ., after all?  The corner cases are enough to ( >>> drive any sane engineer up the wall. >>  K >> I wouldn't suggest mapping VMS names to Unix names.  Why would you?  All J >> your VMS names are legitimate Unix names any way (even with the ";13").I >> If the VMS directory doesn't contain a entry called "." you just don't 7 >> include one.  "ls" doesn't even though there is one.  > < > Because if you're copying a directory full of default-case; > VMS filenames (uppercase) onto a Unix directory, a useful ; > expectation is that you will end up with a Unix directory 2 > full of default-case Unix filenames (lowercase).  B Only if you assume that there is a "default case" for filenames.  E I have lot's of files on my Unix systems that are in capital letters. D Uppercase isn't necessarily the default case on VMS, it just happensG to be the only one they choose to use.  And Unix doesn't have a default H case.  Most files are created as lowercase because that is they way they were typed.    > B > And because this is the inverse of the mapping that is performedI > if you take a directory full of default-case Unix filenames (lowercase) > > and put them into a directory full of only-possible-case VMS > filenames (uppercase). > # > Invertible mappings are goodness.   B Or, don't map them at all.  Leave them exactly as they really are.   > 7 > So the uppercase to lowercase translation is a given.    Sorry, I don't agree.    > D > But this means that you now need an escape convention for encoding' > upper and mixed case Unix filenames.    E That already exists, how do you think they handle NFS mounting a Unix E directory on a VMS system?  But it is also irrelevant to the original F problem which was displaying a VMS directory in IE.  The whole problemC with doing that has to do with the format in which the directory is E sent from the server and has nothing to do with the case of the file- C names.  If people want the names remapped into lowercase, that is a C totally different problem.  (A rather trivial one, but another just 
 the same.)   ? >                                      And this then means that @ > filenames that happen to match that escape convention can't beC > mapped directly into Unix filenames.  They need to be de-escaped.   G I think you are making this a lot harder than it really is.  As I said, F the mapping problem has been solved a long time ago but doesn't relate to the original problem.   > @ > You are in a maze of twisty passages, all different.  The good< > choices are not obvious.   And the obvious choices are not > good.   $ WWWUWW and your outof the maze.  :-)   > G >> Again, I don't think that is the problem.  There is nothing in a VMS K >> filename that is not valid in a Unix filename so no re-mapping of actual  >> names would be needed.  > ( > Again, you haven't thought it through.  	 Whatever.    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: 11 Aug 2006 11:37:09 GMT( From: bill@cs.uofs.edu (Bill Gunshannon). Subject: Re: Clients using a GUI to access FTP+ Message-ID: <4k38f5Fab6avU2@individual.net>   , In article <HETCg.69077$gU4.62731@trnddc07>,# 	John Santos <john@egh.com> writes:  > F > It *is* asking for a human-readable list of files.  That's what LISTF > does: produce a human-readable list of files.  (MS IE may not *want*H > an HRLoF, but that's all that is available, so that's what it asks for > and that's what it gets.)   H True, he mis-stated it.  :-)   All the directory listing provided by FTPN Servers are human readable.  And we damn humans are just too damned adaptable.H We can interpret a Unix style list or a VMS style list.  Computers are aH bit dumber.  They pretty much have to be told what the formats are goingH to look like beforehand.  There are actually two ways to make this work.G You can make VMS deliver the directory in a format that FTP Clients can H interpret or you can change all the clients to understand the VMS formatH as well as the Unix format.  Considering VMS's relevance in the industryA today, which do you think is the better (and more likely) choice?    >  > G > More so than the Unix ls listing...  What's with listing the filename 	 > last?     F Why not?  Humans have this strange ability to recognize it wherever itD falls in the line.  And the listing is intended to be human readableE (although there have been many succesful programs that interpret it.)   H >        The weird stuff with spacing when the size gets big?  (ProbablyF > a day-one bug that has been faithfully preserved for over 30 years.)  E Of course it is.  Hind-sight is always 20-20.  How many people do you C think there were in the early 70's who thought that disks (and thus E files) would ever be as big as they are today?  And once done, it can E be very hard to change without breaking an awful lot of existing art.     $ > The weird way dates are displayed?   What's wierd about the dates?    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: 11 Aug 2006 11:58:11 GMT( From: bill@cs.uofs.edu (Bill Gunshannon). Subject: Re: Clients using a GUI to access FTP+ Message-ID: <4k39mjFachfaU1@individual.net>   , In article <44DC482A.6304E346@teksavvy.com>,0 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > "Steven M. Schweda" wrote:D >>    I don't need any convincing on these points.  But none of it'sH >> particularly relevant to the original question.  The UNIX "ls" format) >> doesn't need to be good to be popular.  > D > The RFCs have always been clear that the output from "LIST" is not/ > computer parsable, and the output of NLST is.  > C > Microsoft still chose to use LIST  *and* try to parse the output.   ( Nothing in the RFC that says they can't.   > I > Perhaps they need to change the RFC to accomodate Microsoft software so J > that LIST produces a "readable" format that is well defined (directoriesL > sepatated by "/" and a data/size fields in specific positions and formats.  H What does the RFC have to do with it?  The RFC is quite clear and works.I If the Clients/Servers choose to do things in ways that while obeying the H RFC are incompatable with each other, so be it.  This is not a universalI problem that needs to be addressed by the IETF.  It is a problem that the I Client/Server writers need to deal with.  In every case I know of but VMS G this is not a problem.  So, who needs to adapt to fix the problem?  VMS E doesn't have to do anything, but then they should not say "IE does it H wrong."  There are standards and then there are de-facto standards.  YouG can choose to ignore the de-facto ones if you wish, but then you should / not be surprised when the industry ignores you.    > H > Then, VMS engineers could update the FTP server to produce such output > from a LIST command.  G While many will not agree, this is the real (and most logical) solution  to this problem.   > H > But until the format of the LIST command output is defined in the RFC,' > what should VMS really change it to ?   H This is not an RFC problem.  This is a Client/Server interaction problemE totally outside the scope of the RFC's and the IETF.  What VMS should D change it to is really rather obvious.  If it wishes to have clientsG work with it it needs to mimic the output of the other systems which is # what the Clients expect to receive.   J Just out of curiosity, a question for the guys from Process (although theyH may have to find someone who actually knows the answer!)  You have an IPF stack for RSX.  That is probably the closest thing to VMS still in use# today.  What format does it output?    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: 11 Aug 2006 07:32:11 -0500 From: briggs@encompasserve.org. Subject: Re: Clients using a GUI to access FTP3 Message-ID: <G2$PqH5TtXoY@eisner.encompasserve.org>   _ In article <06081016455853_2027FAC5@antinode.org>, sms@antinode.org (Steven M. Schweda) writes:   > From: briggs@encompasserve.org > = >> Because if you're copying a directory full of default-case < >> VMS filenames (uppercase) onto a Unix directory, a useful< >> expectation is that you will end up with a Unix directory3 >> full of default-case Unix filenames (lowercase).  >>  C >> And because this is the inverse of the mapping that is performed J >> if you take a directory full of default-case Unix filenames (lowercase)? >> and put them into a directory full of only-possible-case VMS  >> filenames (uppercase).  > . >    This is not true for an ODS5 file system.  
 Of course.   > $ >> Invertible mappings are goodness. >>  8 >> So the uppercase to lowercase translation is a given. > F >    It may be for an ODS2 file syatem.  I see no particular reason to: > mess with the case of file names on an ODS5 file system.  1 I don't know enough to disagree with you on that.   E >> But this means that you now need an escape convention for encoding A >> upper and mixed case Unix filenames.  And this then means that A >> filenames that happen to match that escape convention can't be D >> mapped directly into Unix filenames.  They need to be de-escaped. > E >    Why?  We were discussing a VMS FTP server.  Why should a VMS FTP I > server try to overcome any ODS2 file system limitations (other than the 2 > conversion of all-upper-case to all-lower-case)?  H I did not take the position that a VMS FTP server should try to overcomeC ODS2 file system limitations other than the conversion of all upper  case to all lower case.   < Why do you expect me to support a claim that I did not make?    A I don't know that ODS2 has any significant limitations beyond the E limited character set for file names and the limitation on the number C of dots in a file name.  [The limitation on the number of dots is a C strong argument for a file name mapping function in its own right].   G The directory listing format isn't a limitation of ODS2.  The directory - naming convention isn't a limitation of ODS2.   ? >    And what does any of this have to do with a UNIX-ls-format G > presentation of the LIST results as opposed to a VMS-DIRECTORY-format  > presentation thereof?    Nothing.  D I was responding to the claim that no file name mapping function was required.     J >    The original complaint was that MSIE can't cope with the existing VMSH > TCPIP FTP server.  The case of file names is a secondary considerationA > compared with complete disfunctionality.  Or so it seems to me.   D Absolutely correct.  But the more recent claim was that no file name@ mapping function was required.  And that is the claim that I was responding to.    D If you insist on a response to the original thread topic rather thanB the topic at hand then I'll feed you the following obvious truths:  3 o IE is brain dead for using the LIST format output <   and then not doing the job right.  A host of competing FTP>   clients are an existence proof that it is possible to do the=   job better.  (And a proof that doing the job better doesn't 0   mean much when you're dealing with Microsoft).  8 o UCX is brain dead for not providing an FTP server that<   measures up to the standard of the other vendors who offerB   FTP servers for VMS machines.  Yes, there are serious challengesA   in doing this job "right", but HGFTP is an existence proof that &   it is possible to do the job better.   ------------------------------    Date: 11 Aug 2006 07:51:48 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) . Subject: Re: Clients using a GUI to access FTP3 Message-ID: <hPKhQPqt5ObG@eisner.encompasserve.org>   V In article <4k0onjF7u30rU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > G > How do they differ?  "ls" returns a simple list of filenames in both. G > "ls -l" returns; file modes, number of links, owner, group, filesize, " > last modified time and filename.  D    On BSD systems I've used "ls -l" included the group number unlessH    -g was used to exclude it.  On SVID systems I've used "ls -l" omitted1    the group number unless -g was used to add it.   E    The output I generally see from a UNIX FTP server for a LIST is in A    the format of "ls -l".  I haven't paid attention to whether it     tends to include the group.   ------------------------------    Date: 11 Aug 2006 07:54:24 -0500 From: briggs@encompasserve.org. Subject: Re: Clients using a GUI to access FTP3 Message-ID: <wO2rM6Qbvolh@eisner.encompasserve.org>   V In article <4k3764Fab6avU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:5 > In article <2z3xASIqK9Kt@eisner.encompasserve.org>, # > 	briggs@encompasserve.org writes: Y >> In article <4k0vudF9v06bU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: 5 >>> In article <1QGCg.1833$lL6.724@news.cpqcorp.net>, 3 >>> 	Hoff Hoffman <hoff-remove-this@hp.com> writes: K >>>>    And as for mapping OpenVMS names into Unix names (or the other way  L >>>> 'round), there are a gazillion obvious filename translations, and some M >>>> really ugly ones.  What's ., after all?  The corner cases are enough to  ) >>>> drive any sane engineer up the wall.  >>> L >>> I wouldn't suggest mapping VMS names to Unix names.  Why would you?  AllK >>> your VMS names are legitimate Unix names any way (even with the ";13"). J >>> If the VMS directory doesn't contain a entry called "." you just don't8 >>> include one.  "ls" doesn't even though there is one. >>  = >> Because if you're copying a directory full of default-case < >> VMS filenames (uppercase) onto a Unix directory, a useful< >> expectation is that you will end up with a Unix directory3 >> full of default-case Unix filenames (lowercase).  > D > Only if you assume that there is a "default case" for filenames.  G > I have lot's of files on my Unix systems that are in capital letters. F > Uppercase isn't necessarily the default case on VMS, it just happensI > to be the only one they choose to use.  And Unix doesn't have a default J > case.  Most files are created as lowercase because that is they way they
 > were typed.   G Don't be stupid.  Essentially all [ODS2] VMS file names are upper case. @ A significant majority (95+%) of Unix file names are lower case.   >  >>  C >> And because this is the inverse of the mapping that is performed J >> if you take a directory full of default-case Unix filenames (lowercase)? >> and put them into a directory full of only-possible-case VMS  >> filenames (uppercase).  >>  $ >> Invertible mappings are goodness. > D > Or, don't map them at all.  Leave them exactly as they really are.  ! So it is your devout wish to see:    ftp> put foo.tar.gz / 550 %RMS-F-SYN, file specification syntax error   8 >> So the uppercase to lowercase translation is a given. >  > Sorry, I don't agree.   C Sorry, you still haven't shown any evidence of thinking it through.   E >> But this means that you now need an escape convention for encoding ( >> upper and mixed case Unix filenames.  > G > That already exists, how do you think they handle NFS mounting a Unix  > directory on a VMS system?  ? Just a minute ago you wanted to display the file names "as is". ; Now you want to display them subject to a mapping function.    Which is it?    + > But it is also irrelevant to the original H > problem which was displaying a VMS directory in IE.  The whole problemE > with doing that has to do with the format in which the directory is G > sent from the server and has nothing to do with the case of the file-  > names.  G The file names appear in the directory listing you utter nincompoop!!!!   = > If people want the names remapped into lowercase, that is a E > totally different problem.  (A rather trivial one, but another just  > the same.)  > If you have a file name mapping convention then the names thatA you present should be the mapped names, not the VMS native names.    Think it through.    >   @ >>                                      And this then means thatA >> filenames that happen to match that escape convention can't be D >> mapped directly into Unix filenames.  They need to be de-escaped. > I > I think you are making this a lot harder than it really is.  As I said, H > the mapping problem has been solved a long time ago but doesn't relate > to the original problem.  ) And you still haven't thought it through.   A >> You are in a maze of twisty passages, all different.  The good = >> choices are not obvious.   And the obvious choices are not  >> good. > & > WWWUWW and your outof the maze.  :-)  8 Nope.  The problem is far more complex than you suspect.  H >>> Again, I don't think that is the problem.  There is nothing in a VMSL >>> filename that is not valid in a Unix filename so no re-mapping of actual >>> names would be needed. >>  ) >> Again, you haven't thought it through.  >  > Whatever.   J Further evidence that you haven't thought it through and do not intend to.   ------------------------------    Date: 11 Aug 2006 07:56:23 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) . Subject: Re: Clients using a GUI to access FTP3 Message-ID: <FHQ16jPKs1hY@eisner.encompasserve.org>   \ In article <44DBF080.6027F611@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > Hoff Hoffman wrote: J >>    Yes, I'd like to see a way for Microsoft and TCP/IP Services to playI >> together better here, but then I also gave up on Internet Explorer and 1 >> have been using Mozilla Firefox for eons now.   >  > I > You are part of HP. HP is Microsoft's first or second biggest customer. I > Shirley HP would have some weight on Microsoft to get their software to E > abide by standards used by HP products when those standards are the  > "official" ones ?   
    ROTFLOL   ------------------------------    Date: 11 Aug 2006 07:59:32 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) . Subject: Re: Clients using a GUI to access FTP3 Message-ID: <z7ej68Oeb0Ng@eisner.encompasserve.org>   _ In article <06081022534073_2027FAC5@antinode.org>, sms@antinode.org (Steven M. Schweda) writes:  > H >    I don't think that Microsoft is asking for a human-readable list of	 > files.    D    Microsoft IE is using the LIST command which the RFC specificallyH    states is human readable and may be difficult to parse automatically.  G    If IE would use NLST instead, then Microsoft would not be asking for "    a human readable list of files.   ------------------------------  + Date: Fri, 11 Aug 2006 08:03:21 -0500 (CDT) * From: sms@antinode.org (Steven M. Schweda). Subject: Re: Clients using a GUI to access FTP2 Message-ID: <06081108032165_2027FAC5@antinode.org>  - From: JF Mezei <jfmezei.spamnot@teksavvy.com>   D > The RFCs have always been clear that the output from "LIST" is not/ > computer parsable, and the output of NLST is.  > C > Microsoft still chose to use LIST  *and* try to parse the output.       If that's all there is, ...  I > Perhaps they need to change the RFC to accomodate Microsoft software so J > that LIST produces a "readable" format that is well defined (directoriesL > sepatated by "/" and a data/size fields in specific positions and formats. > H > Then, VMS engineers could update the FTP server to produce such output > from a LIST command. > H > But until the format of the LIST command output is defined in the RFC,' > what should VMS really change it to ?   H    When it comes to density, some folks can make osmium look like cotton candy.  H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------    Date: 11 Aug 2006 08:10:09 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) . Subject: Re: Clients using a GUI to access FTP3 Message-ID: <LBqA2g0YvF6k@eisner.encompasserve.org>   V In article <4k38f5Fab6avU2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >  > What's wierd about the dates?   E    ls -l tends to display the year for last year's files and the time F    for this year's files.  I've never been happy with that, as well asC    trying to determine whether it was really this year vs. older or     one year old vs. newer.  F    Which means if you repeat ls -l on a static collection of files the    output can change.    ------------------------------   Date: 11 Aug 2006 13:42:32 GMT( From: bill@cs.uofs.edu (Bill Gunshannon). Subject: Re: Clients using a GUI to access FTP+ Message-ID: <4k3fq7Fa86dgU1@individual.net>   3 In article <wO2rM6Qbvolh@eisner.encompasserve.org>, ! 	briggs@encompasserve.org writes: X > In article <4k3764Fab6avU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:6 >> In article <2z3xASIqK9Kt@eisner.encompasserve.org>,$ >> 	briggs@encompasserve.org writes:Z >>> In article <4k0vudF9v06bU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:6 >>>> In article <1QGCg.1833$lL6.724@news.cpqcorp.net>,4 >>>> 	Hoff Hoffman <hoff-remove-this@hp.com> writes:L >>>>>    And as for mapping OpenVMS names into Unix names (or the other way M >>>>> 'round), there are a gazillion obvious filename translations, and some  N >>>>> really ugly ones.  What's ., after all?  The corner cases are enough to * >>>>> drive any sane engineer up the wall. >>>>  M >>>> I wouldn't suggest mapping VMS names to Unix names.  Why would you?  All L >>>> your VMS names are legitimate Unix names any way (even with the ";13").K >>>> If the VMS directory doesn't contain a entry called "." you just don't 9 >>>> include one.  "ls" doesn't even though there is one.  >>> > >>> Because if you're copying a directory full of default-case= >>> VMS filenames (uppercase) onto a Unix directory, a useful = >>> expectation is that you will end up with a Unix directory 4 >>> full of default-case Unix filenames (lowercase). >>  E >> Only if you assume that there is a "default case" for filenames.   H >> I have lot's of files on my Unix systems that are in capital letters.G >> Uppercase isn't necessarily the default case on VMS, it just happens J >> to be the only one they choose to use.  And Unix doesn't have a defaultK >> case.  Most files are created as lowercase because that is they way they  >> were typed. > I > Don't be stupid.  Essentially all [ODS2] VMS file names are upper case. B > A significant majority (95+%) of Unix file names are lower case.  G SWell, if it's time to start the insults, I should probably just let it 
 drop, but....   L All [ODS2] VMS are not really uppercase.  They are monocase.  I can type theK name in lowercase and the system will find it. (as opposed to Unix which is I case-significant so that if I type "this.file" and the name on the system C is "THIS.FILE" they will not match.)  And the reason "A significant I majority (95+%) of Unix file names are lower case" is because most people G work with their Caps-Lock off and so they type in lowercase by default. J It really has nothing to do with Unix or it's filesystem.  Oh yeah, I justI checked and my number is 85%.  15% of the files in my home directory here ; at work contain at least one upercase letter in their name.    >  >>   >>> D >>> And because this is the inverse of the mapping that is performedK >>> if you take a directory full of default-case Unix filenames (lowercase) @ >>> and put them into a directory full of only-possible-case VMS >>> filenames (uppercase). >>> % >>> Invertible mappings are goodness.  >>  E >> Or, don't map them at all.  Leave them exactly as they really are.  > # > So it is your devout wish to see:  >  > ftp> put foo.tar.gz 1 > 550 %RMS-F-SYN, file specification syntax error   K Hardly devout, but yes.  If the filesystem can not handle the name then the & user should change it, not the system. ftp> put foo.tar.gz foo.tgz  or ftp> put foo.tar.gz foo-tar.gz  F Probably better than having the system re-map it for you and then whenC you go looking for foo.tar.gz on the other system you can't find it I because it is now $F$O$O$+$T$A$R.$G$Z (just one of the convoluted mapping > schemes I actually remember from the days of DOS and PCTCP :-)  H BUt, again, this is not generic to the discussion at hand which was IE'sD inability to deal with the directory listing format returned by VMS.   > 9 >>> So the uppercase to lowercase translation is a given.  >>   >> Sorry, I don't agree. > E > Sorry, you still haven't shown any evidence of thinking it through.  > F >>> But this means that you now need an escape convention for encoding) >>> upper and mixed case Unix filenames.   >>  H >> That already exists, how do you think they handle NFS mounting a Unix >> directory on a VMS system?  > A > Just a minute ago you wanted to display the file names "as is". = > Now you want to display them subject to a mapping function.  >  > Which is it?  F I don't want to, I just said if the mapping was truly necessary it had already been addressed.    >  > , >> But it is also irrelevant to the originalI >> problem which was displaying a VMS directory in IE.  The whole problem F >> with doing that has to do with the format in which the directory isH >> sent from the server and has nothing to do with the case of the file-	 >> names.  > I > The file names appear in the directory listing you utter nincompoop!!!!   	 Plonk....    > > >> If people want the names remapped into lowercase, that is aF >> totally different problem.  (A rather trivial one, but another just
 >> the same.)  > @ > If you have a file name mapping convention then the names thatC > you present should be the mapped names, not the VMS native names.  >  > Think it through.  >  >>  A >>>                                      And this then means that B >>> filenames that happen to match that escape convention can't beE >>> mapped directly into Unix filenames.  They need to be de-escaped.  >>  J >> I think you are making this a lot harder than it really is.  As I said,I >> the mapping problem has been solved a long time ago but doesn't relate  >> to the original problem.  > + > And you still haven't thought it through.  > B >>> You are in a maze of twisty passages, all different.  The good> >>> choices are not obvious.   And the obvious choices are not	 >>> good.  >>  ' >> WWWUWW and your outof the maze.  :-)  > : > Nope.  The problem is far more complex than you suspect. > I >>>> Again, I don't think that is the problem.  There is nothing in a VMS M >>>> filename that is not valid in a Unix filename so no re-mapping of actual  >>>> names would be needed.  >>> * >>> Again, you haven't thought it through. >>   >> Whatever. > L > Further evidence that you haven't thought it through and do not intend to.   --  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: 11 Aug 2006 13:45:49 GMT( From: bill@cs.uofs.edu (Bill Gunshannon). Subject: Re: Clients using a GUI to access FTP+ Message-ID: <4k3g0dFa86dgU2@individual.net>   3 In article <hPKhQPqt5ObG@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:X > In article <4k0onjF7u30rU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >>  H >> How do they differ?  "ls" returns a simple list of filenames in both.H >> "ls -l" returns; file modes, number of links, owner, group, filesize,# >> last modified time and filename.  > F >    On BSD systems I've used "ls -l" included the group number unlessJ >    -g was used to exclude it.  On SVID systems I've used "ls -l" omitted3 >    the group number unless -g was used to add it.   H Well, I actually looked in an old SYSV manual here because it had been aJ long time since I used a pure SYSV machine and the description for "ls -l"? included the group.  I can type it in if you don't believe me.     > G >    The output I generally see from a UNIX FTP server for a LIST is in C >    the format of "ls -l".  I haven't paid attention to whether it   >    tends to include the group.  G It would as Unix FTP Servers use the "ls -l" command and then just pipe 0 the output into a newly created ftp-data socket.   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: 11 Aug 2006 13:55:08 GMT( From: bill@cs.uofs.edu (Bill Gunshannon). Subject: Re: Clients using a GUI to access FTP+ Message-ID: <4k3ghsFa86dgU3@individual.net>   3 In article <LBqA2g0YvF6k@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:X > In article <4k38f5Fab6avU2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >>    >> What's wierd about the dates? > G >    ls -l tends to display the year for last year's files and the time H >    for this year's files.  I've never been happy with that, as well asE >    trying to determine whether it was really this year vs. older or  >    one year old vs. newer.  H I guess it's just another case of differing philosophy. I understand theH reasoning behind the way it is done, but then I have been using Unix for a long time.  H For more current files the time may be of significance.  For a file thatG is already a year old, the actual time of day probably is not nearly as G significant.  Had to make the cut-off somewhere and I guess one year is ' as good (and practical) a place as any.    > H >    Which means if you repeat ls -l on a static collection of files the >    output can change.   E That is, of course true, but then how often would you do that?  Maybe F more often now than originally as ls now seems to include a "T" option which prints the entire date: E -rw-------   1 bill  120      213909 Oct 25 22:30:21 1999 xxdp.tar.gz    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: Fri, 11 Aug 2006 13:46:45 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk. Subject: Re: Clients using a GUI to access FTP, Message-ID: <ebi1o5$gta$1@south.jnrs.ja.net>  T In article <wO2rM6Qbvolh@eisner.encompasserve.org>, briggs@encompasserve.org writes:W >In article <4k3764Fab6avU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: 6 >> In article <2z3xASIqK9Kt@eisner.encompasserve.org>,$ >> 	briggs@encompasserve.org writes:Z >>> In article <4k0vudF9v06bU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:6 >>>> In article <1QGCg.1833$lL6.724@news.cpqcorp.net>,4 >>>> 	Hoff Hoffman <hoff-remove-this@hp.com> writes:L >>>>>    And as for mapping OpenVMS names into Unix names (or the other way M >>>>> 'round), there are a gazillion obvious filename translations, and some  N >>>>> really ugly ones.  What's ., after all?  The corner cases are enough to * >>>>> drive any sane engineer up the wall. >>>>  M >>>> I wouldn't suggest mapping VMS names to Unix names.  Why would you?  All L >>>> your VMS names are legitimate Unix names any way (even with the ";13").K >>>> If the VMS directory doesn't contain a entry called "." you just don't 9 >>>> include one.  "ls" doesn't even though there is one.  >>> > >>> Because if you're copying a directory full of default-case= >>> VMS filenames (uppercase) onto a Unix directory, a useful = >>> expectation is that you will end up with a Unix directory 4 >>> full of default-case Unix filenames (lowercase). >>  E >> Only if you assume that there is a "default case" for filenames.   H >> I have lot's of files on my Unix systems that are in capital letters.G >> Uppercase isn't necessarily the default case on VMS, it just happens J >> to be the only one they choose to use.  And Unix doesn't have a defaultK >> case.  Most files are created as lowercase because that is they way they  >> were typed. > H >Don't be stupid.  Essentially all [ODS2] VMS file names are upper case.A >A significant majority (95+%) of Unix file names are lower case.  > K VMS filenames under ODS-2 are case insensitive. The fact that the usual VMS N tools display them in uppercase is not really significant since you can accessN them from DCL, Programs etc just as easily by specifying the name in lowercaseM or mixed case. Hence it doesn't really matter whether they are transferred as K upper or lowercase filenames to other systems since if they are transferred O back they will again be stored in a case insensitive manner and will appear to  + the usual VMS tools as uppercase filenames.   L There are other mapping issues with ODS-2 such as multiple dots in filenamesM etc but these have been well known and handled by programs transferring files 1 between VMS and other systems since the year dot.   O ODS-5 gets rid of a lot of these mapping issues but imposes issues of it's own. I When ODS-5 was first introduced it was case-blind but case-preserving ie  I the standard VMS tools would preserve the case of a file's name as it was 0 created rather than displaying it in uppercase. F However ODS-5 can now also be used in a case sensitive manner by using  $ set process/parse=ext/case=sensitive  5 so that like on Unix  you can have two separate files   	 test1.txt  and 	 Test1.txt      Alpha2:dir/full test1.txt    Directory USER52:[DAVID20]  4 test1.txt;1                   File ID:  (184167,4,0)     Alpha2:dir/full Test1.txt    Directory USER52:[DAVID20]  4 Test1.txt;1                   File ID:  (218404,2,0)    
 David Webb Security team leader CCSS Middlesex University     >>   >>> D >>> And because this is the inverse of the mapping that is performedK >>> if you take a directory full of default-case Unix filenames (lowercase) @ >>> and put them into a directory full of only-possible-case VMS >>> filenames (uppercase). >>> % >>> Invertible mappings are goodness.  >>  E >> Or, don't map them at all.  Leave them exactly as they really are.  > " >So it is your devout wish to see: >  >ftp> put foo.tar.gz0 >550 %RMS-F-SYN, file specification syntax error > 9 >>> So the uppercase to lowercase translation is a given.  >>   >> Sorry, I don't agree. > D >Sorry, you still haven't shown any evidence of thinking it through. > F >>> But this means that you now need an escape convention for encoding) >>> upper and mixed case Unix filenames.   >>  H >> That already exists, how do you think they handle NFS mounting a Unix >> directory on a VMS system?  > @ >Just a minute ago you wanted to display the file names "as is".< >Now you want to display them subject to a mapping function. > 
 >Which is it?  >  > , >> But it is also irrelevant to the originalI >> problem which was displaying a VMS directory in IE.  The whole problem F >> with doing that has to do with the format in which the directory isH >> sent from the server and has nothing to do with the case of the file-	 >> names.  > H >The file names appear in the directory listing you utter nincompoop!!!! > > >> If people want the names remapped into lowercase, that is aF >> totally different problem.  (A rather trivial one, but another just
 >> the same.)  > ? >If you have a file name mapping convention then the names that B >you present should be the mapped names, not the VMS native names. >  >Think it through. >  >>  A >>>                                      And this then means that B >>> filenames that happen to match that escape convention can't beE >>> mapped directly into Unix filenames.  They need to be de-escaped.  >>  J >> I think you are making this a lot harder than it really is.  As I said,I >> the mapping problem has been solved a long time ago but doesn't relate  >> to the original problem.  > * >And you still haven't thought it through. > B >>> You are in a maze of twisty passages, all different.  The good> >>> choices are not obvious.   And the obvious choices are not	 >>> good.  >>  ' >> WWWUWW and your outof the maze.  :-)  > 9 >Nope.  The problem is far more complex than you suspect.  > I >>>> Again, I don't think that is the problem.  There is nothing in a VMS M >>>> filename that is not valid in a Unix filename so no re-mapping of actual  >>>> names would be needed.  >>> * >>> Again, you haven't thought it through. >>   >> Whatever. > K >Further evidence that you haven't thought it through and do not intend to.    ------------------------------    Date: 10 Aug 2006 23:31:25 -07001 From: "Bart.Zorn@gmail.com" <Bart.Zorn@gmail.com> ) Subject: Re: DECnet-IV strangeness in NCP C Message-ID: <1155277885.433506.204380@p79g2000cwp.googlegroups.com>    Indeed, I stand corrected!  > I have been using past DECnet Phase IV features ever since theC (in)famous DECnet VAX Extensions, but I do not remember ever having E heard of using DECdns in combination with DECnet Phase IV (apart from E DECdns using Phase IV transport). Not even at the Digital Educational  Services courses in those days!    Regards,   Bart   VAXelate wrote:  > Hoff Hoffman wrote:  > > Bart.Zorn@gmail.com wrote: > > > Hoff Hoffman wrote:  > > . > > > DECdns with DECnet Phase IV? Not likely! > > L > >    Ran it all the time, and for many years.  Worked fine, so long as theH > > network and the DNS servers were themselves holding stable.  NCP SETK > > EXEC DNS, et al.  The DECdns capability had been latent for a while and L > > appeared (quietly) back around OpenVMS VAX V5.5-2...  (I see it is stillK > > commented out in the OpenVMS Alpha help library text for NCP, however.)  > > 	 > >    --  > > L > >    This is not the DNS/BIND name service seen commonly with IP networks,J > > this is a different name service known variously as DNS and as DECdns. > H > Mr. Zorn and I stand corrected --- nonetheless local databases only at > this site.G > (I'll have to spend some time with the Phase-IV docs, as it obviously G > has some potential for management improvements with our 30-some nodes D > site.  Nice to know your posts still teach me something most days) >  > Chris    ------------------------------    Date: 11 Aug 2006 08:12:30 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ) Subject: Re: DECnet-IV strangeness in NCP 3 Message-ID: <xb0QGJt3l1ua@eisner.encompasserve.org>   v In article <1155191085.033746.298920@75g2000cwc.googlegroups.com>, "Bart.Zorn@gmail.com" <Bart.Zorn@gmail.com> writes: > Hoff Hoffman wrote:  > * > DECdns with DECnet Phase IV? Not likely! >   D    Used DECdns on a Phase IV network myself.  DECdns was required toE    set up a network monitoring product DEC sold us.  Phase V was not.    ------------------------------  % Date: Fri, 11 Aug 2006 10:11:13 -0400 # From: sol gongola <sol@adldata.com> % Subject: Re: Enabling SMTP in VAX/VMS 0 Message-ID: <1155305475.333301@nntp.acecape.com>   Steven M. Schweda wrote: > From: contracer11@gmail.com  > E >>>>>    As usual, it would help to know the VMS and/or UCX version.   >>>>> [...]  >>>    Still true. > % >    Still true.  "UCX SHOW VERSION"?  > D >> In reality I don=B4t need access Internet, only send e-mails from >> VAX to Outlook Express. > H >    In reality, you ask for what you want, not what you think will makeI > possible what you want.  Remember, if you knew what you were doing, you  > wouldn't seeking help here.  > K >    I believe that one doesn't send e-mail messages to Outlook [Express].  J > Outlook [Express] fetches e-mail messages from a POP or IMAP server.  IfJ > your UCX version has any of these, you might try the "Server components"$ > menu.  Mine has both POP and IMAP. > J > ------------------------------------------------------------------------ > 5 >    Steven M. Schweda               sms@antinode-org 6 >    382 South Warwick Street        (+1) 651-699-9818 >    Saint Paul  MN  55105-2547   K And with vms mail running, you wouldn't need smtp to get mail into the box.   F tcpip imap is very recent on vms, even pop is only a few versions old./ What version of tcpip/ucx are we talking about?   ( $ucx sho version -or- $tcpip sho version   ------------------------------    Date: 11 Aug 2006 05:28:27 -0700% From: "VAXelate" <moore.mc@gmail.com> , Subject: Re: HP Test Drive sub-network dead?C Message-ID: <1155299307.706408.218180@m73g2000cwd.googlegroups.com>    Steven M. Schweda wrote:C > The HP Test Drive sub-network seems to be dead.  Anyone here know ) > anything?  For example, I can't get to:  > - >    td182.testdrive.hp.com    15.170.178.182 - >    td183.testdrive.hp.com    15.170.178.183 - >    td191.testdrive.hp.com    15.170.178.191 - >    www.testdrive.hp.com      15.170.178.254  > F >    How am I supposed to build the IA64 binaries for GnuPG 1.4.5 this > way? > J > ------------------------------------------------------------------------ > 5 >    Steven M. Schweda               sms@antinode-org 6 >    382 South Warwick Street        (+1) 651-699-9818 >    Saint Paul  MN  55105-2547   0 >From the testdrive site this morning (8:27 EST)> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 July 31, 2006 E The HP Test Drive Program will be down from August 7th to August 11th E for system maintenance. Please make sure that you backup all the data G in your /home directory. We will do everything possible to minimize the D amount of downtime as much as possible. If you have any questions or> comments, please email us at testdrive@hp.com and let us know.> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hope you don't need the backup!    ------------------------------  % Date: Fri, 11 Aug 2006 08:52:32 +0200 + From: Karsten Nyblad <nospam@nospam.nospam> / Subject: Re: LAT to SSH(or Telnet even) tunnel? ; Message-ID: <44dc292f$0$145$157c6196@dreader2.cybercity.dk>    Julian Wolfe wrote: I > Does anyone know if there is an easy way to forward a LAT connection to E > either SSH or Telnet on a VMS 8.2 machine?  I have a PDP-11 running I > RSTS/E that has no form of TCP/IP available, only LAT and DECnet, and I F > want to make it available via SSH connection through the VMS system.A > Attaching via RTERM to RSTS/E from the VMS machine results in a > > crashdump on the VMS machine. Any help would be appreciated.  G You can llogin from a Linux box to a LAT service if you install LAT on   the Linux machine.   ------------------------------    Date: 11 Aug 2006 02:53:02 -0700) From: "Bob Gezelter" <gezelter@rlgsc.com> / Subject: Re: LAT to SSH(or Telnet even) tunnel? C Message-ID: <1155289982.899666.175900@m79g2000cwm.googlegroups.com>    Julian,   F After re-reading your posting, I am unclear about your use of the word) "through" (in "through the VMS machine").   D If you are connecting TO the OpenVMS system, then the comments aboutF the Lantronix are, if memory serves correctly, correect. Additionally,G if you have a terminal server that has the ability to speak LAT and IP, E and as the ability to create Reverse connections, as most do, you can G create a gateway with a simple reversal cable between two of the ports.   B If you are trying to connect to the RSTS/E machine from some otherD system that uses SSH, with the OpenVMS system as a gateway, then the@ answer I would recommend would be the use of SET HOST/LAT on theG OpenVMS system with a captive account for the SSH login. You would need B to ensure that outgoing LAT connections are enabled on the OpenVMSC system (using LATCP).   More complex arrangements are possible, for F example, I have created a test version (uncirculated) of C-Kermit that$ can create outgoing LAT connections.  ! I hope that the above is helpful.   $ - Bob Gezelter, http://www.rlgsc.com   ------------------------------    Date: 11 Aug 2006 08:20:14 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) / Subject: Re: LAT to SSH(or Telnet even) tunnel? 3 Message-ID: <3+1dPZ+Z2$aH@eisner.encompasserve.org>   s In article <1155240474.002142.254060@i3g2000cwc.googlegroups.com>, "Julian Wolfe" <fireflyst@earthlink.net> writes: I > Does anyone know if there is an easy way to forward a LAT connection to E > either SSH or Telnet on a VMS 8.2 machine?  I have a PDP-11 running I > RSTS/E that has no form of TCP/IP available, only LAT and DECnet, and I F > want to make it available via SSH connection through the VMS system.A > Attaching via RTERM to RSTS/E from the VMS machine results in a > > crashdump on the VMS machine. Any help would be appreciated.  B    DEC sold an IP/DECnet gateway, but it was prior to SSH.  It was@    actually an ULTRIX system running DEC's DECnet implementationE    for ULTIRX.  Those of us who had DECnet on our ULTRIX MIPS systems G    had the same capability (I'm not sure if it shipped for UlTRIX VAX).   F    You might dig one of those up for TELNET, LAT, CTERM, FTP, and DNA,E    but you'ld have to write your own gateway if you wanted to support     SSH.   F    Multinet includes a gateway for X11, but I don't think that's going    to be much use for RSTS.   3    You also might want to look at DECnet for Linux.   C    There are also various ways of settin up captive accounts on VMS F    the might allow you to "set host" from RSTS to the VMS box and have"    the VMS box SSH somewhere else.  F    DECnet connections from RSTS to VMS should not make anything crash.   ------------------------------    Date: 11 Aug 2006 08:20:58 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) / Subject: Re: LAT to SSH(or Telnet even) tunnel? 3 Message-ID: <AWAyPCBOuORu@eisner.encompasserve.org>   s In article <1155240474.002142.254060@i3g2000cwc.googlegroups.com>, "Julian Wolfe" <fireflyst@earthlink.net> writes: I > Does anyone know if there is an easy way to forward a LAT connection to E > either SSH or Telnet on a VMS 8.2 machine?  I have a PDP-11 running I > RSTS/E that has no form of TCP/IP available, only LAT and DECnet, and I F > want to make it available via SSH connection through the VMS system.A > Attaching via RTERM to RSTS/E from the VMS machine results in a > > crashdump on the VMS machine. Any help would be appreciated.  @    OBTW, instead of DECnet connections as I posted earlier, it's>    possible to set up incoming LAT connections on the VMS end.   ------------------------------    Date: 11 Aug 2006 02:06:10 -0700  From: "Ian Miller" <ijm@uk2.net>* Subject: Re: TCPIP$TELNETSYM_SYSTARTUP.COMB Message-ID: <1155287170.263174.134670@75g2000cwc.googlegroups.com>   Ian Miller wrote: C > they are called from  TCPIP$TELNET_STARTUP/SHUTDOWN if they exist    typo - I meant  TCPIP$TELNETSYM_STARTUP/SHUTDOWN  , which are called from TCPIP$STARTUP/SHUTDOWN   ------------------------------  % Date: Fri, 11 Aug 2006 11:16:26 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> 6 Subject: Re: VMS 7.3 vs 8.x - java in HTML files, Hmm.; Message-ID: <afb07$44dc4aeb$50db5015$11804@news.hispeed.ch>    patrick jankowiak wrote: > Neil Rieck wrote:  >  > * >> What version of Apache are you running?G >> I've seen JavaScript get messed up by the STREAM_LF requirement. If  B >> you are running SWS-2.1 then you need to disable the STREAM_LF ( >> requirement via the following method:H >> http://www3.sympatico.ca/n.rieck/docs/openvms_notes_apache.html#sws21 >> >  >>H > Here's the info - VMS 8.2 and Apache 2.0 are what we loaded back then J > when the javacript line insertion issue showed up. Sorry I have no more K > info. Maybe next time we re-configure the system we can try it out again   > and see what happens.  >   ' I may have just stumbled across a clue.   A With CSWS 2.1 on VMS V8.2, the apache$common:[htdocs] contains a   subdirectory [.error].  H In there are a bunch of multilingual files for various HTML errors. The 1 multilingual stuff is implemented via Javascript.    The README.; in there says:   ' " Multi Language Custom Error Documents '   -------------------------------------   K   The 'error' directory contains HTTP error messages in multiple languages. C   If the preferred language of a client is available it is selected C   automatically via the MultiViews feature. This feature is enabled D   by default via the Options, Language and ErrorDocument directives.  G   You may configure the design and markup of the documents by modifying 2   the HTML files in the directory 'error/include'.   ..."   --  
 Paul Sture   ------------------------------   End of INFO-VAX 2006.445 ************************