DNS

Archive-Date: Tue, 8 Jul 2003 15:41:16 -0400 Resent-Date: Tue, 08 Jul 2003 15:36:34 -0400 Date: Tue, 08 Jul 2003 10:59:27 -0400 Resent-From: Geoff Bryant From: Morgan Lee Reply-To: Info-TCPware@process.com Subject: DNS Resent-To: info-tcpware@process.com To: info-tcpware@process.com Resent-Message-ID: <01KY0RRIIX8CA8TY4S@PROCESS.COM> Message-ID: <20030708145941.2106.qmail@mellon.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary_(ID_L/s3bSbdSZHsISN3T8seRA)" --Boundary_(ID_L/s3bSbdSZHsISN3T8seRA) Content-type: text/plain; charset=iso-8859-1 Hi I am currently running TCPWARE 5.5-3 on openVMS 7.3. I currently have approx 200 printers setup which print via IP addresses. I have been told that I need to configure my system to print using DNS. Unfortunately, I don't have a great wealth of Network experience and would appreciate some pointers with regards to configuring DNS and setting up the print queues to use DNS. The DNS servers are SUN boxes in a different location to the VMS system. Thanks in advance. Lee Morgan Mellon Site Services - Europe 71 Queen Victoria Street, London, EC4V 4DR +44 (0) 20 7653 2465 - Work +44 (0) 20 7653 2800 - Fax +44 (0) 778 892 7406 - Mobile Email: lee_morgan@newton.co.uk --Boundary_(ID_L/s3bSbdSZHsISN3T8seRA) Content-type: text/html; charset=iso-8859-1 DNS

I am currently running TCPWARE 5.5-3 on openVMS 7.3.

I currently have approx 200 printers setup which print via IP addresses.

I have been told that I need to configure my system to print using DNS.

Unfortunately, I don't have a great wealth of Network experience and would appreciate some pointers with regards to configuring DNS and setting up the print queues to use DNS.

The DNS servers are SUN boxes in a different location to the VMS system.

Thanks in advance.

Lee Morgan
Mellon Site Services - Europe
71 Queen Victoria Street, London, EC4V 4DR
+44 (0) 20 7653 2465 - Work
+44 (0) 20 7653 2800 - Fax
+44 (0) 778 892 7406 - Mobile
Email: lee_morgan@newton.co.uk

--Boundary_(ID_L/s3bSbdSZHsISN3T8seRA)-- ================================================================================ Archive-Date: Tue, 8 Jul 2003 16:19:02 -0400 Date: Tue, 08 Jul 2003 16:12:40 -0400 From: Vic Mendham Reply-To: Info-TCPware@process.com Subject: Re: DNS To: info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii It's pretty simple with Process.com software to do this. I did it 2 years ago with Multinet. I needed a patch to allow the switch from having the printers setup with IP addresses to printers using DNS names. I then went into the config and changed the printers to use the new DNS naming convention. So if your printer is located at address 1.2.3.4 and you are told it will now be known as mickey.netwon.co, simply switch the 1.2.3.4 to mickey So first I guess see if you need a patch to allow you to use DNS names with your version of TCPware. The get a list of all printers which your networking team has now decided to give DNS names to. Compare this list with all your current printers in your Tcpware (generic or otherwise) config - U might find you have a bunch of printers which are still hanging around using LAT, etc... confirm which are actually required. pick one to test with ( u might have to change some queue parameters or test actual forms with the physical printer ) when your test works, roll it out. If you have the TCPware manuals, take a look at how to setup a printer, if not, download them from the process.com site. Regards, Victor Mendham MCP, CCNP, CSS1 Technical Services Professional IBM Global Services - Canada 245 Consumers Rd. North York, Ontario Primeline - 416-490-5155 Pager - 416-329-1095 mendham@ca.ibm.com |---------+----------------------------> | | Morgan Lee | | | | | | | | | 07/08/2003 10:59 | | | AM | | | Please respond to| | | Info-TCPware | | | | |---------+----------------------------> >--------------------------------------------------------------------------------------------------------------------------| | | | To: info-tcpware@process.com | | cc: | | Subject: DNS | | | | | >--------------------------------------------------------------------------------------------------------------------------| Hi I am currently running TCPWARE 5.5-3 on openVMS 7.3. I currently have approx 200 printers setup which print via IP addresses. I have been told that I need to configure my system to print using DNS. Unfortunately, I don't have a great wealth of Network experience and would appreciate some pointers with regards to configuring DNS and setting up the print queues to use DNS. The DNS servers are SUN boxes in a different location to the VMS system. Thanks in advance. Lee Morgan Mellon Site Services - Europe 71 Queen Victoria Street, London, EC4V 4DR +44 (0) 20 7653 2465 - Work +44 (0) 20 7653 2800 - Fax +44 (0) 778 892 7406 - Mobile Email: lee_morgan@newton.co.uk ================================================================================ Archive-Date: Tue, 8 Jul 2003 16:36:54 -0400 Date: Tue, 08 Jul 2003 15:31:45 -0500 From: "Lutes, Dale" Reply-To: Info-TCPware@process.com Subject: Re: DNS To: info-tcpware@process.com Message-ID: <3F0AE3E1.786B5DC3@cessna.textron.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20030708145941.2106.qmail@mellon.com> Morgan, First, you will need the IP addresses of your SUN DNS servers. Next, @TCPWARE:CNFNET DNS to change the configuration. You want to enable DNS Client support (NOT server support). CNFNET will ask you for the IP addresses of your servers. Enter them as in the example. Once you have finished and restarted DNS, edit your TCPWARE:TCPWARE_CONFIGURE.COM file and replace the hard-coded IP addresses with the printer names. @TCPWARE:RESTART DNS will finish the process. Good luck. -- Dale D. Lutes ______ Cessna Aircraft Company / ___/_____ _____ _____ ______ ______ One Cessna Boulevard / / / <> // __// __// __ // / Wichita, KS 67215 / /__ / ___//__ //__ // / / // <> / 316-517-7109 /_____//____//____//____//_/ /_//___/_/ ================================================================================ Archive-Date: Tue, 8 Jul 2003 17:41:32 -0400 Date: Tue, 08 Jul 2003 17:36:54 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com Subject: Re: DNS To: info-tcpware@process.com Message-ID: <01KY0VNV8QXEA904JN@PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii "Lutes, Dale" writes: > >First, you will need the IP addresses of your SUN DNS servers. >Next, @TCPWARE:CNFNET DNS to change the configuration. You >want to enable DNS Client support (NOT server support). > The question I believe is in regards to pointing his print queues at the printers by name rather than IP address. I'm going to assume that the user has the DNS resolver configured. However if that is not the case, then follow the steps that Dale provided. Providing that you have the DNS resolver setup, and you have A records in the DNS on the SUN systems that map names to the IP addresses of the printers in question, then you just need to change the printer configuration to refer to the printers by name rather than IP address. If you do not have DNS entries for the printers, you'll need to add those in the DNS servers on the Sun boxes. The issue with Multinet referenced by another user was a problem specific to the Multinet product. It was just a case that Multinet wasn't designed to handle hostnames in the printer configuration. Once it was brought to our attention it was quickly handled... that's the patch the other customer was referring to. I wanted to set that straight so there wasn't any more confusion. So Basically: 1) Check to make sure your DNS resolver is configured on the TCPware system. 2) Check and make sure there are mappings for the names you want to use. Step one and two is easy to do all at once with simply: $ nslookup If you get it's IP address back as a response, then your resolver is configured and the name to address mapping works for that system. Then 3) is to change the printer config to refer to it by that name rather than the IP address. -Jeff Schreiber -- Jeff Schreiber Principal Software Engineer Process Software LLC schreiber@mx.process.com http://www.process.com TCPware, MultiNet & PMDF: Stronger than Ever ================================================================================ Archive-Date: Tue, 8 Jul 2003 23:09:00 -0400 Date: Tue, 08 Jul 2003 21:48:15 -0500 From: "David J. Dachtera" Subject: Re: SNMP Commands (was Re: How do I monitor the CPU temperature i n an ES40 running OpenVMS 7.3-1? an ES40 running OpenVMS 7.3-1? a n ES40 running OpenVMS 7.3-1? an ES40 running OpenVMS 7.3-1? an ES40 running OpenVMS 7.3-1? a n ES40 running OpenVMS 7.3-1? an ES40 running OpenVMS 7.3-1? an ES40 running OpenVMS 7.3-1? a n ES40 running OpenVMS 7.3-1? To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <3F0B826F.1D030184@fsi.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Richard Whalen wrote: > > The information below should be documented; and is supported. It was > contained in the MultiNet 4.3 release notes, but I was not able to find the > information about the trap_gen program in the MultiNet 4.4 manual set. I've > sent email to the various people involved to hopefully get it included in > the next manual set. Likewise for TCPware. My ISP has it on the server where I have my telnet account, and there's TRAP_GEN.EXE in the TCPWARE: path. -- David J. Dachtera dba DJE Systems http://www.djesys.com/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ ================================================================================ Archive-Date: Sun, 20 Jul 2003 02:06:22 -0400 Date: Sun, 20 Jul 2003 15:17:31 +0930 From: Jeremy Begg Reply-To: Info-TCPware@process.com Subject: Will decc$get_sdc() work with MultiNet & TCPware? To: info-multinet@process.com, info-tcpware@process.com CC: jeremy@vsm.com.au Message-ID: <01KYHJ2HPBCS90MWZR@vsm.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Hi, I'm working on a TCP client program which uses the standard DECC$RTL sockets interface. Program development is being done on an Alphastation 255/300 running OpenVMS V7.3 and TCP/IP Services 5.1. The "server" with which this program communicates is an ethernet/serial interface board made by Moxa Technologies. Extensive testing has shown that after an hour or so of continuous running the Moxa board seems to lose track of the TCP session information. It either ACKs an earlier packet from the VMS host (i.e. not the last one sent) or resends an earlier response (i.e. one which the VMS host has already ACKed). VMS and the Moxa then engage in a lengthy series of retries which eventually result in the VMS recv() routine returning ETIMEDOUT about nine minutes after calling recv(). I ran my program on a different system which has MultiNet installed, and this problem did not surface. However, the location of that machine meant the network topology was slightly different so I'm doubtful that the failure is due to TCP/IP Services vs MultiNet. (And besides, if it *was* a TCP/IP Services fault, I would expect to see similar behaviour in other applications.) I've decided to work aournd this problem by wrapping the network I/O with my own timeout, as follows: $SETIMR send() recv() $CANTIM If the timer AST is fired, it will $CANCEL the network I/O. For this to work, the program needs to know the VMS I/O channel corresponding to the TCP socket. The DECC$RTL provides a routine, decc$get_sdc(), which returns the VMS I/O channel for an open socket. This routine is written for an program running under TCP/IP Services for OpenVMS; will it return the correct information when the program is running on a system with MultiNet or TCPware? Thanks, Jeremy Begg +---------------------------------------------------------+ | VSM Software Services Pty. Ltd. | | http://www.vsm.com.au/ | | "OpenVMS Systems Management & Programming" | |---------------------------------------------------------| | P.O.Box 402, Walkerville, | E-Mail: jeremy@vsm.com.au | | South Australia 5081 | Phone: +61 8 8221 5188 | |---------------------------| Mobile: 0414 422 947 | | A.C.N. 068 409 156 | FAX: +61 8 8221 7199 | +---------------------------------------------------------+ ================================================================================ Archive-Date: Sun, 20 Jul 2003 10:23:38 -0400 Date: Sun, 20 Jul 2003 10:18:39 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com Subject: Re: Will decc$get_sdc() work with MultiNet & TCPware? To: info-tcpware@process.com Message-ID: <01KYH8640JDQA8VJUI@PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii jeremy, That should work fine. Geoff On Sun, 20 Jul 2003 15:17:31 +0930, Jeremy Begg wrote: > >Hi, > >I'm working on a TCP client program which uses the standard DECC$RTL sockets >interface. Program development is being done on an Alphastation 255/300 >running OpenVMS V7.3 and TCP/IP Services 5.1. The "server" with which this >program communicates is an ethernet/serial interface board made by Moxa >Technologies. > >Extensive testing has shown that after an hour or so of continuous running >the Moxa board seems to lose track of the TCP session information. It >either ACKs an earlier packet from the VMS host (i.e. not the last one sent) >or resends an earlier response (i.e. one which the VMS host has already >ACKed). VMS and the Moxa then engage in a lengthy series of retries which >eventually result in the VMS recv() routine returning ETIMEDOUT about nine >minutes after calling recv(). > >I ran my program on a different system which has MultiNet installed, and >this problem did not surface. However, the location of that machine meant >the network topology was slightly different so I'm doubtful that the failure >is due to TCP/IP Services vs MultiNet. (And besides, if it *was* a TCP/IP >Services fault, I would expect to see similar behaviour in other >applications.) > >I've decided to work aournd this problem by wrapping the network I/O with >my own timeout, as follows: > > $SETIMR > send() > recv() > $CANTIM > >If the timer AST is fired, it will $CANCEL the network I/O. For this to >work, the program needs to know the VMS I/O channel corresponding to the >TCP socket. > >The DECC$RTL provides a routine, decc$get_sdc(), which returns the VMS I/O >channel for an open socket. This routine is written for an program running >under TCP/IP Services for OpenVMS; will it return the correct information >when the program is running on a system with MultiNet or TCPware? > >Thanks, > > Jeremy Begg > > +---------------------------------------------------------+ > | VSM Software Services Pty. Ltd. | > | http://www.vsm.com.au/ | > | "OpenVMS Systems Management & Programming" | > |---------------------------------------------------------| > | P.O.Box 402, Walkerville, | E-Mail: jeremy@vsm.com.au | > | South Australia 5081 | Phone: +61 8 8221 5188 | > |---------------------------| Mobile: 0414 422 947 | > | A.C.N. 068 409 156 | FAX: +61 8 8221 7199 | > +---------------------------------------------------------+ ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/MultiNet/PMDF/SSH Engineering Process Software http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Mon, 21 Jul 2003 10:07:24 -0400 Date: Mon, 21 Jul 2003 09:36:21 -0400 (EDT) From: Ira Melamed - Database Administrator Reply-To: Info-TCPware@process.com Subject: Purveyor and VMS 7.3-1 To: info-tcpware@process.com CC: MELAMEIS@FARMINGDALE.EDU Message-ID: <01KYILVTOD1Q8ZDWD1@FARMINGDALE.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii I sent a message last week to info-vax (included below) and did not receive any replies, hope someone on this list is still using the "unsupported" Purveyor webserver and can help. I can't figure out what, but "something" changed with an upgrade to VMS 7.3-1. We are using Purveyor to authenticate against our UAF file. As of the 7.3-1 upgrade, it fails to authenticate usernames of eight or more characters. I don't see the problem when I run Purveyor on a 7.2 node of our VMS cluster. If anyone has a copy of the .c source code for a working authentication routine, on any version of vms, I would appreciate it if you could share it with us. This would be the code that is compiled as a .dll, similar to the sample_auth.c file that is included in the Purveyor package. Thanks in advance to anyone who can assist... im =============================================================================== Date: Tue, 15 Jul 2003 09:36:47 -0400 (EDT) From: Ira Melamed - Database Administrator Subject: Purveyor and VMS 7.3-1 To: INFO-VAX@LISTSERV.UGA.EDU Cc: MELAMEIS@FARMINGDALE.EDU Having a problem with Purveyor and user authentication since upgrading to VMS 7-3.1. We have been using the rights identifier method of authentication for years. Now it looks like usernames of eight characters or more fail to authenticate, We use the sample_auth.c supplied by Process Software. I tried to recompile the source and received this informational warning: $ @sample_auth { strlen(groupname), DSC$K_DTYPE_T, DSC$K_CLASS_S, groupname }; ..................^ %CC-I-INTRINSICINT, In this statement, the return type for intrinsic "strlen" is being changed from "size_t" to "int". at line number 206 in file DSA1:[PURVEYOR.SAMPLES.SCRIPTS.DLL]SAMPLE_AUTH.C;4 SAMPLE_AUTH_AXP.DLL built. I am not a competent C programmer. Can anyone tell me if this message could be related to our problem...and maybe suggest a fix! If this does not look like the problem area - what could have changed in VMS 7.3-1 (upgraded from 7.2) that could cause this type of problem? Thanks in advance, for any suggestions... im dba dba dba dba dba dba dba dba dba dba dba dba dba dba dba dba dba dba o Ira Melamed o o r Database Administrator r Email: MELAMEIS@FARMINGDALE.EDU r a Farmingdale State a a c University of New York c Phone: (631) 420-2415 c l Whitman Hall - Room 267 l l e Farmingdale, New York 11735 e Fax : (631) 420-2696 e dba dba dba dba dba dba dba dba dba dba dba dba dba dba dba dba dba dba ================================================================================ Archive-Date: Fri, 25 Jul 2003 17:41:17 -0400 Date: Fri, 25 Jul 2003 17:36:15 -0400 From: bradhamilton Reply-To: Info-TCPware@process.com Subject: finger To: info-tcpware@process.com Message-ID: <3F21A2CF.8060700@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, (TCPWare V5.6-2, all level 0-2 patches applied) Is there any syntax help for FINGER? HELP FINGER is no help :-) (it's a "leftover" from a previous TCP/IP Services installation), and "finger ?", "finger -h", etc. show nothing. "Finger asjlaknslk" returns "correct usage: finger user@node". Are there no other options, switches, qualifiers? Nothing seen in the documentation... TIA ================================================================================ Archive-Date: Fri, 25 Jul 2003 18:11:52 -0400 Date: Fri, 25 Jul 2003 17:01:03 -0500 (CDT) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: Re: finger In-Reply-To: "Your message dated Fri, 25 Jul 2003 17:36:15 -0400" <3F21A2CF.8060700@comcast.net> To: info-tcpware@process.com Message-ID: <01KYOLV96SX28WW0CU@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed > (TCPWare V5.6-2, all level 0-2 patches applied) > Is there any syntax help for FINGER? HELP FINGER is no help :-) > (it's a "leftover" from a previous TCP/IP Services installation), and > "finger ?", "finger -h", etc. show nothing. "Finger asjlaknslk" returns > "correct usage: finger user@node". Are there no other options, > switches, qualifiers? Nothing seen in the documentation... No, there's nothing else to it. It's a very small, simple program. The source for it can be found in TCPWARE_ROOT:[TCPWARE.EXAMPLES]FINGER.C. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Thu, 31 Jul 2003 20:28:24 -0400 Date: Thu, 31 Jul 2003 19:22:09 -0500 (CDT) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: Process.com power outage Friday & Saturday To: TCPware-Announce@lists.process.com Message-ID: <01KYX4D5YSJG8WW01M@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii The Process Software office building will be undergoing some electrical work on Saturday that will result in a 24-hour shutdown of all of our computer systems (and the phone system). Everything is scheduled to be shut down at 7 PM EDT on Friday, August 1, 2003. Hopefully, everything will be back online at 7 PM EDT on Saturday, August 2, 2003. This means that www.process.com, the FTP sites, the mailing lists, etc., will all be inaccessible during that 24-hour period. We apologize for any inconvenience, but if you heard the *very* loud buzzing of the transformer in the electrical room, you'd want it replaced too! ;-) Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Thu, 31 Jul 2003 21:54:04 -0400 Date: Thu, 31 Jul 2003 20:48:25 -0500 From: "Wiens, Art (CITG)" Reply-To: Info-TCPware@process.com Subject: RE: Process.com power outage Friday & Saturday To: "'Info-TCPware@process.com'" Message-ID: <7FFD07791928174DAB97CB4C70F61BFC02774518@wpg-exchange.cgs.globaltv.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 > -----Original Message----- > From: Hunter Goatley [mailto:goathunter@goatley.com] > Subject: Process.com power outage Friday & Saturday Good Luck! Sincerely, Art Wiens Technical Specialist - VMS CanWest Information Technology Group Email: awiens@canwest.com Post : 6th Floor - 300 Carlton Street Winnipeg, Manitoba, Canada R3B 2K6