INFO-VAX Sat, 13 Jan 2007 Volume 2007 : Issue 26 Contents: Alpha Server 1200 memory configuration quiz Re: Alpha Server 1200 memory configuration quiz Re: DFU comments Re: DFU comments Re: DFU comments Re: MicroVAX IIs/BA123s in Demand? Re: Replacement for the TK70 Re: Replacement for the TK70 ---------------------------------------------------------------------- Date: Sat, 13 Jan 2007 11:44:56 +0100 From: "H Vlems" Subject: Alpha Server 1200 memory configuration quiz Message-ID: <45a8b70f$0$23770$bf4948fe@news.tele2.nl> System description: Alpha Server 1200 with two 5/400 cpu's and two pairs of 32 MB memory boards, 128 MB total memory. The system runs VMS V8.3, no patches (yet). We all know Digital's standard reply to performance problems: "Buy more memory", so when I found MS300-BA memory on eBay for $1.99 per stick I immediately ordered 4 pairs (yup, me big spender...). While waiting for the memory to arrive I reread the AS1200 user guide on how to install the memory, fairly simple, and the Systems&Options docs for configuration guidelines. That proved somewhat disturbing because it tells you that the AS1200 can handle up to 4 pairs of 32MB boards, or 256 MB total memory. You can't use the top four slots. The memory arrived today and it worked perfectly, so I decided to put back the original two pairs of 32MB as well. SRM reported no errors, VMS booted without a problem and SHOW MEMORY/PHYS reported 384MB. No errors. The systems has run 40 minutes, so may be problems will show up. So what is the correct explanation: a - the Systems&Options catalog has it wrong b - VMS V8.3 (or another version after V7.1-2) lifted the old restriction c - a classic case of an unsupported configuration that just happens to work in this case d - just wait another day for white smoke Any ideas? Hans ------------------------------ Date: Sat, 13 Jan 2007 11:54:26 -0500 From: Stephen Hoffman Subject: Re: Alpha Server 1200 memory configuration quiz Message-ID: H Vlems wrote: > System description: Alpha Server 1200 with two 5/400 cpu's and two pairs of > 32 MB memory boards, 128 MB total memory. The system runs VMS V8.3, no > patches (yet). > > We all know Digital's standard reply to performance problems: "Buy more > memory", so when I found MS300-BA memory on eBay for $1.99 per stick I > immediately ordered 4 pairs (yup, me big spender...). > While waiting for the memory to arrive I reread the AS1200 user guide on how > to install the memory, fairly simple, and the Systems&Options docs for > configuration guidelines. That proved somewhat disturbing because it tells > you that the AS1200 can handle up to 4 pairs of 32MB boards, or 256 MB total > memory. You can't use the top four slots. > The memory arrived today and it worked perfectly, so I decided to put back > the original two pairs of 32MB as well. SRM reported no errors, VMS booted > without a problem and SHOW MEMORY/PHYS reported 384MB. No errors. The > systems has run 40 minutes, so may be problems will show up. > > So what is the correct explanation: > a - the Systems&Options catalog has it wrong > b - VMS V8.3 (or another version after V7.1-2) lifted the old restriction > c - a classic case of an unsupported configuration that just happens to work > in this case > d - just wait another day for white smoke This may well be a combination of an old configuration limitation of OpenVMS and some poorly-worded English around the rules. EK-AS120-UG-A01 indicates you can use all eight slots, just that you must keep the bigger modules in the lower slots. And AFAIK, that was related to a restriction that no longer exists within OpenVMS -- memory holes. The piece you're probably looking at is the last rule, where you can have at most four 64 GB MS300-BA modules. QB00oDPF.PDF (lowercase letter o for visibility) lacks that particular sequence, and has a rather clearer description, and no analog to rule 4.) You use both memory risers, installing into slot 0 on each riser, and you are supposed to install the modules in order of equal or descending size starting at slot zero. This was to avoid the memory holes. Prior to V7.1?), OpenVMS didn't like to see gaps in the physical range occupied by the memory, and would register (harmless) memory errors -- bad pages -- for the pages that would have been in the physical memory address gap. Drives could also see some nastiness. There's a diagram of what a memory hole looks like in OVMS_731_REL_NOTES.PDF, and some supporting information and related code. This was specifically updated in OpenVMS for the AlphaServer 4100 series, a system which is the same family as the AlphaServer 1200. There were various confusingly-worded restrictions in the documentation for the AlphaServer 4100, in my experience. Put another way, at US$2 per pair of sticks, load it up -- why stop at 384 MB? Spend another US$4 and go for 512 MB -- and buy a few spares. But I'd not expect to encounter a problem here. And even if I'm wrong, US$4 is among the cheapest magic white smoke producers I've encountered in a while. :-) -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Sat, 13 Jan 2007 10:57:47 +0000 From: "R.A.Omond" Subject: Re: DFU comments Message-ID: JF Mezei wrote: > Since I had to delete a large directory tree many times to restart a > backup via FTP as many times, I decided to use DFU. It says it is > versions 3.1-1 > > > $MC DFU DELETE/DIR/TREE $disk2:[000000]macbackup.dir seemed easy enough > to zap everything below it. > > However, this still goes (by default) into SMG mode and still issues a > message for each and every file that is deleted, defeating its ability > to do this fast. (since progress is limited by the display speed). > > By default, DFU should perhaps display only a message for each directory > that is deleted in the tree, not for each file. /LOG could be added if > you wish to see every file. Oh come on, JF. Whilst I agree with the issue about SMG mode, you are surely well aware that you can easily achieve what you want: $ define dfu$nosmg 1 [/system :-) ] $ mcr dfu delete/dir/tree/nolog $disk2:[000000]macbackup.dir I hate anyone bitching about DFU. DFU is better than sliced bread. Sure, Ton adopted some defaults that you (and I) wouldn't. Big deal; you always have the option of choosing otherwise. ------------------------------ Date: Sat, 13 Jan 2007 07:20:01 -0500 From: JF Mezei Subject: Re: DFU comments Message-ID: <45a8cdef$0$17810$c3e8da3@news.astraweb.com> R.A.Omond wrote: > I hate anyone bitching about DFU. DFU is better than sliced bread. > Sure, Ton adopted some defaults that you (and I) wouldn't. Big > deal; you always have the option of choosing otherwise. I was not complaing about SMG, I was complaining about DFU, by default, showing each and every file it was deleting in a big directory tree. Are you saying that if I had disabled SMG, it would not have listed every file it was deleting ? And this wasn't a "complaint". Just a suggestion of what I would have expected since I had heard that DFU was so much better at deleting large amounts of files. And while I am at it, pressing does suppress the output of each file being deleted. But it also suppresses the escape sequences that reset the terminal after the command exits (I called it as a single command line from DCL, so onnce it is done, it returns to DCL). As a result, after the DCL command ends, one is stuck in a single line scrolling window at bottom of screen, so one has to do a set term/inquire to reset it. If nobody "complained", then improvements to it would not be made. ------------------------------ Date: Sat, 13 Jan 2007 12:53:01 -0500 From: Stephen Hoffman Subject: Re: DFU comments Message-ID: R.A.Omond wrote: > I hate anyone bitching about DFU. DFU is better than sliced bread. > Sure, Ton adopted some defaults that you (and I) wouldn't. Big > deal; you always have the option of choosing otherwise. DFU is an amazing tool. Probably the biggest problem with DFU is that it was never integrated into base OpenVMS. But that wasn't and isn't Ton... JF, though you might not realize it, you really want to learn more about Linux and BSD, or other such options. These can be customized to meet your exact requirements, and these solutions also clearly meet your preferred price point. And you are not beholden on any vendor for solutions or platform ports or systems or support. Ultimate software freedom. x86-32 and x86-64 hardware, too. I think it would be a very good fit for you and your applications. (I was going to suggest Darwin and Mac OS X here, but that would put you back into the same basic hardware and software situation, with x86-32 and now x86-64, though with a different vendor. And a different newsgroup. But I digress.) And as for OpenVMS, there have been various solutions -- such as deltree -- that have been around for eons, too. Check the Freeware; I know I've tossed versions of this tool onto it. I have certainly used deltree myself. But that OpenVMS itself lacks a direct analog to rm -R or deltree is a longstanding missing feature. Or DFU with tweaks. One (other) alternative approach here would be to fire up bash and aim rm -R at the directories... Or -- if somebody needed or wanted it, and was inclined to better integrate deltree with DELETE norms -- extract the DELETE verb and its alternates and replace it back in with another alternative syntax; re-insert DELETE back into the command tables as, say, DELETE /DIRECTORY_TREE [/options]. One-plus it with modifications to VERB to allow commands to be more automatically integrated are also obviously possible here. (Though the current CLD design is rather limited, particularly around surviving CLD upgrades. There are other limits within CLD, too, such as no existing integration between the CLD and getopt and related C, C++ and shell command-parsing mechanisms.) -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Sat, 13 Jan 2007 01:13:27 GMT From: "Douglas A. Gwyn" Subject: Re: MicroVAX IIs/BA123s in Demand? Message-ID: <45A83237.607DCA25@null.net> Jeff Shirley wrote: > I have a couple of MicroVAX II systems in BA123 boxes I would like to sell, > hopefully to hobbyists rather than the local scrap guy. My question is > whether it might make more sense to just pull the boards and cabinet kits, and > scrap the BA123 enclosures. From a preservationist/hobbyist point of view, it is better to keep the system intact. However, you could probably make more money selling it piecemeal. ------------------------------ Date: 13 Jan 2007 08:14:19 -0800 From: "AEF" Subject: Re: Replacement for the TK70 Message-ID: <1168704856.643663.29740@s34g2000cwa.googlegroups.com> Stephen Hoffman wrote: > Island Computers, D B Turner wrote: [...] > Ancient hardware issues aside (and the TK70 series drive is, what, > twenty years old?), DLT drives and media are far more reliable than > DDS/DAT low-end cartridge drives. I know of several places that "got What about high-end DDS/DAT drives? Is there such a species? Or are all DDS/DAT drives "low-end"? > cheap" with their archival devices, and subsequently regretted it when > they discovered they had a complete set of write-only archives, or I think of them as write-probably/read-maybe drives. :-) [...] > -- > www.HoffmanLabs.com > Services for OpenVMS AEF ------------------------------ Date: Sat, 13 Jan 2007 13:41:13 -0500 From: Stephen Hoffman Subject: Re: Replacement for the TK70 Message-ID: AEF wrote: > Stephen Hoffman wrote: >> Island Computers, D B Turner wrote: > [...] >> Ancient hardware issues aside (and the TK70 series drive is, what, >> twenty years old?), DLT drives and media are far more reliable than >> DDS/DAT low-end cartridge drives. I know of several places that "got > > What about high-end DDS/DAT drives? Is there such a species? Or are all > DDS/DAT drives "low-end"? I would personally place all DDS (DAT) tape drives in the low-end of available tape options. Look at rated media lifetimes; typical DDS media is rated for 2,000 head passes, and you can reach that quickly with the typical reading and re-reading and re-writing of the tape label area with the usual multiple-step MOUNT, BACKUP, [whatever,] DISMOUNT sequence. Toss in /VERIFY for good measure, and for extra wear. DLT media is rated for a million passes or so. DLT has better EDC, as well. Four 4KB blocks per twenty blocks can be recovered, IIRC. I would also tend to expect to replace heavily-used DDS drives every few years, and I would tend to expect to get maybe thirty uses of a piece of media given typical cycles, and I would expect to have occasional problems reading the media. I certainly would not expect to archive DDS media. TANSTAAFL. There Ain't No Such Thing As A Free Lunch. DDS drives are far cheaper than DLT drives. There's a reason for that. DDS is a good technology and a good choice for desktop system BACKUPs, and for occasional BACKUP operations, and for media interchange. And I would expect to have a regular order of DDS cartridges scheduled. DDS drives are not something I would personally initially choose for production-sensitive usage; for use with more valuable data, for heavy use, or for longer-term archival storage. I'd personally tend to look toward DLT for these environments. Or near-line disk. DVD+RW is in the same target market ballpark as DDS, in terms of my experience with media and media re-use. DVD+R media is cheap enough that throw-away is an option, for smaller data archives. HD DVD and BD (Blu-ray Disk) up the media capacity, but I'd be surprised if the HD/BD media lifetimes for rewritable/re-recordable significantly better than current volume DVD media. Good choice for small/low volume archive operations, and the hardware and media can be very economical. As for cost-sensitive production environments (and cases where I had more staff time than hardware), I might well choose to scrounge an older (and cheaper) DLT and its media, and to carefully size and target what data I was centrally archiving. The rational for archiving data is to be able to retrieve the data if/when that becomes necessary. Otherwise, it's a waste of time and hardware. A production site can restore OpenVMS itself from a distro or from a (reliable) BACKUP made as the system goes into production, and typical sites don't make frequent changes to OpenVMS itself or to ancillary pieces such as the system startups. When changes are made, spin another DLT. Or a set of DLTs, if you are as far back in the product line as TK70, TZ87, or... -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ End of INFO-VAX 2007.026 ************************