Archive-Date: Sun, 1 Feb 1998 13:00:17 -0400 Date: Sun, 1 Feb 1998 12:57 -0500 From: SCHREIBER@PROCESS.COM (Jeff Schreiber) Reply-To: Info-TCPware@process.com Message-ID: <009C12995AC92D4F.4D0B@PROCESS.COM> To: Info-TCPware@process.com Subject: RE: Interoparability of UCX FTP and TCPware FTP "Veli Körkkö" writes: > >When doing FTP GET, the FTP client on the UCX system hangs at the next >operation if >VMSplus mode is enabled between UCX FTP client and TCPware FTP server. > Yes. There is a problem with UCX's VMS Plus mode. They aren't closing the data connection, and that's why it's hanging (because the TCPware server is waiting for the data connection to be done before it closes the command connection, and UCX isn't closing the data connection). UCX to UCX isn't a problem because the UCX server doesn't care if the data connection is done.. it'll shut down if it gets a close on the command connection regardless. You can sort of see it when you send the commands directly: FTP> quote quit 221 Service closing connection. FTP> pwd 421 Service not available, Remote server has closed the connection FTP> pwd %FTP-E-CONCNC, Control connction is not set up to remote host The UCX system never realized the connection was closed until it tried something. On that first pwd after the close, the UCX system actually sent the PWD command across to the server, to which the server responded saying that the client already closed the connection. To see it even better, try: FTP> quote quit 221 Service closing connection. FTP> open %FTP-E-DISCON, Disconnect first; connection to already exists. The only way around it is to disable VMS Plus mode, or you could use the Madgoat FTP client on your UCX systems. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Mon, 2 Feb 1998 12:38:51 -0400 From: eplan@kapsch.co.at (Peter LANGSTOEGER) Subject: TCPWARE_LPD_*_OPTION problem since ALPQMAN01_071 Date: 2 Feb 98 17:20:46 GMT Message-ID: <34d6006e.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Since we installed the ALPQMAN01_071 ECO on our OpenVMS Alpha V7.1 we're getting error messages when we specify $ DEFINE/SYSTEM/EXEC TCPWARE_LPD_*_OPTION "/NOFLAG" Error message is %TCPWARE_LPD-W-OPTION, error parsing option logical -CLI-W-PARMDEL, invalid parameter delimiter - check use of special characters Since you cannot initialize a queue with eg. /DISFLAG (I mean to force the absence of a flag page) we need this option (logical) to avoid wasting paper ! Any ideas (besides contacting PSC support as I already did) ? ------------------------------------------------------------------------ Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2382 Network and OpenVMS system manager Fax. +43 1 81111-888 Technical Computer Center (ADV) E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Tue, 3 Feb 1998 03:11:07 -0400 Subject: Re: TCPWARE_LPD_*_OPTION problem since ALPQMAN01_071 Message-ID: <1998Feb2.220330@process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 2 Feb 98 22:03:30 -0500 To: Info-TCPware@PROCESS.COM In article <34d6006e.0@nevada.kapsch.co.at>, eplan@kapsch.co.at (Peter LANGSTOEGER) writes: > Since we installed the ALPQMAN01_071 ECO on our OpenVMS Alpha V7.1 we're > getting error messages when we specify > > $ DEFINE/SYSTEM/EXEC TCPWARE_LPD_*_OPTION "/NOFLAG" > > Error message is > > %TCPWARE_LPD-W-OPTION, error parsing option logical > -CLI-W-PARMDEL, invalid parameter delimiter - check use of special characters > > Since you cannot initialize a queue with eg. /DISFLAG (I mean to force the > absence of a flag page) we need this option (logical) to avoid wasting paper ! > > Any ideas (besides contacting PSC support as I already did) ? Rather odd that this would change with the installation of a Digital patch? Please check to make sure you have no other TCPWARE_LPD_*_OPTION logicals defined. Do: SHOW LOG/FULL TCPWARE_LPD_*_OPTION Perhaps there is another logical defined for one of the queues and this is causing problems? - Bernie Volz Process Software ================================================================================ Archive-Date: Wed, 4 Feb 1998 12:43:45 -0400 From: eplan@kapsch.co.at (Peter LANGSTOEGER) Subject: Re: TCPWARE_LPD_*_OPTION problem since ALPQMAN01_071 Date: 4 Feb 98 17:22:49 GMT Message-ID: <34d8a3e9.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article <1998Feb2.220330@process.com>, volz@process.com (Bernie Volz) writes: >Please check to make sure you have no other TCPWARE_LPD_*_OPTION logicals >defined. Do: > SHOW LOG/FULL TCPWARE_LPD_*_OPTION > >Perhaps there is another logical defined for one of the queues and this >is causing problems? I obviously did this, before I opened the support call (and wrote the posting) In the meantime, I checked the VAXQMAN01_071 patch, too. So far, no problems... ------------------------------------------------------------------------ Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2382 Network and OpenVMS system manager Fax. +43 1 81111-888 Technical Computer Center (ADV) E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Fri, 6 Feb 1998 17:19:06 -0400 Message-ID: <4079434C7E6AD11187560000F81F36CB1E6625@exchange.process.com> From: Terri Izzi Reply-To: Info-TCPware@process.com To: "'info-tcpware@process.com'" Subject: READ ME FIRST notice for TCPware 5.3 upgrades Date: Fri, 6 Feb 1998 17:15:14 -0500 MIME-Version: 1.0 Content-Type: text/plain > Please READ BEFORE Upgrading to TCPware 5.3 > > The installation process for TCPware Version 5.3 was enhanced to > better support > non-system disk installations. Unfortunately, that enhancement caused > the > TCPWARE_ROOT logical for system-disk installations to be defined > differently > starting with this version. This change in logical definition coupled > with a > fairly common problem with the C Run Time Library chdir function and > search-listed logicals across many versions of OpenVMS can cause a few > problems > with TCPware V5.3. > > For systems where TCPware is installed on the system disk, the easiest > > corrective action is to redefine the TCPWARE_ROOT logical definition > as it > appears in the TCPWARE_COMMON:[TCPWARE]TCPWARE_LOGICALS.COM file. > > Change: > > DEFINE/SYSTEM/NOLOG/EXEC TCPWARE_ROOT > TCPWARE_SPECIFIC:,TCPWARE_COMMON: > > to: > > DEFINE/SYSTEM/NOLOG/EXEC TCPWARE_ROOT SYS$SYSROOT: > > Then rerun TCPWARE_LOGICALS.COM. > > Note: This is possible only for installations where TCPWARE_SPECIFIC > is > SYS$SPECIFIC and TCPWARE_COMMON is SYS$COMMON. > > For other systems, the problem is that chdir will only set the default > working > directory to the first directory in the search list, > TCPWARE_SPECIFIC:[TCPWARE...]. This means that any files that were > placed in > TCPWARE_COMMON and were supposed to be found because of the search > list will not > be found. The easiest solution is to move the files into the > TCPWARE_SPECIFIC > directory, if possible. > > An example is when NAMED needs to operate with the zone files in the > TCPWARE_COMMON area. An alternative would be to change the NAMED.BOOT > file to > specify TCPWARE_COMMON:[TCPWARE.NAMED] in the directory clause. > > We apologize for this inconvenience and will work to correct it as > soon as > possible. > > Terri Izzi > Technical Support Manager, OpenVMS Products > Process Software Corp. > > Technical Support: 508-628-5074 > U.S./Canada: 800-394-8700 > FAX: 508-879-0042 > email: support@process.com > ================================================================================ Archive-Date: Thu, 12 Feb 1998 10:43:49 -0400 From: "Technical Support Group" Reply-To: Info-TCPware@process.com Subject: Tcpware Pints fail Date: Thu, 12 Feb 1998 11:17:00 -0000 Message-ID: <6bulpq$rho$1@ns2.aladdin.net> To: Info-TCPware@PROCESS.COM We have recently upgraded tcpware to version 5.1-4, but found that when trying to print to an TCPIP queue the following problem occurs: When more than 1 job is queued , the first job prints ok. but jobs 2 and 3 both fail to print, have the same completion time as job 1 and are retained on the queue with error status. The queue are referenced using the DNS names and are ok on other versions of Tcpware. We have tried logging a help call with our suppliers (Integralis) but they fail even to return phone calls. Has anybody got any ideas? ================================================================================ Archive-Date: Thu, 12 Feb 1998 11:09:47 -0400 Date: Thu, 12 Feb 1998 11:06 -0500 From: GLEASON@PROCESS.COM (Kristy, Technical Support Specialist) Reply-To: Info-TCPware@process.com Message-ID: <009C1B2EACC775BC.1A3C@PROCESS.COM> To: Info-TCPware@process.com Subject: RE: Tcpware Pints fail *From: "Technical Support Group" *We have recently upgraded tcpware to version 5.1-4, but found that when *trying to print to an TCPIP queue the following problem occurs: *When more than 1 job is queued , the first job prints ok. but jobs 2 and 3 *both fail to print, have the same completion time as job 1 and are retained *on the queue with error status. *The queue are referenced using the DNS names and are ok on other versions of *Tcpware. *We have tried logging a help call with our suppliers (Integralis) but they *fail even to return phone calls. *Has anybody got any ideas? Hiya Andy, Ftp to ftp.process.com. Login as anonymous, using your email address as your password. cd support cd 51_5 image get tssym_v515p030.a exit It's a VMSINSTALable saveset. You'll need to stop all your printers that use the TCPWARE_TSSYM symbiont, VMSINSTAL the patch, then restart your TSSYM printers. -- Kristy +--------------------------------------------------------------------+ | Kristy S. Gleason Process Software Corporation | | Technical Support Specialist 959 Concord Road | | Email: gleason@process.com Framingham, MA 01701-4682 | | Tel: 800-394-8700 FAX: 508-879-0042 | +--------------------------------------------------------------------+ ================================================================================ Archive-Date: Thu, 12 Feb 1998 11:18:40 -0400 Date: Thu, 12 Feb 1998 11:14 -0500 From: GLEASON@PROCESS.COM (Kristy, Technical Support Specialist) Reply-To: Info-TCPware@process.com Message-ID: <009C1B2FE942C4F0.1A3C@PROCESS.COM> To: Info-TCPware@process.com Subject: FWD: TCPware prints fail *From: "Technical Support Group" *We have recently upgraded tcpware to version 5.1-4, but found that when *trying to print to an TCPIP queue the following problem occurs: *When more than 1 job is queued , the first job prints ok. but jobs 2 and 3 *both fail to print, have the same completion time as job 1 and are retained *on the queue with error status. *The queue are referenced using the DNS names and are ok on other versions of *Tcpware. *We have tried logging a help call with our suppliers (Integralis) but they *fail even to return phone calls. *Has anybody got any ideas? My apologies for my fat fingers. The CORRECT saveset is tssym_v515p020.a, not tssym_v515p030.a as I had originally sent. Sorry about that. -- Kristy Hiya Andy, Ftp to ftp.process.com. Login as anonymous, using your email address as your password. cd support cd 51_5 image get tssym_v515p020.a exit It's a VMSINSTALable saveset. You'll need to stop all your printers that use the TCPWARE_TSSYM symbiont, VMSINSTAL the patch, then restart your TSSYM printers. -- Kristy +--------------------------------------------------------------------+ | Kristy S. Gleason Process Software Corporation | | Technical Support Specialist 959 Concord Road | | Email: gleason@process.com Framingham, MA 01701-4682 | | Tel: 800-394-8700 FAX: 508-879-0042 | +--------------------------------------------------------------------+ ================================================================================ Archive-Date: Tue, 17 Feb 1998 07:10:58 -0400 Message-ID: <19980217120723.9853.rocketmail@send1c.yahoomail.com> Date: Tue, 17 Feb 1998 04:07:23 -0800 (PST) From: John Richards Reply-To: Info-TCPware@process.com Subject: Porting applications from VAX to Alpha To: Info-TCPware@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii We are attempting to port an application based on TCPWARE from TCPWARE 5.1-5 on a VAX, to TCPWARE 5.2-3 on an ALPHA In our applications we need to get the socket connection accepted by the NETCP listener and we currently do that using the tcpware_server() routine. When porting to the Alpha, we will need to use DecC instead of VaxC. When doing this should/can we use the old TCPware socket libraries or is there a way of doing the same with the new libraries (which don't have the tcpware_server() routine) If tcpware_server() routine is no longer usable when using DecC on a Alpha, there must be a mechanism for NETCP to pass an accepted socket connection to a server routine. UCX has a similar facility, but requires passing the special value UCX$C_AUXS to their socket() routine. Does TCPWARE NETCP emulate UCX well enough for this approach to work? Has anyone on the list examples they could let me have? Regards John Richards _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com ================================================================================ Archive-Date: Tue, 17 Feb 1998 09:02:46 -0400 Date: Tue, 17 Feb 1998 08:58 -0500 From: BRYANT@PROCESS.COM (Geoff Bryant) Reply-To: Info-TCPware@process.com Message-ID: <009C1F0ABB730E73.2861@PROCESS.COM> To: Info-TCPware@process.com Subject: RE: Porting applications from VAX to Alpha John Richards writes: > >We are attempting to port an application based on TCPWARE from TCPWARE >5.1-5 on a VAX, to TCPWARE 5.2-3 on an ALPHA Should be no problem. >In our applications we need to get the socket connection accepted by >the NETCP listener and we currently do that using the tcpware_server() >routine. > >When porting to the Alpha, we will need to use DecC instead of VaxC. >When doing this should/can we use the old TCPware socket libraries or >is there a way of doing the same with the new libraries (which don't >have the tcpware_server() routine) > >If tcpware_server() routine is no longer usable when using DecC on a >Alpha, there must be a mechanism for NETCP to pass an accepted socket >connection to a server routine. The tcpware_server() routine is provided in the TCPware socket library provided for the AXP, so you should be able to continue using that mechanism. This is all documented in the Programmer's Guide which you should have received with TCPware 5.2-3. Check out appendix A. >UCX has a similar facility, but requires passing the special value >UCX$C_AUXS to their socket() routine. Does TCPWARE NETCP emulate UCX >well enough for this approach to work? TCPware also supports the UCX way of doing things. Since you are moving to using DEC C on the AXP, you could move completely to using the DEC C socket routines. The technique is the same as for UCX of using the special socket() call specifying UCX$C_AUXS to aquire the connection from the "auxilliary server". In TCPware, NETCP serves as the "auxilliary server". The one trick here is that you need to tell NETCP that you have this type of server when issuing your NETCU ADD SERVICE command. You need to specify the service as a BG_TCP service instead of as a TCP service. Again, check out the Programmer's guide, particularly chapter 2. >Has anyone on the list examples they could let me have? > >Regards > >John Richards If you need any more help, feel free to ask. ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Tue, 17 Feb 1998 21:46:56 -0400 From: "Hal Kuff" Reply-To: Info-TCPware@process.com Subject: Oracle Rdb/SqlNet Support Date: Tue, 17 Feb 1998 19:41:26 -0500 Message-ID: <6cdaj7$56o@usenet43.supernews.com> To: Info-TCPware@PROCESS.COM Hi, Is anyone using Tcpware with Oracle/Rdb SQLNET? Hal Kuff Kuff@Tessco.Com ================================================================================ Archive-Date: Wed, 18 Feb 1998 12:32:33 -0400 From: "Paul Roberts" Reply-To: Info-TCPware@process.com Subject: Re: Tcpware Pints fail Date: Wed, 18 Feb 1998 10:27:53 -0000 Message-ID: <887797674.739.0.nnrp-01.c29f9d9a@news.demon.co.uk> To: Info-TCPware@PROCESS.COM Kristy, Technical Support Specialist wrote in message Yo Kristy! Starting to hang around in the newsgroups now eh? Not got enough work to do? :-) <009C1B2EACC775BC.1A3C@PROCESS.COM>... >*From: "Technical Support Group" > >*We have recently upgraded tcpware to version 5.1-4, but found that when >*trying to print to an TCPIP queue the following problem occurs: >*When more than 1 job is queued , the first job prints ok. but jobs 2 and 3 >*both fail to print, have the same completion time as job 1 and are retained >*on the queue with error status. > >*The queue are referenced using the DNS names and are ok on other versions of >*Tcpware. > >*We have tried logging a help call with our suppliers (Integralis) but they >*fail even to return phone calls. Tut! Tut! :-) > >*Has anybody got any ideas? I remember seeing this back in 5.0-4 when I used to work at Integralis. Thought they'd have fixed that by now. There's probably a patch available somewhere. > >Hiya Andy, > >Ftp to ftp.process.com. Login as anonymous, using your email address as your >password. Ah-ha! > >cd support >cd 51_5 >image >get tssym_v515p030.a >exit > >It's a VMSINSTALable saveset. You'll need to stop all your printers that use >the TCPWARE_TSSYM symbiont, VMSINSTAL the patch, then restart your TSSYM >printers. Not still having problems with TSSYM are you Kristy? It always was a pain in the butt wasn't it? :-) TTFN, Paul Paul Roberts, Internet & Intranet Solutions Ltd., e-mail: spam-filter@intranet-solutions.com Replace spam-filter with paul.roberts to reply. Antispam address for local postmaster: postmaster@localhost ================================================================================ Archive-Date: Mon, 23 Feb 1998 02:50:22 -0400 From: "Arne Johansson" Reply-To: Info-TCPware@process.com Subject: Socket program with TCPWare Date: 23 Feb 1998 07:12:05 GMT Message-ID: <01bd402a$47889760$d40a3d0a@nirvana> To: Info-TCPware@PROCESS.COM I am attempting to port a socket application to OpenVMS and TCPWare 5.0-3. The server program is started by NETCP and an ADD SERVICE command. The socket communication is working just as expected. At the end the server program makes a C system call to start a DCL script file and this is my problem. I can not see any trace of the execution of the DCL file, so I assume it is not run. In the NETCU ADD SERVICE command the UIC parameter is SYSTEM, so my priviledge should enough. I tried to add the /LOG parameter, but there where no differences in the NETCP.LOG. Is it impossible to get a DCL script file started in this way, or has anyone a hint. Regards Arne Johansson ================================================================================ Archive-Date: Mon, 23 Feb 1998 11:30:39 -0400 Date: Mon, 23 Feb 1998 11:26 -0500 From: BRYANT@PROCESS.COM (Geoff Bryant) Reply-To: Info-TCPware@process.com Message-ID: <009C23D65A734FFB.517E@PROCESS.COM> To: Info-TCPware@process.com Subject: RE: Socket program with TCPWare "Arne Johansson" writes: > >I am attempting to port a socket application to OpenVMS and TCPWare 5.0-3. >The server program is started by NETCP and an ADD SERVICE command. >The socket communication is working just as expected. At the end the server >program makes a C system call to start a DCL script file and this is my >problem. > >I can not see any trace of the execution of the DCL file, so I assume it is >not run. >In the NETCU ADD SERVICE command the UIC parameter is SYSTEM, so my >priviledge should >enough. I tried to add the /LOG parameter, but there where no differences >in the NETCP.LOG. > >Is it impossible to get a DCL script file started in this way, or has >anyone a hint. I'm not completely sure of what you are doing, but unless you start up a BG style service, the process for your service is not started with the DCL CLI by firing up LOGINOUT.EXE to run your image. You can have a DCL procedure invoked as your service if you add the service as a BG_TCP or BG_UDP service and specify your command procedure with /INPUT. > >Regards > >Arne Johansson > I hope that is the pointer you need.... ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Wed, 25 Feb 1998 09:29:15 -0400 From: "Cok Baris" Reply-To: Info-TCPware@process.com Subject: FTP Tcpware 5.3-2 +patches to Tcpware for IAS V2.1-1 Date: 25 Feb 1998 14:19:08 GMT Message-ID: <01bd41f8$9acc0a40$ce6643c1@cokbar.intra.kender-thijssen.nl> To: Info-TCPware@PROCESS.COM Hi there, Since the upgrade to tcpware 5.3-2 I get an error message during connect with ftp to TCPWARE for IAS V2.1-1 FTP>con log 220 LOG (163.175.36.2) TCPware(TM) for IAS V2.1-1 (c) Process Sofwtare Corporation Username [blabla]:[1,1] 331 Password required _Password: 230 User logged in, proceed 500 Syntax error or unrecognized command <--------------------------------- I can send and receive files, but most of the command procedures fail because of this message. Has anyone a suggestion? ================================================================================ Archive-Date: Wed, 25 Feb 1998 09:43:59 -0400 Date: Wed, 25 Feb 1998 09:39 -0500 From: SCHREIBER@PROCESS.COM (Jeff Schreiber) Reply-To: Info-TCPware@process.com Message-ID: <009C2559C3BFE6AC.7C9B@PROCESS.COM> To: Info-TCPware@process.com Subject: RE: FTP Tcpware 5.3-2 +patches to Tcpware for IAS V2.1-1 "Cok Baris" writes: >I can send and receive files, but most of the command procedures fail >because of this message. Please type "SET DEBUG/CLASS=ALL" and issue your tests again so that we can see exactly what commands are being sent across and being rejected. (You probably will want to delete the value associated with the "PASS" command, so you aren't telling the world your password :) - Jeff -- Jeff Schreiber, Process Software Corp. schreiber@process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Thu, 26 Feb 1998 03:12:21 -0400 Subject: Re: FTP Tcpware 5.3-2 +patches to Tcpware for IAS V2.1-1 Message-ID: <1998Feb25.223806@process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 25 Feb 98 22:38:06 -0500 To: Info-TCPware@PROCESS.COM In article <01bd41f8$9acc0a40$ce6643c1@cokbar.intra.kender-thijssen.nl>, "Cok Baris" writes: > Hi there, > > Since the upgrade to tcpware 5.3-2 I get an error message during connect > with ftp to TCPWARE for IAS V2.1-1 > > FTP>con log > 220 LOG (163.175.36.2) TCPware(TM) for IAS V2.1-1 (c) Process Sofwtare > Corporation > Username [blabla]:[1,1] > 331 Password required > _Password: > 230 User logged in, proceed > 500 Syntax error or unrecognized command > <--------------------------------- > > I can send and receive files, but most of the command procedures fail > because of this message. > > Has anyone a suggestion? Yes, just use CONNECT/NOVMS (or OPEN/NOVMS). The 500 error is caused by the command to enter VMS-to-VMS mode, which IAS does not support. - Bernie Volz Process Software