INFO-VAX Thu, 22 Nov 2007 Volume 2007 : Issue 640 Contents: Re: %RPCGEN-E-PREPRFAIL, preprocessor error; subprocess or compilation error(s) Re: OpenVMS Blades Webcast Re: Putting a throttle on Apache (CSWS), or all of TCP Query re volume extent cache Re: Query re volume extent cache Rsync on VMS ---------------------------------------------------------------------- Date: Wed, 21 Nov 2007 23:13:37 -0800 (PST) From: Volker Halle Subject: Re: %RPCGEN-E-PREPRFAIL, preprocessor error; subprocess or compilation error(s) Message-ID: <1f0b222a-3c0b-4e61-95bb-dde0b9948c7a@e10g2000prf.googlegroups.com> Doug, try $ SET WATCH FILE/CLASS=MAJOR (turn off with CLASS=NOMAJOR afterwards). This will log all (major) XQP operations on your SYS $OUTPUT device. Or SET AUDIT/ALARM/ENABLE=ACCESS:FAILURE (turn off with /DISABLE=...) and REPLY/ENABLE=SECURITY Then run the RPCGEN command again. Volker. ------------------------------ Date: Thu, 22 Nov 2007 12:32:01 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: OpenVMS Blades Webcast Message-ID: <5Fe1j.3$ZD6.0@newsfe10.lga> In article , AEF writes: > > >On Nov 20, 8:27 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote: >> In article <9VA0j.626$R_4....@newsb.telia.net>, >> Jan-Erik S=F6derholm writes: >> >> > > a gallon or two of gasoline at close to $3/gal. >> >> > Should be at least $8-$10/gal, I'd say. >> > Gasoline is *way* to cheap in the US. >> >> Gasoline is the same price here as it is over there. You just have more >> taxes on it. Our's should not be more expensive, your government should >> just get its hand out of your wallet. Of course, so should our's but >> at least our's isn't as deep into it in the first place. >> >> bill >> >> -- >> Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves= > >> b...@cs.scranton.edu | and a sheep voting on what's for dinner. >> University of Scranton | >> Scranton, Pennsylvania | #include > >Assuming Thomas Friedman's gas tax idea would actually work: > >If the oil-consuming nations all taxed gasoline sufficiently, it would >keep the price of oil down. This way, the money stays within the >consuming countries instead of going to Iran, and Hugo Chavez, and the >like. > >So it comes down to this choice: expensive gas with too much money >going to Iran and Hugo Chavez and the like or expensive gas with the >same money going ending up as OUR tax revenues which could be used to >fund research in alternative energy sources and/or to reduce other >taxes. Increased taxes do nothing to better anyone or anything save for those with the authority to impose them. In people's republic of New Jermany we are facing a budget crisis from years of corruption, excess dumborat spending, borrowing against state constitional restrictions and outright wasteful practices and policies. Increasing taxes will not ease the corruption, excess dumborat spending, borrowing against state constitional restrictions and outright wasteful practices and policies. Increased taxation only emboldens them to per- pertuate their insalubrious fiscal habits. -- 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: 22 Nov 2007 08:40:10 +0100 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) Subject: Re: Putting a throttle on Apache (CSWS), or all of TCP Message-ID: <4745406a$1@news.langstoeger.at> In article <604bd536-1bc0-414e-83f7-3a09d3f470a0@g21g2000hsh.googlegroups.com>, Keith Lewis writes: >It's VMS 7.3-1 (version 8 has no audio) Why not V7.3-2? >TCPIP V5.4 ECO7 perhaps? >CSWS 1.2 I think. I rejected the "all files must be stmlf" upgrade. You missed CSWS V2.1 (ECO1) vs V2.0 features? -- 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: 22 Nov 2007 09:41:55 -0600 From: omond@encompasserve.org (R.A.Omond) Subject: Query re volume extent cache Message-ID: Gentle colleagues (this is also posted on EISNER in the Notes forum): I'd appreciate your thoughts on this: The goal for a particular disk volume is to have any file extend operations as fast as possible. Tests show that file extends which can be satisfied from VMS's volume extent cache complete in about 0.01 seconds. When the system has to go back to the BITMAP.SYS (i.e. not enough blocks in the extent cache to satisfy the request) the time for the extend to complete goes up to a pretty consistent 0.33 seconds (all this is on a standalone ES40 with local disks). Note: all of this is with highwater marking DISABLED, and no requests are for contiguous or contiguous-best-try. So, I thought the obvious thing to do was to make sure this volume gets mounted with: $ mount/system dka0:/cache=(LIMIT=1000,EXTENT=2048) Data As in: $ help mount /cache MOUNT /CACHE /CACHE=(keyword[,...]) /NOCACHE For disks, controls whether caching limits established at system generation time are disabled or overridden. The following table lists the keywords for this qualifier: Keyword Description EXTENT[=n] Enable or disable extent caching. To enable extent and NOEXTENT caching, you must have the operator user privilege (OPER) and you must specify n, the number of entries in the extent cache. Note that NOEXTENT is equivalent to EXTENT=0; both disable extent caching. [...snip...] LIMIT=n Specifies the maximum amount of free space in the extent cache in one-thousandths of the currently available free space on the disk. However, I'm seeing behaviour that I cannot explain. OK, let's mount the volume (and just to make sure we don't get anything else involved, we'll also specify /Proc=Unique). $ mou/sys/cac=(limi=1000,ext=2048) dka0 data/proc=uniq DATA mounted on DKA0: $ sh dev dka0/full [...stuff snipped...] Free blocks 643698 Maximum files allowed 419004 Extend quantity 2048 Mount count 1 Mount status System Cache name "_P4$DKA0:XQPCACHE" Extent cache size 2048 Maximum blocks in extent cache 643698 File ID cache size 64 Blocks in extent cache 0 Looking at the volume with DFU - we see that the number of free extents is 90: ***** Free space statistics (from BITMAP.SYS) ***** Total blocks on disk : 8380080 Total free blocks : 643698 Percentage free (rounded) : 7 Total free extents : 90 <---- Largest free extent : 64287 blocks at LBN: 6334425 Average extent size (rounded) : 7152 Free space fragmentation index : 0.014 (excellent) Next let's create a file so that VMS will populate the extent cache. $ copy/log/alloc=64288 nl: x.x NL: copied to DISK$DATA:[ROYO]X.X;6 (0 records) $ dire x.x. Directory DISK$DATA:[ROYO] X.X;6 0/64296 Now, let's Show Dev/Full again: [...snipped...] Free blocks 579402 Maximum files allowed 419004 Extend quantity 2048 Mount count 1 Mount status System Cache name "_P4$DKA0:XQPCACHE" Extent cache size 2048 Maximum blocks in extent cache 579402 File ID cache size 64 Blocks in extent cache 8271 Question: What caused the number of "Blocks in extent cache" to go to 8,271 (I was really hoping it would be all of the free extents, in other words, it should be 579,402. Next, let's really exhaust everything by creating a file to mop up all free blocks: $ delete x.x. $ copy/log/alloc=643698 nl: x.x NL: copied to DISK$DATA:[ROYO]X.X;6 (0 records) $ show dev dka0/full [...snipped...] Free blocks 0 Maximum files allowed 419004 Extend quantity 2048 Mount count 1 Mount status System Cache name "_P4$DKA0:XQPCACHE" Extent cache size 2048 Maximum blocks in extent cache 0 File ID cache size 64 Blocks in extent cache 0 Again, with DFU, we can see that the file has 90 fragments, as was entirely expected: P4$DKA0:[ROYO]X.X;6 0/643698 2/90 Now, when we delete this file, I think it's reasonable to expect all 90 freed extents to end up in the extent cache ... $ delele/log x.x. DISK$DATA:[ROYO]X.X;6 deleted (643698 blocks) $ show dev dka0/fu [...] Free blocks 643698 Maximum files allowed 419004 Extend quantity 2048 Mount count 1 Mount status System Cache name "_P4$DKA0:XQPCACHE" Extent cache size 2048 Maximum blocks in extent cache 643698 File ID cache size 64 Blocks in extent cache 49950 But, no ... only 49,950 free blocks' worth of extents are in the cache. Why not all 643,698 (in 90 extents) ??? I can drill down through the UCB -> VCB -> VCA -> VCA$L_EXTCACHE 816C7AC8 to the extent cache, which looks like this: SDA> ex 816C7AC8;200 000003E8 0000C31E 00000009 00000800 .........C..h... FFFFFFFF.816C7AC8 20000000 00000000 00000000 00000000 ............... FFFFFFFF.816C7AD8 00000000 00000000 00000000 00000000 ................ FFFFFFFF.816C7AE8 004C77A2 0000066F 00000000 00000000 ........o..."wL. FFFFFFFF.816C7AF8 004F400A 00000051 004EA902 0000137A z....)N.Q....@O. FFFFFFFF.816C7B08 0056A681 0000211E 004F40B5 000007B3 3...5@O..!...&V. FFFFFFFF.816C7B18 005A649E 00000630 00596508 0000298E .)...eY.0....dZ. FFFFFFFF.816C7B28 00620595 000026B5 0061DBEC 000029A0 .)..l[a.5&....b. FFFFFFFF.816C7B38 00565CC8 00001A55 0057FD98 0000042F /....}W.U...H\V. FFFFFFFF.816C7B48 00565CC8 00001A55 00565CC8 00001A55 U...H\V.U...H\V. FFFFFFFF.816C7B58 00565CC8 00001A55 00565CC8 00001A55 U...H\V.U...H\V. FFFFFFFF.816C7B68 00565CC8 00001A55 00565CC8 00001A55 U...H\V.U...H\V. FFFFFFFF.816C7B78 00418BCC 000015BA 00565CC8 00001A55 U...H\V.:...L.A. FFFFFFFF.816C7B88 00418BCC 000015BA 00418BCC 000015BA :...L.A.:...L.A. FFFFFFFF.816C7B98 00418BCC 000015BA 00418BCC 000015BA :...L.A.:...L.A. FFFFFFFF.816C7BA8 00418BCC 000015BA 00418BCC 000015BA :...L.A.:...L.A. FFFFFFFF.816C7BB8 00418BCC 000015BA 00418BCC 000015BA :...L.A.:...L.A. FFFFFFFF.816C7BC8 00418BCC 000015BA 00418BCC 000015BA :...L.A.:...L.A. FFFFFFFF.816C7BD8 00418BCC 000015BA 00418BCC 000015BA :...L.A.:...L.A. FFFFFFFF.816C7BE8 00418BCC 000015BA 00418BCC 000015BA :...L.A.:...L.A. FFFFFFFF.816C7BF8 00418BCC 000015BA 00418BCC 000015BA :...L.A.:...L.A. FFFFFFFF.816C7C08 Some of these clearly correspond to LBN/number-of-free-blocks pairs, and which I could see in the X.X file before its deletion. Any comments/thoughts ? Anything I'm overlooking in my attempt to get all free extents to be mapped in the extent cache ? Thanks, Roy. ------------------------------ Date: Thu, 22 Nov 2007 09:22:52 -0800 (PST) From: Hein RMS van den Heuvel Subject: Re: Query re volume extent cache Message-ID: <842369c8-35b7-4fb9-b6ed-f9d3fa0116e4@i29g2000prf.googlegroups.com> On Nov 22, 10:41 am, om...@encompasserve.org (R.A.Omond) wrote: > Gentle colleagues (this is also posted on EISNER in the Notes forum): : > The goal for a particular disk volume is to have any file extend operations > as fast as possible. Thats a fine start, but curious minds want to know why this is critical to you. Just the GP (General Principle) or, is there a specific, application defined, need to meet? Maybe there are better ways to tackle those application needs? Pre-extends? Large default extentds? SET RMS/EXTE=64000 ? > $ mou/sys/cac=(limi=1000,ext=2048) dka0 data/proc=uniq > $ sh dev dka0/full > File ID cache size 64 Blocks in extent cache 0 > > Looking at the volume with DFU - we see that the number of free extents is 90: : > Largest free extent : 64287 blocks at LBN: 6334425 > Next let's create a file so that VMS will populate the extent cache. > > $ copy/log/alloc=64288 nl: x.x : > Now, let's Show Dev/Full again: > > [...snipped...] > Extent cache size 2048 Maximum blocks in extent cache 579402 > File ID cache size 64 Blocks in extent cache 8271 > > Question: What caused the number of "Blocks in extent cache" to go to 8,271 > (I was really hoping it would be all of the free extents, in other words, > it should be 579,402. Stuff gets into the extend cache by truncating (which is integral to delete), not by scanning for space. You did not specify /CONT on the copy, so I do not think that file got the large contiguous extend. I think it just started collecting free space and the 8271 is a leftover from the last free chunk it used. > Next, let's really exhaust everything by creating a file to mop up all free blocks: : > $ delele/log x.x. > DISK$DATA:[ROYO]X.X;6 deleted (643698 blocks) > $ show dev dka0/fu > [...] > Free blocks 643698 Maximum files allowed 419004 > Extend quantity 2048 Mount count 1 > Mount status System Cache name "_P4$DKA0:XQPCACHE" > Extent cache size 2048 Maximum blocks in extent cache 643698 > File ID cache size 64 Blocks in extent cache 49950 > > But, no ... only 49,950 free blocks' worth of extents are in the cache. > > Why not all 643,698 (in 90 extents) ??? I did not drill down all the way, but there is a percetage of free space involved: From F11X\V732\SMALOC ROUTINE MAX_CACHE_SPACE : ! This routine computes the maximum free space that may be ! reserved in one extent cache. We limit the amount of space in ! the cache two ways: ! (1) by absolute percentage with cache fill limit ! (2) by dividing free space by mount count plus 2. ! The latter prevents overcommittment of the extent cache in ! large clusters, which can lead do dismal thrashing situations. Hope this helps some, Hein van den Heuvel HvdH Performance Consulting. ------------------------------ Date: 22 Nov 2007 10:06:32 GMT From: "Andrew Black (delete obvious bit)" Subject: Rsync on VMS Message-ID: Is Rsync or anything equivalent available on VMS and what are peoples exeperience. I am trying to synchronise files between different disks (same and different machines) Andrwe ------------------------------ End of INFO-VAX 2007.640 ************************