Archive-Date: XXX, 1 Feb 1996 17:23:23 -0500 Subject: Re: TCPWare TCP site command Message-ID: <1996Feb1.172323@process.com> From: tchen@process.com (Weimin Tchen - Process Software 800-722-7770 x280) Date: 1 Feb 96 17:23:23 -0500 > I'm trying to implement a data server using only ftp, using the > SITE command available in TCPWare. Problem is, if my command > line exceeds a hundred or so characters (i.e. way less than > the VMS limit of 256, although I don't know the exact length > at which this starts to happen), the client gets a message > back from the VMS machine: "SYSTEM-F-IVBUFLEN - Invalid Buffer > Length". In TCPware 5.1, the buffer size is increased to hold up to a 252 character command after "SITE SPAWN" ... The previous limit was 192 char. I hope this helps. Thanks for pointing this out, -Weimin Tchen ================================================================================ Archive-Date: XXX, 1 Feb 1996 18:58:01 -0500 Subject: Re: Mixing UCX and TCPWARE in a cluster Message-ID: <1996Feb1.185801@process.com> From: volz@process.com (Bernie Volz) Date: 1 Feb 96 18:58:01 -0500 References: <4eibfs$gms@romeo.logica.co.uk> <822922954.3181@paulr.integralis.co.uk> In article <822922954.3181@paulr.integralis.co.uk>, Paul.Roberts@integralis.co.uk (Paul Roberts) writes: > Blacka@logica.com (Andrew Black) wrote: > >>Does anyone know if there might be problems trying to >>load TCPWARE and UCX on two nodes that share a common >>system disk. We already have TCPWARE, and it has >>been suggested to load UCX. > >>My gut feeling is someting is SYS$SYSTEM or SYS$LIBRARY >>or similar will get itself very confused. > >>Dont ask too closely why I want to do this - its to >>do with trying to support a product that can use either >>if the two TCP stacks. > > I'd be careful about this. TCPware emulates the UCX $QIO interface > anyway, so everything that runs over UCX should run fine over TCPware. > Also, if both products update DCLTABLES then which version of ftp, > telnet, rsh, ping etc. will be run when you issue those commands? TCPware does not update the DCLTABLES. We use foreign command definitions and it was done just with this in mind. - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: XXX, 5 Feb 1996 12:07:45 -0400 Subject: TCPware V5.1 Beta Sites Message-ID: <1996Feb5.120745.1825@delta.process.com> From: ostrom@process.com (Andy Ostrom) Date: 5 Feb 96 12:07:45 -0400 MIME-Version: 1.0 Content-Type: Text/Plain; charset=ISO-8859-1 We are planning to begin Beta testing of TCPware V5.1 at the end of this month. Major new features of V5.1 include: PPP Server Classless Inter Domain Routing (CIDR) NFS Client Performance Improvements Extensible MIBs POP3 Mail (really in V5.0-4) Current plans for V5.1 will change our support to OpenVMS V5.5-2 and later. If you are interested in participating in the TCPware V5.1 Beta Program, please send me a mail message at "ostrom@process.com" with your e-mail address, and I will send you the Beta Program questionaire. Thanks. Andy Ostrom OpenVMS Products Business Manager Process Software Corporation ================================================================================ Archive-Date: XXX, 5 Feb 1996 17:03:15 GMT Subject: Re: Work around TCPWARE 5.0 bug Message-ID: <4f5d8j$qq@theben.kapsch.co.at> From: eplan@kapsch.co.at (Peter LANGSTOEGER) Date: 5 Feb 1996 17:03:15 GMT Reply-To: eplan@kapsch.co.at References: <4eoqll$vhs@hera.cuci.nl> In article <4eoqll$vhs@hera.cuci.nl>, akorsten@cuci.nl (Andreas Korsten) writes: >Recently I installed the 5.0 version of TCPWARE. I discoverd that if >you use the DECW interface of the FTP module the window of the FTP >session starts growing and schrinking. >Has any one discoverd the same problems??? Sorry, no. I was so far not able to use DECW_FTP at all. Every time I invoke DECW_FTP it crashes with an ACCVIO shortly after getting the initial directory listing from the remote FTP server. (we are using vanilla OpenVMS Alpha V6.2 with TCPware V5.0-4) jfi PS: Normal FTP client crashes sometimes with "%TCPWARE_FTP-F-ERRDURWRI", too. PPS: Use of RFC1006 (eg. DECnet/OSI over IP) crashes our VAXes and Alphas (again OpenVMS V6.2 w/ or w/o patches, TCPware V5.0-4, DECnet/OSI V6.2 ECO 4) with DOUBLEDEALLO or BADDALRQSZ bugchecks in PWIPDRIVER. ----------------------------------------------------------------------------- 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.co.at <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: XXX, 5 Feb 1996 19:04:32 -0500 Subject: Re: Work around TCPWARE 5.0 bug Message-ID: <1996Feb5.190432@process.com> From: volz@process.com (Bernie Volz) Date: 5 Feb 96 19:04:32 -0500 References: <4eoqll$vhs@hera.cuci.nl> <4f5d8j$qq@theben.kapsch.co.at> In article <4f5d8j$qq@theben.kapsch.co.at>, eplan@kapsch.co.at (Peter LANGSTOEGER) writes: > In article <4eoqll$vhs@hera.cuci.nl>, akorsten@cuci.nl (Andreas Korsten) writes: >>Recently I installed the 5.0 version of TCPWARE. I discoverd that if >>you use the DECW interface of the FTP module the window of the FTP >>session starts growing and schrinking. >>Has any one discoverd the same problems??? > > Sorry, no. I was so far not able to use DECW_FTP at all. > > Every time I invoke DECW_FTP it crashes with an ACCVIO shortly after > getting the initial directory listing from the remote FTP server. > (we are using vanilla OpenVMS Alpha V6.2 with TCPware V5.0-4) > > jfi > > PS: Normal FTP client crashes sometimes with "%TCPWARE_FTP-F-ERRDURWRI", too. > PPS: Use of RFC1006 (eg. DECnet/OSI over IP) crashes our VAXes and Alphas > (again OpenVMS V6.2 w/ or w/o patches, TCPware V5.0-4, DECnet/OSI V6.2 ECO 4) > with DOUBLEDEALLO or BADDALRQSZ bugchecks in PWIPDRIVER. > ----------------------------------------------------------------------------- > Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2382 We'd like to make sure these problems you are reporting are addressed. We are currently working on TCPware V5.1 and would like to make that release as solid as possible. Please contact either myself (volz@process.com) or support@process.com to provide more details about these problems ASAP. For example: For DECW_FTP, what remote system(s) are you trying to access? Are these public sites so that we can try to reproduce the problem here? Can you also provide the stack/traceback dump (if any) from the DECW_FTP ACCVIO? For the FTP Client crashing with "%TCPWARE_FTP-F-ERRDURWRI", can you be more specific about when this happens? This is a Run-Time Library error. For the PWIPDRIVER issue, could you make available a crash dump or provide some details on the crash using SDA? There was a problem in V5.0-3 that could result in this kind of system crash; we believed V5.0-4 fixed it. Are you certain you were using V5.0-4 when this crash occured? V5.0-4 is fairly recent. Thanks in advance. - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: XXX, 20 Feb 1996 00:23:54 -0500 Subject: Re: Form feed between jobs in LPR queue Message-ID: <1996Feb20.002354@process.com> From: shibuya@process.com (Hiroto Shibuya) Date: 20 Feb 96 00:23:54 -0500 References: <4g2707$77c@romeo.logica.co.uk> In article <4g2707$77c@romeo.logica.co.uk>, Blacka@logica.com (Andrew Black) writes: > I have a que set up on my VAX that uses LPR to an NT server. > Eventually it ends up on an HP4SI. > > This works OK apart from the fact the at the end of one print job the next > one continues at the same page. I assume that I need to put an FF at the > end of each job - how can I do this. > > The qeiei os defined as follows: > > Server queue GMS_HP4SI_G, idle, on KIRK::, mounted form DEFAULT > /BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) /OWNER=[SYSTEM] > /PROCESSOR=TCPWARE_VMSLPRSMB /PROTECTION=(S:M,O:D,G:R,W:S) /RETAIN=ERROR > > Any suggestions ? > Thanks We had problem with TCPWARE_VMSLPRSMB symbiont that it inserts extra unwanted FF in certain situation, but no the other way around :-) This symbiont talks LPD protocol, which pass down contents of files (in this case VMS symbiont formatted file), and it is remote server's responsibility to appropriately insert FF or use whatever means to separate jobs. Since VMS print symbiont thinks it is printing out to printer device, it tries to insert FF when it thinks appropriate and we play some game to make sure these extra FF are not send out as part of the data. We didn't play the game quite right in 5.0-3B and fixed in 5.0-4. But the problem here seems different. To isolate the problem, please try to print simple files to the same printer using LPR command, or TCPWARE_LPRSMB symbiont and see if the results are the same. Or if you could, try printing from Unix box and compare the result. If the results are the same, it could be problem with Microsoft LPD serer. If the problem occur only with TCPWARE_VMSLPRSMB symbiont, does it occur with any printing? Do you specify forms? Do you specify setup modules? Please try changing these variables and post the result. -- Hiroto Shibuya Process Software Corporation