Archive-Date: Tue, 3 Aug 2004 14:16:16 -0400 Date: Tue, 03 Aug 2004 13:12:38 -0500 (CDT) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: Re: Process Software Support phone numbers are down In-Reply-To: "Your message dated Mon, 26 Jul 2004 16:28:03 -0500 (CDT)" <01LCX9KTYDLC8WW8W4@goatley.com> To: Hunter Goatley CC: goathunter@goatley.com BCC: tcpware-announce@lists.process.com Message-ID: <01LD891O64UO8WWD5E@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Just FYI, our Support telephone numbers are still down. We're still waiting for some kind of paperwork to make its way through the phone company. I'll post again as soon as they're working, but until then, please call the main Process Software number for Support calls: Toll-free: 800-722-7770 Direct: 508-879-6994 Thanks for your patience. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Tue, 10 Aug 2004 10:33:35 -0400 Date: Tue, 10 Aug 2004 09:27:16 -0500 (CDT) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: Process Software Support phone numbers are UP! To: goathunter@goatley.com CC: goathunter@goatley.com BCC: TCPware-Announce@Lists.process.com Message-ID: <01LDHT9XBWHK8WWJMU@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Hello! The Process Software Support telephone numbers are operational again (finally---the phone company took a little over two weeks to get it all straightened out). These numbers now work again: 800-394-8700 508-628-5074 We apologize for any inconvenience the problem may have caused. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Thu, 26 Aug 2004 07:59:57 -0400 Date: Thu, 26 Aug 2004 13:58:07 +0200 From: =?iso-8859-15?Q?Vorl=E4nder=2C_Martin?= Reply-To: Info-TCPware@process.com Subject: Once again: RPC server exceeds quota To: info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable I wrote on July 26: > our (asynchronous [1]) RPC server bombs out of a request with >=20 > %RPC-E-RECVERR, error receiving data > -SYSTEM-F-EXQUOTA, process quota exceeded >=20 > The request's data isn't particularly big or complicated;=20 ... > That makes 19300 bytes of sent data (if my calculation is right). > Shouldn't place too heavy a burden on the server process... > > Problem is: the RPC server gives the error message without any > chance of finding out exactly which quota it is running out of > (or is there)? Okay, so reading the documentation got me a bit further: Chapter 13 of the programming guide states: "When TCPA receives requests greater than 4Kbytes, it uses significantly = more memory than TCP uses for the same size requests. TCP reads in = 4Kbytes=20 of data, processes the data, then reads more data as necessary. TCPA = reads=20 all of the data before calling the server dispatch routine." What I didn't yet find out is what "significantly more memory" would mean. I increased the RPC server's memory significantly and still get EXQUOTA?! > [1] If someone can show me a way to serve multiple clients using > TCPware's DEC C Socket library RPC routines, I'd happily leave the > old TCPA API behind. This still holds. cu, Martin --=20 | Martin Vorlaender | OpenVMS rules! Cetero censeo | work: mv@pdv-systeme.de Redmondem delendam esse. | http://www.pdv-systeme.de/users/martinv/ | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Thu, 26 Aug 2004 10:26:28 -0400 Date: Thu, 26 Aug 2004 08:24:30 -0600 From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: Re: Once again: RPC server exceeds quota In-Reply-To: To: info-tcpware@process.com Message-ID: <6.1.0.6.0.20040826082340.01f58668@192.168.1.145> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii References: Since it is a Buffered IO what about the Sysgen parameter MAXBUF At 05:58 AM 8/26/2004, you wrote: >I wrote on July 26: > > our (asynchronous [1]) RPC server bombs out of a request with > > > > %RPC-E-RECVERR, error receiving data > > -SYSTEM-F-EXQUOTA, process quota exceeded > > > > The request's data isn't particularly big or complicated; >... > > That makes 19300 bytes of sent data (if my calculation is right). > > Shouldn't place too heavy a burden on the server process... > > > > Problem is: the RPC server gives the error message without any > > chance of finding out exactly which quota it is running out of > > (or is there)? > >Okay, so reading the documentation got me a bit further: > >Chapter 13 of the programming guide states: > >"When TCPA receives requests greater than 4Kbytes, it uses significantly >more memory than TCP uses for the same size requests. TCP reads in 4Kbytes >of data, processes the data, then reads more data as necessary. TCPA reads >all of the data before calling the server dispatch routine." > >What I didn't yet find out is what "significantly more memory" >would mean. I increased the RPC server's memory significantly and >still get EXQUOTA?! > > > [1] If someone can show me a way to serve multiple clients using > > TCPware's DEC C Socket library RPC routines, I'd happily leave the > > old TCPA API behind. > >This still holds. > >cu, > Martin >-- > | Martin Vorlaender | OpenVMS rules! > Cetero censeo | work: mv@pdv-systeme.de > Redmondem delendam esse. | http://www.pdv-systeme.de/users/martinv/ > | home: martin@radiogaga.harz.de Jim Mehlhop Join Cauce to outlaw spam http://www.cauce.org/