INFO-VAX Sun, 14 Jan 2007 Volume 2007 : Issue 27 Contents: Re: 1,000,000 License PAK's Served! Re: Alpha Server 1200 memory configuration quiz Re: Alpha Server 1200 memory configuration quiz Re: Alpha Server 1200 memory configuration quiz Re: DFU comments Re: DFU comments Re: DFU comments Re: DFU comments Re: DFU comments PDP11 Tape Copy to VAX: DOS11_BLOCKSIZE Re: PDP11 Tape Copy to VAX: DOS11_BLOCKSIZE Re: PDP11 Tape Copy to VAX: DOS11_BLOCKSIZE Re: PDP11 Tape Copy to VAX: DOS11_BLOCKSIZE Re: PDP11 Tape Copy to VAX: DOS11_BLOCKSIZE Re: RMS-E-WLK, device currently write locked Re: RUN SYS$SYSTEM:DCL on Itanium VMS 8.2-1 Re: Strategies for keeping 2 system disks in sync TCPIP 5.x SMTP File format Re: TCPIP 5.x SMTP File format ---------------------------------------------------------------------- Date: Sun, 14 Jan 2007 02:56:03 GMT From: patrick jankowiak Subject: Re: 1,000,000 License PAK's Served! Message-ID: <45A99BBF.5020208@swbell.net> davidc@montagar.com wrote: > The OpenVMS Hobbyist Program has served it's one millionth License PAK! > > http://www.openvmshobbyist.com/blog/index.php > quite a milesone.. and it is the 10 year anniversary of the start of it all, this year. 1997-2007. DEC did listen.. Thanks so much to all who worked so hard to make it at first a reality, in those first few months after the symposium. VMS engineering, VMS marketing, and DEC legal, and the great support for the initiative from DECUS members and DEC customers. As I recall, it took DEC only 6 months to say "yes". Patrick J. ------------------------------ Date: Sat, 13 Jan 2007 15:58:22 -0500 From: Stephen Hoffman Subject: Re: Alpha Server 1200 memory configuration quiz Message-ID: H Vlems wrote: > BTW Hoff, I was afraid that the white smoke would not only come from the > memory but also from the main board. Smoked various parts of a Unibus BA-11 and its associated UBA after asking the requisite "are you _really_ sure I should use this board in there?" question. Insert board. Flip breaker. Most impressive sizzle and petite smoke. And no, that particular board never should have been inserted into any Unibus you cared about. I've certainly smoked a few other parts over the years. Been in attendance when an engineer smoked an SBI, for an arcing electrical feed for cluster of a dozen office cubicles, for various disk crashes (and back when that event involved serious quantities of rotating mass -- disk crashes now are far more boring) and for a lightning strike in the immediate vicinity of a VAX-11/730. Smoke happens... > A month ago a similar experiment with > memory boards destroyed an Alpha Server 1000A motherboard. And I haven't > been able to find a spare one (other than paying well over $700 for it). I usually look at these cases as learning experiences. As for repair, I'm sure you've looked at replacement of the whole box. Older boxes can be more expensive to repair than can be to replace. And if I'm (still) using and supporting these older boxes in production, I invest in spares. Or replacements. Years ago, I thought of these VAX and Alpha boxes as huge purchases and as permanent fixtures. Now they're tools that I can need to update or replace and that I occasionally break, and I expect to eventually transfer the data and toss the boxes out. Much like I tossed a 1601, a 4361, Prime, PDP-11s, or that poor, slightly singed VAX-11/730. And more client-level boxes than I care to count. Ok, so tossing a 1601 didn't really happen. Dragging a 1601... But I don't think you'll have ill effects with this AlphaServer 1200 box and with this memory configuration. But should you have a critical requirement for this or any other box, well, I'd look for a spare box or for spare parts -- regardless of the memory changes. This box is a tool. Do be careful with and don't mistreat the hardware, but do expect to replace it. (Well, this assuming you are not running some sort of hardware museum.) -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Sun, 14 Jan 2007 01:03:22 +0100 From: "H Vlems" Subject: Re: Alpha Server 1200 memory configuration quiz Message-ID: <45a972af$0$10323$bf4948fe@news.tele2.nl> "Stephen Hoffman" schreef in bericht news:eobh5g$2697$1@pyrite.mv.net... > H Vlems wrote: > > > BTW Hoff, I was afraid that the white smoke would not only come from the > > memory but also from the main board. > > Smoked various parts of a Unibus BA-11 and its associated UBA after > asking the requisite "are you _really_ sure I should use this board in > there?" question. Insert board. Flip breaker. Most impressive sizzle > and petite smoke. And no, that particular board never should have been > inserted into any Unibus you cared about. I've certainly smoked a few > other parts over the years. Been in attendance when an engineer smoked > an SBI, for an arcing electrical feed for cluster of a dozen office > cubicles, for various disk crashes (and back when that event involved > serious quantities of rotating mass -- disk crashes now are far more > boring) and for a lightning strike in the immediate vicinity of a > VAX-11/730. Smoke happens... > > > A month ago a similar experiment with > > memory boards destroyed an Alpha Server 1000A motherboard. And I haven't > > been able to find a spare one (other than paying well over $700 for it). > > I usually look at these cases as learning experiences. As for > repair, I'm sure you've looked at replacement of the whole box. Older > boxes can be more expensive to repair than can be to replace. And if > I'm (still) using and supporting these older boxes in production, I > invest in spares. Or replacements. Years ago, I thought of these VAX > and Alpha boxes as huge purchases and as permanent fixtures. Now > they're tools that I can need to update or replace and that I > occasionally break, and I expect to eventually transfer the data and > toss the boxes out. Much like I tossed a 1601, a 4361, Prime, PDP-11s, > or that poor, slightly singed VAX-11/730. And more client-level boxes > than I care to count. Ok, so tossing a 1601 didn't really happen. > Dragging a 1601... > > But I don't think you'll have ill effects with this AlphaServer 1200 > box and with this memory configuration. But should you have a critical > requirement for this or any other box, well, I'd look for a spare box or > for spare parts -- regardless of the memory changes. This box is a > tool. Do be careful with and don't mistreat the hardware, but do expect > to replace it. (Well, this assuming you are not running some sort of > hardware museum.) > > > -- > www.HoffmanLabs.com > Services for OpenVMS Consider me lucky, or very careful with hardware (which I am), but the most expensive thing I was able to smoke was 32 kB of core memory attached to a PDP 11/40. I fitted the flatcables into the wrong slot of the backplane, come to think of it, it may have been the correct slot but the wrong section of it. I don't really expect the Alpha Server 1200 to be damaged by this configuration. Not after it has been running for about 14 hours. I do expect to have to replace hardware in the future. But it is privately owned equipment and as much as I prefer to write programs for VMS and run that operating system on top of "real" hardware (yes, I appreciate simh) I cannot spend huge amounts of money on a hobby. When asked I guess i'd never tell I'm running a hardware museam. but the fact that I still own my first computer (VAXstation 2000) and very occasionally power it up might indicate otherwise. The 2000 is too slow to do anything useful on today, the 1200's can still keep up. ------------------------------ Date: Sat, 13 Jan 2007 19:27:28 -0800 From: Alan Frisbie Subject: Re: Alpha Server 1200 memory configuration quiz Message-ID: <1168745184.598206@smirk> Stephen Hoffman wrote: > H Vlems wrote: > >> BTW Hoff, I was afraid that the white smoke would not only come from the >> memory but also from the main board. > Smoked various parts of a Unibus BA-11 and its associated UBA after > asking the requisite "are you _really_ sure I should use this board in > there?" question. Insert board. Flip breaker. Most impressive sizzle > and petite smoke. The electrician at a client's site mis-wired a 120 volt outlet with 240 volts. They then plugged an LN08 (DEClaser 3250) into it. Big puff of smoke. Fortunately, the smoke was from the MOVs, as they sacrificed themselves to save the rest of the LN08. After cleaning out the MOV fragments and installing new ones, it worked perfectly. Yay, DEC!!! Alan ------------------------------ Date: Sat, 13 Jan 2007 15:27:34 -0500 From: Stephen Hoffman Subject: Re: DFU comments Message-ID: Neil Rieck wrote: > > "Stephen Hoffman" wrote in message > news:eob69v$22un$1@pyrite.mv.net... >> R.A.Omond wrote: >> > [...snip...] >> >> One (other) alternative approach here would be to fire up bash and >> aim rm -R at the directories... >> > > Now there is a suggestion I never thought I'd see in this newsgroup. And > yet it would work if the keyboardist dared to digitate the suggested > incantation. JF knows Mac, and Mac OS X does rm -R, QED JF knows rm -R. :-) Well, ok, maybe dragging the folder over to the trashcan is a more common Mac OS X solution to the task. JF's other FTP character-mapping report/thread is interesting and semi-related, too, particularly around alternate considerations and details around the HFS metadata, and how that can get stripped off files, I'd probably still use zip to transfer the files over, but even that can strip off the various (other) forks. Other options could also utilize SMB or NFS or other such, and use that to "transfer" the Mac files. Character-mapping and filename mapping is very far from being as easy as it might initially be assumed. The inevitable corner cases that crop up are always ugly -- there are seemingly always cases that don't map, that don't map "right", or that are not orthagonal. HFS includes constructs not supported by OpenVMS file system -- much like how OpenVMS has file attributes and settings that are not or not directly supported by HFS. HFS stores these in forks, while OpenVMS stuffs them over in the index file. But I digress. > (forgive the flowery language but I just finished watching some > Babylon-5 DVDs and now I've got "technomage" on my mind; anyone who has > looked closely at the new Apple iPhone would be thinking "technomage" too) The Apple Talk -- um, err, the iPhone :-) -- is an embedded version of Mac OS X per various Apple statements, so you can experience some the iPhone environment using one of the existing Mac OS X platforms. And dropping into bash to script your phone calls would be entertaining... :-) -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Sat, 13 Jan 2007 16:51:13 -0500 From: JF Mezei Subject: Re: DFU comments Message-ID: <45a955fd$0$25408$c3e8da3@news.astraweb.com> Stephen Hoffman wrote: > 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. Gentlemen, this is a first: even Hoff recommends migrating from VMS to UNIX. (yeah, I know, it may be a ploy to just get rid of me, but still...) ------------------------------ Date: Sat, 13 Jan 2007 19:55:08 -0500 From: JF Mezei Subject: Re: DFU comments Message-ID: <45a97ee9$0$17817$c3e8da3@news.astraweb.com> Richard B. Gilbert wrote: > If it were possible, short of a capital offense, someone would have > gotten rid of you by now. All this from a suggestion that DFU shouldn't by default, display a delete message for each individual file when deleting a directory tree. It was my first time using the utility for such a purpose, and decided to try it out because I had been told it was so much faster than DELETE. Sorry if I have offended anyone/everyone. ------------------------------ Date: Sat, 13 Jan 2007 21:01:51 -0500 From: bradhamilton Subject: Re: DFU comments Message-ID: <45A98F0F.7050004@comcast.net> JF Mezei wrote: [...] > Sorry if I have offended anyone/everyone. This is USENET; get used to it. :-) :-) :-) :-) Actually, I was spoiled by "commercial" VMS defraggers by the time I got to DFU; I was "disappointed" at its relative lack of functionality. If it's the only thing you (or the site(s) you support) can afford, however... ------------------------------ Date: Sat, 13 Jan 2007 22:34:01 -0500 From: "Neil Rieck" Subject: Re: DFU comments Message-ID: <45a9a311$0$28069$9a6e19ea@news.newshosting.com> "Stephen Hoffman" wrote in message news:eobfbo$25k8$1@pyrite.mv.net... > Neil Rieck wrote: [...snip...] > > The Apple Talk -- um, err, the iPhone :-) -- is an embedded version of > Mac OS X per various Apple statements, so you can experience some the > iPhone environment using one of the existing Mac OS X platforms. And > dropping into bash to script your phone calls would be entertaining... > :-) > It was the touch-screen voodoo I was referring to. Two finger tips coming together signifies "zoom in" while finger tips separating "zoom out" (or was it the other way round :-) On top of that, building in accelerometers to automatically rotate the image or even turn it off if the phone is at your ear seems a little over the top. But what else would you expect for $500 ? 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 ------------------------------ Date: 13 Jan 2007 12:22:10 -0800 From: "bclaremont" Subject: PDP11 Tape Copy to VAX: DOS11_BLOCKSIZE Message-ID: <1168719727.660667.219880@51g2000cwl.googlegroups.com> Hi, I have three old 9-track, 1600bpi tapes created on a PDP-11 system using the COPY process. I don't have any more details on the process used to create the tapes than that. I am using a MicroVAX II/GPX running VMS 5.5 connected to a TU81 to read the tapes. I can copy one of the tapes to the VAX using the following EXCHANGE procedure: $ MOUNT /FOREIGN MUA0: $ EXCHANGE MOUNT/FOREIGN MUA0:/VOLUME_FORMAT=DOS11 DIRECTORY/FULL/COLUMNS=1/OUTPUT=PDP1.TXT MUA0: COPY/LOG MUA0:*.* [.PDP1]*.* DISMOUNT MUA0: EXIT $ DISMOUNT/NOUNLOAD MUA0: $ EXIT On the other two tapes, the DIRECTORY command works fine, producing a listing of the files on the tape. However, the COPY command issues the following messages for all files on the tape. Empty files with the correct file names, but no data, are created on disk. %EXCHANGE-I-NOTCOPIED, file _HOTLGS$MUA0:RGNDTA.DEF not copied to DUA1:[WHITLEY.PDP1]RGNDTA.DEF;1 %EXCHANGE-I-DOS11_POSITION, rewinding tape to recover correct positioning %EXCHANGE-W-DOS11_BLOCKSIZE, volume on _HOTLGS$MUA0: has block larger than 512 bytes %EXCHANGE-I-NOTCOPIED, file _HOTLGS$MUA0:RMSDTF.DEF not copied to DUA1:[WHITLEY.PDP1]RMSDTF.DEF;1 %EXCHANGE-I-DOS11_POSITION, rewinding tape to recover correct positioning %EXCHANGE-W-DOS11_BLOCKSIZE, volume on _HOTLGS$MUA0: has block larger than 512 bytes I have tried various block size settings in multiples of 512 on the DCL MOUNT command. I have also tried different RECORD_FORMAT settings within EXCHANGE. I even tried creating a virtual RT11 volume to copy to: $ EXCHANGE init/create/alloc=32000 mt.dsk mount/virt dt: mt.dsk copy mua0:*.* dt:/allo=1/trans=block copy/log dt:*.* [.pdp2]*.* exit $ EXIT In all cases, the behavior and messages issued by the COPY command are the same. I ran across this in the OpenVMS System Messages and Recovery Procedures Reference Manual, which is not encouraging: DOS11_BLOCKSIZE, volume on ' tape ' has block larger than 512 bytes Facility: EXCHANGE, Exchange Utility Explanation: While reading a DOS-11 magtape, the Exchange Utility has read a block which is longer than 512 bytes. User Action: The file containing the long block cannot be processed by EXCHANGE. It seems odd to me that the DIRECTORY command works, but the COPY does not. Can anyone offer any suggestions on a resolution to this problem? Thanks, Bruce Claremont www.MigrationSpecialties.com OpenVMS Stealth Marketing Squad ------------------------------ Date: Sat, 13 Jan 2007 23:24:07 +0100 From: Paul Sture Subject: Re: PDP11 Tape Copy to VAX: DOS11_BLOCKSIZE Message-ID: In article <1168719727.660667.219880@51g2000cwl.googlegroups.com>, "bclaremont" wrote: > Hi, > > I have three old 9-track, 1600bpi tapes created on a PDP-11 system > using the COPY process. I don't have any more details on the process > used to create the tapes than that. I am using a MicroVAX II/GPX > running VMS 5.5 connected to a TU81 to read the tapes. I can copy one > of the tapes to the VAX using the following EXCHANGE procedure: > > $ MOUNT /FOREIGN MUA0: > $ EXCHANGE > MOUNT/FOREIGN MUA0:/VOLUME_FORMAT=DOS11 > DIRECTORY/FULL/COLUMNS=1/OUTPUT=PDP1.TXT MUA0: > COPY/LOG MUA0:*.* [.PDP1]*.* > DISMOUNT MUA0: > EXIT > $ DISMOUNT/NOUNLOAD MUA0: > $ EXIT > > On the other two tapes, the DIRECTORY command works fine, producing a > listing of the files on the tape. However, the COPY command issues the > following messages for all files on the tape. Empty files with the > correct file names, but no data, are created on disk. > > %EXCHANGE-I-NOTCOPIED, file _HOTLGS$MUA0:RGNDTA.DEF not copied to > DUA1:[WHITLEY.PDP1]RGNDTA.DEF;1 > %EXCHANGE-I-DOS11_POSITION, rewinding tape to recover correct > positioning > %EXCHANGE-W-DOS11_BLOCKSIZE, volume on _HOTLGS$MUA0: has block larger > than 512 bytes > %EXCHANGE-I-NOTCOPIED, file _HOTLGS$MUA0:RMSDTF.DEF not copied to > DUA1:[WHITLEY.PDP1]RMSDTF.DEF;1 > %EXCHANGE-I-DOS11_POSITION, rewinding tape to recover correct > positioning > %EXCHANGE-W-DOS11_BLOCKSIZE, volume on _HOTLGS$MUA0: has block larger > than 512 bytes > > I have tried various block size settings in multiples of 512 on the DCL > MOUNT command. I have also tried different RECORD_FORMAT settings > within EXCHANGE. I even tried creating a virtual RT11 volume to copy > to: > > $ EXCHANGE > init/create/alloc=32000 mt.dsk > mount/virt dt: mt.dsk > copy mua0:*.* dt:/allo=1/trans=block > copy/log dt:*.* [.pdp2]*.* > exit > $ EXIT > > In all cases, the behavior and messages issued by the COPY command are > the same. > > I ran across this in the OpenVMS System Messages and Recovery > Procedures Reference Manual, which is not encouraging: > > DOS11_BLOCKSIZE, volume on ' tape ' has block larger than 512 bytes > Facility: EXCHANGE, Exchange Utility > Explanation: While reading a DOS-11 magtape, the > Exchange Utility has read a block which is longer than > 512 bytes. > User Action: The file containing the long block cannot > be processed by EXCHANGE. > > It seems odd to me that the DIRECTORY command works, but the COPY does > not. Can anyone offer any suggestions on a resolution to this problem? > The first thing I'd try is, with the tape mounted foreign: $ COPY / LOG MUA0:*.* [.somewhere] then you can use DUMP to analyze the resulting disk files at your leisure, and reduce the chances of damaging these old tapes just be repeated attempts to read them. -- Paul Sture ------------------------------ Date: 13 Jan 2007 17:22:26 -0800 From: "bclaremont" Subject: Re: PDP11 Tape Copy to VAX: DOS11_BLOCKSIZE Message-ID: <1168737746.729496.303650@q2g2000cwa.googlegroups.com> Good suggestion, but the copy doesn't work. I get either a data overrun or a %COPY-F-OPENOUT error. ------------------------------ Date: Sat, 13 Jan 2007 19:58:51 -0700 From: Jeff Campbell Subject: Re: PDP11 Tape Copy to VAX: DOS11_BLOCKSIZE Message-ID: <1168743612_1209@sp6iad.superfeed.net> bclaremont wrote: > Good suggestion, but the copy doesn't work. I get either a data > overrun or a %COPY-F-OPENOUT error. > You might try VMSTPC from one of the freeware distributions. Jeff ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups ----= East and West-Coast Server Farms - Total Privacy via Encryption =---- ------------------------------ Date: 13 Jan 2007 21:30:34 -0800 From: "bclaremont" Subject: Re: PDP11 Tape Copy to VAX: DOS11_BLOCKSIZE Message-ID: <1168752634.550221.69770@m58g2000cwm.googlegroups.com> Using the DUMP command confirmed a block size of 4096. Using the VMSTPC command, I was able to copy the contents of the tape to disk: HOTLGS> mount/for/block=4096 mua0: %MOUNT-I-WRITELOCK, volume is write locked %MOUNT-I-MOUNTED, mounted on _HOTLGS$MUA0: HOTLGS> tc/dos11/block=4096 mua0: pdp2.con Tape dump starting to DUA1:[WHITLEY]PDP2.CON; File marks: 737 Records: 1770 CPU TIME = 0:00:11.15 HOTLGS> dism/nounload mua0: HOTLGS> I can dump and edit the resulting file, PDP2.CON. It does not appear that I can reference the file as a virtual volume, at least not using EXCHANGE. MOUNT /VIRTUAL refuses to recognize the file type: EXCHANGE> mount/virtual tp: pdp2.con %EXCHANGE-W-RT11_BADDIRECT, volume TP: has invalid RT-11 directory EXCHANGE> mount/virtual tp: pdp2.con/volume=dos11 %EXCHANGE-W-PARSEERR, unable to parse input name PDP2.CON -EXCHANGE-W-INVVOLFMT, volume format specified is not consistent with file spec Is my best bet at this point to manually dismember the tape contents? ------------------------------ Date: Sat, 13 Jan 2007 14:20:42 -0500 From: Stephen Hoffman Subject: Re: RMS-E-WLK, device currently write locked Message-ID: davidc@montagar.com wrote: > rajib_agarw...@hotmail.com wrote: >> What are the possible reason that $1$DIA3: got write locked ? > > Usually when I've seen a disk go writelocked like that, it's due to a > bad block in the bitmap.sys or indexf.sys files. When this happens, > the file system writelocks itself to avoid future corruption. You > might try ANALYZE/DISK and see if it comes up with anything. It can also potentially be a lack of spare blocks in the spares area; in the replacement caching table (RCT). Given these are DSSI disks and thus comparatively ancient rotating storage hardware, I'd be looking at the validity and currency of the disk backups, and at ensuring the copies in the archives are current. And I'd look at moving to less-ancient storage. SCSI via HSD, or otherwise. Even if it's "just a bitmap error"... -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Sat, 13 Jan 2007 14:14:48 -0500 From: Stephen Hoffman Subject: Re: RUN SYS$SYSTEM:DCL on Itanium VMS 8.2-1 Message-ID: Marc Van Dyck wrote: > Stephen Hoffman was thinking very hard : >> -- DCL is one of the weirder images on OpenVMS > > Indeed ! And that reminds me the fact that, while there is in the UAF > a field that allows you to associate an account with the command > interpreter of your choice, I have never seen any documentation or > support offered to help you write your own... Too complicated, > I presume ? The effort involved in creating the documentation and maintaining the interfaces and the user-level effort involved in creating and debugging and maintaining and upgrading a CLI never seemed to even approach the level of the "fold", much less above it. CLIs are fully-privileged, operate in P1 space, and must field callbacks from sys$cli arising underneath various of the more familiar APIs. All certainly feasible, but there never seemed to be much call for it all. There have been several CLIs other than DCL around. MCR and DEC/shell come to mind here, as does the POSIX shell. IIRC, there was at least one user-written CLI. Poke around for HOW_INVOKED.C for an idea of how to use sys$cli(), and look around for a copy of sys$cli.zip. As for pointers to any examples of a user-written CLI, the last time I can recall hearing about such was back around V3 on VAX; eons ago. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Sat, 13 Jan 2007 14:49:59 -0500 From: Stephen Hoffman Subject: Re: Strategies for keeping 2 system disks in sync Message-ID: Bill Todd wrote: > Stephen Hoffman wrote: > > ... > >> 5MB is not a disk I/O cache, it's a rounding error comprised of nine >> pages of physical memory. > > 9? Let alone on a DS10L? > > Regardless, for a workstation primarily doing serial operations it > shouldn't be too bad: granted, it won't actually cache much of anything > (which may or may not slow things down, depending on the degree to which > the workload benefits from disk caching), but it should be more than > adequate to buffer I/O requests, shouldn't it? For a system that does nothing other than act like a glorified terminal server or embedded processor and that has little or no change to the run-time memory environment and no interactive activity and no process changes and no non-dedicated activities, it's still gonna suck seriously rotten eggs. > In a situation where RAM is limited, I'd tend to suspect that giving the > system as much physical memory as possible to back *virtual* memory > might take precedence over enlarging the disk cache. Correct. Nine or ten pages is not a valid disk cache. Well, for not anything other than a carefully assembled and dedicated embedded system. For OpenVMS, this number of pages in an I/O cache is an example of a hideously under-configured or mis-configured system -- or the box is a non-interactive dedicated or real-time system that was extremely carefully tuned for a very specific load. (And a load that was probably also undersized.) Can you run a box this close to the edge? Yes. But it is also a complete waste of an Alpha and of the OpenVMS operating system. There is a high likelihood this box going to run hideously slowly, and that it may (will?) encounter problems, stalls and errant behavior. Go find an embedded board. Set this Alpha free! Or spend a few dollars and add in a couple hundred megabytes. If you can't afford the added memory for this box, sell the Alpha and replace it with an embedded board, and pocket the profits from the sale. Virtual memory _needs_ physical memory. I/O to disk is massively slower than I/O from cache. Systems that are resource-constrained run poorly. Nine blocks does not an I/O cache make. Free those nine pages, and eliminate the cache all together. Or acquire some memory. Or replace the box with one better suited for the application. Going commodity price for 512 MB MS310 memory for this box looks to be a little above US$200, with 256 MB going for rather less than that. There's a 256 DS10 DIMM stick currently going for US$31.99. A US$31.99 fix for a nine-page I/O cache appears a no-brainer. (I should go look to see if the memory DIMMs need to be paired.) -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Sat, 13 Jan 2007 21:15:39 GMT From: Michael Austin Subject: TCPIP 5.x SMTP File format Message-ID: <%Zbqh.62354$wP1.42387@newssvr14.news.prodigy.net> OpenVMS 7.3-2/TCPIP 5.4 Is there a document that describes the format of the TCPIP smtp control file? ie. 07011315190994_TCPIP$SMTP-20227953.TCPIP_ALPHA1 contains who is to receive it along with other header information. It is this file for which I am seeking the file layout/format. and 07011315190994_TCPIP$SMTP-20227953.TCPIP_ALPHA1_TEXT contains the actual "email". With forged headers in this file, the control file seems to the more logical place to kill emails to unknown/unwanted/invalid usernames. I would like to make try and reduce the number of bad usernames that my system processes daily. During Christmas season this year, my little 2100 avergaged >1500/day sometimes more. Most were to userid's like <3cffca66.7aff1cfa at my domain name> and I would like to alter my homegrown (downloaded from somewhere) spamkiller to be a lot more accurate when deleting these things... -- Michael Austin. Database Consultant Domain Registration and Linux/Windows Web Hosting Reseller http://www.spacelots.com ------------------------------ Date: Sat, 13 Jan 2007 17:08:46 -0500 From: JF Mezei Subject: Re: TCPIP 5.x SMTP File format Message-ID: <45a95852$0$21853$c3e8da3@news.astraweb.com> Michael Austin wrote: > Is there a document that describes the format of the TCPIP smtp control file? Yes. But we can't have it. It is proprietary etc etc. Same for the TCPIP$ routines that are used to create the control files and submit them directly to the queue (as opposed to the Send From File which creates yet another intermediate file before using the TCPIP routines to convert those files to the ones used by the symbiont. > With forged headers in this file, the control file seems to the more logical > place to kill emails to unknown/unwanted/invalid usernames. Are you aware of the SMTP.CONFIG option: Symbiont-Checks-Deliverability: FALSE This is really meant as "Receiver checks deliverability: TRUE" but alas, they didn't chose that more obvious wording. This causes the receiver to check for the validity of the destination usernames and reject the message before it is accepted. This mean that the symbiont doesn't need to send out a gazillion "sorry I can't deliver this message" back. I believe the option was enabled in 5.4. I am at 5.6 and I have to say that it made a HUGE difference/improvement. For one thing, I now very rarely get any postmaster message telling me that a bounce message from my symbiont couldn't be delivered to the person who originally sent the undeliverable message. ------------------------------ End of INFO-VAX 2007.027 ************************