1 INFO-VAX	Wed, 19 Oct 2005	Volume 2005 : Issue 583       Contents: Re: Booting from SAN?  Hurd on IA64 Re: Porting VMS back to VAX ?  Re: Porting VMS back to VAX ?  Re: Porting VMS back to VAX ?  Re: Porting VMS back to VAX ?  Re: Porting VMS back to VAX ?  Re: Porting VMS back to VAX ?  Re: [CSWS V2.1] When expected ?  Re: [CSWS V2.1] When expected ?  Re: [TCPIP V5.5] X11 over SSH   F ----------------------------------------------------------------------  # Date: Tue, 18 Oct 2005 23:56:25 GMT 2 From: AJ Schroeder <ajschroeder-no-spam@gmail.com> Subject: Re: Booting from SAN?7 Message-ID: <JYf5f.4025$8K4.3357@tornado.rdc-kc.rr.com>    Colin Butcher wrote:  E > And don't forget that you can put a list of up to 4 fully-qualified = > device names into the bootdef_dev environment variable. The B > fully-qualified names reflect the path to the device through theA > fabric (see WWIDMGR again), so it's usually a good idea to have E > alternate paths configured in case a switch or an HSG80 dies - that ' > way you can still boot from the disc.  >   F That I did not know... I have to get the second fabric online and then4 I can set multiple boot device names in bootdef_dev.  > Thank you for the advice - I used to administer these HSG's onD Windows, which was nothing like how Alpha/VMS interact with the SAN. --   AJ Schroeder   To reply: Remove "-no-spam"    ------------------------------  % Date: Tue, 18 Oct 2005 22:33:31 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>  Subject: Hurd on IA64 , Message-ID: <4355B069.131FA374@teksavvy.com>   From: i > http://news.com.com/HPs+chief+exec+dismisses+any+me+too+attitude/2100-1010_3-5899561.html?tag=nefd.lede    ##? HP will focus more closely on three areas: Servers, storage and G management software. "You will see us double down on those businesses," 
 Hurd said. ##F As for Itanium-based servers, Hurd said that HP remains committed. "IfE you buy Itanium, you have my commitment for support. We're committed.  Intel is committed," he said.  ##      E Assuming Hurd chose his words carefully, as one would expect a CEO to C do, this means yet another nail in IA64's coffin. It is no longer a G commitment for long term development of the IA64 platform, but rather a G commitment to support what you buy today. (not too different from Alpha  or PaRisc).   G If Hurd uttered that sentence without carefully weighting his choice of > words, he isn't qualified to speak publically on behalf of HP.  > In a context where Hurd said that servers would be a key area.R Discussing IA64, you would have expected a greater commitment than just "support".   ------------------------------  % Date: Tue, 18 Oct 2005 17:16:36 -0400 ' From: Dave Froble <davef@tsoft-inc.com> & Subject: Re: Porting VMS back to VAX ?0 Message-ID: <11lap643ooh7l54@corp.supernews.com>   Hoff Hoffman wrote: J > : So basically, VAX Macro has evolved on Alpha and IA64 but not on VAX ! > G >   A down-port of the OpenVMS 64-bit code pool (Alpha and I64) and its G >   kernel and application code from a 64-bit platform back to a 32-bit D >   platform is just as likely as a port of most any existing 32-bitC >   platform back to its 16-bit predecessor platform(s), of course.  > F >   As we stated some eons ago, the VAX kernel and its environment is,F >   are, and will remain stable -- we'd have to overhaul it as part ofC >   any down-port, causing most any drivers or other kernel-code to # >   require relinks or more rework.  > E >   Getting the compilers and the code generation and other such back H >   to OpenVMS VAX is just the first part of the effort here -- stuffingG >   applications back into 32-bits virtual and (up to) 34-bits physical G >   will be entertaining.    (Piles of my own OpenVMS source code won't J >   particularly down-port willingly, either due to prerequisite products,E >   or due to use of compiler features or system services or such for G >   64-bit operations.)  The additional expectation here -- that any of I >   this work would keep most existing 32-bit code on OpenVMS VAX working F >   -- is non-trivial, particularly where we would have to tear up theJ >   existing kernel to make it 64-bit.  Or pull enough out of the existing2 >   applications to remove the 64-bit assumptions. > G >   Except for PDAs and existing and embedded applications, most 32-bit G >   processing is basically dead, too -- the software on many platforms F >   is often stuck on 16-bit or 32-bit assumptions, but -- even in theD >   PC space -- the new hardware is 64-bit.  And both PC and OpenVMSF >   VAX 32-bit software is moving forward.  So why again would we wantE >   to spend the effort down-porting 64-bit code to 32-bit iron here, C >   when we could be adding features into OpenVMS on current 64-bit 
 >   hardware?  > E >   Could we get more pieces back to OpenVMS VAX and 32-bit?  Sure.   H >   Could we down-port all of the 64-bit OpenVMS implementation?  Maybe.G >   But in the time that it would take to down-port OpenVMS -- ignoring G >   what I perceive as a (lack of) interest that folks have around this H >   particular address space reduction right now -- would anybody want aF >   down-port enough to pay for it?  Or would you rather have new work >   and new features?   G Frankly, as soon as you mention new table structures in OpenVMS Alpha,  F that's more than enough for me.  Don't take this the wrong way, but I I wouldn't trust you to come up with a product as stable as OpenVMS VAX is  I today.  I think you'd agree with that, and the job of revalidating every  H old VAX system, well, it wouldn't go well.  And for what?  A CPU out of  production in the mid 1990s?  G When possible, I for one do appriciate having new features implemented  B on VAX.  I'm sure you already have some criteria you measure each G feature against to determine whether it should get implemented on VAX.  C As long as you do implement those things easily done, I think your   effort is outstanding.   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Tue, 18 Oct 2005 17:59:05 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> & Subject: Re: Porting VMS back to VAX ?: Message-ID: <vee5f.20174$GH1.277053@news20.bellglobal.com>  ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  & news:435171A8.66340643@teksavvy.com...F > Ok, putting all management and business issues aside for a moment... > G > Much has been said about VMS having gotten a good cleanup when ported K > from Alpha to IA64 and making possible common code bases across multiple   > platforms. > F > Much has been said about VAX not having the same code base as Alpha. >  > G > How difficult would it be to "port" VMS back to VAX and have it share H > the same code base as Alpha/IA64 ?  They could re-use the VAX specificF > code and integrate it into the source code management system right ? > H > How much of the VMS code is 64 bit specific that would require lots ofI > changes to run on a 32 bit entity such as VAX ? Or is a large amount of F > code written in such a way that it can easily be compiled for 32 bit > architecture (aka VAX) ? > C > For instance, would ODS5 compile easily for VAX, or would it be a G > nighmare because there are so many assumptions that it will run in 64  > bit environment ?   I I was never convinced that RISC was better than CISC until I experienced  K OpenVMS on Alpha. (CISC was much more important when RAM was expensive but  H those days are long gone). So just like I'll probably never find myself L sitting at the keyboard of a PDP-11 (or 8080, 8085, Z80, 6502, 6811, 680x0, J 808x, 80286, etc.), I hope that I never find myself doing any work on any , kind of VAX outside of a museum environment.  H BTW, I am yet to be convinced that EPIC is better than RISC. One way to M convince me would be to write a SETI@Home (or BOINC) client and then publish  K the results for the whole world to drool at. Compaq did this with Alpha so  $ why wouldn't HP do it with Itanium ?  
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html        ------------------------------  + Date: Wed, 19 Oct 2005 02:14:09 +0000 (UTC) 3 From: Howard Siegel <not.interested@nospam.invalid> & Subject: Re: Porting VMS back to VAX ?, Message-ID: <dj4a5g$rrn$1@reader2.panix.com>  $ jfmezei.spamnot@teksavvy.com writes: > Neil Rieck wrote: L > > I was never convinced that RISC was better than CISC until I experiencedN > > OpenVMS on Alpha. (CISC was much more important when RAM was expensive but > > those days are long gone). >  > 0 > What is the difference between CISC and RISC ? > H > I know that VAX was a 48 point bold reverse video and flashing "C" forC > complex. But the IBM 360 architecture (in whatever incarnation it E > currently has) was also considered CISC but its instruction set was J > nowhere near as Complex as VAX with fewer addressing modes and something> > that was closer to a RISC architecture than it was from VAX. >  > H > When you consider that the 8086 is considered CISC but sports the sameJ > types of features as Alpha's RISC, it truly blurrs the line between CISC > and RISC.   : The VAX was the poster child for CISC instruction sets;-).   - h      --    ? hsiegel~at~pobox~dot~com  <*>  Netcom Class of '93, RIP Netcom!    ------------------------------  % Date: Tue, 18 Oct 2005 23:59:04 -0400 ' From: Dave Froble <davef@tsoft-inc.com> & Subject: Re: Porting VMS back to VAX ?0 Message-ID: <11lbgnb68fg1879@corp.supernews.com>   Neil Rieck wrote: = > "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  ( > news:435171A8.66340643@teksavvy.com... > F >>Ok, putting all management and business issues aside for a moment... >>G >>Much has been said about VMS having gotten a good cleanup when ported K >>from Alpha to IA64 and making possible common code bases across multiple   >>platforms. >>F >>Much has been said about VAX not having the same code base as Alpha. >> >>G >>How difficult would it be to "port" VMS back to VAX and have it share H >>the same code base as Alpha/IA64 ?  They could re-use the VAX specificF >>code and integrate it into the source code management system right ? >>H >>How much of the VMS code is 64 bit specific that would require lots ofI >>changes to run on a 32 bit entity such as VAX ? Or is a large amount of F >>code written in such a way that it can easily be compiled for 32 bit >>architecture (aka VAX) ? >>C >>For instance, would ODS5 compile easily for VAX, or would it be a G >>nighmare because there are so many assumptions that it will run in 64  >>bit environment ?  >  > K > I was never convinced that RISC was better than CISC until I experienced  M > OpenVMS on Alpha. (CISC was much more important when RAM was expensive but  J > those days are long gone). So just like I'll probably never find myself N > sitting at the keyboard of a PDP-11 (or 8080, 8085, Z80, 6502, 6811, 680x0, L > 808x, 80286, etc.), I hope that I never find myself doing any work on any . > kind of VAX outside of a museum environment.  I I seem to remember that you use DEC BASIC.  I'm surprised with the above  F statement, since the incremental compilation on VAX Basic that allows I you to execute statements immediately is rather useful, but never ported  I to Alpha.  I find doing development on a VAX to be a better environment,  ? even if I'm going to move the product to Alpha, and now itanic.   J > BTW, I am yet to be convinced that EPIC is better than RISC. One way to O > convince me would be to write a SETI@Home (or BOINC) client and then publish  M > the results for the whole world to drool at. Compaq did this with Alpha so  & > why wouldn't HP do it with Itanium ?  E Enough people, in positions that would allow them to speak with some  D intimate knowledge, have made statements that EPIC was not going to C challenge Alpha/Power, all else being equal.  Curly made sure that  G things wouldn't be equal for Alpha, but look at how Power continues to   vastly outperform the itanic.   B I remember reading a post from Paul in Australia that even the HP E developers told their masters that they should change course.  Don't  E know where he got his info, so I cannot comment on it's authenticity.   G So what?  If we can continue to get itanics, at reasonable prices, and  I continue to run VMS, that's all that counts to me.  Alpha is truly dead,  F and x86 is just one of JF's dreams, at this time.  My only concern is ' being able to continue getting systems.    --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Wed, 19 Oct 2005 00:55:12 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> & Subject: Re: Porting VMS back to VAX ?, Message-ID: <4355D196.F571C378@teksavvy.com>   Dave Froble wrote:H > So what?  If we can continue to get itanics, at reasonable prices, andJ > continue to run VMS, that's all that counts to me.  Alpha is truly dead,G > and x86 is just one of JF's dreams, at this time.  My only concern is ) > being able to continue getting systems.     
 Just me ?????   E David Dachtera has been dreaming about VMS on the 8086 for far longer H than me. He deserves the credit too. And there are plenty others who nowE see the 8086 as a far better platform for VMS , now that the 8086 has D moved to 64 bits and is about to get large system features/chipsets,G enabling VMS to once again span from laptop to datacentre, something it E has been prevented from doing  first by Palmer's policies, and now by - the fact that IA64 is aimed only at big iron.     G Strategically, it is very important that customers tell Hurd that while G HP-UX can be dead-ended when IA64 is abandonned since Linux on 8086 can G replace HP-UX, VMS has unique industry leading features and must not be = allowed to die when IA64 is officially put out of its misery.   C Like it or not, VMS is owned by a company whose future rides on the H 8086. As long as VMS doesn't run on the 8086 (natively), VMS will not beC strategic to HP and the odds of VMS becoming healthy again are nil.   G Also, VMS is a hodge podge of software availability. Legacy software is F overwhelmingly more available on VAX than on Alpha and IA64 has only aD subset of Alpha's software.  Alpha has some software advantages overG VAX, notably HP's proprietary version of Apache, and JAVA, but IA64 has ! no software advantage over Alpha.     H It takes time to build the software ecosystem on a new platform. VMS hasC two barriers to this. Uncertainty about VMS itself, and uncertainty G about the platform and the fact that the current platform is likited to  a low volume niche market.  H Announcing port of VMS to the 8086 would first and foremost put VMS on aF potential for far higher volumes, making ISVs more interested, as wellE as putting VMS on HP's strategic platform which HP works hard to grow E and advertise. This would be a big sign that with VMS on the 8086, HP . would have no reason to pull the plug on it.    M In such an environment, ISVs would be more likely to consider porting to VMS.   F And with HP now just committing to "supporting" IA64 customers insteadG of working hard to dispell media rumours, do you really think that ISVs F will be interesting in reconsidering VMS, a platform they abandonned a long time ago ?    ------------------------------  # Date: Wed, 19 Oct 2005 05:17:21 GMT 0 From: John Santos <john.santos@post.harvard.edu>& Subject: Re: Porting VMS back to VAX ?> Message-ID: <MPG.1dbfa0e9764af3c79896f9@news.bellatlantic.net>  C In article <mbW4f.14773$FD3.8304@news.cpqcorp.net>, hoff@hp.nospam   says...  > J > : So basically, VAX Macro has evolved on Alpha and IA64 but not on VAX ! > G >   A down-port of the OpenVMS 64-bit code pool (Alpha and I64) and its G >   kernel and application code from a 64-bit platform back to a 32-bit D >   platform is just as likely as a port of most any existing 32-bitC >   platform back to its 16-bit predecessor platform(s), of course.  >   E Oh, so you mean you *ARE* going to port VMS to the PDP-11!  Hooray!!!    :-) :-) :-)       F >   As we stated some eons ago, the VAX kernel and its environment is,F >   are, and will remain stable -- we'd have to overhaul it as part ofC >   any down-port, causing most any drivers or other kernel-code to # >   require relinks or more rework.  > E >   Getting the compilers and the code generation and other such back H >   to OpenVMS VAX is just the first part of the effort here -- stuffingG >   applications back into 32-bits virtual and (up to) 34-bits physical G >   will be entertaining.    (Piles of my own OpenVMS source code won't J >   particularly down-port willingly, either due to prerequisite products,E >   or due to use of compiler features or system services or such for G >   64-bit operations.)  The additional expectation here -- that any of I >   this work would keep most existing 32-bit code on OpenVMS VAX working F >   -- is non-trivial, particularly where we would have to tear up theJ >   existing kernel to make it 64-bit.  Or pull enough out of the existing2 >   applications to remove the 64-bit assumptions. > G >   Except for PDAs and existing and embedded applications, most 32-bit G >   processing is basically dead, too -- the software on many platforms F >   is often stuck on 16-bit or 32-bit assumptions, but -- even in theD >   PC space -- the new hardware is 64-bit.  And both PC and OpenVMSF >   VAX 32-bit software is moving forward.  So why again would we wantE >   to spend the effort down-porting 64-bit code to 32-bit iron here, C >   when we could be adding features into OpenVMS on current 64-bit 
 >   hardware?  > E >   Could we get more pieces back to OpenVMS VAX and 32-bit?  Sure.   H >   Could we down-port all of the 64-bit OpenVMS implementation?  Maybe.G >   But in the time that it would take to down-port OpenVMS -- ignoring G >   what I perceive as a (lack of) interest that folks have around this H >   particular address space reduction right now -- would anybody want aF >   down-port enough to pay for it?  Or would you rather have new work >   and new features?  >  > P >  ---------------------------- #include <rtfaq.h> -----------------------------M >     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq P >  --------------------------- pure personal opinion ---------------------------G >         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com  >  >    --   John   ------------------------------  % Date: Tue, 18 Oct 2005 18:11:17 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> ( Subject: Re: [CSWS V2.1] When expected ?: Message-ID: <Xpe5f.20184$GH1.277643@news20.bellglobal.com>  5 "Rick Barry" <richard.barry@hp.com> wrote in message  & news:4353dbef$1@usenet01.boi.hp.com...E > We now expect a mid-November availability for SWS 2.1 on Alpha and  
 > Itanium. > , > SWS 2.1 removes the stream-lf restriction. >  > Rick Barry > Hewlett-Packard Company  > Secure Web Server Engineering  > OpenVMS System Software Group  > Nashua, NH >  Yippee!   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------  % Date: Tue, 18 Oct 2005 18:13:39 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> ( Subject: Re: [CSWS V2.1] When expected ?: Message-ID: <9se5f.20185$GH1.277974@news20.bellglobal.com>  8 "Steven M. Schweda" <sms@antinode.org> wrote in message , news:05101718215425_20200274@antinode.org... > Rick Barry wrote: F >> We now expect a mid-November availability for SWS 2.1 on Alpha and  >> Itanium.  >>- >> SWS 2.1 removes the stream-lf restriction.  >  >   Sounds good. > ) >   Did anyone ever fix the problem where H > "@ SYS$MANAGER:APACHE$CONFIG.COM FLUSH" caused holes in the access log > file?  > I >   Can SWS 2.1 be installed on an ODS2 disk?  (Or should I just read the  > documentation?)  > H If you want the built in documentation associated with Open_SSL to work  properly then you need ODS5.  
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------  # Date: Tue, 18 Oct 2005 18:12:18 GMT " From:   VAXman-  @SendSpamHere.ORG& Subject: Re: [TCPIP V5.5] X11 over SSH0 Message-ID: <00A4B776.693E24B1@SendSpamHere.ORG>  e In article <43551203$1@news.langstoeger.at>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes: = >I just tried to do X11 over SSH in TCPIP V5.5 and it worked. 6 >But I think in TCPIP V5.4 (ECO 5) it looks like this: >  >$ SHOW DISPLAY  >  >    Device:    WSA4:  [super]% >    Node:      mechta.langstoeger.at  >    Transport: TCPIP  >    Server:    10 >    Screen:    0  > " >while in V5.5 it looks like this: >  >$ SHOW DISPLAY > >%DECW-W-OPENIN, error opening ns.langstoeger.at:10.0 as input( >-SYSTEM-F-IVDEVNAM, invalid device name! >$ SHOW LOGICAL/FULL DECW$DISPLAY G >   "DECW$DISPLAY" [user] = "ns.langstoeger.at:10.0" (LNM$JOB_82006900)  >  > G >Any good reason for this change ?? I'm quite sure it works for most if H >not all the X11 applications, but it is different to V5.4 (and uglier).  F It's the same in V5.4... the eco fixed it and now they've reintroduced the old behaviour.  :rolleyes:   --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------   End of INFO-VAX 2005.583 ************************