Archive-Date: Wed, 1 Mar 2000 09:51:25 -0500 Reply-To: Info-TCPware@process.com From: "Theresa Campbell" To: "'Chuck Piecham'" CC: , Subject: RE: Trouble with CNFNET Date: Wed, 1 Mar 2000 09:52:46 -0500 Message-ID: <000201bf838d$ce8037c0$32026b83@tol.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In-Reply-To: <01BF7DE5.B3345F80@rasadm3.admins.com> Thanks Chuck, Operating from System seems to have helped. Using CNFNET I tested last night and then backed out the changes. I noted the following, and hope you can shed some light on this for me: During testing, telnet access was MUCH slower (75-90 seconds instead of the almost instant connections we're accustomed to). After backing out the changes, telnet access is still MUCH slower, as it was during the test. The Assessor's office is unable to gain access to their SQL server application (Patriot Properties ASSESS PRO). SQL uses TCP Sockets. I checked the hosts, named.hosts, and named.local files, and they all match with the original files as configured prior to testing. Theresa Campbell, Littleton Information Systems Manager 37 Shattuck Street, Littleton, MA 01460 theresa@ma.ultranet.com FAX 978-952-2718 PHONE 978-952-2777 -----Original Message----- From: Chuck Piecham [mailto:chuck@admins.com] Sent: Wednesday, February 23, 2000 10:07 AM To: 'Theresa Campbell' Subject: RE: Trouble with CNFNET Theresa: Edit your SYSTEM username specific login command file, add the lines $DELETE/SYMBOL/GLOBAL DEF $DELETE/SYMBOL/GLOBAL DEFINE Write the changes and exit the editor. Logoff SYSTEM, log into SYSTEM again. CNFNET should run correctly now. Chuck ---------- From: Theresa Campbell [SMTP:theresa@ma.ultranet.com] Sent: Tuesday, February 22, 2000 7:44 PM To: Info-TCPware@process.com Cc: Chuck Piecham (E-mail) Subject: Trouble with CNFNET 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: Wed, 1 Mar 2000 09:57:01 -0500 Date: Wed, 1 Mar 2000 8:56:28 -0600 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: theresa@ma.ultranet.com Message-ID: <000301085628.202000c1@process.com> Subject: RE: Trouble with CNFNET "Theresa Campbell" writes: > > During testing, telnet access was MUCH slower (75-90 seconds instead of the >almost instant connections we're accustomed to). > That sounds like DNS issues---the Telnet client is asking for an IP address for the host, then not getting it quickly. > The Assessor's office is unable to gain access to their SQL server >application (Patriot Properties ASSESS PRO). SQL uses TCP Sockets. > That, too, could be caused by a faulty DNS setup. > I checked the hosts, named.hosts, and named.local files, and they all match >with the original files as configured prior to testing. > Sounds like you should contact our Support group at . They should be able to get the problem resolved. Thanks for choosing TCPware! Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Wed, 1 Mar 2000 10:30:35 -0500 Sender: schreiber@process.com Date: Wed, 1 Mar 2000 10:29:49 -0500 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009E66F1.88F67CDF.222@process.com> Subject: RE: Trouble with CNFNET "Theresa Campbell" writes: > > During testing, telnet access was MUCH slower (75-90 seconds instead of the >almost instant connections we're accustomed to). > I'm going to assume that you are telnetting into a TCPware system. When you log in, do the following for me: $nslookup -d2 (e.g. if telnetting _from_ 10.0.0.1 _to_ 10.0.0.2, we'll want to do $nslookup -d2 10.0.0.1 ) I'm guessing we'll see some timeout issues that we can then try to track down what the DNS problem is. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Wed, 1 Mar 2000 11:26:58 -0500 From: trataski@lightstream.net (Tom Rataski) Reply-To: Info-TCPware@process.com Subject: TCPware, NTP and DST Message-ID: <38bd3e81.14909357@news.lightstream.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 01 Mar 2000 16:14:41 GMT To: Info-TCPware@PROCESS.COM We are using TCPwares NTP daemon and are synching to a GPS timeserver as our stratum 1 clock. Our Alphas are level 2 process control machines. We have to control when the DST time change occurs because a lot of calculations in the process are done from the time of day clock. In the past we would change the clocks at a agreed upon time where certain controls could be put into automatic and the time change wouldn't affect the process, or the change could occur when the process was down. With NTP running is there a way to tell the systems manually when the time change could occur? Has anyone else addressed this same problem a different way? I have looked at changing the timeszone manually but there doesn't seem to be a standard time period where the logical tcpip_timezone is read. Thanks for any input -TomR- --- Tom Rataski Akron, Ohio ================================================================================ Archive-Date: Fri, 3 Mar 2000 10:00:39 -0500 Date: Fri, 03 Mar 2000 09:59:23 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: DRIVERS_V543P020 To: TCPware-Announce@PROCESS.COM Message-ID: <01JMLBVLWKAA000Y23@DELTA.PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: DRIVERS_V543P020 Description: Apache support, BG multicast programming, VMS 7.2 p= rivs Release date: 3-MAR-2000 Versions: 5.4-3, 5.3-3, 5.3-2 ftp://ftp.process.com/support/54_3/drivers_v543p020.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. ----------------------------------------------------------- DRIVERS patch kit revision 2.0 for TCPware Version 5.4-3 2= 5-FEB-2000 Copyright =A9 1999-2000 Process Software Corporation This patch kit provides new versions of the following drivers for TCPware Version 5.4: =09BGDRIVER - D/E 5732 - Add support for "privileged sockets" to =09=09=09=09allow beta 2 of the Apache server from =09=09=09=09Compaq to work. =09=09 - D/E 5733 - Add support for the DEC C values of the =09=09=09=09multicast options to BGDRIVER (actual =09=09=09=09change was to IPDRIVER). =09TCPDRIVER - D/E 5775 - Add proper VMS V7.2 privilege check. =09=09 - D/E 5350 - Changes made to the Outgoing Access =09=09=09=09Restrictions feature that corrects =09=09=09=09problems introduced in TCPware 5.4 and =09=09=09=09DRIVERS_V533P050. =09UDPDRIVER - D/E 5775 - Add proper VMS V7.2 privilege check. =09IPDRIVER - D/E 5775 - Add proper VMS V7.2 privilege check. This patch kit also provides the following changes applicable to TC= Pware Version 5.3 previously provided in DRIVERS_V533P050: BGDRIVER - D/E 2298 - Modify behaviour of IO$_DEACCESS - D/E 3509 - Modified to allow DCL/Perl scripts to= work properly under the Netscape FastTrack= web server. - D/E 5296 - Provide proper privilege checks under= OpenVMS Alpha V7.2 and higher. INETDRIVER - D/E 339 - Correct the output of an extra f= or output from REXEC - D/E 5296 - Provide proper privilege checks under= OpenVMS Alpha V7.2 and higher. IPDRIVER - D/E 2213 - Fix routine which derives largest MTU= of all physical interfaces. This is us= ed by TCP to set the MSS advertised at conn= ection establishment. - D/E 2453 - EWA twisted pair Ethernet controllers= with the cable removed would hang TCPware = during startup. This problem has been corre= cted. - D/E 5296 - Provide proper privilege checks under= OpenVMS Alpha V7.2 and higher. NTDRIVER - D/E 3330 - Drop any received data when closing. - D/E 1537 - Permanent NTA /w CLOSE_DASSGN cannot = be deleted. - D/E 5296 - Provide proper privilege checks under= OpenVMS Alpha V7.2 and higher. TCPDRIVER - D/E 3872 - Recognize SYN packets in successive connections when old connection is in TIME_WAIT (RLOGIN clients no longer h= ang on successive connections) - D/E 5296 - Provide proper privilege checks under= OpenVMS Alpha V7.2 and higher. UDPDRIVER - D/E 5296 - Provide proper privilege checks under= OpenVMS Alpha V7.2 and higher. NOTE: You must reboot your system after installing this patch in or= der to load the new driver(s). The old versions of the driver(s) will be renamed to *.EXE_OLD. Once installed, you may undo this patch by renaming the file(s) bac= k to: TCPWARE_COMMON:[TCPWARE]INETDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]INETDRIVER.EXE TCPWARE_COMMON:[TCPWARE]IPDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]IPDRIVER.EXE TCPWARE_COMMON:[TCPWARE]BGDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]BGDRIVER.EXE TCPWARE_COMMON:[TCPWARE]TCPDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]TCPDRIVER.EXE TCPWARE_COMMON:[TCPWARE]NTDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]NTDRIVER.EXE TCPWARE_COMMON:[TCPWARE]UDPDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]UDPDRIVER.EXE [End of ECO announcement] ================================================================================ Archive-Date: Fri, 3 Mar 2000 10:41:31 -0500 Message-ID: <20000303154221.6283.qmail@venus.postmark.net> MIME-Version: 1.0 From: yottabit Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: DNSworks question Date: Fri, 03 Mar 2000 08:42:21 -0700 Content-Type: text/plain; charset="iso-8859-1" Hi, We've got a couple DNS servers running on TCPware 5.3-3 on Alpha OpenVMS. The DNSworks report (which is great! It definitely points out the "rough edges"...) says this for us: e152 - The cache of the server "ns1.abc.com." can be poisoned with false data. This is a threat to the security of your domain. What is the cure for this for TCPware? I tried following this link, and also tried searching the process.com web site for info on spoofing but couldn't find much (well, the search function kept failing). Thanks! Chris ================================================================================ Archive-Date: Fri, 3 Mar 2000 22:06:55 -0500 From: martin@RADIOGAGA.HARZ.DE (Martin Vorlaender) Subject: Re: DNSworks question Message-ID: <38bff417.524144494f47414741@radiogaga.harz.de> Date: Fri, 03 Mar 2000 18:19:19 +0100 Reply-To: Info-TCPware@process.com CC: yottabit@postmark.net To: Info-TCPware@PROCESS.COM [posted & mailed] yottabit (yottabit@postmark.net) wrote: : We've got a couple DNS servers running on TCPware 5.3-3 on Alpha : OpenVMS. The DNSworks report (which is great! It definitely points : out the "rough edges"...) says this for us: : : e152 - The cache of the server "ns1.abc.com." can be poisoned with : false data. This is a threat to the security of your domain. : : What is the cure for this for TCPware? I tried following this link, : and also tried searching the process.com web site for info on spoofing : but couldn't find much (well, the search function kept failing). Update to version 5.4-3. The BIND that comes with it is based on v8.1.2 (the 5.3-3 is based on v4) which isn't vulnerable to this any more. cu, Martin -- | Martin Vorlaender | VMS & WNT programmer OpenVMS: When you | work: mv@pdv-systeme.de KNOW where you want | http://www.pdv-systeme.de/users/martinv/ to go today. | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Mon, 13 Mar 2000 15:51:32 -0500 Date: Mon, 13 Mar 2000 15:49:52 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: FTP_V543P040 To: TCPware-Announce@PROCESS.COM Message-ID: <01JMZN1LQZO20019YX@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_V543P040 Description: Fix for denial of service attack Release date: 13-MAR-2000 Versions: 5.4-3 ftp://ftp.process.com/support/54_3/ftp_v543p040.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 4.0) for TCPware version 5.4-3 29-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. - Correct a problem with FTP_V543P030 that could cause the TCPware_FTP process to consume channels. 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) - Correct a problem when TCPWARE_FTP__ROOT is defined to be disk:[dir.] /translation=conceal that would cause the user to be denied access to directories that previous versions of FTP did not deny access to. (DE5670) - Correct a problem with deleting wildcarded files in Unix mode. (DE 5734) - Correct a problem with displaying the directory in the 150 reply message in Unix mode. (DE 5736) [End of ECO announcement] ================================================================================ Archive-Date: Thu, 16 Mar 2000 13:50:41 -0500 Date: Thu, 16 Mar 2000 13:48:54 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: DHCP_V543P040 To: TCPware-Announce@PROCESS.COM Message-ID: <01JN3POO2PDU001CM4@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: DHCP_V543P040 Description: Assorted DHCP fixes Release date: 16-MAR-2000 Versions: 5.4-3 ftp://ftp.process.com/support/54_3/dhcp_v543p040.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. ----------------------------------------------------------- DHCPD Patch kit revision 4.0 for TCPware version 5.4 9-MAR-2000 Copyright (c) 2000, by Process Software Corporation This kit updates TCPware V5.4 with a new version of DHCPD.EXE. It corrects the following problems and adds the following enhancements. Changes in this patch: 1) When using DHCP Safe-Failover, the numbers output by the NETCU SHOW DHCP /POOLS command could be incorrect, such as displaying negative numbers in the 'available' column. This has been fixed. d/e 5791) 2) When using DHCP Safe-Failover, if the size of the lease pool is reduced, or the backup-pool-size value is reduced, the DHCP server could reserve too many addresses in the pool for the secondary. This has been fixed. Changes since patch DHCP_V543P020: 1) The DHCP server no longer exits with the following fatal errors: PSCDHCPD-E-Abandoning IP address x.x.x.x: pinged before offer PSCDHCPD-E-dhcp_reply was supplied lease with no state! (d/e 5356, 5539) 2) The DHCP server could crash if a client sent option 81 (client FQDN) and the configuration file did not have a domain name option specified for the client. This has been fixed. (d/e 5615) 3) The DHCP server could hang after the following error appeared: PSCDHCPD-E-receive_packet failed on xxx: I/O stream empty The hang has been fixed. (d/e 5610) 4) For statically assigned IP addresses, the DHCP server no longer performs unnecessary dynamic DNS udpates upon a renewal of the lease. (d/e 5474) 5) When using DHCP Safe-Failover, the sending of DHCPOFFERs could be delayed. This has been fixed. (d/e 5570) 6) When using DHCP Safe-Failover, the following error displayed during normal operations: PSCDHCPD-E- -> update's expiration seems obsolete:xxxxxxxx This has been fixed. (d/e 5371) 7) For DHCP Safe-Failover, the following statement has been added to the lease file: last-partner-transaction _date_; This indicates the last time the failover partner modified the lease (for example, renewed it). The 'starts' time indicates when this server itself last modified the lease. (d/e 5442) Changes in this patch since patch DHCP_V543P010: 1) New configuration file parameter: unicast-bootp-reply _flag_; The default is off. If this is set to on, the DHCP server will unicast its BOOTREPLY messages for BOOTP clients. 2) More improved reclaiming of expired leases. How often the lease list is checked for expired leases can now be modified using the following new configuration file parameter: lease-scan-interval _seconds_; The default is 60 seconds. Changes since V5.4-3: 1) Improved reclaiming of expired leases both when Safe-Failover is in use and when it is not. 2) Correctly parse option 81 (Client-FQDN) sent by client. This fixes a memory leak. 3) Improved Dynamic DNS error and debug messages. 4) Improved handling of errors trying to communicate with the Server Manager when IP AddressWorks is used. 5) New DHCP Safe-Failover state: Revoked. Used with IP AddressWorks. The old version of DHCPD will be renamed to TCPWARE_COMMON:[TCPWARE]DHCPD.EXE_OLD Once installed, you may undo this patch by renaming the file back to: TCPWARE_COMMON:[TCPWARE]DHCPD.EXE and restart DHCP component. NOTE: You do not need to reboot or restart TCPware, but you must start or restart the DHCP component to enable this patch. [End of ECO announcement] ================================================================================ Archive-Date: Thu, 16 Mar 2000 16:56:44 -0500 Sender: goatley@triton.process.com Return-Path: Date: Thu, 16 Mar 2000 16:53:22 GMT From: babiarz@ENDOR.COM Reply-To: Info-TCPware@process.com To: INFO-TCPWARE@PROCESS.COM Message-ID: <000316165322.6aca6@ENDOR.COM> Subject: smtp reject file, STOPPING RELAY I have been told that my network is open to third party relay. I have closed things up, but still have a problem. I think that the following line may be the cause. ! ! Accept all messages with MAIL FROM:<> (bounce messages) ! <> * * n ! john babiarz interglactic software ================================================================================ Archive-Date: Thu, 16 Mar 2000 18:18:20 -0500 From: goathunter@PROCESS.COM (Hunter Goatley) Reply-To: Info-TCPware@process.com To: info-tcpware@process.com Subject: Re: ping can't go through when ip filtering is on Date: Thu, 16 Mar 2000 23:16:45 GMT Message-ID: <38d16aef.35436454@news.wku.edu> References: <38D1383D.65838F6@-NOSPAM-vipnet.qc.ca> On Thu, 16 Mar 2000 19:38:43 GMT, Jean-Marc Beaudoin wrote: >I have a VAX 4000-705A running OpenVMS 6.2 and TCPWare 5-4.3 > >It uses ip filtering.... > >When filters are up (NETCU SET FILTER ISA-0 TCPWARE:FILTER-ISA-0.DAT) we >can't ping outside from that system. > >When filters are down (NETCU SET NOFILTER ISA-0) we can ping without any >problems. > >I have checked in the port lists and did not find any ports associated >to ping. > >The first lines in the filter file are... > >permit udp 0 0 eq 53 0 0 >permit tcp 0 0 0 0 gt 1023 established > >Then it goes all the permit directives. > >A few examples extracted from the file... > >permit tcp 131.195.14.227 255.255.255.255 201.200.55.6 255.255.255.255 >eq 20 >permit tcp 131.195.14.227 255.255.255.255 201.200.55.6 255.255.255.255 >eq 21 >permit ip 131.195.18.37 255.255.255.255 201.200.55.6 255.255.255.255 >permit ip 131.195.18.41 255.255.255.255 201.200.55.6 255.255.255.255 >permit ip 131.195.28.15 255.255.255.255 201.200.55.6 255.255.255.255 > >Is anything wrong with it? > Yes. PING requests are ICMP packets, so you need to add lines to permit those as well: ! ! Allow ICMP stuff through ! permit icmp 0 0 0 0 Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ goathunter@PROCESS.COM ================================================================================ Archive-Date: Fri, 17 Mar 2000 04:38:17 -0500 Message-ID: <38D1F60F.BD27715E@SMTP.DeltaTel.RU> Date: Fri, 17 Mar 2000 12:08:31 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: smtp reject file, STOPPING RELAY Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM babiarz@ENDOR.COM wrote: > > I have been told that my network is open to third party > relay. I have closed things up, but still have a problem. > I think that the following line may be the cause. > > ! > ! Accept all messages with MAIL FROM:<> (bounce messages) > ! > <> * * n Follows is right variant: <> * <*@endor.com> n -- 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, 22 Mar 2000 13:26:01 -0500 From: Jee Hyung Kim Subject: Event Announcement: Internet Global Summit: Global Distributed Intelligence for Everyone Intelligence for Everyone Date: Wed, 22 Mar 2000 13:25:18 -0500 Message-ID: <38D9100D.AEBFD6EB@ubqt.net> Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hello, I want to give every one a heads up about a great conference that's happening in Japan this July. The Internet Society, one of the oldest international Internet organizations, is hosting its annual Global Summit in Yokohama, Japan. This four day event will cover such pivotal topics as: -- Regulation, Policy and Governance -- E-Commerce and E-business -- Interactive and Multimedia -- Mobile Internet and IP Network Appliances -- Internet Science and Technology -- Internet Infrastructure and Technologies -- Third World Expansion -- Security -- Domain Names -- Linux -- Open Source Movement Please feel free to forward/post this announcement or pass it around to your colleagues. Here are the logistics of the event. INET 2000 The Internet Global Summit: Global Distributed Intelligence For Everyone The 10th Annual Internet Society Conference 18-21, July 2000 Pacifico Yokohama Conference Center, Yokohama, Japan email: web: REGISTER AT: http://mc-net.jtbcom.co.jp/inet2000registration/ INET is the premier event in the Internet industry, providing an international forum for advancing the development and implementation of Internet networks, technologies, applications, and policies. The world's Internet leaders meet at INET conferences to exchange experiences and shape the future of the Internet. INET attendees examine strategic issues emanating from the Internet's impact on commerce and finance, education, technologies and societies. INET 2000 presents a strong technical program with all papers peer reviewed by industry experts from around the world. *WHO ATTENDS INET CONFERENCES:* More than 2,000 decision-makers and networking professionals involved in extending the use and reach of Internet networks in their organizations or countries are expected to attend INET 2000. Their roles involve nearly every aspect of the Internet's development and operations. *KEYNOTE SPEAKERS:* - John T. Chambers, President and CEO of Cisco Systems, Inc. - Dr. Ken-ichi Ohmae, international management consultant and creator of the framework of the borderless economy. SUPER PANELS: Super Panel #1: Open Source Movement Launched in 1985 by Richard Stallman, (GNU), the free source code movement has blossomed into a broad front of projects best exemplified by the stunning success of Linux, the Unix-like kernel launched by Linus Torvalds in 1991. It is now challenging Microsoft's Windows NT in the server business and is poised to invade the desktop as well. Some call Linux the Internet Operating System and this is twice true: it could not have existed without the Internet and a lot of machines that are making up the Internet run on Linux. Apache, another free source code software, powers nearly half of all Internet servers in the world. This round table Super Panel will discuss how these two communities are rapidly merging into one that may be the real basis for the new net economy. Super Panel #2: Next-Generation Internet Research Projects: What's New, What's Next and What Works? Late-breaking news from Next-generation Internet projects will be presented. Panelists will address their current status, next step, and what has led them to success. Super Panel #3: The Future of the Internet Layer As the Internet continues to grow, there are increasing stresses and strains on some of its foundations, such as the original numeric addressing space and the underlying assumption of transparent communications. The expected arrival of millions of wireless devices, and expansion to new, very populous regions of the world, will maintain or increase these stresses for several decades to come. The Internet technical community has been aware of this issue for at least seven years and has carried out various studies and new developments including Classless Interdomain Routing, Network Address Translation and IPv6. The panel will discuss all this and more, and attempt to discern where we are headed next. PROGRAM THEMES: - Internet Infrastructure Technologies - Internet Science and Technology for the 21st Century - Mobile Internet and IP Network Appliances - Interactive, Multimedia, Innovative Contents with Full Demonstrations - Bio-Medical Issues - Education - E-Commerce and E-Business - Regulation, Policy and - Governance iGrid2000: LIVE DEMONSTRATIONS: The potential for using global, next-generation networks to significantly change the way science is conducted will be showcased at INET 2000, where researchers from around the world will collaborate in iGrid2000, sharing computing resources and data over high-speed networks to solve complex computational programs. REGISTER AT: http://mc-net.jtbcom.co.jp/inet2000registration/ For more information and the latest updates regarding the summit, visit http://www.isoc.org/inet2000/ ================================================================================ Archive-Date: Thu, 23 Mar 2000 13:52:16 -0500 Date: Thu, 23 Mar 2000 19:29:12 +0100 Message-ID: <0E16861EE7BCD111BE9400805FE6841F0F0BCA17@c1s5x001.cor.srvfarm.origin-it.com> From: "Hermann Reisenbauer" Reply-To: Info-TCPware@process.com Subject: How to setup protocol "Netbios over TCP/IP (RFC1001,RFC1002,STD-19) " on OpenVMS ? To: Info-TCPware@PROCESS.COM We want to connect PCs to an OpenVMS system using this protocol. Please mail any hints and tips to: hermann.reisenbauer@at.origin-it.com Thanks ! ================================================================================ Archive-Date: Thu, 23 Mar 2000 15:24:10 -0500 Message-ID: <38DA76A1.E5F60931@SMTP.DeltaTel.RU> Date: Thu, 23 Mar 2000 22:55:13 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: How to setup protocol "Netbios over TCP/IP (RFC1001,RFC1002,STD-19) " on OpenVMS ? Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Start Pathworks and PWIP support and enjoy. Hermann Reisenbauer wrote: > > We want to connect PCs to an OpenVMS system using this protocol. > > Please mail any hints and tips to: hermann.reisenbauer@at.origin-it.com > > Thanks ! -- 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: Fri, 24 Mar 2000 05:28:12 -0500 Message-ID: From: Kevin Phillip Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Subject: NFS Mount Problems Date: Fri, 24 Mar 2000 10:10:21 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I have a Unix box setup as an NFS server (JERS09). I have two AlphaServers in a cluster running TCPware and also setup as NFS clients (JERS0A & JERS0B). Finally, I have a standalone AlphaServer setup as an NFS client (EXTEL). When I use NFSMOUNT to mount JERS09's disk on one of the cluster nodes (JERS0B), it works perfectly. But when I use NFSMOUNT on the other node (JERS0A), I get a device timeout. I also get the same result when mounting on EXTEL. The weird thing is that I can mount the disk if I use JERS09's IP address but not the node name. Yet, I can ping and telnet onto JERS09 from JERS0A and EXTEL. Here's an example: EXTEL::SYSTEM>NFSMOUNT /UID=7004 /GID=160 - _EXTEL::SYSTEM>/CACHE_TIMEOUT=(DIRECTORY=::01,ATTRIBUTE=::01,READ_DIRECTORY) - _EXTEL::SYSTEM>JERS09 "/usr1/svs/v3.2" NFS9: JERS09_NFS %NFSMOUNT-E-MOUNTFAIL, error mounting _$1$NFS9:[000000] -SYSTEM-F-TIMEOUT, device timeout EXTEL::SYSTEM>NFSMOUNT /UID=7004 /GID=160 - _EXTEL::SYSTEM>/CACHE_TIMEOUT=(DIRECTORY=::01,ATTRIBUTE=::01,READ_DIRECTORY) - _EXTEL::SYSTEM>194.202.150.36 "/usr1/svs/v3.2" NFS9: JERS09_NFS %NFSMOUNT-S-MOUNTED, /usr1/svs/v3.2 mounted on _$1$NFS9:[000000] EXTEL::SYSTEM>ping JERS09 PING jers09.itexhld.com (194.202.150.36): 56 data bytes 64 bytes from 194.202.150.36: icmp_seq=0. time=2. ms 64 bytes from 194.202.150.36: icmp_seq=1. time=1. ms 64 bytes from 194.202.150.36: icmp_seq=2. time=1. ms I have managed to baffle a few people with this and I would love to find out why this happens. Thanks, Kevin Phillip *********************************************************************** Any views expressed in this message are those of the individual sender, except where the sender states them to be the views of Itex Limited. This e-mail is intended only for the individual or entity to which it is addressed and contains information that is private and confidential. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying is strictly prohibited. If you have received this e-mail in error please delete it immediately and advise us by return e-mail to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Fri, 24 Mar 2000 11:51:08 -0500 Sender: DLUTES@fw1.textron.com Message-ID: <38DB4826.70A12AC8@cessna.textron.com> Date: Fri, 24 Mar 2000 10:49:10 -0600 From: Dale Lutes Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: NFS Mount Problems References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kevin, I can't comment on this specific problem. However, I've had similar experiences in the past with TCPware's telnet client running on my VMS machines and various clients on my NCD X-terminals. In each instance, the *real* problem was my company's awful DNS server. I would suggest that you double-check the list of Domain Name servers in JERS0A's TCPware configuration. If you are not using a static host file, you may want to consider having one at least for those systems which are accessed frequently from your cluster. Kevin Phillip wrote: > ... > When I use NFSMOUNT to mount JERS09's disk on one of the cluster nodes > (JERS0B), it works perfectly. But when I use NFSMOUNT on the other node > (JERS0A), I get a device timeout. I also get the same result when mounting > on EXTEL. > > The weird thing is that I can mount the disk if I use JERS09's IP address > but not the node name. Yet, I can ping and telnet onto JERS09 from JERS0A > and EXTEL. > ... -- Dale D. Lutes Flight Data Systems Cessna Aircraft Company 316-517-7109 ================================================================================ Archive-Date: Fri, 24 Mar 2000 12:02:11 -0500 Message-ID: <4.2.2.20000324095814.048a2a30@mehlhop.org> Date: Fri, 24 Mar 2000 09:59:38 -0700 To: Info-TCPware@process.com From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: Re: NFS Mount Problems In-Reply-To: <38DB4826.70A12AC8@cessna.textron.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I would agree try issuing $ netcu nslookup JERS09 on all of the client systems. Jim At 10:49 AM 3/24/00 -0600, you wrote: >Kevin, > >I can't comment on this specific problem. However, I've had similar >experiences in the past with TCPware's telnet client running on my >VMS machines and various clients on my NCD X-terminals. In each >instance, the *real* problem was my company's awful DNS server. > >I would suggest that you double-check the list of Domain Name servers >in JERS0A's TCPware configuration. If you are not using a static >host file, you may want to consider having one at least for those >systems which are accessed frequently from your cluster. > >Kevin Phillip wrote: > > ... > > When I use NFSMOUNT to mount JERS09's disk on one of the cluster nodes > > (JERS0B), it works perfectly. But when I use NFSMOUNT on the other node > > (JERS0A), I get a device timeout. I also get the same result when mounting > > on EXTEL. > > > > The weird thing is that I can mount the disk if I use JERS09's IP address > > but not the node name. Yet, I can ping and telnet onto JERS09 from JERS0A > > and EXTEL. > > ... > >-- >Dale D. Lutes >Flight Data Systems >Cessna Aircraft Company >316-517-7109 _________________________________________________________________________ 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, 24 Mar 2000 12:20:58 -0500 Reply-To: Info-TCPware@process.com From: "Robert Cervantez" To: Subject: SMTP Logging.. Date: Fri, 24 Mar 2000 09:17:20 -0800 Message-ID: <000001bf95b4$d043a810$786acbd1@symcastsg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <4.2.2.20000324095814.048a2a30@mehlhop.org> Is there any way to enable logging for smtp connections? I am interested in user, time the message was spooled, and size of the message. Thanks, Rob. ================================================================================ Archive-Date: Mon, 27 Mar 2000 17:43:52 -0500 From: Andy Reply-To: Info-TCPware@process.com Subject: Timezone settings Date: Mon, 27 Mar 2000 22:27:48 GMT Message-ID: <8bon8f$1pt$1@nnrp1.deja.com> To: Info-TCPware@PROCESS.COM Well, it's that time of year again where our clocks moved an hour forward... and now I've got the same timezone-related issue I had last year. Config: VAX running VMS V6.2 together with TCPware V5.4-3. I'm in the UK so I alternate between GMT in the winter and BST (British Summer Time). BST has just cut in (the last Sunday of March). I configured TCPware as follows: $ NETCU_TIMEZONE == "UT" $ NETCU_TIMEZONE_NAME == "GMT" $ NETCU_TIMEZONE_RULES == "Britain" So far so good. The clock got bumped an hour forward early Sunday morning as expected. Now I'm running on BST a NETCU SHOW TIMEZONE command comes out with: "Offset from universal time (UT) is +01:00:00 (BST)" which all looks fine until the VAX sends an SMTP message through to Microsoft Exchange. When you read the message through Outlook the 'received' time in the Inbox is correct. But when you open the message the 'sent' time that's displayed is an hour ahead of everything else. For example, it's now 23:24 on Monday evening in the UK. I mail from the VAX something like: $ MAIL/SUBJ="TEST" NL: SMTP%"""Myname@company.com""" The message gets delivered OK, but when you open it to read it the SENT part reports as "Tuesday 00:24" - which is that hour later. Has anybody else experienced this & solved it, or am I missing a basic trick somewhere along the line ? Should I be running the TIMED service alongside the NTP daemon ? Thanks for any help ! -Andy Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Mon, 27 Mar 2000 18:10:16 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE860251A4FA@lespaul.process.com> From: Matt Brightman Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Timezone settings Date: Mon, 27 Mar 2000 18:08:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Andy, Try the following: $ DEF/SYS/EXEC MULTINET_TIMEZONE "BST" (And yes, I did mean to say Multinet). Then restart SMTP with @TCPWARE:START_SMTP Regards, -Matt Brightman Process Software Corp. > -----Original Message----- > From: Andy [mailto:andyw9804@my-deja.com] > Sent: Monday, March 27, 2000 5:28 PM > To: Info-TCPware@PROCESS.COM > Subject: Timezone settings > > > > Well, it's that time of year again where our clocks moved an hour > forward... and now I've got the same timezone-related issue I had last > year. > Config: VAX running VMS V6.2 together with TCPware V5.4-3. I'm in the > UK so I alternate between GMT in the winter and BST (British Summer > Time). BST has just cut in (the last Sunday of March). > I configured TCPware as follows: > $ NETCU_TIMEZONE == "UT" > $ NETCU_TIMEZONE_NAME == "GMT" > $ NETCU_TIMEZONE_RULES == "Britain" > So far so good. The clock got bumped an hour forward early Sunday > morning as expected. Now I'm running on BST a NETCU SHOW TIMEZONE > command comes out with: > "Offset from universal time (UT) is +01:00:00 (BST)" > which all looks fine until the VAX sends an SMTP message through to > Microsoft Exchange. When you read the message through Outlook > the 'received' time in the Inbox is correct. But when you open the > message the 'sent' time that's displayed is an hour ahead of > everything > else. For example, it's now 23:24 on Monday evening in the UK. I mail > from the VAX something like: > $ MAIL/SUBJ="TEST" NL: SMTP%"""Myname@company.com""" > The message gets delivered OK, but when you open it to read > it the SENT > part reports as "Tuesday 00:24" - which is that hour later. > Has anybody else experienced this & solved it, or am I missing a basic > trick somewhere along the line ? Should I be running the TIMED service > alongside the NTP daemon ? > Thanks for any help ! > -Andy > > > Sent via Deja.com http://www.deja.com/ > Before you buy. > ================================================================================ Archive-Date: Tue, 28 Mar 2000 10:10:10 -0500 Message-ID: <75E5B8E274DBD1118D6800805FE60E7703A68915@ntprdex4.admin.liffe.com> From: Andy Williams Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Timezone settings Date: Tue, 28 Mar 2000 16:08:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Yep, thanks Matt ! That solves the 'sent' time, but am I now back where I started in that I have something that needs to be manually adjusted on the systems every time the clocks change ? I have over 200 VMS systems here & the only reason we have to move up from V5.3-2 (which still runs on most of our servers) is the automatic time change. Ummm, can you give the background on why I need to specify a Multinet logical name when I'm running TCPware ? Cheers, Andy Williams OpenVMS System Specialist Andy.Williams@LIFFE.nospam.com +44 171 379 2581 -----Original Message----- From: Matt Brightman [mailto:Brightman@process.com] Sent: Tuesday, March 28, 2000 12:08 AM To: 'Info-TCPware@process.com' Subject: RE: Timezone settings ---------------------------------------------------------------------- Warning - This email originates from the Internet. If you are in any doubt as to the contents of the email then contact PC Support on ext.2288. ---------------------------------------------------------------------- Andy, Try the following: $ DEF/SYS/EXEC MULTINET_TIMEZONE "BST" (And yes, I did mean to say Multinet). Then restart SMTP with @TCPWARE:START_SMTP Regards, -Matt Brightman Process Software Corp. > -----Original Message----- > From: Andy [mailto:andyw9804@my-deja.com] > Sent: Monday, March 27, 2000 5:28 PM > To: Info-TCPware@PROCESS.COM > Subject: Timezone settings > > > > Well, it's that time of year again where our clocks moved an hour > forward... and now I've got the same timezone-related issue I had last > year. > Config: VAX running VMS V6.2 together with TCPware V5.4-3. I'm in the > UK so I alternate between GMT in the winter and BST (British Summer > Time). BST has just cut in (the last Sunday of March). > I configured TCPware as follows: > $ NETCU_TIMEZONE == "UT" > $ NETCU_TIMEZONE_NAME == "GMT" > $ NETCU_TIMEZONE_RULES == "Britain" > So far so good. The clock got bumped an hour forward early Sunday > morning as expected. Now I'm running on BST a NETCU SHOW TIMEZONE > command comes out with: > "Offset from universal time (UT) is +01:00:00 (BST)" > which all looks fine until the VAX sends an SMTP message through to > Microsoft Exchange. When you read the message through Outlook > the 'received' time in the Inbox is correct. But when you open the > message the 'sent' time that's displayed is an hour ahead of > everything > else. For example, it's now 23:24 on Monday evening in the UK. I mail > from the VAX something like: > $ MAIL/SUBJ="TEST" NL: SMTP%"""Myname@company.com""" > The message gets delivered OK, but when you open it to read > it the SENT > part reports as "Tuesday 00:24" - which is that hour later. > Has anybody else experienced this & solved it, or am I missing a basic > trick somewhere along the line ? Should I be running the TIMED service > alongside the NTP daemon ? > Thanks for any help ! > -Andy > > > Sent via Deja.com http://www.deja.com/ > Before you buy. > ---------------------------------------------------------------------- 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, 28 Mar 2000 13:11:20 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE860251A502@lespaul.process.com> From: Matt Brightman Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Timezone settings Date: Tue, 28 Mar 2000 13:09:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > > Yep, thanks Matt ! That solves the 'sent' time, but am I now > back where I > started in that I have something that needs to be manually > adjusted on the > systems every time the clocks change ? I have over 200 VMS > systems here & > the only reason we have to move up from V5.3-2 (which still > runs on most of > our servers) is the automatic time change. > > Ummm, can you give the background on why I need to specify a Multinet > logical name when I'm running TCPware ? > Andy, TCPware v5.4 has a new SMTP server. That SMTP server actually came from the Multinet product. In the porting of the Multinet SMTP server to TCPware, the reference to the timezone logical was missed. Therefore the TCPware v5.4 SMTP server is looking for the existence of the MULTINET_TIMEZONE logical to find out what timezone it's in. Since it doesn't find the MULTINET_TIMEZONE logical it assumes that it's in GMT. This was an oversight and is being addressed. There will be a patch coming out for TCPware shortly that fixes this. When it's available there will be an announcement of it on this list. Regards, -Matt Brightman ================================================================================ Archive-Date: Tue, 28 Mar 2000 16:26:16 -0500 From: Andy Reply-To: Info-TCPware@process.com Subject: RE: Timezone settings Date: Tue, 28 Mar 2000 21:14:57 GMT Message-ID: <8br7c2$rd1$1@nnrp1.deja.com> To: Info-TCPware@PROCESS.COM In article <63D30D6E10CFD11190A90000F805FE860251A502@lespaul.process.com>, Matt Brightman wrote: > TCPware v5.4 has a new SMTP server. That SMTP server actually came from the > Multinet product. In the porting of the Multinet SMTP server to TCPware, > the reference to the timezone logical was missed. Therefore the TCPware > v5.4 SMTP server is looking for the existence of the MULTINET_TIMEZONE > logical to find out what timezone it's in. Since it doesn't find the > MULTINET_TIMEZONE logical it assumes that it's in GMT. This was an > oversight and is being addressed. There will be a patch coming out for > TCPware shortly that fixes this. When it's available there will be an > announcement of it on this list. What about the automatic adjustment of the system time ? By defining this logical name have I overridden all the rule-based stuff ? Will by clocks refuse to return to GMT in October while this logical is set ? Cheers, -Andy Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Fri, 31 Mar 2000 08:13:56 -0500 Message-ID: <38E498BF.384CD8AD@SMTP.DeltaTel.RU> Date: Fri, 31 Mar 2000 16:23:27 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: TCPWare 5.4-3 & Telnet Symbiont Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi All! I use printer HP LJ5si and special device control library for perform some action (like font switching), when I'm need to print something I use PRINT .../SETUP=. My LJ eject the blank page before every printing, I see (by NETCU DEBUG/TCP) that in stream after body of setup module exist FF. Where this FF is added, in PCM or in symbiont? Any tips & trisk will be greately appreciated. TCPWare TCP 5.4-3, VMS 7.1-1h1 "TCPWARE_TSSYM_LJ5SI_1" = "PSrv4,9100,raw,noopcom" Server queue LJ5SI_1, idle, on DTV3::, mounted form DEFAULT /AUTOSTART_ON=(DTV5::,DTV3::,DTV4::) /BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) /LIBRARY=LJ4SI /OWNER=[SYSTEM] /PROCESSOR=TCPWARE_TSSYM /NO_INITIAL_FF /PROTECTION=(S:M,O:D,G:R,W:S) /SCHEDULE=(NOSIZE) -- 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, 31 Mar 2000 08:57:58 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE860251A52A@lespaul.process.com> From: Matt Brightman Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Timezone settings Date: Fri, 31 Mar 2000 08:55:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" The existance of the MULTINET_TIMEZONE logical on your TCPware system won't affect system time. The only thing that looks for that logical is the SMTP server. The SMTP server will be fixed by the time October rolls around so that it looks for the correct logical (TCPWARE_TIMEZONE) and you won't have to worry about this any more. Regards, -Matt > -----Original Message----- > From: Andy [mailto:andyw9804@my-deja.com] > Sent: Tuesday, March 28, 2000 4:15 PM > To: Info-TCPware@PROCESS.COM > Subject: RE: Timezone settings > > > > In article > <63D30D6E10CFD11190A90000F805FE860251A502@lespaul.process.com>, > Matt Brightman wrote: > > TCPware v5.4 has a new SMTP server. That SMTP server actually came > from the > > Multinet product. In the porting of the Multinet SMTP server to > TCPware, > > the reference to the timezone logical was missed. Therefore the > TCPware > > v5.4 SMTP server is looking for the existence of the > MULTINET_TIMEZONE > > logical to find out what timezone it's in. Since it doesn't find the > > MULTINET_TIMEZONE logical it assumes that it's in GMT. This was an > > oversight and is being addressed. There will be a patch > coming out for > > TCPware shortly that fixes this. When it's available there > will be an > > announcement of it on this list. > > What about the automatic adjustment of the system time ? By defining > this logical name have I overridden all the rule-based stuff > ? Will by > clocks refuse to return to GMT in October while this logical is set ? > > Cheers, > > -Andy > > > Sent via Deja.com http://www.deja.com/ > Before you buy. > ================================================================================ Archive-Date: Fri, 31 Mar 2000 10:14:45 -0500 Subject: Re: TCPWare 5.4-3 & Telnet Symbiont From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <38e4bfe7$1@news.kapsch.co.at> Date: 31 Mar 2000 16:10:31 +0100 To: Info-TCPware@PROCESS.COM In article <38E498BF.384CD8AD@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: > I use printer HP LJ5si and special device control library for perform some action >(like font switching), when I'm need to print something I use PRINT >..../SETUP=. > My LJ eject the blank page before every printing, I see (by NETCU DEBUG/TCP) that in >stream after body of setup module exist FF. > > Where this FF is added, in PCM or in symbiont? > Any tips & trisk will be greately appreciated. Reminds me of the long list of similar questions (blank pages on HP printers). Check the VMS FAQ or the VMS Wizard area http://www.openvms.digital.com/wizard/openvms_faq.html http://www.openvms.digital.com/wizard/index.html -- 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