Archive-Date: XXX, 3 Apr 1993 11:09:10 -0500 From: volz@process.com Subject: Hello and Welcome Message-ID: <1993Apr3.110910.54@process.com> Date: 3 Apr 93 11:09:10 -0500 Welcome to this newsgroup on issues relating to the TCPware for OpenVMS (and TCPware for PDP-11) software. This posting is to let you know that folks from Process Software Corporation (provider of TCPware) will be reading this news group and responding. Best regards, - Bernie Volz Process Software Corporation 800-722-7770 or 508-879-6994 FAX: 508-879-0042 ================================================================================ Archive-Date: XXX, 3 Apr 1993 23:51:00 GMT Subject: How to setup tcp ip on workstations using arcnet cards Message-ID: <3APR199318515004@vill.edu> From: 166728647@vill.edu (DHARMESH CHOVATIA) Date: 3 Apr 93 23:51:00 GMT Sender: news@vu-vlsi.ee.vill.edu on novell 3.11 and using arcnet cards. My school has similar machines which have tcp ip setup but are using ethernet cards. I have been told that the telnet connections are possible only on the stations using ethernet cards. I tend to dibelieve this and think that there are packet drivers, or something similar, to set it up for arcnet cards. I am novice to telnet and do not have an indepth understanding of the pc hardware pertaining to networking and so would appreciate if the replies are based on pretty basic stuff. I would also like the same information for appletalk network running again on novell 3.11 and using local talk. Thanking in advance Sincerely Dhar ================================================================================ Archive-Date: XXX, 4 Apr 1993 13:27:59 -0500 From: volz@process.com Subject: Re: How to setup tcp ip on workstations using arcnet cards Message-ID: <1993Apr4.132759.55@process.com> Date: 4 Apr 93 13:27:59 -0500 References: <3APR199318515004@vill.edu> In article <3APR199318515004@vill.edu>, 166728647@vill.edu (DHARMESH CHOVATIA) writes: > on novell 3.11 and using arcnet cards. My school has similar machines which > have tcp ip setup but are using ethernet cards. > > I have been told that the telnet connections are possible only on the stations > using ethernet cards. I tend to dibelieve this and think that there are packet > drivers, or something similar, to set it up for arcnet cards. > > I am novice to telnet and do not have an indepth understanding of the pc > hardware pertaining to networking and so would appreciate if the replies > are based on pretty basic stuff. > > I would also like the same information for appletalk network running again > on novell 3.11 and using local talk. > > Thanking in advance > > Sincerely > > Dhar Dhar: The vmsnet.networks.tcp-ip.tcpware newsgroup is for discussing issues with Process Software Corporation TCPware for OpenVMS softare ... not for Netware related issues. I'm not a Netware or PC user so can't help you much regarding the above issues. > I have been told that the telnet connections are possible only on the stations >using ethernet cards. I tend to dibelieve this and think that there are packet >drivers, or something similar, to set it up for arcnet cards. What TCP/IP software are you using on the PC? You should check with that software vendor to determine whether arcnet drivers are available (or contact the manufacturer of the cards). In principal, TCP/IP should be able to run over the arcnet cards. - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: Mon, 5 Apr 1993 22:16:42 GMT Subject: Re: SQL*NET on top of TCPWare ? Message-ID: <1993Apr5.221642.767@unipalm.co.uk> From: ian@unipalm.co.uk (Ian Phillipps) Date: Mon, 5 Apr 1993 22:16:42 GMT References: <1993Apr2.150924.50@elmrd6.ineab.ikea.se> anos@elmrd6.ineab.ikea.se writes: >I'm interested in hearing from anybody that have experience in using >SQL*NET on top of TCPWARE (and possible BUSINESS OBJECTS too)... One of our customers has just done this, using the UCX (DEC) emulation built into TCPware. You tell Oracle that you have a DEC system, and the rest follows, since the START/UCX happens automatically as long as the BGDRIVER executable is there. It all fired off with no problems, although they haven't done any "real" work with it yet. This was with a copy of SQL*NET that they already had. Maybe someone with more Oracle experience can say whether native support is also available in recent versions. Ian Unipalm Technical Support -- Ian Phillipps, Unipalm Ltd, 216 Science Park, Phone +44 223 420002 Milton Road, Cambridge, CB4 4WA, England. Phax +44 223 426868 PIPEX is a division of Unipalm Ltd. - phone 0223 424616. ================================================================================ Archive-Date: Fri, 9 Apr 1993 21:10:20 GMT Subject: ANONYMOUS setup Message-ID: <0096AC70.ECF08A20@buckie.HSC.Colorado.EDU> From: dwing@uh01.colorado.edu (Dan Wing) Date: Fri, 9 Apr 1993 21:10:20 GMT Reply-To: dwing@uh01.colorado.edu Sender: news@colorado.edu (The Daily Planet) I have an evaluation copy of TCPware V3.1. In the manual, page 10-1, it mentions that a log file is created in the users' default directory which contains information about files transferred during an FTP session. On page 10-4, in bold type, it says "It is recommended that you protect the login directory to prevent the owner, group, and world from writing in that directory." Questions: 1. Is it possible to get a log of transferred files while still preventing people from uploading junk into ANONYMOUS's top-level directory? 2. The documentation also states that there are no special access restrictions imposed by the ANONYMOUS support. Any plans to add the ability to restict access to subdirectories below SYS$LOGIN if a site desires such a restriction? -d ================================================================================ Archive-Date: XXX, 9 Apr 1993 20:35:04 -0400 From: volz@process.com Subject: Re: ANONYMOUS setup Message-ID: <1993Apr9.203504.59@process.com> Date: 9 Apr 93 20:35:04 -0400 References: <0096AC70.ECF08A20@buckie.HSC.Colorado.EDU> In article <0096AC70.ECF08A20@buckie.HSC.Colorado.EDU>, dwing@uh01.colorado.edu (Dan Wing) writes: > I have an evaluation copy of TCPware V3.1. > > In the manual, page 10-1, it mentions that a log file is created in the > users' default directory which contains information about files transferred > during an FTP session. > > On page 10-4, in bold type, it says "It is recommended that you protect the > login directory to prevent the owner, group, and world from writing in that > directory." > > Questions: > > 1. Is it possible to get a log of transferred files while still preventing > people from uploading junk into ANONYMOUS's top-level directory? No, I it isn't possible (once the directory is protected, the .LOG file will not be created). In one sense, this is desirable since the directory won't have extraneous files in it (.LOG). On the other hand, a record of the files transferred might be nice. > > 2. The documentation also states that there are no special access > restrictions imposed by the ANONYMOUS support. Any plans to add the > ability to restict access to subdirectories below SYS$LOGIN if a site > desires such a restriction? > > -d It is our intention to improve the ANONYMOUS support. Exactly when this improved version will be available I can't say. Some of the items we are considering are: - The ability to restrict access to files only at or below the login directory. - The ability to define a message to be displayed after a ANONYMOUS user logs on. If there are other items you desire, please let us know (perhaps some mechanism to record the files transferred?). Thanks. - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: Sat, 10 Apr 1993 01:29:56 GMT Subject: Re: ANONYMOUS setup Message-ID: <0096AC95.33905540@buckie.HSC.Colorado.EDU> From: dwing@uh01.colorado.edu (Dan Wing) Date: Sat, 10 Apr 1993 01:29:56 GMT Reply-To: dwing@uh01.colorado.edu Sender: news@colorado.edu (The Daily Planet) References: <0096AC70.ECF08A20@buckie.HSC.Colorado.EDU>,<1993Apr9.203504.59@process.com> In article <1993Apr9.203504.59@process.com>, volz@process.com writes: >Some of the items we are considering are: > - The ability to restrict access to files only at or below > the login directory. Some sites (I'm not one of them) may want Anonymous to be able to get to files outside of their login directory tree. > - The ability to define a message to be displayed after a > ANONYMOUS user logs on. > >If there are other items you desire, please let us know (perhaps some >mechanism to record the files transferred?). That would be great. If the log was outside of Anonymous' directory tree, and the above-mentioned enhancement were implemented, we'd be all set. The log would have to include the source IP address or system name, but I haven't found a way to obtain that information other than the FTP log file that is created by defining the TCPWARE_FTPD_LOGFILE logical. Otherwise, there are two processes involved with an FTP transfer -- one is logged into the actual user's account, the other does (?something - haven't looked at it closely yet). Anyway, the "other" process is privileged, and maybe it could write a log of files transferred, and perhaps even log when a user attempts to transfer a file they aren't supposed to transfer? For example, it would be useful to know if someone tried to transfer RIGHTSLIST.DAT. Thank you for your quick reply, -d ================================================================================ Archive-Date: Mon, 19 Apr 1993 02:33:03 GMT Subject: NeXT/OS2 TCP-IP Device Driver(s) Message-ID: <2944265515.4.p00378@psilink.com> From: "James Gaines" Date: Mon, 19 Apr 1993 02:33:03 GMT Sender: usenet@worldlink.com To all programming hotdogs ... I need some input on the existence of solutions to the following NeXT/OS2 TCP-IP problem. I'd appreciate you telling me your experiences. DISCLAIMER: I am not nearly as well versed as I would like to be in network issues. My specialty is data analysis and financial engineering and I need this problem resolved to build a better *mouse trap*! Any help is greatly appreciated. I am interested in interfacing my NeXT workstation with an OS2 (INTEL) machine. The OS2 machine collects data from an external source and maps all the data (all data structures are known) locally into RAM. My goal is for the NeXT to access the data from the OS2 machine across TCP-IP. Please don't curse me for incorporating an OS2 machine, but I am locked in because OS2 is the only platform upon which this app runs. The app is a real-time market data feed quote server. If anyone knows of a real-time data feed quote server which runs on the NeXT and is distributable (ie. maps all data into RAM locally and provides utilities/C structures for data access) across, please let me know! Otherwise, here we go ... The networked setup involves three (3) pieces. First, a distributable data feed app running on the OS2 machine which perpetually maps the incoming (serial port) data into local RAM. Also, the OS2 app [APP1] has a daemon which looks across the TCP-IP network for data requests from the NeXT. The second piece involves the NeXT app [APP2] which sends out data requests across TCP-IP. This involves a daemon of a sort because, as market data is updated, the NeXT app must be aware of the change and submit a new request accordingly. The third item is the obvious: the TCP-IP network. The problem appears to be that I need a device driver which will interface between the NeXT daemon calls and the OS2 daemon which is looking for the NeXT calls to come across network. I do not know exactly what daemon/program pieces I need to make this work. I am looking for solution proposals and references to previous efforts to do the same (if any exist). I would appreciate any expert clarification of the problem and of course any and all solutions! Currently, I have solved this problem by writing an OS2 app which perpetually ports out *all* the real-time data across a serial cable. Subsequently the NeXT machine reads its' own serial port and grabs *all* the packets. APP2 then reads through the packets and structures and determines what it wants and what it will discard. -- I feel that this a *kluge* and extremely inefficient. Also, I believe I suffer a degradation in data transfer speed which will become significant once we move 100Mbs TCP-IP. So I would prefer to resolve the situation noted above and be better positioned for today and tomorrow. I thank you in advance. Peace!! ================================================================================ Archive-Date: XXX, 22 Apr 1993 11:02 MST Subject: Experiences wanted: TCP/IP on VMS support quality Message-ID: <22APR199311025203@opus1.com> From: jms@opus1.com (Joel M-for-Vnews Snyder) Date: 22 Apr 1993 11:02 MST Reply-To: jms@Opus1.COM Folks: I am writing a review of TCP/IP packages for OpenVMS, and would like your subjective (or objective) experiences with support from any of the TCP/IP vendors you've worked with. Please don't post them here, but send them to me at jms@Opus1.COM. I'm looking for both positive and negative experiences. It would be useful for you to also include a timeframe (e.g., "we bought EXOS from Excelan in 1987, and back then, they were ...") Thanks, jms PS: Apologies to those of you who read more than one vmsnet.networks.tcp-ip.* newsgroup, who will see this than once. Joel M Snyder, 1103 E Spring Street, Tucson, AZ, 85719 Phone: 602.882.4094 (voice) .4095 (FAX) .4093 (data) Internet: jms@Arizona.EDU BITNET: jms@Arizona Yow! Are you the self-frying president?