1 INFO-VAX	Wed, 25 Jul 2001	Volume 2001 : Issue 410       Contents: 7.3 system disk corruption( Re: Alpha:  an invitation to communicate
 backup VMS Re: backup VMS Re: backup VMS Blasted PASCAL set limit Re: Blasted PASCAL set limit+ Re: Check out the Wall Street Journal today  Re: CSWS 1.1 & TCPware* Re: DFWCUG Announcement regarding DEFCON 9* Re: DFWCUG Announcement regarding DEFCON 9 Re: Future of Alpha/VMS support ) Re: IPF already needs a face-lift for VMS ) Re: IPF already needs a face-lift for VMS : Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS) Re: ISV's and VMS future* Re: KZPCA SCSI adapter board for Alpha/VMS* Re: KZPCA SCSI adapter board for Alpha/VMS Re: LPs on the Web Re: LPs on the Web Re: LPs on the Web Re: LPs on the Web Re: LPs on the Web Re: Migration from VMS
 Re: Minimerge 0 MONITOR on FC RAID MA Subsystem - OpenVMS v7.1-24 Re: MONITOR on FC RAID MA Subsystem - OpenVMS v7.1-24 Re: MONITOR on FC RAID MA Subsystem - OpenVMS v7.1-2+ Re: MX V51-A:  MX-W-NOCONTACT Error message ? Re: Now we're cooking with gas. (was:  Wailing and moaning....) ? Re: Now we're cooking with gas. (was:  Wailing and moaning....) ? Re: Now we're cooking with gas. (was:  Wailing and moaning....) * Re: Oracle Magazine: Where is Oracle RDB ? Perl for  VMS Error  Re: Perl for  VMS Error 0 Re: Problem w/protected subsystems & lib$spawn() Re: Process adopts Itanium$ Re: Selling VMS to another company ?$ Re: Selling VMS to another company ?$ Re: Selling VMS to another company ?$ Re: Selling VMS to another company ?$ Re: Selling VMS to another company ?$ Re: Selling VMS to another company ? simple COPY question Re: simple COPY question Re: simple COPY question Re: SMTP and distribution lists $ Re: Terry Shannon Tech Talk on IA-64$ Re: Terry Shannon Tech Talk on IA-64$ Re: Terry Shannon Tech Talk on IA-64$ Re: Terry Shannon Tech Talk on IA-64B Re: Triggering tasks from network file arrival - Was Re: Basic VMSB Re: Triggering tasks from network file arrival - Was Re: Basic VMSP Re: Triggering tasks from network file arrival - Was Re: Basic VMS Questio Quest Re: VMS Trivia Question  Re: VMS Trivia Question  Re: VS3100 & (dead?) ST51080N D Re: What is the maximum number of mirrorsets on a HSG80 controller ?- Re: [DWMOTIF V1.2-6] VAX EURO patch missing ?   F ----------------------------------------------------------------------  % Date: Wed, 25 Jul 2001 17:56:09 +0100 + From: "Tim Jackson" <tim.jackson@amsjv.com> # Subject: 7.3 system disk corruption & Message-ID: <3b5ef7f5$1@pull.gecm.com>  E Configuration:   DS10 and DS20E, shared SCSI, RAIDarray 3000, OpenVMS C 7.3 plus latest patches, DECnet-Plus, TCP/IP Services 5.1, Advanced E Server 7.3 (as BDC), DECwindows Motif 1.2-6, FORTRAN, Pascal, C, C++,  GKS, DCPS-(Open and Plus).  G Has anyone experienced corruption of their OpenVMS 7.3 system disk?  We F have successfully configured our system, but twice now I have left theE system running overnight only to come in the next morning to find the @ system disk corrupted.  Many symptoms reported from ANALYZE/DISKF including multiply allocated blocks, blocks marked free when used, andC many others I can't remember and which ANALYZE/DISK/REPAIR cleared.    TIA D ------------------ Purely Personal Opinion -------------------------D Tim Jackson                                    tim.jackson@amsjv.com Air Systems Group  Alenia Marconi Systems Ltd.    ------------------------------  % Date: Wed, 25 Jul 2001 13:17:29 -0400 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> 1 Subject: Re: Alpha:  an invitation to communicate 0 Message-ID: <5aD77.94$Yx2.2702@news.cpqcorp.net>  = JF Mezei wrote in message <3B5D059E.4501E5DF@videotron.ca>...  > G >And Alpha was to have an active lifetime of over 25 years. It will die  after G >15 years. Also, I am not sure if the DII-CEO stuff is targetted at all J >customers or only a contractual obligation to only a few select customers inI >the military who require this. Marcello gave the impression that DII-CEO  was  >"for those who need it".  >     K There is a very specific set of reasons that DII-COE is targeted for "those K who need it".  It is more than just an OS release, it also includes the COE J kernel (which currently has export restrictions), and which when installedH will change the execution environment and UI to something much closer to UNIX.   L When the things that were done for COE are integrated into the mainstream ofH the OS, the capabilites will be available in a much more selectable way.   ------------------------------  + Date: Wed, 25 Jul 2001 13:40:42 +0000 (UTC) B From: Massimiliano.Mauceri@tlc.semagroup.it (Mauceri Massimiliano) Subject: backup VMS B Message-ID: <23DC1A5C6E91D411BCD300508B6573E8012CA9AA@SEMARMN0006>   Hi( i need some information about backuo VMS? It's correct that the end of backup termineted with above word:   4 %BACKUP-S-COPIED, copied INS_ROOT:[UTILS]UNZIP.EXE;1  2 %BACKUP-S-COPIED, copied INS_ROOT:[UTILS]ZIP.EXE;1  4 %BACKUP-S-COPIED, copied INS_ROOT:[000000]VDF8.DIR;1  6 %BACKUP-S-COPIED, copied INS_ROOT:[VDF8]INS_VDF8.SCF;3  > %BACKUP-S-COPIED, copied INS_ROOT:[VDF8]SMSC_CONFIG_VDF8.CFG;1  E %BACKUP-S-COPIED, copied INS_ROOT:[VDF8]SMSC_ONLINE_CONFIG_VDF8.CFG;1   D %BACKUP-F-CLOSEOUT, error closing $1$MKF200:[]MIBEP1.SAV;0 as output  9 -SYSTEM-F-INSFARG, insufficient call arguments            . and if I restore the saveset to another disk     Massimiliano Mauceri Delivery and Support Engineer  SchulmbergerSema Telecoms - e-mail: massimiliano.mauceri@tlc.semagroup.it  Tel: +39 06 41536371           --   Posted from [213.255.32.100]  1 via Mailgate.ORG Server - http://www.Mailgate.ORG    ------------------------------  % Date: Wed, 25 Jul 2001 10:45:36 -0300 ) From: fabio_compaq@ep-bc.petrobras.com.br  Subject: Re: backup VMS L Message-ID: <OFBD108F91.60F3B24C-ON03256A94.004B839E@ep-bc.petrobras.com.br>  I You must give us (the list) the whole syntax of the BACKUP comand, and we 
 can help you.    Regards    FC        J Massimiliano.Mauceri@tlc.semagroup.it (Mauceri Massimiliano) em 25/07/2001 10:40:42  @ Favor responder a Massimiliano.Mauceri@tlc.semagroup.it (Mauceri       Massimiliano)              Info-VAX@Mvb.Saic.Com        Assunto: backup VMS      Hi( i need some information about backuo VMS? It's correct that the end of backup termineted with above word:   4 %BACKUP-S-COPIED, copied INS_ROOT:[UTILS]UNZIP.EXE;1  2 %BACKUP-S-COPIED, copied INS_ROOT:[UTILS]ZIP.EXE;1  4 %BACKUP-S-COPIED, copied INS_ROOT:[000000]VDF8.DIR;1  6 %BACKUP-S-COPIED, copied INS_ROOT:[VDF8]INS_VDF8.SCF;3  > %BACKUP-S-COPIED, copied INS_ROOT:[VDF8]SMSC_CONFIG_VDF8.CFG;1  E %BACKUP-S-COPIED, copied INS_ROOT:[VDF8]SMSC_ONLINE_CONFIG_VDF8.CFG;1   D %BACKUP-F-CLOSEOUT, error closing $1$MKF200:[]MIBEP1.SAV;0 as output  . -SYSTEM-F-INSFARG, insufficient call arguments, and if I restore the saveset to another disk   Massimiliano Mauceri Delivery and Support Engineer  SchulmbergerSema Telecoms - e-mail: massimiliano.mauceri@tlc.semagroup.it  Tel: +39 06 41536371           -- Posted from [213.255.32.100]1 via Mailgate.ORG Server - http://www.Mailgate.ORG    ------------------------------  # Date: Wed, 25 Jul 2001 17:00:09 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: backup VMS 0 Message-ID: <tWC77.92$Yx2.2634@news.cpqcorp.net>   In article <23DC1A5C6E91D411BCD300508B6573E8012CA9AA@SEMARMN0006>, Massimiliano.Mauceri@tlc.semagroup.it (Mauceri Massimiliano) writes:  ..) :i need some information about backuo VMS @ :It's correct that the end of backup termineted with above word: ..F :%BACKUP-S-COPIED, copied INS_ROOT:[VDF8]SMSC_ONLINE_CONFIG_VDF8.CFG;1E :%BACKUP-F-CLOSEOUT, error closing $1$MKF200:[]MIBEP1.SAV;0 as output : :-SYSTEM-F-INSFARG, insufficient call arguments           / :and if I restore the saveset to another disk     G   OpenVMS platform and version?  ECO level?  Exact BACKUP command used? 0   Exactly what sort of (tape) device is MKF200:?  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------    Date: 25 Jul 2001 07:12:54 -0700) From: tim@bcd-modelling.com (Tim Shields) ! Subject: Blasted PASCAL set limit < Message-ID: <98b90000.0107250612.5d91b07@posting.google.com>   Hi all,   B Is there anyway of getting around the 255 element limit in the VMSB implimentation of PASCAL SETS? I really don't want to write my own version + access methods.   B If anyone knows of any PASCAL compiler switchs etc that would helpD please could you email me, as I'm out of the office for a while now.   Many thanks.   Tim    ------------------------------  % Date: Wed, 25 Jul 2001 13:43:20 -0400 * From: John Reagan <john.reagan@compaq.com>% Subject: Re: Blasted PASCAL set limit ' Message-ID: <3B5F0538.30201@compaq.com>    Tim Shields wrote:  	 > Hi all,  > D > Is there anyway of getting around the 255 element limit in the VMSD > implimentation of PASCAL SETS? I really don't want to write my own > version + access methods.  > D > If anyone knows of any PASCAL compiler switchs etc that would helpF > please could you email me, as I'm out of the office for a while now. >  > Many thanks. >  > Tim  >   F For sets of integer or unsigned, you are limited to 255.  There is no I way to extend the limit.  You can have sets of enumerated types that are   upto 32K in length.    John Reagan  Compaq Pascal Project Leader   ------------------------------    Date: 25 Jul 2001 11:22:49 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> 4 Subject: Re: Check out the Wall Street Journal todayH Message-ID: <y4hew1icra.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ) "Bill Todd" <billtodd@foo.mv.com> writes:   I > I mean that VMS in no enjoys the perception of 'standardness' that Unix K > variants and Windows do.  The only entry in the list that VMS is remotely M > like in such respects (which I believe are the respects that largely define N > 'proprietary' in many minds) is MacOS.  Hence the phrase 'just like' - i.e.,A > *identically to* that entire list - seems wildly inappropriate.   G Oh, it wasn't clear that you were talking perception instead of reality I (whatever that is). With this in mind, I quite agree with you. OTOH, such N perception has not stopped IBM to successfully market MVS, VM, AS/400 systems.   	Jan   ------------------------------  % Date: Wed, 25 Jul 2001 16:07:51 +0200 < From: "Martin Vorlaender" <martin.vorlaender@pdv-systeme.de> Subject: Re: CSWS 1.1 & TCPware 3 Message-ID: <9jmjss$5jnv$1@ID-56200.news.dfncis.de>   A Coming back on the thread originating on 3-Jul-2001, I now have a  working CSWS 1.1.   > After some toying aroung with the sources, I decided to take a minimalistic approach:C - Boot the machine with DEC TCP/IP, install CSWS 1.1, start it. OK. ; - Shut it down, install CSWS_PERL. Start it. Doesn't run... C   Ironically, the error message was the same as I had with TCPware.   C Install updated PERL V5.5-3A2, CSWS_PERL 1.0-1. Start it. IT WORKS! / Shut it down. Install CSWS_JSERV. Start it. OK.   I Reconfigure SYSTARTUP to install TCPware. Reboot the machine. Start CSWS. 	 It works!   " Thanks, everyone, for suggestions.   cu,    Martin --  J One OS to rule them all       | Martin Vorlaender  |  VMS & WNT programmer7 One OS to find them           | work: mv@pdv-systeme.de J One OS to bring them all      |   http://www.pdv-systeme.de/users/martinv/> And in the Darkness bind them.| home: martin@radiogaga.harz.de   ------------------------------  % Date: Wed, 25 Jul 2001 09:35:42 +0100 - From: John Wisniewski <wisniewski@vmsone.com> 3 Subject: Re: DFWCUG Announcement regarding DEFCON 9 * Message-ID: <3B5E84DE.501BCA43@vmsone.com>  H > The Dallas Ft Worth Compaq User Group (The DFWCUG) has an announcement > regarding the  > recent DEFCON 9 Convention:  > C > July 12-14th  2001, a team of DFWCUG members took an Alphastation  > running OpenVMS A > 7.2-1h1 with a standard installation and OpenVMS Hobbyist PAKs,  > Apache, and TCP/IPE > services for OpenVMS 5.0a to the DEFCON 9 Hackers Convention in Las  > Vegas NV.    This was  posted Monday...   No snide comments...   No Jabs....    No cries for free VMS...  C No complaints about OpenVMS being the reason your site is moving to  SUN...   No moans about marketing...   1 No one telling me that it's already in the FAQ...   > Either comp.os.vms is slipping or you folks really are getting0 apathetic... Or maybe it's just July doldrums...3 Or maybe you're busy porting VMS apps to Itanium;-)   E This was a good thing.. Just taking a VMS box to DEFCON and Surviving  would have been a good thing... ' The DFWCUG did much better then that...    See you at CETS in September...    John Wisniewski  wisniewski@vmsone.com   > PS:  Please tell me if I missed any of the reoccuring posts;-)   ------------------------------  % Date: Wed, 25 Jul 2001 11:33:02 -0400 * From: "Andy Stoffel" <acs@fcgnetworks.net>3 Subject: Re: DFWCUG Announcement regarding DEFCON 9 7 Message-ID: <oFB77.25098$sE4.502230@news6.giganews.com>   D [The original was posted to assorted places but I'm only replying to comp.os.vms.)  I don't feel the urge to cross-post :-)]   : "John Wisniewski" <wisniewski@vmsone.com> wrote in message$ news:3B5E84DE.501BCA43@vmsone.com...   > This was  posted Monday...  @ > Either comp.os.vms is slipping or you folks really are getting2 > apathetic... Or maybe it's just July doldrums...5 > Or maybe you're busy porting VMS apps to Itanium;-)   @ > PS:  Please tell me if I missed any of the reoccuring posts;-)  G You missed the "Why is it in PDF, this is a VMS newsgroup !" complaint. B Of course, that particular group appears too busy burning assortedB Compaq personalities in effigy right now to have possibly noticed.; (Or maybe there is a non-pdf version available somewhere ?)    -Andy-   ------------------------------    Date: 25 Jul 2001 11:07:24 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> ( Subject: Re: Future of Alpha/VMS supportH Message-ID: <y4n15tidgz.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  4 rdeininger@mindspring.com (Robert Deininger) writes:  H > But the various shuttles are not at all identical in the details.  ForA > example, one of them (the oldest one?) has sufficiently smaller = > payload/altitude limits that it can't do certain missions.  K > The 4 shuttles have parts in common, but I suspect each is treated like a . > unique beast for operational considerations.  N The differences are fairly small. Rockwell was offereing a significant upgradeH of the avionics (something which is happening at the moment with the newN "glass cockpit"). The savings were to come from not traing to rebuild obsolete equipment and parts.   	Jan   ------------------------------    Date: 25 Jul 2001 11:10:56 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> 2 Subject: Re: IPF already needs a face-lift for VMSH Message-ID: <y4k80xidb3.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ? system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) writes:   I > >Nonsense. Don't mix Microsoft's software quality with Intel's hardware K > >quality. Or do you have a specific fault of either the IA32 architecture L > >or any implementation thereof in mind that prohibits writing a stable OS?N > Intel quality?  You mean like the "perfect circle" around the "intel inside"N > warning which was drawn by the Pentium processor with "small" floating point > calculation discrepancies.  K Have a look at the bug lists of competing processors. They are more-or-less N similar in the type of bugs that happen. Compilers are full of workarounds for such problems.   	Jan   ------------------------------  % Date: Wed, 25 Jul 2001 12:03:10 +0100u/ From: Nigel Arnot <sysmgr@maxwell.ph.kcl.ac.uk>d2 Subject: Re: IPF already needs a face-lift for VMS7 Message-ID: <009FF88A.3CAD8B94.18@maxwell.ph.kcl.ac.uk>    >  > In article <y4r8v6qy9e.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>, Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:. > >"Neil Rieck" <n.rieck@sympatico.ca> writes: > > L > >> We all know that this is not the case with IA-32 (make one mistake and E > >> you get the blue screen of death no matter which OS is running).  > >oI > >Nonsense. Don't mix Microsoft's software quality with Intel's hardwarenK > >quality. Or do you have a specific fault of either the IA32 architecturesL > >or any implementation thereof in mind that prohibits writing a stable OS? > >  > >	Jan  > N > Intel quality?  You mean like the "perfect circle" around the "intel inside"N > warning which was drawn by the Pentium processor with "small" floating point > calculation discrepancies.  I At the time, I asked why DEC and/or AMD didn't jump on this Intel blunder L and launch a counter-campaign along the lines of "Alpha - the right answers,. and faster" or "AMD inside - our chips work".   L The answers I got said that all chip-makers thoughts on this matter could be2 summed up as "there but for the grace of God go I"  J Intel's biggest failure wasn't a chip bug, it was the MARKETING fubar thatA followed. I think they've learnt: a more recent problem chip was r/ acknowleged and withdrawn pdq (the P3 1130MHz)..  H I wish a certain other organisation could have learnt from its previous  marketing failures.e     	Yours,r
 		Nigel Arnote- 		NRA@MAXWELL.PH.KCL.AC.UK                   e  7 		"In the beginning there was nothing, which exploded."h   ------------------------------    Date: 25 Jul 2001 11:36:20 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS) H Message-ID: <y4elr5ic4r.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  # Tom Linden <tom@kednos.com> writes:o  J > I just don't see the utility of being able to boot different OS's on theJ > same computer, unless they are running something akin to VM.  Hobbyists N > might do it but for people who need different OS's they will have different  > machines.g  D Both machines next door dual-boot W2k or Linux. Desk real-estate and8 ease-of-use are more valuable than any other complexity.   	Jan   ------------------------------    Date: 25 Jul 2001 07:47:14 -0700& From: jordan@ccs4vms.com (Rich Jordan)C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)-= Message-ID: <cc5619f2.0107250647.7a7986fb@posting.google.com>0  l "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message news:<x2i77.25$Yx2.499@news.cpqcorp.net>...I > It is unlikely that VMS will support having a single disk with multiple0L > partitions (beyond the EFI partition) to allow multiple OS types to resideI > on a single spindle.  However, all my research so far would support the I > notion that you will easily be able to have a VMS disk, a Tru64 disk, aON > Linux disk, and a Windows disk all attached to the system, and bootable from= > the console by simply selecting which OS partition to boot.t > A > There should be a single console (unlike ARC versus SRM) image.o >    Fred,LE      are we going to be "stuck with" a graphics only console?  Will auF serial console be possible?  Believe it or not, serial consoles are of0 some importance to us and some of our customers.   > J > The EFI console would then find the MBR, and be able to locate the FAT32I > firmware partition needed to boot VMS.  While on the VMS side, the disk 2 > would look just like any normal VMS system disk. >  > _Fred   F And realizing that its still quite early to ask... _can_ (and when youD can answer, _will_) all necessary tools to create non-VMS partitionsC required for console or bootstrap be provided under the auspices ofvB VMS itself, and its installation utilities?  Or is it likely we'llC have to delve into wintel utilities to 'set up' disks/partitions in  advance of using VMS?r   Rich Jordan    ------------------------------    Date: 25 Jul 2001 09:10:05 -0700/ From: chris@applied-synergy.com (Chris Scheers)oC Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS) = Message-ID: <754a27c1.0107250810.6b826b67@posting.google.com>    Tom Linden wrote:  > J > I just don't see the utility of being able to boot different OS's on the > same computer,N > unless they are running something akin to VM.  Hobbyists might do it but for > people who8 > need different OS's they will have different machines.    ? One benefit would be to allow someone who is not running VMS to 3 evaluate it without buying any additional hardware.s  G -----------------------------------------------------------------------1$ Chris Scheers, Applied Synergy, Inc.  C Voice: 817-237-3360            Internet: chris@applied-synergy.com     Fax: 817-237-30745   ------------------------------  % Date: Wed, 25 Jul 2001 12:54:47 -0400o5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)I0 Message-ID: <PQC77.88$Yx2.2585@news.cpqcorp.net>  : D.Webb wrote in message <9jkcsu$6ke$1@aquila.mdx.ac.uk>...B >In article <x2i77.25$Yx2.499@news.cpqcorp.net>, "Fred Kleinsorge"% <kleinsorge@star.zko.dec.com> writes::I >>It is unlikely that VMS will support having a single disk with multipleCL >>partitions (beyond the EFI partition) to allow multiple OS types to resideI >>on a single spindle.  However, all my research so far would support the I >>notion that you will easily be able to have a VMS disk, a Tru64 disk, aeI >>Linux disk, and a Windows disk all attached to the system, and bootables from= >>the console by simply selecting which OS partition to boot.- >> >tJ >Might it not be worth looking at this to see whether it would be feasible toF >alter VMS to allow it to be booted off a single spindle with other OSL >partitions on it. After all the way disk sizes are growing it won't be many4 >years until you can't get a disk smaller than 72GB. >t    D I believe that the ability to partition a VMS disk should be left asJ something to be done when we finally replace ODS2/5 with a new filesystem.J There are ample reasons to replace ODS2/5 in the next few years - none theL least of which is that we are confined to 32-bit pointers using the existingF structures.  At that point, the "new" EFI partitioning scheme could beA employed, which would then allow many partitions (instread of 4).    ------------------------------  % Date: Wed, 25 Jul 2001 12:59:06 -0400I5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>IC Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)]0 Message-ID: <RUC77.91$Yx2.2563@news.cpqcorp.net>    Rich Jordan wrote in message ...A >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in messageD+ news:<x2i77.25$Yx2.499@news.cpqcorp.net>...F >F >Fred,F >     are we going to be "stuck with" a graphics only console?  Will aG >serial console be possible?  Believe it or not, serial consoles are ofs1 >some importance to us and some of our customers.y >d >>    1 I'll know more when I finally see an IA64 box ;-)s  J The EFI specification makes it clear that you can implement a non-graphics# console, and have headless booting.O   >rG >And realizing that its still quite early to ask... _can_ (and when you E >can answer, _will_) all necessary tools to create non-VMS partitionsfD >required for console or bootstrap be provided under the auspices ofC >VMS itself, and its installation utilities?  Or is it likely we'll9D >have to delve into wintel utilities to 'set up' disks/partitions in >advance of using VMS? >e    H It's probably too early to tell how this all works.  My guess offhand isH that a contiguous file would be created for the EFI partition, and a newH writeboot would construct and write the MBR.  A utility would then allowK "files" within the FAT32 "partition" contained in the contiguous file to be 
 read/written.    ------------------------------  # Date: Wed, 25 Jul 2001 17:08:16 GMTn2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)-0 Message-ID: <42D77.93$Yx2.2617@news.cpqcorp.net>  f In article <cc5619f2.0107250647.7a7986fb@posting.google.com>, jordan@ccs4vms.com (Rich Jordan) writes:F :     are we going to be "stuck with" a graphics only console?  Will aG :serial console be possible?  Believe it or not, serial consoles are of-1 :some importance to us and some of our customers.4  C   It appears that both serial and graphics can be made to function,SE   and we will likely need to get a serial console working during the .D   debug.  If we use USB, there will be restrictions around switchingG   from a running OpenVMS system back to the console and then attemptingrH   to continue OpenVMS -- that very likely won't work.  (No HALT and then   CONTINUE, in other words.)  G :And realizing that its still quite early to ask... _can_ (and when you E :can answer, _will_) all necessary tools to create non-VMS partitions2D :required for console or bootstrap be provided under the auspices ofC :VMS itself, and its installation utilities?  Or is it likely we'll@D :have to delve into wintel utilities to 'set up' disks/partitions in :advance of using VMS?  H   I would obviously expect OpenVMS to ship with all the tools necessary 2   to perform an initial system load on an IPF box.  F   Be forewarned that if you want to delve into Microsoft Windows Data D   Center tools (Windows NT, 2000, etc, do not run on IPF) to try to G   partition disks, the tools might or might not be compatible with the ,8   tools and disk structures and expectations of OpenVMS.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Wed, 25 Jul 2001 06:51:23 -0600> From: yyyc186@mindspring.com! Subject: Re: ISV's and VMS futureM; Message-ID: <3b5ec0de$1$lllp186$mr2ice@nntp.mindspring.com>   3 In <3B53D0B5.A2BAB07C@telocity.com>, on 07/16/2001 a2    at 10:44 PM, Koloth <koloth@telocity.com> said:  > Probably because Unix developers have no concept of stability.   Roland  H >This is true if the only reason for using OpenVMS was for performance. H >Now if you have the same performance as other systems OpenVMS gives you >reliability, ....etcn  H >So the question to the ISV and compaq marketeers is with all else being9 >equal, why would you choose anything other than OpenVMS?c   >Cass Witkowski,   >BK4Leg wrote:  Q >> The company I work for has several applications from software vendors, some on Q >> VMS and some on UNIX.  I'm talking about applications, not tools or utilities.. >>O >> One rationale for the ISV's who use VMS has been the superior performance oftR >> the Alpha chip and VMS over its UNIX competition - esp Solaris and HP-UX.  WithN >> the demise of Alpha, where is the incentive for a vendor to remain on VMS ? >>K >> Even more so for the vendors who have both UNIX and VMS flavors of theirnP >> application software, since without the performance advantage of Alpha, thereR >> is little reason to go to VMS.  They can cut costs either by delaying their VMSM >> versions until well after their UNIX releases, or by eliminating their VMSo >> support entirely. >>G >> It was nice to hope for a while that Compaq might bring new softwareoO >> applications to VMS.  With the demise of the Alpha advantage, I can't expectt9 >> that many of the current vendors will remain with VMS.  >>R >> If Compaq is sucessful in bringing new applications to VMS, then they should be >> widely publicizing that.  >>0 >> And BTW, when was the last VMS ad in Forbes ? >>	 >> Bernie-   -- -; -----------------------------------------------------------m yyyc186@mindspring.com; -----------------------------------------------------------g   ------------------------------  # Date: Wed, 25 Jul 2001 10:05:30 GMT . From: Burnie M <burniem.NOSPAM@ozemail.com.au>3 Subject: Re: KZPCA SCSI adapter board for Alpha/VMSi8 Message-ID: <ea6tlts4elkgpd4g297rfv0h78cl0m51dq@4ax.com>   And just to confuse you;  5 A KZPBA-CB is a KZPBA-CY and a KZPBA-CA is a KZPBA-CXO   (the -CA (-CX) is just UWSE)  B (can't remember which is the card and which is the part number you order)   Burnie M    ? On Tue, 24 Jul 2001 20:44:10 -0400, "D.B. Turner, islandco.com"J <dbturner@islandco.com> wrote:   >Richo >mM >The KZPCA-AA (aka SN-KZPCA-AA and 3X-KZPCA-AA) is a Symbios 8952U Controllera >aL >It is an Ultra2 Wide LVD  80MB/sec (autosenses to Ultra Wide and downwards)! >card that uses a 32 Bit PCI SLot  >kH >Internal Connector is a 68Pin High Density connector as is the external
 >connectorF >Unlike the KZPBA-CA and CB, there is no internal narrow (8 bit 50 pin >rectangular) connector  >  >Supports Busmastering too.  >dI >As for the External RAID - no this will not control an external RAID boxS >eJ >You must still use a differential controller such as the KZPSA-BB (an oldG >Qlogic based Wide - not Ultra WIde) or the reasonably current KZPBA-CB-I >(which is 40MB/sec - Oh - we sell these by the way on our website and wen( >will continue to do so for a long time)L >Oh - for other platforms such as the Proliant etc Intel based, you can also' >use an Adaptec 2944W or 2944UW/3944UW.t >pI >As for the KZPCA - it's a cheap controller that deters people from usings >SCSI narrow devices.iH >I still don't understand why they didn't continue selling the KZPAA for> >tapes and CD-ROM's - we sell loads of our own compatible ones >v" >That's about it - any questions ? >g >i
 >David Turner. >O >We sell Alpha's & Alpha Parts >http://www.islandco.com >sales@islandco.comI >Island Computers US Corp. >2700 Gregory Street >Savannah GA 31404 >Tel: 912 447 6622 >Fax: 912 201 0096   ------------------------------    Date: 25 Jul 2001 07:35:53 -0700& From: jordan@ccs4vms.com (Rich Jordan)3 Subject: Re: KZPCA SCSI adapter board for Alpha/VMSp= Message-ID: <cc5619f2.0107250635.6046bd90@posting.google.com>e  C Thanks to David for the technical info, and to all for responding. JE FYI I did happen to get the compaq 'survey' pop-up while on my searchaD for info; they got a rather scathing bit of feedback.  I will likely? call them when I have time to languish on hold for a while (notm today).d  B So it appears that we can now get Ultra-2 SCSI throughput on a VMSD system, but only to individual disks.  At least that might be of use> on my home system, assuming a KZPCA will work in a PWS600au...  A : On Tue, 24 Jul 2001 20:44:10 -0400, "D.B. Turner, islandco.com"l <dbturner@islandco.com> wrote:  C >As for the KZPCA - it's a cheap controller that deters people froma using  >SCSI narrow devices.a >   E David, the configurator is showing the KZPCA working with narrow tapemE drives using a specific (passive) wide to narrow adapter cable at the C tape drive (looks like a little stub cable).  Unfortunately all thenF DS10s we put out recently came with preconfigured crappy IDE drives; IF imagine a SCSI CD would get the same treatment, and would work on thisC controller also.  Is there a documented limitation concerning otherVA narrow devices, or is it just the lack of a 50-pin header you areo refering to above?   Rich Jordan    ------------------------------    Date: 25 Jul 2001 06:44:27 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)y Subject: Re: LPs on the Weba3 Message-ID: <MDSYRWzWa+Lk@eisner.encompasserve.org>m  u In article <nTp77.7102$zN6.4024420@e3500-chi1.usenetserver.com>, "Zane H. Healy" <healyzh@shell1.aracnet.com> writes: * > David Mathog <mathog@caltech.edu> wrote:S >> They  also charge an awful lot for the CONDIST, so they may consider it a profit 
 >> center. > L > I think this is the real reason.  A CONDIST has got to only cost somethingM > like $30 to produce and ship, yet they charge a little over $1000.  I'm not.N > sure what a subscription costs, however, it doesn't take much math to figureN > out that they've got to be pulling in a MINIMUM of a few hundred thousand inK > profits there, and I wouldn't be surprised if it's a few million.  TakingaG > that into consideration what logical reason is there for dropping it?u  F I think you underestimate the cost of producing and checking all thoseE products before they go onto the master discs.  Is there really a new C version of the French variant of DECwindows ?  Did they provide the C documentation update required by internal procedures.  ConceptuallynE this is straightforward, but it takes a lot of people, including timeI9 of the individual development teams when products change.l  ? I am not saying the cost is $1000, but it is certainly not $30.f   ------------------------------    Date: 25 Jul 2001 15:51:59 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>" Subject: Re: LPs on the WebyH Message-ID: <y4vgkhm800.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ; Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:n  H > I think you underestimate the cost of producing and checking all thoseG > products before they go onto the master discs.  Is there really a new E > version of the French variant of DECwindows ?  Did they provide thelE > documentation update required by internal procedures.  ConceptuallygG > this is straightforward, but it takes a lot of people, including time ; > of the individual development teams when products change.n > A > I am not saying the cost is $1000, but it is certainly not $30.o  I They should be delivering at least ten thousand of these CDs, right? EvenYJ $10 per CD will buy you half a man year to do the checking which should be- highly automated in any case. I don't buy it.o   	Jan   ------------------------------    Date: 25 Jul 2001 10:55:24 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)i Subject: Re: LPs on the WebF3 Message-ID: <VZ5Ugmumjudq@eisner.encompasserve.org>    In article <y4vgkhm800.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>, Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:= > Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:s > I >> I think you underestimate the cost of producing and checking all thosepH >> products before they go onto the master discs.  Is there really a newF >> version of the French variant of DECwindows ?  Did they provide theF >> documentation update required by internal procedures.  ConceptuallyH >> this is straightforward, but it takes a lot of people, including time< >> of the individual development teams when products change. >> :B >> I am not saying the cost is $1000, but it is certainly not $30. > K > They should be delivering at least ten thousand of these CDs, right? EvenmL > $10 per CD will buy you half a man year to do the checking which should be/ > highly automated in any case. I don't buy it.   H It takes different people skilled in various languages and applications,+ spread over many groups within the company.e  G How do you "automate" checking the differences between V2.6 and V2.7 ofv kits ?   ------------------------------  , Date: Wed, 25 Jul 2001 17:31:42 +0200 (CEST)- From: Freddy Meerwaldt <frederik@freddym.org>e Subject: Re: LPs on the Web K Message-ID: <Pine.LNX.4.21.0107251729310.23683-100000@firewall.freddym.org>o   Hi!   M > > They should be delivering at least ten thousand of these CDs, right? EveneN > > $10 per CD will buy you half a man year to do the checking which should be1 > > highly automated in any case. I don't buy it.  > J > It takes different people skilled in various languages and applications,- > spread over many groups within the company.S > I > How do you "automate" checking the differences between V2.6 and V2.7 ofe > kits ?  D Maybe they shouldn't automate it, but what about the following idea:H Just make an internal location for all the layered Products, and as soonI as a layered product is updated to a new version, the new version will benH copied to this internal source, and CDs will be burned according to this source.lF So there's almost no need for manpower (OK, just a bit for copying the! ready product to the location...)-  - Or did I get something wrong in this thread??h   Greetings - Freddy -- rN Geek Code 3.1: GCS s+: a--- C+++ UBOU+++ P-- E--- W++ N w--- V++ PGP- t? 5? tv  J ==========================================================================>  Frederik Meerwaldt           Homepage: http://www.freddym.orgC  Bavaria/Germany              OpenVMS and Unix Howtos and much morenI  Solaris, HP/UX, AIX, NetBSD, OpenBSD, IRIX, Tru64, OpenVMS, Ultrix, BeOSd   ------------------------------    Date: 25 Jul 2001 12:58:16 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)e Subject: Re: LPs on the Webo3 Message-ID: <rgGXBiQsjC$$@eisner.encompasserve.org>-  { In article <Pine.LNX.4.21.0107251729310.23683-100000@firewall.freddym.org>, Freddy Meerwaldt <frederik@freddym.org> writes:p > Hi!n > N >> > They should be delivering at least ten thousand of these CDs, right? EvenO >> > $10 per CD will buy you half a man year to do the checking which should be 2 >> > highly automated in any case. I don't buy it. >> rK >> It takes different people skilled in various languages and applications,i. >> spread over many groups within the company. >> iJ >> How do you "automate" checking the differences between V2.6 and V2.7 of	 >> kits ?m > F > Maybe they shouldn't automate it, but what about the following idea:J > Just make an internal location for all the layered Products, and as soonK > as a layered product is updated to a new version, the new version will beuJ > copied to this internal source, and CDs will be burned according to this	 > source. H > So there's almost no need for manpower (OK, just a bit for copying the# > ready product to the location...)t  B You are correct that skipping all quality control would save work,- but that is not what draws some of us to VMS.    ------------------------------  % Date: Wed, 25 Jul 2001 10:45:15 +0100 % From: Alan Greig <a.greig@virgin.net>s Subject: Re: Migration from VMSa8 Message-ID: <b45tltcjucfed1nlbfcb8vicbg9akgad9o@4ax.com>  # On Tue, 24 Jul 2001 14:47:42 -0300,a* fabio_compaq@ep-bc.petrobras.com.br wrote:  : >I  read that  ABB is not planning to use Alphas anymore !7 >Is it true abroad ? Was a news from ABB Brazil........n  @ ABB just announced 12000 job cuts yesterday... I used to do someF consultancy work for an ABB location. They still had a VAX 6000 seriesA cluster at that point. Don't know if they moved to Alphas or whatw their futures intentions are.)   -- Alan   ------------------------------    Date: 25 Jul 2001 11:04:22 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>n Subject: Re: MinimergeH Message-ID: <y4puapidm1.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  4 rdeininger@mindspring.com (Robert Deininger) writes:  L > > What is the rationale for going through these shenanigans (as you later K > > call them) for a full copy (and not for a mini-copy)? Why not just copyo' > > the source to the target in one go?pD > Perhaps it is done without write-locking that section of the disk.  F That is the explanation Glenn gave in an e-mail to me. It seems a veryI wasteful way of solving the problem though - at a minimum, you're readingaI the source disk twice instead of once, and have to keep an additional setdB of buffers around to do the comparison (which trashes cache in theL process). As all writes must also go to the source member, the driver shouldN be able to do a local check (at the host of the source member) for conflictingL writes (a simple fence variable would be sufficient if the copy were done in LBN order) and act accordingly.p   	Jan   ------------------------------    Date: 25 Jul 2001 06:08:34 -07006 From: andrew.rycroft@intrinsitech.com (Andrew Rycroft)9 Subject: MONITOR on FC RAID MA Subsystem - OpenVMS v7.1-2 < Message-ID: <58ba0101.0107250508.8e3f2d7@posting.google.com>   Hi,l  E I have an OpenVMS system running v7.1-2 with an MA6000 disk subsystem D attached. When I run the MONITOR utility, I have one device whose IOF queue continually grows, $1$DGA106:. It shows a queue length of 41899.E Appreciate any comments on this, or why it is behaving in this mannerV ?-   Thanks Andrew   ------------------------------    Date: 25 Jul 2001 15:53:39 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> = Subject: Re: MONITOR on FC RAID MA Subsystem - OpenVMS v7.1-2lH Message-ID: <y4snflm7x8.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  8 andrew.rycroft@intrinsitech.com (Andrew Rycroft) writes:  G > I have an OpenVMS system running v7.1-2 with an MA6000 disk subsystemeF > attached. When I run the MONITOR utility, I have one device whose IOH > queue continually grows, $1$DGA106:. It shows a queue length of 41899.I > Appreciate any comments on this, or why it is behaving in this manner ?   K It is a known bug - a UCB field was moved and MONITOR wasn't told about it.rK There was a thread here recently about this subject. Can't remember whethere there is a fix for it yet.   	Jan   ------------------------------  % Date: Wed, 25 Jul 2001 14:57:52 +0000r  From: Steve.Spires@yellgroup.com= Subject: Re: MONITOR on FC RAID MA Subsystem - OpenVMS v7.1-2l/ Message-ID: <00256A94.005234DF.00@quegw01.btyp>   L Contact:   Tel: 3063  -  IS - Infrastructure, 1st Floor, Bridge Street Plaza     Yes, I raised that.l  O There is an article about it on WIS/DSN which gives a patch, although the patchf9 doesn't directly mention this problem as far as I recall.D  4 We just left it and it returned to normal over time.   Steve St        L Jan Vorbrueggen <jan@fsnif.neuroinformatik.ruhr-uni-bochum.de> on 07/25/2001 01:53:39 PMs    To:        Info-VAX@Mvb.Saic.Com+ cc:         (bcc: Steve Spires/YellowPages)<M From:      Jan Vorbrueggen <jan@fsnif.neuroinformatik.ruhr-uni-bochum.de>, 25e            July 2001, 1:53 p.m.m  4 Re: MONITOR on FC RAID MA Subsystem - OpenVMS v7.1-2        8 andrew.rycroft@intrinsitech.com (Andrew Rycroft) writes:  G > I have an OpenVMS system running v7.1-2 with an MA6000 disk subsystem F > attached. When I run the MONITOR utility, I have one device whose IOH > queue continually grows, $1$DGA106:. It shows a queue length of 41899.I > Appreciate any comments on this, or why it is behaving in this manner ?1  K It is a known bug - a UCB field was moved and MONITOR wasn't told about it. K There was a thread here recently about this subject. Can't remember whetherl there is a fix for it yet.        Jan   ------------------------------    Date: 25 Jul 2001 10:15:59 +0200* From: eplan@kapsch.net (Peter LANGSTOEGER)4 Subject: Re: MX V51-A:  MX-W-NOCONTACT Error message* Message-ID: <3b5e803f$1@news.kapsch.co.at>  o In article <34e80f93.0107241328.5651cf0@posting.google.com>, techwebsite@netscape.net (Michael Angello) writes:c0 >I am using OVMS 7.2 AXP and using MXV51-A, and 7 >DIGITAL TCP/IP Services for OpenVMS Alpha Version V5.0   B You know, that MX V5.2 (ECO 4) and TCPIP V5.1 (ECO 1) is current ?  A >but there are a lot of email messages waiting for processing andI >at: DKAn:[MX.SMTP.LOCK]  C You know, that you can disable the locking alltogether/specificallya* with the MX_SMTP_LOCK_EXCLUSIONS logical ?  1 >a lot of messages has the following description:s > 7 >0C2783B8: %MX-W-NOCONTACT, could not establish contactm+ >with any mail servers for this destinationr  ; The SMTP agent is not able to reach the remote SMTP server.r? This is not really a MX problem (if not weird config happened).m  4 Check with NSLOOKUP -type=MX destination.domain.nameC and then with TELNET mail-server.destination.domain.name [/PORT=]25p  G You can however redirect the mailmessage to another mailserver (despite  the infos in BIND/DNS) with ther  H $ MCP ADD PATH "destination.domain.name" SMTP/ROUTE="another-mailserver"   command.  
 >at MCP STAT:o > 0 >MX Router       Idle               Router agent0 >MX Router#2     Idle               Router agent0 >MX Router#3     Idle               Router agent8 >MX Local        Waiting for #  311 Local delivery agent8 >MX Local#2      Waiting for #   30 Local delivery agent8 >MX Local#3      Waiting for #   36 Local delivery agent8 >MX Local#4      Waiting for #   17 Local delivery agent8 >MX Local#5      Waiting for #   12 Local delivery agent  = 5 local agents and all busy ? Do you have so much local userst; or are they all busy rewriting the mails for the SMTP agenta, (when "MAIL>SET FORWARD/USER=..." is in use)  < >MX MLF          Idle               Mailing list/file server7 >MX SMTP         Waiting for #   89 SMTP delivery agent-7 >MX SMTP#2       Waiting for #  115 SMTP delivery agentm7 >MX SMTP#3       Waiting for #  175 SMTP delivery agentd7 >MX SMTP#4       Processing  #  159 SMTP delivery agenta7 >MX SMTP#5       Waiting for #  117 SMTP delivery agent 7 >MX SMTP#6       Waiting for #    9 SMTP delivery agentr7 >MX SMTP#7       Waiting for #   34 SMTP delivery agent 7 >MX SMTP#8       Waiting for #   87 SMTP delivery agenti  I 8 SMTP agents is not that many. I've 60 running (and only 2 LOCAL agent).uG What are the entries waiting for ? Do they all have delivery problems ?lE If you have a lot of mails in the queue, the throughput is limited bye the count of the SMTP agents.   @ >MX Site Agent   Idle               Site-specific delivery agent= >MX SMTP Server  Connected       36 SMTP server (over TCP/IP)r2 >MX FLQ Manager  Idle               MX FLQ manager< >MX LSV Intfc    Idle               Listserv interface agent >b+ >and a lot of SMTP request: (almost always)2= >MX SMTP Server  Connected       36 SMTP server (over TCP/IP)   D Wow. Are they really all doing useful things. Or are they only badlyG closed TCP connections. Better check in TCPIP (and upgrade to V5.1-151)O  = >The MX Server cannot deliver email so easy as another times, = >so at the client side it takes a lot of time passing througha: >some errors (time outs) before sending the email message.  @ You could configure more than one SMTP server to split the load.@ But not on the same IP address (only usable on multihomed hosts)8 on the same TCP port (check MX_SMTP_TCPIP_PORT logical).2 I've never done it, and I also won't recommend it.  < >I have configured the network services well, because I have> >the connectivity needed, by using pings, nslookups, etc. evenC >more, It doesn't have any other email services up except this one.h  D You mean, you haven't enabled TCPIP's SMTP. This is good, obviously.   -- i< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888e< <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------  % Date: Wed, 25 Jul 2001 02:14:12 -04002' From: "Bill Todd" <billtodd@foo.mv.com>oH Subject: Re: Now we're cooking with gas. (was:  Wailing and moaning....)( Message-ID: <9jlnr8$i19$1@pyrite.mv.net>  ? "Robert Deininger" <rdeininger@mindspring.com> wrote in messagegF news:rdeininger-2407011945130001@user-2ivecho.dialup.mindspring.com...L > In article <9jkbpb$a1m$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> > wrote: >nA > > Again, likely because the statement was not "no further alphar improvementsL > > will occur" but rather "no further alpha improvements will be possible":' > > there's a very definite difference.i >aH > If the engineers want to do something, and they think they can, but itJ > turns out  that Compaq management won't give them enough resources, then0 > from their point of view it is "not possible". > I > The long-lost post in the other group came after the alpha announcementhH > (maybe that's obvious), and when I first read it I immediately assumedF > that the reasons had to do with the recent management decisions, notL > anything technical.  I was surprised that many others read it differently,! > and responded the way they did.o  J I thought I detected a faint whiff of inconsistency here, but it took me a while to pin it down.o  J Above, and in your previous post in this sub-thread, you state that you'veK believed all along that the difficulties Compaq alluded to in keeping AlphasC competitive were fiscal rather than 'anything technical' in nature.g  I Whereas two days ago, in another thread (Selling VMS to another company),aK you were quite ready to suggest that unforeseen technical difficulties (anddL the unexpectedly higher cost of overcoming them) might be at the root of the cancellation decision.  K I think I addressed that suggestion adequately in the 'ostriches and sheep'tG post.  And it just doesn't matter that one might be able to construct aeJ scenario in which Compaq told some engineer "We're not going to fund AlphaH at anything like the levels that had been planned" and then received theK response "Well, then we're not going to be able to maintain our performancetI lead" - because that's emphatically not the message Compaq trotted out in-H its attempt to paint the cancellation as resulting from a combination ofG unrealizable technical goals (information supposedly volunteered by itsh4 Alpha engineers) and excessive funding requirements.  K On the basis of the information available, that message still appears to ben
 a triple lie:   1 1.  The Alpha engineers said nothing of the kind.h  6 2.  The Alpha engineers *believe* nothing of the kind.  D 3.  The long-planned funding levels were clearly sustainable even atH existing Alpha sales levels, let alone with the increased sales that any7 reasonable Alpha marketing effort should have produced.,  D Those lies (and their vigorous spreading by proxies), plus the totalJ disregard for the firm commitments to Alpha's future Compaq had made rightB up until the June 25th announcement, are the major aspects of thisI development that disgust me (there are also some VMS-related side-effectsmG that are disturbing, but they just indicate that Compaq cares as little 3 about VMS as it always has - no new perfidy there).-  D And, as I said earlier, it really bothers me to see people like HoffG standing up to support them - and to see people like you trying to findVE circumlocutions and interpretations that make them something at leastiH marginally less distasteful (perhaps that's what Hoff is doing as well).  I For a decision with this degree of impact on customers, there needs to beaG more justification than Hoff's assurances that these things that to allfL appearances are just not true should be taken on faith because he can't tellG us more right now.  From an outside viewpoint, such an assertion simplynH seems like a stall while Compaq tries to come up with some new tale thatK people will swallow more readily than the previous ones (or waits to see if L the storm will subside).  If there *is* some justification for the June 25thK move (and while I can't think of one that doesn't mean one couldn't exist),3H it's long past time to make it clear - before people become unwilling to believe *anything* Compaq says.    - bill   >y > -- > Robert Deininger > rdeininger@mindspring.comt   ------------------------------  % Date: Wed, 25 Jul 2001 10:55:03 -0400r- From: JF Mezei <jfmezei.spamnot@videotron.ca>aH Subject: Re: Now we're cooking with gas. (was:  Wailing and moaning....), Message-ID: <3B5EDDC4.2FB7BEB1@videotron.ca>   Bill Todd wrote:K > For a decision with this degree of impact on customers, there needs to belI > more justification than Hoff's assurances that these things that to all.N > appearances are just not true should be taken on faith because he can't tell > us more right now.  L 1- Hoff can tell no more than he knows. And the fact that he knows so littleN is not his fault, but reflects on the reasons behind Compaq's decision to giveM Alpha's knowledge to Intel: the porting of VMS was a consequence of this mains* decision, it was not part of the decision.  J > seems like a stall while Compaq tries to come up with some new tale thatM > people will swallow more readily than the previous ones (or waits to see ift > the storm will subside). u  N Compaq has already communicated with the customers it wants to keep. And basedL on the customer-compaq-apoligists here, it seems that Compaq has lured a big( enough carrot to please those customers.  J The fact that Compaq has made no effort to provide more information to theH general public since the 25th is another good indication of where CompaqK intends to take VMS, or rather where it does not intend to take it (smaller: less important customers).    4 > If there *is* some justification for the June 25thM > move (and while I can't think of one that doesn't mean one couldn't exist), J > it's long past time to make it clear - before people become unwilling to! > believe *anything* Compaq says.   H The justification is quite clear. Compaq just doesn't want to be in thatN business. Compaq is a box maker, not a chip designer. Its strategy is to buildK software solutions and services businesses instead if designing chips. ThisoA was made quite clear on the 25th. What more do you need to know ?e  N As far as VMS is concerned, I beleive that it is business as usual for Compaq.J VMS will continue to live on IA64 instead of Intel. When Compaq started toN support IDE drives, did VMS customers cry foul over the future of VMS ? So now5 Compaq is changing another component in the hardware.>  J The problem has not much to do with the death of Alpha but rather with theI continued absence of VMS as part of Compaq's core products and marketing,rL hence a continued fear that Compaq doesn't intend to do anything with VMS inK the medium and long term as well as the strong messages from Compaq that it 2 wants to focus on Wintel stuff for the enterprise.  N The very public murder of Alpha just caused many to realise that Compaq wasn'tI interested in their small business and that Compaq was only interested ins( keeping certain large key VMS customers.  H As far as I am concerned, Compaq sent a clear and strong message. If youL decide not to heed it because you don't like it, it is your problem. But the message is there.   K And the fact that Compaq has not made any attempts to clarify the situationVH only re-enforces the fact that its original murder-day message reflected, Compaq's intentions/policies clearly enough.   ------------------------------  % Date: Wed, 25 Jul 2001 12:46:53 -040095 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>aH Subject: Re: Now we're cooking with gas. (was:  Wailing and moaning....)0 Message-ID: <rJC77.87$Yx2.2588@news.cpqcorp.net>  = JF Mezei wrote in message <3B5EDDC4.2FB7BEB1@videotron.ca>...0 >jI >Compaq has already communicated with the customers it wants to keep. Andn basedsI >on the customer-compaq-apoligists here, it seems that Compaq has lured a  bigp) >enough carrot to please those customers.) >     J We are woring in an ongoing way to communicate to customers.  But a lot ofI the information that many people are looking for won't be available untilu mid to late August.   % We want to keep ALL of our customers.o  J If your company hasn't been talked to by your account rep, or you feel youK need higher level discussions, please drop a note to Sue Skonetski, or Mark L Gorham, or even me (I'll simply forward it to one or both of them).  Or even to Rich Marcello.    ------------------------------  % Date: Wed, 25 Jul 2001 09:28:10 -0400g0 From: "Syltrem" <syltrem@videotron.ca.spammenot>3 Subject: Re: Oracle Magazine: Where is Oracle RDB ?a5 Message-ID: <FOz77.48585$TW.239638@tor-nn1.netcom.ca>,   And what about OpenVMS?eF There are advertisements for Compaq/Unix evey month, but no mention of OpenVMS. Ever.   --   Syltrem(; http://pages.infinit.net/syltrem (OpenVMS related web site)     C <fabio_compaq@ep-bc.petrobras.com.br> a crit dans le message news:aA OF6E508420.C5098557-ON03256A93.00406981@ep-bc.petrobras.com.br...f9 > I received  the Oracle Magazine and again serarched for 3 > some  information about Oracle RDB: Where is it ?- >-9 > Oracle RDB is really dead and nobody told us: customers  >r	 > Regardsi >i > FC >o   ------------------------------  # Date: Wed, 25 Jul 2001 09:06:34 GMT.2 From: Piyush Avichal<pa@it.singer-friedlander.com> Subject: Perl for  VMS Error5 Message-ID: <u_v77.6171$ar1.18266@www.newsranger.com>    Hello,  @ I was wondering if you could help me. I downloaded Perl for VMS F from the CPAN website. I have tried to install it using the configure E script, but it crashes out half way through with the following error:e  # Do you wish to edit CONFIG.SH? [n] -  * Adding VMS specific preprocessor commands., Doing variable substitutions on .SH files...1 Extracting config.h (with variable substitutions)MM %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000002,a PC=000573CC, PSL=0BC00000-/ %TRACE-F-TRACEBACK, symbolic stack dump follows L module name     routine name                     line       rel PC    abs PC   000573CC  000573CC 000545F5  000545F5M MUNCHCONFIG     main                                       00000070  00000526,    4 Does anyone know what might be causing this problem?  6 I am running OpenVMS 7.1 for VAX on a Microvax 3100-80  & Any help would be grately appreciated.   Many Thanks,   Piyush.t   ------------------------------  # Date: Wed, 25 Jul 2001 16:57:54 GMTn2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)  Subject: Re: Perl for  VMS Error0 Message-ID: <mUC77.90$Yx2.2574@news.cpqcorp.net>  j In article <u_v77.6171$ar1.18266@www.newsranger.com>, Piyush Avichal<pa@it.singer-friedlander.com> writes:  A :I was wondering if you could help me. I downloaded Perl for VMS n :from the CPAN website.  ..M %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000002,/ PC=000573CC, PSL=0BC00000t ..7 :I am running OpenVMS 7.1 for VAX on a Microvax 3100-80r     Which version of Perl?  D   PCSI and other pre-built installation kits for Perl are available.  A   The FAQ has various Perl-related pointers, and a pointer to the     Perl for OpenVMS mailing list.    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Wed, 25 Jul 2001 16:54:32 GMTn2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)9 Subject: Re: Problem w/protected subsystems & lib$spawn()h0 Message-ID: <cRC77.89$Yx2.2395@news.cpqcorp.net>  j In article <Pine.LNX.4.31.0107242149070.2559-100000@jaipur>, Ryan Moore <rmoore@rmoore.dyndns.org> writes:K :I'm having problems getting a protected subsystem identifier to get passedhG :to a subprocess when using lib$spawn() within a program.  Basically, I-G :want a set of users to have read access to a directory, but have write H :access when they use a certain image.  That's what protected subsystems :are designed to do.  H   Yep, and they're also designed to remove the enhanced access when the    image runs down.    J   In this case, the image that first runs down is LOGINOUT, since you are J   running DCL.  This, of course, scorches off any sign of the identifiers.  H   In other words, subsystem identifiers are presently incompatible with :   lib$spawn or lib$creprc invocations of DCL subprocesses.  G :However, within the image with the protected subsystem identifier, I'msH :calling lib$spawn() a couple times to perform some tasks (a couple COPY :and PURGE commands).d  G   Use the callable convert API for the COPY, and use the LIB$FIND_FILE, G   LIB$FIND_FILE_END and LIB$DELETE_FILE calls for the PURGE.  This willeJ   allow you to avoid the SPAWN.  (Or -- if you have control over the file G   creation -- consider options such as the delete-on-close or similar.)iF   Or use task-to-task or a central (privileged) server that the clientC   application calls when it needs to use these operations -- these r6   servers can be application images or DCL procedures.    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------    Date: 25 Jul 2001 09:37:14 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> # Subject: Re: Process adopts ItaniumiH Message-ID: <y44rs1jw7p.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  / JF Mezei <jfmezei.spamnot@videotron.ca> writes:w  L > What hints do you see that Compaq would not complete the IA64 port ? It is= > being funded by Intel (indirectly from the sale of Alpha). v  L None. But there are also no hints that Compaq intends to go through with theN VMS - or, for that matter, any of the other OSes it has - port to IPF. Nor canN there really be at this time, I suppose, unless they would want to send a veryJ strong signal by hiring lots of people - but then again "mulp" is claimingF Compaq is in fact currently making people from these groups redundant.  M Consider: Let's say 100 people are currently working on preparing the VMS-to- J IPF port. In a year, that spends about $20M on salaries etc. I would guessN that preparing and executing the 25 June announcement spend about that amount L of effort - as a SWAG, say 800 people working for a month. In a year's time,M the bean counters will look at VMS last-year performance and "decide" whetheryM it makes sense to continue. Remember that all current contractual commitments > (even those to DOD et al.) can easily be met without the port.  , > The Wintel crowd will benefit from the VMSN > and NSK knowledge and expertise in building systems and the Wintel crowd may@ > be able to then sell "wildfires" based on IA64 and running NT.  N IIRC, that organizational schema was the one _before_ the current one. And theK Wintel crowd did everything it could to get rid of those three warts in itsoN face, as they have no interest at all in learning everything - after all, they are the champoins, aren't they?d   M > On the other hand, by having the wintel crowd responsible for VMS, it giveseJ > the slight possibility that Compaq may start to view VMS as a mainstreamM > product and market the hell out of it. However, I do not personally beleive H > that the attitudes at Compaq and Microsoft would allow this to happen.   V.s.   	Jan   ------------------------------    Date: 25 Jul 2001 10:14:09 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>e- Subject: Re: Selling VMS to another company ?oH Message-ID: <y4vgkhifxq.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  4 rdeininger@mindspring.com (Robert Deininger) writes:  K > We have seen hints, if not outright statements from Compaq, that the cost H > of funding future alpha development was a factor in the cancellation. L > Your analysis of past expenditures really doesn't, and can't, address whatE > they would have had to spend to complete EV8 as it should have beenwJ > completed.  Maybe there were significant problems on the horizon that we > haven't heard about.  K I agree with the analysis. The point is, while the hints are there, why not3N say more about those potential "significant problems"? Others (e.g., Sun) haveI taken much more on their plate going from one processor generation to theeM next. The EV6->EV7->EV8 progression is quite well thought out: keep the core,uH update the glue (EV7), then keep the glue, update the core by adding SMTM (EV8). Such a progression significantly reduces risk. And EV8 would not have eI been the first SMT implementation (IBM has done a PowerPC implementation eH (Northstar?) that does two threads). So exactly what might have been the	 problem?    5 > If Compaq could not or would not commit to spendingnD > enought money to ensure success in the face of difficult technicalL > problems, it's quite possible that the more technical folks would start to" > seriously consider alternatives.  K That is a totally different matter. But this interpretation is inconsistenty with anything Compaq has said.   	Jan   ------------------------------  # Date: Wed, 25 Jul 2001 09:50:42 GMTb4 From: "Terry C. Shannon" <terryshannon@mediaone.net>- Subject: Re: Selling VMS to another company ? ; Message-ID: <SDw77.1729$eH.1239581@typhoon.ne.mediaone.net>   L "Jan Vorbrueggen" <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote inJ message news:y4vgkhifxq.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de...6 > rdeininger@mindspring.com (Robert Deininger) writes: >hH > > We have seen hints, if not outright statements from Compaq, that the costI > > of funding future alpha development was a factor in the cancellation. I > > Your analysis of past expenditures really doesn't, and can't, address  whatG > > they would have had to spend to complete EV8 as it should have beeniL > > completed.  Maybe there were significant problems on the horizon that we > > haven't heard about. > I > I agree with the analysis. The point is, while the hints are there, whys nottK > say more about those potential "significant problems"? Others (e.g., Sun)t haveK > taken much more on their plate going from one processor generation to thenI > next. The EV6->EV7->EV8 progression is quite well thought out: keep then core,qJ > update the glue (EV7), then keep the glue, update the core by adding SMTI > (EV8). Such a progression significantly reduces risk. And EV8 would noth haveJ > been the first SMT implementation (IBM has done a PowerPC implementationJ > (Northstar?) that does two threads). So exactly what might have been the
 > problem?  F With EV8 the problem was cost and time to implementation. Further info available under NDA.   ------------------------------  # Date: Wed, 25 Jul 2001 10:13:20 GMTt. From: Burnie M <burniem.NOSPAM@ozemail.com.au>- Subject: Re: Selling VMS to another company ?n8 Message-ID: <4u6tltcq5ovptpirpfhihdr6r3fp6c45ni@4ax.com>  4 On Tue, 24 Jul 2001 16:19:00 GMT, "Terry C. Shannon"" <terryshannon@mediaone.net> wrote:   >e. >"jlsue" <jlsuexxxz@home.com> wrote in message3 >news:q8vqltos4gnruftne1enbp8p9h5sprqrem@4ax.com... 3 >> There are other things to consider here as well:e >>2 >> 1.  Business is down for many (most?) companies? >> 2.  Compaq has *two* high-end server groups:  One working oniH >> Alphaserver systems, and one working on Intel/AMD systems.  Ever lookH >> at the details of the Proliant 8500 architecture?  It has an internalG >> switched bus... but it doesn't use switch technology we own.  HavingsH >> two completely different "systems" engineering groups has got to be a >> drain on resources. >>I >> I see one huge benefit of the IA64-based VMS/Tru64/NSK systems is thataG >> we will probably end up with one consolidated group working togetheroE >> to engineer the best high-end servers.  Combining them should helpe0 >> make Compaq much more competitive/profitable. >t >Yup.  Stay tuned... >i     Well we are Terry...  C How much longer do we have to wait or should we give it away and go3 talk to HP etc ?   ------------------------------  % Date: Wed, 25 Jul 2001 11:48:33 +0100*% From: Alan Greig <a.greig@virgin.net> - Subject: Re: Selling VMS to another company ? 8 Message-ID: <pq7tlt0p7n7po49mf0057qpvav2f9nd5t0@4ax.com>  4 On Wed, 25 Jul 2001 09:50:42 GMT, "Terry C. Shannon"" <terryshannon@mediaone.net> wrote:    G >With EV8 the problem was cost and time to implementation. Further info1 >available under NDA.T  B Let's hope that if the Compaq NDA information is accurate (I'm notC suggesting that anyone who has seen it is being anything other thantD truthful) that Intel can work magic to add the EV8 goodies to IPF onC time and on budget then. As Compaq said that EV8 was "fully funded"aD just a few weeks ago (and I have very strong reason to believe theseD words were officially sanctioned to be used to customers *after* theF internal decision to drop) it implies that what changed officially wasD that funding was withdrawn after it was approved. Legally Compaq didD not lie to customers when it said that EV8 was "fully funded".  They dropped the funding.  D However I think we're all starting to dance on the head of a pin nowC and it is probably time to either take Compaq at face value or look F elsewhere until such time as Marcello, Capellas, Winkler etc feel freeF to give more details. I'm still irritated as hell but if I want VMS toF survive then that is entirely in Compaq's hands right now. But it doesE not surprise me in the slightest that those who no longer work on VMSrC have the blackest views of Compaq's motives because those of us whotA still do would quite like to continue to do so for a long time too come.i   >i   -- Alan   ------------------------------    Date: 25 Jul 2001 15:49:42 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>e- Subject: Re: Selling VMS to another company ?aH Message-ID: <y4y9pdm83t.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  6 "Terry C. Shannon" <terryshannon@mediaone.net> writes:  ; > With EV8 the problem was cost and time to implementation.e  K Such things don't suddenly drop from heaven into one's unsuspecting lap. SohL all proclamations by Compaq in recent months that EV8 was on track must haveH been lies. Furthermore, it means that the group doing the work seriouslyH screwed up - why then should Intel have any interest in buying them? AndM what else is new in that ambitious chip projects are late - would an EV8 thatoH was a year or even two late to market have to fear the then-current IA64F implementation? With all the systems-integration features it has aboveG anything Intel has on its roadmap? It seems quite hard to imagine that.t  L Finally, why not say "we looked at the EV8 project, and realized it wouldn'tH be able to deliver a workable product in such a time frame to be able toJ compete with future IA64 processors". But that is not what has been and is being said.n   	Jan   ------------------------------  % Date: Wed, 25 Jul 2001 11:58:02 -0400p- From: JF Mezei <jfmezei.spamnot@videotron.ca>a- Subject: Re: Selling VMS to another company ?g, Message-ID: <3B5EEC82.7FF4D13D@videotron.ca>   Alan Greig wrote:iG > not surprise me in the slightest that those who no longer work on VMSqE > have the blackest views of Compaq's motives because those of us whotC > still do would quite like to continue to do so for a long time ton > come.i  @ Since the end of the Olsen era where Digital purposefully becameM uncompetitive, there have been thousands of computer sites that saw the lightcM and decided it was time to migrate. At first, the ones with the most paranoia E moved. Then, some with some strategic thinking, seing how Digital waseL neglecting VMS. Then came the "migrate from VMS to NT" and many more saw the" message and moved out of VMS ASAP.  F The remaining customers had the same mentality as your paragraph. TheyM "wanted" to stay with VMS. They had hopes that Compaq would fix things up ande make VMS succesful again.a  M However, open your eyes. Had Compaq had wanted to make VMS succesful on IA64,eJ it would have made a big splash about it and we'd all know that Compaq hadN every intentions of making VMS compete against NT and Unix. None of that couldN been seen or heard, and VMS continues its standard silent treatment by Compaq.N We may not pronounce the "open" in "OpenVMS", but Compaq doesn't pronounce the "VMS" in "OpenVMS".   K You can continue to use VMS if you wish. I am sure Compaq won't prevent you0I from doing so, and if you fight hard enough, you may even find someone atRK Compaq willing to sell you a VMS system if you're not a large customer in a8N specific niche market. But with a smaller and smaller niche market, the amountH of applications and mind-share available on VMS will go down quite fast.  K Any application not needed by those remaining large niche customers will goaH away. VMS still has stuff such as Netscape, Mosaic, a decent telnet/ftp,I newsreaders etc, which a platform such as Tandem doesn't. That is becauseeC Tandem is dedicated to running a very small and very focused set ofRI applications and is not seen as a general operating system. It is truly atA server OS. And It seems that VMS is going to become that as well.-   ------------------------------  % Date: Wed, 25 Jul 2001 08:27:17 -0700e( From: William King <wrking@dadaboom.com> Subject: simple COPY question$> Message-ID: <NFBBJPCFMLDJOBNGBJGIAEAKCAAA.wrking@dadaboom.com>   Looking for a little help...  J It has been a long time since I used VMS full time and I'm having a bit ofG difficulty moving data around between disks. What I'm trying to do is arJ image disk copy from a file onto a RL02 disk. The file was created on RT11F and contains an image of a XXDP diagnostic disk (copy/device/file dl0:
 xxdp.dsk).  H I have a uVAXIII running VMS 5.5-2H4 with an RL02 attached and I want toK copy this file onto the RL02 as a disk image. In unix land, what I would doA is:y   	dd if=xxdp.dsk of=/dev/dl0u  ( But, sadly I can't figure it out in VMS.   Thanks for the help, Bill   ------------------------------  # Date: Wed, 25 Jul 2001 17:47:25 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)! Subject: Re: simple COPY questioni0 Message-ID: <NCD77.96$Yx2.2783@news.cpqcorp.net>  i In article <NFBBJPCFMLDJOBNGBJGIAEAKCAAA.wrking@dadaboom.com>, William King <wrking@dadaboom.com> writes:-  F   This is far from a simple question, as it involves very old tools...  K :It has been a long time since I used VMS full time and I'm having a bit of-H :difficulty moving data around between disks. What I'm trying to do is aK :image disk copy from a file onto a RL02 disk. The file was created on RT11 G :and contains an image of a XXDP diagnostic disk (copy/device/file dl0:o :xxdp.dsk).b  *   RT?  Which ancient VAX console was used?  I :I have a uVAXIII running VMS 5.5-2H4 with an RL02 attached and I want to L :copy this file onto the RL02 as a disk image. In unix land, what I would do :is: :  :	dd if=xxdp.dsk of=/dev/dl0 :l) :But, sadly I can't figure it out in VMS.   H   IIRC, dd is a binary dump tool, is that what you have here?  ("Image" J   has a common interpretation in OpenVMS, and specifically a BACKUP/IMAGE F   saveset.  That is clearly not the case here.  And referencing a UNIXG   tool means that I have to know about the tool or I have to go figure sI   out what the UNIX tool does -- while referencing a UNIX tool is clearlyMK   a useful comparison and a useful reference, providing us with background  K   and details of what you want to do is also useful.  No offense intended.)H  G   If this is a block dump, try mounting the RL02 foreign and using the eI   OpenVMS EXCHANGE utility -- EXCHANGE provides a block-mode binary dump .C   transfer mode mechanism.  See COPY/TRANSFER in the EXCHANGE help.r  F   Slightly fancier would be the use of this file an LDDRIVER (logical H   disk) target file, which might allow you direct access to the contentsD   without an intervening RL02 disk.  (Assuming you can make heads or!   tails of the volume structure.)e  E   Before trying any of this, keep a copy of the source file around...o    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Wed, 25 Jul 2001 17:47:44 GMT 0 From: John Santos <john.santos@post.harvard.edu>! Subject: Re: simple COPY questionb> Message-ID: <MPG.15c8d039f8a3caf598968c@news.bellatlantic.net>  ? In article <NFBBJPCFMLDJOBNGBJGIAEAKCAAA.wrking@dadaboom.com>, , wrking@dadaboom.com says...  > Looking for a little help... > L > It has been a long time since I used VMS full time and I'm having a bit ofI > difficulty moving data around between disks. What I'm trying to do is atL > image disk copy from a file onto a RL02 disk. The file was created on RT11H > and contains an image of a XXDP diagnostic disk (copy/device/file dl0: > xxdp.dsk). > J > I have a uVAXIII running VMS 5.5-2H4 with an RL02 attached and I want toM > copy this file onto the RL02 as a disk image. In unix land, what I would do  > is:n >  > 	dd if=xxdp.dsk of=/dev/dl0w > * > But, sadly I can't figure it out in VMS. >  > Thanks for the help, > Bill  D I don't know from unix, but mount the output disk /foreign, and just copy the file to it.   $ mount/for dla0:- $ copy dua1:[dir]xxdp.dsk dla0:2  D should do the trick.  If dla0: has been previously initiallized as aC VMS disk, you will need lots of privs to allow you to overwrite it.DD Also, you may want to suppress mount verification on the RL02, since? you'll be overwriting the header blocks.  (/foreign might implyo% /nomount_verification, I'm not sure.)e   HTHo   -- John   ------------------------------  # Date: Wed, 25 Jul 2001 14:52:43 GMTu- From: Jonathan Boswell <jsb@ost.cdrh.fda.gov>o( Subject: Re: SMTP and distribution lists0 Message-ID: <3B5EDD2C.2373C219@ost.cdrh.fda.gov>   "John E. Malmberg" wrote:t? > An enhancement to recent versions of the OpenVMS mail utilityg@ > was done so that if it discovers an "@" in an address in otherB > than the first character position, it uses the SMTP protocol and > passes that address through.  N Unfortunately, when MAIL was rewritten in C, some hack rearranged the order ofI processing and didn't quite get it quite right.  If you try to send to anu9 Internet address with a perfectly valid username, such aseM patrick.j.o'brien@somewhere.com, you will find that MAIL(?) first attempts toe@ check "PATRICK.J.O'BRIEN" against a valid VMS username and failsO (%MAIL-E-USERSPEC).  I just checked this with VMS V7.3, TCPIP Services V5.1 andeO it still exhibits this irritating behavior.  You must surround the address withtO the SMTP% construction to override this check and get the address to be passed.   ( The good ol' MAILSHR_PATCH got it right!   ------------------------------    Date: 25 Jul 2001 05:53:34 +0800, From: Paul Repacholi <prep@prep.synonet.com>- Subject: Re: Terry Shannon Tech Talk on IA-64n- Message-ID: <87hew2xach.fsf@prep.synonet.com>t  / JF Mezei <jfmezei.spamnot@videotron.ca> writes:n  D > 1-if you're not a big enough customer to have gotten a visit, then( > Compaq doesn't want you as a customer.  ; > 2-if you're expecting/needing VMS to grow to attract morea2 > applications, then VMS isn't the right platform.  C 3- If you are big enought to get a visit, come Monday, the promisesv$ you where made may be worth nothing.   -- o< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.r@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------    Date: 25 Jul 2001 10:57:05 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> - Subject: Re: Terry Shannon Tech Talk on IA-64tH Message-ID: <y4snflidy6.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  / JF Mezei <jfmezei.spamnot@videotron.ca> writes:   H > Why would customers have to wonder ? Compaq made it quite clear on itsI > announcement that this was part of its 180 day restructuring. They were N > ditching non-core assets in order to get a wad of money that will allow them? > to buy stuff that will help with that 180 day transformation.,  K No, they are saying Alpha was technically supportable in the future. And ittM seems quite doubtful they received enough short-term influx of cash from this M deal to help acquisitions. Isn't their stock of cash large enough to fund anyT& reasonable set of acquisitions anyway?   > The port of VMSVO > to IA64 is a secondary thing that is being done to keep key customers, but inlH > do way do I see that port of VMS to Ia64 as being strategic to Compaq.   No question about that.   fL > Compaq's strategy is to develop that softare/solutiosn/support business by > buying existing firms.  N Wo why gut their own support group, the one they got by buying DEC, first? AndK who, after DEC, is large enough to buy to compete with IBM Global Services?nM Remember, the current MBA thinking is you have to be the first in your marketiL to make continued existence (as a company) wirthwhile; being in second place is barely acceptable.   L > If you're a large customer with an already huge VMS setup, I am confident M > that Compaq managed to convince you during its private vistits that Compaq rL > won't kill VMS and will port it to IA64 and that you should plan to stray O > with VMS for your existing applications. But if you're not a valued customer,n. > then the message Compaq sent is quite clear: > K > 1-if you're not a big enough customer to have gotten a visit, then Compaqf! > doesn't want you as a customer.a   M They can't continue to make VMS available to their "valued customers" withoutsL making it available in general. So the fact that they tried to convince whatL they see as their market in private talks of VMS's viability does nothing to help their general credibility.a   	Jan   ------------------------------    Date: 25 Jul 2001 11:42:25 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> - Subject: Re: Terry Shannon Tech Talk on IA-64uH Message-ID: <y4bsm9ibum.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  I Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:   M > No, they are saying Alpha was technically supportable in the future. And it8    Bah. "unsupportable", of course!   	Jan   ------------------------------  % Date: Wed, 25 Jul 2001 11:42:50 -0400s- From: JF Mezei <jfmezei.spamnot@videotron.ca>t- Subject: Re: Terry Shannon Tech Talk on IA-64v, Message-ID: <3B5EE8F3.98082FD6@videotron.ca>   Jan Vorbrueggen wrote:O > They can't continue to make VMS available to their "valued customers" without N > making it available in general. So the fact that they tried to convince whatN > they see as their market in private talks of VMS's viability does nothing to! > help their general credibility.   E Tandem seems to have survived with a very small niche of very captiveoL customers. If Compaq can do with VMS what Tandem was able to do with NSK, itH should be able to make the remaining VMS customers extremely captive andN unable to move to another platform because VMS is the only available solution.  I The problem, of course is that VMS doesn't offer the fault tolerance thateJ Tandem does and the applications for those niche markets also run on other* platforms or could be ported quite easily.  K In the case of Tandem, when a group of banks in a country decide to setup anI national EFTPOS network and commissions software to be written, they willtG chose one platform and all banks will run the network interface on that6S platform (Tandem). That is one example that shows how captive Tandem customers are.t  D For VMS however, the "niche" markets are a bunch of very independantJ businesses, so one business can easily migrate to another platform withoutA affecting other businesses since they don't require the amount ofhK synchronisation of software and transaction formats that banks do when they? exchange transactions.   ------------------------------    Date: 25 Jul 2001 10:55:12 -05003 From: malmberg@encompasserve.org (John E. Malmberg)nK Subject: Re: Triggering tasks from network file arrival - Was Re: Basic VMS 3 Message-ID: <agoqZqMzs$V$@eisner.encompasserve.org>   ( In article <3B5E74BA.1A927E44@home.com>,B Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <noone@home.company> writes: > Hi.l3 > Personaly I think a combination of an FTP session 6 > to copy the datafile and a REXEC command to initiate, > the processing is the most flexible setup.  = Frequently the system transferring the file is in a differentP) management and different security domain.i  7 Many sites for security reasons do not allow either the ; rexec client or server programs, if they are even availablel for that platform.  > FTP is more universally available, and even there you can have7 an interesting time when the non-OpenVMS host wants alld= records to be a fixed length, and use of a set record length.o  > The simpler that the interaction is between groups the better.  = > You *do* have to edit the process/script on the originatinga > system a little.  5 Since that script is under the control of a differentr; department or company, that can be a difficult thing to do.l  A Generally if you tell them to FTP a file with a specific name andu: then rename it, the otherside will eventually find someone> that knows how to do that on their system and put it in one of their scripts.    < Getting them to find someone that can edit the script to put( in a specific command may be impossible.  = Considering that on the OpenVMS side, you have may no idea ofi> the exact syntax needed for the other's host operating system,< and they do not know the syntax needed for OpenVMS.  You may4 not even have a language or character set in common.  : And what happens if they make a change on their computer's+ platform.  You start all over from scratch.y     -John" wb8tyw@qsl.network Personal Opinion Onlyi   ------------------------------  % Date: Wed, 25 Jul 2001 19:26:08 +0200'< From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <noone@home.com>K Subject: Re: Triggering tasks from network file arrival - Was Re: Basic VMS ( Message-ID: <3B5F0130.7779EF63@home.com>  < Well, I'm sure they already have the file format sorted out,# they are FTP'ing files today, not ?A  = And it a peace-of-cake to check the "other" sides TCP/IP docso% to look up the REXEC or RSH syntax...o  8 And if the other side changes plattform, you don't start@ from scratch, do you ? (regarding this issue at least). You move, what you already have to the new plattform.   3 After all, we are just speaking about a single-lineo command, in most cases...   = Then, firewall's and such things is another story of course !c   Jan-Erik Sderholm.l   ------------------------------  % Date: Wed, 25 Jul 2001 09:26:50 +0200n< From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <noone@home.com>Y Subject: Re: Triggering tasks from network file arrival - Was Re: Basic VMS Questio Questu( Message-ID: <3B5E74BA.1A927E44@home.com>   Hi.s1 Personaly I think a combination of an FTP sessione4 to copy the datafile and a REXEC command to initiate* the processing is the most flexible setup.; You *do* have to edit the process/script on the originating  system a little.   Regardsc Jan-Erik Sderholm.a   ------------------------------    Date: 25 Jul 2001 09:44:30 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>t  Subject: Re: VMS Trivia QuestionH Message-ID: <y41yn5jvvl.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ? system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) writes:   E > In memory mgt. these used to be used bit have been abandoned on theeD > Alpha version of VMS for performance reasons.  The lookaside listsF > are now singly linked lists with elements being removed and inserted > at the head.  M In an SMP system, these operations still have to be interlocked among CPUs ino some way...so: how?m   	Jan   ------------------------------    Date: 25 Jul 2001 09:53:29 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>V  Subject: Re: VMS Trivia QuestionH Message-ID: <y4y9pdigw6.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  , "David Cressey" <david@dcressey.com> writes:  K > This worked, but it was highly unaesthetic.  My understanding is that the G > VAX "insert queue" instructions,  or at least some of their variants,oM > enabled VMS to maintain its queues without turning off the interrupts.  But ; > I never learned VMS internals,  so I don't actually know.   K IIRC, all queue manipulation instructions on VAX are atomic and can thus bekK used by multiple threads on one CPU. For SMP systems, you have to make sureqM that two threads running on two CPUs don't compete for the same data. On VAX,rI there is a set of interlocked instructions that implement this - the fourlM mentioned queue instructions (insert and remove, at head or tail), ADAWI (addaJ aligned word interlocked, for maintaining shared counters) and BBCCI/BBSSIC (branch on bit clear/set and clear/set interlocked, for maintaininglL semaphores). The definition of the interlocked queue instructions contain anL implementation detail: they use a so-called secondary interlock, because theK VAX architecture defines (via the operations on the memory bus on the firstDN implementation, the VAX-11/780) interlocked operations as working on longwordsF (32-bit entities) and the queue instructions manipulate quadwords. WhyF anything larger than ADAWI (e.g., ADALI) wasn't included, I have neverL understood. I vaguely remember reading about at least one bug caused by this lack.T   	Jan   ------------------------------  % Date: Wed, 25 Jul 2001 12:04:42 +0100k* From: "Richard Brodie" <R.Brodie@rl.ac.uk>& Subject: Re: VS3100 & (dead?) ST51080N+ Message-ID: <9jm94d$o9i@newton.cc.rl.ac.uk>u  b "Tom Linden" <tom@kednos.com> wrote in message news:CIEJLCMNHNNDLLOOGNJIKELMDAAA.tom@kednos.com...  U > On the other hand, this drive is only 1 GB, and as such qualifies for the dust bin.u  I Hmm, that's a matter of opinion, for a system that must be 10+ years old.jE 1GB is the maximum size for a boot disk on that model, and 9GB drivesc) can't be used at all on that VMS version.I   > You sure it isn't the driver?i  C It *is* the driver. Or at least the driver won't play with the disku@ with factory settings. Please let us not rehash the generic SCSI support debate again.l  ; A more recent VMS would probably support the disk but mightb, strain the limited resources of the machine.   ------------------------------    Date: 25 Jul 2001 01:50:10 -0700( From: rob@denbraber.org (Rob den Braber)M Subject: Re: What is the maximum number of mirrorsets on a HSG80 controller ?n= Message-ID: <9fa0ae66.0107250050.49708158@posting.google.com>   E Thanks for the reply. This morning I ran into the same error message.gH We're running the following version: Software V85S-5 on our controllers.F Hopefully you're wrong about the maximum not changed for version V8.6.   ------------------------------    Date: 25 Jul 2001 10:25:46 +0200* From: eplan@kapsch.net (Peter LANGSTOEGER)6 Subject: Re: [DWMOTIF V1.2-6] VAX EURO patch missing ?* Message-ID: <3b5e828a$1@news.kapsch.co.at>  _ In article <3B5E818D.22A9BDE@digital.com>, Mike Rechtman <michael.rechtman@digital.com> writes:r >TryE >http://ftp.service.digital.com/public/vms/axp/v7.3/decwindows/motif/n  . Sorry, wrong answer. The question was for VAX.9 I've the Alpha version in use for a couple of time now....   --  < Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888l< <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------   End of INFO-VAX 2001.410 ************************