INFO-VAX Tue, 18 Dec 2007 Volume 2007 : Issue 691 Contents: Re: Compiling PHP and/or any PHP Extension on VMS Re: Compiling PHP and/or any PHP Extension on VMS Re: HP to close Nashua (ZKO) Re: HP to close Nashua (ZKO) Re: HP to close Nashua (ZKO) Re: HP to close Nashua (ZKO) Re: HP to close Nashua (ZKO) Re: Let's get back to some VMS tech talk!! Re: Let's get back to some VMS tech talk!! Re: Timezone rule change won't stick! Re: Timezone rule change won't stick! Re: Unix for VMS guys Re: Unix for VMS guys Re: VMS 5.5-2 patch question Re: VMS 5.5-2 patch question Re: Why can't I use an IA64 as a boot server for an Alpha? Re: Why can't I use an IA64 as a boot server for an Alpha? Re: Why can't I use an IA64 as a boot server for an Alpha? Re: Why can't I use an IA64 as a boot server for an Alpha? Re: Why can't I use an IA64 as a boot server for an Alpha? Re: Why can't I use an IA64 as a boot server for an Alpha? ---------------------------------------------------------------------- Date: Tue, 18 Dec 2007 07:43:19 +1030 From: Mark Daniel Subject: Re: Compiling PHP and/or any PHP Extension on VMS Message-ID: <13mdpkqcfd692f6@corp.supernews.com> Grant Croker wrote: > Hi, > > I have over the last year or so tried to build the PHP source provided > by HP[1] on OpenVMS. The driver for this is a client request to have > the PHP Ingres extension[2] built on the same platform. Unfortunately > I have encountered problems building PHP using the supplied source. > Whilst I realize the source code has been provided as-is and "The save > sets do not include complete build procedures...", I was wondering if This statement has always puzzled me. Of course there is some value in having access to source if you have a somewhat academic interest in the way something is implemented but I'm guessing for the vast majority source is for building, correction (bugfix), tailoring, extension, improvement ... What can be the magic ingredient that they are loath to or cannot share I wonder? > any brave soul had managed to build PHP on their VMS system? Dave Jones of OSU has successfully built (earlier?) versions. Perhaps he used a particular approach he can comment on. As PHP is such a widely deployed component of Web infrastructure it would be beneficial to the community for it to be taken out of HP's hands with their (still much appreciated but) widely staggered releases I'm sure they wouldn't mind either. Perhaps someone needs to take the (probably to begin with fairly onerous) responsibility for porting and maintaining a VMS baseline for PHP. One that would allow others to build all sorts of extensions against. This is certainly the case with Jean-François Piéronne's port of Python. Always up-to-date and bugfixed. You can download and build it yourself. Add extensions if you want. I understand about corporate requirements for 'officially supported' products. Let HP take the n-1 or n-2 such GPL release and call it their own if they want. Just so the rest of the community can keep moving forward. > regards > > grant > > [1] http://h71000.www7.hp.com/openvms/products/ips/apache/csws_source.html > [2] http://pecl.php.net/ingres I'm not going broke spending these AU$0.02 one at a time. -- Those afraid of the universe as it really is, those who pretend to nonexistent knowledge and envision a Cosmos centered on human beings will prefer the fleeting comforts of superstition. They avoid rather than confront the world. But those with the courage to explore the weave and structure of the Cosmos, even where it differs profoundly from their wishes and prejudices, will penetrate its deepest mysteries. [Carl Sagan; Cosmos] ------------------------------ Date: 18 Dec 2007 06:04:39 GMT From: JONESD@ecr6.ohio-state.edu (David Jones) Subject: Re: Compiling PHP and/or any PHP Extension on VMS Message-ID: In message <13mdpkqcfd692f6@corp.supernews.com> Mark Daniel >Grant Croker wrote: >> Whilst I realize the source code has been provided as-is and "The save >> sets do not include complete build procedures...", I was wondering if >What can be the magic ingredient that they are loath to or cannot share >I wonder? The revision control system they use, perhaps? >Dave Jones of OSU has successfully built (earlier?) versions. Perhaps >he used a particular approach he can comment on. Last June I did a fresh port of PHP 4.4.7 for use with the OSU server. The main problem is that the UNIX kits build by using shell scripts to generate key header files that select tons and tons of conditional source lines based on the OS variant, application environment, and build options you selected. Once you get a best guess for a couple hundred #defines in the header files, you then have to compiler qualifiers to make the compiles resolve the #include paths correctly and use the right compiler mode options. Finally, you have to craft linker options files with associated object libraries and/or shareable images to be able to link your final executables. I packaged up the result as a zip file for distribution, available at http://www.ecr6.ohio-state.edu/www/preview/PHP_4_4_7-OVMS-1.ZIP Note that this kit contains files that supplement/supplant the standard 4.4.7 source kit tree from php.net (which they'll probably stop distributing at the end of this year). The only executable it builds is a custom PHP interpreter for the OSU script environment (interpreter internally provides the CGI environment seen by the scrpits). I don't think it would work with the CSWS mod_osu module since it requires a patch to work with the OSU server. David L. Jones | Phone: (614) 271-6718 Ohio State University | Internet: 140 W. 19th St. | jonesd@ecr6.ohio-state.edu Columbus, OH 43210 | vman+@osu.edu Disclaimer: I'm looking for marbles all day long. ------------------------------ Date: Mon, 17 Dec 2007 15:03:03 -0500 From: JF Mezei Subject: Re: HP to close Nashua (ZKO) Message-ID: <99c18$4766d5f0$cef8887a$10861@TEKSAVVY.COM> David P. Murphy wrote: >> > computer equipment is being shipped to an unspecified location in >> > Jackson, NJ, which is widely known as a worldwide focus point for VAX >> > machines. > who know of the VAXcave. http://www.tmesis.com/VAXcave/ Geez, I got caught in that one. I was going to post something to the effect that Mr Vaxman would be near to all the HP equipment from ZKO :-) I didn't realise just how near it would have been ! But will it all fit ? ------------------------------ Date: Mon, 17 Dec 2007 15:31:55 -0500 From: "Richard B. Gilbert" Subject: Re: HP to close Nashua (ZKO) Message-ID: <4766DCBB.5000106@comcast.net> David P. Murphy wrote: > On Dec 17, 10:44 am, "Richard B. Gilbert" > wrote: > > >>Why do I have this feeling of deja vu? >> >>I don't think this is news any longer! > > > Perhaps I was too subtle. > > ok > dpm Perhaps I should have read the whole thing but the beginning looked soooooo familiar!!!!! ------------------------------ Date: 17 Dec 2007 16:03:18 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: HP to close Nashua (ZKO) Message-ID: In article , "David P. Murphy" writes: > I was attempting to have a bit of fun at Brian's expense, but > apparently I have overestimated the number of comp.os.vms readers > who know of the VAXcave. http://www.tmesis.com/VAXcave/ Perhaps I know too much. I know I saw Alphas when I visited the VAXcave and relieved the surrounding space from a couple MV III. ------------------------------ Date: Tue, 18 Dec 2007 01:57:09 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: HP to close Nashua (ZKO) Message-ID: In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > > >In article , "David P. Murphy" writes: >> I was attempting to have a bit of fun at Brian's expense, but >> apparently I have overestimated the number of comp.os.vms readers >> who know of the VAXcave. http://www.tmesis.com/VAXcave/ > > Perhaps I know too much. I know I saw Alphas when I visited the > VAXcave and relieved the surrounding space from a couple MV III. And now a couple boxes with the "intel inside" warning labels too! I miss the one uVAX you took away. I loved fiddling about in 'ye olde qbus'. I need to borrow or buy a fish-eye lens to get a new and better picture of the VAXcave... and the VAXgarage... and the VAXbasement and... well, I have been amassing much by saving these boxes from the landfills. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Tue, 18 Dec 2007 01:06:24 -0500 From: JF Mezei Subject: Re: HP to close Nashua (ZKO) Message-ID: <2962f$47676326$cef8887a$4316@TEKSAVVY.COM> VAXman- @SendSpamHere.ORG wrote: > I need to borrow or buy a fish-eye lens to get a new and better picture > of the VAXcave... and the VAXgarage... and the VAXbasement and... well, > I have been amassing much by saving these boxes from the landfills. A word of warning though: some countries have passed fairly strict environmental regulations with regards to the disposal of computers. Should this ever happen to where you live, you may be stuck with the responsability of transporting all the stuff to some recycling centre or paying for its transportation. Compact fluorescent bulbs are an equal problem since you can't throw them in any rubbish bin (they contain mercury). And the current batch of chinese made bulbs don't last very long. (I've had one catch on fire BTW, managed to turn off power before it got out of hand). I once completely stripped the IO box for the MVII's in Q5s. This is very heavy high grade steel. Recycling didn't take it. So it was dumped in normal rubbish even though this SHOULD have been recycled. ------------------------------ Date: 17 Dec 2007 16:13:00 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Let's get back to some VMS tech talk!! Message-ID: In article <5snsucF1a8askU2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: > > If I have all the necessary hardware info, how hard is it write a device > driver for VMS? I have another 8" controller for QBUS that was never > supported by DEC but did have RT-11 drivers written by the vendor so > it did work there. Would it be reaosnable to try to write and install > a device driver for this card or is it likely more work than it would > be worth and not likely to succeed. A driver is not too hard, if you've done drivers on other systems. But you do have to pay attention to synchronisation across multiple IPL and such which many single-threaded OS hide from driver writers. You need real good documentation on how the hardware works at the software interface, of course. And if you want to make the driver talk to existing ACP or the XQP (such as to add a disk that operates as Files-11), you need the source listing CD as those interfaces are undocumented. If you've never written a VMS device driver you need to read the guide closely, twice. Then you'll have a good start at knowing which context you're in in each routine you write. Expect to keep track of process vs. system context, and at least 3, probably 4 IPL levels. Since you said Qbus, italmost must be a VAX, so you'll be working in Macro-32. If you haven't done that for a while then practice with some ordinary little user mode applications first, you don't want to be wondering about the instruction set in the middle of driver writing. ------------------------------ Date: 17 Dec 2007 22:25:20 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Let's get back to some VMS tech talk!! Message-ID: <5sobagF1a797nU2@mid.individual.net> In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article <5snsucF1a8askU2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: >> >> If I have all the necessary hardware info, how hard is it write a device >> driver for VMS? I have another 8" controller for QBUS that was never >> supported by DEC but did have RT-11 drivers written by the vendor so >> it did work there. Would it be reaosnable to try to write and install >> a device driver for this card or is it likely more work than it would >> be worth and not likely to succeed. > > A driver is not too hard, if you've done drivers on other systems. > But you do have to pay attention to synchronisation across multiple > IPL and such which many single-threaded OS hide from driver writers. > > You need real good documentation on how the hardware works at the > software interface, of course. > > And if you want to make the driver talk to existing ACP or the XQP > (such as to add a disk that operates as Files-11), you need the > source listing CD as those interfaces are undocumented. > > If you've never written a VMS device driver you need to read the > guide closely, twice. Then you'll have a good start at knowing which > context you're in in each routine you write. Expect to keep track of > process vs. system context, and at least 3, probably 4 IPL levels. > > Since you said Qbus, italmost must be a VAX, so you'll be working in > Macro-32. If you haven't done that for a while then practice with > some ordinary little user mode applications first, you don't want > to be wondering about the instruction set in the middle of driver > writing. Well, that kills that. I know where my strengths and weaknesses are. Files-11 is precisely what I was looking at so I think this is beyond my abilities. Hmmm.... Wonder if I can write something for BSD that will be able to read Files-11. Probably easier. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 17 Dec 2007 21:51:09 +0100 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) Subject: Re: Timezone rule change won't stick! Message-ID: <4766ef4d$1@news.langstoeger.at> In article <9d677706-3b47-4ada-ba17-b8320194495a@c4g2000hsg.googlegroups.com>, ChrisL writes: >We have several DS15 alphas running VMS 7.3-2 with DTSS, all of them >currently have a problem which will show up at the next clock change >in March. > >show log SYS$TIMEZONE_RULE gives the following output. > "SYS$TIMEZONE_RULE" = "GMT0BST-1,M3.4.0/01,M10.4.0/02" (LNM >$SYSTEM_TABLE) > >If this rule is used in March our clocks will go forward a week early. > >The rule should be > "GMT0BST-1,M3.5.0/01,M10.5.0/02" Look again after 1-JAN-2008 and see if you're surprised then ;-) http://groups.google.com/group/comp.os.vms/browse_thread/thread/49da4a489c83cb8f/085e42eb2f7517f0 HIH -EPLAN PS: Isn't WET your correct timezone? -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------ Date: Mon, 17 Dec 2007 13:14:05 -0800 (PST) From: ChrisL Subject: Re: Timezone rule change won't stick! Message-ID: On Dec 17, 8:51 pm, pe...@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) wrote: > >The rule should be > > "GMT0BST-1,M3.5.0/01,M10.5.0/02" > > Look again after 1-JAN-2008 and see if you're surprised then ;-) > > http://groups.google.com/group/comp.os.vms/browse_thread/thread/49da4... > > HIH > > -EPLAN > > PS: Isn't WET your correct timezone? > -- > Peter "EPLAN" LANGSTOEGER > Network and OpenVMS system specialist > E-mail pe...@langstoeger.at > A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist Have to be honest Peter that thread didn't clear things up a great deal for me, (I'll give it another read tomorrow when I'm awake!). As far as whether we should be using WET, I don't know? I thought the Europe/London combo gave me the GMT string I got (and we are in the UK). Thanks Chris ------------------------------ Date: 17 Dec 2007 16:00:49 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Unix for VMS guys Message-ID: <7ex4kcDi9m+W@eisner.encompasserve.org> In article <5snsmbF1a8askU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: > > Didn't say that. But, given your bias and my (rather extensive) experience > I have my doubts. Kind of like me pointing out VMS shortcomings and saying > all you experts are just plain wrong.... So how many decades of UNIX experience do I need to recall correctly that vipw screwed up a Solaris system? ------------------------------ Date: 17 Dec 2007 22:22:58 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Unix for VMS guys Message-ID: <5sob62F1a797nU1@mid.individual.net> In article <7ex4kcDi9m+W@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article <5snsmbF1a8askU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: >> >> Didn't say that. But, given your bias and my (rather extensive) experience >> I have my doubts. Kind of like me pointing out VMS shortcomings and saying >> all you experts are just plain wrong.... > > So how many decades of UNIX experience do I need to recall correctly > that vipw screwed up a Solaris system? You win, I give up. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Mon, 17 Dec 2007 23:36:18 GMT From: gerry77@no.spam.mail.com Subject: Re: VMS 5.5-2 patch question Message-ID: On Mon, 17 Dec 2007 11:37:57 +0000, "R.A.Omond" wrote: > > [1] http://decnet.ipv7.net/index.html.en > > Gerry77, that's very impressive! Tomorrow it will be just a year since we saw our first DECnet frames travelling thru the Internet. At first everything was difficult and connections were quite unreliable, but now it works almost flawlessy! It was a daunting project and we are really proud of our achievement. Sometimes we don't ever fully realize what we have done and how far we went since those early days. > I'd be interested to learn more about Retro DECnet. Just write me privately. The address in the header of this message is good, execpt for the obvious antispam addition that has to be removed. > I'd be willing to donate to your efforts. Anything, hardware or software, will be very much appreciated! :-) G. ------------------------------ Date: Mon, 17 Dec 2007 15:58:59 -0800 From: "Tom Linden" Subject: Re: VMS 5.5-2 patch question Message-ID: On Sun, 16 Dec 2007 09:03:57 -0800, wrote: > In article <47655712$1@news.langstoeger.at>, peter@langstoeger.at (Peter > 'EPLAN' LANGSTOeGER) writes: >> In article , >> gerry77@no.spam.mail.com writes: >>> I'm about to patch a newly installed VMS 5.5-2 (Hobbyist MicroVAX II) >> >> Strange. As even such an old uVAX2 can run V7.3, >> I don't understand why you want to do this. Think again, please. >> > Maybe he has ported some software and wants to see whether it will > compile > under VMS 5.5-2 ? VAX VMS 5.5-2 seems to be a fairly common earliest > supported > version for a number of software packages eg TCPWARE, MULTINET etc We still keep one system around for PL/I support. > > > David Webb > Security team leader > CCSS > Middlesex University > > >>> and noticed that VAXCLIU03_U2055 requires VAXVERI01_071, as per its >>> cover letter. >> >> On ITRC & in patches & cover letters there are often such silly bugs. >> If you ask at HPQ, the bugs get fixed most of the times (but >> unfortunately >> not always) and then all is clear again - until the next bug of course. >> (eg. current OpenVMS Alpha V8.3 master list states that VMS83A_MOUNT96 >> V3 >> is current and replaces the old VMS83A_MOUNT96 V3 which is now included >> in >> VMS83A_UPDATE V5 - it is of course VMS83A_MOUNT96 V4 which is current >> now ;-), >> But I don't think, that anyone ever fixes such an old version now. >> >> A _071 ECO is for VMS V7.1 only. You need _U2055 ECOs. >> >>> Unfortunately the latter is not available on the usual >>> ftp://ftp.itrc.hp.com server: I've discovered that it was superseded >>> by VAXY2K01_071 which appears to be a VMS 7.1 patch only. >> >> Yup. ECOs for V5.5-2 are not there (as everything not even is PVS - >> like VMS Vx - V5, V6.0 - V6.1, V7.0 - V7.1 - is archived now). >> They are here: >> >> ftp://ftp.itrc.hp.com/archived_patches/openvms_patches/vax/5.X/v5.5-2/ >> ftp://ftp.itrc.hp.com/archived_patches/openvms_patches/vax5x.html >> >> Unfortunately, there are no master ECO lists for the old VMS versions. >> You have to read all cover letters yourself to find out, what is >> required. >> I'm wondering, if someone did such a list in the last years and posted >> it >> somewhere (openvms.org?)... >> >>> The Year 2000 patch for VMS 5.5-2 is VAXY2K01_U2055 which in turn >>> supersedes VAXVERI01_U2055. Maybe VAXVERI01_071 is a multi-version >>> remedial kit and VAXVERI01_U2055 is its 5.5-2 specific issue? >> >> Don't think so. >> >>> If I'll just install VAXY2K01_U2055 do you think that VAXCLIU03_U2055 >>> requirements will be satisfied? >>> >>> What I'm supposed to do? >> >> Think again (and maybe you end up on V7.3) >> and/or read again (if you haven't done the URLs of above already) >> >> >> -- >> Peter "EPLAN" LANGSTOEGER >> Network and OpenVMS system specialist >> E-mail peter@langstoeger.at >> A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Mon, 17 Dec 2007 11:02:28 -0800 From: Malcolm Dunnett Subject: Re: Why can't I use an IA64 as a boot server for an Alpha? Message-ID: <4766c7c5$1@flight> Malcolm Dunnett wrote: > I could use an ATA drive in the DS10L, but performance of these in > the DS10L is fairly poor and I wouldn't have any redundancy for the > system disk. > > I guess I need to do a bit more testing to decided between the > "supported but slow" local ATA disk vs the "unsupported but fast" > network served disk. > Just did a fairly simple-minded test but it's probably indicative of relative performance. I did an image copy of the Alpha system disk (being served from the Rx2600) to a local ATA drive on the DS10L. I then ran an image backup of both disk images to NL: (to get the relative time to read from each disk). There's about 5GB of data in the system disk image. The image backup to NL: of the MSCP served disk (10K Ultra 160 SCSI drives in a RAID-5 set on a Smart Array controller in the RX2600) took 1 minute and 46 seconds. The image backup of the local ATA disk on the DS10L to NL: (with identical data) took 18 minutes 22 seconds. It appears there's a big performance win with using the "unsupported" MSCP served disk vs the local ATA disk. ------------------------------ Date: Mon, 17 Dec 2007 14:59:08 -0500 From: JF Mezei Subject: Re: Why can't I use an IA64 as a boot server for an Alpha? Message-ID: <6d655$4766d506$cef8887a$10861@TEKSAVVY.COM> Malcolm Dunnett wrote: > That's all I was really getting at with my original post. I can't > see any technical reason it shouldn't work just fine and I was wondering > if anyone had any insights into hidden showstoppers or if it's just a > case of "we haven't tested that sufficiently yet". The VMS community has , for a long time, been able to distinguish between "supported" and "not supported but it may work". So it is suprising that they would have gone out of their way to make LANCP on IA64 disregard MOP requests if the remote node is configured as Alpha but serve the request if it is configured as an IA64. In LANCP, does /BOOT_TYPE serve any purpose other than being informative ? (aka: does MOP respond differently if the request comes from an Alpha, VAX, IA64 or DECSERVER ?) ------------------------------ Date: Mon, 17 Dec 2007 21:37:29 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: Why can't I use an IA64 as a boot server for an Alpha? Message-ID: Malcolm Dunnett writes: > Just did a fairly simple-minded test but it's probably indicative >of relative performance. I did an image copy of the Alpha system >disk (being served from the Rx2600) to a local ATA drive on >the DS10L. I then ran an image backup of both disk images to NL: >(to get the relative time to read from each disk). There's about >5GB of data in the system disk image. >The image backup to NL: of the MSCP served disk (10K Ultra 160 SCSI >drives in a RAID-5 set on a Smart Array controller in the RX2600) took >1 minute and 46 seconds. The image backup of the local ATA disk >on the DS10L to NL: (with identical data) took 18 minutes 22 seconds. >It appears there's a big performance win with using the "unsupported" >MSCP served disk vs the local ATA disk. I've long suspected the VMS ATA disk driver code uses programmed I/O or some other hideously slow method that PCs haven't used since Windows 3.1 or so. ------------------------------ Date: Mon, 17 Dec 2007 15:33:05 -0800 From: Malcolm Dunnett Subject: Re: Why can't I use an IA64 as a boot server for an Alpha? Message-ID: <47670731.5060903@spammers.are.scum> JF Mezei wrote: > The VMS community has , for a long time, been able to distinguish > between "supported" and "not supported but it may work". So it is > suprising that they would have gone out of their way to make LANCP on > IA64 disregard MOP requests if the remote node is configured as Alpha > but serve the request if it is configured as an IA64. My guess is that the intention is that you could share a common LANCP database between the Alpha and the IA64 nodes in the cluster and that each architecture would only respond to requests from clients identified as being its kind of system. This seems a bit odd as IA64 clients don't use MOP to boot, but perhaps there was once an intent that they would? > > In LANCP, does /BOOT_TYPE serve any purpose other than being informative > ? (aka: does MOP respond differently if the request comes from an Alpha, > VAX, IA64 or DECSERVER ?) If you define the client as being a VMS system of any flavour then MOP adds extra data which allows the client to find the boot server and make an MSCP connection to it ( for use after the primary bootstrap has finished ). If I define the node as "/OTHER" then APB is loaded but it's unable to find the system disk to continue with the boot process. I didn't try defining the DS10L as a VAX - my guess is that LANCP on the RX2600 would also ignore those. ------------------------------ Date: Mon, 17 Dec 2007 15:35:58 -0800 From: Malcolm Dunnett Subject: Re: Why can't I use an IA64 as a boot server for an Alpha? Message-ID: <476707df$1@flight> JF Mezei wrote: > The VMS community has , for a long time, been able to distinguish > between "supported" and "not supported but it may work". So it is > suprising that they would have gone out of their way to make LANCP on > IA64 disregard MOP requests if the remote node is configured as Alpha > but serve the request if it is configured as an IA64. My guess is that the intention is that you could share a common LANCP database between the Alpha and the IA64 nodes in the cluster and that each architecture would only respond to requests from clients identified as being its kind of system. This seems a bit odd as IA64 clients don't use MOP to boot, but perhaps there was once an intent that they would? > > In LANCP, does /BOOT_TYPE serve any purpose other than being informative > ? (aka: does MOP respond differently if the request comes from an Alpha, > VAX, IA64 or DECSERVER ?) If you define the client as being a VMS system of any flavour then MOP adds extra data which allows the client to find the boot server and make an MSCP connection to it ( for use after the primary bootstrap has finished ). If I define the node as "/OTHER" then APB is loaded but it's unable to find the system disk to continue with the boot process. I didn't try defining the DS10L as a VAX - my guess is that LANCP on the RX2600 would also ignore those. ------------------------------ Date: Tue, 18 Dec 2007 00:54:08 -0500 From: JF Mezei Subject: Re: Why can't I use an IA64 as a boot server for an Alpha? Message-ID: <7f070$47675fd5$cef8887a$7458@TEKSAVVY.COM> Malcolm Dunnett wrote: > This seems a bit odd as IA64 clients don't use MOP to boot, but > perhaps there was once an intent that they would? I seem to recall that lack of MOP client on IA64 was known very very early into the porting process. Looking at the LANCP.EXE on Alpha 8.3, I see mention of ALPHA_SATELLITE I64_SATELLITE VAX_SATELLITE OTHER However, looking at LANACP.EXE, it gets stranger: There is no mention of I64 or IA64 in there. And consider this: If LANACP needs to append VAXVMSSYS.PAR, ALPHAVMSSYS.PAR or whatever parameter file is used by those IA64 contraptions, then it is quite interesting that you would have had auccess in feeding an Alpha satellite its own ALPHAVMSSYS.PAR file if it was defined as a I64_SATELLITE My only exprience was an alpha booting from a VAX boot node. And since VAX LANCP is different code base, it doesn't apply. If Alpha does allow VAXes to MOP boot, I am puzzled why an IA64 wouldn't support an Alpha booting off it since it has the same code as on Alpha. Perhaps your experience is a fluke that points to a bug where specifying I64_SATELLITE gets treated as ALPHA_SATELLITE. The problem is that this "feature" might get fixed some day and the MOP booting would no longer work because it would no longer append the right parameter file (or find it). Perhaps this should be reported to the current onwer of VMS so that, should the codebase of LANACP ever be opened again, they would ensure IA64 can respond to Alpha and VAX requests even if it is not supported (or at the very least not break the current way of faking an IA64 satellite to feed an Alpha its APB and parameter files. ------------------------------ End of INFO-VAX 2007.691 ************************