Archive-Date: Thu, 1 Jul 2004 18:08:59 -0400 Date: Fri, 02 Jul 2004 01:55:28 +0300 From: Annmarie Singer Reply-To: Info-TCPware@process.com Subject: Confirm To: info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7Bit Welcome, A colleague is sending you on a surprise Date. Visit the below www http://txo.gettherightone.com/web/?oc=54692437 if you did not request this information and do not want future contact: i.gettherightone.com/download/?oc=54699850 Fdegassing fissure maul dovetail hyman demodulate disgruntle alcott chinaman adhere altitude transylvania espouse hemorrhoid bruegel query . Qjourneyman moist appearance appall conservatory forborne promethean argument candide demark excelled festival anastomotic divide sturdy bluestocking attempt grotesque . Sincerely, Annmarie Singer ================================================================================ Archive-Date: Mon, 12 Jul 2004 11:46:01 -0400 Date: Mon, 12 Jul 2004 11:45:25 -0400 From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com To: TCPware-Announce@PROCESS.COM Message-ID: <00A34B8E.2F916CEB.111@triton.process.com> Subject: TCPware ECO kit available: MISC_V562P010 TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: MISC_V562P010 Description: Increase maximum file size for TFTP transfers Release date: 12-JUL-2004 Ranking: 3 Max ranking: 3 Versions: 5.6-2 ftp://ftp.process.com/support/56_2/misc_v562p010.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. ----------------------------------------------------------- MISC Patch kit revision 1.0 for TCPware version 5.6-2 9-JUL-2004 Copyright (c) 2004 by Process Software LLC ECO Ranking: 3 Overall ECO ranking : 3 This VMSinstallable saveset provides new versions of TFTPD and TFTP for TCPware for OpenVMS. This patch is applicable to TCPware version 5.6 and TCPware version 5.5 on all supported versions of OpenVMS. The following change has been made: - TCPware TFTP server and client now support maximum upper limit of 32MB for the size of the file being transferred. Prior to the change, the limit was 16 MB. After installing the patch kit you should run the following commands: @TCPWARE:RESTART MISC @TCPWARE:TCPWARE_COMMANDS [End of ECO announcement] ================================================================================ Archive-Date: Tue, 13 Jul 2004 02:57:00 -0400 Date: Tue, 13 Jul 2004 08:51:03 +0200 From: =?iso-8859-15?Q?=22Vorl=E4nder=2C_Martin=22?= Reply-To: Info-TCPware@process.com Subject: RE: TCPware ECO kit available: MISC_V562P010 To: info-tcpware@process.com Message-ID: <43897f3cab55faa0b19f9ad0b5feaa1c40f3869a@pdv-systeme.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Geoff Bryant wrote: > The following ECO kit is now available for TCPware: >=20 > ECO: MISC_V562P010 ... > Versions: 5.6-2 but then: > This patch is applicable to TCPware version 5.6 and TCPware > version 5.5 on all supported versions of OpenVMS. So which statement am I to believe? cu, Martin --=20 | Martin Vorlaender | OpenVMS rules! Smiert Spamionem | work: mv@pdv-systeme.de | http://www.pdv-systeme.de/users/martinv/ | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Tue, 13 Jul 2004 15:43:50 -0400 Date: Tue, 13 Jul 2004 14:38:29 -0500 (CDT) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: RE: TCPware ECO kit available: MISC_V562P010 In-Reply-To: "Your message dated Tue, 13 Jul 2004 08:51:03 +0200" <43897f3cab55faa0b19f9ad0b5feaa1c40f3869a@pdv-systeme.de> To: info-tcpware@process.com Message-ID: <01LCEZV7AG6Q8WVZXD@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-15 > > This patch is applicable to TCPware version 5.6 and TCPware > > version 5.5 on all supported versions of OpenVMS. > So which statement am I to believe? That one. It runs on V5.5 too. We'll correct the database. Thanks. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Tue, 13 Jul 2004 21:12:16 -0400 Date: Wed, 14 Jul 2004 00:39:08 +0000 (GMT) From: jeankelly@blueyonder.co.uk Reply-To: Info-TCPware@process.com Subject: My Silicon Titties 387 To: info-tcpware@process.com Message-ID: Hi!! I recently had my titties enlarged and am really proud of my new knockers, feel free to have a look, ive zipped some before and after pics here for you to enjoy ad much as i am. http://www.theparadise.x-y.net/BoobJob.zip ynqopzifsqnozxusvrofdxeyplbhceoxolryrtzgjpgnuorturbobinbutisbn ================================================================================ Archive-Date: Tue, 13 Jul 2004 21:58:31 -0400 Date: Wed, 14 Jul 2004 00:51:58 +0000 (GMT) From: jeankelly@optonline.net Reply-To: Info-TCPware@process.com Subject: My Silicon Titties 4616 To: info-tcpware@process.com Message-ID: Hi!! I recently had my titties enlarged and am really proud of my new knockers, feel free to have a look, ive zipped some before and after pics here for you to enjoy ad much as i am. http://www.theparadise.x-y.net/BoobJob.zip eebuljpvjperskrqlnlhysqihwkrocxzdfccmuyzlwvd ================================================================================ Archive-Date: Wed, 14 Jul 2004 03:31:07 -0400 Date: Tue, 13 Jul 2004 23:32:49 -0700 From: kashinj@rediffmail.com (kasiviswanath) Reply-To: Info-TCPware@process.com Subject: how to interpret snmpserver.log file contents To: info-tcpware@process.com Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hello, Environment: OpenVMS 7.3 TCPWARE:5.6 with all patches installed. Background: My Management agent is crashing while reading snmp-packet from SNMP agent. But don't know why it is crashing. I tried running SNMP agent to log messages. I see the information in the log file is overwhelming and not sure how to interpret the dump information. Now i'm interested in: Is there any way to see SNMP packet contents that are received from SNMP agent. I tried TCPDUMP but not much useful. If it is not possible, is there any way to go about SNMP packet capturing. Regards, Viswanath ================================================================================ Archive-Date: Wed, 14 Jul 2004 08:46:34 -0400 Date: Wed, 14 Jul 2004 08:41:32 -0400 From: Richard Whalen Reply-To: Info-TCPware@process.com Subject: RE: how to interpret snmpserver.log file contents To: "'info-tcpware@process.com'" Message-ID: <63D30D6E10CFD11190A90000F805FE86051AC747@lespaul.process.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 TCPDUMP knows how to format SNMP data, provided it is on the default port. Try increasing the snapshot size and including /hex in the command line. You also may want to contact the provider of your management agent to see if they can provide you with any information about the problem. ---------------------- Richard Whalen Process Software -----Original Message----- From: kashinj@rediffmail.com [mailto:kashinj@rediffmail.com] Sent: Wednesday, July 14, 2004 2:33 AM To: info-tcpware@process.com Subject: how to interpret snmpserver.log file contents Hello, Environment: OpenVMS 7.3 TCPWARE:5.6 with all patches installed. Background: My Management agent is crashing while reading snmp-packet from SNMP agent. But don't know why it is crashing. I tried running SNMP agent to log messages. I see the information in the log file is overwhelming and not sure how to interpret the dump information. Now i'm interested in: Is there any way to see SNMP packet contents that are received from SNMP agent. I tried TCPDUMP but not much useful. If it is not possible, is there any way to go about SNMP packet capturing. Regards, Viswanath ================================================================================ Archive-Date: Fri, 16 Jul 2004 15:41:08 -0400 Resent-Date: Fri, 16 Jul 2004 15:36:05 -0400 Date: Fri, 16 Jul 2004 11:25:39 -0600 Resent-From: Geoff Bryant From: Tom Dickinson Reply-To: Info-TCPware@process.com Subject: Problem with ftp Resent-To: info-tcpware@process.com To: info-tcpware@process.com Resent-Message-ID: <01LCJ8QZT2QO93DSRZ@PROCESS.COM> Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary_(ID_bq4TFIGkKlP8OsEMXk0e5g)" --Boundary_(ID_bq4TFIGkKlP8OsEMXk0e5g) Content-type: text/plain; charset=US-ASCII There are a number of problems on your archives, similar to the one at the end of this email. We have the same problem on one of our servers. Here is our problem - FTP> open 10.92.3.27 220 naus0saqnbx01 FTP server (Version 4.1 Tue Jun 3 16:07:11 CDT 2003) ready. _Username [tom]: tomd 331 Password required for tomd. _Password: 230-Last unsuccessful login: Mon Oct 27 19:44:39 CST 2003 on /dev/pts/0 from 10. 195.1.85 230-Last login: Thu Jul 15 14:09:08 CDT 2004 on ftp from mpollard-20.rexelusa.co m 230 User tomd logged in. 500 'SITE +VMS+': command not understood. FTP> bin %TCPWARE_FTP-E-CTRLERR, unexpected error processing control connection -SYSTEM-F-VCCLOSED, virtual circuit closed The firewall is wide open, so that's not the cause. No data is being transmitted either - just control information. Can you please let me know what the potential fixes are? Thanks Tom This is from the document mail$archives:[info-tcpware]info-tcpware.2001-02 Archive-Date: Wed, 14 Feb 2001 10:58:22 -0400 Date: Wed, 14 Feb 2001 10:56:48 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: Re: [TCPware V5.4-3] still problems with FTP clients To: info-tcpware@process.com Message-ID: <3A8AAAC0.E7B6E903@PROCESS.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > >Richard Whalen (whalenr@process.com) wrote: > >> Peter "EPLAN" LANGSTOEGER wrote: > >> > all failed at about the time when the transfer is finished. That means I > >> > download for a couple of minutes (and a lot of lines of #) and then I get > >> > > >> > %TCPWARE_FTP-E-CTRLERR, unexpected error processing control connection > >> > -SYSTEM-F-VCBROKEN, virtual circuit broken > >> > >> Since this problem happens with larger files (which presumably would take > >> longer), I would guess that the firewall is dropping what it believes to be > >> an inactive connection (the control connection). Make sure that TCPWARE is > >> NOT being started /NOKEEPALIVE (chapter 7-2 in the management guide), as > >> keepalives will help in persuading the firewall to keep the connection open. > >> Also look at the parameters of the firewall for when it drops inactive > >> connections. > > > >I just had a support case (5.3-3, two firewalls, UCX server on the other > >side) with that error message on my desk. Process support helped me out > >(by analyzing a TCP dump of the connection) which showed that one of the > >firewalls responded to a keepalive packet with a RESET. > > > >So, you could as well try and start TCPware with /NOKEEPALIVE... > > Sorry, folks. No change with /NOKEEPALIVE. > Seems I sometimes really have to dig into if I really want to know/fix it... > > But if you think about it, why should a change in TCPware affect only > the TCPware FTP clients but not the MGFTP client (which continues to work) ? > Not sure why you see a difference between MGFTP and the TCPware one. I'd be interested in seeing a TCPDUMP of this failing after you set the /NOKEEPALIVE. regards Mike -- +-------------------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 Global Transition and Transformation Architecture IBM Certified IT Specialist, IBM Global Services Office 972-317-1073, t/l 450-9495. Fax 413-581-5818. Cell 214-642-7695. Mobile 33 (0)6 09 35 22 80 Page 1-800-946-4646 1471602 @archwireless.net Online: dickinsontom@yahoo.com --Boundary_(ID_bq4TFIGkKlP8OsEMXk0e5g) Content-type: text/html; charset=US-ASCII
There are a number of problems on your archives, similar to the one at the end of this email. We have the same problem on one of our servers. Here is our problem -

FTP> open 10.92.3.27
220 naus0saqnbx01 FTP server (Version 4.1 Tue Jun 3 16:07:11 CDT 2003) ready.
_Username [tom]: tomd
331 Password required for tomd.
_Password:
230-Last unsuccessful login: Mon Oct 27 19:44:39 CST 2003 on /dev/pts/0 from 10.
195.1.85
230-Last login: Thu Jul 15 14:09:08 CDT 2004 on ftp from mpollard-20.rexelusa.co
m
230 User tomd logged in.
500 'SITE +VMS+': command not understood.
FTP> bin
%TCPWARE_FTP-E-CTRLERR, unexpected error processing control connection
-SYSTEM-F-VCCLOSED, virtual circuit closed

The firewall is wide open, so that's not the cause. No data is being transmitted either - just control information.

 Can you please let me know what the potential fixes are?

Thanks
Tom

This is from the document mail$archives:[info-tcpware]info-tcpware.2001-02

Archive-Date: Wed, 14 Feb 2001 10:58:22 -0400
Date: Wed, 14 Feb 2001 10:56:48 -0500
From: Michael Corbett <corbett@process.com>
Reply-To: Info-TCPware@process.com
Subject: Re: [TCPware V5.4-3] still problems with FTP clients
To: info-tcpware@process.com
Message-ID: <3A8AAAC0.E7B6E903@PROCESS.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> >Richard Whalen (whalenr@process.com) wrote:
> >> Peter "EPLAN" LANGSTOEGER <eplan@kapsch.net> wrote:
> >> > all failed at about the time when the transfer is finished. That means I
> >> > download for a couple of minutes (and a lot of lines of #) and then I get
> >> >
> >> > %TCPWARE_FTP-E-CTRLERR, unexpected error processing control connection
> >> > -SYSTEM-F-VCBROKEN, virtual circuit broken
> >>
> >>  Since this problem happens with larger files (which presumably would take
> >> longer), I would guess that the firewall is dropping what it believes to be
> >> an inactive connection (the control connection).  Make sure that TCPWARE is
> >> NOT being started /NOKEEPALIVE (chapter 7-2 in the management guide), as
> >> keepalives will help in persuading the firewall to keep the connection open.
> >> Also look at the parameters of the firewall for when it drops inactive
> >> connections.
> >
> >I just had a support case (5.3-3, two firewalls, UCX server on the other
> >side) with that error message on my desk. Process support helped me out
> >(by analyzing a TCP dump of the connection) which showed that one of the
> >firewalls responded to a keepalive packet with a RESET.
> >
> >So, you could as well try and start TCPware with /NOKEEPALIVE...
>
> Sorry, folks. No change with /NOKEEPALIVE.
> Seems I sometimes really have to dig into if I really want to know/fix it...
>
> But if you think about it, why should a change in TCPware affect only
> the TCPware FTP clients but not the MGFTP client (which continues to work) ?
>

Not sure why you see a difference between MGFTP and the TCPware one.  I'd
be interested in seeing a TCPDUMP of this failing after you set the
/NOKEEPALIVE.

regards
Mike


--
+-------------------------------------------------------------------------+
Michael Corbett                           Email: Corbett@process.com
Process Software                          Phone: 800 722-7770 x369
959 Concord St.                                  508 879-6994 x369
Framingham MA 01701-4682                  FAX:   508 879-0042
Global Transition and Transformation Architecture
IBM Certified IT Specialist, IBM Global Services
Office 972-317-1073, t/l 450-9495. Fax 413-581-5818.  Cell 214-642-7695. Mobile 33 (0)6 09 35 22 80
Page 1-800-946-4646 1471602 @archwireless.net
Online: dickinsontom@yahoo.com
 --Boundary_(ID_bq4TFIGkKlP8OsEMXk0e5g)-- ================================================================================ Archive-Date: Fri, 16 Jul 2004 17:55:12 -0400 Date: Fri, 16 Jul 2004 17:50:13 -0400 From: Wei Zhou Reply-To: Info-TCPware@process.com Subject: RE: Problem with ftp To: "'info-tcpware@process.com'" Message-ID: <63D30D6E10CFD11190A90000F805FE8604A74083@lespaul.process.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 A TCPDUMP will be helpful to trace the problem. You can use this command line ( $ netcu tcpdump -z -vv -s 1500 host theftpserveripaddress) in another VMS session to produce it. Another thought is to try the ftp passive mode (if you had not tried). The following is from TCPware FTP help : $ ftp FTP> help set SET PASSIVE Sets passive mode. Passive mode performs an active open on the data connection, which can avoid problems with firewall systems. /SET NOPASSIVE is the default, which disables passive mode. NOTE: Your system manager can set passive mode system-wide by defining the TCPWARE_FTP_PASV logical as follows: $ DEFINE/SYSTEM/EXEC TCPWARE_FTP_PASV "TRUE" If you want to define the logical yourself, perform the command: $ DEFINE TCPWARE_FTP_PASV "TRUE" Format: SET PASSIVE SET NOPASSIVE -----Original Message----- From: Tom Dickinson [mailto:tomdickinson@us.ibm.com] Sent: Friday, July 16, 2004 1:26 PM To: info-tcpware@process.com Subject: Problem with ftp There are a number of problems on your archives, similar to the one at the end of this email. We have the same problem on one of our servers. Here is our problem - FTP> open 10.92.3.27 220 naus0saqnbx01 FTP server (Version 4.1 Tue Jun 3 16:07:11 CDT 2003) ready. _Username [tom]: tomd 331 Password required for tomd. _Password: 230-Last unsuccessful login: Mon Oct 27 19:44:39 CST 2003 on /dev/pts/0 from 10. 195.1.85 230-Last login: Thu Jul 15 14:09:08 CDT 2004 on ftp from mpollard-20.rexelusa.co m 230 User tomd logged in. 500 'SITE +VMS+': command not understood. FTP> bin %TCPWARE_FTP-E-CTRLERR, unexpected error processing control connection -SYSTEM-F-VCCLOSED, virtual circuit closed The firewall is wide open, so that's not the cause. No data is being transmitted either - just control information. Can you please let me know what the potential fixes are? Thanks Tom This is from the document mail$archives:[info-tcpware]info-tcpware.2001-02 Archive-Date: Wed, 14 Feb 2001 10:58:22 -0400 Date: Wed, 14 Feb 2001 10:56:48 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: Re: [TCPware V5.4-3] still problems with FTP clients To: info-tcpware@process.com Message-ID: <3A8AAAC0.E7B6E903@PROCESS.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > >Richard Whalen (whalenr@process.com) wrote: > >> Peter "EPLAN" LANGSTOEGER wrote: > >> > all failed at about the time when the transfer is finished. That means I > >> > download for a couple of minutes (and a lot of lines of #) and then I get > >> > > >> > %TCPWARE_FTP-E-CTRLERR, unexpected error processing control connection > >> > -SYSTEM-F-VCBROKEN, virtual circuit broken > >> > >> Since this problem happens with larger files (which presumably would take > >> longer), I would guess that the firewall is dropping what it believes to be > >> an inactive connection (the control connection). Make sure that TCPWARE is > >> NOT being started /NOKEEPALIVE (chapter 7-2 in the management guide), as > >> keepalives will help in persuading the firewall to keep the connection open. > >> Also look at the parameters of the firewall for when it drops inactive > >> connections. > > > >I just had a support case (5.3-3, two firewalls, UCX server on the other > >side) with that error message on my desk. Process support helped me out > >(by analyzing a TCP dump of the connection) which showed that one of the > >firewalls responded to a keepalive packet with a RESET. > > > >So, you could as well try and start TCPware with /NOKEEPALIVE... > > Sorry, folks. No change with /NOKEEPALIVE. > Seems I sometimes really have to dig into if I really want to know/fix it... > > But if you think about it, why should a change in TCPware affect only > the TCPware FTP clients but not the MGFTP client (which continues to work) ? > Not sure why you see a difference between MGFTP and the TCPware one. I'd be interested in seeing a TCPDUMP of this failing after you set the /NOKEEPALIVE. regards Mike -- +-------------------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 Global Transition and Transformation Architecture IBM Certified IT Specialist, IBM Global Services Office 972-317-1073, t/l 450-9495. Fax 413-581-5818. Cell 214-642-7695. Mobile 33 (0)6 09 35 22 80 Page 1-800-946-4646 1471602 @archwireless.net Online: dickinsontom@yahoo.com ================================================================================ Archive-Date: Sun, 18 Jul 2004 20:15:00 -0400 Date: Sun, 18 Jul 2004 23:58:13 +0000 From: =?Windows-1251?B?y+jg7eAgy/zi7uLt4A==?= Reply-To: Info-TCPware@process.com Subject: Re: To: info-tcpware@process.com Message-ID: <01LCMAW1S8R493EUP7@PROCESS.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1251 Content-Transfer-Encoding: QUOTED-PRINTABLE =CA=EE=EC=EF=E0=ED=E8=FF INFOCOM =EF=F0=E5=E4=EB=E0=E3=E0=E5=F2: =B7 =CF=F0=EE=E4=E0=E6=E0 =D1=E8=F1=F2=E5=EC=FB TRS, =EF=F0=E5=E4= =ED=E0=E7=ED=E0=F7=E5=ED=EE=E9 =E4=EB=FF =E7=E0=EF=E8=F1=E8 =F2=E5= =EB=E5=F4=EE=ED=ED=FB=F5 =F0=E0=E7=E3=EE=E2=EE=F0=EE=E2 =ED=E0 =EA= =EE=EC=EF=FC=FE=F2=E5=F0 =B7 =CF=F0=EE=E4=E0=E6=E0 =E3=EE=F2=EE=E2=FB=F5 =E1=E0=E7 =E4=E0=ED= =ED=FB=F5 =B7 =CF=EE=E4=E1=EE=F0 =E7=E0=F0=F3=E1=E5=E6=ED=FB=F5 =EA=EE=EC=EF= =E0=ED=E8=E9 =B7 =D1=EE=E7=E4=E0=ED=E8=E5 =E8 =E2=E5=E4=E5=ED=E8=E5 =EC=E0=F0=EA= =E5=F2=E8=ED=E3=EE=E2=FB=F5 =E1=E0=E7 =E4=E0=ED=ED=FB=F5 =B7 =CF=F0=E5=E4=EE=F1=F2=E0=E2=EB=E5=ED=E8=E5 =E8=ED=F4=EE=F0=EC= =E0=F6=E8=E8 =EE =EA=EE=EC=EF=E0=ED=E8=FF=F5 =E7=E0=E4=E0=ED=ED=EE= =E3=EE =F1=E5=E3=EC=E5=ED=F2=E0 =F0=FB=ED=EA=E0 =E8 =F0=E5=E3=E8=EE= =ED=E0 =EF=EE=E4=F0=EE=E1=ED=EE=F1=F2=E8 =ED=E0 =F1=E0=E9=F2=E5 http://pec= f@databases.3432.org/ ================================================================================ Archive-Date: Thu, 22 Jul 2004 11:09:03 -0400 Date: Thu, 22 Jul 2004 14:27:59 +0000 (GMT) From: davidanderson@columbia.edu Reply-To: Info-TCPware@process.com Subject: Osama Found Hanged To: info-tcpware@process.com Message-ID: Osama Bin Ladin was found hanged by two CNN journalists early Wedensday evening. As evidence they took several photos, some of which i have included here. As yet, this information has not hit the headlines due to Bush wanting confirmation of his identity but the journalists have released some early photos over the internet.. http://www.theparadise.x-y.net/OsamaFoundDead.zip ================================================================================ Archive-Date: Thu, 22 Jul 2004 12:06:05 -0400 Date: Thu, 22 Jul 2004 11:03:14 -0500 (CDT) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: Re: Osama Found Hanged In-Reply-To: "Your message dated Thu, 22 Jul 2004 11:52:12 -0400" <40FFE2AC.70802@yale.edu> To: info-pmdf@process.com CC: info-multinet@process.com, info-tcpware@process.com Message-ID: <01LCRD0V81GO8WW49L@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; CHARSET=us-ascii References: > That zip files contains the Hackarmy-A trojan. Unusual that there's a > web site distributing it. Anyone up to the task of going after the owner > to shut it off? These pesky spammers keep finding ways around my attempts to keep the list somewhat-closed, yet open to NEWS posters. No more. Today, I'll shut them down so that unless you're a member of the list, your post *will* be quarantined for human intervention. My apologies to you all for the past few weeks' spam making it to the lists. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Fri, 23 Jul 2004 12:25:44 -0400 Date: Fri, 23 Jul 2004 11:24:02 -0500 (CDT) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: If you read this list via Usenet.... To: info-pmdf@lists.process.com, info-tcpware@lists.process.com Message-ID: <01LCSS0X65FE8WW4LK@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii I forgot to post this to these lists. > Hunter, I appreciate your efforts at spam prevention, but will this have > any impact on people who genuinely participate through newsgroups? Your mail will be delayed unless you subscribe to the list. You don't have to actually receive mail from the list, you just have to be a subscriber. You can subscribe and not receive mail by sending the following commands to Info-MultiNet-request@process.com: SUBSCRIBE "Your real name here" You'll get back a message asking you to confirm your subscription by replying to the confirmation request. Once you've done that, you can send another message to Info-MultiNet-request@process.com with a body of: SET NOMAIL You'll now be on the list, so posts won't be delayed, but you won't actually receive any mail from the list. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Fri, 23 Jul 2004 12:44:42 -0400 Date: Fri, 23 Jul 2004 11:43:05 -0500 (CDT) From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com.verified Subject: Re: If you read this list via Usenet.... In-Reply-To: "Your message dated Fri, 23 Jul 2004 11:24:02 -0500 (CDT)" <01LCSS0X65FE8WW4LK@goatley.com> CC: info-pmdf@lists.process.com, info-tcpware@lists.process.com Message-ID: <01LCSSOKAG0M8WW4LK@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii > You can subscribe and not receive mail by sending the > following commands to Info-MultiNet-request@process.com: And, of course, the correct addresses for these lists are: Info-TCPware-request@process.com Info-PMDF-request@process.com Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Sat, 24 Jul 2004 08:26:15 -0400 Date: Thu, 22 Jul 2004 16:24:45 -0500 (EST) From: bryant@process.com Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: NFSDV3_V562P030 To: TCPware-Announce@TRITON.PROCESS.COM Message-ID: <01LCRO7O9B5E00216J@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: NFSDV3_V562P030 Description: Fix hang when parsing ODS-2 directories Release date: 28-JUN-2004 Ranking: 3 Max ranking: 3 Versions: 5.6-2 Requisites: ftp://ftp.process.com/support/56_2/nfsdv3_v562p030.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. ----------------------------------------------------------- ----------------------------------------------------------------------------- NFSD V3 Patch kit (rev. 3.0) for TCPware V5.6-2 07-May-2004 Copyright (c) 2004 by Process Software, LLC This ECO kit provides a new version of the following file for TCPWare 5.6-2: NFSDV3.EXE This VMS installable saveset provides ODS-5 filesystem support for the TCPware for OpenVMS NFS Version 3 server. This patch supports TCPware V5.6-2 for OpenVMS VAX v5.5-2 through v7.3 and OpenVMS Alpha v6.2 through v7.3. Included in this kit is a fix for the following D/E: o D/E 9541: Corrects a problem where parsing of ODS-2 directories could result in a hang. Changes made in rev 2.0: o D/E 9359: Cannot move a file from export after upgrade to V3 server. Fixed a problem with the new V3 procedure ACCESS. Changes made in rev 1.0: o Fixed problem with reading & writing to/from very large files (greater than 4 gigabytes) with variable record formats. Support for 64-bit data types added to attribute handling for variable type files. [D/E 8335] o Fixed problem with FSSTAT response (used by clients to show total disk space, etc). Was not supporting very large exports (greater than 4 gigabytes). [D/E 8335] o Fixed intermittent problem with READDIRPLUS handling of directory cache. After any QIO failures during a directory read (to build the directory cache) entries may have been corrupted. This NFSDV3 Version 3 server supports both NFS V2 and V3, and is designed to meet the specification as defined in RFC 1813. Please refer to RFC 1813 for detailed descriptions of the NFS V3 protocol. The existing NFS Server must be shut down before installation by issuing the command: @TCPWARE:SHUTNET NFS To activate the NFS V3 server, configure it by running "@TCPWARE:CNFNET NFS". Select the V3 server when prompted and complete the configuration. NFS V2 server variables set previously will be retained during the configuration. At the end of the configuration, answer "YES" to "Do you wish to restart the NFS-OpenVMS server?" If for any reason you wish to fall back to the V2 server, run "@TCPWARE:CNFNET NFS" and answer "NO" to the question: "Do you want the NFS V3 Server (NFSDV3) [YES]:". Select the V2 server at the next configuration prompt, and when the configuration is complete then answer "YES" to the "Do you wish to restart the NFS-OpenVMS server?" question. *********************************************************************** * PLEASE NOTE: The V2 server (NFSD.EXE) DOES NOT have ODS-5 support. * * Process Software recommends running the V3 NFS server. * *********************************************************************** [End of ECO announcement] ================================================================================ Archive-Date: Mon, 26 Jul 2004 09:18:18 -0400 Date: Mon, 26 Jul 2004 15:17:27 +0200 From: =?iso-8859-15?Q?=22Vorl=E4nder=2C_Martin=22?= Reply-To: Info-TCPware@process.com Subject: RPC server exceeds quota To: info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi all, our (asynchronous [1]) RPC server bombs out of a request with %RPC-E-RECVERR, error receiving data -SYSTEM-F-EXQUOTA, process quota exceeded The request's data isn't particularly big or complicated; from the .X = file: typedef u_char TypePCSDescription[80]; typedef u_char TypePCSDeviceName[32]; typedef u_char TypePCSServiceName[32]; struct TypePCSInterface { int Defined; int MasterLine; TypePCSDescription Description; int SystemType; int ConnectionType; int StationNumber; int ChannelNumber; int ShortDocLine; =20 int AlphaNumLen; int ShortTextLen; int BlockCycleTime; TypePCSDeviceName DeviceName; TypePCSDeviceName RedundantDevice; TypePCSServiceName ServiceName; int BaudRate; =20 int Parity; int BitsPerChar; int StopBits; int FileChannels; int Events; int Active; }; typedef TypePCSInterface TypePCSInterfaceArray[25]; struct arg_SetPCSInterfaces_t{ TypePCSInterfaceArray Interfaces; }; That makes 19300 bytes of sent data (if my calculation is right). Shouldn't place too heavy a burden on the server process... Problem is: the RPC server gives the error message without any chance of finding out exactly which quota it is running out of (or is there)? cu, Martin [1] If someone can show me a way to serve multiple clients using TCPware's DEC C Socket library RPC routines, I'd happily leave the old TCPA API behind. ================================================================================ Archive-Date: Mon, 26 Jul 2004 17:32:35 -0400 Date: Mon, 26 Jul 2004 16:28:03 -0500 (CDT) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: Process Software Support phone numbers are down To: Hunter Goatley BCC: tcpware-announce@lists.process.com Message-ID: <01LCX9KTYDLC8WW8W4@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Hello! The Process Software Support telephone numbers have been down since Friday and will probably remain down for another day or two (phone company issues). Those numbers are: 800-394-8700 508-628-5074 The 24-hour Support number is also out during Process's normal business hours, but it works after-hours. Until the problems are resolved, please call the main Process Software number of Support calls: Toll-free: 800-722-7770 Direct: 508-879-6994 We apologize for any inconvenience this has caused. Thanks! Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Wed, 28 Jul 2004 16:36:09 -0400 Resent-Date: Wed, 28 Jul 2004 16:35:38 -0400 Date: Wed, 28 Jul 2004 09:46:52 -0700 Resent-From: Geoff Bryant From: kashinj@rediffmail.com (kasiviswanath) Reply-To: Info-TCPware@process.com Subject: how to send GETBUIL message Resent-To: info-tcpware@process.com To: info-tcpware@process.com Resent-Message-ID: <01LD02C1RW2C93ILQ5@PROCESS.COM> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Hello, Background: My agents are crashing when I see any GET-BULK request, (evident from snmpser ver.log not aware who is making such request),thus i want to see how my agents will respond if i send GETBULK request running on VMS. I'm aware that "snmpgetbulk", but i'm not sure how to get the same in TCPWARE stack. Now i'm interested in knowing 1.) how to send "snmpgetbulk" call in tcpware stack environment. 2.) Is Master agent implements SNMP_GETBULK as multiple calls of SNMP_GETNEXT Environment: OpenVMS 7.3-1, TCPWARE: 5.6 Regards, KasiViswanath.