RE: TCPIP IVP File?

Archive-Date: Tue, 8 Oct 2002 10:46:39 -0400 Date: Tue, 08 Oct 2002 10:44:45 -0400 From: "Harsha, J" Reply-To: Info-TCPware@process.com Subject: TCPIP IVP File? Sender: Geoff Bryant To: "'info-tcpware@process.com'" Message-ID: <177E503C4DA3D311BC9D0008C791C3060AE4B55C@diexch01.xko.dec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary_(ID_lkkFq3A+iFthrSPdPl+q3w)" --Boundary_(ID_lkkFq3A+iFthrSPdPl+q3w) Content-type: text/plain; charset=iso-8859-1 Hi All, I would like to know that is there any file (an EXE or a COM file) which tests the TCP/IP working after TCPWARE product is installed? i.e. Is there any IVP file which can be used for testing the TCPWARE's TCPIP working? and what all needs to be tested to check whether the TCPWARE's TCPIP is installed? If there is any file which does this, please specify the path with the file name. and suppose if no such file exists, then how the commands needs to be tested for TCPIP working? It will be very helpful if I get an earlier response. Thanks in advance & Regards, Harsha --Boundary_(ID_lkkFq3A+iFthrSPdPl+q3w) Content-type: text/html; charset=iso-8859-1

Hi All,

I would like to know that is there any file (an EXE or a COM file) which tests the TCP/IP working after TCPWARE product is installed? i.e. Is there any IVP file which can be used for testing the TCPWARE's TCPIP working? and what all needs to be tested to check whether the TCPWARE's TCPIP is installed?

If there is any file which does this, please specify the path with the file name.

and suppose if no such file exists, then how the commands needs to be tested for TCPIP working?

It will be very helpful if I get an earlier response.

Thanks in advance & Regards,

Harsha

--Boundary_(ID_lkkFq3A+iFthrSPdPl+q3w)-- ================================================================================ Archive-Date: Tue, 8 Oct 2002 11:05:26 -0400 Date: Tue, 08 Oct 2002 11:05:19 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: Re: TCPIP IVP File? To: info-tcpware@process.com Message-ID: <3DA2F42F.8000807@process.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit References: <177E503C4DA3D311BC9D0008C791C3060AE4B55C@diexch01.xko.dec.com> Harsha, J wrote: > Hi All, > > I would like to know that is there any file (an EXE or a COM file) > which tests the TCP/IP working after TCPWARE product is installed? i.e. > Is there any IVP file which can be used for testing the TCPWARE's TCPIP > working? and what all needs to be tested to check whether the TCPWARE's > TCPIP is installed? > > > > If there is any file which does this, please specify the path with the > file name. > > > > and suppose if no such file exists, then how the commands needs to be > tested for TCPIP working? > > > > It will be very helpful if I get an earlier response. > > There is no IVP for TCPware. Perform basic test such has pinging another system on the same subnet. Ping something on another subnet if you have a default route configured. Try to establish connections to the services you've enabled. regards Mike -- +-------------------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Wed, 9 Oct 2002 19:13:22 -0400 Date: Wed, 09 Oct 2002 19:11:23 -0400 From: "Harsha, J" Reply-To: Info-TCPware@process.com Subject: RE: TCPIP IVP File? Sender: Geoff Bryant To: "'Info-TCPware@process.com'" Message-ID: <177E503C4DA3D311BC9D0008C791C3060AE4B581@diexch01.xko.dec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary_(ID_t6RMnU6Q7+wIRmT98RRoqg)" --Boundary_(ID_t6RMnU6Q7+wIRmT98RRoqg) Content-type: text/plain; charset=iso-8859-1 Hi Mike, Thanks for the information. Since we don't have the TCPWARE's TCPIP installed on any of our machine, we are finding it difficult to write the code to check the working of the TCPWARE's TCPIP. Can you please provide with the following information or give me the steps with the commands and output, which tests the TCPWARE's TCPIP? I wanted to know how to check the TCPIP installed or not on the machine? will it be installed using PCSI? What are the commands for pinging and what is the output when it is working and when it is not working? Since I don't know the commands for pinging using TCPWARE's TCPIP, I m finding difficult to test for its working. or is there any other way to check? Thanks in advance, Harsha -----Original Message----- From: Michael Corbett [mailto:corbett@process.com] Sent: Tuesday, October 08, 2002 8:35 PM To: info-tcpware@process.com Subject: Re: TCPIP IVP File? Harsha, J wrote: > Hi All, > > I would like to know that is there any file (an EXE or a COM file) > which tests the TCP/IP working after TCPWARE product is installed? i.e. > Is there any IVP file which can be used for testing the TCPWARE's TCPIP > working? and what all needs to be tested to check whether the TCPWARE's > TCPIP is installed? > > > > If there is any file which does this, please specify the path with the > file name. > > > > and suppose if no such file exists, then how the commands needs to be > tested for TCPIP working? > > > > It will be very helpful if I get an earlier response. > > There is no IVP for TCPware. Perform basic test such has pinging another system on the same subnet. Ping something on another subnet if you have a default route configured. Try to establish connections to the services you've enabled. regards Mike -- +-------------------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 --Boundary_(ID_t6RMnU6Q7+wIRmT98RRoqg) Content-type: text/html; charset=iso-8859-1 RE: TCPIP IVP File?

Hi Mike,
Thanks for the information. Since we don't have the TCPWARE's TCPIP installed on any of our machine, we are finding it difficult to write the code to check the working of the TCPWARE's TCPIP.

Can you please provide with the following information or give me the steps with the commands and output, which tests the TCPWARE's TCPIP?

I wanted to know
how to check the TCPIP installed or not on the machine? will it be installed using PCSI?
What are the commands for pinging and what is the output when it is working and when it is not working?

Since I don't know the commands for pinging using TCPWARE's TCPIP, I m finding difficult to test for its working.

or is there any other way to check?

Thanks in advance,
Harsha

-----Original Message-----
From: Michael Corbett [mailto:corbett@process.com]
Sent: Tuesday, October 08, 2002 8:35 PM
To: info-tcpware@process.com
Subject: Re: TCPIP IVP File?

Harsha, J wrote:

> Hi All,
>
> I would like to know that is there any file (an EXE or a COM file)
> which tests the TCP/IP working after TCPWARE product is installed? i.e.
> Is there any IVP file which can be used for testing the TCPWARE's TCPIP
> working? and what all needs to be tested to check whether the TCPWARE's
> TCPIP is installed?
>
>
>
> If there is any file which does this, please specify the path with the
> file name.
>
>
>
> and suppose if no such file exists, then how the commands needs to be
> tested for TCPIP working?
>
>
>
> It will be very helpful if I get an earlier response.
>
>

There is no IVP for TCPware. Perform basic test such has pinging
another system on the same subnet. Ping something on another subnet
if you have a default route configured. Try to establish connections
to the services you've enabled.

regards
Mike

--
+-------------------------------------------------------------------------+
Michael Corbett                           Email: Corbett@process.com
Process Software                          Phone: 800 722-7770 x369
959 Concord St.                                  508 879-6994 x369
Framingham MA 01701-4682                  FAX:   508 879-0042

--Boundary_(ID_t6RMnU6Q7+wIRmT98RRoqg)-- ================================================================================ Archive-Date: Fri, 11 Oct 2002 03:16:24 -0400 Date: Fri, 11 Oct 2002 09:19:15 +0200 From: Godfrey Pillay Reply-To: Info-TCPware@process.com Subject: OKI Printers on IP To: info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi I am currently experiencing problems with the OKI printers (model 395) that are configured via TCPWare. These printers are connected via JET Direct cards. The printers seems to have problems with flow control and form feeds and some page settings. This is an example of a printer configuration. Please let me know if I have missed something out. $ QUEUE = "NEWFIN001" $ INITIALIZE /QUEUE /START/ON="ip address,9100" - /PROC=TCPWARE_TSSYM /NOBLOCK_LIMIT - /DEFAULT=(FEED,FORM=A4FORM) /PROTECTION=(S:M,O:D,G:R,W:SM) 'QUEUE' This is an example of a form setup: Form name Number Description --------- ------ ----------- A4FORM (stock=DEFAULT) 1 A4 Stationery /LENGTH=66 /STOCK=DEFAULT /TRUNCATE /WIDTH=132 I am using VAX/VMS version 7.2 on a VAX 4000 model 105 with TCPWare V5.3-2 . An urgent response will be appreciated... Regards Godfrey Pillay SAB - AOM Location: IBM Park Sandton, IA2G Tel: (011) 302-6310 Fax: (011) 302-6592 Cell: 082 823-5339 E-mail: gpillay@za.ibm.com ================================================================================ Archive-Date: Fri, 11 Oct 2002 08:19:54 -0400 Date: Fri, 11 Oct 2002 09:33:03 -0400 (EDT) From: Gary Reynolds Reply-To: Info-TCPware@process.com Subject: Re: OKI Printers on IP In-Reply-To: To: Godfrey Pillay CC: info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Godfrey, I don't use Jet Direct cards but I have worked with the Okidata 320/390 printers. A couple of questions come to mind ... 1. Did the printers ever work OK? Is this a fairly recent problem related to anything else ? 2. Did you get, and can you post a MENU - PRINT SETTINGS for the OKI 395 from the OKi's control panel. 3. I am not real familiar with the Jet Direct cards -- do they plug directly in from the Network line to the printer? Are they Serial or Parallel type ? 4. Do the Jet Direct cards have a Setup configuration that you can post ? Sorry not to be more helpful, but that's where I would start. Gary Reynolds Waynesburg College On Fri, 11 Oct 2002, Godfrey Pillay wrote: > Hi > > I am currently experiencing problems with the OKI printers (model 395) > that are configured via TCPWare. These printers are connected via JET > Direct cards. The printers seems to have problems with flow control and > form feeds and some page settings. > > This is an example of a printer configuration. Please let me know if I have > missed something out. > > > $ QUEUE = "NEWFIN001" > $ INITIALIZE /QUEUE /START/ON="ip address,9100" - > /PROC=TCPWARE_TSSYM /NOBLOCK_LIMIT - > /DEFAULT=(FEED,FORM=A4FORM) /PROTECTION=(S:M,O:D,G:R,W:SM) 'QUEUE' > > > This is an example of a form setup: > > Form name Number Description > --------- ------ ----------- > A4FORM (stock=DEFAULT) 1 A4 Stationery > /LENGTH=66 /STOCK=DEFAULT /TRUNCATE /WIDTH=132 > > > I am using VAX/VMS version 7.2 on a VAX 4000 model 105 with TCPWare V5.3-2 > . > > An urgent response will be appreciated... > > Regards > > Godfrey Pillay > SAB - AOM > Location: IBM Park Sandton, IA2G > Tel: (011) 302-6310 Fax: (011) 302-6592 > Cell: 082 823-5339 E-mail: gpillay@za.ibm.com > > > ================================================================================ Archive-Date: Fri, 11 Oct 2002 08:41:24 -0400 Date: Fri, 11 Oct 2002 14:44:19 +0200 From: Godfrey Pillay Reply-To: Info-TCPware@process.com Subject: Re: OKI Printers on IP To: info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Gary These printers were configured previously using the LAT protocol running thru a Dec Server 90tl. The Lat configuration allows us to use a terminal type device and this terminal device can have the characteristics set. eg communication settings (speed,parity etc) and also the XON/XOFF flow control. With the IP configuration, there seems to be no device to set and I suppose the printer settings is important in this case. I do not know much about the Jet Direct card itself. All I am aware off is that this device plugs directly on the LAN and has its IP address,subnet etc configured on it. All the IP configuration does is that it prints to an IP address and port number. The printer is obviously connected to this port. I am going on site on Monday to check the printer settings and I will learn more about these Jet cards. I just thought that I might get some pointers before I go to site. Regards Godfrey Pillay SAB - AOM Location: IBM Park Sandton, IA2G Tel: (011) 302-6310 Fax: (011) 302-6592 Cell: 082 823-5339 E-mail: gpillay@za.ibm.com Gary Reynolds cc: info-tcpware@process.com Subject: Re: OKI Printers on IP 10/11/2002 03:33 PM Please respond to Info-TCPware Godfrey, I don't use Jet Direct cards but I have worked with the Okidata 320/390 printers. A couple of questions come to mind ... 1. Did the printers ever work OK? Is this a fairly recent problem related to anything else ? 2. Did you get, and can you post a MENU - PRINT SETTINGS for the OKI 395 from the OKi's control panel. 3. I am not real familiar with the Jet Direct cards -- do they plug directly in from the Network line to the printer? Are they Serial or Parallel type ? 4. Do the Jet Direct cards have a Setup configuration that you can post ? Sorry not to be more helpful, but that's where I would start. Gary Reynolds Waynesburg College On Fri, 11 Oct 2002, Godfrey Pillay wrote: > Hi > > I am currently experiencing problems with the OKI printers (model 395) > that are configured via TCPWare. These printers are connected via JET > Direct cards. The printers seems to have problems with flow control and > form feeds and some page settings. > > This is an example of a printer configuration. Please let me know if I have > missed something out. > > > $ QUEUE = "NEWFIN001" > $ INITIALIZE /QUEUE /START/ON="ip address,9100" - > /PROC=TCPWARE_TSSYM /NOBLOCK_LIMIT - > /DEFAULT=(FEED,FORM=A4FORM) /PROTECTION=(S:M,O:D,G:R,W:SM) 'QUEUE' > > > This is an example of a form setup: > > Form name Number Description > --------- ------ ----------- > A4FORM (stock=DEFAULT) 1 A4 Stationery > /LENGTH=66 /STOCK=DEFAULT /TRUNCATE /WIDTH=132 > > > I am using VAX/VMS version 7.2 on a VAX 4000 model 105 with TCPWare V5.3-2 > . > > An urgent response will be appreciated... > > Regards > > Godfrey Pillay > SAB - AOM > Location: IBM Park Sandton, IA2G > Tel: (011) 302-6310 Fax: (011) 302-6592 > Cell: 082 823-5339 E-mail: gpillay@za.ibm.com > > > ================================================================================ Archive-Date: Fri, 11 Oct 2002 08:51:38 -0400 Date: Fri, 11 Oct 2002 08:50:39 -0400 From: "Robert, Andrew" Reply-To: Info-TCPware@process.com Subject: RE: OKI Printers on IP To: "'Info-TCPware@process.com'" Message-ID: <0555B6986D9BD411843B00E009000004081FDDBC@perseus.mfs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit If you would like to retain the same time of control as you did under LAT, I recommend you use NTY port configurations. An example of this would be the following script. Please note that the script creates both execution and generic queues for easier management across multi-node clusters. The script is designed for Multinet but I am sure you can adapt it for TCPware. $! START_IP_PRINTERS.COM $! $! CREATED 10-15-98 $! AUTHOR: ANDREW ROBERT $! $! FUNCTION: TO CREATE MULTINET NTY QUEUES USING A SUPPLIED DATA FILE $! $ SET NOON $! $ ON ERROR THEN CONTINUE $! $! SET VERIFY $! $ CLOSE/NOLOG PRINTERS $! $! $! DEFINE SYMBOLS FOR PROCEDURE $! $ NODENAME = F$GETSYI("NODENAME") $ PRINTER_FILE1 = "SYSTEMS__COM:CLUSTER_PRINTERS.DAT" $ NTYCP := $MULTINET:NTYCP $ NTY_PORT=6000 $! $!CREATE GENERIC AND EXECUTION QUEUES $! $! $! $ OPEN/READ/SHARE PRINTERS 'PRINTER_FILE1' $! $ READ_LOOP: $! $ READ/END=CLOSE PRINTERS PRINTER_DATA1 $! $ QNAM = F$ELEMENT(0,"/",PRINTER_DATA1) $ QUEUE_ADDR = F$ELEMENT(1,"/",PRINTER_DATA1) $! $ WRITE SYS$OUTPUT " " $ WRITE SYS$OUTPUT "CREATING QUEUE ''QNAM' ON NTY PORT ''NTY_PORT' " $ WRITE SYS$OUTPUT " " $! $ NTYCP CREATE PORT NTY'NTY_PORT' /NODE='QNAM'.MFS.COM/PORT=9100 $! $ SET TERMINAL NTY'NTY_PORT' - /WIDTH=255 /PAGE=66 - /NOBROADCAST /NOTAB /NOWRAP - /SCOPE /AUTOBAUD /NOHOSTSYNC /FORM /NOECHO - /NOPASTHRU /PERM $! $ ON ERROR THEN CONTINUE $! $ INITIALIZE /QUEUE /START /PROCESSOR=MULTINET_NTYSMB - /NORETAIN=ERROR /RECORD_BLOCKING - /LIB=HP5LASERJET /SEPARATE=(RESET=(RESET)) - /DEFAULT=(NOBURST,NOTRAILER,NOFLAG,NOFEED) - /ON=NTY'NTY_PORT': 'NODENAME'_'QNAM' $! $ ON ERROR THEN CONTINUE $! $ INIT/QUE/START 'QNAM' /GENERIC=('NODENAME'_'QNAM') $! $ ON ERROR THEN CONTINUE $! $ NTY_PORT='NTY_PORT'+1 $! $ GOTO READ_LOOP $! $! $ CLOSE: $! $ ON ERROR THEN CONTINUE $! $ CLOSE PRINTERS $! $! $ EXIT The printer data file would contain a list of printers you would like created based on their DNS entry. If you wanted to set up the printer laser.mydomain.com, the file would contain the entry laser. Thanks, Andrew Robert Principal Systems Analyst Massachusetts Financial Services -----Original Message----- From: Godfrey Pillay [mailto:gpillay@za.ibm.com] Sent: Friday, October 11, 2002 8:44 AM To: info-tcpware@process.com Subject: Re: OKI Printers on IP Gary These printers were configured previously using the LAT protocol running thru a Dec Server 90tl. The Lat configuration allows us to use a terminal type device and this terminal device can have the characteristics set. eg communication settings (speed,parity etc) and also the XON/XOFF flow control. With the IP configuration, there seems to be no device to set and I suppose the printer settings is important in this case. I do not know much about the Jet Direct card itself. All I am aware off is that this device plugs directly on the LAN and has its IP address,subnet etc configured on it. All the IP configuration does is that it prints to an IP address and port number. The printer is obviously connected to this port. I am going on site on Monday to check the printer settings and I will learn more about these Jet cards. I just thought that I might get some pointers before I go to site. Regards Godfrey Pillay SAB - AOM Location: IBM Park Sandton, IA2G Tel: (011) 302-6310 Fax: (011) 302-6592 Cell: 082 823-5339 E-mail: gpillay@za.ibm.com Gary Reynolds cc: info-tcpware@process.com Subject: Re: OKI Printers on IP 10/11/2002 03:33 PM Please respond to Info-TCPware Godfrey, I don't use Jet Direct cards but I have worked with the Okidata 320/390 printers. A couple of questions come to mind ... 1. Did the printers ever work OK? Is this a fairly recent problem related to anything else ? 2. Did you get, and can you post a MENU - PRINT SETTINGS for the OKI 395 from the OKi's control panel. 3. I am not real familiar with the Jet Direct cards -- do they plug directly in from the Network line to the printer? Are they Serial or Parallel type ? 4. Do the Jet Direct cards have a Setup configuration that you can post ? Sorry not to be more helpful, but that's where I would start. Gary Reynolds Waynesburg College On Fri, 11 Oct 2002, Godfrey Pillay wrote: > Hi > > I am currently experiencing problems with the OKI printers (model 395) > that are configured via TCPWare. These printers are connected via JET > Direct cards. The printers seems to have problems with flow control and > form feeds and some page settings. > > This is an example of a printer configuration. Please let me know if I have > missed something out. > > > $ QUEUE = "NEWFIN001" > $ INITIALIZE /QUEUE /START/ON="ip address,9100" - > /PROC=TCPWARE_TSSYM /NOBLOCK_LIMIT - > /DEFAULT=(FEED,FORM=A4FORM) /PROTECTION=(S:M,O:D,G:R,W:SM) 'QUEUE' > > > This is an example of a form setup: > > Form name Number Description > --------- ------ ----------- > A4FORM (stock=DEFAULT) 1 A4 Stationery > /LENGTH=66 /STOCK=DEFAULT /TRUNCATE /WIDTH=132 > > > I am using VAX/VMS version 7.2 on a VAX 4000 model 105 with TCPWare V5.3-2 > . > > An urgent response will be appreciated... > > Regards > > Godfrey Pillay > SAB - AOM > Location: IBM Park Sandton, IA2G > Tel: (011) 302-6310 Fax: (011) 302-6592 > Cell: 082 823-5339 E-mail: gpillay@za.ibm.com > > > ================================================================================ Archive-Date: Fri, 11 Oct 2002 11:48:58 -0400 Date: Fri, 11 Oct 2002 11:46:33 -0400 From: peter@langstoeger.at (Peter LANGSTOEGER) Subject: Re: OKI Printers on IP Sender: Geoff Bryant To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: In article , Godfrey Pillay writes: >I am currently experiencing problems with the OKI printers (model 395) >that are configured via TCPWare. These printers are connected via JET >Direct cards. The printers seems to have problems with flow control and >form feeds and some page settings. > >This is an example of a printer configuration. Please let me know if I have >missed something out. > >$ QUEUE = "NEWFIN001" >$ INITIALIZE /QUEUE /START/ON="ip address,9100" - > /PROC=TCPWARE_TSSYM /NOBLOCK_LIMIT - > /DEFAULT=(FEED,FORM=A4FORM) /PROTECTION=(S:M,O:D,G:R,W:SM) 'QUEUE' If you have form-feed troubles consider using /DEFAULT=NOFEED and $ DEF/SYS/EXE TCPWARE_TSSYM_queuename "ip-name-or-address,9100,noff" $ INI/AUTO=nodename::/PROC=TCPWARE_TSSYM/... >This is an example of a form setup: > >Form name Number Description >--------- ------ ----------- >A4FORM (stock=DEFAULT) 1 A4 Stationery > /LENGTH=66 /STOCK=DEFAULT /TRUNCATE /WIDTH=132 How about /WRAP (or /NOWRAP/NOTRUNCATE) ? And is this printer really 132 columns ? And what do you normally send to this printer ? Postscript, some kind of Binary-Data or simple ASCII-Text? >I am using VAX/VMS version 7.2 on a VAX 4000 model 105 with TCPWare V5.3-2 Current is OpenVMS VAX V7.3 and TCPware V5.6-2, but you probably know this. And check also the HPJD itself and disable unwanted protocols and banner pages. HIH -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ================================================================================ Archive-Date: Fri, 11 Oct 2002 11:53:20 -0400 Date: Fri, 11 Oct 2002 11:51:32 -0400 From: Chris Moore Subject: Re: TCPIP IVP File? Sender: Geoff Bryant To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: RE: TCPIP IVP File?The installation typically uses VMSINSTAL rather than PCSI, and can be fairly time-consuming if you have selected a lot of components. I have never had an instance where this product didn't function as advertised right out-of-the-box. - once the installation is complete, edit the TCPWARE:TCPWARE_COMMANDS.com file to "un-comment" the PING command (and any others in there you feel you need) - perform the appropriate core and component configurations (@tcpware:CNFNET MENU .....check the Installation Guide) Have your config information (address, sub-net mask, gateway address, domain names, DNS server addresses, etc. etc.) available before you start and you shouldn't have any trouble - add "@tcpware:TCPWARE_COMMANDS" to your login (or SYLOGIN.com as appropriate) - log-out and back in to check that it executes properly - to 'ping' a known good address, just $ PING nnn.nnn.nnn.nnn (not "$TCPIP PING" like in UCX...er...TCP/IP Services) - depending on the options chosen, you could try: $ PING address $ PING name $ TELNET localhost (to do a telnet loop-back) $ TELNET otherhostname $ FTP (try an OPEN, DIR, GET, PUT, CLOSE etc) Chris Moore "Harsha, J" wrote in message news:177E503C4DA3D311BC9D0008C791C3060AE4B581@diexch01.xko.dec.com... Hi Mike, Thanks for the information. Since we don't have the TCPWARE's TCPIP installed on any of our machine, we are finding it difficult to write the code to check the working of the TCPWARE's TCPIP. Can you please provide with the following information or give me the steps with the commands and output, which tests the TCPWARE's TCPIP? I wanted to know how to check the TCPIP installed or not on the machine? will it be installed using PCSI? What are the commands for pinging and what is the output when it is working and when it is not working? Since I don't know the commands for pinging using TCPWARE's TCPIP, I m finding difficult to test for its working. or is there any other way to check? Thanks in advance, Harsha -----Original Message----- From: Michael Corbett [mailto:corbett@process.com] Sent: Tuesday, October 08, 2002 8:35 PM To: info-tcpware@process.com Subject: Re: TCPIP IVP File? Harsha, J wrote: > Hi All, > > I would like to know that is there any file (an EXE or a COM file) > which tests the TCP/IP working after TCPWARE product is installed? i.e. > Is there any IVP file which can be used for testing the TCPWARE's TCPIP > working? and what all needs to be tested to check whether the TCPWARE's > TCPIP is installed? > > > > If there is any file which does this, please specify the path with the > file name. > > > > and suppose if no such file exists, then how the commands needs to be > tested for TCPIP working? > > > > It will be very helpful if I get an earlier response. > > There is no IVP for TCPware. Perform basic test such has pinging another system on the same subnet. Ping something on another subnet if you have a default route configured. Try to establish connections to the services you've enabled. regards Mike -- +-------------------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Mon, 14 Oct 2002 08:45:40 -0400 Date: Mon, 14 Oct 2002 14:44:24 +0200 From: Martin Vorlaender Reply-To: Info-TCPware@process.com Subject: Compaq TCP/IP HR MIB & TCPware To: "TCPware Mailing List (E-Mail)" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi, I've installed the Management Agent 2.4 on a VMS 7.3-1 system. Compaq TCP/IP 5.3 had also been installed, but has since been superceeded by TCPware 5.6. But the TCPIP$HR_MIB won't start: $ mcr tcpip$hr_mib -trace 10-OCT-2002 13:21:44.43 **ERROR CONFIG.C line 198: read_config: Error opening: SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$VMS_SNMP_CONF.DAT 10-OCT-2002 13:21:44.43 **ERROR OS_MIBS.C line 554: Could not read VMS configuration file: SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$VMS_SNMP_CONF.DAT Terminating... (wrappings by me). Thanks in advance for any clues. cu, Martin -- One OS to rule them all | Martin Vorlaender | VMS & WNT programmer One OS to find them | work: mv@pdv-systeme.de One OS to bring them all | http://www.pdv-systeme.de/users/martinv/ And in the Darkness bind them.| home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Mon, 14 Oct 2002 09:26:37 -0400 Date: Mon, 14 Oct 2002 09:25:33 -0400 From: Lisa Fuellemann Reply-To: Info-TCPware@process.com Subject: RE: Compaq TCP/IP HR MIB & TCPware To: "'info-tcpware@process.com'" Message-ID: <63D30D6E10CFD11190A90000F805FE8604238FFF@lespaul.process.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Good morning, > I've installed the Management Agent 2.4 on a VMS 7.3-1 system. > Compaq TCP/IP 5.3 had also been installed, but has since been > superceeded by TCPware 5.6. But the TCPIP$HR_MIB won't start: > > $ mcr tcpip$hr_mib -trace > 10-OCT-2002 13:21:44.43 **ERROR CONFIG.C line 198: read_config: > Error opening: SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$VMS_SNMP_CONF.DAT > 10-OCT-2002 13:21:44.43 **ERROR OS_MIBS.C line 554: Could not read VMS > configuration file: > SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$VMS_SNMP_CONF.DAT > Terminating... > > (wrappings by me). > > Thanks in advance for any clues. You can simply create an empty file with that name: SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$VMS_SNMP_CONF.DAT and try again. The TCPIP$HR_MIB always looks for that file, but it doesn't require it to have any contents. That should take care of the above error, and barring any other issues with the configuration of TCPWare/SNMP/AgentX/etc., should allow the MIB to run. Hope that helps! Regards, --Lisa ----------------------------- Lisa D. Fuellemann Quality Assurance Engineer Process Software, LLC 959 Concord St. Framingham, MA 01701 Email: fuellemann@process.com ================================================================================ Archive-Date: Mon, 14 Oct 2002 10:01:08 -0400 Date: Mon, 14 Oct 2002 15:59:41 +0200 From: Martin Vorlaender Reply-To: Info-TCPware@process.com Subject: RE: Compaq TCP/IP HR MIB & TCPware In-Reply-To: To: "TCPware Mailing List (E-Mail)" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit > > I've installed the Management Agent 2.4 on a VMS 7.3-1 system. > > Compaq TCP/IP 5.3 had also been installed, but has since been > > superceeded by TCPware 5.6. But the TCPIP$HR_MIB won't start: > > You can simply create an empty file with that name: > > SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$VMS_SNMP_CONF.DAT > > and try again. The TCPIP$HR_MIB always looks for that file, > but it doesn't require it to have any contents. > > That should take care of the above error, and barring any > other issues with the configuration of TCPWare/SNMP/AgentX/etc., > should allow the MIB to run. Worked like a charm. Thanks much. cu, Martin -- | Martin Vorlaender | VMS & WNT programmer OpenVMS is today | work: mv@pdv-systeme.de what Microsoft wants | http://www.pdv-systeme.de/users/martinv/ Windows NT 8.0 to be! | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Mon, 14 Oct 2002 17:18:44 -0400 Date: Mon, 14 Oct 2002 17:17:18 -0400 From: =?iso-8859-1?Q?=22Vorl=E4nder=2C_Martin=22?= Reply-To: Info-TCPware@process.com Subject: RE: Compaq TCP/IP HR MIB & TCPware Sender: Geoff Bryant To: info-tcpware@process.com Message-ID: <9e0c1cfa13192c1500047ccd1857d0033daacd98@pdv-systeme.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 > > I've installed the Management Agent 2.4 on a VMS 7.3-1 system. > > Compaq TCP/IP 5.3 had also been installed, but has since been > > superceeded by TCPware 5.6. But the TCPIP$HR_MIB won't start: > > You can simply create an empty file with that name: > > SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$VMS_SNMP_CONF.DAT > > and try again. The TCPIP$HR_MIB always looks for that file, > but it doesn't require it to have any contents. > > That should take care of the above error, and barring any > other issues with the configuration of TCPWare/SNMP/AgentX/etc., > should allow the MIB to run. Worked like a charm. Thanks much. cu, Martin -- | Martin Vorlaender | VMS & WNT programmer OpenVMS is today | work: mv@pdv-systeme.de what Microsoft wants | http://www.pdv-systeme.de/users/martinv/ Windows NT 8.0 to be! | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Tue, 15 Oct 2002 10:19:12 -0400 Date: Tue, 15 Oct 2002 13:36:51 +0000 (GMT) From: peter@langstoeger.at (Peter LANGSTOEGER) Subject: [TCPware V5.6-2] Problems with SET GATEWAY (on OpenVMS Alpha V7.3) To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: Since I upgraded to TCPware V5.6-2 (from V5.5-3) I have a problem with the default gateway, but only on my Alpha. On my VAX it works correctly. 9 out of 10 reboots/TCPware-startups the default route is not set, though the startup commandfiles are unchanged. My TCPWARE_CONFIGURE.COM still has the gateway parameter correctly set (as about 1 out of 10 reboots proofs). Adding the default gateway after the reboot by hand with $ NETCU SET GATEWAY 192.168.1.1 works. So, I don't understand why it happens. Now, I continue to watch... Anyone else seen such a behaviour ? -Peter PS: I also noted, that on V5.6-2 the TCPWARE_CONFIGURE.COM config symbol NTP_WAYTOOBIG is now required. I didn't do a CNFNET after the upgrade (which seems to now enter it) and got startup errors by this missing item... -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ================================================================================ Archive-Date: Fri, 25 Oct 2002 04:27:23 -0400 Date: Fri, 25 Oct 2002 10:26:01 +0200 From: "Kurt A. Schumacher" Reply-To: Info-TCPware@process.com Subject: Ftp server - Unix mode - additional parameter support To: info-tcpware@process.com Message-ID: <001701c27c00$274da780$14010a0a@home.schumi.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All, We found many of the nice ftp clients still don't work with the TCPware ftp server in Unix mode. The typical reason are additional parameters passed on with the ls and/or dir commands, e.g. ls -l, ls -s, ending on the server as LIST -l, LIST -s . Is there a chance to get the most common parameters implemented in the V5.6-2 ff. ftp server? TIA, Kurt. ------------------------------------------------------------------------ KCS Engineering & Consulting H=E4rdlenstrasse 116, CH-8302 Kloten, = Switzerland ------------------------------------------------------------------------ Kurt.Schumacher@schumi.ch POTS +41 1 881 37 80 http://www.schumi.ch FAX: +41 1 881 37 88 ------------------------------------------------------------------------ =20 ================================================================================ Archive-Date: Fri, 25 Oct 2002 09:03:02 -0400 Date: Fri, 25 Oct 2002 09:01:23 -0400 From: Richard Whalen Reply-To: Info-TCPware@process.com Subject: RE: Ftp server - Unix mode - additional parameter support To: "'info-tcpware@process.com'" Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA775@lespaul.process.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable NO. These "parameters" were recently discussed in the FTP working group. = Most Unix systems support them as an artifact - they fork the ls command = with whatever was passed to it. RFC 959 specifies that the optional = parameter to the LIST command is a pathname - "Pathname normally contains device = and/or directory names, and file name specification." Richard Whalen Process Software. -----Original Message----- From: Kurt A. Schumacher [mailto:Kurt.Schumacher@schumi.ch] Sent: Friday, October 25, 2002 4:26 AM To: info-tcpware@process.com Subject: Ftp server - Unix mode - additional parameter support All, We found many of the nice ftp clients still don't work with the TCPware ftp server in Unix mode. The typical reason are additional parameters passed on with the ls and/or dir commands, e.g. ls -l, ls -s, ending on the server as LIST -l, LIST -s . Is there a chance to get the most common parameters implemented in the V5.6-2 ff. ftp server? TIA, Kurt. ------------------------------------------------------------------------= KCS Engineering & Consulting H=E4rdlenstrasse 116, CH-8302 Kloten, = Switzerland ------------------------------------------------------------------------= Kurt.Schumacher@schumi.ch POTS +41 1 881 37 = 80 http://www.schumi.ch FAX: +41 1 881 37 = 88 ------------------------------------------------------------------------= =20 ================================================================================ Archive-Date: Fri, 25 Oct 2002 15:17:19 -0400 Date: Fri, 25 Oct 2002 21:15:55 +0200 From: "Kurt A. Schumacher" Reply-To: Info-TCPware@process.com Subject: DNS 8.1 query-source address * port 53; option not honored! To: info-tcpware@process.com Message-ID: <000001c27c5a$f1823b60$14010a0a@home.schumi.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit TCPware V5.6-2 on OpenVMS version V7.3 Alpha We have configured named.conf (since the first BIND 8.1 implementation), since V5.6-2 it appears to be ignored. Following the file revision dates on the slave servers this worked when using the V5.6 beta version. options { directory "SYS$COMMON:[TCPWARE.NAMED]"; /* ** If there is a firewall between you and nameservers you want ** to talk to, you might need to uncomment the query-source ** directive below. Previous versions of BIND always asked ** questions using port 53, but BIND 8.1 uses an unprivileged ** port by default. */ query-source address * port 53; ... Here what the firewall log says: # Time Message Source Destination Notes 1 10/25/2002 21:07:50 Firewall rule match: TCP(set:2, rule:1) 194.191.19.253:18436 10.10.1.13:53 ACCESS FORWARD ... It's a random high port, as usual with BIND 8.1... Do I have missed something? -Kurt. ================================================================================ Archive-Date: Fri, 25 Oct 2002 15:18:50 -0400 Date: Fri, 25 Oct 2002 21:17:25 +0200 From: "Kurt A. Schumacher" Reply-To: Info-TCPware@process.com Subject: DNS 8.1 query-source address * port 53; option not honored! (2) To: info-tcpware@process.com Message-ID: <000101c27c5b$271dd590$14010a0a@home.schumi.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit TCPware V5.6-2 on OpenVMS version V7.3 Alpha We have configured named.conf (since the first BIND 8.1 implementation), since V5.6-2 it appears to be ignored. Following the file revision dates on the slave servers this worked when using the V5.6 beta version. => Ignoring this blocks named-xfers through firewalls!! options { directory "SYS$COMMON:[TCPWARE.NAMED]"; /* ** If there is a firewall between you and nameservers you want ** to talk to, you might need to uncomment the query-source ** directive below. Previous versions of BIND always asked ** questions using port 53, but BIND 8.1 uses an unprivileged ** port by default. */ query-source address * port 53; ... Here what the firewall log says: # Time Message Source Destination Notes 1 10/25/2002 21:07:50 Firewall rule match: TCP(set:2, rule:1) 194.191.19.253:18436 10.10.1.13:53 ACCESS FORWARD ... It's a random high port, as usual with BIND 8.1... Do I have missed something? -Kurt. ================================================================================ Archive-Date: Sun, 27 Oct 2002 02:20:56 -0400 Date: Sun, 27 Oct 2002 07:19:00 +0000 (GMT) From: peter@langstoeger.at (Peter LANGSTOEGER) Subject: Timezone-change observations To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: Because summertime ended today, I thought I share my observations. 1) Local Time (SHOW TIME) was correct on VAX and Alpha !! I'm running VMS V7.3 and TCPware V5.6-2 but no longer DECdts (which made perfect timezone changes for years !) 2) VMS timezone logicals showed correct values on Alpha but showed wrong (still summertime) values on VAX (just like as there happened no timezone change on VAX - which seems logical [but unacceptable] as there is no AUTO_DLIGHT_SAV parameter in SYSGEN on VAX) SYS$TIMEZONE_DAYLIGHT_SAVING SYS$TIMEZONE_DIFFERENTIAL SYS$TIMEZONE_NAME 3) TCPWARE_TIMEZONE_NAME Logical contained wrong values ("MET-DST" instead of "MET") on both platforms while TCPWARE_TIMEZONE Logical contained the correct values 4) SYS$TIMEZONE_RULE on Alpha contains a wrong formula "MET-1MET DST-2,M3.5.0/02,M10.4.0/03" instead of "MET-1MET DST-2,M3.5.0/02,M10.5.0/03" while on VAX "MET-1MET_DST-2,M3.5.0/2,M10.5.0/3" I saw this (and another) bug in DECdts some years ago for some years but it is - at least in DECdts - fixed for some years now. It surprises me that such a bug reappears in VMS timezones now. And why only on Alpha... 5) One still needs to fix TCPware startup files as there is in TCPWARE:TCPWARE_CONFIGURE.COM $ NETCU_TIMEZONE == "+0200" $ NETCU_TIMEZONE_NAME == "MET-DST" $ NETCU_TIMEZONE_RULES == "EUROPE" Which seems silly, because a fixed timezone value and name doesn't make sense while there is an automatic change (TCPWARE_TIMEZONE_RULES) implemented. -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ================================================================================ Archive-Date: Sun, 27 Oct 2002 22:37:50 -0400 Date: Sun, 27 Oct 2002 19:34:49 -0800 From: bob@instantwhip.com (Bob Ceculski) Subject: Re: Timezone-change observations To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit peter@langstoeger.at (Peter LANGSTOEGER) wrote in message news:... > Because summertime ended today, I thought I share my observations. > > 1) Local Time (SHOW TIME) was correct on VAX and Alpha !! > I'm running VMS V7.3 and TCPware V5.6-2 > but no longer DECdts (which made perfect timezone changes for years !) > why are you doing it the hard way? all you have to do is set up 2 tcpware_configure.com files, for me it was tcpware_configure.com_edt and tcpware_configure.com_est a dcl command procedure can be written to run once in the spring and once in the fall on the appropriate date and time at 2am and swap in the correct tcpware configure com file and do a simple $ @restart isn't this simple? ================================================================================ Archive-Date: Mon, 28 Oct 2002 01:16:01 -0400 Date: Mon, 28 Oct 2002 06:09:30 +0000 (GMT) From: peter@langstoeger.at (Peter LANGSTOEGER) Subject: Re: Timezone-change observations To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: In article , bob@instantwhip.com (Bob Ceculski) writes: >peter@langstoeger.at (Peter LANGSTOEGER) wrote in message news:... >> Because summertime ended today, I thought I share my observations. >> >> 1) Local Time (SHOW TIME) was correct on VAX and Alpha !! >> I'm running VMS V7.3 and TCPware V5.6-2 >> but no longer DECdts (which made perfect timezone changes for years !) > >why are you doing it the hard way? all you have to do is set up 2 >tcpware_configure.com files, for me it was > >tcpware_configure.com_edt and tcpware_configure.com_est > >a dcl command procedure can be written to run once in the spring >and once in the fall on the appropriate date and time at 2am >and swap in the correct tcpware configure com file and do a >simple > >$ @restart > >isn't this simple? Yup, but you missed the point. The point was to get VMS being in the line of many Opsys which do the DST switches automatically. And progress have been made obviously. But, as I wrote, something is still not ok. The VMS time switch on VAX, the DST rules on Alpha and the neccessity to change TCPware startup files. -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ================================================================================ Archive-Date: Mon, 28 Oct 2002 04:38:45 -0400 Date: Mon, 28 Oct 2002 10:38:52 +0100 From: "Kurt A. Schumacher" Reply-To: Info-TCPware@process.com Subject: RE: Timezone-change observations In-Reply-To: To: info-tcpware@process.com Message-ID: <000f01c27e65$d3d0d330$14010a0a@home.schumi.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob, - maintaintaining two configuration files - edititing a single file - copy configuration files on DST switching - restart ...are unappropriate ways to solve this problem on a 24x366 class platform! All the problems mentioned can be resolved by reading the local time, process the DST rules, and place the settings accordingly. We started this discussion many years back when DST has been introduced in Europe, still the same variables hardcoded in tcpware_configure.com... -Kurt. -----Original Message----- From: Bob Ceculski [mailto:bob@instantwhip.com] Sent: Monday, October 28, 2002 4:35 AM To: info-tcpware@process.com Subject: Re: Timezone-change observations peter@langstoeger.at (Peter LANGSTOEGER) wrote in message news:... > Because summertime ended today, I thought I share my observations. > > 1) Local Time (SHOW TIME) was correct on VAX and Alpha !! > I'm running VMS V7.3 and TCPware V5.6-2 > but no longer DECdts (which made perfect timezone changes for years > !) > why are you doing it the hard way? all you have to do is set up 2 tcpware_configure.com files, for me it was tcpware_configure.com_edt and tcpware_configure.com_est a dcl command procedure can be written to run once in the spring and once in the fall on the appropriate date and time at 2am and swap in the correct tcpware configure com file and do a simple $ @restart isn't this simple? ================================================================================ Archive-Date: Mon, 28 Oct 2002 05:02:25 -0400 Date: Mon, 28 Oct 2002 10:01:33 +0000 From: ths@dzus.co.uk Reply-To: Info-TCPware@process.com Subject: RE: Timezone-change observations To: info-tcpware@process.com BCC: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii A good way around this deficiency in TCPWare is to use NTP to track time on our Alpha (and our NT server!) to another server - we use a Netware server and fiewall (reliable) and in turn track these to an accurate outside source. Works for us - all servers/desktops corrected automatically on Sunday. Regards, Tony Hamilton-Smith I T Manager Dzus Fasteners Direct Dial: 01252 741160 "Kurt A. Schumacher" To: info-tcpware@process.com Subject: RE: Timezone-change observations 28/10/02 09:38 Please respond to Info-TCPware Bob, - maintaintaining two configuration files - edititing a single file - copy configuration files on DST switching - restart ...are unappropriate ways to solve this problem on a 24x366 class platform! All the problems mentioned can be resolved by reading the local time, process the DST rules, and place the settings accordingly. We started this discussion many years back when DST has been introduced in Europe, still the same variables hardcoded in tcpware_configure.com... -Kurt. -----Original Message----- From: Bob Ceculski [mailto:bob@instantwhip.com] Sent: Monday, October 28, 2002 4:35 AM To: info-tcpware@process.com Subject: Re: Timezone-change observations peter@langstoeger.at (Peter LANGSTOEGER) wrote in message news:... > Because summertime ended today, I thought I share my observations. > > 1) Local Time (SHOW TIME) was correct on VAX and Alpha !! > I'm running VMS V7.3 and TCPware V5.6-2 > but no longer DECdts (which made perfect timezone changes for years > !) > why are you doing it the hard way? all you have to do is set up 2 tcpware_configure.com files, for me it was tcpware_configure.com_edt and tcpware_configure.com_est a dcl command procedure can be written to run once in the spring and once in the fall on the appropriate date and time at 2am and swap in the correct tcpware configure com file and do a simple $ @restart isn't this simple? ================================================================================ Archive-Date: Mon, 28 Oct 2002 05:21:01 -0400 Date: Mon, 28 Oct 2002 11:21:09 +0100 From: "Kurt A. Schumacher" Reply-To: Info-TCPware@process.com Subject: RE: Timezone-change observations In-Reply-To: To: info-tcpware@process.com Message-ID: <001001c27e6b$bbdf01b0$14010a0a@home.schumi.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tony, Many Internet applications (starting with the TCPware SMTP, POP3 and IMAP4 server) are relying on TCPWARE_TIMEZONE and TCPWARE_TIMEZONE_NAME, non Process Software ones (HPq, public) are relying on the SYS$TIMEZONE_* logicals to carry out time related things correctly. On the other hand, to come back to Peter original request, I think the "TCPWARE_TIMEZONE" = "+010000" = "MET" "TCPWARE_TIMEZONE_NAME" = "MET-DST" definitions are correct, the timezone name "MET-DST" must not be changed in the tcpware_configure.com twice a year. The last variable item remaining in tcpware_configure.com is $ NETCU_TIMEZONE == "+0200", and this one should no longer be required with future development. These entries are fine IMHO, and don't need to be changed twice a year: $ NETCU_TIMEZONE_NAME == "MET-DST" $ NETCU_TIMEZONE_RULES == "EUROPE" Out of question, time synching using NTP, TIMED or similar is a good thing anyway, but this does not update the time zone related variables. -Kurt. -----Original Message----- From: ths@dzus.co.uk [mailto:ths@dzus.co.uk] Sent: Monday, October 28, 2002 11:02 AM To: info-tcpware@process.com Subject: RE: Timezone-change observations A good way around this deficiency in TCPWare is to use NTP to track time on our Alpha (and our NT server!) to another server - we use a Netware server and fiewall (reliable) and in turn track these to an accurate outside source. Works for us - all servers/desktops corrected automatically on Sunday. Regards, Tony Hamilton-Smith I T Manager Dzus Fasteners Direct Dial: 01252 741160 "Kurt A. Schumacher" To: info-tcpware@process.com Subject: RE: Timezone-change observations 28/10/02 09:38 Please respond to Info-TCPware Bob, - maintaintaining two configuration files - edititing a single file - copy configuration files on DST switching - restart ...are unappropriate ways to solve this problem on a 24x366 class platform! All the problems mentioned can be resolved by reading the local time, process the DST rules, and place the settings accordingly. We started this discussion many years back when DST has been introduced in Europe, still the same variables hardcoded in tcpware_configure.com... -Kurt. -----Original Message----- From: Bob Ceculski [mailto:bob@instantwhip.com] Sent: Monday, October 28, 2002 4:35 AM To: info-tcpware@process.com Subject: Re: Timezone-change observations peter@langstoeger.at (Peter LANGSTOEGER) wrote in message news:... > Because summertime ended today, I thought I share my observations. > > 1) Local Time (SHOW TIME) was correct on VAX and Alpha !! > I'm running VMS V7.3 and TCPware V5.6-2 > but no longer DECdts (which made perfect timezone changes for years > !) > why are you doing it the hard way? all you have to do is set up 2 tcpware_configure.com files, for me it was tcpware_configure.com_edt and tcpware_configure.com_est a dcl command procedure can be written to run once in the spring and once in the fall on the appropriate date and time at 2am and swap in the correct tcpware configure com file and do a simple $ @restart isn't this simple? ================================================================================ Archive-Date: Mon, 28 Oct 2002 05:49:23 -0400 Date: Mon, 28 Oct 2002 10:47:50 +0000 (GMT) From: peter@langstoeger.at (Peter LANGSTOEGER) Subject: RE: Timezone-change observations To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: In article <001001c27e6b$bbdf01b0$14010a0a@home.schumi.ch>, "Kurt A. Schumacher" writes: >On the other hand, to come back to Peter original request, I think the > "TCPWARE_TIMEZONE" = "+010000" > = "MET" > "TCPWARE_TIMEZONE_NAME" = "MET-DST" > definitions are correct, the timezone name "MET-DST" must not be >changed in the tcpware_configure.com twice a year. The last variable >item remaining in tcpware_configure.com is $ NETCU_TIMEZONE == "+0200", >and this one should no longer be required with future development. > >These entries are fine IMHO, and don't need to be changed twice a year: > >$ NETCU_TIMEZONE_NAME == "MET-DST" >$ NETCU_TIMEZONE_RULES == "EUROPE" You think, NETCU_TIMEZONE_NAME == "MET-DST" is the index into the rule file and not the name of the current timezone ? That means, MET with DST switches regardless if it's winter or summer ? That would make sense and then I would agree, that TCPware does it correct. I remove the NETCU_TIMEZONE line from my TCPWARE:TCPWARE_CONFIGURE.COM and see what happens in spring ;-) >Out of question, time synching using NTP, TIMED or similar is a good >thing anyway, but this does not update the time zone related variables. Agreed. Thanks -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ================================================================================ Archive-Date: Mon, 28 Oct 2002 07:10:04 -0400 Date: Mon, 28 Oct 2002 11:53:56 +0000 (GMT) From: pawe@hotmail.com Subject: Stop the extinction... 1146 To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: Please read this itll only take you a minute - it could be your local area next...! The corporations are at it again, this time focussing their attentions on a small part of the SW of England. A large international mining company claims to have found platinum in the UK and in their quest for money are going to extinquish at least 1 species from our planet. Butterflies, birds, small mammals, fish and even some plants are at risk from extinction if this corporate monster is not stopped. Please, please, please send as many emails as you can to register your views at info@mcleaninternationalmining.com - like i said, it could be your area next... Thanks Harry P.A.W.E wvbdbchqzcbmhbenkdrsoqhojqnrxnouefgtojddrxdmmsctqtsxzfxtmedfegbnoppcgiefrwzji ================================================================================ Archive-Date: Mon, 28 Oct 2002 11:01:05 -0400 Date: Mon, 28 Oct 2002 11:00:18 -0500 From: john.joy@abbott.com Reply-To: Info-TCPware@process.com Subject: Info on RSHD Sender: Geoff Bryant To: VMSNET-INTERNALS@GOATLEY.COM, INFO-VAX@MVB.SAIC.COM, SOCKETSHR@IFN.ING.TU-BS.DE, info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi, I am relatively new to VMS and my experiences with network programming is mostly in Solaris. I am trying to find some information regarding rshd (remote shell/command demon). I want to write a utility (OS: wint-nt) that can talk to the rshd on VMS (Alpha) and pass it a command name so that it could execute the command and return the status. I am looking for the sequence of execution on the server side and in what sequence it accepts the user id, the command and other information if required. Thanks in advance, ___________ John Joy 847 938 6059 ================================================================================ Archive-Date: Mon, 28 Oct 2002 19:28:06 -0400 Date: Tue, 29 Oct 2002 00:03:59 +0000 (GMT) From: peter@langstoeger.at (Peter LANGSTOEGER) Subject: [TCPware V5.6-2] Default Route gets lost (on Alpha) To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: You may remember my posting from about 2 weeks ago. [TCPware V5.6-2] Problems with SET GATEWAY (on OpenVMS Alpha V7.3) Today I verified again, that my PWS433au (with OpenVMS Alpha V7.3) has a default gateway set during startup of TCPware. ... %STARTNET-I-DEBUG, NETCU START/IP LPB-0 127.0.0.1 %STARTNET-I-DEBUG, NETCU START/IP EWA-0 192.168.1.3 /MASK=255.255.255.0 /FLAGS=(NOTRAILERS) %STARTNET-I-DEBUG, NETCU START/TCP %STARTNET-I-DEBUG, NETCU START/UDP %STARTNET-I-DEBUG, NETCU START/INET %STARTNET-I-DEBUG, NETCU START/UCX %STARTNET-I-DEBUG, NETCU SET TIMEZONE "UT" %STARTNET-I-DEBUG, NETCU DEFINE TIMEZONE/FILE=TCPWARE:TIMEZONES.DAT/SELECT=/SELECT=("EUROPE") MET-DST %STARTNET-I-DEBUG, NETCU SET DOMAIN luna.langstoeger.at %STARTNET-I-DEBUG, NETCU SET GATEWAY 192.168.1.1 ... TCPware(R) for OpenVMS Internet Routing Table: Destination Gateway Flags RefCnt UseCnt Line ----------- ------- ----- ------ ------ ---- 192.168.1.0 192.168.1.3 UNIL 0 1 EWA-0 127.0.0.0 127.0.0.1 UNIL 0 0 LPB-0 all others (default) 192.168.1.1 UNG 0 0 EWA-0 then after some more TCPware startup modules an IP Multicast Address gets added TCPware(R) for OpenVMS Internet Routing Table: Destination Gateway Flags RefCnt UseCnt Line ----------- ------- ----- ------ ------ ---- 224.0.0.9 127.0.0.1 UHA 0 0 LPB-0 192.168.1.0 192.168.1.3 UNIL 0 5 EWA-0 127.0.0.0 127.0.0.1 UNIL 0 0 LPB-0 all others (default) 192.168.1.1 UNG 0 1 EWA-0 and this table keeps the same until startup is finished. But then seconds/minutes after startup is completed the default gateway seems to get lost (and some problems starts to pop up). TCPware(R) for OpenVMS Internet Routing Table: Destination Gateway Flags RefCnt UseCnt Line ----------- ------- ----- ------ ------ ---- 224.0.0.9 127.0.0.1 UHA 0 0 LPB-0 192.168.1.0 192.168.1.3 UNIL 0 5 EWA-0 127.0.0.0 127.0.0.1 UNIL 0 0 LPB-0 Do you have any idea why this happens ? Does or did anyone with a support contract (I'm only a hobbyist) see the same behaviour on his/her system ? Currently I'm stuck (and live with doing a NETCU SET GATEWAY 192.168.1.1 then, which OTOH doesn't get lost later on). TIA -Peter -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ================================================================================ Archive-Date: Mon, 28 Oct 2002 22:13:48 -0400 Date: Mon, 28 Oct 2002 22:13:30 -0500 From: Geoff Bryant Reply-To: Info-TCPware@process.com Subject: Re: [TCPware V5.6-2] Default Route gets lost (on Alpha) To: info-tcpware@process.com Message-ID: <01KO7PTZ92BG9LZ6FO@PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Do you have Gated enabled? Have you searched TCPWARE:*.COM for any NETCU REMOVE ROUTE commands? Those are the only things that come to mind as possibilities... removing that route On Tue, 29 Oct 2002 00:03:59 +0000 (GMT), peter@langstoeger.at (Peter LANGSTOEGER) wrote: > >You may remember my posting from about 2 weeks ago. > [TCPware V5.6-2] Problems with SET GATEWAY (on OpenVMS Alpha V7.3) > >Today I verified again, that my PWS433au (with OpenVMS Alpha V7.3) >has a default gateway set during startup of TCPware. > >... >%STARTNET-I-DEBUG, NETCU START/IP LPB-0 127.0.0.1 >%STARTNET-I-DEBUG, NETCU START/IP EWA-0 192.168.1.3 /MASK=255.255.255.0 /FLAGS=(NOTRAILERS) >%STARTNET-I-DEBUG, NETCU START/TCP >%STARTNET-I-DEBUG, NETCU START/UDP >%STARTNET-I-DEBUG, NETCU START/INET >%STARTNET-I-DEBUG, NETCU START/UCX >%STARTNET-I-DEBUG, NETCU SET TIMEZONE "UT" >%STARTNET-I-DEBUG, NETCU DEFINE TIMEZONE/FILE=TCPWARE:TIMEZONES.DAT/SELECT=/SELECT=("EUROPE") MET-DST >%STARTNET-I-DEBUG, NETCU SET DOMAIN luna.langstoeger.at >%STARTNET-I-DEBUG, NETCU SET GATEWAY 192.168.1.1 >... > >TCPware(R) for OpenVMS Internet Routing Table: > >Destination Gateway Flags RefCnt UseCnt Line >----------- ------- ----- ------ ------ ---- >192.168.1.0 192.168.1.3 UNIL 0 1 EWA-0 >127.0.0.0 127.0.0.1 UNIL 0 0 LPB-0 >all others (default) 192.168.1.1 UNG 0 0 EWA-0 > >then after some more TCPware startup modules an IP Multicast Address gets >added > >TCPware(R) for OpenVMS Internet Routing Table: > >Destination Gateway Flags RefCnt UseCnt Line >----------- ------- ----- ------ ------ ---- >224.0.0.9 127.0.0.1 UHA 0 0 LPB-0 >192.168.1.0 192.168.1.3 UNIL 0 5 EWA-0 >127.0.0.0 127.0.0.1 UNIL 0 0 LPB-0 >all others (default) 192.168.1.1 UNG 0 1 EWA-0 > >and this table keeps the same until startup is finished. > >But then seconds/minutes after startup is completed the default gateway >seems to get lost (and some problems starts to pop up). > >TCPware(R) for OpenVMS Internet Routing Table: > >Destination Gateway Flags RefCnt UseCnt Line >----------- ------- ----- ------ ------ ---- >224.0.0.9 127.0.0.1 UHA 0 0 LPB-0 >192.168.1.0 192.168.1.3 UNIL 0 5 EWA-0 >127.0.0.0 127.0.0.1 UNIL 0 0 LPB-0 > > >Do you have any idea why this happens ? >Does or did anyone with a support contract (I'm only a hobbyist) >see the same behaviour on his/her system ? >Currently I'm stuck (and live with doing a NETCU SET GATEWAY 192.168.1.1 >then, which OTOH doesn't get lost later on). > >TIA > >-Peter > >-- >Peter "EPLAN" LANGSTOEGER >Network and OpenVMS system specialist >E-mail peter@langstoeger.at >A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/MultiNet/PMDF Engineering Process Software http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Mon, 28 Oct 2002 22:51:24 -0400 Date: Mon, 28 Oct 2002 21:47:40 -0500 From: John Santos Subject: Re: [TCPware V5.6-2] Default Route gets lost (on Alpha) In-Reply-To: To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <1021028214107.400A-100000@Ives.egh.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 29 Oct 2002, Peter LANGSTOEGER wrote: > You may remember my posting from about 2 weeks ago. > [TCPware V5.6-2] Problems with SET GATEWAY (on OpenVMS Alpha V7.3) > > Today I verified again, that my PWS433au (with OpenVMS Alpha V7.3) > has a default gateway set during startup of TCPware. > > ... > %STARTNET-I-DEBUG, NETCU START/IP LPB-0 127.0.0.1 > %STARTNET-I-DEBUG, NETCU START/IP EWA-0 192.168.1.3 /MASK=255.255.255.0 /FLAGS=(NOTRAILERS) > %STARTNET-I-DEBUG, NETCU START/TCP > %STARTNET-I-DEBUG, NETCU START/UDP > %STARTNET-I-DEBUG, NETCU START/INET > %STARTNET-I-DEBUG, NETCU START/UCX > %STARTNET-I-DEBUG, NETCU SET TIMEZONE "UT" > %STARTNET-I-DEBUG, NETCU DEFINE TIMEZONE/FILE=TCPWARE:TIMEZONES.DAT/SELECT=/SELECT=("EUROPE") MET-DST > %STARTNET-I-DEBUG, NETCU SET DOMAIN luna.langstoeger.at > %STARTNET-I-DEBUG, NETCU SET GATEWAY 192.168.1.1 > ... > > TCPware(R) for OpenVMS Internet Routing Table: > > Destination Gateway Flags RefCnt UseCnt Line > ----------- ------- ----- ------ ------ ---- > 192.168.1.0 192.168.1.3 UNIL 0 1 EWA-0 > 127.0.0.0 127.0.0.1 UNIL 0 0 LPB-0 > all others (default) 192.168.1.1 UNG 0 0 EWA-0 > > then after some more TCPware startup modules an IP Multicast Address gets > added > > TCPware(R) for OpenVMS Internet Routing Table: > > Destination Gateway Flags RefCnt UseCnt Line > ----------- ------- ----- ------ ------ ---- > 224.0.0.9 127.0.0.1 UHA 0 0 LPB-0 > 192.168.1.0 192.168.1.3 UNIL 0 5 EWA-0 > 127.0.0.0 127.0.0.1 UNIL 0 0 LPB-0 > all others (default) 192.168.1.1 UNG 0 1 EWA-0 > > and this table keeps the same until startup is finished. > > But then seconds/minutes after startup is completed the default gateway > seems to get lost (and some problems starts to pop up). > > TCPware(R) for OpenVMS Internet Routing Table: > > Destination Gateway Flags RefCnt UseCnt Line > ----------- ------- ----- ------ ------ ---- > 224.0.0.9 127.0.0.1 UHA 0 0 LPB-0 > 192.168.1.0 192.168.1.3 UNIL 0 5 EWA-0 > 127.0.0.0 127.0.0.1 UNIL 0 0 LPB-0 > > > Do you have any idea why this happens ? > Does or did anyone with a support contract (I'm only a hobbyist) > see the same behaviour on his/her system ? > Currently I'm stuck (and live with doing a NETCU SET GATEWAY 192.168.1.1 > then, which OTOH doesn't get lost later on). > > TIA > > -Peter Doesn't happen on mine. I have 2 Alpha's and 2 Vaxes running TCPWare V5.6-2. One Alphas is VMS V7.2-1. The other Alpha and both Vaxes are V7.3. I do have a real router (with a real routable IP address) set as the gateway, rather than a local, non-routable address, but I don't think that should matter. I also don't have the 224... route (is that from netware?) Are you sure nothing is deleting the route? Check TCPWARE:ROUTING.COM. HTH. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ================================================================================ Archive-Date: Tue, 29 Oct 2002 05:45:13 -0400 Date: Tue, 29 Oct 2002 10:24:08 +0000 (GMT) From: peter@langstoeger.at (Peter LANGSTOEGER) Subject: Re: [TCPware V5.6-2] Default Route gets lost (on Alpha) To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: In article <01KO7PTZ92BG9LZ6FO@PROCESS.COM>, Geoff Bryant writes: >Do you have Gated enabled? Yes and that was obviously the reason. I should have known that (the 224.0.0.9 make it also clear) but alas... Though GATED seems properly configured for what I intended rip yes { nobroadcast; }; the problem is, that GATED is not required here (in contrast to my previous company) because I've only one LAN with only one Router which does NOT broadcast (RIP or OSPF or what else). Disabling GATED again and the bad behaviour disappeared. On my VAX where the problem did not pop up, GATED was disabled (as it should be here at home). So the question(s) is/are now different 1) Why does GATED delete the default route ? Only because there is no broadcasting router ? Or do I need to enter the default route in addition to TCPWARE_CONFIGURE.COM in the GATED.CONF ? 2) Why does GATED delete the default route only in 9 of 10 cases ? I mentioned this in my first posting. That is the strange one... 3) Why does GATED delete the default route only the first time ? NETCU SET GATEWAY it again and the route keeps there. Is it required to enter the default route in the GATED.CONF (or set it after GATED started) to make it aware of the default route ? 4) Why did GATED of TCPware V5.5-3 not show this behaviour ? Remember, I did only upgrade TCPware but did not change the config and the behaviour started to be seen. >Have you searched TCPWARE:*.COM for any NETCU REMOVE ROUTE commands? There are none of course. And there is also no NETWARE here. Thanks for the right hint... -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ================================================================================ Archive-Date: Tue, 29 Oct 2002 09:45:31 -0400 Date: Tue, 29 Oct 2002 09:45:09 -0500 From: Geoff Bryant Reply-To: Info-TCPware@process.com Subject: Re: [TCPware V5.6-2] Default Route gets lost (on Alpha) To: info-tcpware@process.com Message-ID: <01KO8DW1FBS09LXG8H@PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii When using Gated to do routing, you need to just use Gated to do routing. Gated wants to be in charge of the routing table and will tend to get rid of "unnecessary" routes when it starts up. So, if using Gated, then yes configure the default route in the gated.conf and remove it from the regular TCPware configuration. I would guess that the cases where Gated did/didn't delete the route depend on whether it knows from its own config to add one, or has learned it from RIP, router discovery, or some other protocol you have it configured to use. On Tue, 29 Oct 2002 10:24:08 +0000 (GMT), peter@langstoeger.at (Peter LANGSTOEGER) wrote: > >In article <01KO7PTZ92BG9LZ6FO@PROCESS.COM>, Geoff Bryant writes: >>Do you have Gated enabled? > >Yes and that was obviously the reason. >I should have known that (the 224.0.0.9 make it also clear) but alas... >Though GATED seems properly configured for what I intended > >rip yes { > nobroadcast; >}; > >the problem is, that GATED is not required here (in contrast to my previous >company) because I've only one LAN with only one Router which does NOT >broadcast (RIP or OSPF or what else). > >Disabling GATED again and the bad behaviour disappeared. >On my VAX where the problem did not pop up, GATED was disabled (as it >should be here at home). > >So the question(s) is/are now different >1) Why does GATED delete the default route ? Only because there is no > broadcasting router ? Or do I need to enter the default route > in addition to TCPWARE_CONFIGURE.COM in the GATED.CONF ? >2) Why does GATED delete the default route only in 9 of 10 cases ? > I mentioned this in my first posting. That is the strange one... >3) Why does GATED delete the default route only the first time ? > NETCU SET GATEWAY it again and the route keeps there. > Is it required to enter the default route in the GATED.CONF (or > set it after GATED started) to make it aware of the default route ? >4) Why did GATED of TCPware V5.5-3 not show this behaviour ? > Remember, I did only upgrade TCPware but did not change the config > and the behaviour started to be seen. > >>Have you searched TCPWARE:*.COM for any NETCU REMOVE ROUTE commands? > >There are none of course. > >And there is also no NETWARE here. > >Thanks for the right hint... > >-- >Peter "EPLAN" LANGSTOEGER >Network and OpenVMS system specialist >E-mail peter@langstoeger.at >A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/MultiNet/PMDF Engineering Process Software http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Tue, 29 Oct 2002 15:25:16 -0400 Date: Tue, 29 Oct 2002 21:24:50 +0100 From: "Kurt A. Schumacher" Reply-To: Info-TCPware@process.com Subject: SSH V2 Server Debugging To: info-tcpware@process.com Message-ID: <004d01c27f89$3ba9b520$14010a0a@home.schumi.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Can we have some details on debugging SSL v2 tunnels? We are loosing F-Secure 5.2 Build 10 (Windows) based MS Outlook XP to IMAP4 (TCPware 5.6-2) tunnels on every hour or so. Similar effect seen with the direct connection every other day, using the tunnel it's much worse. The command line sessions open at the same time are not disconnected, no proof yet other non-ssh-shell sessions get disconnected at the same time. Some debug hints would help before calling for support. -Kurt.