Archive-Date: XXX, 12 Sep 1996 15:15:23 GMT Subject: All solutions for printing in DEC envirement Message-ID: <5199eb$4j3@news.sct.fr> From: toto (ZORRO) Date: 12 Sep 1996 15:15:23 GMT Content-Type: Text/Plain; charset=US-ASCII Look WEB adress: http://www.worldnet.net/~stvray/ E-Mail: supp_srp@stvray.worldnet.fr Thanks ================================================================================ Archive-Date: Thu, 12 Sep 1996 15:20:55 GMT Subject: DHCP Server for MS Windows Clients Message-ID: From: mikewd@leica.co.uk (Mike Wilmot-Dear) Date: Thu, 12 Sep 1996 15:20:55 GMT I am trying to get the TCPWare DHCP server to serve (static) addresses to MS Windows for Workgroups clients (running the MS TCP-IP 32 stack). Although my DHCPTAB. looks o.k. (and is correctly read in) and the broadcasts from the PC Client are reaching the server and activating the DHCP server. The PC does not seem to be recieving any responses. No errors are being logged on the server either to OPCOM or to standard output of the DHCP server process. (I did a NETCU MOD SERV BOOTP UDP /out=TCPWARE:DHCP.LOG and get a start up messages in the log e.g. "Read 5 entries (2 hosts) from TCPWARE_COMMON:[TCPWARE]DHCPTAB.") So I would be interested if a) anyone else is doing this and if so what did they put in their DHCPTAB. b) Is there any way to increase the amount of logging from the DHCP server to see what it is doing with the requests. My DHCPTAB. is (apologies for the long lines but I wanted to keep avoid confusing the issue with extra newlines) :- =========================================================================== # First, we define a global entry which specifies the stuff every host uses. global.dummy:\ :sm=255.255.255.0: ds=193.128.84.3 193.128.84.117 158.43.128.1:\ :hn: bs=auto: vm=auto: to=auto: # Next, we can define different master entries for each subnet. . . leicanet.dummy:\ :tc=global.dummy: gw=193.128.84.99:\ :dn=leica.co.uk: # Individual entries.... faclx1: ht=ethernet: ha=00-00-E8-C7-AB-75: tc=leicanet.dummy: ip=193.128.84.49: thames: ht=ethernet: ha=00-00-E8-D1-B4-32: tc=leicanet.dummy: ip=193.128.84.10: =========================================================================== Any help would be appreciated as we're planning to do a major network renumbering excercise next week and I'd like to get DHCP working before then. Cheers, Mike. -- ------------------------------------------------------------------------------ Mike Wilmot-Dear (MW342) Network Manager Leica Cambridge Ltd. e-mail: mikewd@leica.co.uk Cambridge, UK ================================================================================ Archive-Date: XXX, 13 Sep 1996 16:35:35 -0400 Subject: Re: DHCP Server for MS Windows Clients Message-ID: <1996Sep13.163535@process.com> From: shibuya@process.com (Hiroto Shibuya) Date: 13 Sep 96 16:35:35 -0400 References: In article , mikewd@leica.co.uk (Mike Wilmot-Dear) writes: > I am trying to get the TCPWare DHCP server to serve (static) addresses > to MS Windows for Workgroups clients (running the MS TCP-IP 32 stack). > > Although my DHCPTAB. looks o.k. (and is correctly read in) and the > broadcasts from the PC Client are reaching the server and activating > the DHCP server. ... > faclx1: ht=ethernet: ha=00-00-E8-C7-AB-75: tc=leicanet.dummy: ip=193.128.84.49: > > thames: ht=ethernet: ha=00-00-E8-D1-B4-32: tc=leicanet.dummy: ip=193.128.84.10: > =========================================================================== > This does not work with DHCPD up to 5.1-4. To reply to DHCP request, you must have "ar" address range. To assigne a single static address to a DHCP client, you have to say something like: ar=193.128.84.49 193.18.84.49: It is stupid limitation so TCPware 5.1-5 will take your syntax as synonym to the above. You can try the patch kit DHCPD_V515P010 from our FTP server which include this enhancement and more. -- Hiroto Shibuya Process Software Corporation ================================================================================ Archive-Date: XXX, 16 Sep 1996 20:32:24 GMT Subject: Q: Windows 95 and TCPware for Opem VMS Message-ID: <51kdgo$238@Nntp1.mcs.net> From: jbarr@Mercury.mcs.com (James W. Barr) Date: 16 Sep 1996 20:32:24 GMT If I install TCPware on my VAX OpenVMS system and then connect a Windows 95 based PC to the same ethernet network, using an ethernet card, can I use Windows 95 networking functions to connect to the VAX? How would this be done? Is Pathworks necessary in this scenario? Also, what about the same scenario, except for using dial-up PPP? Any information would be GREATLY helpful and appreciated! -- -Jim ----------------------------------------------------------------------------- James W. Barr, N9ONL | e-mail: jbarr@mcs.com Buffalo Grove, IL, USA | Web site: http://www.mcs.net/~jbarr ----------------------------------------------------------------------------- US Robotics' Pilot Organizer info: http://www.usr.com GEOS Operating system info : http://www.geoworks.com GEOS IZL info: send e-mail to jferas@netaxs.com ----------------------------------------------------------------------------- ================================================================================ Archive-Date: XXX, 17 Sep 1996 09:35:30 -0400 Subject: Re: Q: Windows 95 and TCPware for Opem VMS Message-ID: <1996Sep17.093530@process.com> From: volz@process.com (Bernie Volz) Date: 17 Sep 96 09:35:30 -0400 References: <51kdgo$238@Nntp1.mcs.net> In article <51kdgo$238@Nntp1.mcs.net>, jbarr@Mercury.mcs.com (James W. Barr) writes: > If I install TCPware on my VAX OpenVMS system and then connect a Windows 95 > based PC to the same ethernet network, using an ethernet card, can I use > Windows 95 networking functions to connect to the VAX? > > How would this be done? > > Is Pathworks necessary in this scenario? > > Also, what about the same scenario, except for using dial-up PPP? > > Any information would be GREATLY helpful and appreciated! > Windows 95 includes TCP/IP network support. So, if you configure the TCP/IP software on Windows 95 you should be all set to transfer files and do remote logins, for example. You can use the Microsoft provided TCP/IP utilities - such as FTP and TELNET. These aren't great utilities (their TELNET leaves a lot to be desired). But, they do work. If you wanted better Windows 95 utilities, I'd suggest checking out some commercial products. If you want NFS access to the files on the OpenVMS system, you will need a commercial product for Windows 95. Pathworks is not necessary. You can use Windows 95 PPP support to dial-up the OpenVMS system. TCPware supports PPP and it works just great with Windows 95's PPP (I use this all the time from home). Note that depending on what Windows 95 kit you got, you may need to get the Windows 95 Plus package (it was a while since I installed the "Dial-up Networking" option on Windows 95 so I forget whether this is in the base kit of requires the Plus kit). - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: XXX, 18 Sep 1996 12:00:22 GMT Subject: VMS 5.5 and TCP/IP Message-ID: <01bba558$83aed9c0$8b07e8c3@el> From: "Etienne Lacour" <100520.465@compuserve.com> Date: 18 Sep 1996 12:00:22 GMT :-? VMS 5.5 and TCP/IP I am looking for informations about the connectivity of an VMS Vax 4400 VLC on a TCP/IP network. We have to do a connection between this machine and an Unix Server via FTP services, and we can't upgrade the VMS machine. I would like to know if it exists an IP stack available on VMS 5.5, or what the version of DEC product compatible with VMS 5.5. The product of DIGITAL available runs only under 6.2 or more (it's DEC TCP/IP Services for OpenVMS Version 3.3). thank You Etienne Lacour - Bank of France. email : 100520.465@compuserve.com ================================================================================ Archive-Date: XXX, 18 Sep 1996 10:52:55 -0400 Subject: Re: VMS 5.5 and TCP/IP Message-ID: <1996Sep18.105255@process.com> From: bryant@process.com (Geoff Bryant) Date: 18 Sep 96 10:52:55 -0400 References: <01bba558$83aed9c0$8b07e8c3@el> In article <01bba558$83aed9c0$8b07e8c3@el>, "Etienne Lacour" <100520.465@compuserve.com> writes: > :-? VMS 5.5 and TCP/IP > I am looking for informations about the connectivity of an VMS Vax 4400 VLC > on a TCP/IP network. > We have to do a connection between this machine and an Unix Server via FTP > services, and we can't upgrade the VMS machine. > > I would like to know if it exists an IP stack available on VMS 5.5, or what > the version of DEC product compatible with VMS 5.5. > The product of DIGITAL available runs only under 6.2 or more (it's DEC > TCP/IP Services for OpenVMS Version 3.3). > > thank You > > Etienne Lacour - Bank of France. > email : 100520.465@compuserve.com Our product, TCPware, is a full TCP/IP stack for VMS and we do support VMS 5.5. It should certainly meet your need. Please check us out at http://www.process.com/ or send mail to info@process.com if you do not have Web access. You can receive an evaluation copy. Geoff Bryant Process Software ================================================================================ Archive-Date: XXX, 18 Sep 1996 16:27:08 GMT Subject: Re: VMS 5.5 and TCP/IP Message-ID: <51p7ss$96m@mercury.hgmp.mrc.ac.uk> From: jgreen@nimr.mrc.ac.uk (John Green) Date: 18 Sep 1996 16:27:08 GMT References: <01bba558$83aed9c0$8b07e8c3@el> Content-Type: Text/Plain; charset=US-ASCII In article <01bba558$83aed9c0$8b07e8c3@el>, 100520.465@compuserve.com says... > >I would like to know if it exists an IP stack available on VMS 5.5,.... The current version of Cisco Multinet (V4.0) is compatible with VAX/VMS 5.0 or later. See http://www.tgv.cisco.com/ for more information. In France you can find Cisco at: Cisco Systems Inc, France Internet BU Parc Evolic / Batiment L2 16 Avenue du Quebec - Villebon - BP 706 91961 Courtaboeuf Cedex France 33 1 69 18 61 85 33 1 69 28 83 26 (FAX) Sales Contact: Michel Dartois ================================================================================ Archive-Date: XXX, 18 Sep 1996 14:07:24 -0400 Subject: Re: Q: Windows 95 and TCPware for Opem VMS Message-ID: <1996Sep18.140724@process.com> From: volz@process.com (Bernie Volz) Date: 18 Sep 96 14:07:24 -0400 References: <51kdgo$238@Nntp1.mcs.net> In article <51kdgo$238@Nntp1.mcs.net>, jbarr@Mercury.mcs.com (James W. Barr) writes: > If I install TCPware on my VAX OpenVMS system and then connect a Windows 95 > based PC to the same ethernet network, using an ethernet card, can I use > Windows 95 networking functions to connect to the VAX? > > How would this be done? > > Is Pathworks necessary in this scenario? > > Also, what about the same scenario, except for using dial-up PPP? > > Any information would be GREATLY helpful and appreciated! > Windows 95 includes TCP/IP network support. So, if you configure the TCP/IP software on Windows 95 you should be all set to transfer files and do remote logins, for example. You can use the Microsoft provided TCP/IP utilities - such as FTP and TELNET. These aren't great utilities (their TELNET leaves a lot to be desired). But, they do work. If you wanted better Windows 95 utilities, I'd suggest checking out some commercial products. If you want NFS access to the files on the OpenVMS system, you will need a commercial product for Windows 95. Pathworks is not necessary. You can use Windows 95 PPP support to dial-up the OpenVMS system. TCPware supports PPP and it works just great with Windows 95's PPP (I use this all the time from home). Note that depending on what Windows 95 kit you got, you may need to get the Windows 95 Plus package (it was a while since I installed the "Dial-up Networking" option on Windows 95 so I forget whether this is in the base kit of requires the Plus kit). - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: XXX, 18 Sep 1996 14:08:02 -0400 Subject: Re: ??? NEWBIE QUESTION ??? Message-ID: <1996Sep18.140802@process.com> From: volz@process.com (Bernie Volz) Date: 18 Sep 96 14:08:02 -0400 References: <1996Aug28.150951.15954@giant> In article <1996Aug28.150951.15954@giant>, joneil@giant.intranet.com writes: > Hi, > > First of all, I'm *extremely* green in configuring networks, so please > bear with me. I'm trying to connect a PC-lan system to a VAX 3100 system > running TCPWare V5.1-4. There is a decrouter 90t connected to the > ethernet. The address of my vax is 192.9.200.60, and an > address in the lan that I'm trying to ping is 192.15.1.99. Something > tells me I need to add a ROUTE in NETCU, since the following errors > appeared on my first ping attempt: > > $ PING 192.15.1.99 > PING 192.15.1.99: 56 data bytes > sendto: no route to host > ping: wrote 192.15.1.99 64 chars, ret=-1 > sendto: no route to host > ping: wrote 192.15.1.99 64 chars, ret=-1 > > Now you would probably need more information from me, but I'm not sure what > info I should forward to you (see, I told you i was *green*). > If there's anyone out there who may have done this type of thing, > could you either email me or followup post asking for more specific > info. I would GREATLY APPRECIATE IT. First of all, if both the PC and the VAX are on the same network, you really should be using the same network number for both. In your case (assuming the default Class C network mask), but systems should be in the 192.15.1 or 192.9.200 network. This assumes a network such as the following: |---|----------------|-----------------|--------| | | | VAX PC Decrouter | |---|---------------| (other network) Now, if the router is connecting the two systems, then you need to set up a default route to tell the VAX (and the PC) to use the router whenever communicating outside of their local network (192.9.200 for the VAX and 192.15.1 for the PC). This assumes a network such as: 192.9.200 network |---|----------------------------------|--------| | | VAX DECrouter | |-------|--------------|---------------| | 192.15.1 network PC In this diagram, the DECrouter has TWO addresses - one will be 192.9.200.x and the other will be 192.15.1.y - since it is connected to both networks. For the VAX running TCPware, best is to use @TCPWARE:CNFNET to set up the default route (enter 192.9.200.x). You can also issue the NETCU SET GATEWAY 192.9.200.x command (but this will be lost when you reboot or restart TCPware unless you also add it to the TCPWARE:ROUTING.COM file. Note that x in 192.9.200.x is whatever internet address was assigned to your router at the end that is connected to the network the VAX is on. You'd also need to configure the PC to use the router - it would use a 192.15.1.y address). Configure the default router (or gateway) to be the 192.15.1.y address of the router. Hope that solves your problem. - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: XXX, 18 Sep 1996 14:09:29 -0400 Subject: Re: Vax Basic Socket Programming Message-ID: <1996Sep18.140929@process.com> From: volz@process.com (Bernie Volz) Date: 18 Sep 96 14:09:29 -0400 References: <4rubtl$qe9@news0-alterdial.uu.net> (This is a resent because it apparently never went out ... sorry about that!) In article <4rubtl$qe9@news0-alterdial.uu.net>, Kuff@Access.Digex.Net (Hal Kuff) writes: > Hi, > > Anyone done Vax Basic socket programming? Any examples? > > Hal Kuff > Kuff@tessco.com > I'd recommend using the SYS$QIO/SYS$QIOW calls directly if you can. This should be easier than dealing with the socket routines directly (and for the most part isn't that difficult to do). How to use system-services in general is documented (if I recall) in the BASIC documentation set. Another nice feature of using these is you can use the nice VMS services (such as event flags and asynchronous system traps) to do real-time event driven programming. Doing that via sockets means you have to use polling (select). Calling the socket routines from BASIC should be doable provided you understand the calling standards and how C passes arguments. C passes arguments by value and by reference. Strings are null-byte terminated and passed by reference. You also have to make sure that you allocate sufficient space for strings that return data and understand that a null-byte will terminate them. This means if you're going to use them with BASIC, you need to "fix" them up upon return (as well as before calling the routine). Access to C data structures is also possible. Perhaps using something like the MAP/REMAP statements in BASIC? Or, declaring the entire structure as a string and pulling out the various pieces (via the CVT$x functions). - Bernie Volz Process Software Corporation BTW: It has been a while since I used VAX BASIC and I never did use it much. ================================================================================ Archive-Date: XXX, 18 Sep 1996 15:11:58 -0400 Subject: Postings from Process Software to vmsnet.networks.tcp-ip.tcpware Message-ID: <1996Sep18.151158@process.com> From: bryant@process.com (Geoff Bryant) Date: 18 Sep 96 15:11:58 -0400 We have just discovered that postings from people at Process Software have apparently not been going out onto the Internet. We were not aware of the problem, as we did see all the postings internally. We will be re-posting some recent postings to try and assist those we thought we were responding to. We apologize to everyone reading the vmsnet.networks.tcp-ip.tcpware newsgroup. If you notice in the future that Process seems very quiet on this newsgroup, please let us know! ================================================================================ Archive-Date: Wed, 18 Sep 1996 19:00:41 GMT Subject: Re: VMS 5.5 and TCP/IP Message-ID: <1996Sep18.150041.1@eisner> From: bryant@eisner.decus.org (Geoff Bryant) Date: Wed, 18 Sep 1996 19:00:41 GMT References: <01bba558$83aed9c0$8b07e8c3@el> In article <01bba558$83aed9c0$8b07e8c3@el>, "Etienne Lacour" <100520.465@compuse rve.com> writes: > :-? VMS 5.5 and TCP/IP > I am looking for informations about the connectivity of an VMS Vax 4400 VLC > on a TCP/IP network. > We have to do a connection between this machine and an Unix Server via FTP > services, and we can't upgrade the VMS machine. > > I would like to know if it exists an IP stack available on VMS 5.5, or what > the version of DEC product compatible with VMS 5.5. > The product of DIGITAL available runs only under 6.2 or more (it's DEC > TCP/IP Services for OpenVMS Version 3.3). > > thank You > > Etienne Lacour - Bank of France. > email : 100520.465@compuserve.com Our product, TCPware, is a full TCP/IP stack for VMS and we do support VMS 5.5. It should certainly meet your need. Please check us out at http://www.process.com/ or send mail to info@process.com if you do not have Web access. You can receive an evaluation copy. Geoff Bryant Process Software ================================================================================ Archive-Date: XXX, 19 Sep 1996 11:52:34 -0400 Subject: Re: DHCP Server for MS Windows Clients Message-ID: <1996Sep19.115234@process.com> From: bryant@process.com (Geoff Bryant) Date: 19 Sep 96 11:52:34 -0400 References: I am re-posting this response since it seems that it did not make it out onto the net due to problems with the news server at Process. If you have already seen this, I apoligize for the duplication. Article 411 of vmsnet.networks.tcp-ip.tcpware: Relay-Version: ANU News - V6.1B9 05/16/94 VAX/VMS; site delta.process.com Path: delta.process.com!process.com!shibuya Newsgroups: vmsnet.networks.tcp-ip.tcpware Subject: Re: DHCP Server for MS Windows Clients Message-ID: <1996Sep13.163535@process.com> From: shibuya@process.com (Hiroto Shibuya) Date: 13 Sep 96 16:35:35 -0400 References: Nntp-Posting-Host: alcor.process.com Lines: 29 In article , mikewd@leica.co.uk (Mike Wilmot-Dear) writes: > I am trying to get the TCPWare DHCP server to serve (static) addresses > to MS Windows for Workgroups clients (running the MS TCP-IP 32 stack). > > Although my DHCPTAB. looks o.k. (and is correctly read in) and the > broadcasts from the PC Client are reaching the server and activating > the DHCP server. ... > faclx1: ht=ethernet: ha=00-00-E8-C7-AB-75: tc=leicanet.dummy: ip=193.128.84.49: > > thames: ht=ethernet: ha=00-00-E8-D1-B4-32: tc=leicanet.dummy: ip=193.128.84.10: > =========================================================================== > This does not work with DHCPD up to 5.1-4. To reply to DHCP request, you must have "ar" address range. To assigne a single static address to a DHCP client, you have to say something like: ar=193.128.84.49 193.18.84.49: It is stupid limitation so TCPware 5.1-5 will take your syntax as synonym to the above. You can try the patch kit DHCPD_V515P010 from our FTP server which include this enhancement and more. -- Hiroto Shibuya Process Software Corporation ================================================================================ Archive-Date: XXX, 19 Sep 1996 11:57:03 -0400 Subject: Re: ANU-NEWS Implementation onTCPware Message-ID: <1996Sep19.115703@process.com> From: bryant@process.com (Geoff Bryant) Date: 19 Sep 96 11:57:03 -0400 References: <4ucnjh$tr8@nw101.infi.net> In article <4ucnjh$tr8@nw101.infi.net>, usatlccc@ibmmail.com (Cameron C. Caffee) writes: > Does anyone have a specific list of implementation tips and techniques for > implementation on Process Software's TCPware for VAX/VMS ? > > A pointer to FAQ's etc. would also be appreciated ! > > Thanks ! > > Cameron > > usatlccc@ibmmail.com If you have purchased our Internet Server product, we provide everything you need from source to executables on the CD. Here is the initial readme for ANU news from the CD: ANU NEWS V6.1 BETA 10 This kit contains all the zip files contained in the Internet copy of ANU news from the University of Kansas. We've added two other directories called [.NEWS_BUILD_VAX] and [.NEWS_BUILD_ALPHA]. These directories contain subdirectories for the executables and objects built for each architecture, Vax and Alpha. The directory structure contained within is the correct structure for building from scratch. See the news.ps or news.txt files in the [.news_docs] for procedures. The minimum supported version for VAX is OpenVMS 5.5 and for Alpha is OpenVMS 6.1. The [.news_dist] contains template files and com procedures from the base kit. To Set up TCPware(R) for OpenVMS TCP NNTP Server and Server/Client Nodes: 1. Copy nntp_tcpwinmultinet.exe to tcpware_common:[tcpware]nntp_server.exe. 2. Make sure that the following line appears in the tcpware:services. file. nntp 119/tcp readnews # USENET News Transfer Protocol 3. Use NETCU as follows to define the service: $ RUN TCPWARE:NETCU ADD SERVICE NNTP STREAM TCPWARE:NNTP_SERVER.EXE - /PROCESS_NAME = NNTP_SERVER - /NOACCOUNTING - /NOAUTHORIZE - /UIC = [SYSTEM] - /AST_LIMIT = 50 - /BUFFER_LIMIT = 10240 - /ENQUEUE_LIMIT = 100 - /EXTENT = 1024 - /FILE_LIMIT = 50 - /IO_BUFFERED = 16 - /IO_DIRECT = 16 - /MAXIMUM_WORKING_SET = 4096 - /PAGE_FILE = 10000 - /PRIORITY = 4 - /PRIVILEGES = (NOSAME, SYSPRV, PHY_IO, NETMBX, TMPMBX, WORLD) - /QUEUE_LIMIT = 8 - /WORKING_SET = 1024 - /SUBPROCESS_LIMIT = 0 Note: Feel free to alter the quota parameters. These are just initial values. Also, you may want to add access restrictions. 4. You should also add the commands in (3) to the TCPWARE:SERVERS.COM file so that the service will be defined at subsequent TCPware startups. Hope that helps. Geoff Bryant Prcoess Software ================================================================================ Archive-Date: XXX, 19 Sep 1996 08:40:54 GMT Subject: Re: VMS 5.5 and TCP/IP Message-ID: <01bba606$59f40700$17b4e584@RULB07.leidenuniv.nl> From: "Arend Rook" Date: 19 Sep 1996 08:40:54 GMT References: <01bba558$83aed9c0$8b07e8c3@el> Etienne Lacour <100520.465@compuserve.com> wrote in article <01bba558$83aed9c0$8b07e8c3@el>... > :-? VMS 5.5 and TCP/IP > > I would like to know if it exists an IP stack available on VMS 5.5, or what > the version of DEC product compatible with VMS 5.5. > The product of DIGITAL available runs only under 6.2 or more (it's DEC > TCP/IP Services for OpenVMS Version 3.3). > > thank You > we use UCX Version 3.1 - ECO Level 7 on VMS 5.5-2. no problems -- Arend Rook system/networkmanager University Bureau of the Leiden University The Netherlands e-mail: a.rook@bvdu.leidenuniv.nl ================================================================================ Archive-Date: Fri, 20 Sep 1996 16:35:43 GMT Subject: Re: DHCP Server for MS Windows Clients Message-ID: From: mikewd@leica.co.uk (Mike Wilmot-Dear) Date: Fri, 20 Sep 1996 16:35:43 GMT References: <1996Sep19.115234@process.com> Geoff Bryant (bryant@process.com) wrote: : Article 411 of vmsnet.networks.tcp-ip.tcpware: : From: shibuya@process.com (Hiroto Shibuya) : In article , mikewd@leica.co.uk (Mike Wilmot-Dear) writes: : > Although my DHCPTAB. looks o.k. (and is correctly read in) and the : > broadcasts from the PC Client are reaching the server and activating : > the DHCP server. : > faclx1: ht=ethernet: ha=00-00-E8-C7-AB-75: tc=leicanet.dummy: ip=193.128.84.49: : > : > thames: ht=ethernet: ha=00-00-E8-D1-B4-32: tc=leicanet.dummy: ip=193.128.84.10: : > =========================================================================== : > : This does not work with DHCPD up to 5.1-4. To reply to DHCP request, : you must have "ar" address range. To assigne a single static address : to a DHCP client, you have to say something like: : ar=193.128.84.49 193.18.84.49: : It is stupid limitation so TCPware 5.1-5 will take your syntax as : synonym to the above. You can try the patch kit DHCPD_V515P010 : from our FTP server which include this enhancement and more. Thanks, I spotted the patch on your FTP site so I downloaded it on the off-chance as I'd already seen in the release notes for 5.1 (which we still haven't yet received) that some fixes had been made to DHCPD. I also did a search on that excutable for strings and found a reference to TCPWARE_DHCPD_DEBUG which I took to be the standard debug o/p enabling logical. So I defined it to be 0XFFFFFFF and hey presto a TCPWARE:DHCPDEBUG.LOG is produced each time the demon runs which includes all the info. on whats going on, what's recieved from the client and what's sent back etc. This enabled me to find the other problem with my DHCPTAB. entries in that I hadn't provided an :lt=0: field. I had assumed, incorrectly, that it would default to 0 i.e. infinite lease, but in fact the entries were just ignored. In fact I've now decided to use a finite lease time as otherwise there doesn't seem to be any way to revoke the lease except by releasing it at the client end. Given the difficulty in getting DHCP systems working initially it might be an idea to document this debug facility in the manuals. Mike. -- ------------------------------------------------------------------------------ Mike Wilmot-Dear (MW342) Network Manager Leica Cambridge Ltd. e-mail: mikewd@leica.co.uk ================================================================================ Archive-Date: Mon, 23 Sep 1996 11:31:17 -0400 Subject: Re: [Q] Port from DECnet 4 --> TCP/IP Message-ID: <3246AD45.1DE1@process.com> From: Cathy Wright Date: Mon, 23 Sep 1996 11:31:17 -0400 References: <1995Jun7.100636.1@brest> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit massol@brest wrote: > > Hi, > > We are planning to move from a DECnet 4 network to a TCP/IP one. Thus we > are planning to port some application to TCP/IP. I would like to know > from some persons who have had some experience in this domain, what are > the easiest applications to port and the most difficult ones. > Let me give you some more details; we have all the following kind of > network access : > > Transparent task-to-task applications using : > - DCL (TYPE ...) > - I/O statements in a high-level language (C, Pascal, ...) > - RMS in > - high-level language > - VAX MACRO > - System services($QIO) in > - high-level language > - VAX MACRO > > Non-transparent task-to-task applications using : > - System services($QIO) in > - high-level language > - VAX MACRO > > ... well I think we have all the possible kind of network accesses .... !! > > For all these kinds of accesses can you tell me which one are the most difficult > to port and the easiest ones. > My opinion is that non-transparent task-to-task might be the easiest to > port as it needs only translate the $QIO calls to socket ones (???) > whereas for transparent access DECnet handles everything and to port it might > need to developp additionnal code (??) > For instance with TCP/IP it doesn't seem possible to manipulate remote files > (??). > > I would appreciate any comment regarding a port from DECnet to TCP/IP, > especially an average cost (man/day) for every network access listed > above (if it is possible to evaluate it !!) ... > > Thanks very much for any information. > > Vincent Massol > > -- > -----------------------------+----------------------------------------- > Vincent Massol | Internet: massol@vaxli.enst-bretagne.fr > Ecole Nationale Superieure | Address : 37, rue de Saussure. > des Telecommunications de | 75017 Paris. France. > Bretagne. | > -----------------------------+----------------------------------------- Vincent, You can run your DECnet applications over a TCP/IP implementation such as TCPware if you upgrade your DECnet Phase IV systems to DECnet-plus (DECnet Phase V). That way no porting will be required. You can run your DECnet apps between any two VMS machines running DECnet-Plus, even if your network backbone is TCP/IP. I know your request is pretty old, but this may help for apps that haven't been ported yet. Cathy ================================================================================ Archive-Date: XXX, 22 Sep 1996 19:53:35 GMT Subject: Re: VMS 5.5 and TCP/IP Message-ID: <5245fv$mk0@niamh.indigo.ie> From: johndunn@indigo.ie (John Dunn) Date: 22 Sep 1996 19:53:35 GMT Reply-To: johndunn@indigo.ie//John.Dunn@n1.ESB.IE References: <01bba558$83aed9c0$8b07e8c3@el> In article <01bba558$83aed9c0$8b07e8c3@el>, 100520.465@compuserve.com says... > >:-? VMS 5.5 and TCP/IP >I am looking for informations about the connectivity of an VMS Vax 4400 VLC >on a TCP/IP network. >We have to do a connection between this machine and an Unix Server via FTP >services, and we can't upgrade the VMS machine. > >I would like to know if it exists an IP stack available on VMS 5.5, or what >the version of DEC product compatible with VMS 5.5. >The product of DIGITAL available runs only under 6.2 or more (it's DEC >TCP/IP Services for OpenVMS Version 3.3). > Your looking for TCPWare version5 from Process Software. They have quite a good Web page with all the info about this product. UserName=John Dunn MailAddress=johndunn@indigo.ie Organization=Indigo Navigator User ReplyTo=johndunn@indigo.ie//John.Dunn@n1.ESB.IE ================================================================================ Archive-Date: XXX, 23 Sep 1996 19:25:05 -0400 Subject: Re: VMS 5.5 and TCP/IP Message-ID: <1996Sep23.192505@process.com> From: volz@process.com (Bernie Volz) Date: 23 Sep 96 19:25:05 -0400 References: <01bba558$83aed9c0$8b07e8c3@el> <5245fv$mk0@niamh.indigo.ie> In article <5245fv$mk0@niamh.indigo.ie>, johndunn@indigo.ie (John Dunn) writes: > In article <01bba558$83aed9c0$8b07e8c3@el>, 100520.465@compuserve.com > says... >> >>:-? VMS 5.5 and TCP/IP >>I am looking for informations about the connectivity of an VMS Vax 4400 > VLC >>on a TCP/IP network. ... > > Your looking for TCPWare version5 from Process Software. They have quite > a good Web page with all the info about this product. > Since John didn't give the URL, let me ... The web page is at http://www.process.com. You can also reach us at info@process.com or call 800-722-7770 (508-879-6994). - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: XXX, 23 Sep 1996 22:00:36 GMT Subject: Re: UNIX SYSLOGD Data Message-ID: <32470884.0@nevada.kapsch.co.at> From: eplan@kapsch.co.at (Peter LANGSTOEGER) Date: 23 Sep 96 22:00:36 GMT Reply-To: eplan@kapsch.co.at References: <51c8mm$mss@nw101.infi.net> In article <51c8mm$mss@nw101.infi.net>, usatlccc@ibmmail.com (Cameron C. Caffee) writes: >Does anyone have a technique for capturing UNIX SYSLOGD data on a VAX using >TCPware ? > >Any suggestions would be appreciated ! Start with SYSLOGD on ftp.spc.edu (or ftp.wku.edu) and see if it fits your needs. (I've not done it myself, but maybe I sometime try to...) HIH ----------------------------------------------------------------------------- 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, 26 Sep 1996 12:18:25 -0400 Subject: Re: DHCP Server for MS Windows Clients Message-ID: <1996Sep26.121825@process.com> From: shibuya@process.com (Hiroto Shibuya) Date: 26 Sep 96 12:18:25 -0400 References: <1996Sep19.115234@process.com> In article , mikewd@leica.co.uk (Mike Wilmot-Dear) writes: > > In fact I've now decided to use a finite lease time as otherwise > there doesn't seem to be any way to revoke the lease except by > releasing it at the client end. > You can revoke the lease by: NETCU REMOVE DHCP -- Hiroto Shibuya Process Software Corporation ================================================================================ Archive-Date: Mon, 30 Sep 1996 15:18:37 +0100 Subject: Re: TCPware 5.1 POP3 server question Message-ID: <324FD6BD.1996@boat.bt.com> From: Greg Thomas Date: Mon, 30 Sep 1996 15:18:37 +0100 Reply-To: thomasgd@boat.bt.com References: <1996Sep26.135249.1@eisner> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Geoff Bryant Geoff Bryant wrote: ... > > He can $DEFINE/SYSTEM SYS$CLUSTER_NODE local_nodename:: > $DEFINE/SYS/EXEC TCPWARE_SMTP_FROM_DOMAIN mx_address. > > What POP3 will do is set mydomainname to what TCPWARE_SMTP_FROM_DOMAIN > is during startup. In funcion patch_from_line, it checks SYS$CLUSTER_NODE > to see if it is the same as the node:: in the From: node::username header. > If it matches, it will append mydomainname to the username. In addition, > all outgoing SMTP mail will also have the TCPWARE_SMTP_FROM_DOMAIN in the > from: header. The trouble is, SYS$CLUSTER_NODE is defined to be SVHDEV, the name of our cluster. If user A sitting on node PINKY in the cluster SVHDEV mails user B, then the mail appears to be from PINKY::A which does not match SVHDEV::A - so the reply_to: address gets mangled to a@pinky instead of a@svhdev - but pinky has no MX record (svhdev does) so the returned mail gets bounced. Any ideas? TIA, Greg -- #include ================================================================================ Archive-Date: XXX, 30 Sep 1996 17:57:45 -0400 Subject: Re: TCPware 5.1 POP3 server question Message-ID: <1996Sep30.175745@process.com> From: volz@process.com (Bernie Volz) Date: 30 Sep 96 17:57:45 -0400 References: <1996Sep26.135249.1@eisner> <324FD6BD.1996@boat.bt.com> In article <324FD6BD.1996@boat.bt.com>, Greg Thomas writes: > Geoff Bryant wrote: > ... >> >> He can $DEFINE/SYSTEM SYS$CLUSTER_NODE local_nodename:: >> $DEFINE/SYS/EXEC TCPWARE_SMTP_FROM_DOMAIN mx_address. >> >> What POP3 will do is set mydomainname to what TCPWARE_SMTP_FROM_DOMAIN >> is during startup. In funcion patch_from_line, it checks SYS$CLUSTER_NODE >> to see if it is the same as the node:: in the From: node::username header. >> If it matches, it will append mydomainname to the username. In addition, >> all outgoing SMTP mail will also have the TCPWARE_SMTP_FROM_DOMAIN in the >> from: header. > > The trouble is, SYS$CLUSTER_NODE is defined to be SVHDEV, the name of > our cluster. If user A sitting on node PINKY in the cluster SVHDEV mails > user B, then the mail appears to be from PINKY::A which does not match > SVHDEV::A - so the reply_to: address gets mangled to a@pinky instead of > a@svhdev - but pinky has no MX record (svhdev does) so the returned mail > gets bounced. > > Any ideas? > > TIA, > Greg > -- > #include Typically, you'd define SVHDEV to be the DECnet cluster alias name - which means that MAIL will send the mail from SVHDEV::user and will not bother using a DECnet link to interconnect to the cluster nodes. It's been a while since I've played with setting this up, but I believe you must make sure that bit 0 (value 1) of the MAIL$SYSTEM_FLAGS logical is set and make sure that SVHDEV is the cluster alias name. For example, in the cluster I'm on, SYS$CLUSTER_NODE is "PSC::" which is also the DECnet cluster alais name. The POP3 server knows to drop the PSC:: from the mail addresses and contructs the return address as username@PROCESS.COM. - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: Mon, 30 Sep 1996 20:01:48 GMT Subject: Re: TCPware 5.1 POP3 server question Message-ID: <1996Sep30.160148.1@eisner> From: bryant@eisner.decus.org (Geoff Bryant) Date: Mon, 30 Sep 1996 20:01:48 GMT References: <1996Sep26.135249.1@eisner> <324FD6BD.1996@boat.bt.com> In article <324FD6BD.1996@boat.bt.com>, Greg Thomas writes: > Geoff Bryant wrote: > ... >> >> He can $DEFINE/SYSTEM SYS$CLUSTER_NODE local_nodename:: >> $DEFINE/SYS/EXEC TCPWARE_SMTP_FROM_DOMAIN mx_address. >> >> What POP3 will do is set mydomainname to what TCPWARE_SMTP_FROM_DOMAIN >> is during startup. In funcion patch_from_line, it checks SYS$CLUSTER_NODE >> to see if it is the same as the node:: in the From: node::username header. >> If it matches, it will append mydomainname to the username. In addition, >> all outgoing SMTP mail will also have the TCPWARE_SMTP_FROM_DOMAIN in the >> from: header. > > The trouble is, SYS$CLUSTER_NODE is defined to be SVHDEV, the name of > our cluster. If user A sitting on node PINKY in the cluster SVHDEV mails > user B, then the mail appears to be from PINKY::A which does not match > SVHDEV::A - so the reply_to: address gets mangled to a@pinky instead of > a@svhdev - but pinky has no MX record (svhdev does) so the returned mail > gets bounced. > > Any ideas? > > TIA, > Greg > -- > #include I sent the following response to Greg via email. I am posting it for anyone else who may also have this problem: Here is the response I received about your question: If PINKY is part of the cluster and SVHDEV is the cluster alias, then PINKY should adopt the alias. You can run NCP on PINKY to see what is the characteristic of the node PINKY. Do a NCP>SHOW CHAR NODE PINKY. If there is no alias node, then on PINKY do a NCP>DEFINE EXECUTOR ALIAS NODE node-id, node-id is SVHDEV. SVHDEV must have already been defined previously. If not NCP>DEFINE NODE address NAME name. "address" is the decnet addres of SVHDEV and "name" is SVHDEV. This will update the permanent database. Use the SET command to update the volatile database.