INFO-VAX Fri, 10 Oct 2008 Volume 2008 : Issue 548 Contents: DS15 Systems incoming Re: media of old VMS versions Re: media of old VMS versions Re: mounting USB Sandisk Re: MX list revival Re: MX list revival Re: MX list revival Re: New LaserJet fun (or upward compatibility? What is that?) Re: printer recommendation for hobbyist cluster Re: printer recommendation for hobbyist cluster PURGE/RECLAIM and CONVERT Re: PURGE/RECLAIM and CONVERT Re: PURGE/RECLAIM and CONVERT Re: PURGE/RECLAIM and CONVERT Re: PURGE/RECLAIM and CONVERT Re: PURGE/RECLAIM and CONVERT Re: PURGE/RECLAIM and CONVERT Re: PURGE/RECLAIM and CONVERT Re: PURGE/RECLAIM and CONVERT Re: PURGE/RECLAIM and CONVERT Re: Using an Infoserver Re: Using an Infoserver ---------------------------------------------------------------------- Date: Fri, 10 Oct 2008 09:45:35 -0400 From: "David Turner, islandco.com" Subject: DS15 Systems incoming Message-ID: <7XIHk.46730$Ep1.8370@bignews2.bellsouth.net> NEW DS15a Systems 1Ghz CPU 4GB Memory Front Access Disk Cage 2 x 72GB U320m Disks U320 RAID Controller ATI Radeon 7500 Graphics 10/100 and 10/100/1000 Ethernet NICS OpenVMS base and EIP Licenses 600GB SDLTII Table Top Tape Backup Commercial System 1 Year Warranty from island Price each is $12,800 -- David B Turner ============================================= Island Computers US Corp PO Box 86 Tybee GA 31328 Toll Free: 1-877 636 4332 x201, Mobile x251 Email: dturner@islandco.com International & Local: (001)- 404-806-7749 Fax: 912 786 8505 Web: www.islandco.com ============================================= ------------------------------ Date: Fri, 10 Oct 2008 06:20:12 -0700 From: "Tom Linden" Subject: Re: media of old VMS versions Message-ID: On Thu, 09 Oct 2008 18:16:14 -0700, Richard B. Gilbert wrote: > Steven M. Schweda wrote: >> From: shadoooo >> >>> The 3100 has some problem to boot the OS. Thre disks (two RZ23) seems >>> to work, but if I boot it, only the first row of text presenting VMS >>> 5.3 appears, then the system seems to search something on all other >>> SCSI devices connected, in sequence, until an HALT error appears... >> Sounds as if your hardware is not all that it should be. >> Is that a MicroVAX 3100 or a VAXstation 3100? >> No matter how old the VMS version, I would look for a nice 1GB SCSI >> disk to use instead of an RZ23. If your RZ23's still work, you can >> always find them new homes in some old Macintoshes, where 100MB would >> look big. >> I would not bother with any VMS version older than V5.5-2, which is >> the last of the V5 series. If you think that CD images of V5.4, >> V5.5(-2), or something newer might be useful, send me some e-mail. >> >> ------------------------------------------------------------------------ >> Steven M. Schweda sms@antinode-info >> 382 South Warwick Street (+1) 651-699-9818 >> Saint Paul MN 55105-2547 > > ??????? > > ISTR that MicroVAX 3100s have some restrictions on the size of disks > they will boot from. Before you waste big bucks on GB SCSI disks, check > out what's supported. I think you can use just about anything for data > but there are restrictions in the firmware that limit the size disk you > can boot from. Actually, it's not the size per se, but everything you > need to boot the system must be in the FIRST X megabytes of the disk. This comes up from time to time and as I recall (I think Hoff responded to this) there is an address field in the ROM that isn't wide enough so it will overwrite itself for anything larger. I have a patched ROM that I got from Wolfgang Moeller but you would have to have the ability to burn some PROMs that are likely no longer available. google for Moeller VAX ROM -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Fri, 10 Oct 2008 09:22:35 -0400 From: "David Turner, islandco.com" Subject: Re: media of old VMS versions Message-ID: I have some working 1GB disks for a few bucks if someone needs one -- David B Turner ============================================= Island Computers US Corp PO Box 86 Tybee GA 31328 Toll Free: 1-877 636 4332 x201, Mobile x251 Email: dturner@islandco.com International & Local: (001)- 404-806-7749 Fax: 912 786 8505 Web: www.islandco.com ============================================= "Steven M. Schweda" wrote in message news:08100921082249_202004A1@antinode.info... > From: "Richard B. Gilbert" > >> ISTR > > In the words of a very wise man, "[...] knowledge is stronger than > memory, and we should not trust the weaker." The VMS FAQ exists to > obviate recollection from a weak memory. > >> that MicroVAX 3100s have some restrictions on the size of disks >> they will boot from. > > The size restriction is on the boot disk when the system does a crash > dump. You can normally still boot from larger disks, but your data are > at risk if the system crashes, and the firmware mislocates the dump > file. Perhaps there was a reason that I suggested a 1GB disk, not > anything larger. > >> Before you waste big bucks on GB SCSI disks, check >> out what's supported. > > It may be possible to "waste big bucks" on a 1GB SCSI disk, but it > can't be very easy. The list of "supported" disks is pretty short. The > list of disks which will work is much longer. > >> I think you can use just about anything for data >> but there are restrictions in the firmware that limit the size disk you >> can boot from. Actually, it's not the size per se, but everything you >> need to boot the system must be in the FIRST X megabytes of the disk. > > More critically, the dump file needs to be in the first GB, but read > the FAQ. And don't believe everything you read here. > > ------------------------------------------------------------------------ > > Steven M. Schweda sms@antinode-info > 382 South Warwick Street (+1) 651-699-9818 > Saint Paul MN 55105-2547 ------------------------------ Date: Fri, 10 Oct 2008 07:49:59 +0200 From: Jur van der Burg <"lddriver at digiater dot nl"> Subject: Re: mounting USB Sandisk Message-ID: <48eeed07$0$190$e4fe514c@news.xs4all.nl> > Question: Might you try using LDDRIVER to "shield" DSDRIVER from the > weirdnesses of USB? Sure that should work. > Specifically, I'm suggesting using LD CONNECT to specify a block range > from the USB devices, then INIT the LD devices and shadow them instead > of the "raw" USB device. You can do that, or just create a container file on the usb device and use that. Jur. David J Dachtera wrote: > Malcolm Dunnett wrote: >> forrret.kenney@hp.com_nospam wrote: >>> "Tom Linden" wrote in message >>> news:op.uiat9kr2hv4qyg@murphus.hsd1.ca.comcast.net... >>>> On Tue, 30 Sep 2008 05:56:04 -0700, forrret.kenney@hp.com_nospam >>>> wrote: >>>> >>>>> "Tom Linden" wrote in message >>>>> news:op.uh9n7fiyhv4qyg@murphus.hsd1.ca.comcast.net... >>>>>> I initialized /gpt on a RX2620 runing 1H1 and mounted it with >>>>>> /cluster, but it only gets mounted on that box. Why? >>>>>> >>>>> There are capabilities needed for MSCP serving that are not in the >>>>> driver. >>>> Any plans to do so? BTW, what is the transfer rate on USB? >>> No to the MSCP question. >> Apparently shadowing doesn't work either. I tried shadowing a couple >> of external 500GB drives (HP Personal Media drives). The first drive >> mounted and worked ok, but the system crashed when I tried to add the >> second drive to the shadowset(exception above ASTDEL). I also found that >> dismounting the single member shadowset would crash the system. > > Question: Might you try using LDDRIVER to "shield" DSDRIVER from the > weirdnesses of USB? > > Specifically, I'm suggesting using LD CONNECT to specify a block range > from the USB devices, then INIT the LD devices and shadow them instead > of the "raw" USB device. > > Working from (admittedly defective) memory here - my V7.3-2 system is > not currently booted/-able. > > D.J.D. ------------------------------ Date: Fri, 10 Oct 2008 06:10:37 -0700 From: "Tom Linden" Subject: Re: MX list revival Message-ID: On Thu, 09 Oct 2008 17:48:27 -0700, VAXman- wrote: Brian, 9-OCT-2008 14:14:31.12: MX SMTP server: rejected message from sent by [64.253.47.113] due to RFC822 header rule [Received: from *warning*] [rule id 804] I have removed this rule, but it has been very effective in eliminating spam, I wonder why you got caught? Tom -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Fri, 10 Oct 2008 07:07:21 -0700 From: "Tom Linden" Subject: Re: MX list revival Message-ID: On Fri, 10 Oct 2008 06:10:37 -0700, Tom Linden wrote: > On Thu, 09 Oct 2008 17:48:27 -0700, VAXman- wrote: > > Brian, > > 9-OCT-2008 14:14:31.12: MX SMTP server: rejected message from > sent by [64.253.47.113] due to RFC822 header rule > [Received: from *warning*] [rule id 804] > > I have removed this rule, but it has been very effective in eliminating > spam, I wonder why > you got caught? > > Tom > Here is an example of the type of spam I was rejecting, which is now back. Return-Path: Received: from hotkeyserver.net (206.106.11.53) by FREJA.KEDNOS.COM (MX V5.4 An1f) with SMTP (warning type 0007) for ; Fri, 10 Oct 2008 06:56:19 -0700 I wonder what type 0007 is? BTW, in experimenting we found that one of the 4 nodes running MX with loadbroker was rejecting but others not. There is a common config file for all, so this is a mystery. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Fri, 10 Oct 2008 16:15:50 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: MX list revival Message-ID: <00A80E5A.65EE977B@SendSpamHere.ORG> In article , "Tom Linden" writes: >On Thu, 09 Oct 2008 17:48:27 -0700, VAXman- wrote: > >Brian, > > 9-OCT-2008 14:14:31.12: MX SMTP server: rejected message from > sent by [64.253.47.113] due to RFC822 header rule >[Received: from *warning*] [rule id 804] > >I have removed this rule, but it has been very effective in eliminating >spam, I wonder why >you got caught? *warning* The MX server saw me coming! :) I'm signed up now. Thanks. No idea why one MX% mailer would reject another though. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM ... pejorative statements of opinion are entitled to constitutional protection no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC) Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside of usenet _must_ include its contents in its entirety including this copyright notice, disclaimer and quotations. ------------------------------ Date: Fri, 10 Oct 2008 07:22:26 -0700 (PDT) From: Rich Jordan Subject: Re: New LaserJet fun (or upward compatibility? What is that?) Message-ID: <9658197a-125f-4141-84fd-8dab0b739b15@u40g2000pru.googlegroups.com> On Oct 9, 8:47=A0pm, "Richard B. Gilbert" wrote: > William Webb wrote: > > On Wed, Oct 8, 2008 at 11:48 AM, Rich Jordan wrote= : > >> Just a note if any of you are still spec'ing LaserJet printers for use > >> on VMS systems. =A0I'm not aware of any available PCL6 support info or > >> libraries on VMS (PCL5 either for that matter, but its easy enough to > >> roll your own with that). > > >> We've used PCL (3, then 5) as our primary 'print forms' language for > >> 16 years. =A0HP hasn't always made that easy as their backward > >> compatibility has been less than stellar, and their penchant for > >> producing badly crippled firmware in their low end printers has also > >> not helped. =A0Soft fonts were a particular problem over the years as > >> certain low end printers refused to load them; these limitations were > >> often not documented; we found out 'in use'. > > >> The newest printer we've tried to use is the P2015-N. =A0There is one, > >> and only one note, indicating a font limitation: =A045 scalable fonts > >> (PCL6), 35 scalable fonts (PS), 11 Scalable fonts plus 11 lineprint > >> fonts (PCL5e). > > >> None of the scalable fonts available to PCL5e have proportional > >> spacing. =A0This printer has been crippled back to a fixed pitch dumb > >> printer for anyone not running a PCL6 driver. =A0It is NOT their botto= m > >> line stuff; its in the mid-range. =A0And not suitable to our forms > >> printing needs. > > >> At the same time, the HP developer website that was supposed to > >> provide links to the various PCL5/PCL6 specs and docs has apparently > >> been lobotomized. =A0All my searches ended up going to dead pages or t= o > >> the hp.com pages with the PCL5 docs; nothing on PCL6. =A0If anyone kno= ws > >> where the PCL6 developer or spec docs are I'd appreciate a heads-up. > >> In the meantime these printers are sidelined while we locate some real > >> LaserJets that haven't been crippled into PC toys. > > > I have a PCL 5 manual on my desk. > > Good for looking stuff up when writing device control library modules. > > > Most HP printers will respond positively to PCL 5 commands, although > > I've got to admit that PCL is even more positional than BACKUP. > > > WWWebb > > I've been using a LaserJet 4000 with JetDirect card for a good many > years now. =A0I print from Windows, VMS, Solaris, and Linux. =A0It's rock > solid and has done everything I need it to do. Midgrade printers like the 4000 series were always safe bets. I don't know any that have run as long or reliably as the tank-like III/IIID printers (the 4s were the first ones to start cheaping down on the physical construction, though the 4si lasted many years at any of our customers that had one) but they were still pretty good. Where we first ran into problems was the low end printers after the 6 series; the 1100/2100 printers had crippled PCL interpreters, but you could not find that out from any pre-sales literature. Later you need to watch out for printers that don't state 'PCL5' or 'PCL5e' support, which were the ones that used the host-based interpreter and were therefore useless without an HP driver. However the firmware crippling seemed to stay down in the personal desktop end of the product line. Now you need to make sure about PCL5/5e _and_ font availability. Who knows what gotchas HP will be adding in the future. This is not a good thing. If you need to replace your 4000, be very careful what you settle on. ------------------------------ Date: Fri, 10 Oct 2008 09:24:01 -0400 From: "David Turner, islandco.com" Subject: Re: printer recommendation for hobbyist cluster Message-ID: THe Color lasterjet 2605 is supported with DCPS - You can get one for about $300 from office Depot Supplies are costly - We have one in our office for invoicing - good quality -- David B Turner ============================================= Island Computers US Corp PO Box 86 Tybee GA 31328 Toll Free: 1-877 636 4332 x201, Mobile x251 Email: dturner@islandco.com International & Local: (001)- 404-806-7749 Fax: 912 786 8505 Web: www.islandco.com ============================================= "Phillip Helbig---remove CLOTHES to reply" wrote in message news:gcis0n$qe$1@online.de... >I have no printer in my hobbyist cluster (VAX and ALPHA, nothing very > new). I would like to have one. The minimum would be a printer which > would print plain text as well as PostScript. These days, it should > also be possible to print a PDF file on it. Another requirement would > be the ability for a web browser to print a given page (not sure how > this works behind the scenes). Colour would be nice, but I could live > with black and white if colour is going to cost me a lot more (in > initial costs or in maintenance). > > I don't care how it is connected up, as long as it can be. (Serial? > Parallel? Network?) An added plus would be the ability for non-VMS > stuff on the LAN to use it as well (presumably this would imply a > network connection). > > 300 DPI should be enough, but 600 (or even more) would be nice. > > Can I buy some new printer off the shelf in any old shop? > > What new HP printers would fit the bill? > > What used DEC/Compaq/HP printers would fit the bill? > > To save paper, the ability to print double-sided would be nice. > > A4 is the only size I need. > > If anyone has such a printer to give away or sell cheap in Europe, let > me know and I'll see if I can come and get it. > ------------------------------ Date: Fri, 10 Oct 2008 12:29:19 -0400 From: JF Mezei Subject: Re: printer recommendation for hobbyist cluster Message-ID: <48ef8407$0$12395$c3e8da3@news.astraweb.com> Phillip Helbig---remove CLOTHES to reply wrote: > Wouldn't CONVERT/DOCUMENT be the best place for this? Assuming HP still has the sources/rights to this, this is a great idea: They would simply need to create a PDF reader shareable image and make it possible for interactive use of CONVERT/DOCUMENT myfile.PDF to myfile.PS , and then DCPS could simply use the callable interface of the CDA to do the same when given PDF files to print on a PS printer. The caveat to this is that I am not sure the CDA architecture supports going from final form to final form. I think there is an inherent requirement that the document being read be converted to a CDA internal format first, and this would require the software create a virtual image of the PDF document in CDA semantics before converting that into Postscript. But such virtual image might allow you to convert it to ascii or other document formats and that would be REALLY neat. It is a REAL SHAME that Digital abandonned the CDA architecture. This would have been something really useful in a modern world and if DEC had had leaderhsip it would have made VMS useful even i offices because of that document conversion capability (with up to date and full set of converters). ------------------------------ Date: Fri, 10 Oct 2008 09:50:21 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: PURGE/RECLAIM and CONVERT Message-ID: VMS MAIL, of course: PURGE /RECLAIM Releases deleted message space back to OpenVMS RMS for reuse. Because your mail file is locked while PURGE/RECLAIM is running, you cannot receive new mail. Users attempting to send you mail while PURGE/RECLAIM is running receive an error message indicating that their message has not been sent successfully. You cannot access your own Mail files while a PURGE/RECLAIM command is running. COMPRESS Makes an indexed mail file smaller by recovering space that is left by deleted mail messages. When you compress a file, the following steps occur: Behind the scenes, is the effect the same (except for the copy of the uncompressed file one gets with COMPRESS)? Is there the locked-file problem causing messages to bounce with COMPRESS like there is with PURGE/RECLAIM? If so, is this time always shorter than is the case with PURGE/RECLAIM? I just moved 220 MB of stuff from one mail file from another. What should I do to "clean up" the file with the deleted stuff? PURGE/RECLAIM? Compress? Separate RMS procedure? (I'm sure Hein will respond.) ------------------------------ Date: Fri, 10 Oct 2008 07:17:34 -0700 (PDT) From: Hein RMS van den Heuvel Subject: Re: PURGE/RECLAIM and CONVERT Message-ID: <708916ee-526b-470d-a0cc-8f2a476aec4b@n1g2000prb.googlegroups.com> On Oct 10, 5:50=A0am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- remove CLOTHES to reply) wrote: > VMS MAIL, of course: : > Behind the scenes, is the effect the same (except for the copy of the > uncompressed file one gets with COMPRESS)? Compress (straight convert) will be cleaner, tighter. Purge (convert/reclaim) will only recycle completely empty buckets. The effect of re-cycle will also cause randomish spread of records over the VBN range. > Is there the locked-file problem causing messages to bounce with > COMPRESS like there is with PURGE/RECLAIM? =A0If so, is this time always > shorter than is the case with PURGE/RECLAIM? I believe the Compress to behave nicer, but have no time to try/ check back in my old notes. Sorry. Both reclaim and convert will read each databucket from the file. Reclaim will then re-write those index and data buckets foudn to be empty, one at a time. Convert (8.2+) will build large (127 block) buffers of buckets with valid records. Which one is faster clearly depends on the deleted vs retained ratio. I find a full convert often faster than a significant reclaim and prefer the result, so a full convert is a no-brainer for me. But I suppose if you faithfull purge regularly, then it that woudl be quicker each time ( but slower in aggregation). > I just moved 220 MB of stuff from one mail file from another. =A0What > should I do to "clean up" the file with the deleted stuff? VMSmail files a basic indexed file and can and could/should be tuned as such. While ideally you'd tune each VMSmail file with EDIT/FDL/NOINT based on the number of records it is expected to have, a more coarse approach is fine. I used to use a little script to choose between SMALL, MEDIUM and BIG. I'll attach it below. Now for expected to be stable files, you may want to tweak the allocations towards exact fit. Possibly just one area with an ALLOCATION of 80% of anticipated need and an extent of 4 or 5%. =A0(I'm sure Hein will respond.) :-). Regards, Hein van den Heuvel $! MAIL_CONVERT.COM Cleans up and optimizes VMSmail indexed files. $! Hein van den Heuvel, March 1996 $! Oct-2008, Make 'big' FDL bigger. $ $ BIG =3D 5000 $ SMALL =3D 500 $ $! This command file will convert the MAIL.MAI file in the current $! directory selecting a reasonable FDL file based on the current size. $! It will NOT compress as agressivly as standard MAIL COMPRESS would $! do as it is believed that current mail file size is an indication $! of the future size. $! It makes an attempt to protect against incoming mail during the convert. $! Such new mail would create a fresh MAIL.MAI file which is merged in. $! Hein van den Heuvel $! $if f$search("mail.mai").eqs."" then goto help $open/read/write/erro=3Dhelp x mail.mai $close x $size =3D f$file ("mail.mai","alq") $gbc =3D f$file ("mail.mai","gbc") $set prot mail.mai;* $rena/log mail.mai;* mail.old;* $! $! Select the convert with appropriate FDL $! $if size.gt.big then goto big_fdl $if size.lt.small then goto small_fdl $goto medium_fdl $! $! Come back here after convert and make sure no new mail has arrived $! $newmail: $set noon $if f$search("mail.mai").eqs."" then goto nonews $write sys$output "New MAIL.MAI file appeared. Merging in with .NEW file." $convert/merge/stat MAIL.MAI MAIL.NEW $set prot MAIL.MAI $delete/conf MAIL.MAI. $goto newmail $ $nonews: $rena/log mail.new mail.mai $set prot=3D(ow:rw,sy:rw,gr,wo) mail.mai $if gbc.gt.0 then set file/global=3D'gbc' mail.mai $dele/conf mail.old.* $exit $ $big_fdl: $conv/fast/stat/nosort/fdl=3Dsys$input mail.old mail.new FILE; ORG indexed; RECORD; FORMAT variable; SIZE 2048 AREA 0; BEST_TRY_CONTIGUOUS yes; BUCKET 16; ALLOCATION 16; EXTENSION 160; AREA 1; BEST_TRY_CONTIGUOUS yes; BUCKET 16; ALLOCATION 3200; EXTENSION 6400; AREA 2; BEST_TRY_CONTIGUOUS yes; BUCKET 16; ALLOCATION 320; EXTENSION 640; KEY 0; DATA_KEY_COMPR no; DATA_RECORD_COMPR yes; INDEX_COMPRES no DATA_AREA 1; DATA_FILL 100; DUPLICATES no; PROLOG 3 INDEX_AREA 0; INDEX_FILL 100; LEVEL1_INDEX_AREA 0 SEG0_LENGTH 8; SEG0_POSITION 0; TYPE bin8 KEY 1; DATA_KEY_COMPR yes; INDEX_COMPR yes; NULL_KEY yes; NULL_VALUE 0 DATA_AREA 2; DATA_FILL 70; CHANGES yes; DUPLICATES yes INDEX_AREA 2; INDEX_FILL 90; LEVEL1_INDEX_AREA 2 SEG0_LENGTH 39; SEG0_POSITION 9; TYPE string $ $goto newmail $ $medium_fdl: $conv/fast/stat/nosort/fdl=3Dsys$input mail.old mail.new FILE; ORG indexed; RECORD; FORMAT variable; SIZE 2048 AREA 0; BEST_TRY_CONTIGUOUS yes; BUCKET 8; ALLOCATION 8; EXTENSION 64; AREA 1; BEST_TRY_CONTIGUOUS yes; BUCKET 8; ALLOCATION 480; EXTENSION 320; KEY 0; DATA_KEY_COMPR no; DATA_RECORD_COMPR yes; INDEX_COMPRES no DATA_AREA 1; DATA_FILL 100; DUPLICATES no; PROLOG 3 INDEX_AREA 0; INDEX_FILL 100; LEVEL1_INDEX_AREA 0 SEG0_LENGTH 8; SEG0_POSITION 0; TYPE bin8 KEY 1; DATA_KEY_COMPR yes; INDEX_COMPR yes; NULL_KEY yes; NULL_VALUE 0 DATA_AREA 1; DATA_FILL 70; CHANGES yes; DUPLICATES yes INDEX_AREA 1; INDEX_FILL 90; LEVEL1_INDEX_AREA 1 SEG0_LENGTH 39; SEG0_POSITION 9; TYPE string $ $goto newmail $ $small_fdl: $conv/fast/stat/nosort/fdl=3Dsys$input mail.old mail.new FILE; ORG indexed; RECORD; FORMAT variable; SIZE 2048 AREA 0; BEST_TRY_CONTIGUOUS yes; BUCKET 6; ALLOCATION 60; EXTENSION 120; KEY 0; DATA_KEY_COMPR no; DATA_RECORD_COMPR yes; INDEX_COMPRES no DATA_FILL 100; INDEX_FILL 100; DUPLICATES no; PROLOG 3 SEG0_LENGTH 8; SEG0_POSITION 0; TYPE bin8 KEY 1; DATA_KEY_COMPR yes; INDEX_COMPR yes; NULL_KEY yes; NULL_VALUE 0 DATA_FILL 70; INDEX_FILL 90; CHANGES yes; DUPLICATES yes SEG0_LENGTH 39; SEG0_POSITION 9; TYPE string $ $goto newmail $ $help: $type sys$input MAIL.MAI file note found, or could not be opened exclusivly (in use). Please execute this command file while default set to mail directory. Exit from any and all active VMSmail/DECwindowsmail processed. $exit ------------------------------ Date: Fri, 10 Oct 2008 14:43:17 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: PURGE/RECLAIM and CONVERT Message-ID: In article <708916ee-526b-470d-a0cc-8f2a476aec4b@n1g2000prb.googlegroups.com>, Hein RMS van den Heuvel writes: > Compress (straight convert) will be cleaner, tighter. OK, doing COMPRESS now. Will probably take another 15 hours. > > Is there the locked-file problem causing messages to bounce with > > COMPRESS like there is with PURGE/RECLAIM? If so, is this time always > > shorter than is the case with PURGE/RECLAIM? > > I believe the Compress to behave nicer, but have no time to try/ check > back in my old notes. Sorry. The PURGE/RECLAIM will lock it for the whole time during the reclaim. COMPRESS makes a copy then compresses the copy before renaming it to MAIL.MAI. So, the time the file is blocked is MUCH less than with PURGE/RECLAIM (at least for a large number of deleted messages). > I used to use a little script to choose between SMALL, MEDIUM and BIG. > I'll attach it below. Thanks. I'm doing a big reorg now, so the file will shrink significantly. After the reorg, the size should stay roughly constant, so in future I will maintain it with your procedure. ------------------------------ Date: Fri, 10 Oct 2008 09:06:53 -0700 (PDT) From: Hein RMS van den Heuvel Subject: Re: PURGE/RECLAIM and CONVERT Message-ID: <1125b6f0-28fb-4183-a734-ef1e06b39261@40g2000prx.googlegroups.com> > OK, doing COMPRESS now. =A0Will probably take another 15 hours. How can that be ???? Use ^T to see where it is and again 1 minute later., Verify with the PROCIO SDA extention if you feel like seeing details. And then stop it. Surely it is nickle and diming the output file. (MONI FILE,FCP,MODE) Pre-allocate and be happy! The bucket size is probably just 5 blocks (the mimimum). So 220MB =3D 440K blocks =3D 90,000 read IOs at the most. Give it 100 IO/sec --> 900 seconds =3D 15 minutes to read ? Another 5 minutes to write, 1 minute for the secondary key. Shouldn't take more then 1/2 hour for an 220MB VMSmail file... with proper pre-allocation and CONVERT/FAST. I would really expect less than 10 minutes on any storage from this century. fwiw, Hein. ------------------------------ Date: Fri, 10 Oct 2008 12:45:02 -0400 From: JF Mezei Subject: Re: PURGE/RECLAIM and CONVERT Message-ID: <48ef875a$0$9644$c3e8da3@news.astraweb.com> Phillip Helbig---remove CLOTHES to reply wrote: > PURGE > > /RECLAIM > > Releases deleted message space back to OpenVMS RMS for reuse. HELP CONVERT/RECLAIM If you have 5 records in a bucket and delete all of them, then the bucket remains marked as in use. New records can be placed in that bucket only if they fit the key range of the index entry pointing to that bucket. CONVERT/RECLAIM spot all those buckets that are in the index but contain only deleted records and mark those buckets as free (and I assume will update the index to give the previous bucket a new key range to include the range of the former bucket, is that correct ?) This work is done in-situ with the file opened for read/write with exclusive status. Nobody can insert new records in it while you re-arrange the deck chairs in the index structure. This is the moral equivalent of emptying the trash can on a desktop. > COMPRESS > > Makes an indexed mail file smaller by recovering space that is > left by deleted mail messages. When you compress a file, the > following steps occur: This is a CONVERT/FDL operation. It renames your MAIL.MAI file to MAIL.OLD, then it does a CONVERT MAIL.OLD to MAIL.MAI. This creates a new empty file and copies record by record from the old to the new file. and then tries to delete MAIL.OLD (which usually fails because those files are created by default so that the user can't delete them) This is the moral equivalent of using BACKUP/IMAGE to defragment your disk. This takes a lot more time than the convert/reclaim which is generally very fast. Reception of new mail during this time is problematic. While CONVERT write the new MAIL.MAI, incoming new mail is not possible. If you get mail betwene the time the old file has been renamed and the new file created, than MAIL will create a new MAIL.MAI, and the CONVERT may create a MAIL.MAI;2 ------------------------------ Date: Fri, 10 Oct 2008 16:45:41 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: PURGE/RECLAIM and CONVERT Message-ID: In article <1125b6f0-28fb-4183-a734-ef1e06b39261@40g2000prx.googlegroups.com>, Hein RMS van den Heuvel writes: > > OK, doing COMPRESS now. Will probably take another 15 hours. > > How can that be ???? Big file, slow system. :-) I did delete aboutu 220 MB of stuff from the file. > Use ^T to see where it is > and again 1 minute later., > Verify with the PROCIO SDA extention if you feel like seeing details. This is the COMPRESS from within MAIL on 7.3-2. Control-T just has the standard output. (Control-T on PURGE/RECLAIM does show more stuff, at least sometimes (just checked and it didn't).) > I would really expect less than 10 minutes on any storage from this > century. The disk is a shadow set (10 MB/s SCSI) mounted on two VAXes in the cluster. The command is running on one of them, a VAXstation 4000/90. So all writes are going to both disks over the LAN. ------------------------------ Date: Fri, 10 Oct 2008 16:53:33 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: PURGE/RECLAIM and CONVERT Message-ID: In article <48ef875a$0$9644$c3e8da3@news.astraweb.com>, JF Mezei writes: > This is a CONVERT/FDL operation. It renames your MAIL.MAI file to > MAIL.OLD, then it does a CONVERT MAIL.OLD to MAIL.MAI. This creates a > new empty file and copies record by record from the old to the new file. > > and then tries to delete MAIL.OLD (which usually fails because those > files are created by default so that the user can't delete them) Are you sure about the delete stuff? I just tried it from an account with all privs enabled, and it DOESN'T delete the file. There is also no indication that it tried. > Reception of new mail during this time is problematic. While CONVERT > write the new MAIL.MAI, incoming new mail is not possible. If you get > mail betwene the time the old file has been renamed and the new file > created, than MAIL will create a new MAIL.MAI, and the CONVERT may > create a MAIL.MAI;2 Hein's procedure handles this much better. His idea should be integrated into VMS MAIL. When I get rich and buy all the old DEC stufuf from HP (or whoever owns it when I get rich), I'll hire him to do it! ------------------------------ Date: Fri, 10 Oct 2008 16:55:46 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: PURGE/RECLAIM and CONVERT Message-ID: In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: > > I would really expect less than 10 minutes on any storage from this > > century. > > The disk is a shadow set (10 MB/s SCSI) mounted on two VAXes in the > cluster. The command is running on one of them, a VAXstation 4000/90. > So all writes are going to both disks over the LAN. It is definitely from the LAST century: device type SEAGATE SX910800N which is, I guess, from sometime in the 1990s. When old hardware stops working, I do replace it, usually with new stuff, but my Seagate disks and VAX stuff is so well built that some of it has been quite literally running practically continuously for 20 years! ------------------------------ Date: Fri, 10 Oct 2008 16:59:36 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: PURGE/RECLAIM and CONVERT Message-ID: In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: > In article , helbig@astro.multiCLOTHESvax.de > (Phillip Helbig---remove CLOTHES to reply) writes: > > > > I would really expect less than 10 minutes on any storage from this > > > century. > > > > The disk is a shadow set (10 MB/s SCSI) mounted on two VAXes in the > > cluster. The command is running on one of them, a VAXstation 4000/90. > > So all writes are going to both disks over the LAN. > > It is definitely from the LAST century: > > device type SEAGATE SX910800N > > which is, I guess, from sometime in the 1990s. When old hardware stops > working, I do replace it, usually with new stuff, but my Seagate disks > and VAX stuff is so well built that some of it has been quite literally > running practically continuously for 20 years! My mistake. It's the PURGE which will take about 15 hours! After that I'll do the COMPRESS! ------------------------------ Date: Fri, 10 Oct 2008 10:10:31 -0700 (PDT) From: Hein RMS van den Heuvel Subject: Re: PURGE/RECLAIM and CONVERT Message-ID: <9e33f68f-cefb-42e7-8b30-247ba9d072c6@f63g2000hsf.googlegroups.com> On Oct 10, 12:45=A0pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- remove CLOTHES to reply) wrote: > In article > <1125b6f0-28fb-4183-a734-ef1e06b39...@40g2000prx.googlegroups.com>, Hein > RMS van den Heuvel writes: > > > > OK, doing COMPRESS now. =A0Will probably take another 15 hours. > > > How can that be ???? > > Big file, slow system. =A0:-) =A0I did delete aboutu 220 MB of stuff from > the file. Ay yes, I read too quickly. 220 MB deleted. No telling (for me) how much is left. > This is the COMPRESS from within MAIL on 7.3-2. =A0 Ah... 7.3-2 no ^T, no large output buffers on convert The size of the output may be your best progress indicator. ANAL/SYS... SHOW PROC/RMS=3Dbdbsum may also give clues. And PROCIO or the WCB can give READ & WRITE stats. > The disk is a shadow set (10 MB/s SCSI) mounted on two VAXes in the > cluster. =A0The command is running on one of them, a VAXstation 4000/90. Ah, just a vax. nice vax, but just a vax. > So all writes are going to both disks over the LAN. Which is hopefully 100mb/FD, but maybe not. So stop it already! Check my procedure, Get out of vaxmail, CONV/FDL... with that 'large' FDL further tweaked for your appoximate output size. convert input from a local disk. convert output to a non-shadowed local disk. When done, copy result to target location Optionally use convert again to copy new to target for optimal size. That convert will not take muck longer than a copy, as (supposedly) you picked a large bucket size. JFM> convert/reclaim which is generally very fast. Both have to read all data buckets. Reclaim has to read index buckets and alternate indexes as well. Basic convert uses SYS$GET (RMS RECORD IO) for read sych.. Reclaim uses SYS$READ... also synchroneously. Convert can use an optimized bucket size for output, reclaim does not. Convert double-buffers output, reclaim does not. JFM> Reception of new mail during this time is problematic Yes and no. A new file will be created, which can be merged into the comverted file... if you notice the extra file. But I believe Philip is not converting his main mail file (or at least he should not be imho ;-) so then it becomes a moot point. Hmm, I guess he is converting the main file, as he was worried about the file being locked. Hein. ------------------------------ Date: Fri, 10 Oct 2008 01:19:27 -0700 (PDT) From: IanMiller Subject: Re: Using an Infoserver Message-ID: <9dd77e74-aa6f-4b6a-b12c-d7a2e9c3f926@v16g2000prc.googlegroups.com> See also http://mvb.saic.com/freeware/freewarev80/infoserver/ "This directory contains various InfoServer software disk images, the client for Microsoft MS-DOS (the OpenVMS LAD/LAST client is built into OpenVMS), and the associated keys for enabling various InfoServer functions." ------------------------------ Date: Fri, 10 Oct 2008 02:35:22 -0700 (PDT) From: etmsreec@yahoo.co.uk Subject: Re: Using an Infoserver Message-ID: <5a3dc2e3-1447-4ce2-9294-30301732dda9@v72g2000hsv.googlegroups.com> On 9 Oct, 20:58, Wilm Boerhout wrote: > Kari Uusim=E4ki vaguely mentioned on 9-10-2008 21:25: > > > Here's some links to information about Infoservers and their features > > and protocols: > > >http://h71000.www7.hp.com/doc/73final/6017/6017pro_097.html > > >http://h30266.www3.hp.com/masterindex/spd/spd_004ee544.txt > > Interesting reading. What we now call iSCSI, Digital had it back then. > Serving CD, disks, tapes and "partitions" (disk containers). > > /Wilm Indeed! Infoservers can be used to offer CD services to hosts on the network. They use LAD and LAST protocols, LAD being (IIRC) Local Area Disk. If you look in SYS$HELP you'll probably find some help libraries starting ESS$ that will contain help on the VMS side of the programs required. The startup files ESS$LAST_STARTUP.COM and ESS $LAD_STARTUP.COM will probably be of interest too. ------------------------------ End of INFO-VAX 2008.548 ************************