1 INFO-VAX	Mon, 12 Dec 2005	Volume 2005 : Issue 690       Contents:  Re: Attaching Terminals Directly" Re: calloc() fails, no more memory" Re: calloc() fails, no more memory" Re: calloc() fails, no more memory" Re: calloc() fails, no more memory" Re: calloc() fails, no more memory" Re: calloc() fails, no more memory" Re: calloc() fails, no more memory" Re: calloc() fails, no more memory Re: DFG (Defrag) - OpenVMS- DVNETRTG (Phase IV routing) Hobbyist license? 1 Re: DVNETRTG (Phase IV routing) Hobbyist license? . Re: Help with Storageworks Drive/BA364 problem/ Re: HP : Massive strike and protest march today  Re: HP's 4Q FY05 results* Re: OpenVMS/TCPware Upgrade Results (good)- Re: propagation of write bitmaps for minicopy " Re: saving recovery data with PCSI8 Re: SDA> TCPIP SHO DEV/PORT=n/SOCK displays no BG device Re: shadowing questions ) Re: SWCC_AGENT doesn't work with ACS 8.8? , Timeout strategy: terminal vs Telnet drivers0 Re: Timeout strategy: terminal vs Telnet drivers0 Re: Timeout strategy: terminal vs Telnet drivers  F ----------------------------------------------------------------------   Date: 11 Dec 2005 18:04:39 GMT( From: volkeren@rsli.de (Volker Englisch)) Subject: Re: Attaching Terminals Directly * Message-ID: <dnhpnn$pgk$1@rrz.allgaeu.org>   FredK wrote:B > The PBXDA-BA (which is actually made by DIGI) is a PCI card thatC > will do what you want on Alpha.  For Itanium the supported method H > is to use USB serial devices - in this case, DIGI also makes the rightG > solution for you - in the form of a 8-port serial multiplexer (google F > search for DIGI Edgeport).  The USB drivers will show up in V8.3 but= > we have made them available as-needed for earlier versions.   F Great, that seems to be the ones I'm looking for. Not really available$ for low, but that's life ;-) Thanks!   V.   ------------------------------  # Date: Sun, 11 Dec 2005 18:46:06 GMT  From: "Jim" <j.n@nospam.com>+ Subject: Re: calloc() fails, no more memory > Message-ID: <Ot_mf.28317$BZ5.18728@newssvr13.news.prodigy.com>  0 "Hans Blom" <tocum2@yahoo.com> wrote in message D news:1134303970.bcd67978e90e81688cc82000703ebe4c@fe2.teranews.com... > Hello all,I > I'm running OpenVMS 7.3-2 on an Alphaserver. A programmer has developed I > an application that, in order to work with speed, wants to keep as much I > as possible of the data in memory. At some point he does an calloc() to F > get a memoryarea to keep about 400 000 pointers. He gets a null backF > from the call, basically OpenVMS saying - sorry sir, no more memory! > J > We have tried raising pgflquota, wsextent (in order to decrease need forI > paging) and every other conceivable quota both in sysuaf and sysgen. We I > can see that as long as the program works in memory everything is fine, F > but as soon as wsextent is hit and it has to start paging, it fails. > 1 > I'm stuck! Anybody got any ideas on what to do?  > 	 > Regards  >  > Hans Blom K How much space do 400,000 pointers require?  Assuming 4 bytes per pointer,  J that call requires 1,600,000 bytes of free memory somewhere.  It might be K that the pagefile is too small.  On an Alpha with 64 bit address space, it  M is hard to believe that you have run out of virtual addresses, but that is a   possibility. Jim    ------------------------------  % Date: Sun, 11 Dec 2005 20:19:49 +0000 " From: Hans Blom <tocum2@yahoo.com>+ Subject: Re: calloc() fails, no more memory J Message-ID: <1134332389.975a5b7dc6bcd3f8552d3ca4a1406370@fe2.teranews.com>  
 Jim wrote:2 > "Hans Blom" <tocum2@yahoo.com> wrote in message F > news:1134303970.bcd67978e90e81688cc82000703ebe4c@fe2.teranews.com... >  >>Hello all,I >>I'm running OpenVMS 7.3-2 on an Alphaserver. A programmer has developed I >>an application that, in order to work with speed, wants to keep as much I >>as possible of the data in memory. At some point he does an calloc() to F >>get a memoryarea to keep about 400 000 pointers. He gets a null backF >>from the call, basically OpenVMS saying - sorry sir, no more memory! >>J >>We have tried raising pgflquota, wsextent (in order to decrease need forI >>paging) and every other conceivable quota both in sysuaf and sysgen. We I >>can see that as long as the program works in memory everything is fine, F >>but as soon as wsextent is hit and it has to start paging, it fails. >>1 >>I'm stuck! Anybody got any ideas on what to do?  >>	 >>Regards  >> >>Hans Blom  > M > How much space do 400,000 pointers require?  Assuming 4 bytes per pointer,  L > that call requires 1,600,000 bytes of free memory somewhere.  It might be M > that the pagefile is too small.  On an Alpha with 64 bit address space, it  O > is hard to believe that you have run out of virtual addresses, but that is a   > possibility. > Jim  >  > C I agree with you. But shouldn't we get the infamous "PAGEFILE full, C system will try to continue" or at least something in OPERATOR.LOG? F And shouldn't accounting show that the process used an enormous amount of the paging file?      Hans   ------------------------------  # Date: Sun, 11 Dec 2005 21:07:55 GMT  From: "Jim" <j.n@nospam.com>+ Subject: Re: calloc() fails, no more memory = Message-ID: <Ly0nf.34579$tV6.7997@newssvr27.news.prodigy.net>   0 "Hans Blom" <tocum2@yahoo.com> wrote in message D news:1134332389.975a5b7dc6bcd3f8552d3ca4a1406370@fe2.teranews.com... > Jim wrote:2 >> "Hans Blom" <tocum2@yahoo.com> wrote in messageG >> news:1134303970.bcd67978e90e81688cc82000703ebe4c@fe2.teranews.com...  >>
 >>>Hello all, J >>>I'm running OpenVMS 7.3-2 on an Alphaserver. A programmer has developedJ >>>an application that, in order to work with speed, wants to keep as muchJ >>>as possible of the data in memory. At some point he does an calloc() toG >>>get a memoryarea to keep about 400 000 pointers. He gets a null back G >>>from the call, basically OpenVMS saying - sorry sir, no more memory!  >>> K >>>We have tried raising pgflquota, wsextent (in order to decrease need for J >>>paging) and every other conceivable quota both in sysuaf and sysgen. WeJ >>>can see that as long as the program works in memory everything is fine,G >>>but as soon as wsextent is hit and it has to start paging, it fails.  >>> 2 >>>I'm stuck! Anybody got any ideas on what to do? >>> 
 >>>Regards >>>  >>>Hans Blom >>E >> How much space do 400,000 pointers require?  Assuming 4 bytes per   >> pointer, L >> that call requires 1,600,000 bytes of free memory somewhere.  It might beK >> that the pagefile is too small.  On an Alpha with 64 bit address space,   >> it K >> is hard to believe that you have run out of virtual addresses, but that   >> is a  >> possibility.  >> Jim >> >>E > I agree with you. But shouldn't we get the infamous "PAGEFILE full, E > system will try to continue" or at least something in OPERATOR.LOG? H > And shouldn't accounting show that the process used an enormous amount > of the paging file?  >  >  > Hans Yes and Yes. Jim    ------------------------------  % Date: Sun, 11 Dec 2005 21:31:22 +0000 " From: Hans Blom <tocum2@yahoo.com>+ Subject: Re: calloc() fails, no more memory J Message-ID: <1134336682.3b8349c936bba3b353afc12a48d12f38@fe2.teranews.com>  
 Jim wrote:2 > "Hans Blom" <tocum2@yahoo.com> wrote in message F > news:1134332389.975a5b7dc6bcd3f8552d3ca4a1406370@fe2.teranews.com... >  >>Jim wrote: >>2 >>>"Hans Blom" <tocum2@yahoo.com> wrote in messageG >>>news:1134303970.bcd67978e90e81688cc82000703ebe4c@fe2.teranews.com...  >>>  >>>  >>>>Hello all,K >>>>I'm running OpenVMS 7.3-2 on an Alphaserver. A programmer has developed K >>>>an application that, in order to work with speed, wants to keep as much K >>>>as possible of the data in memory. At some point he does an calloc() to H >>>>get a memoryarea to keep about 400 000 pointers. He gets a null back >>> H >>>>from the call, basically OpenVMS saying - sorry sir, no more memory! >>> L >>>>We have tried raising pgflquota, wsextent (in order to decrease need forK >>>>paging) and every other conceivable quota both in sysuaf and sysgen. We K >>>>can see that as long as the program works in memory everything is fine, H >>>>but as soon as wsextent is hit and it has to start paging, it fails. >>>>3 >>>>I'm stuck! Anybody got any ideas on what to do?  >>>> >>>>Regards  >>>>
 >>>>Hans Blom  >>> E >>>How much space do 400,000 pointers require?  Assuming 4 bytes per   >>>pointer, L >>>that call requires 1,600,000 bytes of free memory somewhere.  It might beK >>>that the pagefile is too small.  On an Alpha with 64 bit address space,   >>>it K >>>is hard to believe that you have run out of virtual addresses, but that   >>>is a  >>>possibility.  >>>Jim >>>  >>>  >>E >>I agree with you. But shouldn't we get the infamous "PAGEFILE full, E >>system will try to continue" or at least something in OPERATOR.LOG? H >>And shouldn't accounting show that the process used an enormous amount >>of the paging file?  >> >> >>Hans >  > Yes and Yes. > Jim  >  > ? But we get nuttin'! Just a message from the application "memory # allocation failed". Drives me nuts.  Hans   ------------------------------    Date: 11 Dec 2005 18:50:48 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) + Subject: Re: calloc() fails, no more memory 3 Message-ID: <Kipuh2rmZOXH@eisner.encompasserve.org>   o In article <1134332389.975a5b7dc6bcd3f8552d3ca4a1406370@fe2.teranews.com>, Hans Blom <tocum2@yahoo.com> writes:   E > I agree with you. But shouldn't we get the infamous "PAGEFILE full, E > system will try to continue" or at least something in OPERATOR.LOG?   J Such memory issues in process context likely never can go to OPERATOR.LOG,E because there is no possibility of allocating the memory to send them G there.  The most that could happen would be a console message to OPA0:.    ------------------------------  # Date: Mon, 12 Dec 2005 01:15:14 GMT + From: Jack Patteeuw <jjpatteeuw@nospam.net> + Subject: Re: calloc() fails, no more memory A Message-ID: <Ca4nf.2690$3Z.2035@newsread1.news.atl.earthlink.net>   
 Jim wrote:2 > "Hans Blom" <tocum2@yahoo.com> wrote in message F > news:1134303970.bcd67978e90e81688cc82000703ebe4c@fe2.teranews.com... >  >>Hello all,I >>I'm running OpenVMS 7.3-2 on an Alphaserver. A programmer has developed I >>an application that, in order to work with speed, wants to keep as much I >>as possible of the data in memory. At some point he does an calloc() to F >>get a memoryarea to keep about 400 000 pointers. He gets a null backF >>from the call, basically OpenVMS saying - sorry sir, no more memory! >>J >>We have tried raising pgflquota, wsextent (in order to decrease need forI >>paging) and every other conceivable quota both in sysuaf and sysgen. We I >>can see that as long as the program works in memory everything is fine, F >>but as soon as wsextent is hit and it has to start paging, it fails. >>1 >>I'm stuck! Anybody got any ideas on what to do?  >>	 >>Regards  >> >>Hans Blom  > M > How much space do 400,000 pointers require?  Assuming 4 bytes per pointer,  L > that call requires 1,600,000 bytes of free memory somewhere.  It might be M > that the pagefile is too small.  On an Alpha with 64 bit address space, it  O > is hard to believe that you have run out of virtual addresses, but that is a   > possibility. > Jim  >   / Wouldn't an Alpha require 8 bytes per pointer ?   : Also, what does $SHOW PROCESS/CONTINUOUS/ID=pid and $SHOW  PROCESS/QUOTA/ID=pid   ------------------------------  % Date: Sun, 11 Dec 2005 20:19:31 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> + Subject: Re: calloc() fails, no more memory , Message-ID: <439CD01F.B556DED2@teksavvy.com>   Hans Blom wrote:E > I agree with you. But shouldn't we get the infamous "PAGEFILE full, E > system will try to continue" or at least something in OPERATOR.LOG?     H The "page file is badly fragmented message" is issued when the page fileF is oversubscribed AND over used.  I believe it is when a process tries* to write to it that the message is issued.  G If you are doing a malloc/calloc and get a null back, it means that the E memory allocation didn't happen, so it never came close to writing to  the page file.  G You'd be getting a big pointer to virtual memory and it isn't until you H start to write to it that the memory would actually materialise (forcingA other stuff to go to page file for instance). And you're not even  getting a pointer.  B A process is allowed to allocate as much RAM as the combination ofE WSQUOTA and PGFILQUOTA.  (eg: what you're allowed to have in physical H memory and what you're allowed to have in memory paged to disk. (PuristsF will point out that you can have more than WSQUOTA up to WSEXTENT, but) that is also limited to WSMAX in SYSGEN).     C Someone mentioned "calloc". This zeroes the memory.  If the area is C bigger than your WSQUOTA/WSEXTENT, the process would not be able to L bring the whole "calloced" buffer into physical memory to do the "zap to 0".  F Have you tried using malloc, and then doing a loop to zap each pointerK to 0 ? This way you never need to have the whole areea into memory at once.   H If you have enough physical RAM, you could increase the WSQUOTA/WSEXTENTC to be able to contain not only the program but also the whole large 6 memory area so that calloc would then be able to work.   ------------------------------  % Date: Sun, 11 Dec 2005 19:57:20 -0800 ( From: Jeff Cameron <roktsci@comcast.net>+ Subject: Re: calloc() fails, no more memory 0 Message-ID: <BFC23520.18D9F%roktsci@comcast.net>   On 12/11/05 1:07 PM, in article G Ly0nf.34579$tV6.7997@newssvr27.news.prodigy.net, "Jim" <j.n@nospam.com>  wrote:   > 1 > "Hans Blom" <tocum2@yahoo.com> wrote in message F > news:1134332389.975a5b7dc6bcd3f8552d3ca4a1406370@fe2.teranews.com...
 >> Jim wrote: 3 >>> "Hans Blom" <tocum2@yahoo.com> wrote in message H >>> news:1134303970.bcd67978e90e81688cc82000703ebe4c@fe2.teranews.com... >>>  >>>> Hello all, L >>>> I'm running OpenVMS 7.3-2 on an Alphaserver. A programmer has developedL >>>> an application that, in order to work with speed, wants to keep as muchL >>>> as possible of the data in memory. At some point he does an calloc() toI >>>> get a memoryarea to keep about 400 000 pointers. He gets a null back I >>>> from the call, basically OpenVMS saying - sorry sir, no more memory!  >>>>  M >>>> We have tried raising pgflquota, wsextent (in order to decrease need for L >>>> paging) and every other conceivable quota both in sysuaf and sysgen. WeL >>>> can see that as long as the program works in memory everything is fine,I >>>> but as soon as wsextent is hit and it has to start paging, it fails.  >>>>  4 >>>> I'm stuck! Anybody got any ideas on what to do? >>>>   >>>> Regards >>>>   >>>> Hans Blom >>> E >>> How much space do 400,000 pointers require?  Assuming 4 bytes per  >>> pointer,M >>> that call requires 1,600,000 bytes of free memory somewhere.  It might be K >>> that the pagefile is too small.  On an Alpha with 64 bit address space,  >>> itK >>> is hard to believe that you have run out of virtual addresses, but that  >>> is a >>> possibility. >>> Jim  >>>  >>> F >> I agree with you. But shouldn't we get the infamous "PAGEFILE full,F >> system will try to continue" or at least something in OPERATOR.LOG?I >> And shouldn't accounting show that the process used an enormous amount  >> of the paging file? >>   >>   >> Hans  > Yes and Yes. > Jim  >  > H No, because the calloc failed, so the process never received the memory.   ------------------------------  % Date: Sun, 11 Dec 2005 16:20:04 -0600 6 From: "Craig A. Berry" <craigberry@mac.com.spamfooler># Subject: Re: DFG (Defrag) - OpenVMS D Message-ID: <craigberry-AEF943.16200411122005@news.isp.giganews.com>  C In article <1134314977.085570.258540@g14g2000cwa.googlegroups.com>, &  "Ed Wilts" <ewilts@ewilts.org> wrote:   > Craig A. Berry wrote: J > > In article <43999a19$0$28638$892e7fe2@authen.yellow.readfreenews.net>,E > >  caaron@ceris.purdue-dot-edu.no-spam.invalid (Chuck Aaron) wrote:  > > @ > > > %DFG-F-SYSSRVERR, call to system service SYS$EXPREG failed/ > > > -SYSTEM-F-EXQUOTA, process quota exceeded  > > G > > I believe with DFG this generally means you are out of file headers - > > (yeah, not the most informative message).  > H > And you'd be wrong.  As somebody else pointed out, it simply means youF > don't have enough page file quota.  And yes, the message is actually8 > informative - it actually is a process quota exceeded.  G Well, I have seen at least one case where running out of page file was  G only the proximate cause and the disk could not be defragged until the  D number of headers was increased.  Obviously if increasing the quota 6 used by DFG works, then that's something to try first.   ------------------------------    Date: 11 Dec 2005 16:03:03 -0800$ From: "Bob Armstrong" <bob@jfcl.com>6 Subject: DVNETRTG (Phase IV routing) Hobbyist license?C Message-ID: <1134345783.690769.157880@o13g2000cwo.googlegroups.com>   F   Is there a reason that DVNETRTG is not included (among the 100 or so% other PAKs!) in the hobbyist program?   E   I want to set up a Multinet DECnet-over-IP circuit between by house A and another hobbyist, and without a routing node it's pretty much D impossible.  Sure, you can do it, but with an end node you either a)A won't be able to access the Multinet link, or b) won't be able to & access any other machines on your LAN.     Are there any other options?   Thanks, 
 Bob Armstrong    ------------------------------  % Date: Sun, 11 Dec 2005 20:26:39 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> : Subject: Re: DVNETRTG (Phase IV routing) Hobbyist license?, Message-ID: <439CD1C8.5AA3CA82@teksavvy.com>   Bob Armstrong wrote: > H >   Is there a reason that DVNETRTG is not included (among the 100 or so' > other PAKs!) in the hobbyist program?  > G >   I want to set up a Multinet DECnet-over-IP circuit between by house C > and another hobbyist, and without a routing node it's pretty much  > impossible.     C I have one from a decommissioned all mighty microvax II.  It is 230 / units, with "MOD_UNITS". Could this be of use ?   G Not sure on the ethical aspects, but this is from a former VMS customer 8 (they switched to Solaris/HP-UX before the HP takeover).   ------------------------------  % Date: Mon, 12 Dec 2005 00:32:17 +0800  From: prep@prep.synonet.com 7 Subject: Re: Help with Storageworks Drive/BA364 problem - Message-ID: <87wtib8ui6.fsf@prep.synonet.com>   / William Webb <william.w.webb@gmail.com> writes:   N > On 9 Dec 2005 12:13:18 -0800, mcbill20@yahoo.com <mcbill20@yahoo.com> wrote:  C >> Thanks. I'll see if the machine has enough slots to get a second F >> KZPBA.  Right now I have that, plus the slower NCR one for my CDROM >> and DLT drive.    > OMG!  E > You're running a DLT off of an NCR53C810 or whatever it is?  Narrow  > SCSI?   
 Well, yes.   > What KIND of DLT?   E TZ887. Narrow is the connection on it! Mind, it is hanging off a 1020  that may in fact be a 1040.     B BTW, does anyone have a cook book for solving SCSI port errors andJ port shut downs? Getting the stupid thing to re-init and write a dump file would be a good start...   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------    Date: 11 Dec 2005 17:16:45 -0800$ From: "AEF" <spamsink2001@yahoo.com>8 Subject: Re: HP : Massive strike and protest march todayC Message-ID: <1134350205.331916.147650@z14g2000cwz.googlegroups.com>    Dave Froble wrote: > AEF wrote: > > Lurker wrote:  > > C > >>"David J Dachtera" <djesys.nospam@comcast.net> wrote in message ) > >>news:4397A2A3.1A9C358A@comcast.net...  > >> > >>>AEF wrote:  > >>> < > >>>>So threatening to do an illegal strike is negotiating? > >>> K > >>>Try to grasp this: when negotiating fails, methods of last resort come F > >>>into play, illegal/unconstitutional legislation not withstanding. > >>C > >>So, according to your logic, if a man tries to "negotiate" with ? > >>a woman and she flatly refuses, it's alright to rape her as A > >>"methods of last resort come into play". Or at least threaten  > >>to do that.  > >  > > E > > This is an unfair tactic. I wouldn't touch this with a pulverized F > > 300-baud line! Any direct response to this used to argue about theC > > subject at hand could be subject to incorrect and very negative  > > interpretation.  > B > It's NOT an unfair tactic.  Different people will have differentH > tolerances for different issues, but, if you do not respect a law, youI > do so with the consequence of being totally responsible for the result.   F Well, the way Bill Todd pulled this one was definitely unfair. He saidF something like "So are you one of those [probable curse noun here] who5 say a woman dressing a certain way is asking for it".   C That is definitely an unfair, loaded question. You can't respond to D that without great risk of being thought extremely poorly by someoneF who misinterprets it, no matter how reasonable and correct your anwserE may be. And as I often find myself misinterpreted, I don't touch such  points at all.  F Lurker's was in the gray zone and I overreacted and said so. Again, my
 apologies.  M > If you cannot negotiate a loan with a bank, is bank robbery then justified?   ) OK. This is fair, and the answer is "No".    > 1 > > (Or are you just trying to kill this thread?)  > $ > Hey, great idea!  Can this happen? > H > > It's also unfair on another level. One could just as easily bring upD > > speeding. Someone could drive 53 mph in a 50 mph zone. Is that a  > > horrible crime? I think not! > F > And because of the excess speed, you hit and kill someone, then yes,A > it's a horrible crime.  Worse than the rape, where no one dies.   D Oh, so if you drive 49 mph in a 50 zone and hit someone and kill himC that is not a horrible crime, but going 50.0001 is? It's a horrible F outcome. It is not a horrible crime. In fact, I frequently hear on theC news about people who drive drunk, 100 mph, drag racing, and rarely F suffer any substantive consequences for it. THOSE are horrible crimes.F Driving 53 in a 50 and hitting someone is more accident than crime. IfF you insist 53 in a 50 is a crime, then we are a nation of lawbreakers.? I was on the road today and almost EVERYONE was speeding on the  interstate.   G OK, how about stealing a penny? Not a horrible crime. In fact, some may  see it as a favor!   > H > > Not that I accept David's argument. Unions get their power from lawsE > > that are passed by legislatures elected by the people, no? So the E > > unions, by going on strike, are hurting the whole city, including J > > people that vote for legislators who make laws that allow the union toI > > exist in the first place. And said people and laws have made it clear J > > that a strike will not be tolerated. The Taylor Law provides some veryJ > > stiff fines. If there is a strike, hopefully the law will be enforced. > I > David's far out on this thread.  He wants the perspective he wants, and H > no one will convince him otherwise.  Just admit it and lower the noise > level.  ? Many posters are quite stubborn. David certainly doesn't have a  monopoly on that!    ------------------------------  % Date: Sun, 11 Dec 2005 19:41:51 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ! Subject: Re: HP's 4Q FY05 results , Message-ID: <439CC74D.EAF4D230@teksavvy.com>   Alan Greig wrote: C > workstations. Given that HP is out of the workstation market with F > Itanium, current customers are being pushed towards Windows or LinuxH > workstations as replacements or are sticking with PA-RISC workstations    F In fairness, while HP and Intel have stated that that IA64 thing isn'tE designed for workstations (anymore), HP does sells small servers that D can be configured as a workstation.  So those who need it can get itH even though the web site may not have a section on IA64 workstations andJ even though HP stated in 2004 that it would stop making IA64 workstations.  F However, last years's statement would also have had quite an impact onH software writers and this may result in much of the workstation softwareF not being available on that IA64 thing.  And that is a bigger problem.   ------------------------------  % Date: Mon, 12 Dec 2005 00:27:03 +0800  From: prep@prep.synonet.com 3 Subject: Re: OpenVMS/TCPware Upgrade Results (good) - Message-ID: <871x0ja9bc.fsf@prep.synonet.com>   + "Neil Rieck" <n.rieck@sympatico.ca> writes:   F > I wonder if it is because so much stuff is loaded into the XFC? Does@ > anyone know if a "DISK I/O" is "physical only" or does it also% > includes transactions with the XFC?   I When I looked at that stuff, back about 5.2 or so, it was part of queuing B the IRP to the driver. So I'd guess that no driver, not DIO count.  J Look at the cache stats and do a bit of arithmatic and see what drops out.   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Sun, 11 Dec 2005 19:06:08 -0800 , From: Ken Fairfield <my.full.name@intel.com>6 Subject: Re: propagation of write bitmaps for minicopy+ Message-ID: <dnipf4$rdb$1@news01.intel.com>   / Phillip Helbig---remove CLOTHES to reply wrote: J > If I do DISMOUNT/POLICY=MINICOPY, do I have to issue the MOUNT from the K > same node in order to get MINICOPY to work?  Do I have to make sure that  J > the shadow copy is initiated from the same node to get MINICOPY to work? > 7 > In other words, when the write bitmap is created when I > DISMOUNT/POLICY=MINICOPY is issued, when, if ever, does this propagate   > to other nodes?   B     The first thing you have to know is that MINICOPY maintains an@ in-memory bitmap of clusters of blocks for the whole shadow set.= Secondly, since shadow sets are cluster-wide entities, when a B shadow member is dismounted, all nodes with the shadow set mounted> have to communicate to all other nodes which blocks they write to.   A     I find the inline HELP for MOUNT/POLICY=MINICOPY and DISMOUNT A /POLICY=MINICOPY confusing! :-(  The entry for DISMOUNT says that B a write bitmap will be created when a single member is dismounted.B It doesn't say whether other bitmap-capable nodes will also createA bitmaps (likely not) and neither this entry nor the one for MOUNT @ say that the subsequent mini-copy of the dismounted member needsC to be executed from the node that dismounted it...but that may very A well be the case.  The entry for MOUNT implies that the _initial_ A mount in cluster of a shadow set must specify /POLICY=MINICOPY to D allow subsequent minicopies (and creates the write bitmap), but thatD seems too restrictive, etc. You'll need to carefully read the Volume Shadowing for OpenVMS manual...   K > In particular, if I dismount a physical member of a shadow set on a node  I > which is to be shut down and rebooted, and the shadow set gets mounted  H > during the startup sequence, what do I need to do to make sure that a  > MINICOPY occurs?  E     You need to make sure there's an active write bitmap on some node C in the cluster that has the shadow set mounted, and that you're NOT A shutting down.  The bitmap is memory-resident and won't survive a  reboot (obviously).    	-Ken  --  6 I don't speak for Intel, Intel doesn't speak for me...  
 Ken Fairfield ! D1C Automation VMS System Support " who:   kenneth dot h dot fairfield where: intel dot com   ------------------------------  % Date: Sun, 11 Dec 2005 15:18:06 -0600 E From: Staffan Tjernstrom <thisisafakeaddress@staffan.tjernstrom.name> + Subject: Re: saving recovery data with PCSI D Message-ID: <pan.2005.12.11.21.18.05.324331@staffan.tjernstrom.name>  G Peter 'EPLAN' LANGSTOEGER scribbled something like this, on Sun, 11 Dec  2005 15:28:33 +0100:  C >>Other than reading all the notes, is there a quick way to see if  - >>something at ITRC is a patch or a full kit?  > F > Anything named VMSxyz_ or ECO should be an ECO (but isn't always ;-)2 The trick is in the last digit of the PCSI file :-   1 - Full (Layered Product) 2 - Operating SystemI 3 - Partial (An upgrade to currently installed software). Changes product  version of installed software . 4 - Partial (A correction to currently installJ installed software). Does not change the version of the installed software3 5 - Platform (Integrated set of software products)   6 - Transition (Product H information used to register a product that was provided by VMSINSTAL or	 similar)  : 7 - Mandatory Update. Functionality the same as ($) above.   HTH    ------------------------------  % Date: Sun, 11 Dec 2005 22:25:54 -0800 = From: "John Gemignani, Jr." <john@nfw-invalid.cibtrikker.com> A Subject: Re: SDA> TCPIP SHO DEV/PORT=n/SOCK displays no BG device , Message-ID: <SPednfwstMVpigDeRVn-vw@dls.net>  G A BG device will only be present if there is a channel assigned to the   socketE by at least one process.  Adding /SOCKET to the TCPIP SHOW command is L looking for the socket structure in the memory tables as opposed to scanning8 the BG device list and linking to the socket from there.  M The socket structure often lingers after close to ensure that it catches all   packets G no matter what path around the globe they took.  Setting REUSEADDR will L allow your app to replace the socket before the normal timeout value, which  I , believe is SUPPOSED TO BE about two minutes.  1 You mentioned something about a terminal session?   L I did all of the work on the TCPIP SDA extension.  Some people bitched a fewL years ago about some of the gags that I had put in there, so I removed them  beforeL I left HP and moved on.  A lot of the commands have a special (undocumented)C /DEBUG qualifier that usually displays special information such as:            .... SO at xxxxxxxx ...   2 In this case, you can look at the structure using:  $         FORMAT /TYPE=SOCKET xxxxxxxx  L NOTE: Normally this would be /TYPE=SO, but for some reason the tables built  with the netstack J called them SOCKETS and not SO.  Check out "TCPIP SHOW MEMORY /TYPES" and  you'll6 see a list of types built into the kernel's knowledge.  H (I'm starting to forget a lot of my VMS, so I hope that I got it right.)  I If you want to see all of the socket structures and such, to see if your   unexplained ' socket is somewhere in the system, use:   B         TCPIP SHOW MEMORY /TYPE=SOCKET /COMMAND="FORMAT /TYPE=SO "   John  > "Gerald_Marsh" <gerald.marsh@barclays.co.uk> wrote in message = news:1134143138.914035.319050@g47g2000cwa.googlegroups.com... G > I've managed to replicate the problem on the OpenVMS system using the G > noddy client and server programs supplied with TCPIP Services. I just D > put a big wait in the client before closing the socket. The serverE > sends the test string and exits ok - It's socket is in Closewt. The ) > client immediately goes into FIN_WAIT2.  > F > If I kill the terminal emulation session, the socket closes ok afterE > going into TIME_WAIT for a few minutes. However, if I establish the G > same situation from a PC (NT4) using a Java client then the FIN_WAIT2 ( > persists - even if I power off the PC!G > (Java class was cross-compiled from OpenVMS - File transfer was a bit % > of a git but it worked eventually!) E > Tried setting KEEPALIVE option but that hasn't made any difference.  > @ > I'll have a look after the weekend to see if it has timed out. > * > Bye for now and thanks for the comments, > 	 > Gerald.  >  >  >  > Gerald Marsh wrote:  >> Hello VMSers  >>I >> Here's a cracker which maybe should be targetted at the TCPIP brigade.  >> >> Scenario... >>I >> OpenVMS process running happilly receiving messages via TCP/IP from NT  >> box.  >>8 >> Process fails to respond to messages from NT system -. >> TCPIP> SHO DEV/PORT=n shows no such device. >>B >> After much web and newsgroups searching, a better command of... >>G >> SDA>TCPIP SHO DEV/PORT=n/SOCK shows some big hex number and a socket 1 >> in FIN_WAIT_2. The BG device no longer exists.  >>G >> The OpenVMS listener can be STOP/ID'd and refuses to restart because 6 >> of a"addrinuser" error - 48, if I recall correctly. >>D >> After some random time the situation resolves itselfs - somewhereG >> between 42 mins (Hitchhiker's Guide to the Galaxy, springs to mind!) I >> but can go up to over an hour. No TPCIP Services timer seems to relate F >> to this and the supplier of the application - both OpenVMS and NT - >> cannot explain it either! >>B >> My intellectual capacity cannot handle the well published stateD >> diagrams and apply them to our situation.: The socket seems to beE >> awaiting a FIN from the other side and then should send it an ACK. A >> Some research of the relevant RFC's suggest the damn thing can F >> legitimately stay in the FIN_WAIT_2 state for ever as the app couldD >> expect to process real info. Cannot undertand that it the app has >> called a close()! >>I >> The supplier - who is very responsive on this but a bit flummoxed - is E >> going to go through formal channels but I'm hoping to contact that B >> strange combination of a VMS Systems Manager and IP specialist!! >> (One of the many black arts??)  >> >>! >> Keep theOpenVMS flag a'flying,  >>
 >> Gerald. >> >> Gerald Marsh  >>7 >> gerald -at_Sign- cyfer -dot- demon -dot- co -dot- uk / >> (And I really get miffed having to do that!)  >    ------------------------------  % Date: Sun, 11 Dec 2005 19:14:38 -0800 , From: Ken Fairfield <my.full.name@intel.com>  Subject: Re: shadowing questions+ Message-ID: <dnipuv$rkl$1@news01.intel.com>   / Phillip Helbig---remove CLOTHES to reply wrote: F > Here are some questions which I would prefer to have answered here, ) > rather than testing them on my cluster.   
 [big snip]  E > My third question is whether such logic makes sense for an ALPHA as H > well.  In other words, suppose an ALPHA is to be rebooted, and I do a K > DISMOUNT/POLICY=MINICOPY on the disks connected to it from another ALPHA  I > in the cluster.  When this ALPHA reboots, I obviously don't want a VAX  H > to pick up the copy, since then no MINICOPY is possible.  (Thus, when I > the special logical is defined at DISMOUNT, I also set SHADOW_MAX_COPY  F > to 0 on all VAX nodes via SYSMAN.)  However, what about the booting B > ALPHA itself.  Is it capable of performing a MINICOPY to a disk J > connected (only) to it (but, of course, MSCP served to all other nodes),K > or does this have to be done from another ALPHA.  (I'm wondering whether  K > the write bitmaps propagate to a node after it boots, like, for example,  J > cluster-wide logicals.)  If so, then I shouldn't set SHADOW_MAX_COPY to B > 0 on the ALPHAs when booting, so that the booting ALPHA has the D > possibility to pick up the minicopy (which might be the preferred F > scenario).  If not, then I should use the same code as on the VAXes.  A     Bitmaps don't propagate.  Even in host-based minimerge, which E used a lot of the machinery created for minicopy, in a 2-node cluster C with one node crashing, the remaining node has to do all the merges < because the merge write-bitmap is memory resident and is NOTB copied to the node that crashed and rebooted.  I'd expect minicopyA to be more restrictive than minimerge since it predates minimerge A and because it was explicitly designed for _controlled_ dismounts  and mounts, not for crashes...  F > Is there some way to allow a MINICOPY in the case of unplanned node  > crashes?  ...         No.  End of story.    	-Ken  --  6 I don't speak for Intel, Intel doesn't speak for me...  
 Ken Fairfield ! D1C Automation VMS System Support " who:   kenneth dot h dot fairfield where: intel dot com   ------------------------------  % Date: Sun, 11 Dec 2005 18:39:25 -0800 , From: Ken Fairfield <my.full.name@intel.com>2 Subject: Re: SWCC_AGENT doesn't work with ACS 8.8?+ Message-ID: <dninsv$qkg$1@news01.intel.com>    Malcolm Dunnett wrote:. > In article <4394F92E.65D4C1B7@comcast.net>, 9 >    David J Dachtera <djesys.nospam@comcast.net> writes:  > J >>We're running V88F-2, and we're seeing strangeness we can't account for,G >>like multiple HSG pairs going flaky unpredictably: the serial console E >>stops responding, and one or more served devices ends up showing in E >>MntVerifyTimeout until you restart the HSGs from their "//" button.  >>H >>We've also been having issues where a disk in an EMA array babbling on? >>the SCSI bus drives the HSG pair crazy, with similar outcome.  > 
 >    Ouch!   Indeed!   H >    I've also noticed some strange delays when mounting a shadow set onH > a single node - seems to stall for 10-15 seconds sometimes rather than7 > mounting right away - but it doesn't seem repeatable.  > I >    Anybody else want to share an experience with V88F-2? Should I stick  > with 8.6F?  A      All our disks a served as JBOD from the HSG's, and we see no  problems with ACS 8.8F-2.   E      HOWEVER! If you do controller-based mirroring (RAID 1, RAID 0+1, A etc.), do be aware that there are two patches out that you really $ should apply: ACS 8.8F-3 and 8.8F-4.  B      As I've mentioned in other posts, we've had a lot of problems@ with soft errors on large disks (146GB universal drives).  Under@ earlier  versions of ACS, typically, v8.7F-3 (there were variousC fixes going from v8.6 to 8.7, but a great deal of those fixes apply F to more "complex" environments, e.g., serving mutiple, non-cooperating= Windows servers...).  Under v8.7, we just don't get bad block @ replacement like one would like.  Also, and especially on EMA's,= we've seen bad disks cause the controller to attempt "heroic" B recovery, trying over and over again to read or write to the disk,> causing all the disks on that SCSI bus to be unavailable, when> what one really wants is to declare and error and allow VMS to> eject it from the HBVS shadow set.  V8.8-2 is _supposed_ to be> better at allowing bad block replacement (we don't have enoughA experience to know yet whether it does), and it has a new setting A for units, HOST_REDUDANT, which is supposed to keep the contoller  from trying to be a hero...    	-Ken  --  6 I don't speak for Intel, Intel doesn't speak for me...  
 Ken Fairfield ! D1C Automation VMS System Support " who:   kenneth dot h dot fairfield where: intel dot com   ------------------------------  % Date: Sun, 11 Dec 2005 21:56:45 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 5 Subject: Timeout strategy: terminal vs Telnet drivers , Message-ID: <439CE6E2.D659D5D0@teksavvy.com>  3 With the terminal driver, one can do the following:    wait for 1 character eternally loop: 8 read 500 characters with a timeout of a few milliseconds goto loop if not timeout.     G This way, you can process bursts of data very efficently and go back to  "sleep" when data stops coming.       H The TCPIP stack does not support timeouts in read QIOs. What is the best@ way to emulate the above performance for an inbound telnet style  communcation to an application ?   ------------------------------  % Date: Mon, 12 Dec 2005 11:49:10 +0800 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> 9 Subject: Re: Timeout strategy: terminal vs Telnet drivers 1 Message-ID: <dnis17$dfo$1@news-02.connect.com.au>    Hi JF,  H Isn't this why you have the choice of blocking and non-blocking? (And ifJ you're sensible enough to use the $QIO interface then you have the benefit0 of AST processing anyway so what's the problem?)  K Even if you wanted to, I don't think you can use the $settimr/$cancel combo F that other drivers like 'cos I think it has this lovely side-effect of closing the socket.   L I normally deal with message-oriented protocols rather than a burst of bytesI (come back DECnet all is forgiven :-) but what works for me is, you do an J asynchronous Peek followed by a non-blocking Read which obviously may read more bytes than were peeked.   Regards Richard Maher   : "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message& news:439CE6E2.D659D5D0@teksavvy.com...5 > With the terminal driver, one can do the following:  >   > wait for 1 character eternally > loop: : > read 500 characters with a timeout of a few milliseconds > goto loop if not timeout.  >  > I > This way, you can process bursts of data very efficently and go back to ! > "sleep" when data stops coming.  >  >  > J > The TCPIP stack does not support timeouts in read QIOs. What is the bestB > way to emulate the above performance for an inbound telnet style" > communcation to an application ?   ------------------------------  % Date: Sun, 11 Dec 2005 22:06:35 -0800 = From: "John Gemignani, Jr." <john@nfw-invalid.cibtrikker.com> 9 Subject: Re: Timeout strategy: terminal vs Telnet drivers , Message-ID: <nOOdnYygXMHwjgDeRVn-gg@dls.net>  ) Actually, you have several possibilities:   I 1) The $QIO/$SETIMR/$CANCEL mechanism ~does~ work and does not close the   socket. M      I would use a combo that uses one EFN for the $QIO, one for the $SETIMR  
 and a $WFLOR. J     User $CANTIM/$CANCEL as appropriate.  I used a mechanism like this to  implement a select!     that also supports terminals.   L 2) You can use the TNQIO front end for the socket and get the same behavior  that you described     with terminal timeouts.   1 3) Use what works best --- select with a timeout.    John  ? "Richard Maher" <maher_rj@hotspamnotmail.com> wrote in message  + news:dnis17$dfo$1@news-02.connect.com.au...  > Hi JF, > J > Isn't this why you have the choice of blocking and non-blocking? (And ifL > you're sensible enough to use the $QIO interface then you have the benefit2 > of AST processing anyway so what's the problem?) > H > Even if you wanted to, I don't think you can use the $settimr/$cancel  > combo H > that other drivers like 'cos I think it has this lovely side-effect of > closing the socket.  > I > I normally deal with message-oriented protocols rather than a burst of   > bytes K > (come back DECnet all is forgiven :-) but what works for me is, you do an L > asynchronous Peek followed by a non-blocking Read which obviously may read > more bytes than were peeked. >  > Regards Richard Maher  > < > "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message( > news:439CE6E2.D659D5D0@teksavvy.com...6 >> With the terminal driver, one can do the following: >>! >> wait for 1 character eternally  >> loop:; >> read 500 characters with a timeout of a few milliseconds  >> goto loop if not timeout. >> >>J >> This way, you can process bursts of data very efficently and go back to" >> "sleep" when data stops coming. >> >> >>K >> The TCPIP stack does not support timeouts in read QIOs. What is the best C >> way to emulate the above performance for an inbound telnet style # >> communcation to an application ?  >  >    ------------------------------   End of INFO-VAX 2005.690 ************************