Archive-Date: Tue, 7 Sep 1993 15:27:00 GMT Subject: TCPware and ANU-News link problem Message-ID: <7SEP199315270143@news.rsc.org> From: sysuser@news.rsc.org (SYSTEM MANAGER) Date: Tue, 7 Sep 1993 15:27:00 GMT Sender: news@math.fu-berlin.de (Math Department) I'm having problems linking ANU-News after compiling with gcc. I'm getting the error message "Illegal Record Type (9)". Anybody got any ideas? We're using VMS 5.4-3. Stewart White Royal Society of Chemistry ================================================================================ Archive-Date: XXX, 7 Sep 1993 17:06 PDT Subject: Re: TCPware and ANU-News link problem Message-ID: <7SEP199317065778@eql.caltech.edu> From: rankin@eql.caltech.edu (Pat Rankin) Date: 7 Sep 1993 17:06 PDT References: <7SEP199315270143@news.rsc.org> In article <7SEP199315270143@news.rsc.org>,\ sysuser@news.rsc.org (SYSTEM MANAGER) writes... > I'm having problems linking ANU-News after compiling with gcc. I'm getting > the error message "Illegal Record Type (9)". Anybody got any ideas? We're > using VMS 5.4-3. If you get just one or a few of those, then I don't know what's going on. But if you get a whole bunch of them, then you probably have some logical name which matches the base portion of one of the source filenames, and you're accidentally feeding the wrong file to the linker because of it. Another possibility is omitting /options when passing foo.opt to the linker, so that it treats foo.opt as an object file (ditto for omitting /library and /include from foo.olb). Either way, the linker should be reporting the actual filename of the one which has bad records in it. If that file really is an object module, try ANALYZE/OBJECT on it and/or browsing it with an editor to see what it really contains. Pat Rankin, rankin@eql.caltech.edu ================================================================================ Archive-Date: XXX, 10 Sep 1993 13:39:59 GMT Subject: new features Message-ID: <26q03f$hn5@pulitzer.eng.sematech.org> From: COLER@MAIL.ENG.SEMATECH.ORG (REGINALD COLE) Date: 10 Sep 1993 13:39:59 GMT Can anyone share any information at this time about what will be available in the next release of TCPware. Release date? NFS? DNS? SMTP? Other file sharing methods INTERNET ADDRESS: REGINALD_COLE@SEMATECH.ORG (512)356-7527 ================================================================================ Archive-Date: Fri, 10 Sep 1993 16:12:31 GMT Subject: Re: new features Message-ID: <1993Sep10.161231.22049@aragorn.unibe.ch> From: egger@ubeclu.unibe.ch (Martin Egger) Date: Fri, 10 Sep 1993 16:12:31 GMT Reply-To: egger@ubeclu.unibe.ch Sender: news@aragorn.unibe.ch References: <26q03f$hn5@pulitzer.eng.sematech.org> In article <26q03f$hn5@pulitzer.eng.sematech.org>, COLER@MAIL.ENG.SEMATECH.ORG (REGINALD COLE) writes: >Can anyone share any information at this time about what will be available in >the next release of TCPware. Perhaps you could tell us, which release you actually have ... ! >Release date? >NFS? >DNS? >SMTP? All this stuff *is* available in the current release 3.1-5 on OpenVMS/VAX and AXP and has been (for VAX) at least since release 2.0, when we started to use TCPware here 2 years ago! >Other file sharing methods Which one do you think of, other than NFS? Martin ******************************************************************************* Martin Egger, Ph.D., Computing Services - Head of System/User Support Group University of Bern, P.O. Box, Laenggassstrasse 51, CH-3012 Bern, Switzerland Phone: ++41 (0)31 65 38 45, Fax: ++41 (0)31 65 38 65, Telex: 912 643 pibe ch RFC: egger@id.unibe.ch, X.400: S=egger;OU=id;O=unibe;P=switch;A=arcom;C=ch; HEPNET/SPAN: 20579::49202::egger, DECnet (Switzerland): 49202::egger ******************************************************************************* ================================================================================ Archive-Date: XXX, 10 Sep 1993 19:18:16 GMT Subject: Re: new features Message-ID: <26qjto$d34@pulitzer.eng.sematech.org> From: COLER@MAIL.ENG.SEMATECH.ORG (REGINALD COLE) Date: 10 Sep 1993 19:18:16 GMT References: <26q03f$hn5@pulitzer.eng.sematech.org> <1993Sep10.161231.22049@aragorn.unibe.ch> In-Reply-To: egger@ubeclu.unibe.ch's message of Fri, 10 Sep 1993 16:12:31 GMT In <1993Sep10.161231.22049@aragorn.unibe.ch> egger@ubeclu.unibe.ch writes: > In article <26q03f$hn5@pulitzer.eng.sematech.org>, COLER@MAIL.ENG.SEMATECH.ORG (REGINALD COLE) writes: > >Can anyone share any information at this time about what will be available in > >the next release of TCPware. > > Perhaps you could tell us, which release you actually have ... ! > > >Release date? > >NFS? > >DNS? > >SMTP? > > All this stuff *is* available in the current release 3.1-5 on OpenVMS/VAX and > AXP and has been (for VAX) at least since release 2.0, when we started to use > TCPware here 2 years ago! > > >Other file sharing methods > > Which one do you think of, other than NFS? > Martin Thanks Martin, I have the current version as well. I guess I'am looking for rumors about the new version(SMB support, Name server tools or any other enhancements) Don't break any ethical rules. ================================================================================ Archive-Date: XXX, 15 Sep 1993 09:14:38 -0500 From: volz@process.com Subject: Re: new featrues Message-ID: <1993Sep15.091438.90@process.com> Date: 15 Sep 93 09:14:38 -0500 Sorry for the delay on a response to a request for details on the next release of TCPware for OpenVMS. And, sorry to say, you'll have to wait just a bit longer ... The announcement on the next release will occur in the first week of October. That announcement will be posted to this newsgroup. Thanks for your continued interest! - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: Fri, 17 Sep 1993 18:01:11 GMT Subject: Unwanted SMTP Source Routing. Message-ID: From: mikewd@leica.co.uk (Mike Wilmot-Dear) Date: Fri, 17 Sep 1993 18:01:11 GMT I have a problem with TCPWare (V3.0-2) when it is resending mail (sent from PCs). In that it generates an unwanted source routed From: address. Our configuration is that we have a number of PC's which read mail (via POP3) from peoples accounts on the VAX and when sending mail the PC's use SMTP to send the mail to the VAX (running TCPWare) which then sends it on to it's destination via our main site mail gateway. The problem is that although the PC's are configured to have a correct (fully qualified) From: address. e.g. . Where "eng.leica.co.uk" is the generic mail domain for our Vax. What comes from the VAX in the resent message is a source routed From: address e.g. <@vax-name.leica.co.uk:bloggs@eng.leica.co.uk>. Now although I would rather the VAX didn't generate a source routed address. But I'm prepared to accept that it is, possibly, strictly correct behaviour, and it wouldn't matter (as the From: address is pointing at the VAX anyway), *except* that TCPWare uses the actual VAX hostname rather than the TCPWARE_SMTP_FROM_DOMAIN (which is setup to be "eng.leica.co.uk"). This means that mail goes out with a specific machine hostname on it which is what the TCPWARE_SMTP_FROM_DOMAIN was supposed to avoid in the first palce. :-( A further complication is that being in the UK when communicating with some backbone sites on JANET ( the UK academic Newtork) they expect all UK mail address to be registered in the JANET central register (a hangover from the old days of centralised name registration) and we don't want to have to go around registering individual machines. {We have perfectly valid DNS records for all our hosts but this isn't good enough for JANET :-( } Firstly does anyone think this behaviour of TCPWare is wrong, or have I missed something in the RFC's that mean the source route has to be a the primary hostname rather than an MX record. Secondly does anyone have any suggestions for solving it or know if it is fixed in a later version of TCPWare. Otherwise I guess I'll just have to hack up something in the sendmail.cf on our main mail gateway to try to rewrite this address to strip out the source routing. But I'd rather not as it's otherwise working alright at the moment and I adopt the maxim "if it's not broken leave well alone" ;-) In other respects TCPWare's a very good product (and streets ahead of the DEC offering) but its SMTP, whilst being easy to setup initially, does lack the "configurability" of some UNIX mailers, which limits it's usefulness for use as a central mail machine. Thanks for any comments, Mike -- ------------------------------------------------------------------------------ Mike Wilmot-Dear (MW342) e-mail: mikewd@leica.co.uk Leica Cambridge Ltd. Tel: +44 223-411411 (x385) Clifton Road Fax: +44 223-210692 Cambridge, CB1 3QH, UK ================================================================================ Archive-Date: XXX, 18 Sep 1993 11:09:22 -0400 From: volz@process.com Subject: Re: Unwanted SMTP Source Routing. Message-ID: <1993Sep18.110922.92@process.com> Date: 18 Sep 93 11:09:22 -0400 References: In article , mikewd@leica.co.uk (Mike Wilmot-Dear) writes: > I have a problem with TCPWare (V3.0-2) when it is resending mail (sent from > PCs). In that it generates an unwanted source routed From: address. > (rest of message discarded) Mike: We'll look into it and get back to you. Source routing is "discouraged" these days, so we really shouldn't be doing it unless absoletely necessary. For a more full service mail package, you might look into MX (available from several sites) or PMDF (available from Innosoft). If you need further details on either, let me know. Thanks, - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: Mon, 27 Sep 1993 19:46:43 GMT Subject: Re: Unwanted SMTP Source Routing. Message-ID: From: mikewd@leica.co.uk (Mike Wilmot-Dear) Date: Mon, 27 Sep 1993 19:46:43 GMT References: <1993Sep18.110922.92@process.com> volz@process.com wrote: : In article , mikewd@leica.co.uk (Mike Wilmot-Dear) writes: : > I have a problem with TCPWare (V3.0-2) when it is resending mail (sent from : > PCs). In that it generates an unwanted source routed From: address. : > : (rest of message discarded) : Mike: : We'll look into it and get back to you. Source routing is "discouraged" : these days, so we really shouldn't be doing it unless absoletely necessary. [... text deleted ...] : - Bernie Volz : Process Software Corporation I thought I would just post the conclusion to this in case anyone else has the same problem. The answer is that these days, as Bernie says, source routing, even on the SMTP FROM:
is not normally used unless going off the Internet. This problem has already been addressed in the upcoming release of TCPWare, (version 4) which is I believe scheduled for release around November time. So that it no longer puts in source routing on messages forwared via SMTP (it also doesn't bother adding various redundant headers such as "Resent-From:"). In the meantime Process Software have kindly sent us a patch which applies this new behaviour to our version and this seems to have succesfully fixed our problem. I would like to thank Bernie, Mike, and Noel at Process Software Corp. for their speedy response on this. It confirms my opinion in preferring TCPWare over the competing products. (Especially one made by a certain large mini-computer manufacturer.) If only all vendors had such a good attitude to customer support. Thanks, Mike. -- ------------------------------------------------------------------------------ Mike Wilmot-Dear (MW342) e-mail: mikewd@leica.co.uk Leica Cambridge Ltd. Tel: +44 223-411411 (x385) Clifton Road Fax: +44 223-210692 Cambridge, CB1 3QH, UK ================================================================================ Archive-Date: XXX, 28 Sep 1993 16:12:04 -0400 From: capobianco@process.com Subject: Expanding Worldwide Distribution channels Message-ID: <1993Sep28.161204.94@process.com> Date: 28 Sep 93 16:12:04 -0400 Process Software Corporation Significantly Expands Worldwide Distribution Channels Signs Agreements With Four Major European Business Partners Process Software Corporation announces it has substantially expanded its worldwide distribution channels with the signing of four additional European business partners. As Process Software Corporation's European business partners, DATACCESS, headquartered in France, BRAIN FORCE Group, based in Germany, and Interparts Computer Products B.V., headquartered in the Netherlands will market and distribute the TCPware and CompressNET product lines while providing service and support at the local level. As a Process Software Corporation Authorized Solutions Partner, Neuronet, headquartered in France, will provide TCP/IP networking solutions to meet and satisfy the specific networking needs of the end#user community in France. DATACCESS, based in Les Ulis, France, specializes in DEC and UNIX environments, providing end users with a wide range of products including TCP/IP and Novell networking software. The BRAIN FORCE Group, headquartered near Munich, Germany, specializes in systems management and networking. Interparts Computer Products, based in Lisse, Netherlands, provides open systems solutions to DEC, UNIX, and PC users in the Netherlands, Belgium and Luxembourg. Neuronet, located in Bron, France, is a systems integrator providing software products and network design, implementation, and support services. For additional information, please contact Process Software Corporation Director of International Sales Ed Brohm or Brohm@process.com or support@process.com (800)722-7770 or (508)879-6994 ================================================================================ Archive-Date: XXX, 29 Sep 1993 12:22:02 -0400 From: wadelton@process.com Subject: TCPware 4.0 Press Release Message-ID: <1993Sep29.122202.96@process.com> Date: 29 Sep 93 12:22:02 -0400 Process Software Corporation Merges NetWare and TCP/IP Network Services in Major New Release of TCPware FRAMINGHAM, Mass., October 4, 1993 -- Process Software Corporation today announced TCPware 4.0 for OpenVMS, a major new release of its networking software solutions. The new version complements TCPware's TCP/IP functionality by providing a full range of NetWare-OpenVMS interoperability services including file sharing, bi-directional printing and terminal emulation capabilities. In addition, TCPware 4.0 includes a number of significant enhancements to its TCP/IP services. With TCPware 4.0, organizations can seamlessly integrate their OpenVMS systems into both TCP/IP and NetWare environments with one comprehensive software solution. Each TCP/IP and NetWare service in the TCPware family comes complete with the essential lower layer services that enable the OpenVMS system to function as a TCP/IP and/or IPX/SPX network host. This modular architecture allows each service to operate as a standalone product, in combination with other services, or as part of the complete TCPware package. "With TCPware 4.0, organizations not only have the freedom to choose exactly the network services they need, but also the flexibility to meet their users' multiple protocol application requirements," said Jack Simpson, vice president of marketing, sales and support, Process Software Corporation. "Equally important, TCPware enables these organizations to leverage their investment in OpenVMS systems." The IPX/SPX stack in TCPware is based upon technology developed by InterConnections, Inc., in conjunction with Novell, Inc. TCPware's NetWare services include: -Terminal Emulation Services (TES), which allow NetWare users to log in to the OpenVMS system and run OpenVMS applications. -File Sharing Services (FSS), which enable NetWare LAN users and OpenVMS users to transparently share files, and allows NetWare users to print to VAX printers. -Network Print Services (NPS) which make NetWare printers available to OpenVMS users. TCPware 4.0 also includes a number of enhancements to its TCP/IP services. Among the highlights are: Routing Information Protocol (RIP) support, which automatically provides dynamic routing information on the network; rcp (UNIX remote copy command) support; the ability for users of DEC's ALL-IN-1 mail facility to exchange mail with users on TCP/IP systems not running ALL-IN-1; LMF licensing support; and increased NFS functionality, including the ability to run NFS over TCP, NFS Client file locking, NFS Client support for symbolic links, NFS Client auditing support, and support for Sun's PCNFSD Version 2. TCPware's TCP/IP services include: -File Transfer Protocol (FTP) for bi-directional file transfers. -Simple Mail Transfer Protocol (SMTP) for electronic mail transfers. -TELNET for transparent access to applications and information on remote systems. -NFS Client for transparent access to files stored on remote servers. -NFS Server for file sharing among other systems running TCP/IP. -NFS-Plus, combining TCPware's NFS Client and Server into one cost-effective package. TCPware 4.0 will begin shipping in late October, 1993. #####