Archive-Date: Sun, 03 Aug 1997 17:00:31 GMT Subject: Re: Terminal IP Queues on OPENVMS Message-ID: <33e4b50e.77867617@news> From: corbett@process.com (Michael Corbett) Date: Sun, 03 Aug 1997 17:00:31 GMT References: <5qta8l$e87@sjx-ixn8.ix.netcom.com> On Sun, 20 Jul 1997 15:13:13 GMT, royalef@aol.com (Royal E. Frazier Jr.) wrote: >We have several IP queues setup by a previous employee using TCPWARE. >All of them are server queues, none are terminal. Is there any >restriction that prevents a TCPWARE queue from being a TERMINAL DQS >queues? Having all server IP queus prevents us from assigning them to >eachother during outages. I'm assuming these are TSSYM queues and not LPS queues. Because the queues use the TCPWARE_TSSYM symbiont they have to be SERVER queues. An option would be to would be to create a permanent NTA device and have a queues print to it. Permanent NTA devices were introduced in 5.2-3. There is a drivers patch (DRIVERS_523P010) that should be installed before using the Permanent NTA devices. There is also a possibility of data loss with printers that reset the connection. This is being worked on and a patch will be available to correct this. regards Mike ================================================================================ Archive-Date: Sun, 3 Aug 1997 21:27:21 +0100 Subject: Re: Terminal IP Queues on OPENVMS Message-ID: From: Marc Sheppard Date: Sun, 3 Aug 1997 21:27:21 +0100 References: <5qta8l$e87@sjx-ixn8.ix.netcom.com> <33e4b50e.77867617@news> MIME-Version: 1.0 In article <33e4b50e.77867617@news>, Michael Corbett writes i'M HAVING PROBLEMS setting up telnet devices in Batch or in detach processes!! any news on a fix marc >On Sun, 20 Jul 1997 15:13:13 GMT, royalef@aol.com (Royal E. Frazier >Jr.) wrote: > >>We have several IP queues setup by a previous employee using TCPWARE. >>All of them are server queues, none are terminal. Is there any >>restriction that prevents a TCPWARE queue from being a TERMINAL DQS >>queues? Having all server IP queus prevents us from assigning them to >>eachother during outages. > > I'm assuming these are TSSYM queues and not LPS queues. >Because the queues use the TCPWARE_TSSYM symbiont they >have to be SERVER queues. > > An option would be to would be to create a permanent NTA >device and have a queues print to it. Permanent NTA devices were >introduced in 5.2-3. There is a drivers patch (DRIVERS_523P010) that >should be installed before using the Permanent NTA devices. There >is also a possibility of data loss with printers that reset the >connection. This is being worked on and a patch will be available to >correct this. > >regards >Mike > > -- Marc Sheppard ================================================================================ Archive-Date: Mon, 04 Aug 1997 15:12:46 GMT Subject: Re: Terminal IP Queues on OPENVMS Message-ID: <33e5f0ea.158727768@news> From: corbett@process.com (Michael Corbett) Date: Mon, 04 Aug 1997 15:12:46 GMT References: <5qta8l$e87@sjx-ixn8.ix.netcom.com> <33e4b50e.77867617@news> On Sun, 3 Aug 1997 21:27:21 +0100, Marc Sheppard wrote: > >i'M HAVING PROBLEMS setting up telnet devices in Batch or in detach >processes!! any news on a fix A patch is being worked on to correct this problem. regards Mike +-----------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Corporation Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Wed, 06 Aug 1997 09:03:06 +0200 Subject: TCPware select() does not select... Message-ID: <33E821A9.CACDBB44@neurope.ikea.com> From: "Anders =?iso-8859-1?Q?=D6stling?=" Date: Wed, 06 Aug 1997 09:03:06 +0200 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello Some time ago I asked a couple of questions regarding a strange problem that I have with an app on our system. I was then told to upgrade a (rather) old TCPware to V5.x, and that is what I have done now. Working setup: OpenVMS 6.2/Alpha, TCPware 5.1, DECC 5.2 Broken setup: OpenVMS 5.5-2/VAX, Tcpware 5.2, DECC 5.2 The problem: The application is listening on three sockets with a select() call. When a connection is made the first time, it works fine, the connect is accepted an the client request is sent to a newly created thread. The main thread is returning to the select() loop after dispatching the first message. When the second message arrives, nothing happens. It seems like the select() call never gets notified (on the VAX). Note that the Alpha versions works perfect, so I dont buy any application errors. The same source/server is running fine on AIX, Linux, Digital Unix as well (and soon NT). mo.tv_sec =3D gTimeout; mo.tv_usec =3D 0; #ifdef _AIX s =3D select (32,&fd,0,0,&tmo); // AIX lacks FD_SETSIZE.. #else s =3D select (FD_SETSIZE,&fd,0,0,&tmo); #endif=18 I suspect library problems, or linking/compiler switches that are = faulty, so I include = mhsnd1/mhsanos.rt>type rtr.opt This is the options file that I use losys$share:cma$tis_shr.exe/share sys$share:cma$lib_shr.exe/share sys$share:cma$rtl.exe/share sys$share:cma$open_lib_shr.exe/share sys$share:cma$open_rtl.exe/share C-switches on ALPHA (works) EXTRADEFS =3D /DEFINE=3D(_VMS_TCPWARE,POSIX_THREADS,DEBUG,VMS) CCFLAGS =3D /DEBUG /NOOPTIMIZE /NOMEMBER_ALIGN /ASSUME=3DNOALIGNED /STAND=3DCOMMON = C-switches on VAX (works, sort of...) EXTRADEFS =3D /DEFINE=3D(_VMS_TCPWARE,POSIX_THREADS,DEBUG,_REENTRANT) CCFLAGS =3D /DECC /STANDARD=3DCOMMON /DEBUG /NOOPTIMIZE An analyze/image of the resulting exe's shows that both are linked against the new DECC library and not the old VAXCRTL. Any clues are welcome since this problem start to get very annoying ! Best regards Anders = -- = +--------------------------------------------------------------+ Anders =D6stling IKEA Svenska AB (European IS Dept.) Virtual contact anders.ostlingneurope.ikea.com Physical contact Box 228, 260 35 Odakra, Swe, +46-42-25 73 45 ================================================================================ Archive-Date: XXX, 6 Aug 1997 16:19:24 -0400 Subject: Re: TCPware select() does not select... Message-ID: <1997Aug6.161924@process.com> From: volz@process.com (Bernie Volz) Date: 6 Aug 97 16:19:24 -0400 References: <33E821A9.CACDBB44@neurope.ikea.com> In article <33E821A9.CACDBB44@neurope.ikea.com>, "Anders =?iso-8859-1?Q?=D6stling?=" writes: > Hello > > Some time ago I asked a couple of questions regarding a strange > problem that I have with an app on our system. I was then told > to upgrade a (rather) old TCPware to V5.x, and that is what I have > done now. > > Working setup: OpenVMS 6.2/Alpha, TCPware 5.1, DECC 5.2 > Broken setup: OpenVMS 5.5-2/VAX, Tcpware 5.2, DECC 5.2 > > The problem: > > The application is listening on three sockets with a select() call. > When a connection is made the first time, it works fine, the connect > is accepted an the client request is sent to a newly created thread. > The main thread is returning to the select() loop after dispatching > the first message. When the second message arrives, nothing happens. > It seems like the select() call never gets notified (on the VAX). Note > that the Alpha versions works perfect, so I dont buy any application > errors. The same source/server is running fine on AIX, Linux, Digital > Unix as well (and soon NT). > > mo.tv_sec =3D gTimeout; > mo.tv_usec =3D 0; > > #ifdef _AIX > s =3D select (32,&fd,0,0,&tmo); // AIX lacks FD_SETSIZE.. > #else > s =3D select (FD_SETSIZE,&fd,0,0,&tmo); > #endif=18 > > I suspect library problems, or linking/compiler switches that are = > > faulty, so I include = > > > mhsnd1/mhsanos.rt>type rtr.opt This is the options file that I use > losys$share:cma$tis_shr.exe/share > sys$share:cma$lib_shr.exe/share > sys$share:cma$rtl.exe/share > sys$share:cma$open_lib_shr.exe/share > sys$share:cma$open_rtl.exe/share > > C-switches on ALPHA (works) > > EXTRADEFS =3D /DEFINE=3D(_VMS_TCPWARE,POSIX_THREADS,DEBUG,VMS) > CCFLAGS =3D /DEBUG /NOOPTIMIZE /NOMEMBER_ALIGN /ASSUME=3DNOALIGNED > /STAND=3DCOMMON > = > > C-switches on VAX (works, sort of...) > EXTRADEFS =3D /DEFINE=3D(_VMS_TCPWARE,POSIX_THREADS,DEBUG,_REENTRANT) > CCFLAGS =3D /DECC /STANDARD=3DCOMMON /DEBUG /NOOPTIMIZE > > An analyze/image of the resulting exe's shows that both are linked > against > the new DECC library and not the old VAXCRTL. > > Any clues are welcome since this problem start to get very annoying ! > > Best regards > > Anders = Are you using the standard C RTL socket calls available in OpenVMS or are you using the TCPware specific socket library. We'd highly recommend you use the C RTL socket calls, not the TCPware socket library. The C RTL uses UCX Emulation (BGDRIVER) QIOs. Note that the TCPware socket library on VAX is designed to run with VAX C (VAXCRTL), not DEC CRTL. So, if you are using the TCPware socket library, that might explain the problem?? Please indicate which socket library set you are using. If you link against SYS$SHARE:TCPWARE_SOCKLIB_SHR.EXE, then it is the TCPware library. - Bernie Volz Process Software ================================================================================ Archive-Date: Thu, 07 Aug 1997 08:29:02 +0000 Subject: Re: TCPware select() does not select... Message-ID: <33E9874E.3C09CAB5@process.com> From: Geoff Bryant Date: Thu, 07 Aug 1997 08:29:02 +0000 References: <33E821A9.CACDBB44@neurope.ikea.com> MIME-Version: 1.0 To: Anders Östling Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Anders Östling wrote: > > Hello > > Some time ago I asked a couple of questions regarding a strange > problem that I have with an app on our system. I was then told > to upgrade a (rather) old TCPware to V5.x, and that is what I have > done now. > > Working setup: OpenVMS 6.2/Alpha, TCPware 5.1, DECC 5.2 > Broken setup: OpenVMS 5.5-2/VAX, Tcpware 5.2, DECC 5.2 > [...] > Anders > > -- > +--------------------------------------------------------------+ > Anders Östling IKEA Svenska AB (European IS Dept.) > Virtual contact anders.ostlingneurope.ikea.com > Physical contact Box 228, 260 35 Odakra, Swe, +46-42-25 73 45 I think the most likely problem is the VAX/DECC combination. For this situation, you most likely need to use a different types.h. I believe that the default types.h that we provide is the old version which was compatable with VAXC. There is a new version provided with TCPware 5.2 that should work with DECC. Look for the types.h file in the [.RPCXDR] subdirectory of the TCPWARE_INCLUDE directory and try using that. If that doesn't help, you should most likely try logging a support call. ---------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Thu, 07 Aug 1997 12:02:45 -0600 Subject: TCPWARE error message? Message-ID: <870972848.12043@dejanews.com> From: wells@syrres.com Date: Thu, 07 Aug 1997 12:02:45 -0600 Reply-To: wells@syrres.com I am running TCPware 3.1 on vms5.5.2 getting the message: Failed to create RPC Client /../../../tmp/statd -vulnerable RPC: Unknown Host at my console.  Have rebooted, checked logs etc... Have no way of tracking this down. Any ideas? Thanks. wells@syrres.com -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet ================================================================================ Archive-Date: XXX, 7 Aug 1997 19:06:12 -0400 Subject: Re: TCPWARE error message? Message-ID: <1997Aug7.190612@process.com> From: volz@process.com (Bernie Volz) Date: 7 Aug 97 19:06:12 -0400 References: <870972848.12043@dejanews.com> In article <870972848.12043@dejanews.com>, wells@syrres.com writes: > I am running TCPware 3.1 on vms5.5.2 I hope that's an error ... 3.1 is ancient. Current is 5.2. Hopefully you meant 5.1? > > getting the message: > > Failed to create RPC Client /../../../tmp/statd -vulnerable > RPC: Unknown Host > > at my console.  Have rebooted, checked logs etc... Have no way of > tracking this down. > > Any ideas? > > Thanks. > > wells@syrres.com > I assume you mean that this message is an OPCOM message? If so, can you provide complete text (there should be a bit more). If not an OPCOM message, you must be running some application - what application? Basically, the error means that some application is attempting to issue an RPC request to the named host and the RPC code can't translate the name to an IP address. Obviously, that is not a valid host name and that is why the operation fails. This might be from the Network Lock Manager/Status Monitor ... do a NETCU SHOW SM and NETCU SHOW SM_BAK. If either of these report a client of the name "/../../../tmp/statd -vulnerable", use the NETCU REMOVE SM (or REMOVE SM_BAK) to remove the offending entry (you'll have to quote the string). - Bernie Volz Process Software ================================================================================ Archive-Date: Thu, 7 Aug 1997 12:46:12 -0400 Subject: Tcpware rpc error? Message-ID: <33eb4e9a.0@rtmfw.syrres.com> From: "Rick Wells" Date: Thu, 7 Aug 1997 12:46:12 -0400 I am running TCPware 3.1 on vms5.5.2 getting the message: Failed to create RPC Client /../../../tmp/statd -vulnerable RPC: Unknown Host at my console. Have rebooted, checked logs etc... Have no way of tracking this down. Any ideas? Thanks. wells@syrres.com ================================================================================ Archive-Date: XXX, 9 Aug 1997 15:06:42 -0400 Subject: Re: Tcpware rpc error Message-ID: <1997Aug9.150642@process.com> From: volz@process.com (Bernie Volz) Date: 9 Aug 97 15:06:42 -0400 References: <33eb4e9a.0@rtmfw.syrres.com> In article <33eb4e9a.0@rtmfw.syrres.com>, "Rick Wells" writes: > I am running TCPware 3.1 on vms5.5.2 That's ancient ... I'd recommend upgrading ... contact support@process.com. > > getting the message: > > Failed to create RPC Client /../../../tmp/statd -vulnerable > RPC: Unknown Host > > at my console. Have rebooted, checked logs etc... Have no way of > tracking this down. > > Any ideas? > > Thanks. > > wells@syrres.com What applications are you running ... can you do: SHOW SYSTEM You still didn't answer the question as to whether this is an OPCOM message or not. Does a "%%%%%%%%%%% OPCOM 18-MAY-1997 22:05:51.45 %%%%%%%%%%%" type header appear before this or not? If it does *NOT*, then you must be running some application (RUN app) to get this and then you need to fix your application (since it is doing an RPC Client call asking for a RPC program to be run on a client called "/../../..tmp/statd - vulnerable" (which is not a valid client name). If it is an *OPCOM* message, then it is a TCPware component generating the message and there should (hopefully) be a message before the the "Failed to create RPC Client /../../../tmp/statd -vulnerable" identifying the application. Also, check the TCPWARE:NLMSERVER.LOG or TCPWARE:STATSERVER.LOG files. This assumes you are running NFS. - Bernie Volz Process Software ================================================================================ Archive-Date: Mon, 11 Aug 1997 13:51:32 -0600 Subject: Re: TCPWARE error message? Message-ID: <871325055.506@dejanews.com> From: wells@syrres.com Date: Mon, 11 Aug 1997 13:51:32 -0600 References: <870972848.12043@dejanews.com> <1997Aug7.190612@process.com> Thanks Bernie. Yes, the version is 3.1.... We hope to upgrade to the latest very soon as we are running it other vaxen/alphas throughout and it is great! Kudos on deciphering my message as well. Regards, Rick Wells wells@syrres.com In article <1997Aug7.190612@process.com>, volz@process.com (Bernie Volz) wrote: > > In article <870972848.12043@dejanews.com>, wells@syrres.com writes: > > I am running TCPware 3.1 on vms5.5.2 > > I hope that's an error ... 3.1 is ancient. Current is 5.2. Hopefully you > meant 5.1? > > > > > getting the message: > > > > Failed to create RPC Client /../../../tmp/statd -vulnerable > > RPC: Unknown Host > > > > at my console.  Have rebooted, checked logs etc... Have no way of > > tracking this down. > > > > Any ideas? > > > > Thanks. > > > > wells@syrres.com > > > > I assume you mean that this message is an OPCOM message? If so, can you > provide complete text (there should be a bit more). If not an OPCOM > message, you must be running some application - what application? > > Basically, the error means that some application is attempting to issue > an RPC request to the named host and the RPC code can't translate the > name to an IP address. Obviously, that is not a valid host name and that > is why the operation fails. > > This might be from the Network Lock Manager/Status Monitor ... do a > NETCU SHOW SM and NETCU SHOW SM_BAK. If either of these report a client > of the name "/../../../tmp/statd -vulnerable", use the NETCU REMOVE SM > (or REMOVE SM_BAK) to remove the offending entry (you'll have to quote > the string). > > - Bernie Volz > Process Software -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet ================================================================================ Archive-Date: XXX, 13 Aug 1997 02:55:07 GMT Subject: source code Message-ID: <01bca795$0fe40a20$b023bcca@pc10.tm.net.my> From: "Razak" Date: 13 Aug 1997 02:55:07 GMT pls send me source code for tcp/ip programming using any language or send email ajakmar@hotmail.com ================================================================================ Archive-Date: Wed, 13 Aug 1997 13:56:23 GMT Subject: Running Rsh from WinNT 3.51 to VAX Message-ID: <33f1bcdd.131435@news.asiaonline.net> From: lungwong@asiaonline.net (Kevin Wong) Date: Wed, 13 Aug 1997 13:56:23 GMT Reply-To: lungwong@asiaonline.net When I run Rsh it fail with error msg "Host: login information not recognized at remote node". I've set up .rhosts on my home dir on the host and can run Rexec successfully, what else do I need to be able to run Rsh ? Config :- Host : VAX/VMS 5.5 Client: WinNT 3.51 Thanks Kevin Wong lungwong@asiaonline.net ================================================================================ Archive-Date: XXX, 14 Aug 1997 08:55:55 GMT Subject: DEC Forms Trainer Required Message-ID: <01bca890$4b097800$81fb82c1@tom-office> From: "Tom Millington" Date: 14 Aug 1997 08:55:55 GMT We have a client in NW England who requires training in DEC Forms. Trainer must have their own training facilities and equipment. Please respond asap to 2M by email. -- Regards Tom Millington 2M Limited Tel +44 (0) 1647 231686 Email tom@2m.co.uk Web Site http://www.2m.co.uk/2mhome ================================================================================ Archive-Date: Thu, 14 Aug 1997 15:47:20 GMT Subject: Re: Running Rsh from WinNT 3.51 to VAX Message-ID: <33f31cdd.259120365@news> From: corbett@process.com (Michael Corbett) Date: Thu, 14 Aug 1997 15:47:20 GMT References: <33f1bcdd.131435@news.asiaonline.net> On Wed, 13 Aug 1997 13:56:23 GMT, lungwong@asiaonline.net (Kevin Wong) wrote: >When I run Rsh it fail with error msg "Host: login information not >recognized at remote node". I've set up .rhosts on my home dir on the >host and can run Rexec successfully, what else do I need to be able to >run Rsh ? > Kevin, There are a few things to check. First is that the name for the remote host matches what you have in the .rhosts file. Do a - $ NETCU SHOW HOST ipaddressofrshclient and make sure it matches what is in .RHOSTS file. Does the username on the client side match the username on the TCPware side? If not then the .rhosts file would have to have both a hostname and the username on the client side to give access. Also remember that the username is case sensitive. You can use NETCU DEBUG to capture what the client is sending to see how it is sending the username. The debug command you would use is (use CTRL-C to stop the DEBUG) - $ NETCU DEBUG/TCP/DIA=clientipaddress/DATA=512/SPN=514 With the above command running then try the RSH from the client. One of the packets that the DEBUG command will display will look something like this - 14:31.89 RCVD 71 bytes INET21: 192.42.95.175,518 -> 198.115.142.3,514 ESTBLSHD SEQ=1808576767 D=31 ACK=44958710 W=8760 CTL=PSH!ACK DATA=63 6F 72 62 65 74 74 00 76 6D 73 63 6F 72 62 65 *Corbett.vmscorbe* 74 74 00 73 68 6F 77 20 73 79 73 74 65 6D 00 *tt.show system.* The first name is the remote username (Corbett) the second is the user they are trying to access (vmscorbett) and the last part is the command to be executed (show system). Again if the accounts are different the .rhosts file for the username being accessed (vmscorbett) must have a line that has the remote host and the remote username (case sensitive.) In the above example it might look like this - hostname Corbett Hopefully this gives you enough to figure it out. If not let me know. One other thing that you might be running into is that the .rhosts file must be owned by the user they are for. Regards Michael +-----------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Corporation Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Thu, 14 Aug 1997 18:13:10 GMT Subject: Telnet seems to need LOG_IO privilege Message-ID: <5svhp2$94k$1@decius.ultra.net> From: jasantos@ultranet.com (John Santos) Date: Thu, 14 Aug 1997 18:13:10 GMT We recently upgraded to TCPWare V5.2 on VAX VMS V7.1, and it seems telnet now requires LOG_IO privilege. I can't find this documented in the TCPWare Docs or release notes. Neither UCX V4.1, ECO 6 on an Alpha V7.1, nor CMU V6.6 on another VAX require LOG_IO to make outbound telnet connections. C-Kermit can also make outboud telnet connections without LOG_IO privilege on all three systems. Thinking that maybe the telnet client image was supposed to be installed with LOG_IO priv, but it somehow got de-installed, I tried installing it with LOG_IO, but that didn't help. The system hasn't been rebooted since I noticed this problem. Could that help? I have shut down and restarted UCX several times (mostly just DNS, to make DNS changes, but I think at least once a complete shutdown and restart.) Could this cause problems? By the way, $@TCPWARE:SHUTNET DNS followed by $@TCPWARE:STARTNET DNS causes $ SHOW NETWORK to claim that TCPWARE isn't enabled. It looks like SHUTNET.COM is executing the $ SET NETWORK command that clears the network status displayed by SHOW NETWORK, unconditionally, but STARTNET.COM only executes the $SET NETWORK command if you are doing a full startup. Thanks John Santos Evans Griffiths & Hart ================================================================================ Archive-Date: Fri, 15 Aug 1997 11:37:25 +0000 Subject: NFSD high CPU useage Message-ID: <33F43F75.6F3C@ukdcs.ftech.co.uk> From: Dave Herdman Date: Fri, 15 Aug 1997 11:37:25 +0000 Reply-To: dherdman@ukdcs.ftech.co.uk Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi I have just taken on the management of a VAX machine that is running VMS 5.5-2H4 and TCPware 4.1 (I know its *very* old ). Over the last few days the machine has been killed by NFSD consuming 60-100% of the CPU a lot of the time. I have tried .. The NFS statistics seem normal only a few timeouts and badxids 1) Stop & Restart NFS 2) Stop & Restart the whole of TCPware 3) Reboot the machine All to no effect The NFS log mechanism does not seem to write anything to the default TCPWARE:NFSSERVER.LOG ( I cant see why this is !!) I changed the log file destination in NFS_STARTUP to be sys$manager:tcpnfs.log and this *does* produce a log file. However it only has normal startup messages in (BTW the NFS logging logical is set to -1) I guessed that it might be a client (especially a PC client) throwing NFSD a weird request. I identified frequent requestors using DEBUG/UDP to port 2049 I shut these PCs down All to no avail. Anyone got any suggestions. I know I can upgrade but the system was OK a week ago and it is a fairly critical system (why is it that folks never seem to do any software maintenance on critical systems :-) ) so I don't really want to upgrade and risk other problems with software that uses TCP/IP regards Dave Herdman ================================================================================ Archive-Date: Fri, 15 Aug 1997 12:09:09 GMT Subject: Re: Running Rsh from WinNT 3.51 to VAX Message-ID: <33f4427d.343610@news.asiaonline.net> From: lungwong@asiaonline.net (Kevin Wong) Date: Fri, 15 Aug 1997 12:09:09 GMT Reply-To: lungwong@asiaonline.net References: <33f1bcdd.131435@news.asiaonline.net> <33f31cdd.259120365@news> On Thu, 14 Aug 1997 15:47:20 GMT, corbett@process.com (Michael Corbett) wrote: >On Wed, 13 Aug 1997 13:56:23 GMT, lungwong@asiaonline.net (Kevin Wong) wrote: > >>When I run Rsh it fail with error msg "Host: login information not >>recognized at remote node". I've set up .rhosts on my home dir on the >>host and can run Rexec successfully, what else do I need to be able to >>run Rsh ? >> > >Kevin, > > There are a few things to check. First is that the name for >the remote host matches what you have in the .rhosts file. Do a - > >$ NETCU SHOW HOST ipaddressofrshclient > >and make sure it matches what is in .RHOSTS file. > > Does the username on the client side match the username on the >TCPware side? If not then the .rhosts file would have to have both a >hostname and the username on the client side to give access. Also remember >that the username is case sensitive. You can use NETCU DEBUG to capture >what the client is sending to see how it is sending the username. The >debug command you would use is (use CTRL-C to stop the DEBUG) - > >$ NETCU DEBUG/TCP/DIA=clientipaddress/DATA=512/SPN=514 > > With the above command running then try the RSH from the client. >One of the packets that the DEBUG command will display will look something >like this - > > >14:31.89 RCVD 71 bytes INET21: 192.42.95.175,518 -> 198.115.142.3,514 > ESTBLSHD SEQ=1808576767 D=31 ACK=44958710 W=8760 CTL=PSH!ACK > DATA=63 6F 72 62 65 74 74 00 76 6D 73 63 6F 72 62 65 *Corbett.vmscorbe* > 74 74 00 73 68 6F 77 20 73 79 73 74 65 6D 00 *tt.show system.* > > The first name is the remote username (Corbett) the second is the >user they are trying to access (vmscorbett) and the last part is the command >to be executed (show system). Again if the accounts are different the .rhosts >file for the username being accessed (vmscorbett) must have a line that has >the remote host and the remote username (case sensitive.) In the above example >it might look like this - > >hostname Corbett > > Hopefully this gives you enough to figure it out. If not >let me know. > > One other thing that you might be running into is that the >.rhosts file must be owned by the user they are for. > >Regards >Michael > >+-----------------------------------------------------------------+ >Michael Corbett Email: Corbett@process.com >Process Software Corporation Phone: 800 722-7770 x369 >959 Concord St. 508 879-6994 x369 >Framingham MA 01701-4682 FAX: 508 879-0042 Hi Michael I suspect the problem was caused by WinNT3.51's Rsh because when I try another Rsh from a download shareware it works without any change at host and PC! PC-NFS's Rsh fails with similar msg too, I've not idea what's the difference them and the shareware. Thanks a lot, it helps me understand more about TCPware. Kevin ------------------------------------------- Kevin Wong Email: lungwong@asiaonline.net BZW Asiz Ltd Hong Kong ================================================================================ Archive-Date: Fri, 15 Aug 1997 17:07:25 GMT Subject: Re: Telnet seems to need LOG_IO privilege Message-ID: <33f48847.352154801@news> From: corbett@process.com (Michael Corbett) Date: Fri, 15 Aug 1997 17:07:25 GMT References: <5svhp2$94k$1@decius.ultra.net> On Thu, 14 Aug 1997 18:13:10 GMT, jasantos@ultranet.com (John Santos) wrote: >We recently upgraded to TCPWare V5.2 on VAX VMS V7.1, and >it seems telnet now requires LOG_IO privilege. I can't find this >documented in the TCPWare Docs or release notes. > >Neither UCX V4.1, ECO 6 on an Alpha V7.1, nor CMU V6.6 on >another VAX require LOG_IO to make outbound telnet connections. > This is a known bug in TCPware 5.2-3. The following patch fixes problem - ftp://ftp.process.com/support/52_3/TELNET_V523P021.a it is also available as TELNET_V523p021.ZIP >By the way, $@TCPWARE:SHUTNET DNS followed by >$@TCPWARE:STARTNET DNS causes $ SHOW NETWORK >to claim that TCPWARE isn't enabled. It looks like SHUTNET.COM >is executing the $ SET NETWORK command that clears the network >status displayed by SHOW NETWORK, unconditionally, but >STARTNET.COM only executes the $SET NETWORK command >if you are doing a full startup. Thanks for pointing this out. regards Mike +-----------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Corporation Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Fri, 15 Aug 1997 13:49:24 -0400 Subject: TCPware V5.3 Beta Message-ID: <33F496A4.5934@process.com> From: James Gildea Date: Fri, 15 Aug 1997 13:49:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all: Process Software is seeking candidates to participate the Besta Test for the next release of TCPware, version 5.3. If you are interested in participating or need further information regarding test expectations or content contact me via email at: gildea@process.com Thanks Jim Gildea Product Marketing Manager ================================================================================ Archive-Date: Sun, 17 Aug 1997 23:30:41 +0200 Subject: Multiple listen on same port with TCPware using UCX sockets? Message-ID: <33F789A1.379AA757@dm.krinfo.ch> From: Martin Winter Date: Sun, 17 Aug 1997 23:30:41 +0200 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit CC: winter I'm trying to have multiple servers running, all listening on the same TCP port. This works fine with the TCPware socket library or using the QIO interface. Unfortunaly we need to convert it to the UCX socket library (as Bernie Volz always told me to do :-)) ) because of some libraries we need. ********* Example Server Programm: ********** #include #include #include #include #include #include #include #include int main(int argc, char *argv[]) { int sock, remote, optval; unsigned int len; struct sockaddr_in l_addr, r_addr; sock = socket(AF_INET, SOCK_STREAM, 0); if (sock < 0) { exit(0); } optval = 1; if (setsockopt(sock, SOL_SOCKET, SO_REUSEPORT, &optval, sizeof(optval)) < 0) { printf("setsockopt failed, code=%d\n", errno); exit(0); } optval = 1; if (setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof(optval)) < 0) { printf("setsockopt failed, code=%d\n", errno); exit(0); } (void) memset ((void *) &l_addr, 0, sizeof l_addr); l_addr.sin_family = AF_INET; l_addr.sin_port = htons(1111); if (bind(sock, (struct sockaddr *)&l_addr, sizeof(l_addr)) < 0) { printf("bind failed, code=%d\n", errno); exit(0); } if (listen(sock, 5) < 0) { printf("listen failed, code=%d\n", errno); printf("listen failed, code=%d\n", errno); exit(0); } len = sizeof(r_addr); remote = accept(sock, (struct sockaddr*)&r_addr, &len); if (remote < 0) { printf("accept failed, code=%d\n", errno); exit(0); } return 0; } ************* end of example programm *********** (compiled with DECC 5.5-002 on OpenVMS Alpha 7.1, using TCPware 5.2-3 or 5.1-5) $ cc /stand=vaxc/nomember/assum=noalign example $ link example --> it runs fine if it is only started once, but running it a second time CONCURRENTLY gives: bind failed, code=48 code 48 is EADDRINUSE (Address already in use) I expected to work using the socket options SO_REUSEPORT and/or SO_REUSEADDR. How do I need to change the program to get it running with the standard UCX socket library ??? Anybody succeeded with this ? - Martin -- ---------------------------------------------------------------------------- Martin Winter Internet: winter@ncc1701.krinfo.ch Knight-Ridder Information postmaster@krinfo.ch & hostmaster@krinfo.ch Berne, Switzerland NIC: MW4, Netmgr of AS5622 ---------------------------------------------------------------------------- ================================================================================ Archive-Date: XXX, 18 Aug 1997 14:24:32 -0400 Subject: Re: Multiple listen on same port with TCPware using UCX sockets? Message-ID: <1997Aug18.142432@process.com> From: volz@process.com (Bernie Volz) Date: 18 Aug 97 14:24:32 -0400 References: <33F789A1.379AA757@dm.krinfo.ch> Martin: The comment to change to the UCX socket library is a general comment. There may be times when you won't be able to do something that you used to be able to with the native TCPware interface if you do this. Note that the native TCPware method of listening is significantly different from the UCX socket library method (TCPware V5.2 introduced the native TCP interface's IO$_CREATE function to support the socket style listens). We currently support what BSD allows one to do when binding to sockets (to the best of my knowledge). That behavoir is: If local port numbers are same and: BIND Existing BIND Socket Then Socket Socket SO_REUSEADDR Allow? ------ ------ ------------ ----- INADDR_ANY INADDR_ANY NO same-IA same-IA NO specified specified YES INADDR_ANY specified Disabled NO INADDR_ANY specified Enabled YES specified INADDR_ANY Disabled NO specified INADDR_ANY Enabled YES Note: same-IA means that both sockets specified the same internet address; specified means that both sockets specified an internet address, but not the same internet address. One more point - true UCX does actually allow more than one application to listen on a port. However, if you do that, only one ever gets any connections. The other will only get connections if the first one exits. And, finally, with UCX socket library listen, lots of connections are queued up on the listening socket. Hence, it doesn't really make much sense to have many sockets doing listens (the one server per connection model doesn't really work unless you hand off the connection to another process; hence use the master server!). Hope that helps. - Bernie Volz Process Software In article <33F789A1.379AA757@dm.krinfo.ch>, Martin Winter writes: > I'm trying to have multiple servers running, all listening on the same > TCP port. > This works fine with the TCPware socket library or using the QIO > interface. > Unfortunaly we need to convert it to the UCX socket library (as Bernie > Volz always told me to do :-)) ) because of some libraries we need. > > ********* Example Server Programm: ********** > #include > #include > #include > #include > #include > #include > #include > #include > > int main(int argc, char *argv[]) > { > int sock, remote, optval; > unsigned int len; > struct sockaddr_in l_addr, r_addr; > > sock = socket(AF_INET, SOCK_STREAM, 0); > if (sock < 0) { > exit(0); > } > > optval = 1; > if (setsockopt(sock, SOL_SOCKET, SO_REUSEPORT, &optval, > sizeof(optval)) < 0) { > printf("setsockopt failed, code=%d\n", errno); > exit(0); > } > > optval = 1; > if (setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &optval, > sizeof(optval)) < 0) { > printf("setsockopt failed, code=%d\n", errno); > exit(0); > } > > (void) memset ((void *) &l_addr, 0, sizeof l_addr); > l_addr.sin_family = AF_INET; > l_addr.sin_port = htons(1111); > if (bind(sock, (struct sockaddr *)&l_addr, sizeof(l_addr)) < 0) { > printf("bind failed, code=%d\n", errno); > exit(0); > } > > if (listen(sock, 5) < 0) { > printf("listen failed, code=%d\n", errno); > printf("listen failed, code=%d\n", errno); > exit(0); > } > > len = sizeof(r_addr); > remote = accept(sock, (struct sockaddr*)&r_addr, &len); > if (remote < 0) { > printf("accept failed, code=%d\n", errno); > exit(0); > } > return 0; > } > ************* end of example programm *********** > (compiled with DECC 5.5-002 on OpenVMS Alpha 7.1, using TCPware 5.2-3 or > 5.1-5) > > $ cc /stand=vaxc/nomember/assum=noalign example > $ link example > > --> it runs fine if it is only started once, but running it a second > time CONCURRENTLY gives: > bind failed, code=48 > code 48 is EADDRINUSE (Address already in use) > > I expected to work using the socket options SO_REUSEPORT and/or > SO_REUSEADDR. > > How do I need to change the program to get it running with the standard > UCX > socket library ??? > > Anybody succeeded with this ? > > - Martin > > -- > ---------------------------------------------------------------------------- > Martin Winter Internet: > winter@ncc1701.krinfo.ch > Knight-Ridder Information postmaster@krinfo.ch & > hostmaster@krinfo.ch > Berne, Switzerland NIC: MW4, Netmgr of > AS5622 > ---------------------------------------------------------------------------- ================================================================================ Archive-Date: XXX, 18 Aug 1997 14:31:38 -0400 Subject: Re: NFSD high CPU useage Message-ID: <1997Aug18.143138@process.com> From: volz@process.com (Bernie Volz) Date: 18 Aug 97 14:31:38 -0400 References: <33F43F75.6F3C@ukdcs.ftech.co.uk> In article <33F43F75.6F3C@ukdcs.ftech.co.uk>, Dave Herdman writes: > Hi > > I have just taken on the management of a VAX machine that is running VMS > 5.5-2H4 and TCPware 4.1 (I know its *very* old ). Over the last few days > the machine has been killed by NFSD consuming 60-100% of the CPU a lot > of the time. I have tried .. > > The NFS statistics seem normal only a few timeouts and badxids > > 1) Stop & Restart NFS > > 2) Stop & Restart the whole of TCPware > > 3) Reboot the machine > > All to no effect > > The NFS log mechanism does not seem to write anything to the default > TCPWARE:NFSSERVER.LOG ( I cant see why this is !!) I changed the log > file destination in NFS_STARTUP to be sys$manager:tcpnfs.log and this > *does* produce a log file. However it only has normal startup messages > in (BTW the NFS logging logical is set to -1) > > I guessed that it might be a client (especially a PC client) throwing > NFSD a weird request. I identified frequent requestors using DEBUG/UDP > to port 2049 > > I shut these PCs down > > All to no avail. > > Anyone got any suggestions. > > I know I can upgrade but the system was OK a week ago and it is a fairly > critical system (why is it that folks never seem to do any software > maintenance on critical systems :-) ) so I don't really want to upgrade > and risk other problems with software that uses TCP/IP > > > regards > > Dave Herdman I'd suggest logging a call to Process Software's Technical Support (508-879-6994) if you're under support. Normally, the NFS server doesn't log much to the log file (just significant errors). There are ways you can get it to write a LOT more (support can tell you how and take a look at the result). Is NFSD just CPU bound? Or it is I/O bound as well? Either reduce the NFSD's process priority or increase your own process priority and do some MONITOR or SHOW PROCESS/CONTINUOUS on it to see what NFSD is doing. > I guessed that it might be a client (especially a PC client) throwing > NFSD a weird request. I identified frequent requestors using DEBUG/UDP > to port 2049 Looking at the traffic under these loaded conditions is also useful. Again, this is best done by increasing the priority of your process while NFSD is having problems. - Bernie Volz Process Software ================================================================================ Archive-Date: Fri, 22 Aug 1997 17:11:16 -0500 Subject: TCP/IP for Dec 3000-400s Message-ID: <33FE0E84.167E@nol.net> From: Kevan Granat Date: Fri, 22 Aug 1997 17:11:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm trying to locate a TCP/IP package for an old system... I've got a DEC 3000 model 400s running Alpha VMS version 1.0 (yes! that is 1.0). It's got to be that version, unfortunately, since we're trying to duplicate another system (I had to get the O/S via the archive group at DEC). I need to connect this to an existing network (ethernet TCP/IP with sgi's, NT-boxes) but I'm not having much luck. Any info on known options would be greatly appreciated. Here's what I've dug up so far... Wollongong (now Attachmate): Pathworks currently supports vms6.1 to 7.1 and keeps no archives of prior versions. Multinet & TCPWare (Process Software, formerly w/CISCO, formerly TGV): due to the recent acquisition, getting multinet 4.0 is easy, but prior versions may not be available (contract issues). I did find out that Multinet 3.5 rev b or earlier will work on this system, though. CMU-TEK: VAX only. Samba: having trouble with samba web pages, may be an options, but I can't tell at this point. DEC: still trying to find proper archive version, pricetag scares the hell out of me, too (on par with the cost of the machine + OS + Fortran). Regarding licensing, is there an option of buying someone's old version and actually having a legitimate license? I'm not too familiar with DECs licensing system, so I'm not sure if licenses are machine-specific, or what. Thanks for any info you can provide! (also note: this system has JUST the OS on it, no NAS (and it predates UCX)) ================================================================================ Archive-Date: XXX, 23 Aug 1997 10:18:01 -0400 Subject: Re: TCP/IP for Dec 3000-400s Message-ID: <1997Aug23.101801@process.com> From: volz@process.com (Bernie Volz) Date: 23 Aug 97 10:18:01 -0400 References: <33FE0E84.167E@nol.net> In article <33FE0E84.167E@nol.net>, Kevan Granat writes: > I'm trying to locate a TCP/IP package for an old system... > > I've got a DEC 3000 model 400s running Alpha VMS version 1.0 (yes! that > is 1.0). It's got to be that version, unfortunately, since we're trying > to duplicate another system (I had to get the O/S via the archive group > at DEC). I need to connect this to an existing network (ethernet TCP/IP > with sgi's, NT-boxes) but I'm not having much luck. > > Any info on known options would be greatly appreciated. Here's what > I've dug up so far... > Yuck! OpenVMS Alpha V1.0 was pretty bad. Even 1.5 is pretty bad. It really wasn't stable until 6.1. > Multinet & TCPWare (Process Software, formerly w/CISCO, formerly TGV): > due to the recent acquisition, getting multinet 4.0 is easy, but > prior versions may not be available (contract issues). I did find out > that Multinet 3.5 rev b or earlier will work on this system, though. I don't recall what version of TCPware last supported V1.0, but we only did so for a very short time (since OpenVMS Alpha V1.0 had so many problems, especially in the RTLs). It is probably TCPware V4.1. You may be able to get a copy of that if you specifically request it (contact sales@process.com, 800-722-7770). I'd really suggest moving to a newer version of OpenVMS (V6.1 or later). - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: XXX, 23 Aug 1997 11:41:06 PDT Subject: Re: TCP/IP for Dec 3000-400s Message-ID: <2McAKWpa2vfX@vmsmail.gov.bc.ca> From: Ed.Wilts@gems1.gov.bc.ca (Ed Wilts) Date: 23 Aug 97 11:41:06 PDT References: <33FE0E84.167E@nol.net> In article <33FE0E84.167E@nol.net>, Kevan Granat writes: > I'm trying to locate a TCP/IP package for an old system... > > I've got a DEC 3000 model 400s running Alpha VMS version 1.0 (yes! that > is 1.0). It's got to be that version, unfortunately, since we're trying > to duplicate another system (I had to get the O/S via the archive group > at DEC). I need to connect this to an existing network (ethernet TCP/IP > with sgi's, NT-boxes) but I'm not having much luck. > > Any info on known options would be greatly appreciated. Here's what > I've dug up so far... > > DEC: > still trying to find proper archive version, pricetag scares the hell > out of me, too (on par with the cost of the machine + OS + Fortran). The DEC 3000 model 400s very likely came with a NAS licence. Ours came with one (NAS 300 - look for a a NET-APP-SUP-300 PAK) back in early '93. All the NAS packages allow you to run UCX. Once you find the license, you just need to worry about the media and docs. You can probably make do with online docs - it's far cheaper than paper - so you need to locate one of the early Alpha CD distributions. Those can be distributed to anyone; Digital doesn't care where you get the media from. I doubt if I've got media going back that far, since my system came with V1.5 I think. Somebody has to have the old CD though... > Thanks for any info you can provide! > > (also note: this system has JUST the OS on it, no NAS (and it predates > UCX)) The 3000-400S was very short-lived. I've gone through my Systems and Options catalogues, and this system ONLY appeared in the April 1993 issue. The Advantage-Servers included NAS300; the Base Servers did not. If your 3000-400S is part number PE411-YE/YF, you're in luck. Otherwise, fork over the $$$. -- Ed Wilts Information Technology Services Division, Province of BC 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8 mailto:Ed.Wilts@GEMS1.Gov.BC.CA Phone: (250) 387-5302 Fax: (250) 387-5231 Disclaimer: The opinions and statements contained in this posting are the sole responsibility of the author and have not in any way been reviewed or approved by my employer or any network service. ================================================================================ Archive-Date: Mon, 25 Aug 1997 19:30:55 GMT Subject: Re: TCP/IP for Dec 3000-400s Message-ID: <3407d91d.324106440@news.his.com> From: reece@eco.twg.com (Reece R. Pollack) Date: Mon, 25 Aug 1997 19:30:55 GMT References: <33FE0E84.167E@nol.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Fri, 22 Aug 1997 17:11:16 -0500, Kevan Granat wrote: >I'm trying to locate a TCP/IP package for an old system... > >I've got a DEC 3000 model 400s running Alpha VMS version 1.0 (yes! that >is 1.0). It's got to be that version, unfortunately, since we're trying >to duplicate another system (I had to get the O/S via the archive group >at DEC). I need to connect this to an existing network (ethernet TCP/IP >with sgi's, NT-boxes) but I'm not having much luck. Attempting to support a product on an operating system as old (and as buggy) as OpenVMS Alpha V1.0 would be a nightmare. The compilers have changed (the current version of the C compiler is V5.6, and the latest version to support VMS 1.0 was V1.2), the PALcode has changed, the linker has changed, and the libraries have changed. >Any info on known options would be greatly appreciated. Here's what >I've dug up so far... > > >Wollongong (now Attachmate): > Pathworks currently supports vms6.1 to 7.1 and keeps no archives of >prior versions. The current release of PathWay (not Pathworks, that's Digital's PC connectivity product) supports OpenVMS Alpha V6.1 through V7.1, and Vax/VMS V5.3 through V7.1. That's a pretty broad spectrum of releases. To say we keep no archives is inaccurate. It would be more appropriate to say we won't sell a product we can't support in a practical manner. To sell such a product would be ethically questionable. >Regarding licensing, is there an option of buying someone's old version >and actually having a legitimate license? I'm not too familiar with >DECs licensing system, so I'm not sure if licenses are machine-specific, >or what. From a legal standpoint, licenses may or may not be transferable. It certainly would not be legal to acquire any version of a product unless the old owner transfers all copies of the product to you and does not retain any copies. Even then, it depends on the licensing agreement between the copyright owner and the licensee. -- Reece R. Pollack Senior Software Engineer Attachmate Open Systems Group ================================================================================ Archive-Date: Tue, 26 Aug 1997 14:06:03 GMT Subject: Re: TCP/IP for Dec 3000-400s Message-ID: From: thou-shalt-not-spam.moroney@world.std.com (Michael Moroney) Date: Tue, 26 Aug 1997 14:06:03 GMT Sender: thou-shalt-not-spam.moroney@world.std.com References: <33FE0E84.167E@nol.net> In article <33FE0E84.167E@nol.net>, Kevan Granat wrote: > I'm trying to locate a TCP/IP package for an old system... > > I've got a DEC 3000 model 400s running Alpha VMS version 1.0 (yes! that > is 1.0). It's got to be that version, unfortunately, since we're trying > to duplicate another system (I had to get the O/S via the archive group > at DEC). Umm, Alpha VMS 1.0 was essentially a beta release of VMS on Alphas. Perhaps you should consider upgrading whatever system you are duplicating to a less prehistoric version before attempting to duplicate it? -Mike ================================================================================ Archive-Date: XXX, 28 Aug 1997 19:49:56 GMT Subject: E-mails stay in the tcpware spool dir Message-ID: <5u4kp4$qoa$1@news.NL.net> From: hve@gastec.nl (Engeland H. van) Date: 28 Aug 1997 19:49:56 GMT Content-Type: Text/Plain; charset=US-ASCII Running TCPWARE 5.1 on a AXP OPENVMS 6.1, sometimes e-mails stay in the spool dir. Deleting all the files in the spool dir and restarting the SMTP service does the job. In the SMTPCLIENT.LOG file is an entry TCPWARE-SMTP-F-ACCVIO, acces violation. After this entry is made the SMTP service dies. Just restarting SMTP wil not do anything. Looking at the first file does not give a hint to what is wrong. It's like all the other files. Does someone know what is going wrong ? ================================================================================ Archive-Date: Fri, 29 Aug 1997 11:49:04 +0000 Subject: Re: E-mails stay in the tcpware spool dir Message-ID: <3406B730.7AA45EBC@process.com> From: Geoff Bryant Date: Fri, 29 Aug 1997 11:49:04 +0000 References: <5u4kp4$qoa$1@news.NL.net> MIME-Version: 1.0 To: "Engeland H. van" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Engeland H. van wrote: > > Running TCPWARE 5.1 on a AXP OPENVMS 6.1, sometimes e-mails stay in the spool > dir. Deleting all the files in the spool dir and restarting the SMTP service > does the job. > In the SMTPCLIENT.LOG file is an entry TCPWARE-SMTP-F-ACCVIO, acces violation. > After this entry is made the SMTP service dies. Just restarting SMTP wil not > do anything. Looking at the first file does not give a hint to what is wrong. > It's like all the other files. > > Does someone know what is going wrong ? I would suggest that you log a support call so that we can investigate this further. Also, TCPware version 5.2-3 is the current shipping version of TCPware. ---------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA