Archive-Date: Wed, 2 Feb 2000 13:26:37 -0400
From: Gunnar.Ehrlich@pdv.de (Gunnar Ehrlich)
Reply-To: Info-TCPware@process.com
Subject: Upgrade troubles
Date: 2 Feb 2000 18:17:10 GMT
Message-ID: <879sb6$fio$1@newsread.do.de.uu.net>
MIME-Version: 1.0
Content-Type: Text/Plain; charset=US-ASCII
To: Info-TCPware@PROCESS.COM

Hallo all,

please excuse this mighty posting, but I thought these infos could be
helpful. Today I tried an upgrade from TCPWare V5.3-3 to V5.4-3, and 
run into several strange problems: neither FTP nor SMTP works as I 
know it. The installation was ok (MV 3100/76,24 Mb, VMS 6.2), the TCPWare 
processes start up, but when I wanted to do something, only errors
happened.

Exactly: When I try to start a FTP session from a remote VAX (MV3100/90, 
VMS 6.2, UCX 3.2) and try to PUT a file with more than 100 blocks, the 
output looks as follows:

FTP> open lydia
220-@tcpware:tcpware_ftp_220_reply.txt
220 lydia.pdv.de (192.168.12.12) FTP-OpenVMS FTPD V5.4-3 (c) 1999 Process
    Software Corporation
[...]
230 User logged in, proceed.
FTP> bin
200 TYPE command okay.
FTP> hash
Hash mark printing on (1024/hash mark).
FTP> put leistb.zip
200 PORT command okay.
150 Opening data connection for SYS$SYSROOT:[SYSMGR]LEISTB.ZIP;1.
################################
%SYSTEM-F-LINKDISCON, network partner disconnected logical link
P$

Short text files with only a few blocks are transferred. The resulting
logfile from the above session:

        --------------------------------------------------------
        FTP Login request received at Wed Feb  2 16:39:46 2000
            from remote IP address 10.1.111.8 (POLLUX)
        --------------------------------------------------------
>>> 230 User logged in, proceed.
<<< SITE +VMS+
>>> 214 SITE +VMS+ recognized.
<<< TYPE I
>>> 200 TYPE command okay.
<<< PORT 10,1,111,8,4,79
>>> 200 PORT command okay.
<<< STOR leistb.zip
>>> 150 Opening data connection for SYS$SYSROOT:[SYSMGR]LEISTB.ZIP;1.
%FDL-E-SYNTAX, syntax error in statement 18   <CR><LF> \              -
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@...
>>> 550 %RMS-S-NORMAL, normal successful completion
  SYSTEM       job terminated at  2-FEB-2000 16:39:54.96

The lines with "FDL..." and "^@^@^@..." are originally only one line with 
at least 255 chars.
BTW, the patch FTP_V534P021 is installed. From a PC I can FTP larger
files without problems, and from an Alpha with VMS 7.1 and UCX 4.1 ECO2
too. When I close FTP on the Alpha, I get "421 Service not available,
Remote server has closed the connection"

The other problem is that I can't receive mails on my VAX at all, and 
sending mails results in the following:

MAIL> send
To:     mail$ich
CC:
Subj:   test
Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit:
test
 Exit
%MAIL-E-SENDERR, error sending to user gunnar.ehrlich@pdv.de at
-LIB-F-BADBLOADR, bad block address
%MAIL-E-SENDERR, error sending to user gunnar.ehrlich@pdv.de at
-LIB-F-BADBLOADR, bad block address
%MAIL-E-SENDERR, error sending to user gunnar.ehrlich@pdv.de at
-LIB-F-BADBLOADR, bad block address
MAIL>

This mail was sent, as I received it on my PC!
Then, I thought of any trouble with logicals:

MAIL> send
To:     smtp%"gunnar.ehrlich@pdv.de"
CC:
Subj:   test
Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit:
test
 Exit
%MAIL-E-SENDERR, error sending to user gunnar.ehrlich@pdv.de at
-LIB-F-INSVIRMEM, insufficient virtual memory
%MAIL-E-SENDERR, error sending to user gunnar.ehrlich@pdv.de at
-SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=69656365,
      PC=000F5CF7, PSL=03C00000
%MAIL-E-SENDERR, error sending to user gunnar.ehrlich@pdv.de at
-SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=69656365,
      PC=000F5CF7, PSL=03C00000
%MAIL-E-SENDERR, error sending to user gunnar.ehrlich@pdv.de at
-SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=69656365,
      PC=000F5CF7, PSL=03C00000

...and these lines are repeated until ctrl/y or power off.

Because of the INSVIRMEM error I rebooted without starting AllIn1, but no 
change. PGFLQUO was temporarily screwed up to 200000 ;-)



Any help?

Kind regards

Gunnar

-------
Gunnar.Ehrlich@pdv.de

================================================================================
Archive-Date: Wed, 2 Feb 2000 14:08:39 -0400
Message-ID: <54F85D7F6DE2D01184EF0000F804953502BCEE3F@MAIL04>
From: "Senulis, Joseph A" <SenulJ@mail01.dnr.state.wi.us>
Reply-To: Info-TCPware@process.com
To: "'Info-TCPware@process.com'" <Info-TCPware@process.com>
Subject: RE: Upgrade troubles
Date: Wed, 2 Feb 2000 13:04:51 -0600
MIME-Version: 1.0
Content-Type: text/plain

Hi,
     We upgraded from 5.3-2 to 5.4-3 last weekend, also with FTP and SMTP
problems, although we are limping along.  We have also installed the
FTP_V543P021 patch, as well as the DRIVERS_V543P010 patch.  We are running
VMS 7.1-1H2 on alphas.  We are not running All-in-one.

FTP:
1) Logical name parsing has changed.  Process Software is working on this,
but I haven't gotten an update since Monday afternoon.  After doing an FTP
to a TCPware FTP server, the following command no longer works: "cd
SYS$LOGIN".  However, "cd SYS$LOGIN:" does work.  (Note the colon.)
Interestingly, "ls SYS$LOGIN" and "ls SYS$LOGIN:" both work.  Backing off
the FTP patch did not resolve the problem.

2) FTP transfer of larger files.  The error message that you got was a
little different that what we got, but we have several versions of this
error depending on what the other node is (VMS vs NT vs MVS) and who
initiated the transfer.  At our site, we need to set /MTU=1500 because of a
mix of different kinds of network between nodes.  This is part of the
NETCU_LINES symbol in TCPWARE_CONFIGURE.COM.  When we ran CNFNET after the
upgrade, this setting was not automatically passed on to the new
configuration and I missed it when I checked.  Setting /MTU has cleared up
that problem.

SMTP:
We had lots of problems with SMTP.  I did not work on this problem myself
and the person who did is out today, but be aware that the configuration for
SMTP has changed radically from 7.3-x.  I know that he did work in
SMTP_ALIASES, SMTP_HOST_ALIASES and SMTP_LOCAL_LOGICALS.  SMTP did not
completely fail.

I have been looking at a time stamp problem in SMTP.  I haven't heard back
from Process Software about this and I am not entirely sure where the
problem lies.  However, SMTP treats our local time, CST, as GMT so that it
appears to be sent 6 hours earlier than it really was.

--Joe

Joseph Senulis
Technical Support Specialist
BEITA ET/8
Wisconsin Department of Natural Resources
101 South Webster Street,  Box 7921
Madison,  Wisconsin  53707-7921

608-266-0853
senulj@dnr.state.wi.us



> ----------
> From: 	Gunnar.Ehrlich@pdv.de[SMTP:Gunnar.Ehrlich@pdv.de]
> Reply To: 	Info-TCPware@process.com
> Sent: 	Wednesday, February 02, 2000 12:17 PM
> To: 	Info-TCPware@PROCESS.COM
> Subject: 	Upgrade troubles
> 
> Hallo all,
> 
> please excuse this mighty posting, but I thought these infos could be
> helpful. Today I tried an upgrade from TCPWare V5.3-3 to V5.4-3, and 
> run into several strange problems: neither FTP nor SMTP works as I 
> know it. The installation was ok (MV 3100/76,24 Mb, VMS 6.2), the TCPWare 
> processes start up, but when I wanted to do something, only errors
> happened. . . .
> 
================================================================================
Archive-Date: Wed, 2 Feb 2000 14:40:53 -0400
Date: Wed, 2 Feb 2000 13:36:51 -0600
From: Hunter Goatley <goathunter@process.com>
Reply-To: Info-TCPware@process.com
To: Info-TCPware@process.com
CC: SenulJ@mail01.dnr.state.wi.us
Message-ID: <000202133651.202000c1@process.com>
Subject: RE: Upgrade troubles

"Senulis, Joseph A" <SenulJ@mail01.dnr.state.wi.us> writes:
>
>I have been looking at a time stamp problem in SMTP.  I haven't heard back
>from Process Software about this and I am not entirely sure where the
>problem lies.  However, SMTP treats our local time, CST, as GMT so that it
>appears to be sent 6 hours earlier than it really was.
>
The SMTP code does not yet handle the TCPware timezone logicals (it
was an oversight).  A simple workaround until we get the problem
resolved is to just define the logical MULTINET_TIMEZONE before
starting TCPware:

$ define/system/exec multinet_timezone "CST"

Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
<goathunter@PROCESS.COM>     http://www2.wku.edu/hunter/
================================================================================
Archive-Date: Wed, 2 Feb 2000 14:49:22 -0400
Message-ID: <54F85D7F6DE2D01184EF0000F804953502BCEE40@MAIL04>
From: "Senulis, Joseph A" <SenulJ@mail01.dnr.state.wi.us>
Reply-To: Info-TCPware@process.com
To: "'Info-TCPware@process.com'" <Info-TCPware@process.com>
Subject: RE: Upgrade troubles
Date: Wed, 2 Feb 2000 13:45:40 -0600
MIME-Version: 1.0
Content-Type: text/plain

Thanks.  This works.
--Joe

> ----------
> From: 	Hunter Goatley[SMTP:goathunter@process.com]
> Reply To: 	Info-TCPware@process.com
> Sent: 	Wednesday, February 02, 2000 1:36 PM
> To: 	Info-TCPware@process.com
> Cc: 	Senulis, Joseph A
> Subject: 	RE: Upgrade troubles
> 
> "Senulis, Joseph A" <SenulJ@mail01.dnr.state.wi.us> writes:
> >
> >I have been looking at a time stamp problem in SMTP.  I haven't heard
> back
> >from Process Software about this and I am not entirely sure where the
> >problem lies.  However, SMTP treats our local time, CST, as GMT so that
> it
> >appears to be sent 6 hours earlier than it really was.
> >
> The SMTP code does not yet handle the TCPware timezone logicals (it
> was an oversight).  A simple workaround until we get the problem
> resolved is to just define the logical MULTINET_TIMEZONE before
> starting TCPware:
> 
> $ define/system/exec multinet_timezone "CST"
> 
> Hunter
> ------
> Hunter Goatley, Process Software, http://www.process.com/
> <goathunter@PROCESS.COM>     http://www2.wku.edu/hunter/
> 
================================================================================
Archive-Date: Thu, 3 Feb 2000 05:59:39 -0500
From: Gunnar.Ehrlich@pdv.de (Gunnar Ehrlich)
Reply-To: Info-TCPware@process.com
Subject: RE: Upgrade troubles
Date: 3 Feb 2000 10:54:07 GMT
Message-ID: <87bmof$jd8$1@newsread.do.de.uu.net>
MIME-Version: 1.0
Content-Type: Text/Plain; charset=US-ASCII
To: Info-TCPware@PROCESS.COM

Hi Joe,

many thanks for your response, but it didn't help :-(((

>FTP:
>1) Logical name parsing has changed.  ["SYS$LOGIN" or "SYS$LOGIN:" in 
cd and ls]

Right. The same behaviour as here. 

>2) FTP transfer of larger files. [...]
>At our site, we need to set /MTU=1500 because of a
>mix of different kinds of network between nodes.

Also the same as here, but after adding this flag with several larger values 
there's still no change. 

The FTP logfile contained an error line "%FDL-E-SYNTAX, syntax error in 
statement 18   <CR><LF> \  ^@^@^@...", so I played around with the /FDL 
qualifier. Seems I found a workaround, because with this qualifier appended to 
the put command it works. Why does the FTP server suddenly require a FDL
file ??

>SMTP:
>We had lots of problems with SMTP.  I did not work on this problem myself
>and the person who did is out today, but be aware that the configuration for
>SMTP has changed radically from 7.3-x.

hm. It seems that SMTP is able to translate logicals, as mail with a logical 
receiver name is sent but with a native smtp%"..." address it is not.

>I have been looking at a time stamp problem in SMTP.

I included the "multinet_timezone" logical suggested by Hunter Goatley in the 
startup file, but didn't really care about, because the other problems are 
more sever.

Thanks again!

gunnar

>
>--Joe
>
>Joseph Senulis
>Technical Support Specialist
>BEITA ET/8
>Wisconsin Department of Natural Resources
>101 South Webster Street,  Box 7921
>Madison,  Wisconsin  53707-7921
>
>608-266-0853
>senulj@dnr.state.wi.us
>
>
>> ----------
>> From:         Gunnar.Ehrlich@pdv.de[SMTP:Gunnar.Ehrlich@pdv.de]
>> Reply To:     Info-TCPware@process.com
>> Sent:         Wednesday, February 02, 2000 12:17 PM
>> To:   Info-TCPware@PROCESS.COM
>> Subject:      Upgrade troubles
>> 
>> Hallo all,
>> 
>> please excuse this mighty posting, but I thought these infos could be
>> helpful. Today I tried an upgrade from TCPWare V5.3-3 to V5.4-3, and 
>> run into several strange problems: neither FTP nor SMTP works as I 
>> know it. The installation was ok (MV 3100/76,24 Mb, VMS 6.2), the TCPWare 
>> processes start up, but when I wanted to do something, only errors
>> happened. . . .
>> 

================================================================================
Archive-Date: Thu, 3 Feb 2000 06:27:39 -0500
From: "Martin Vorlaender" <mv@PDV-SYSTEME.de>
Reply-To: Info-TCPware@process.com
To: <Info-TCPware@process.com>
CC: <Gunnar.Ehrlich@pdv.de>
Subject: RE: Upgrade troubles
Date: Thu, 3 Feb 2000 12:24:09 +0100
Message-ID: <7e02a448abb576edd215f31030f895a938996577@pdv-systeme.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <87bmof$jd8$1@newsread.do.de.uu.net>

>> 2) FTP transfer of larger files. [...]
>> At our site, we need to set /MTU=1500 because of a
>> mix of different kinds of network between nodes.
> 
> Also the same as here, but after adding this flag with 
> several larger values 
> there's still no change. 
> 
> The FTP logfile contained an error line "%FDL-E-SYNTAX, syntax error
> in statement 18   <CR><LF> \  ^@^@^@...", so I played around with the
> /FDL qualifier. Seems I found a workaround, because with this qualifier
> appended to  the put command it works. Why does the FTP server suddenly
> require a FDL file ??

Possibly another option to work around this could be to call the
TCPware FTP client with the NoVMS option, i.e.

$ FTP hostname /NOVMS  (FTP/NOVMS doesn't work) or
FTP> SET NOVMS  or
FTP> OPEN /NOVMS

Beware: In NoVMS mode, you can only transfer STREAM_LF (TYPE ASCII) and
        FIXED-512 (TYPE BINARY) record formats without losing record
        format information.

cu,
  Martin

P.S.: Greetings from one PDV to another :-)
-- 
                       | 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: Thu, 3 Feb 2000 08:59:42 -0500
Date: Thu, 3 Feb 2000 7:55:41 -0600
From: Hunter Goatley <goathunter@process.com>
Reply-To: Info-TCPware@process.com
To: Info-TCPware@process.com
Message-ID: <000203075541.202000c1@process.com>
Subject: RE: Upgrade troubles

Gunnar.Ehrlich@pdv.de (Gunnar Ehrlich) writes:
>
>>FTP:
>>1) Logical name parsing has changed.  ["SYS$LOGIN" or "SYS$LOGIN:" in 
>cd and ls]
>
>Right. The same behaviour as here. 
>
>>2) FTP transfer of larger files. [...]
>>At our site, we need to set /MTU=1500 because of a
>>mix of different kinds of network between nodes.
>
>Also the same as here, but after adding this flag with several larger values 
>there's still no change. 
>
We're looking into both of these issues.  The transfer issue is one
we have not yet been able to reproduce, but we're looking into it.

>hm. It seems that SMTP is able to translate logicals, as mail with a logical 
>receiver name is sent but with a native smtp%"..." address it is not.
>
Are you saying that a logical name within the SMTP%"..." string is not
translated?  That is by design---the only translation that occurs with
that string is an alias lookup.

Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
<goathunter@PROCESS.COM>     http://www2.wku.edu/hunter/
================================================================================
Archive-Date: Thu, 3 Feb 2000 11:20:14 -0500
From: Gunnar.Ehrlich@pdv.de (Gunnar Ehrlich)
Reply-To: Info-TCPware@process.com
Subject: RE: Upgrade troubles
Date: 3 Feb 2000 16:15:03 GMT
Message-ID: <87c9i7$f9l$1@newsread.do.de.uu.net>
MIME-Version: 1.0
Content-Type: Text/Plain; charset=US-ASCII
To: Info-TCPware@PROCESS.COM

Hi Hunter,

In article <000203075541.202000c1@process.com>, goathunter@process.com says...

>>>2) FTP transfer of larger files. [...]
>>>At our site, we need to set /MTU=1500 because of a
>>>mix of different kinds of network between nodes.
>>Also the same as here, but after adding this flag with several larger values 
>>there's still no change. 
>We're looking into both of these issues.  The transfer issue is one
>we have not yet been able to reproduce, but we're looking into it.

I tried it from a System with UCX 3.2. I can get it working by appending a
"/FDL" to the line, e.g. a "put x.y /fdl".

>>hm. It seems that SMTP is able to translate logicals, as mail with a logical 
>>receiver name is sent but with a native smtp%"..." address it is not.
>Are you saying that a logical name within the SMTP%"..." string is not
>translated?  That is by design---the only translation that occurs with
>that string is an alias lookup.

Here are my last explorations:
When I respond to the "to:" prompt with a logical, say MAIL$ME, which 
translates to "SMTP%"gunnar.ehrlich@pdv.de"", the mail is sent (I believe, 
because our mail administrator sent me a response with "<<< 501 
<system@lydia.pdv.de>... Sender domain must exist" - btw, where is the 
logical SMTP_FROM_DOMAIN gone?). But I get three of these "error sending 
to..."- and "bad block address"-errors. The same happens if I don't use the 
logical but the real mail address, as I found now. If I don't exit MAIL and
try to send another mail, I run into a LIB-F-INSVIRMEM error and the endless
loop with "access violation" errors. Before these messages it looks for a 
file "SMTP_OUTGOING_ALIASES.;0" in the TCPWARE dir's - SET WATCH FIL/CLAS=DIR.
It seems that if I start MAIL and write a mail, it is sent, but with three
error messages. If I then try to send another mail, I get an error loop.
If you need some more information - tell me what to check and I'll send
you the output.

Many thanks!

Kind regards
Gunnar



----
Gunnar.Ehrlich@pdv.de

================================================================================
Archive-Date: Sun, 6 Feb 2000 11:32:29 -0500
Subject: ANONYMOUS FTP Problems after TCPware V5.4 upgrade
From: eplan@kapsch.net (Peter LANGSTOEGER)
Reply-To: Info-TCPware@process.com
Message-ID: <389da07f$1@news.kapsch.co.at>
Date: 6 Feb 2000 17:25:35 +0100
To: Info-TCPware@PROCESS.COM

After I upgraded to TCPware V5.4-3 (with the FTP ECO), anonymous FTP does
no longer work here. Login is ok, but a DIR gives a

	"550 Request not permitted for user."

On the definition of the user, or on the directory nothing changed. Only FTP.
I tried various things, but so far no success.

Any ideas/comments ?

-- 
Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651
Network and OpenVMS system manager  Fax.    +43 1 81111-888
FBFV/Information Services           E-mail  eplan@kapsch.net
<<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLAN
A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"
"VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998
================================================================================
Archive-Date: Sun, 6 Feb 2000 11:37:56 -0500
Subject: Re: ANONYMOUS FTP Problems after TCPware V5.4 upgrade
From: eplan@kapsch.net (Peter LANGSTOEGER)
Reply-To: Info-TCPware@process.com
Message-ID: <389da1e8@news.kapsch.co.at>
Date: 6 Feb 2000 17:31:36 +0100
To: Info-TCPware@PROCESS.COM

In article <389da07f$1@news.kapsch.co.at>, eplan@kapsch.net (Peter LANGSTOEGER) writes:
>After I upgraded to TCPware V5.4-3 (with the FTP ECO), anonymous FTP does
>no longer work here. Login is ok, but a DIR gives a
>
>	"550 Request not permitted for user."
>
>On the definition of the user, or on the directory nothing changed. Only FTP.
>I tried various things, but so far no success.
>
>Any ideas/comments ?

Sorry, I forgot to add: Now some silly OPCOM messages are generated:

Message from user ANONYMOUS on MARS
Ftp Server: request for no optional messages detected

Maybe they are related.

-- 
Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651
Network and OpenVMS system manager  Fax.    +43 1 81111-888
FBFV/Information Services           E-mail  eplan@kapsch.net
<<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLAN
A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"
"VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998
================================================================================
Archive-Date: Mon, 7 Feb 2000 08:09:17 -0500
Message-ID: <63D30D6E10CFD11190A90000F805FE8602455A3C@lespaul.process.com>
From: Richard Whalen <Whalenr@process.com>
Reply-To: Info-TCPware@process.com
To: "'Info-TCPware@process.com'" <Info-TCPware@process.com>
Subject: RE: ANONYMOUS FTP Problems after TCPware V5.4 upgrade
Date: Mon, 7 Feb 2000 08:04:58 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

What is the value of the logical TCPWARE_FTP_ANONYMOUS_ROOT ?
What is the default directory for ANONYMOUS?
Was a CD done before the DIR command?

-----Original Message-----
From: eplan@kapsch.net [mailto:eplan@kapsch.net]
Sent: Sunday, February 06, 2000 11:26 AM
To: Info-TCPware@PROCESS.COM
Subject: ANONYMOUS FTP Problems after TCPware V5.4 upgrade



After I upgraded to TCPware V5.4-3 (with the FTP ECO), anonymous FTP does
no longer work here. Login is ok, but a DIR gives a

	"550 Request not permitted for user."

On the definition of the user, or on the directory nothing changed. Only
FTP.
I tried various things, but so far no success.

Any ideas/comments ?

-- 
Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651
Network and OpenVMS system manager  Fax.    +43 1 81111-888
FBFV/Information Services           E-mail  eplan@kapsch.net
<<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLAN
A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"
"VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq,
22-Sep-1998
================================================================================
Archive-Date: Mon, 7 Feb 2000 08:17:06 -0500
Message-ID: <63D30D6E10CFD11190A90000F805FE8602455A3D@lespaul.process.com>
From: Richard Whalen <Whalenr@process.com>
Reply-To: Info-TCPware@process.com
To: "'Info-TCPware@process.com'" <Info-TCPware@process.com>
Subject: RE: ANONYMOUS FTP Problems after TCPware V5.4 upgrade
Date: Mon, 7 Feb 2000 08:12:50 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

That is a debugging message that was accidentally left in the code.
That particular code path should only be reached when the password begins
with a '-' (minus sign)

-----Original Message-----
From: eplan@kapsch.net [mailto:eplan@kapsch.net]
Sent: Sunday, February 06, 2000 11:32 AM
To: Info-TCPware@PROCESS.COM
Subject: Re: ANONYMOUS FTP Problems after TCPware V5.4 upgrade



In article <389da07f$1@news.kapsch.co.at>, eplan@kapsch.net (Peter
LANGSTOEGER) writes:
>After I upgraded to TCPware V5.4-3 (with the FTP ECO), anonymous FTP does
>no longer work here. Login is ok, but a DIR gives a
>
>	"550 Request not permitted for user."
>
>On the definition of the user, or on the directory nothing changed. Only
FTP.
>I tried various things, but so far no success.
>
>Any ideas/comments ?

Sorry, I forgot to add: Now some silly OPCOM messages are generated:

Message from user ANONYMOUS on MARS
Ftp Server: request for no optional messages detected

Maybe they are related.

-- 
Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651
Network and OpenVMS system manager  Fax.    +43 1 81111-888
FBFV/Information Services           E-mail  eplan@kapsch.net
<<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLAN
A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"
"VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq,
22-Sep-1998
================================================================================
Archive-Date: Mon, 7 Feb 2000 11:24:19 -0500
Subject: RE: ANONYMOUS FTP Problems after TCPware V5.4 upgrade
From: eplan@kapsch.net (Peter LANGSTOEGER)
Reply-To: Info-TCPware@process.com
Message-ID: <389eefb0$1@news.kapsch.co.at>
Date: 7 Feb 2000 17:15:44 +0100
To: Info-TCPware@PROCESS.COM

In article <63D30D6E10CFD11190A90000F805FE8602455A3D@lespaul.process.com>, Richard Whalen <Whalenr@process.com> writes:
>That is a debugging message that was accidentally left in the code.
>That particular code path should only be reached when the password begins
>with a '-' (minus sign)

Ok. I did use a minus sign.

I thought, it is common practice, if adding a minus sign to the password,
that the FTP server then omits the "long 220 message" and gives only the
one-line "standard/default 220 message" and so I'm used to it for years now.

I must admit, I haven't checked in docu or RFC about the real status.
Is it common practice ? Or a standard ? Which RFC ?
Or only a long forgotten feature of one/few FTP server implementation(s) ?

-- 
Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651
Network and OpenVMS system manager  Fax.    +43 1 81111-888
FBFV/Information Services           E-mail  eplan@kapsch.net
<<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLAN
A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"
"VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998
================================================================================
Archive-Date: Mon, 7 Feb 2000 11:24:26 -0500
Subject: RE: ANONYMOUS FTP Problems after TCPware V5.4 upgrade
From: eplan@kapsch.net (Peter LANGSTOEGER)
Reply-To: Info-TCPware@process.com
Message-ID: <389eee58$1@news.kapsch.co.at>
Date: 7 Feb 2000 17:10:00 +0100
To: Info-TCPware@PROCESS.COM

In article <63D30D6E10CFD11190A90000F805FE8602455A3C@lespaul.process.com>, Richard Whalen <Whalenr@process.com> writes:
>What is the value of the logical TCPWARE_FTP_ANONYMOUS_ROOT ?

It is a concealed logical (as suggested/working in V5.3 - see mgmt pg. 11-4)
and is exactly the problem. Redefine it as nonconcealed and voila.
Why did this change (without notification) ?

-- 
Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651
Network and OpenVMS system manager  Fax.    +43 1 81111-888
FBFV/Information Services           E-mail  eplan@kapsch.net
<<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLAN
A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"
"VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998
================================================================================
Archive-Date: Mon, 7 Feb 2000 11:28:35 -0500
Message-ID: <63D30D6E10CFD11190A90000F805FE8602455A40@lespaul.process.com>
From: Richard Whalen <Whalenr@process.com>
Reply-To: Info-TCPware@process.com
To: "'Info-TCPware@process.com'" <Info-TCPware@process.com>
Subject: RE: ANONYMOUS FTP Problems after TCPware V5.4 upgrade
Date: Mon, 7 Feb 2000 11:24:20 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

I don't know if it's in the RFC, but it is in the TCPware documentation that
if you start the password with a minus sign then you don't get a long 220
message.

-----Original Message-----
From: eplan@kapsch.net [mailto:eplan@kapsch.net]
Sent: Monday, February 07, 2000 11:16 AM
To: Info-TCPware@PROCESS.COM
Subject: RE: ANONYMOUS FTP Problems after TCPware V5.4 upgrade



In article <63D30D6E10CFD11190A90000F805FE8602455A3D@lespaul.process.com>,
Richard Whalen <Whalenr@process.com> writes:
>That is a debugging message that was accidentally left in the code.
>That particular code path should only be reached when the password begins
>with a '-' (minus sign)

Ok. I did use a minus sign.

I thought, it is common practice, if adding a minus sign to the password,
that the FTP server then omits the "long 220 message" and gives only the
one-line "standard/default 220 message" and so I'm used to it for years now.

I must admit, I haven't checked in docu or RFC about the real status.
Is it common practice ? Or a standard ? Which RFC ?
Or only a long forgotten feature of one/few FTP server implementation(s) ?

-- 
Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651
Network and OpenVMS system manager  Fax.    +43 1 81111-888
FBFV/Information Services           E-mail  eplan@kapsch.net
<<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLAN
A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"
"VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq,
22-Sep-1998
================================================================================
Archive-Date: Mon, 7 Feb 2000 11:29:43 -0500
Message-ID: <63D30D6E10CFD11190A90000F805FE8602455A41@lespaul.process.com>
From: Richard Whalen <Whalenr@process.com>
Reply-To: Info-TCPware@process.com
To: "'Info-TCPware@process.com'" <Info-TCPware@process.com>
Subject: RE: ANONYMOUS FTP Problems after TCPware V5.4 upgrade
Date: Mon, 7 Feb 2000 11:25:23 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

I don't know exactly why it changed, but we should now have enough
information to look into your problem.

-----Original Message-----
From: eplan@kapsch.net [mailto:eplan@kapsch.net]
Sent: Monday, February 07, 2000 11:10 AM
To: Info-TCPware@PROCESS.COM
Subject: RE: ANONYMOUS FTP Problems after TCPware V5.4 upgrade



In article <63D30D6E10CFD11190A90000F805FE8602455A3C@lespaul.process.com>,
Richard Whalen <Whalenr@process.com> writes:
>What is the value of the logical TCPWARE_FTP_ANONYMOUS_ROOT ?

It is a concealed logical (as suggested/working in V5.3 - see mgmt pg. 11-4)
and is exactly the problem. Redefine it as nonconcealed and voila.
Why did this change (without notification) ?

-- 
Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651
Network and OpenVMS system manager  Fax.    +43 1 81111-888
FBFV/Information Services           E-mail  eplan@kapsch.net
<<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLAN
A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"
"VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq,
22-Sep-1998
================================================================================
Archive-Date: Mon, 7 Feb 2000 11:43:00 -0500
Subject: RE: ANONYMOUS FTP Problems after TCPware V5.4 upgrade
From: eplan@kapsch.net (Peter LANGSTOEGER)
Reply-To: Info-TCPware@process.com
Message-ID: <389ef332$1@news.kapsch.co.at>
Date: 7 Feb 2000 17:30:42 +0100
To: Info-TCPware@PROCESS.COM

In article <63D30D6E10CFD11190A90000F805FE8602455A40@lespaul.process.com>, Richard Whalen <Whalenr@process.com> writes:
>Peter LANGSTOEGER (eplan@kapsch.net) wrote,
>>I thought, it is common practice, if adding a minus sign to the password,
>>that the FTP server then omits the "long 220 message" and gives only the
>>one-line "standard/default 220 message" and so I'm used to it for years now.
>
>I don't know if it's in the RFC, but it is in the TCPware documentation that
>if you start the password with a minus sign then you don't get a long 220
>message.

Where ? I did look for it before my last post, but have been unsuccessful.

-- 
Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651
Network and OpenVMS system manager  Fax.    +43 1 81111-888
FBFV/Information Services           E-mail  eplan@kapsch.net
<<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLAN
A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"
"VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998
================================================================================
Archive-Date: Mon, 7 Feb 2000 11:54:32 -0500
Message-ID: <63D30D6E10CFD11190A90000F805FE8602455A42@lespaul.process.com>
From: Richard Whalen <Whalenr@process.com>
Reply-To: Info-TCPware@process.com
To: "'Info-TCPware@process.com'" <Info-TCPware@process.com>
Subject: RE: ANONYMOUS FTP Problems after TCPware V5.4 upgrade
Date: Mon, 7 Feb 2000 11:50:12 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

The Management Guide, under the "Implementation" section, in the detail on
the PASS command.
The following URL will get you to the right page:
http://www.process.com/openvms/MANAGEMENT/Ch11.htm#E13E78

-----Original Message-----
From: eplan@kapsch.net [mailto:eplan@kapsch.net]
Sent: Monday, February 07, 2000 11:31 AM
To: Info-TCPware@PROCESS.COM
Subject: RE: ANONYMOUS FTP Problems after TCPware V5.4 upgrade



In article <63D30D6E10CFD11190A90000F805FE8602455A40@lespaul.process.com>,
Richard Whalen <Whalenr@process.com> writes:
>Peter LANGSTOEGER (eplan@kapsch.net) wrote,
>>I thought, it is common practice, if adding a minus sign to the password,
>>that the FTP server then omits the "long 220 message" and gives only the
>>one-line "standard/default 220 message" and so I'm used to it for years
now.
>
>I don't know if it's in the RFC, but it is in the TCPware documentation
that
>if you start the password with a minus sign then you don't get a long 220
>message.

Where ? I did look for it before my last post, but have been unsuccessful.

-- 
Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651
Network and OpenVMS system manager  Fax.    +43 1 81111-888
FBFV/Information Services           E-mail  eplan@kapsch.net
<<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLAN
A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"
"VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq,
22-Sep-1998
================================================================================
Archive-Date: Mon, 7 Feb 2000 12:08:20 -0500
Subject: RE: ANONYMOUS FTP Problems after TCPware V5.4 upgrade
From: eplan@kapsch.net (Peter LANGSTOEGER)
Reply-To: Info-TCPware@process.com
Message-ID: <389ef85f$1@news.kapsch.co.at>
Date: 7 Feb 2000 17:52:47 +0100
To: Info-TCPware@PROCESS.COM

In article <63D30D6E10CFD11190A90000F805FE8602455A41@lespaul.process.com>, Richard Whalen <Whalenr@process.com> writes:
>I don't know exactly why it changed, but we should now have enough
>information to look into your problem.

User ANONYMOUS has DISK$SW:[ANONYMOUS] as default.

TCPWARE_FTP_ANONYMOUS_ROOT used to be DISK$SW:[ANONYMOUS.] /concealed
and worked like a champ.

Now I have to define

TCPWARE_FTP_ANONYMOUS_ROOT	as	ANON_ROOT:	and
ANON_ROOT			as	DISK$SW:[ANONYMOUS.] /concealed

or (not so good) define

TCPWARE_FTP_ANONYMOUS_ROOT	as	DISK$SW:[ANONYMOUS]

but have then obviously problems with CD [000000] (but not with CD "/").

HIH

-- 
Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651
Network and OpenVMS system manager  Fax.    +43 1 81111-888
FBFV/Information Services           E-mail  eplan@kapsch.net
<<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLAN
A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"
"VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998
================================================================================
Archive-Date: Wed, 9 Feb 2000 11:29:29 -0500
Date: Wed, 09 Feb 2000 11:24:45 -0500 (EST)
From: bryant@PROCESS.COM
Reply-To: Info-TCPware@process.com
Subject: TCPware ECO kit available: NAMED_V543P031
To: TCPware-Announce@PROCESS.COM
Message-ID: <01JLPA6HFUIQ000DMD@DELTA.PROCESS.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

TCPware ECO kit announcement

The following ECO kit is now available for TCPware:

    ECO:          NAMED_V543P031
    Description:  Fix nameserver hang, add sortlist support, backup zone file change
    Release date: 9-FEB-2000
    Versions:     5.4-3

  ftp://ftp.process.com/support/54_3/named_v543p031.zip

To search the TCPware ECO database, please visit the following URL:

        http://vms.process.com/eco.html

For more information, contact Process Software via:

     E-mail:    support@process.com
     Phone:     1-800-394-8700

The ECO kit README contents are below.

------------------------------------------------------------------------------
TCPware_NAMED Patch kit (revision 3.1) for TCPware version 5.4-3    7-FEB-2000

Copyright (c) 1999-2000, by Process Software Corporation

        This VMSinstallable saveset provides a new version of NameD and 
        NameD-Xfer for TCPware for OpenVMS.  NameD must be restarted after
        installation of this patch.

        Applicable TCPware and VMS versions: 

            TCPware 5.4 on all supported VAX/VMS and AXP/VMS systems

        The following change[s] has been made:

            - a timing issue has been corrected.  With the right timing, the
              nameserver could hang intermittently. (D/E 5175)

            - BIND Version 8 had removed a feature called "sortlist" that was
              present in BIND Version 4.  A side effect of this feature was
              that queries from a source on the same subnet as one of the
              servers interfaces could result in a response with a fixed
              order.  If the server found any of the A records in the answer
              to be in the same subnet as the common subnet between the client
              and the server, the server would place that A record first in
              the answer.

              This default part of the feature has been added back with this
              kit.  To enable the feature, you must define the system exec
              logical "TCPWARE_NAMED_PREFER_LOCAL_ADDR" and restart your 
              Nameserver.

              When BIND 8.2 is released for TCPware, this logical will no
              longer provide this feature, and you will need to add the
              following statements to the options {}; section of your
              NAMED.CONF File to gain the results:

                  sortlist {
                        { localhost; localnets; };
                        { localnets; };
                  };

              (D/E 5579)

            - Secondary servers no longer create a new version of the backup
              zone file when it transfers the zone, it now replaces the old
              file with the new file.  Customers are encouraged to check the
              directories where their backup zone files are stored, and purge
              the excess if desired.  (D/E 5206)

	This kit also contains the following changes from previous kits:

        NAMED_V543P020
        --------------
          IP AddressWorks related changes:
            Improved handling of errors trying to communicate with the Server
            Manager.

        NAMED_V543P010
        --------------
            A problem where the nameserver would hang indefinately if 
            reloaded has been fixed. This occurred when the server was
            done sending the data for a zone transfer, but the client 
            requesting the zone transfer had not yet closed its end of
            the connection.

            System managers experiencing this problem may notice lingering 
            TCP connections to the domain port on the system in FIN-WAIT-2
            state.  If this is a problem it is recommended the system manager
            take steps to disallow that remote system from doing zone 
            transfers [see the documentation on the allow-transfers statement
            in the NameD configuration].
 
        The old version of TCPWARE:NAMED.EXE will be renamed to 
                TCPWARE:NAMED.EXE_OLD
        The old version of TCPWARE:NAMED-XFER.EXE will be renamed to 
                TCPWARE:NAMED-XFER.EXE_OLD

        To restart NameD after install, use:

                @TCPWARE:RESTART DNS

        Once installed, you may undo this patch by renaming the files back to
        TCPWARE:NAMED.EXE and TCPWARE:NAMED-XFER.EXE.



[End of ECO announcement]
================================================================================
Archive-Date: Thu, 10 Feb 2000 03:35:49 -0500
Message-ID: <38A2774C.70540B25@ozemail.com.au>
Date: Thu, 10 Feb 2000 18:01:09 +0930
From: "Brian A. Haynes" <bahaynes@ozemail.com.au>
Reply-To: Info-TCPware@process.com
MIME-Version: 1.0
To: TCPware <Info-TCPware@process.com>
Subject: Purveyor
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If I understand correctly that the Purveyor Encrypt Web Server for
OpenVMS is no longer being sold or supported, how about giving it away?
It's a good server, and I'm used to it, so I'd like to use it on my
systems rather than having to learn how to install and configure the
other freeware or open source web servers.  How about it?

Brian Haynes
Raytheon

================================================================================
Archive-Date: Mon, 14 Feb 2000 09:21:01 -0500
Message-ID: <38A80E34.F84BBC20@PROCESS.COM>
Date: Mon, 14 Feb 2000 09:16:20 -0500
From: Michael Corbett <corbett@PROCESS.COM>
Reply-To: Info-TCPware@process.com
MIME-Version: 1.0
To: info-tcpware@process.com
Subject: RE: Purveyor
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> 
> If I understand correctly that the Purveyor Encrypt Web Server for
> OpenVMS is no longer being sold or supported, how about giving it away?
> It's a good server, and I'm used to it, so I'd like to use it on my
> systems rather than having to learn how to install and configure the
> other freeware or open source web servers.  How about it?
> 
> Brian Haynes
> Raytheon
> 

Just a point of clarification - we will still sell licenses for Purveyor but
we are no longer selling support contracts.  

regards
Mike
-- 
+-------------------------------------------------------------------------+
Michael Corbett                           Email: Corbett@process.com
Process Software Corporation              Phone: 800 722-7770 x369
959 Concord St.                                  508 879-6994 x369
Framingham MA 01701-4682                  FAX:   508 879-0042
================================================================================
Archive-Date: Mon, 14 Feb 2000 11:13:38 -0500
Date: Mon, 14 Feb 2000 10:09:02 -0600
From: Hunter Goatley <goathunter@process.com>
Reply-To: Info-TCPware@process.com
To: Info-TCPware@process.com
Message-ID: <000214100902.202000c3@process.com>
Subject: Invitation to join MultiNet & TCPware Teleconference

Process Software invites all MultiNet and TCPware customers to participate
in:

      Online MultiNet and TCPware TCP/IP TeleConference
      February 17th
      1-1:45pm EST

Process Software's Senior Engineering and Product Marketing teams will
bring you information on maximizing your TCP/IP for  OpenVMS product and
learning about upcoming technologies and product advancements.
Teleconference will cover:

- TCPware and MultiNet Product Roadmaps for 2000
- Optimizing the performance of Process Software's TCP/IP stacks
- Introduction on Process Software's Paired Network Interface feature
  which increases your networks throughput and adds reliability 
- Performance testing results
- Question and answer period for participants

Register now for the conference at
http://www.process.com/aspscripts/telebrief/
================================================================================
Archive-Date: Mon, 14 Feb 2000 11:21:12 -0500
Message-ID: <75E5B8E274DBD1118D6800805FE60E7703A68770@ntprdex4.admin.liffe.com>
From: Andy Williams <Andy.Williams@liffe.com>
Reply-To: Info-TCPware@process.com
To: Info-TCPware@process.com
Subject: Using NTP to keep system time
Date: Mon, 14 Feb 2000 16:16:22 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Configuration: OpenVMS VAX V6.2, TCPware V5.3-2
We currently have a huge number of VAX and Alpha systems, most of which run
TCPware. I have a job that runs on a monthly basis that sweeps around all
VMS systems & performs a basic QA of the system from the VMS point of view:
any missing processes, disks offline or in mount verification, etc. etc.
One of the checks it performs is to verify the system time, and every month
it finds at least two or three boxes where the system clock is out by 5
minutes or more. Certainly for the last 3 months these have all been
different systems, but even so, each one of these systems is running NTP. In
fact, to correct the system time I simply do a SHUTNET on NTP, run NTPDATE
"-bs" & then do a STARTNET for NTP. We have two timeservers and all the
errant systems can see both; there are regular messages in the operator log
file telling me it's acquiring the peer or selecting a new synch source or
becoming free running again but nothing mentioning a clock reset.
The strange thing is that it only appears on a very small number of systems.
It's just that they seem to be different ones every time. The NTP.CONF file
simply has:
server xxx.xxx.xxx.xxx
server yyy.yyy.yyy.yyy

in it. Should I be doing something different to ensure accurate times or am
I off track in my expectations ? If so, why do the majority of systems seem
to work OK ?

Thanks for any advice,

-Andy





----------------------------------------------------------------------
The information contained in this e-mail is confidential and solely for the intended addressee(s). Unauthorised reproduction, disclosure, modification, and/or distribution of this email may be unlawful. If you have received this email in error, please notify the sender immediately and delete it from your system. The views expressed in this message do not necessarily reflect those of LIFFE (Holdings) Plc or any of its subsidiary companies.
----------------------------------------------------------------------
================================================================================
Archive-Date: Tue, 15 Feb 2000 04:49:06 -0500
Message-ID: <38A91FF6.5046A543@ozemail.com.au>
Date: Tue, 15 Feb 2000 19:14:22 +0930
From: "Brian A. Haynes" <bahaynes@ozemail.com.au>
Reply-To: Info-TCPware@process.com
MIME-Version: 1.0
To: Info-TCPware@process.com
Subject: Re: Using NTP to keep system time
References: <75E5B8E274DBD1118D6800805FE60E7703A68770@ntprdex4.admin.liffe.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If you are running DECnet-Plus on those systems, make sure you have DTSS turned off, or it will conflict with NTP.

Brian Haynes



Andy Williams wrote:

> Configuration: OpenVMS VAX V6.2, TCPware V5.3-2
> We currently have a huge number of VAX and Alpha systems, most of which run
> TCPware. I have a job that runs on a monthly basis that sweeps around all
> VMS systems & performs a basic QA of the system from the VMS point of view:
> any missing processes, disks offline or in mount verification, etc. etc.
> One of the checks it performs is to verify the system time, and every month
> it finds at least two or three boxes where the system clock is out by 5
> minutes or more. Certainly for the last 3 months these have all been
> different systems, but even so, each one of these systems is running NTP. In
> fact, to correct the system time I simply do a SHUTNET on NTP, run NTPDATE
> "-bs" & then do a STARTNET for NTP. We have two timeservers and all the
> errant systems can see both; there are regular messages in the operator log
> file telling me it's acquiring the peer or selecting a new synch source or
> becoming free running again but nothing mentioning a clock reset.
> The strange thing is that it only appears on a very small number of systems.
> It's just that they seem to be different ones every time. The NTP.CONF file
> simply has:
> server xxx.xxx.xxx.xxx
> server yyy.yyy.yyy.yyy
>
> in it. Should I be doing something different to ensure accurate times or am
> I off track in my expectations ? If so, why do the majority of systems seem
> to work OK ?
>
> Thanks for any advice,
>
> -Andy
>
> ----------------------------------------------------------------------
> The information contained in this e-mail is confidential and solely for the intended addressee(s). Unauthorised reproduction, disclosure, modification, and/or distribution of this email may be unlawful. If you have received this email in error, please notify the sender immediately and delete it from your system. The views expressed in this message do not necessarily reflect those of LIFFE (Holdings) Plc or any of its subsidiary companies.
> ----------------------------------------------------------------------

================================================================================
Archive-Date: Tue, 15 Feb 2000 04:57:52 -0500
Message-ID: <75E5B8E274DBD1118D6800805FE60E7703A68777@ntprdex4.admin.liffe.com>
From: Andy Williams <Andy.Williams@liffe.com>
Reply-To: Info-TCPware@process.com
To: "'Info-TCPware@process.com'" <Info-TCPware@process.com>
CC: "'bahaynes@ozmail.com.au'" <bahaynes@ozmail.com.au>
Subject: RE: Using NTP to keep system time
Date: Tue, 15 Feb 2000 09:52:55 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Thanks for the tip Brian, but no, we're running plain old DECnet phase IV...

Andy Williams
OpenVMS System Specialist
Andy.Williams@LIFFE.nospam.com
+44 171 379 2581



-----Original Message-----
From: Brian A. Haynes [mailto:bahaynes@ozemail.com.au]
Sent: Tuesday, February 15, 2000 9:44 AM
To: Info-TCPware@process.com
Subject: Re: Using NTP to keep system time

If you are running DECnet-Plus on those systems, make sure you have DTSS
turned off, or it will conflict with NTP.

Brian Haynes



----------------------------------------------------------------------
The information contained in this e-mail is confidential and solely for the intended addressee(s). Unauthorised reproduction, disclosure, modification, and/or distribution of this email may be unlawful. If you have received this email in error, please notify the sender immediately and delete it from your system. The views expressed in this message do not necessarily reflect those of LIFFE (Holdings) Plc or any of its subsidiary companies.
----------------------------------------------------------------------
================================================================================
Archive-Date: Wed, 16 Feb 2000 15:26:17 -0500
Sender: goathunter@PROCESS.COM
Message-ID: <009E5C11.9DA309D6.3@goat.process.com>
From: Tom Ricci <Ricci@process.com>
Reply-To: Info-TCPware@process.com
To: Info-TCPware <Info-TCPware@process.com>
Subject: DNSworks Beta 2 Now Available
Date: Wed, 16 Feb 2000 09:28:45 -0500

DNSworks Beta 2 Now Available
Many thanks to those of you have registered for Process Software's DNSworks
free online Domain analysis and optimization service beta program.  With
your help, we have fixed the reported bugs and been able to enhance the
service.  Hopefully you have benefited from the DNS analysis reporting and
solutions online service.  In Beta 2, we have made the scheduling service
fully functional.  You can now enter the domains to be analyzed once,
schedule analyses to be run in the background, and receive HTML reports
daily, weekly, or monthly, as you prefer, via email.  No other interaction
is required.

If you have already registered for the service, simply return to your
Service profile and select the frequency to run reports.  If you haven't
tried the service yet, go to http://www.dnsworks.com and register as a first
time user, follow the menu, and you'll be up and running in minutes.

Thank you again for your participation.  All participants who return the
Beta feedback form will receive a gift and entered into a drawing for a Palm
Pilot.  The beta program will end by the end of the month.

Tom Ricci





=======================================
Tom Ricci, Director of Marketing Communications
Process Software Corporation
959 Concord St., Framingham, MA  01701
(508) 626-7546/FAX: (508) 879-0042
ricci@process.com / www.process.com
=======================================

================================================================================
Archive-Date: Thu, 17 Feb 2000 16:46:10 -0500
Date: Thu, 17 Feb 2000 16:40:57 -0500 (EST)
From: bryant@PROCESS.COM
Reply-To: Info-TCPware@process.com
Subject: TCPware ECO kit available: FTP_V543P030
To: TCPware-Announce@PROCESS.COM
Message-ID: <01JM0RJB1ZIQ000L3O@DELTA.PROCESS.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

TCPware ECO kit announcement

The following ECO kit is now available for TCPware:

    ECO:          FTP_V543P030
    Description:  Image transfer mode of VAR-CRCC files no longer inserts new line after each line
    Release date: 17-FEB-2000
    Versions:     V5.4-3

  ftp://ftp.process.com/support/54_3/ftp_v543p030.zip

To search the TCPware ECO database, please visit the following URL:

        http://vms.process.com/eco.html

For more information, contact Process Software via:

     E-mail:    support@process.com
     Phone:     1-800-394-8700

The ECO kit README contents are below.

-----------------------------------------------------------
-----------------------------------------------------------------------
FTP Patch kit (revision 3.0) for TCPware version 5.4-3   16-Feb-2000

Copyright (c) 2000, by Process Software Corporation

        This VMSinstallable saveset provides a new versions of
	FTP_CONTROL.COM, FTP_LISTENER.EXE, and FTP_SERVER.EXE
        for TCPware for OpenVMS.
                TCPWare V5.4-3 and later
                VMS/VAX V5.5-2 and later
                VMS/ALPHA V6.1 and later

        The following change[s] has been made:

FTP_CONTROL.COM now asks if you wish to provide FTP service in the
configuration phase. (DE 5058)

FTP_LISTENER.EXE
- A problem which caused the wrong IP addresses to be displayed in the log
file has been corrected. (DE 5285)
- A possible denial of service attack has been corrected. (DE 5347) To control
how much time can elapse before the connection is killed if it is not
successfully authorized as an FTP user define TCPWARE_FTP_IDLE_TIMEOUT.
The format for this logical is the delta time (dddd hh:mm:ss.hh) that can
elapse between when the connection is established and when it must be
successfully logged in.  The default value for this is 10 minutes.

FTP_SERVER.EXE
- The default window size increased to improve performance of GET operations. (DE 5195)
- A problem with incorrect IP addresses in the log file has been corrected. (DE 5285)
- A data corruption problem has been corrected. (DE 5298)
- When the logical TCPWARE_FTP_SEMANTICS_VARIABLE_IGNORE_CC is defined to
  TRUE files with variable length records and carriage return carriage control
  will NOT have a new line character inserted after each line when the
  file is transfered in image (binary) mode.  This logical is now defined
  to be TRUE by default in FTPSERVER_DTP.COM, returning to the behavior
  present in TCPWare 5.3 (DE 5709)
- Correct a problem that can occur when deleting files on a VAX from an NT
  system where the error "%LIB-F-INVSTRDES, invalid string descriptor"
  could occur. (DE 5722)

[End of ECO announcement]
================================================================================
Archive-Date: Fri, 18 Feb 2000 08:38:55 -0500
From: <Bob_Drennon@via-christi.org>
Reply-To: Info-TCPware@process.com
To: Info-TCPware@process.com
Message-ID: <86256889.004A5ACB.00@vchub.via-christi.org>
Date: Fri, 18 Feb 2000 07:36:26 -0600
Subject: Question on MPSYNC patch for Multinet
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

In the teleconference, you spoke of the MPSYNC performance related patch for
Multinet 4.2.  Can this be applied to 4.1?  Here is response from Multinet Show
/Version:

B$ multi show/version
Process Software MultiNet V4.1 Rev A-X, AlphaServer 8400 5/440, OpenVMS AXP
V6.2-1H3

I was expecting a little more in you presentation on "tuning" or such that one
would want to look at to insure Multinet is performing at well as possible.  So
please let me ask one question regarding our current environment, expection only
some generalities on your part, as you obvisously do not know specifics of our
system nor our network (which is the responsibility of another group).  An
overview though, our network is based on Xylan switched ethernet with ATM
between chassis and other campuses.  It is flat architecture, using virtual
lans,  i.e no mater what part of town you are in, if they set the port for
10.1.x.x , you see all other 10.1.x.x devices.  VMS system are in the 10.3.x.x
VLAN (as we are the outcast) to isolate DEC protocol traffic.  So, getting to
the question, users see keyboard delays using telnet to our system, yet not from
another system using ucx 4.2, (and this is a heavyly loaded axp 1000), and OUR
LAT users see no delay.  Of course, if there is some serious network traffic,
all suffer, but our box, and the TCP/IP protoclol suffer the most, (i.e. during
a broadcast storm or other network related problem).  Are there any areas we
should look in on our system where we might improve Multinet performance?  (btw,
we are a Cerner client, and Multinet is sublicensed through them).

Thanks,
Bob Drennon
Via Christi Health System
Wichita, KS
316-291-4393



================================================================================
Archive-Date: Fri, 18 Feb 2000 09:39:42 -0500
Date: Fri, 18 Feb 2000 8:38:56 -0600
From: Hunter Goatley <goathunter@process.com>
Reply-To: Info-TCPware@process.com
To: MultiNet-Announce@LISTS.PROCESS.COM, TCPware-Announce@LISTS.PROCESS.COM
Message-ID: <000218083856.202000b9@process.com>
Subject: Process Software TCP/IP Telebriefing replay now available

On Thursday, 17-FEB-2000, Process Software held a TCP/IP telebriefing
for our customers.

If you could not attend, we are providing a replay of the
telebriefing, available now through 24-FEB-2000 at the following
numbers:

USA #:  800-475-6701
International #: 320-365-3844

After dialing the number, please enter the following access code when
prompted: 501570

Here is the original description:
>
>Process Software is pleased that you will be joining our MultiNet and
>TCPware TCP/IP Telebriefing this Thursday, February 17th at 1:00pm EST. 
>   
>Our engineering and marketing team look forward to providing you information
>on maximizing your TCP/IP for OpenVMS product and learning about upcoming
>technologies and product advancements.  The Telebriefing will cover:
>
>- TCPware and MultiNet Product Roadmaps for 2000
>- Optimizing the performance of Process Software's TCP/IP stacks
>- Introduction on Process Software's Paired Network Interface feature
>  which increases your networks throughput and adds reliability 
>- Performance testing results
>- Question and answer period for participants



Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
<goathunter@PROCESS.COM>     http://www2.wku.edu/hunter/
================================================================================
Archive-Date: Fri, 18 Feb 2000 10:35:07 -0500
Message-ID: <4.2.2.20000218083204.00ccfe20@mehlhop.org>
Date: Fri, 18 Feb 2000 08:34:52 -0700
To: Info-TCPware@process.com, info-multinet@process.com
From: Jim Mehlhop <mehlhop@process.com>
Reply-To: Info-TCPware@process.com
Subject: Re: Question on MPSYNC patch for Multinet
In-Reply-To: <86256889.004A5ACB.00@vchub.via-christi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Yes the  kernel-update-021_a042 eco can be installed on MN4.1a or b

Jim

At 07:36 AM 2/18/00 -0600, you wrote:
>In the teleconference, you spoke of the MPSYNC performance related patch for
>Multinet 4.2.  Can this be applied to 4.1?  Here is response from Multinet 
>Show
>/Version:
>
>B$ multi show/version
>Process Software MultiNet V4.1 Rev A-X, AlphaServer 8400 5/440, OpenVMS AXP
>V6.2-1H3
>
>I was expecting a little more in you presentation on "tuning" or such that one
>would want to look at to insure Multinet is performing at well as 
>possible.  So
>please let me ask one question regarding our current environment, 
>expection only
>some generalities on your part, as you obvisously do not know specifics of our
>system nor our network (which is the responsibility of another group).  An
>overview though, our network is based on Xylan switched ethernet with ATM
>between chassis and other campuses.  It is flat architecture, using virtual
>lans,  i.e no mater what part of town you are in, if they set the port for
>10.1.x.x , you see all other 10.1.x.x devices.  VMS system are in the 10.3.x.x
>VLAN (as we are the outcast) to isolate DEC protocol traffic.  So, getting to
>the question, users see keyboard delays using telnet to our system, yet 
>not from
>another system using ucx 4.2, (and this is a heavyly loaded axp 1000), and OUR
>LAT users see no delay.  Of course, if there is some serious network traffic,
>all suffer, but our box, and the TCP/IP protoclol suffer the most, (i.e. 
>during
>a broadcast storm or other network related problem).  Are there any areas we
>should look in on our system where we might improve Multinet 
>performance?  (btw,
>we are a Cerner client, and Multinet is sublicensed through them).
>
>Thanks,
>Bob Drennon
>Via Christi Health System
>Wichita, KS
>316-291-4393

================================================================================
Archive-Date: Mon, 21 Feb 2000 12:47:35 -0500
Message-ID: <001a01bf7c94$2a9b2d40$3a188018@ne.mediaone.net>
From: "Evan D. Wells" <evanwells@mediaone.net>
Reply-To: Info-TCPware@process.com
To: <Info-TCPware@process.com>
Subject: FTP problem after upgrade to TCPWare 5.4-3
Date: Mon, 21 Feb 2000 12:50:39 -0500
MIME-Version: 1.0
Content-Type: text/plain

 === The original message was multipart MIME            ===
 === All non-text parts (attachments) have been removed ===

After upgrading to TCPWare 5.4-3 from 5.3 some PC clients get message =
after password entry "Connection closed by remote host", other accounts =
on the same client are successful. From VMS clients the message is " =
tcpware-f--ctrlerr unexpected error processing control connection"
"virtual circuit closed"

The log file FTPSERVER_DTP.LOG produces the message "process quota =
exceeded"

?

Evan Wells
State Street.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
================================================================================
Archive-Date: Mon, 21 Feb 2000 14:15:47 -0500
From: silversd@aspentech.com (David Silvers)
Reply-To: Info-TCPware@process.com
Subject: NFS 'hanging'
Date: Mon, 21 Feb 2000 17:44:46 GMT
Message-ID: <38b17890.337636672@news.aspentech.com>
To: Info-TCPware@PROCESS.COM

We are running TCPware V5.4-3, on VAX/VMS V6.2, the hardware platform
is a VAX 3300 in a DSSI/NI cluster.  The 3300 NFS shares some
filesystems to unix & NT boxes over a LAN and WAN.  We periodically
experience transient 'hangs' of the NFS resources and frequently the
clients do not see a current view of their data.

I plan on moving the actual data to an alpha which is in the same
cluster and NFS sharing via UCX, unless I can find out what is causing
this problem to occur on the 3300.

Any ideas??? There does not appear to be anything of note recorded in
the NFS logfiles.

David Silvers
AspenTech, Houston TX
================================================================================
Archive-Date: Mon, 21 Feb 2000 15:39:06 -0500
Message-ID: <38B19B4E.D682ABA9@SMTP.DeltaTel.RU>
Date: Mon, 21 Feb 2000 23:08:46 +0300
From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU>
Reply-To: Info-TCPware@process.com
MIME-Version: 1.0
Subject: Re: FTP problem after upgrade to TCPWare 5.4-3
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
To: Info-TCPware@PROCESS.COM

Evan D. Wells wrote:
> 
>  === The original message was multipart MIME            ===
>  === All non-text parts (attachments) have been removed ===
> 
> After upgrading to TCPWare 5.4-3 from 5.3 some PC clients get message =
> after password entry "Connection closed by remote host", other accounts =
> on the same client are successful. From VMS clients the message is " =
> tcpware-f--ctrlerr unexpected error processing control connection"
> "virtual circuit closed"
	
> 
> The log file FTPSERVER_DTP.LOG produces the message "process quota =
> exceeded"

$HELP "process quota exceeded"

> 
> ?
> 
> Evan Wells
> State Street.
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

-- 
Regards.
+.....................pure personal opinion..........................+
    Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM
	Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035
+..... Kick ass VMS solution listening "Nightingales & Bombers" .....+
================================================================================
Archive-Date: Mon, 21 Feb 2000 15:58:52 -0500
Message-ID: <026501bf7cae$e45eb930$3a188018@ne.mediaone.net>
From: "Evan D. Wells" <evanwells@mediaone.net>
Reply-To: Info-TCPware@process.com
To: <Info-TCPware@process.com>
References: <38B19B4E.D682ABA9@SMTP.DeltaTel.RU>
Subject: Re: FTP problem after upgrade to TCPWare 5.4-3
Date: Mon, 21 Feb 2000 16:01:58 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: 7bit

pgflquo modified from 20540 to 200000 fixed the problem.



----- Original Message -----
From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU>
To: <Info-TCPware@process.com>
Sent: Monday, February 21, 2000 3:08 PM
Subject: Re: FTP problem after upgrade to TCPWare 5.4-3



> Evan D. Wells wrote:
> >
> >  === The original message was multipart MIME            ===
> >  === All non-text parts (attachments) have been removed ===
> >
> > After upgrading to TCPWare 5.4-3 from 5.3 some PC clients get message =
> > after password entry "Connection closed by remote host", other accounts
=
> > on the same client are successful. From VMS clients the message is " =
> > tcpware-f--ctrlerr unexpected error processing control connection"
> > "virtual circuit closed"
>
> >
> > The log file FTPSERVER_DTP.LOG produces the message "process quota =
> > exceeded"
>
> $HELP "process quota exceeded"
>
> >
> > ?
> >
> > Evan Wells
> > State Street.
> >
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
>
> --
> Regards.
> +.....................pure personal opinion..........................+
>     Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM
> Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035
> +..... Kick ass VMS solution listening "Nightingales & Bombers" .....+
>

================================================================================
Archive-Date: Tue, 22 Feb 2000 10:08:13 -0500
Message-ID: <38B2A143.45CB089A@SMTP.DeltaTel.RU>
Date: Tue, 22 Feb 2000 17:46:27 +0300
From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU>
Reply-To: Info-TCPware@process.com
MIME-Version: 1.0
Subject: 5.4-3 & Rejection
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
To: Info-TCPware@PROCESS.COM

I have just for testing in rejection file follows lines:
!
! Reject anything with a Message-ID that appears to have originated from
! cyberpromo.com or nowhere.com
!
Message-ID: <*@cyberpromo.com>
Message-ID: <*@nowhere.com>

In OPCOM I periodicaly see messages:

$
%%%%%%%%%%%  OPCOM  22-FEB-2000 17:45:13.37  %%%%%%%%%%%
Message from user SYSTEM on DTV3
PSC SMTP Server: Syntax error in TCPWARE:SMTP_SERVER_REJECT. (line 34) - ACTION field
must be Y, N, or Q

$
%%%%%%%%%%%  OPCOM  22-FEB-2000 17:45:13.38  %%%%%%%%%%%
Message from user SYSTEM on DTV3
PSC SMTP Server: Syntax error in TCPWARE:SMTP_SERVER_REJECT. (line 35) - ACTION field
must be Y, N, or Q



	What is right syntax of this "RFC-822" entry ?

-- 
Cheers,
+OpenVMS [Sys|Net] HardWorker........................................+
 Russia,Delta Telecom JSC,                    Cel:  +7 (901) 971-3222
 191119,St.Petersburg,Transportny per. 3                     116-3222
                                              Fax:  +7 (812) 115-1035
+http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm +
================================================================================
Archive-Date: Tue, 22 Feb 2000 10:16:38 -0500
Date: Tue, 22 Feb 2000 9:16:11 -0600
From: Hunter Goatley <goathunter@process.com>
Reply-To: Info-TCPware@process.com
To: Info-TCPware@process.com
Message-ID: <000222091611.202000c1@process.com>
Subject: RE: 5.4-3 & Rejection

"Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU> writes:
>
>In OPCOM I periodicaly see messages:
>
>$
>%%%%%%%%%%%  OPCOM  22-FEB-2000 17:45:13.37  %%%%%%%%%%%
>Message from user SYSTEM on DTV3
>PSC SMTP Server: Syntax error in TCPWARE:SMTP_SERVER_REJECT. (line 34) - ACTION field
>must be Y, N, or Q
>
[...]
>	What is right syntax of this "RFC-822" entry ?
>
That should be correct.  Can you send me (privately) your entire file?

Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
<goathunter@PROCESS.COM>     http://www2.wku.edu/hunter/
================================================================================
Archive-Date: Tue, 22 Feb 2000 12:53:24 -0500
Message-ID: <38B2C145.F5E3592@SMTP.DeltaTel.RU>
Date: Tue, 22 Feb 2000 20:03:01 +0300
From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU>
Reply-To: Info-TCPware@process.com
MIME-Version: 1.0
Subject: SMTP 5.4-3 & Forwarding incoming mail
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
To: Info-TCPware@PROCESS.COM

Hi All!
	Is the someone who can explaine me how to setup SMTP to forward  incoming mail to
other mail hosts ?
	For example:
*@smtp.deltatel.ru - local mail addresses
*@deltatel.ru - need to forward to host ZZ.DeltaTel.RU



	TIA.



-- 
Cheers,
+OpenVMS [Sys|Net] HardWorker........................................+
 Russia,Delta Telecom JSC,                    Cel:  +7 (901) 971-3222
 191119,St.Petersburg,Transportny per. 3                     116-3222
                                              Fax:  +7 (812) 115-1035
+http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm +
================================================================================
Archive-Date: Tue, 22 Feb 2000 19:42:08 -0500
Reply-To: Info-TCPware@process.com
From: "Theresa Campbell" <theresa@ma.ultranet.com>
To: <Info-TCPware@process.com>
CC: "Chuck Piecham (E-mail)" <chuck@admins.com>
Subject: Trouble with CNFNET
Date: Tue, 22 Feb 2000 19:43:58 -0500
Message-ID: <000101bf7d97$12d44c60$32026b83@tol.gov>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I am trying to change the IP address on the Alpha OpenVMS 6.2 system that
runs TCPWARE.  As set up originally, it was assigned a "pretend" address
because we were not connecting to the internet.  I now can do so, but need
to assign the real IP address.  I tried running CNFNET, but it looks like a
logical may be missing and the following displayed:

CAMPBELLT> @tcpware:cnfnet menu
DEFINE -SYSTEM -NOLOG -EXEC -TRANS=(CONCEALED,TERMINAL) tcpware_common
dkb100:[0
00000.]
                                 -SYSTEM -NOLOG -EXEC -TRANS=(CONCEALED,TERM
INAL
) tcpware_commo
DEF File Name:DEFINE/SYSTEM/NOLOG/EXEC TCPWARE_SPECIFIC SYS$SPECIFIC:
 DEFINE/SYSTEM/NOLOG/EXEC TCPWARE_SPECIFIC SYS$SPECIFIC:.def not found
DEF File Name:DEFINE/SYSTEM/NOLOG/EXEC TCPWARE_ROOT
TCPWARE_SPECIFIC:,TCPWARE_CO
MMON:
                        DEFINE/SYSTEM/NOLOG/EXEC TCPWARE_ROOT
TCPWARE_SPECIFIC:,
TCPWAR
DEF File Name:DEFINE/SYSTEM/NOLOG/EXEC TCPWARE "TCPWARE_ROOT:[TCPWARE]"
 DEFINE/SYSTEM/NOLOG/EXEC TCPWARE "TCPWARE_ROOT:[TCPWARE]".def not found
DEF File Name:DEFINE/SYSTEM/NOLOG TCPWARE_INCLUDE
"TCPWARE_ROOT:[TCPWARE.INCLUDE
]"
                     DEFINE/SYSTEM/NOLOG TCPWARE_INCLUDE
"TCPWARE_ROOT:[TCPWARE.
INC
DEF File Name:
OPTIONS are DEF-NAME SKIP NAME TEST in order
DEF File Name:
%NONAME-F-NOMSG, Message number 00000004
CAMPBELLT>

NETCU> show version
TCPware(R) for OpenVMS V5.3-3 Copyright (c) 1998 Process Software
Corporation

NETCU>

Can anyone help?



Theresa Campbell, Littleton Information Systems Manager
37 Shattuck Street, Littleton, MA 01460
theresa@ma.ultranet.com FAX 978-952-2718 PHONE 978-952-2777

================================================================================
Archive-Date: Tue, 22 Feb 2000 19:48:03 -0500
Date: Tue, 22 Feb 2000 19:48:42 GMT
From: babiarz@ENDOR.COM
Reply-To: Info-TCPware@process.com
To: Info-TCPware@process.com
Message-ID: <000222194842.4fa38@ENDOR.COM>
Subject: RE: Trouble with CNFNET

You need to edit the HOST.; file in TCPWARE to make sure it is set
correctly.



John Babiarz
Intergalactic Software

================================================================================
Archive-Date: Wed, 23 Feb 2000 02:07:01 -0500
From: "Avi Borger" <beto@taulib.tau.ac.il>
Reply-To: Info-TCPware@process.com
To: <Info-TCPware@process.com>
Subject: RE: 5.4-3 & Rejection
Date: Wed, 23 Feb 2000 09:03:22 -0000
Message-ID: <001d01bf7ddc$d66eb580$21204284@tau.ac.il>
MIME-Version: 1.0
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: 7bit
In-Reply-To: <38B2A143.45CB089A@SMTP.DeltaTel.RU>

Shalom Cheers

I think the problem is not on this line. This line is correct.
Send me you full REJECT file and I'll check it for you.

Best regards
Avi Borger
Tel Aviv University
Israel

-----Original Message-----
From: Ruslan R. Laishev [mailto:Laishev@SMTP.DeltaTel.RU]
Sent: Tuesday, February 22, 2000 2:46 PM
To: Info-TCPware@PROCESS.COM
Subject: 5.4-3 & Rejection



I have just for testing in rejection file follows lines:
!
! Reject anything with a Message-ID that appears to have originated from
! cyberpromo.com or nowhere.com
!
Message-ID: <*@cyberpromo.com>
Message-ID: <*@nowhere.com>

In OPCOM I periodicaly see messages:

$
%%%%%%%%%%%  OPCOM  22-FEB-2000 17:45:13.37  %%%%%%%%%%%
Message from user SYSTEM on DTV3
PSC SMTP Server: Syntax error in TCPWARE:SMTP_SERVER_REJECT. (line 34) -
ACTION field
must be Y, N, or Q

$
%%%%%%%%%%%  OPCOM  22-FEB-2000 17:45:13.38  %%%%%%%%%%%
Message from user SYSTEM on DTV3
PSC SMTP Server: Syntax error in TCPWARE:SMTP_SERVER_REJECT. (line 35) -
ACTION field
must be Y, N, or Q



	What is right syntax of this "RFC-822" entry ?

--
Cheers,
+OpenVMS [Sys|Net] HardWorker........................................+
 Russia,Delta Telecom JSC,                    Cel:  +7 (901) 971-3222
 191119,St.Petersburg,Transportny per. 3                     116-3222
                                              Fax:  +7 (812) 115-1035
+http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm +

================================================================================
Archive-Date: Wed, 23 Feb 2000 03:56:32 -0500
Message-ID: <38B39B97.326EF158@SMTP.DeltaTel.RU>
Date: Wed, 23 Feb 2000 11:34:31 +0300
From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU>
Reply-To: Info-TCPware@process.com
MIME-Version: 1.0
Subject: Re: 5.4-3 & Rejection
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
To: Info-TCPware@PROCESS.COM

Avi Borger wrote:
> 
> Shalom Cheers
> 
> I think the problem is not on this line. This line is correct.
> Send me you full REJECT file and I'll check it for you.
	The line number in OPCOM message point to these lines.

> 
> Best regards
> Avi Borger
> Tel Aviv University
> Israel
> 
> -----Original Message-----
> From: Ruslan R. Laishev [mailto:Laishev@SMTP.DeltaTel.RU]
> Sent: Tuesday, February 22, 2000 2:46 PM
> To: Info-TCPware@PROCESS.COM
> Subject: 5.4-3 & Rejection
> 
> I have just for testing in rejection file follows lines:
> !
> ! Reject anything with a Message-ID that appears to have originated from
> ! cyberpromo.com or nowhere.com
> !
> Message-ID: <*@cyberpromo.com>
> Message-ID: <*@nowhere.com>
> 
> In OPCOM I periodicaly see messages:
> 
> $
> %%%%%%%%%%%  OPCOM  22-FEB-2000 17:45:13.37  %%%%%%%%%%%
> Message from user SYSTEM on DTV3
> PSC SMTP Server: Syntax error in TCPWARE:SMTP_SERVER_REJECT. (line 34) -
> ACTION field
> must be Y, N, or Q
> 
> $
> %%%%%%%%%%%  OPCOM  22-FEB-2000 17:45:13.38  %%%%%%%%%%%
> Message from user SYSTEM on DTV3
> PSC SMTP Server: Syntax error in TCPWARE:SMTP_SERVER_REJECT. (line 35) -
> ACTION field
> must be Y, N, or Q
> 
>         What is right syntax of this "RFC-822" entry ?
> 

-- 
Regards.
+.....................pure personal opinion..........................+
    Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM
	Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035
+..... Kick ass VMS solution listening "Nightingales & Bombers" .....+
================================================================================
Archive-Date: Wed, 23 Feb 2000 07:08:28 -0500
Message-ID: <38B3C4C5.7EAD2BFF@SMTP.DeltaTel.RU>
Date: Wed, 23 Feb 2000 14:30:13 +0300
From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU>
Reply-To: Info-TCPware@process.com
MIME-Version: 1.0
Subject: SMTP 5.4-3 & mail forwarding
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
To: Info-TCPware@PROCESS.COM

Hi All!
	How I can configure SMTP (TCPWare 5.4-3) for forwarding incomming mail received for a
particulary domain to other mail server? May be it's FAQ but I can't find any pointers
in docs.



	TIA.

PS:For example, it can be configured in MadGoat MX by:
DEFINE PATH "dom.com" SMTP /ROUTE="othermailhost"

-- 
Cheers,
+OpenVMS [Sys|Net] HardWorker........................................+
 Russia,Delta Telecom JSC,                    Cel:  +7 (901) 971-3222
 191119,St.Petersburg,Transportny per. 3                     116-3222
                                              Fax:  +7 (812) 115-1035
+http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm +
================================================================================
Archive-Date: Wed, 23 Feb 2000 16:57:28 -0500
Message-ID: <38B44E59.7014333E@SMTP.DeltaTel.RU>
Date: Thu, 24 Feb 2000 00:17:13 +0300
From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU>
Reply-To: Info-TCPware@process.com
MIME-Version: 1.0
Subject: Re: SMTP 5.4-3 & mail forwarding
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
To: Info-TCPware@PROCESS.COM

Sorry for dumb questions. A problem is solved.



Ruslan R. Laishev wrote:
> 
> Hi All!
>         How I can configure SMTP (TCPWare 5.4-3) for forwarding incomming mail received for a
> particulary domain to other mail server? May be it's FAQ but I can't find any pointers
> in docs.
> 
>         TIA.
> 
> PS:For example, it can be configured in MadGoat MX by:
> DEFINE PATH "dom.com" SMTP /ROUTE="othermailhost"
> 
> --
> Cheers,
> +OpenVMS [Sys|Net] HardWorker........................................+
>  Russia,Delta Telecom JSC,                    Cel:  +7 (901) 971-3222
>  191119,St.Petersburg,Transportny per. 3                     116-3222
>                                               Fax:  +7 (812) 115-1035
> +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm +

-- 
Regards.
+.....................pure personal opinion..........................+
    Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM
	Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035
+..... Kick ass VMS solution listening "Nightingales & Bombers" .....+
================================================================================
Archive-Date: Wed, 23 Feb 2000 20:42:10 -0500
Sender: goatley@triton.process.com
Return-Path: <aferguso@brazosport.cc.tx.us>
From: AL Ferguson <aferguso@brazosport.cc.tx.us>
Reply-To: Info-TCPware@process.com
Subject: HELP: TCP/IP Browsing problem
Date: Wed, 23 Feb 2000 18:25:48 -0600
Message-ID: <38B47A8C.C5FD4AC9@brazosport.cc.tx.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
To: Info-TCPware@PROCESS.COM
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

So here is a problem that I sure could use some suggestions on how to
resolve:
I have a small lab of 25 computers, P400, Win98 SE, in its own little
network (hub) running TCP/IP protocol, all in the same workgroup named
I102. For some reason these guys have formed two distinct clusters (even
though there is only one workgroup). The machine numbers in each cluster
are of random nature (i.e. not 1-15 or 2,4,6,8.  Completely random- no
pattern). While you browse using network neighborhood, all you can see
is the half (approx.) that are in the entire workgroup, the group of
computers that happens to be in that cluster. You can ping across to a
machine in the other cluster. You can shut down the entire lab, bring it
back up, and still the same machines associate in the same cluster as if
they are in different workgroups.
I have installed the NetBEUI protocol and can then see all the computers
fine, as one big happy workgroup as it should be =96 so I know for certain
that it is not a hub problem (also because I can ping across clusters)
but I want to make it work with TCP/IP as it should. Now, without the
NetBEUI again, I have gone to each machine and disabled the browse
master on all but one computer, this did not work, then set two (one in
each cluster) as browse master, didn=92t help. Then set all back to
automatic, as is the default, no luck, and still it is as if there are
two workgroups of computers.
So here is the challenge: How do I get these machines to see all of the
others through the use of network neighborhood running with TCP/IP
alone?
The reason I want to be able to do this: Say a computer in one of the
clusters has a printer cabled to it, a computer in the other cluster
can=92t browse to that resource.  Now, I realize there are plenty of ways
to skirt this problem but I want to fix what ever it is (if it is
possible) that is preventing TCP/IP from seeing the entire group as one
unit (like the NetBEUI is able to do), I know it is possible but how?
Thanks for any help you can offer.
Al
aferguso=40brazosport.cc.tx.us



================================================================================
Archive-Date: Thu, 24 Feb 2000 15:35:44 -0500
Message-ID: <38B58EF2.2321575C@SMTP.DeltaTel.RU>
Date: Thu, 24 Feb 2000 23:05:06 +0300
From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU>
Reply-To: Info-TCPware@process.com
MIME-Version: 1.0
Subject: SMTP accounting
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
To: Info-TCPware@PROCESS.COM

Hi All!
	I'm would like to have an accounting of using of SMTP service, I can't
find any pointers in the docs. Is there this feature in SMTP 5.4-3?

-- 
Regards.
+.....................pure personal opinion..........................+
    Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM
	Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035
+..... Kick ass VMS solution listening "Nightingales & Bombers" .....+
================================================================================
Archive-Date: Thu, 24 Feb 2000 15:53:04 -0500
Message-ID: <38B5909A.92927BE1@SMTP.DeltaTel.RU>
Date: Thu, 24 Feb 2000 23:12:10 +0300
From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU>
Reply-To: Info-TCPware@process.com
MIME-Version: 1.0
Subject: SMTP services & restrict usage
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
To: Info-TCPware@PROCESS.COM

Hi All!
	I'm would like to restrict sending a mails from VMS accounts, is there
any tips&triks? 

-- 
Regards.
+.....................pure personal opinion..........................+
    Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM
	Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035
+..... Kick ass VMS solution listening "Nightingales & Bombers" .....+
================================================================================
Archive-Date: Thu, 24 Feb 2000 16:00:55 -0500
Date: Thu, 24 Feb 2000 15:00:26 -0600
From: Hunter Goatley <goathunter@process.com>
Reply-To: Info-TCPware@process.com
To: Info-TCPware@process.com
Message-ID: <000224150026.202000c1@process.com>
Subject: RE: SMTP accounting

"Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU> writes:
>
>Hi All!
>	I'm would like to have an accounting of using of SMTP service, I can't
>find any pointers in the docs. Is there this feature in SMTP 5.4-3?
>
There's VMS accounting for each job, but that's currently the extent
of the accounting.  I hope to add more accounting in the future, but
there are no firm plans for it yet.

Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
<goathunter@PROCESS.COM>     http://www2.wku.edu/hunter/
================================================================================
Archive-Date: Thu, 24 Feb 2000 18:12:14 -0500
Date: Thu, 24 Feb 2000 18:11:21 -0500 (EST)
From: bryant@PROCESS.COM
Reply-To: Info-TCPware@process.com
Subject: TCPware ECO kit available: NAMED_V543P033
To: TCPware-Announce@PROCESS.COM
Message-ID: <01JMAMQSEALE000PWM@DELTA.PROCESS.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

TCPware ECO kit announcement

The following ECO kit is now available for TCPware:

    ECO:          NAMED_V543P033
    Description:  Fix nameserver hang, add sortlist support, backup zone file change
    Release date: 24-FEB-2000
    Versions:     5.4-3

  ftp://ftp.process.com/support/54_3/named_v543p033.zip

To search the TCPware ECO database, please visit the following URL:

        http://vms.process.com/eco.html

For more information, contact Process Software via:

     E-mail:    support@process.com
     Phone:     1-800-394-8700

The ECO kit README contents are below.

-----------------------------------------------------------
------------------------------------------------------------------------------
TCPware_NAMED Patch kit (revision 3.3) for TCPware version 5.4-3   18-FEB-2000

Copyright (c) 1999-2000, by Process Software Corporation

        This VMSinstallable saveset provides a new version of NameD and 
        NameD-Xfer for TCPware for OpenVMS.  NameD must be restarted after
        installation of this patch.

        Applicable TCPware and VMS versions: 

            TCPware 5.4 on all supported VAX/VMS and AXP/VMS systems

        The following change[s] has been made:

            - a timing issue has been corrected.  With the right timing, the
              nameserver could hang intermittently. (D/E 5675)

            - BIND Version 8 had removed a feature called "sortlist" that was
              present in BIND Version 4.  A side effect of this feature was
              that queries from a source on the same subnet as one of the
              servers interfaces could result in a response with a fixed
              order.  If the server found any of the A records in the answer
              to be in the same subnet as the common subnet between the client
              and the server, the server would place that A record first in
              the answer.

              This default part of the feature has been added back with this
              kit.  To enable the feature, you must define the system exec
              logical "TCPWARE_NAMED_PREFER_LOCAL_ADDR" and restart your 
              Nameserver.

              When BIND 8.2 is released for TCPware, this logical will no
              longer provide this feature, and you will need to add the
              following statements to the options {}; section of your
              NAMED.CONF File to gain the results:

                  sortlist {
                        { localhost; localnets; };
                        { localnets; };
                  };

              (D/E 5579)

            - Secondary servers no longer create a new version of the backup
              zone file when it transfers the zone, it now replaces the old
              file with the new file.  Customers are encouraged to check the
              directories where their backup zone files are stored, and purge
              the excess if desired.  (D/E 5206)

	This kit also contains the following changes from previous kits:

        NAMED_V543P020
        --------------
          IP AddressWorks related changes:
            Improved handling of errors trying to communicate with the Server
            Manager.

        NAMED_V543P010
        --------------
            A problem where the nameserver would hang indefinately if 
            reloaded has been fixed. This occurred when the server was
            done sending the data for a zone transfer, but the client 
            requesting the zone transfer had not yet closed its end of
            the connection.

            System managers experiencing this problem may notice lingering 
            TCP connections to the domain port on the system in FIN-WAIT-2
            state.  If this is a problem it is recommended the system manager
            take steps to disallow that remote system from doing zone 
            transfers [see the documentation on the allow-transfers statement
            in the NameD configuration].
 
        The old version of TCPWARE:NAMED.EXE will be renamed to 
                TCPWARE:NAMED.EXE_OLD
        The old version of TCPWARE:NAMED-XFER.EXE will be renamed to 
                TCPWARE:NAMED-XFER.EXE_OLD

        To restart NameD after install, use:

                @TCPWARE:RESTART DNS

        Once installed, you may undo this patch by renaming the files back to
        TCPWARE:NAMED.EXE and TCPWARE:NAMED-XFER.EXE.



[End of ECO announcement]
================================================================================
Archive-Date: Thu, 24 Feb 2000 18:34:51 -0500
Sender: goatley@triton.process.com
Return-Path: <babiarz@OBIWAN.ENDOR.COM>
Date: Thu, 24 Feb 2000 18:18:02 GMT
From: babiarz@ENDOR.COM
Reply-To: Info-TCPware@process.com
To: Info-TCPware@process.com
Message-ID: <000224181802.552f4@ENDOR.COM>
Subject: RE: TCPware ECO kit available: NAMED_V543P033

What is the difference between NAMED_V543P033 and NAMED_V543P031.
The description looks the same by me.

john babiarz
================================================================================
Archive-Date: Thu, 24 Feb 2000 18:48:36 -0500
Message-ID: <4.2.2.20000224164624.00c9f7b0@mehlhop.org>
Date: Thu, 24 Feb 2000 16:47:58 -0700
To: Info-TCPware@process.com
From: Jim Mehlhop <mehlhop@process.com>
Reply-To: Info-TCPware@process.com
Subject: RE: TCPware ECO kit available: NAMED_V543P033
In-Reply-To: <000224181802.552f4@ENDOR.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Usually a minor version number change like that has to do with an update to 
the readme or the installation procedure itself.  That's the best I can do 
tonight since the engineer has gone home for the day.

Jim

At 06:18 PM 2/24/00 +0000, you wrote:
>What is the difference between NAMED_V543P033 and NAMED_V543P031.
>The description looks the same by me.
>
>john babiarz

     _________________________________________________________________________
     Jim Mehlhop, Support Engineer
     Process Software
     Mehlhop@process.com
     Phone 719-638-8448
     Join Cauce to outlaw spam
     http://www.cauce.org/
     _________________________________________________________________________

================================================================================
Archive-Date: Fri, 25 Feb 2000 06:10:56 -0500
Message-ID: <38B65881.D5595EDD@SMTP.DeltaTel.RU>
Date: Fri, 25 Feb 2000 13:25:05 +0300
From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU>
Reply-To: Info-TCPware@process.com
MIME-Version: 1.0
Subject: Re: TCPware ECO kit available: NAMED_V543P033
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
To: Info-TCPware@PROCESS.COM

ZIP /VMS ?

The following products will be processed:

  NAMED_V543P V3.3



        Beginning installation of NAMED_V543P V3.3 at 13:23

%VMSINSTAL-I-RESTORE, Restoring product save set A ...
%BACKUP-F-NOTSAVESET, $1$DUA1130:[LAISHEV.KITS.PSC]NAMED_V543P033.A;1 is not a BACKUP
save set
%VMSINSTAL-E-NOSAVESET, Save set  A  cannot be restored.



        VMSINSTAL procedure done at 13:24



Jim Mehlhop wrote:
> 
> Usually a minor version number change like that has to do with an update to
> the readme or the installation procedure itself.  That's the best I can do
> tonight since the engineer has gone home for the day.
> 
> Jim
> 
> At 06:18 PM 2/24/00 +0000, you wrote:
> >What is the difference between NAMED_V543P033 and NAMED_V543P031.
> >The description looks the same by me.
> >
> >john babiarz
> 
>      _________________________________________________________________________
>      Jim Mehlhop, Support Engineer
>      Process Software
>      Mehlhop@process.com
>      Phone 719-638-8448
>      Join Cauce to outlaw spam
>      http://www.cauce.org/
>      _________________________________________________________________________

-- 
Cheers,
+OpenVMS [Sys|Net] HardWorker........................................+
 Russia,Delta Telecom JSC,                    Cel:  +7 (901) 971-3222
 191119,St.Petersburg,Transportny per. 3                     116-3222
                                              Fax:  +7 (812) 115-1035
+http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm +
================================================================================
Archive-Date: Fri, 25 Feb 2000 06:11:04 -0500
Subject: Re: TCPware ECO kit available: NAMED_V543P033
From: eplan@kapsch.net (Peter LANGSTOEGER)
Reply-To: Info-TCPware@process.com
Message-ID: <38b65ece$1@news.kapsch.co.at>
Date: 25 Feb 2000 11:51:58 +0100
To: Info-TCPware@PROCESS.COM

In article <38B65881.D5595EDD@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU> writes:
>ZIP /VMS ?

Bingo.

>%BACKUP-F-NOTSAVESET, $1$DUA1130:[LAISHEV.KITS.PSC]NAMED_V543P033.A;1 is not a BACKUP
>save set
>%VMSINSTAL-E-NOSAVESET, Save set  A  cannot be restored.

$ SET FILE/ATT=(RFM=FIX,LRL=32256,RAT=NONE) NAMED_V543P033.A

-- 
Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651
Network and OpenVMS system manager  Fax.    +43 1 81111-888
FBFV/Information Services           E-mail  eplan@kapsch.net
<<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLAN
A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"
"VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998
================================================================================
Archive-Date: Fri, 25 Feb 2000 07:34:50 -0500
Message-ID: <38B66B3E.C1860C56@SMTP.DeltaTel.RU>
Date: Fri, 25 Feb 2000 14:45:02 +0300
From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU>
Reply-To: Info-TCPware@process.com
MIME-Version: 1.0
Subject: Re: TCPware ECO kit available: NAMED_V543P033
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
To: Info-TCPware@PROCESS.COM

Hi !

Peter LANGSTOEGER wrote:
> 
> In article <38B65881.D5595EDD@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU> writes:
> >ZIP /VMS ?
> 
> Bingo.
> 
> >%BACKUP-F-NOTSAVESET, $1$DUA1130:[LAISHEV.KITS.PSC]NAMED_V543P033.A;1 is not a BACKUP
> >save set
> >%VMSINSTAL-E-NOSAVESET, Save set  A  cannot be restored.
> 
> $ SET FILE/ATT=(RFM=FIX,LRL=32256,RAT=NONE) NAMED_V543P033.A
	I known, but I have not had this problem before. :-)

> 
> --
> Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651
> Network and OpenVMS system manager  Fax.    +43 1 81111-888
> FBFV/Information Services           E-mail  eplan@kapsch.net
> <<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLAN
> A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"
> "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998

-- 
Cheers,
+OpenVMS [Sys|Net] HardWorker........................................+
 Russia,Delta Telecom JSC,                    Cel:  +7 (901) 971-3222
 191119,St.Petersburg,Transportny per. 3                     116-3222
                                              Fax:  +7 (812) 115-1035
+http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm +
================================================================================
Archive-Date: Fri, 25 Feb 2000 07:44:12 -0500
Date: Fri, 25 Feb 2000 6:43:42 -0600
From: Hunter Goatley <goathunter@process.com>
Reply-To: Info-TCPware@process.com
To: Info-TCPware@process.com
Message-ID: <000225064342.202000c1@process.com>
Subject: Re: TCPware ECO kit available: NAMED_V543P033

"Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU> writes:
>
>> $ SET FILE/ATT=(RFM=FIX,LRL=32256,RAT=NONE) NAMED_V543P033.A
>	I known, but I have not had this problem before. :-)
>
We'll get that fixed this morning.

Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
<goathunter@PROCESS.COM>     http://www2.wku.edu/hunter/
================================================================================
Archive-Date: Fri, 25 Feb 2000 07:53:09 -0500
Date: Fri, 25 Feb 2000 6:52:39 -0600
From: Hunter Goatley <goathunter@process.com>
Reply-To: Info-TCPware@process.com
To: Info-TCPware@process.com
Message-ID: <000225065239.202000c1@process.com>
Subject: Re: TCPware ECO kit available: NAMED_V543P033

Hunter Goatley <goathunter@process.com> writes:
>
>"Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU> writes:
>>
>>> $ SET FILE/ATT=(RFM=FIX,LRL=32256,RAT=NONE) NAMED_V543P033.A
>>	I known, but I have not had this problem before. :-)
>>
>We'll get that fixed this morning.
>
Done.

Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
<goathunter@PROCESS.COM>     http://www2.wku.edu/hunter/
================================================================================
Archive-Date: Fri, 25 Feb 2000 08:12:46 -0500
Sender: schreiber@process.com
Date: Fri, 25 Feb 2000 08:12:12 -0500
From: Jeff Schreiber <schreiber@process.com>
Reply-To: Info-TCPware@process.com
To: Info-TCPware@process.com
CC: schreiber@process.com
Message-ID: <009E62F0.7B940CFB.107@process.com>
Subject: RE: TCPware ECO kit available: NAMED_V543P033

babiarz@ENDOR.COM writes:
>
>What is the difference between NAMED_V543P033 and NAMED_V543P031.
>The description looks the same by me.
>

    The patch was originally for the sortlist request.  Since I had a patch
    almost ready, I threw in a attempt at a fix for a hanging problem that
    a customer had, but I wasn't able to reproduce.

>            - a timing issue has been corrected.  With the right timing, the
>              nameserver could hang intermittently. (D/E 5675)

    NAMED_V543P031 had this timing corrected for the TCP sockets.  After some
    time the customer reported another hang, and I noticed I forgot to correct
    it on the UDP socket side.

    This re-kit is this timing issue.  I released to the customer a week ago
    so he was able to give it ample testing this time before we released it.

                                                -Jeff

--
Jeff Schreiber,            Process Software Corp.
schreiber@mx.process.com   http://www.process.com
      TCPware & MultiNet: Stronger than Ever



================================================================================
Archive-Date: Fri, 25 Feb 2000 08:57:24 -0500
Message-ID: <38B6832D.F8DF39D9@SMTP.DeltaTel.RU>
Date: Fri, 25 Feb 2000 16:27:09 +0300
From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU>
Reply-To: Info-TCPware@process.com
MIME-Version: 1.0
Subject: Re: TCPware ECO kit available: NAMED_V543P033
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
To: Info-TCPware@PROCESS.COM

Hunter Goatley wrote:
> 
> "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU> writes:
> >
> >> $ SET FILE/ATT=(RFM=FIX,LRL=32256,RAT=NONE) NAMED_V543P033.A
> >       I known, but I have not had this problem before. :-)
> >
> We'll get that fixed this morning.
	Thanks.

> 
> Hunter
> ------
> Hunter Goatley, Process Software, http://www.process.com/
> <goathunter@PROCESS.COM>     http://www2.wku.edu/hunter/

-- 
Cheers,
+OpenVMS [Sys|Net] HardWorker........................................+
 Russia,Delta Telecom JSC,                    Cel:  +7 (901) 971-3222
 191119,St.Petersburg,Transportny per. 3                     116-3222
                                              Fax:  +7 (812) 115-1035
+http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm +
================================================================================
Archive-Date: Mon, 28 Feb 2000 16:04:01 -0500
Message-ID: <38BAE0A9.7D925002@yahoo.com>
From: linuxmtl@yahoo.com
Reply-To: Info-TCPware@process.com
MIME-Version: 1.0
Subject: ftp not working properly
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Mon, 28 Feb 2000 20:58:54 GMT
To: Info-TCPware@PROCESS.COM

Good day,

Configuration:	TCPWare 5.4-3
Platform:	VAX 4000 serie

Miscellaneous:	Uses ip filtering



Issue: Cannot ftp.

In the filter file I have the following for that machine...

permit tcp 199.22.23.12 255.255.255.255 201.200.55.6 255.255.255.255 eq
20
permit tcp 199.22.23.12 255.255.255.255 201.200.55.6 255.255.255.255 eq
21   

where 199.22.23.12 is the ip for ftp.hydro.qc.ca.

VAXFT::$ ftp ftp.hydro.qc.ca /novms
220-





                      ATTENTION

Vous avez atteint un réseau privé et dont l`accès est réservé
aux utilisateurs autorisés par Hydro-Québec.
Le système sera entièrement contrÔlé et les contrevenants
seront poursuivis en justice.



Pour toutes demandes d'information ou problèmes,
veuillez adresser vos demandes à securite@telecom.hydro.qc.ca



220 pippin.hydro.qc.ca FTP server (Version wu-2.4.2-VR16(1) Fri Mar 5
10:39:30 E
ST 1999) ready.
_Username [system]: anonymous
331 Guest login ok, send your complete e-mail address as pass
_Password:
230- The response 'xx' is not valid
Next time please use your e-mail address as your password
        for example: joe@aragorn.hydro.qc.ca
230 Guest login ok, access restrictions apply.
FTP> pwd
257 "/" is current directory.
The remote working directory is /
FTP> ls
200 PORT command successful.
150 Opening ASCII mode data connection for file list.



.... it freezes there....until I kill the connection with a CTRL-Y.

Can you tell me what I am missing there.

Note: This is a brand new insallation (was running PathWay 3.1 up to
saturday).

Thanks,
================================================================================
Archive-Date: Mon, 28 Feb 2000 16:14:24 -0500
Message-ID: <38BAE3C5.823369DA@yahoo.com>
From: linuxmtl@yahoo.com
Reply-To: Info-TCPware@process.com
MIME-Version: 1.0
Subject: Re: ftp not working properly
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Mon, 28 Feb 2000 21:12:09 GMT
To: Info-TCPware@PROCESS.COM

Just got the answer....

Must type in passive after login in...



linuxmtl@yahoo.com a écrit :
> 
> Good day,
> 
> Configuration:  TCPWare 5.4-3
> Platform:       VAX 4000 serie
> 
> Miscellaneous:  Uses ip filtering
> 
> Issue: Cannot ftp.
> 
> In the filter file I have the following for that machine...
> 
> permit tcp 199.22.23.12 255.255.255.255 201.200.55.6 255.255.255.255 eq
> 20
> permit tcp 199.22.23.12 255.255.255.255 201.200.55.6 255.255.255.255 eq
> 21
> 
> where 199.22.23.12 is the ip for ftp.hydro.qc.ca.
> 
> VAXFT::$ ftp ftp.hydro.qc.ca /novms
> 220-
> 
>                       ATTENTION
> 
> Vous avez atteint un réseau privé et dont l`accès est réservé
> aux utilisateurs autorisés par Hydro-Québec.
> Le système sera entièrement contrÔlé et les contrevenants
> seront poursuivis en justice.
> 
> Pour toutes demandes d'information ou problèmes,
> veuillez adresser vos demandes à securite@telecom.hydro.qc.ca
> 
> 220 pippin.hydro.qc.ca FTP server (Version wu-2.4.2-VR16(1) Fri Mar 5
> 10:39:30 E
> ST 1999) ready.
> _Username [system]: anonymous
> 331 Guest login ok, send your complete e-mail address as pass
> _Password:
> 230- The response 'xx' is not valid
> Next time please use your e-mail address as your password
>         for example: joe@aragorn.hydro.qc.ca
> 230 Guest login ok, access restrictions apply.
> FTP> pwd
> 257 "/" is current directory.
> The remote working directory is /
> FTP> ls
> 200 PORT command successful.
> 150 Opening ASCII mode data connection for file list.
> 
> .... it freezes there....until I kill the connection with a CTRL-Y.
> 
> Can you tell me what I am missing there.
> 
> Note: This is a brand new insallation (was running PathWay 3.1 up to
> saturday).
> 
> Thanks,
================================================================================
Archive-Date: Mon, 28 Feb 2000 16:17:42 -0500
Date: Mon, 28 Feb 2000 15:17:11 -0600
From: Hunter Goatley <goathunter@process.com>
Reply-To: Info-TCPware@process.com
To: Info-TCPware@process.com
Message-ID: <000228151711.202000c1@process.com>
Subject: Re: ftp not working properly

linuxmtl@yahoo.com writes:
>
>Just got the answer....
>
>Must type in passive after login in...
>
Yes, normally FTP file transfers happen by the server making a
connection back to the client.  If you don't allow for that in your
filter, you'll have to use passive mode (which is a good idea anyway).
Passive mode causes all socket opens to happen from the client to the
server.

Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
<goathunter@PROCESS.COM>     http://www2.wku.edu/hunter/