INFO-VAX Sun, 11 Mar 2007 Volume 2007 : Issue 139 Contents: Re: OpenVMS Alpha Source Code listing QB-MT1AB-E8 Re: OT: IBM's Power to power Boeing's 787 Re: SAMBA on OpenVMS with OS X client RE: Time zone/DST change question. ---------------------------------------------------------------------- Date: Sat, 10 Mar 2007 15:35:00 -0500 From: Stephen Hoffman Subject: Re: OpenVMS Alpha Source Code listing QB-MT1AB-E8 Message-ID: The OpenVMS source license was around US$25K. (I don't know off-hand if anyone bought a source license.) The expurgated source listings distributions are priced slightly over US$2K, and are available in the price book. CD for OpenVMS Alpha. DVD for OpenVMS I64. Various part numbers have been in the OpenVMS FAQ for a while now, though I've not gone looking for the most recent part numbers. I know of a number of folks that have purchased the source listings kits. The compilers used in the OpenVMS system builds are the standard compilers. The complex part of the build involve the very large-scale build procedures, and pieces outside the listing including Rdb, VDE, SDL, GNM, CMS and other and lesser-known pieces. Some are available, and some are not. The compilers used within the OpenVMS system build are specific versions of the various commercially-available compilers. The compilers are tracked and maintained as part of the source build; they're (also) considered to be input into the build. These compilers are either the native compilers or the cross-compilers, depending on the platform and whether or not the so-called native builds are in place and in use. I've presented details on the OpenVMS source code and build environment at various of DEC/Compaq/HP events over the years, and at least some of these presentations are undoubtedly available for download from various sites -- somewhere 'round the 'net. There are the usual and seemingly infinite numbers of discussions of porting OpenVMS around, as well, whether you're downgrading to 8086 or x86-32, or moving over to x86-64 (which has some true weirdnesses, but is still rather better in aggregate than x86-32), or looking at a port to TRIPS or to some other newer architecture. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Sat, 10 Mar 2007 22:12:15 -0000 From: "John Wallace" Subject: Re: OT: IBM's Power to power Boeing's 787 Message-ID: <45f32d43$0$8730$ed2619ec@ptn-nntp-reader02.plus.net> "Peter 'EPLAN' LANGSTOeGER" wrote in message news:45f1cb58$1@news.langstoeger.at... > Didn't VxWorks originate on Alpha? No. It's probably safe to assume you were writing your response to Michael Unger at the same time as I was writing mine. Would I also be safe to assume that, if you've now read mine, the history is a little bit clearer? > I also don't know how if any the similarities of VAXeln and VwWorks are Oddly enough I wrote a few words on this subject in the "History of VMS" thread not many days ago; basically there were far more differences than similarities between VAXeln and (any) VxWorks. They're both realtime OSes, in the same way that BSD and System V were both Unixes in the 1980s, and in the same way that (at that time) a non-trival BSD application likely would need a redesign for System V, a non-trivial VAXELN application would likely need a redesign for VxWorks. For starters, VxWorks for Alpha was a 64bit world, VAXELN was 32bit. Then there were significant underlying architectural differences between the OSes, along with other differences like VxWorks being hosted on Unix whereas VAXeln is hosted on VAX/VMS, and VxWorks (at that time) realistically only did C and Ada whereas VAXeln did lots of languages (not just Pascal, C, and Ada). There were also other little details like rather different inter-process comms, and VxWorks not doing DECnet. Both OSes already had their POSIX-compliance layers for the RT bits of POSIX, though DEC re-worked the ones for VxWorks for Alpha (I think DEC and WRS may have had different views on how seriously to take POSIX compliance). A "VAXeln API for VxWorks for Alpha" was developed and offered, but architectural differences including those above meant it could only usefully cover a limited subset of the VAXeln routines. Put another way, sensible customers looking to move beyond VAX and VAXeln in most cases would have likely restarted the whole hardware+software thing from scratch, and sensible customers needing the power of Alpha in a "soft realtime" (non-embedded) system might have done well to look at Tru64 (once the RT stuff came in) rather than VxWorks for Alpha. I had a few Alpha customers do soft-RT stuff on Tru64, and in a couple of cases, on VMS. Any customers who ended up using the VAXeln compatibility API for real must have had very specific requirements; I never came across anyone using it, although a handful of my customers tested the water with VxWorks for Alpha. The newsgroup comp.os.vxworks has a tiny handful of questions about Alpha, and even fewer about the VAXeln API, typically from potential users seeking real user experience, but getting no real answers. I have to wonder what kind of decision process led to the VAXeln API for VxWorks being developed at all. In fact the whole history of VxWorks for Alpha (which started life on Ultrix/MIPS labelled as DECelx, presumably in order to *obscure* its VxWorks heritage!) was a bit messy in commercial terms (I'd best leave it at that). DEC E+RT guru (?) Doug Jensen used to wax lyrical about a vision called Libra which was going to be a truly wonderful distributed/embedded RT OS but it never really came to fruition. He's now at MITRE and still writing about the subject, more at http://www.real-time.org/ Hth John ------------------------------ Date: Sat, 10 Mar 2007 21:09:32 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: SAMBA on OpenVMS with OS X client Message-ID: <00A646B6.F3AD6878@SendSpamHere.ORG> In article , Paul Sture writes: > > >In article <00A645ED.385CEFB1@SendSpamHere.ORG>, > VAXman- @SendSpamHere.ORG wrote: > > >> >> To whomever is working on this at HP, Samba has got to work with ODS-5 >> >> volume shares. >> >> >> > >> >Roundly seconded. >> >> As long as it is not a problem when using a Micro$hite Weendoze machine, >> there's no way they're going to bother with this issue. > >Well, didn't you say you had access to such an abomination? >Just for testing purposes only of course, to eliminate the OS X side. I do. Remotely via VNC. Unfortunately, after goign through an exercise to allow a friend to send me some files over the internet from her Mac- Book out in the Bay area, I learned that my ISP has port 139 blocked on all of their routers due to some PeeCee virus. So, testing with a Bill- zebub box is impossible. > > > >But, seeing your directory named [GigsOfPixOfGigs] has reminded me of >another potential problem facing you, namely that OS X chokes on large >Samba directores, which you see in the Google discussion below. > >http://preview.tinyurl.com/yqfkec > >I tested this at the time and found similar. It appears that Windies is >caching something which OS X doesn't. > >If you thought large directories on VMS were slow pre 7.3 (?), you ain't >seen nothing yet, and at the moment I'm seeing over 1400 Bufios/sec on >my PWS 600au. Not pleasant at all. > > >BTW, for anyone who wants to generate a large bunch of text files for >testing purposes (search engines or whatever), download the WIZARD.ZIP >file - it contains over 8,000 text files. Well, it's completely moot now. I installed the PCSI kits for updating PCSI, some massive UPDATE-11, and the TZ update and SAMBA will no longer server ODS-5 volumes. Back to square #1. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" ------------------------------ Date: Sat, 10 Mar 2007 17:01:54 -0500 From: "Main, Kerry" Subject: RE: Time zone/DST change question. Message-ID: > -----Original Message----- > From: Neil Rieck [mailto:n.rieck@sympatico.ca]=20 > Sent: March 7, 2007 3:17 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Time zone/DST change question. >=20 [snip...] > > > I know of at least three Tru64 machines in Canada that are=20 > going to have=20 > problems. It's not like somebody couldn't figure out a=20 > work-around but=20 > support for these machines has been out-sourced to a=20 > contractor. I suspect=20 > the contractor is going to wait for somebody to phone in for=20 > $upport on=20 > $unday or Monday >=20 > Neil Rieck > Kitchener/Waterloo/Cambridge, > Ontario, Canada. > http://www3.sympatico.ca/n.rieck/links/cool_openvms.html > http://www3.sympatico.ca/n.rieck/links/openvms_demos.html >=20 >=20 Neil, Are you saying that there are problems with the posted Tru64 DST Patches at: http://h30097.www3.hp.com/unix/erp/c00849060.html Btw, I am assuming everyone knows that the DST issues also relate to servers, storage controllers, network and just about every PDA as well? www.hp.com/go/dst has tabs on other devices that folks should at least review to see if any are applicable to them. Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 OpenVMS - the secure, multi-site OS that just works. ------------------------------ End of INFO-VAX 2007.139 ************************