Archive-Date: Wed, 1 Apr 1998 03:50:21 -0400 Subject: Re: Loooooong delay in getting a Username prompt Message-ID: <1998Apr1.011522@process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 1 Apr 98 01:15:22 -0500 To: Info-TCPware@PROCESS.COM In article <199803311521.3523734.7@mdill.tm.net>, 3in7ifi@mdill.tm.net (Daniel A. Gauthier) writes: > > Sorry, I meant REVERSE-resolution. The PCs use the IP address rather than the name to connect, this partially solved the problem, but there is still a 60-90 second delay before the logon screen appears (after telnet negotiation). > (NOTE that this is now a very rare problem). Removing the route to the DNS from the VAX resulted in immediate connects, as does putting the PC hosts in the HOSTS. file on the VAX, but through the wonders of DHCP, they keep changing. Fortunately reaching the DNS has not been a problem for some time. Removing the route to the DNS results in all connects in SHOW USERS/FULL showing the IP address rather than hostnmame, and adding the PC's addresses to HOSTS. results in flexible name displays, but I would st> i > ll like to avoid the occasional (now very rare) delay caused by the network and/or nameserver being down when a PC's address is not in HOSTS. We are a 24 hour operation and I prefer to have 100% reliability by whatever means possible (redundancy, backups, secondaries, and fallbacks). > This problem, from the original description, is on the TCPware end and occurs because it is looking up the hostname for the IP-address - if there is no name server or DNS is mis-configured, you usually have a 60 second delay after the TELNET connection is started before you get the VMS login sequence. To fix this, you have two choices: - Disable the reverse lookup (that's what Kristy Gleason's steps do). - Fix the mis-configured name server(s)/configuration. If you are loosing connectivity to the name server, you might consider a caching name server or (if possible) a local secondary. - Bernie Volz Process Software ================================================================================ Archive-Date: Wed, 1 Apr 1998 11:58:24 -0400 Message-ID: <19980401160230.21749.rocketmail@send1d.yahoomail.com> Date: Wed, 1 Apr 1998 08:02:30 -0800 (PST) From: Chris Wolfe Reply-To: Info-TCPware@process.com Subject: RE: Loooooong delay in getting a Username prompt To: Info-TCPware@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Thanks, Kristy! The telnetd_flag param was the ticket... - Chris ---"Kristy, Technical Support Specialist" wrote: > > >From: Chris Wolfe > > >Hello, > >We're running TCPware v5.2-3 on a DEC Alpha running OVMS v6.2. We've > >noticed for the past week or so that when telnetting in from a PC > >client, we get a 30-45 second delay before getting the Username prompt. > > >Is there something I can do to speed this up? We've usually seen > >maybe a 2-5 second delay, and just assumed that was a function of the > >overall Alpha box speed or maybe how 'busy' it was. > > >Thanks for any help! > >Chris Wolfe > > Hiya Chris, > > Edit TCPWARE_CONFIGURE.COM, page down until you get to the TELNET_SERVERS == 1, > On the next line, enter: > > $ telnetd_flags == 257 > > Save and exit the file and then @tcpware:restart telnet. > > -- Kristy > > +--------------------------------------------------------------------+ > | Kristy S. Gleason Process Software Corporation | > | Technical Support Specialist 959 Concord Road | > | Email: gleason@process.com Framingham, MA 01701-4682 | > | Tel: 800-394-8700 FAX: 508-879-0042 | > +--------------------------------------------------------------------+ > > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com ================================================================================ Archive-Date: Wed, 1 Apr 1998 17:48:16 -0400 From: Delroy Bailey Reply-To: Info-TCPware@process.com Subject: Delay before printing to IP address Date: Wed, 01 Apr 1998 23:36:14 +0100 Message-ID: <3522C15D.42E8C33B@btinternet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Having problems with time delays to printers. Currently running OpenVms 6.2 printing to HP Jetdirect Cards and very very very very close to been lynched by my users !!! Help! ...... delly@btinternet.com Westminster City Council - UK ================================================================================ Archive-Date: Wed, 1 Apr 1998 19:21:01 -0400 Subject: Re: Delay before printing to IP address Message-ID: <1998Apr1.181720@process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 1 Apr 98 18:17:20 -0500 To: Info-TCPware@PROCESS.COM In article <3522C15D.42E8C33B@btinternet.com>, Delroy Bailey writes: > Having problems with time delays to printers. Currently running OpenVms > 6.2 printing to HP Jetdirect Cards and very very very very close to > been lynched by my users !!! > > Help! ...... > > delly@btinternet.com > Westminster City Council - UK > Can you be a bit more specific as to exactly what the problem is? Exactly when are you or your users seeing this time delay? - Bernie Volz Process Software ================================================================================ Archive-Date: Thu, 2 Apr 1998 07:43:59 -0400 From: JimPayne@postmaster.co.uk Reply-To: Info-TCPware@process.com To: info-tcpware@process.com Message-ID: <802565DA.004B1047.00@uks.postmaster.co.uk> Date: Thu, 2 Apr 1998 13:40:11 +0000 Subject: Re: Delay before printing to IP address MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii The problem may well be caused by the fact that, when printing using LPR or VMSLPR, TCPware negotiates a connection with the printer, then reformats the file before actually sending the data. With large files, some printers time-out during the delay Which print symbiont are you using? The problem is FAR worse with the LPR symbiont. I've just dug out some tests I did on a customer site a while ago printing a 2Mb file (not particulary big nowadays when printing graphics). The timings extracted from the NETCU log were: Reformatting time Data transfer time VMSLPR symbiont 2 minutes 30 seconds LPR symbiont 16 minutes 20 seconds The short-term solution might by to switch to the VMSLPR symbiont if you are using the LPR. The long-term requires code changes by Process! This was under 5.2-3 - has is been improved since then??? Why is the LPR symbiont so much slower? Regards Jim | In article <3522C15D.42E8C33B@btinternet.com>, Delroy Bailey | writes: | > Having problems with time delays to printers. Currently running OpenVms | > 6.2 printing to HP Jetdirect Cards and very very very very close to | > been lynched by my users !!! | > | > Help! ...... | > | > delly@btinternet.com | > Westminster City Council - UK | > | | Can you be a bit more specific as to exactly what the problem is? Exactly | when are you or your users seeing this time delay? | | - Bernie Volz | Process Software ___________________________________ To sign up for a free email account, visit http://www.postmaster.co.uk. ================================================================================ Archive-Date: Sat, 4 Apr 1998 00:18:23 -0400 From: jleslie@aco.aspentech.com (Jerry Leslie) Reply-To: Info-TCPware@process.com Subject: Re: TCP IP windows 3.11 Date: 4 Apr 1998 04:55:03 GMT Message-ID: <6g4ef7$41o$1@igate.aco.aspentech.com> To: Info-TCPware@PROCESS.COM Fanie (ffourie@mweb.co.za) wrote: : Anybody please help! : Where can I find TCP IP for windows 3.11???? : Thanks a lot ftp.microsoft.com, in /Softlib/MSLFILES/TCP32B.EXE --Jerry, Gerald (Jerry) R. Leslie jerry.leslie@aspentech.com Aspen Technology, Inc. (my opinions are strictly my own) ================================================================================ Archive-Date: Sun, 5 Apr 1998 07:55:16 -0400 From: Delroy Bailey Reply-To: Info-TCPware@process.com Subject: Re: Delay before printing to IP address Date: Sun, 05 Apr 1998 13:44:31 +0100 Message-ID: <35277CAF.CC7A7F55@btinternet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Sorry my problem has been resloved. Apologies for not providing as much info as I should have but I shall outline the problem below: Something changed on our networks DNS server which has yet to be owned up to by our network team. The problem revolved around the same old reverse lookup problem (Disabling with TELNETD flag set to 256 worked fine for our telnet connections but we still found a delay with printing of about 1 minute which is shattering for the amount of printouts generated on our systems. As a temporary measure I had to stop DNS on the Vax by typing:- NETCU> STOP/DNS This subsequently returned our instant connection times once more, and has bought me some time to murder some network specialist or another. ================================================================================ Archive-Date: Mon, 6 Apr 1998 13:40:24 -0400 From: "Dries" Reply-To: Info-TCPware@process.com Subject: Need Telnet Client For Dos Date: 6 Apr 1998 17:20:01 GMT Message-ID: <01bd5889$3cc8d340$54d219c4@dries.lex.co.za> To: Info-TCPware@PROCESS.COM I need a Telnet Client for MS-Dos. No Packet drivers needed, must work with MsClient for Dos. Please mail me if anyone have such a program bartel@lex.co.za ================================================================================ Archive-Date: Mon, 6 Apr 1998 13:45:06 -0400 Date: Mon, 06 Apr 1998 13:45:06 -0400 (EDT) From: "David A. Massaro, ITEC systems and networking" Reply-To: Info-TCPware@process.com Subject: OPCOM messages To: Info-TCPware@PROCESS.COM Message-ID: <01IVJUKAHBRM9I4IBH@mail.suny.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hello, Since last night's reboot we have been receiving the following OPCOM messages (about every minute) %%%%%%%%%%% OPCOM 5-APR-1998 23:38:25.50 %%%%%%%%%%% Message from user SYSTEM on ALPHA2 %TCPWARE_NLM-F-NOSUCHNODE, remote node is unknown The only changes to TCPware before the boot was to change the time zone string and to comment out some symbols related to LPR printing on network printers. Time zone came up ok, printing to the network printers seems ok. Can you help us to identify whatever it is that TCPware is complaining about? We are running on VMS Alpha 6.2-1H3, TCPware 5.2-3 with the required patch. thanks, ================================================================================ Archive-Date: Tue, 7 Apr 1998 13:54:01 -0400 Subject: Re: OPCOM messages Message-ID: <1998Apr7.104912@process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 7 Apr 98 10:49:12 -0500 To: Info-TCPware@PROCESS.COM In article <01IVJUKAHBRM9I4IBH@mail.suny.edu>, "David A. Massaro, ITEC systems and networking" writes: > Hello, > > Since last night's reboot we have been receiving the following OPCOM > messages (about every minute) > > %%%%%%%%%%% OPCOM 5-APR-1998 23:38:25.50 %%%%%%%%%%% > Message from user SYSTEM on ALPHA2 > %TCPWARE_NLM-F-NOSUCHNODE, remote node is unknown > > The only changes to TCPware before the boot was to change the time > zone string and to comment out some symbols related to LPR printing > on network printers. > > Time zone came up ok, printing to the network printers seems ok. Can > you help us to identify whatever it is that TCPware is complaining about? > > We are running on VMS Alpha 6.2-1H3, TCPware 5.2-3 with the required > patch. > > thanks, Try: NETCU SHOW SM and NETCU SHOW SM_BAK This will display the Status Monitor database of hosts that currently have or had network lock manager (NLM) locks outstanding. Check the lists of host names in the output - one of them is likely no longer valid (ie, a NETCU SHOW HOST does not return an IP address). Use: NETCU REMOVE SM or NETCU REMOVE SM_BAK to remove the offending host. - Bernie Volz Process Software ================================================================================ Archive-Date: Wed, 8 Apr 1998 09:25:53 -0400 Date: Wed, 08 Apr 1998 09:25:57 -0400 (EDT) From: "David A. Massaro, ITEC systems and networking" Reply-To: Info-TCPware@process.com Subject: Re: OPCOM messages To: Info-TCPware@process.com Message-ID: <01IVMDM865MA9I4JOS@mail.suny.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hello, > This will display the Status Monitor database of hosts that currently > have or had network lock manager (NLM) locks outstanding. Check the > lists of host names in the output - one of them is likely no longer > valid (ie, a NETCU SHOW HOST does not return an IP address). > > Use: > NETCU REMOVE SM > or NETCU REMOVE SM_BAK > > to remove the offending host. $ netcu show sm - no output $ netcu show sm_bak STATD SM_BAK Database V5.2-3 Copyright (c) 1997 Process Software Corporation Hosts to be notified: --------------------- %TCPWARE_NETCU-F-OUTSTAOVE, output statement overflows record unit -2 file SYS$OUTPUT:.; user PC 00000000 I don't see a host name to remove, do you want a dump of the sm_bak.dat file? -Dave ,---------------------------------------------------------. | David A. Massaro | | Sr. Systems Programmer - SUNY ITEC | | Computing Services - Twin Rise 208 | | State University of New York College at Buffalo | | 1300 Elmwood Avenue | | Buffalo, New York, 14222 | | U.S.A., Planet Earth | | | | Internet: MassarDA@ITEC.SUNY.EDU | | SUNY DECnet: sbscVC::MassarDA | | Pager-mail: 7166332568.6191954@pagenet.net | | | | VOICE: 716-878-ITEC | | FAX: 716-878-4235 | | URL: h-d.itec.suny.edu | `---------------------------------------------------------' Disclaimer: "However, in their extramural utterances employees have an obligation to indicate that they are not institutional spokespersons." -Policies of the Board of Trustees, 1989 > From: IN%"Info-TCPware@process.com" 7-APR-1998 14:02:53.14 > To: IN%"Info-TCPware@PROCESS.COM" > CC: > Subj: RE: OPCOM messages > > Return-path: > Received: from triton.process.com by mail.suny.edu (PMDF V5.1-9 #24514) > with ESMTP id <01IVL9HQHU349I4JS6@mail.suny.edu> for MASSARDA@mail.suny.edu; > Tue, 7 Apr 1998 14:02:50 EDT > Date: Tue, 07 Apr 1998 10:49:12 -0500 > From: volz@process.com (Bernie Volz) > Subject: Re: OPCOM messages > To: Info-TCPware@PROCESS.COM > Reply-to: Info-TCPware@process.com > Message-id: <1998Apr7.104912@process.com> > List-Unsubscribe: > X-Listname: Process TCPware Discussion List > > In article <01IVJUKAHBRM9I4IBH@mail.suny.edu>, "David A. Massaro, ITEC systems and networking" writes: > > Hello, > > > > Since last night's reboot we have been receiving the following OPCOM > > messages (about every minute) > > > > %%%%%%%%%%% OPCOM 5-APR-1998 23:38:25.50 %%%%%%%%%%% > > Message from user SYSTEM on ALPHA2 > > %TCPWARE_NLM-F-NOSUCHNODE, remote node is unknown > > > > The only changes to TCPware before the boot was to change the time > > zone string and to comment out some symbols related to LPR printing > > on network printers. > > > > Time zone came up ok, printing to the network printers seems ok. Can > > you help us to identify whatever it is that TCPware is complaining about? > > > > We are running on VMS Alpha 6.2-1H3, TCPware 5.2-3 with the required > > patch. > > > > thanks, > > Try: > NETCU SHOW SM > and NETCU SHOW SM_BAK > > This will display the Status Monitor database of hosts that currently > have or had network lock manager (NLM) locks outstanding. Check the > lists of host names in the output - one of them is likely no longer > valid (ie, a NETCU SHOW HOST does not return an IP address). > > Use: > NETCU REMOVE SM > or NETCU REMOVE SM_BAK > > to remove the offending host. > > - Bernie Volz > Process Software ================================================================================ Archive-Date: Wed, 8 Apr 1998 11:32:56 -0400 From: JimPayne@postmaster.co.uk Reply-To: Info-TCPware@process.com To: info-tcpware@process.com Message-ID: <802565E0.0055903B.00@uks.postmaster.co.uk> Date: Wed, 8 Apr 1998 16:34:36 +0100 Subject: Re: Delay before printing to IP address MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I'm glad Delroy's problem was resolved, even if my mail was not relevant! Out of interest, have others experienced the problems I described below? Regards Jim > The problem may well be caused by the fact that, when printing using > LPR or VMSLPR, TCPware negotiates a connection with the printer, then > reformats the file before actually sending the data. > With large files, some printers time-out during the delay > Which print symbiont are you using? The problem is FAR worse with the > LPR symbiont. I've just dug out some tests I did on a customer site a > while ago printing a 2Mb file (not particulary big nowadays when > printing graphics). > The timings extracted from the NETCU log were: > Reformatting time Data transfer time > > VMSLPR symbiont 2 minutes 30 seconds > LPR symbiont 16 minutes 20 seconds > > The short-term solution might by to switch to the VMSLPR symbiont if > you are using the LPR. > The long-term requires code changes by Process! > This was under 5.2-3 - has is been improved since then??? Why is the > LPR symbiont so much slower? ___________________________________ To sign up for a free email account, visit http://www.postmaster.co.uk. ================================================================================ Archive-Date: Wed, 8 Apr 1998 16:20:54 -0400 From: Sylvain Plante Reply-To: Info-TCPware@process.com Subject: NFS_PROXY Date: Wed, 08 Apr 1998 16:04:10 -0400 Message-ID: <352BD83A.351D@ccg.rncan.gc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: Info-TCPware@PROCESS.COM Hi everybody, Is there any way to modify the NFS PROXY from NETCU in all Alpha server in a cluster. About the same way, it is possible to use AUTHORIZE. We just keep one data base SYSUAF when we define a logical for SYSUAF within SYLOGICALS. Thank you - ------------------------------------------------------------------- Sylvain Plante Gestionnaire de système tel : 819-564-4832 Centre d'information topographique fax : 819-564-5698 2144, rue King ouest, bureau 100 E_mail : plante@ccg.RNcan.gc.ca Sherbrooke (Quebec) J1J 2E8 www : http://www.ccg.RNcan.gc.ca CANADA J1J 2E8 ------------------------------------------------------------------- ================================================================================ Archive-Date: Wed, 8 Apr 1998 20:40:22 -0400 From: jleslie@aco.aspentech.com (Jerry Leslie) Reply-To: Info-TCPware@process.com Subject: Multinet 4.0B Not Allowing Underscores in Service Names ? Date: 8 Apr 1998 23:12:12 GMT Message-ID: <6gh08c$1ep$1@igate.aco.aspentech.com> Keywords: underscore,services,vms,tcp To: Info-TCPware@PROCESS.COM The following is a question from one of our developers for a package that runs with UCX, TCP_ware, and Multinet, hence the cross-posting. However this problem is with Multinet V4.0B at a client's site. "Is an underscore a valid character for a service name ?. "If not, what is the RFC or STD which specifies that underscore is not a valid character for a service name ? Note the following examples from RFC 1700: Port Assignments: Keyword Decimal Description References ------- ------- ----------- ---------- ocs_cmu 428/tcp OCS_CMU ocs_cmu 428/udp OCS_CMU ocs_amu 429/tcp OCS_AMU ocs_amu 429/udp OCS_AMU cvc_hostd 442/tcp cvc_hostd cvc_hostd 442/udp cvc_hostd As well as the following 'man' page from HP-UX. TIA, --Jerry, Gerald (Jerry) R. Leslie jerry.leslie@aspentech.com Aspen Technology, Inc. (my opinions are strictly my own) ============================================================================== {"man services" from an HP-UX 10.20 system} # man services services(4) services(4) NAME services - service name data base DESCRIPTION The file /etc/services associates official service names and aliases with the port number and protocol the services use. For each service a single line should be present with the following information: Port numbers 0 through 1023 are assigned by RFC 1700. This RFC also lists the conventional use of various ports with numbers greater than 1023. Aliases are other names under which a service is known. Library routines such as getservbyname() can be invoked with a service alias instead of the service official name. For example: shell 514/tcp cmd In this example, getservbyname() can be invoked with cmd instead of shell: sp = getservbyname("cmd", "tcp"); instead of sp = getservbyname("shell", "tcp"); Both produce the same results. A line cannot start with a space or tab. Items are separated by any number of blanks (space or tab characters in any combination). The port number and protocol name are considered a single item. A / is used to separate the port and protocol (for example, 512/tcp). A # character indicates the beginning of a comment. Characters from the # to the end of the line are not interpreted by routines which search the file. Service names can contain any printable character other than a white space, newline, or comment character. Trailing blanks (spaces or tabs) are allowed at the end of a line. Not all services listed in this file are available on HP-UX. EXAMPLES shell 514/tcp cmd telnet 23/tcp login 513/tcp Hewlett-Packard Company - 1 - HP-UX Release 10.20: July 1996 services(4) services(4) AUTHOR services was developed by the University of California, Berkeley. FILES /etc/services SEE ALSO getservent(3N). Hewlett-Packard Company - 2 - HP-UX Release 10.20: July 1996 ================================================================================ Archive-Date: Sat, 11 Apr 1998 19:41:15 -0400 Subject: Re: OPCOM messages Message-ID: <1998Apr10.171755@process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 10 Apr 98 17:17:55 -0500 To: Info-TCPware@PROCESS.COM In article <01IVMDM865MA9I4JOS@mail.suny.edu>, "David A. Massaro, ITEC systems and networking" writes: > > $ netcu show sm_bak > STATD SM_BAK Database V5.2-3 Copyright (c) 1997 Process Software Corporation > > Hosts to be notified: > --------------------- > %TCPWARE_NETCU-F-OUTSTAOVE, output statement overflows record > unit -2 file SYS$OUTPUT:.; > user PC 00000000 > > I don't see a host name to remove, do you want a dump of the sm_bak.dat > file? > > -Dave Yuck ... we'll have to look into fixing that! Yes, do that. I think it best you try DUMP/RECORD instead of just DUMP (it is an RMS indexed file). Another option is just try: $ OPEN/READ INFILE TCPWARE:SM_BAK.DAT $LOOP: $ READ/ERR=DONE INFILE LINE $ WRITE SYS$OUTPUT LINE $ GOTO LOOP $DONE: $ CLOSE INFILE Do mail me the output! I'd like to see what the problem might be. This explains the problem - I doubt you have a host name that is this long (don't recall exactly what the length limit is, but the error likely occurs at something more than 128 characters). There is another option you can also consider ... - Stop the NLM process (this will upset any outstanding locks!) Use STOP/ID - DELETE TCPWARE:SM_BAK.DAT - NETCU CREATE SM_BAK - @TCPWARE:START CNFS (this should restart NLM) Note that this might be disruptive to NFS users (client and/or server). - Bernie Volz Process Software ================================================================================ Archive-Date: Sat, 11 Apr 1998 19:47:40 -0400 Subject: Re: NFS_PROXY Message-ID: <1998Apr10.180141@process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 10 Apr 98 18:01:41 -0500 To: Info-TCPware@PROCESS.COM In article <352BD83A.351D@ccg.rncan.gc.ca>, Sylvain Plante writes: > Hi everybody, > > Is there any way to modify the NFS PROXY from NETCU > in all Alpha server in a cluster. > > About the same way, it is possible to use AUTHORIZE. > We just keep one data base SYSUAF when we define a > logical for SYSUAF within SYLOGICALS. > > Thank you Normally, TCPware does use a CLUSTER-COMMON PROXY database (this does assume you have a SYS$COMMON area for all your nodes, which of course isn't true for mixed-architecture clusters - but there are always tricks to solving that problem). So, when you update the proxy lists, the common file is updated. However, we do not support a cluster-wide PROXY reload. Yet, this can be accomplished by using SYSMAN: MCR SYSMAN SET ENVIR/CLUSTER (or /NODE=(node-list)) DO NETCU RELOAD PROXY EXIT - Bernie Volz Process Software ================================================================================ Archive-Date: Wed, 15 Apr 1998 11:56:12 -0400 From: WA@GURU1.SDA-ATS.CH (Chris J. WALTHER) Subject: SMTP: MIME-attachements, howto? Date: 15 Apr 1998 15:52:03 GMT Message-ID: Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Hi! Is there a way to send attachements in a MIME-Format using TCPware (5.3) SMTP-gateway? The problem is how to get a Content-Type line into the mail header. Something like this: Content-Type: multipart/mixed; boundary="------------BE1CD63FB6DCB6D5D984A5F9" In my case no interactive user interface (like VMSmail) must be involved. Everything should be done on program or DCL level. Also, I have the attachement already converted to MIME. Is there a solution? -- ChrisW ================================================================================ Archive-Date: Wed, 15 Apr 1998 11:58:44 -0400 Resent-Date: Wed, 15 Apr 1998 11:58:17 -1300 Resent-From: info-tcpware@process.com Resent-To: Sender: goathunter@goat.process.com Date: Wed, 15 Apr 1998 10:58:11 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <009C4BE5.D874DD2A.2@goat.process.com> Subject: RE: SMTP: MIME-attachements, howto? WA@GURU1.SDA-ATS.CH (Chris J. WALTHER) writes: > >Is there a way to send attachements in a MIME-Format using >TCPware (5.3) SMTP-gateway? > >The problem is how to get a Content-Type line into the mail header. >Something like this: > >Content-Type: multipart/mixed; boundary="------------BE1CD63FB6DCB6D5D984A5F9" > >In my case no interactive user interface (like VMSmail) >must be involved. Everything should be done on program >or DCL level. Also, I have the attachement already converted >to MIME. > >Is there a solution? > One way (and the only one I can think of) is to have your program talk to the TCPware SMTP server to send the message; you would add all the desired headers in your program. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Wed, 15 Apr 1998 14:58:55 -0400 Message-ID: From: Reply-To: Info-TCPware@process.com To: Subject: Daylight savings time changes Date: Wed, 15 Apr 1998 14:02:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We are currently running TCPware 5.1-4 on 40-some nodes, and are upgrading to 5.3-2 (so far on 1 node). Our current method of changing in/out of daylight savings time is to NETCU SET TIMEZONE ... Edit TCPWARE:TCPWARE_CONFIGURE.COM so that we reboot with the right timezone. On nodes that are not running NTP: SET TIME=... 1) The TCPware 5.3 Installation and Configuration Guide, p 3.5, strongly advises me not to edit TCPWARE:TCPWARE_CONFIGURE.COM. I did not notice that warning in 5.1. Aside from needing to preserve the file organization, record format and record attributes, are there any other concerns with editing the file, and do these even matter? 2) When using NTP in 5.1-4, we still seem to need to set the time just to get the clock close to being right. Is this an issue any more with 5.3-2? 3) Is there a better way to deal with the change in time? Thanks in advance. --Joe Senulis Technical Support Specialist Wisconsin Department of Natural Resources ================================================================================ Archive-Date: Wed, 15 Apr 1998 15:12:09 -0400 Date: Wed, 15 Apr 1998 15:11 -0500 From: BRYANT@PROCESS.COM (Geoff Bryant) Reply-To: Info-TCPware@process.com Message-ID: <009C4C0941DC0E00.F1F7@PROCESS.COM> To: Info-TCPware@process.com Subject: RE: Daylight savings time changes writes: [...] >1) The TCPware 5.3 Installation and Configuration Guide, p 3.5, strongly >advises me not to edit TCPWARE:TCPWARE_CONFIGURE.COM. I did not notice >that warning in 5.1. Aside from needing to preserve the file >organization, record format and record attributes, are there any other >concerns with editing the file, and do these even matter? This file is re-written when you make changes via the standard configuration tool CNFNET.COM. So, if you edit it directly, your changes will be lost if you use the config tool. It can also be difficult to track down errors in editing the file. >--Joe Senulis >Technical Support Specialist >Wisconsin Department of Natural Resources ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Wed, 15 Apr 1998 15:40:04 -0400 Message-ID: From: Reply-To: Info-TCPware@process.com To: Subject: RE: Daylight savings time changes Date: Wed, 15 Apr 1998 14:44:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Geoff, I understand and agree that editing TCPWARE_CONFIGURE.COM is not good. However, I do not want to run (or set up a script to run) CNFNET on 40 nodes twice a year. (At this frequency, I would probably forget to change the script as we update TCPware.) What would seem best from my point of view is if NETCU SET TIMEZONE also updated TCPWARE_CONFIGURE.COM, but barring that, back to my original question: 3) Is there a better way to deal with the change in time? or is manually running NETCU and answering/acknowledging all the settings the only recommended way? Also, if I am running NTP under TCPware 5.3, so I need to do a VMS SET TIME after changing the timezone? Thanks. --Joe >---------- >From: BRYANT@PROCESS.COM[SMTP:BRYANT@PROCESS.COM] >Sent: Wednesday, April 15, 1998 3:11 PM >To: Info-TCPware@process.com >Subject: RE: Daylight savings time changes > > writes: >[...] >>1) The TCPware 5.3 Installation and Configuration Guide, p 3.5, strongly >>advises me not to edit TCPWARE:TCPWARE_CONFIGURE.COM. I did not notice >>that warning in 5.1. Aside from needing to preserve the file >>organization, record format and record attributes, are there any other >>concerns with editing the file, and do these even matter? > >This file is re-written when you make changes via the standard configuration >tool CNFNET.COM. So, if you edit it directly, your changes will be lost if >you use the config tool. It can also be difficult to track down errors in >editing the file. > >>--Joe Senulis >>Technical Support Specialist >>Wisconsin Department of Natural Resources > >------------------------------------------------------------- >Geoff Bryant bryant@process.com >TCPware/Multinet Engineering >Process Software Corporation http://www.process.com/ >959 Concord St. >Framingham, MA 01701 USA > ================================================================================ Archive-Date: Thu, 16 Apr 1998 10:09:00 -0400 Message-ID: <19980416140827.28932.qmail@hotmail.com> From: "John Richards" Reply-To: Info-TCPware@process.com To: info-tcpware@process.com Subject: StorageWorks and TCPware Content-Type: text/plain Date: Thu, 16 Apr 1998 07:08:26 PDT A customer I'm working with wants to use Digital's Storageworks with TCPware. However, the installation script is UCX-specific. For example, the main configuration script for the Storage Works Command Console contains lines like: $@sys$manager:ucx$symbols $@sys$manager:ucx$fixup and $FILE_NAME = F$SEARCH ("SYS$MANAGER:UCX$UCP_STARTUP.COM") $IF FILE_NAME .EQS. "" THEN GOTO UCXNOTINSTALLED $@SYS$MANAGER:UCX$UCP_STARTUP.COM Not even TCPware's UCX compatability goes that far! Has anyone got this StorageWorks to work with TCPware? Any help much appreciated. Regards John ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com ================================================================================ Archive-Date: Fri, 17 Apr 1998 04:20:25 -0400 Subject: RE: Daylight savings time changes Message-ID: <1998Apr16.203720@process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 16 Apr 98 20:37:20 -0500 To: Info-TCPware@PROCESS.COM In article writes: > > 3) Is there a better way to deal with the change in time? > Let me first deal with another question asked ... editting TCPWARE_CONFIGURE.COM. The reason we state not to edit it is because you need to know what you are doing and must follow some strict rules (and sometimes changing one parameter requires changes to others). However, just changing the timezone from "EST" to "EDT" (or vice versa) should not cause problems. So, go ahead and do it if you need to. Now, to answer the question above (3): ** The following is unsupported and provided for informational purposes only. What we've done here is fairly simple. TCPWARE_CONFIGURE.COM should define the standard timezone (EST, for example). In ROUTING.COM, invoke another command procedure called "TIMEZONE.COM" or something like that. TIMEZONE.COM would be: $ SET NOON $! $! Do standard/daylight savings time fixups $! $ DAY_Sunday = 0 $ DAY_Monday = 6 $ DAY_Tuesday = 5 $ DAY_Wednesday = 4 $ DAY_Thursday = 3 $ DAY_Friday = 2 $ DAY_Saturday = 1 $ TEMPN = DAY_'F$CVTIME("01-APR",,"WEEKDAY")' + 1 $ ST = F$CVTIME("''TEMPN'-APR:02:00:00") $ DAY_Sunday = 0 $ DAY_Monday = 1 $ DAY_Tuesday = 2 $ DAY_Wednesday = 3 $ DAY_Thursday = 4 $ DAY_Friday = 5 $ DAY_Saturday = 6 $ TEMPN = 31 - DAY_'F$CVTIME("31-OCT",,"WEEKDAY")' $ ET = F$CVTIME("''TEMPN'-OCT:02:00:00") $ CT = F$CVTIME() $ TIME = "STANDARD" $ IF ((CT .GES. ST) .AND. (CT .LTS. ET)) THEN TIME = "DAYLIGHT" $ IF (TIME .EQS. "STANDARD") THEN TIMEZONE = "-0500" $ IF (TIME .EQS. "DAYLIGHT") THEN TIMEZONE = "-0400" $ ENDIF $ NETCU SET TIMEZONE 'TIMEZONE' $! End of configuration file Of course, you need to change the following two lines based on your timezone: $ IF (TIME .EQS. "STANDARD") THEN TIMEZONE = "-0500" $ IF (TIME .EQS. "DAYLIGHT") THEN TIMEZONE = "-0400" Note that the procedure follows the rules for the United States. The above will set the proper value at TCPware start-up time. That leaves applying the timezone change when it happens. That is done by another batch job. We happen to run this every day to keep all the clocks in the cluster in reasonable sync and it is as follows: $ SET NOON $! $ DAY_Sunday = 0 $ DAY_Monday = 6 $ DAY_Tuesday = 5 $ DAY_Wednesday = 4 $ DAY_Thursday = 3 $ DAY_Friday = 2 $ DAY_Saturday = 1 $ TEMPN = DAY_'F$CVTIME("01-APR",,"WEEKDAY")' + 1 $ ST = F$CVTIME("''TEMPN'-APR:02:00:00") $ DAY_Sunday = 0 $ DAY_Monday = 1 $ DAY_Tuesday = 2 $ DAY_Wednesday = 3 $ DAY_Thursday = 4 $ DAY_Friday = 5 $ DAY_Saturday = 6 $ TEMPN = 31 - DAY_'F$CVTIME("31-OCT",,"WEEKDAY")' $ ET = F$CVTIME("''TEMPN'-OCT:02:00:00") $ CT = F$CVTIME() $ TIMEZONE = "EST" $ IF ((CT .GES. ST) .AND. (CT .LTS. ET)) THEN TIMEZONE = "EDT" $ IF (P1 .EQS. "") THEN P1 = TIMEZONE $ IF (TIMEZONE .EQS. P1) THEN GOTO NO_TIMEZONE_CHANGE $ P1 = TIMEZONE $ DELTA_TIME = "-01:00:00.00" ! Change to EST $ IF (TIMEZONE .EQS. "EDT") THEN DELTA_TIME = "+01:00:00.00" ! Change to EDT $ SET TIME="''DELTA_TIME'"/CLUSTER $! Now fix up TCPware items as well $ UT_OFFSET = "-0500" $ IF (TIMEZONE .EQS. "EDT") THEN UT_OFFSET = "-0400" $ OPEN/WRITE TZFIXUPS SYS$COMMON:[SYSMGR]00TEMPTZ.COM $ WRITE TZFIXUPS "$ SET NOON" $ WRITE TZFIXUPS "$ NETCU :== $TCPWARE:NETCU" $ WRITE TZFIXUPS "$ NETCU SET TIMEZONE ''UT_OFFSET'" $ WRITE TZFIXUPS "$ DEFINE/SYSTEM/EXEC NEWS_TIMEZONE ''UT_OFFSET'" $ CLOSE TZFIXUPS $ FILE = F$SEARCH("SYS$COMMON:[SYSMGR]00TEMPTZ.COM") $ OPEN/WRITE SYSFIL SYS$COMMON:[SYSMGR]00TEMPTZ1.COM $ WRITE SYSFIL "$ MCR SYSMAN" $ WRITE SYSFIL " SET ENVIRONMENT/CLUSTER" $ WRITE SYSFIL " DO @''FILE'" $ CLOSE SYSFIL $ @SYS$COMMON:[SYSMGR]00TEMPTZ1.COM $ DELETE/NOLOG SYS$COMMON:[SYSMGR]00TEMPTZ1.COM;* $ DELETE 'FILE'/NOLOG $! $NO_TIMEZONE_CHANGE: $ SET TIME="+00:00:00.00"/CLUSTER $! $ SCSNODE = F$EDIT(F$GETSYI("SCSNODE"),"COLLAPSE") $ SUBMIT/NOPRINT/NOLOG/RESTART/AFTER="TOMORROW:+02:00:00" - /QUE=SYS$BATCH$'SCSNODE'/PARAM="''P1'" SYS$MANAGER:TIMEKEEPER You'll have to play with this one a bit to customize it to your needs and timezone. That's left as an exercise for the reader (search for EST and EDT, and -04 and -05). The first time the batch job is run, there will be no P1 so it will assume not to adjust the clock/timezone. NOTE: It also changes the clock on the system (cluster) so beware! Don't send me requests regarding this stuff. It is provided "AS IS" and beware that you'll need to customize it (it was written for our specific needs). It has worked great for many years for us. - Bernie Volz Process Software ================================================================================ Archive-Date: Tue, 21 Apr 1998 10:27:03 -0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com Subject: Re: Q: How similar is TCPWARE QIO programming to UCX ? Date: Tue, 21 Apr 1998 18:12:31 +0400 Message-ID: <353CA94E.79AEE11B@DeltaTel.RU> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM David Jones wrote: > > In message <1998Apr20.194041@process.com>, volz@process.com (Bernie Volz) writes: > >In article <353B51BA.DFB46A03@DeltaTel.RU>, "Ruslan R. Laishev" writes: > >>> Hunter Goatley wrote: > >>> Yes, TCPware's (and MultiNet's) UCX emulation should be virtually > >>> identical to the UCX BG $QIO interface. We do our best to ensure > >>> 100% compatibility. The images produced under UCX should run > >>> without change under both TCPware and Multinet. > > What overhead of this emulation ? > > > >I'm very familar with TCPware's case and the answer is no cost. > >Basically, TCPware has three front ends to the back end TCP/IP layer - > >those 3 interfaces are BG (UCX "emulation"), INET (MultiNet > >"emulation"), and TCPware's native interfaces. > > The original question was about *source code* compatibility, not binary > compatibility. Unless TCPware provides their own copy of UCX$INETDEF.H, > I'd say the answer is no. May be, but I just view the both variant of includes: Begin of Digital's ucx$inetdef.h: /********************************************************************************************************************************/ /* Created: 23-JUL-1996 16:01:01 by OpenVMS SDL EV1-50 */ /* Source: 12-SEP-1995 23:16:14 BUILD4$:[UCX.V41.BL12.SRC.NET]INET_USER.SDL;1 */ /********************************************************************************************************************************/ Begin of TCPWare's ucx$inetdef.h: /********************************************************************************************************************************/ /* Created 31-OCT-1994 17:58:36 by VAX SDL V3.2-12 Source: 14-MAY-1993 18:12:50 BUILD2$:[UCX.V32.BL9.SRC.NET]INET_USER.SDL;2 */ /********************************************************************************************************************************/ May be Process will include latest Digital's ucx$inetdef.h to TCPWare kit and the differences will be dropped? -- Sincerely yours... +--------------------------------------------------------------------+ Delta Telecom JSC Cel: 7+ (812) 116-3222 191119,Russia, St.Petersburg, Fax: 7+ (812) 112-1099 Transportny per. 3 Fido: 2:5030/279 RSA FingerPrint: D1C7 F4D1 9123 25A8 1C12 2F46 8A83 293A +http://www.levitte.org/~rlaishev/----------- SysMan riding Griphon + ================================================================================ Archive-Date: Tue, 21 Apr 1998 15:11:10 -0400 Subject: TCPware Programming Message-ID: <353C89CC.80E@process.com> From: James Gildea Reply-To: Info-TCPware@process.com Date: Tue, 21 Apr 1998 07:58:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM The TCPware development team is in the process of determining where we can most effectively direct our resources. One area of discussion that has arisen is TCPware's programming utilities. As readers of this newgroup and TCPware users, do most of you program using DEC C or VAX C? As always, your replies are appreciated. Jim Gildea Product Marketing Manager ================================================================================ Archive-Date: Wed, 22 Apr 1998 16:16:20 -0400 From: Cameron_C_Caffee@atlanticmutual.com Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <852565EE.006F17A4.00@AtlanticMutual.com> Date: Wed, 22 Apr 1998 16:13:25 -0400 Subject: Need source of user's TCP/IP address in process context MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: Cameron C Caffee@ATLANTIC COMPANIES on 04/22/98 04:13 PM To: Info-TCPware@process.com cc: Subject: Need source of user's TCP/IP address in process context I have a requirement that I can satisfy provided I can find a way to obtain the source address of a user's TELNET connection within the user's process context. The solution needs to provide the information in a form that is useful to a program or DCL procedure (i.e. a screen display isn't good enough). Bear in mind that I'm a novice programmer so if a program is suggested, a code fragment will be much appreciated ! I've discovered some things that could be the basis of a partial solution. When one does a DCL SHOW USER/FULL for a TELNET connection, the user's node name (if resolvable) or TCP/IP address is displayed. This information is available to DCL via the lexicals F$GETJPI or F$GETDVI in item TT_ACCPORNAM. If this is the best source of the information I'm looking for, then I need a means of converting the node name to the address. Provided I'm on the right track, I suppose a small program that does the correct call to the socket library can get the info but, alas, its beyond my C coding skills. I'm open to any other approaches or pointers to shareware that does something similar. I approached the Process Software support staff and they could only suggest the obvious display commands (NETCU SHOW NODE, etc.) which doesn't satisfy my requirement. All suggestions appreciated ! Cameron +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I Cameron Caffee, Sr Systems Manager Atlantic Mutual Companines I +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I Internet : Cameron_C_Caffee@AtlanticMutual.Com I Snail Mail : I I +++++++++++++++++++++++++I I FAX : (540) 772-4116 I 1325 Electric Road, SW I I Voice : (540) 772-4071 I Roanoke, VA 24018 I +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ================================================================================ Archive-Date: Wed, 22 Apr 1998 16:23:12 -0400 Date: Wed, 22 Apr 1998 16:22 -0400 From: BRYANT@PROCESS.COM (Geoff Bryant) Reply-To: Info-TCPware@process.com Message-ID: <009C51934AE1599E.05EC@PROCESS.COM> To: Info-TCPware@process.com Subject: RE: Need source of user's TCP/IP address in process context Cameron_C_Caffee@atlanticmutual.com writes: >From: Cameron C Caffee@ATLANTIC COMPANIES on 04/22/98 04:13 PM >To: Info-TCPware@process.com >cc: >Subject: Need source of user's TCP/IP address in process context > >I have a requirement that I can satisfy provided I can find a way to obtain >the source address of a user's TELNET connection within the user's process >context. The solution needs to provide the information in a form that is >useful to a program or DCL procedure (i.e. a screen display isn't good >enough). > >Bear in mind that I'm a novice programmer so if a program is suggested, a >code fragment will be much appreciated ! > >I've discovered some things that could be the basis of a partial solution. > >When one does a DCL SHOW USER/FULL for a TELNET connection, the user's node >name (if resolvable) or TCP/IP address is displayed. This information is >available to DCL via the lexicals F$GETJPI or F$GETDVI in item >TT_ACCPORNAM. If this is the best source of the information I'm looking >for, then I need a means of converting the node name to the address. > >Provided I'm on the right track, I suppose a small program that does the >correct call to the socket library can get the info but, alas, its beyond >my C coding skills. > >I'm open to any other approaches or pointers to shareware that does >something similar. > >I approached the Process Software support staff and they could only suggest >the obvious display commands (NETCU SHOW NODE, etc.) which doesn't satisfy >my requirement. > >All suggestions appreciated ! > >Cameron > >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >I Cameron Caffee, Sr Systems Manager Atlantic Mutual Companines I >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >I Internet : Cameron_C_Caffee@AtlanticMutual.Com I Snail Mail : I >I +++++++++++++++++++++++++I >I FAX : (540) 772-4116 I 1325 Electric Road, SW I >I Voice : (540) 772-4071 I Roanoke, VA 24018 I >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > If you are looking to avoid writing code to handle this, perhaps you could go into TELNET_CONTROL.COM and change the setting of the flag for the ACCPORNAM reporting so that there isn't a reverse look up to translate it to a name. See the line: $ ! The TELNET Server now uses the host name of the client as the $ ! ACCPORNAM (Remote Port Info) string. However, older versions $ ! of TCPware for OpenVMS used the internet address,port number. If $ ! you need to restore the old action, set bit 8 (mask value of $ ! 256) in the TELNETD_FLAGS symbol (by uncommenting the following $ ! line). $ ! $ TELNETD_FLAGS == TELNETD_FLAGS .OR. 256 ! Use old style ACCPORNAM Then you can continue to use F$GETDVI as you have already. This is likely the simplest solution... ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Wed, 22 Apr 1998 16:32:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Info-TCPware@process.com From: 3in7ifi@cmich.edu (Daniel A. Gauthier) Reply-To: Info-TCPware@process.com Date: Wed, 22 Apr 1998 16:32:31 -0400 Subject: Re: Need source of user's TCP/IP address in process context >Subject: Need source of user's TCP/IP address in process context > >I have a requirement that I can satisfy provided I can find a way to obtain >the source address of a user's TELNET connection within the user's process >context. The solution needs to provide the information in a form that is >useful to a program or DCL procedure (i.e. a screen display isn't good >enough). wELL, THE EASIEST (and I've found best) solution is to disable DNS reverse= of the IP address. This is done with a flag (TELNETFLAGS=3D257) or= something similar in the TCPWARE config files. You'll find it in the= archives of this area a few weeks back (about a month or less) as a= solution to a problem involving delays at login time. This same solution= also makes "SHOW USERS [userid] /FULL" display the connection point as= xxx.xxx.xxx.xxx:port which is the ONLY way I've found to get that= information. If the name lookup is enabled, it does not show= name.domain.zone.edu:port--it simply doesn't display the port number, so I= made this change for several reasons: I can see the port number of users= (maybe not commonly useful, but more info is always better than less),= there is no delay when the DNS is down, and I can see when DHCP has given= local users new addresses. If you make this change you can always do a= SHOW USER/FULL to a file and open it and read it, but I suspect that some= of the F$GET lexicals will return the information you're looking for. Regards, Dan Daniel A. Gauthier Telemanagement Analyst Central Michigan University Technology Operations Dept. Voice: (517) 774-1355 Fax: (517) 774-3537 Email: 3in7ifi@cmich.edu My employer might hate everything I say here, so don't blame them. ================================================================================ Archive-Date: Wed, 22 Apr 1998 17:23:04 -0400 From: Lyle W West Reply-To: Info-TCPware@process.com Subject: Re: TCPware Programming Date: Wed, 22 Apr 1998 16:18:05 -0500 Message-ID: <353E183D.2FACD95A@ncs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM James Gildea wrote: > > The TCPware development team is in the process of determining where we > can most effectively direct our resources. One area of discussion that > has arisen is TCPware's programming utilities. As readers of this > newgroup and TCPware users, do most of you program using DEC C or VAX > C? As always, your replies are appreciated. > > Jim Gildea > Product Marketing Manager -- If someone is/has not migrated VaxC code to DecC v5.x, it seems they are in for serious problems. DecC 5.6 on VMS 7.1 seems very solid. Just my opinion. Lyle W.West lwest@nospam.digcomp.com ================================================================================ Archive-Date: Wed, 22 Apr 1998 19:01:11 -0400 From: mrx@remove-this-unless-you-send-junk.tiac.net (Mr. X) Subject: Re: Need source of user's TCP/IP address in process context Date: Wed, 22 Apr 1998 22:54:08 GMT Message-ID: <353e72d7.284885046@news.tiac.net> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM I have written my own "show users" program, including what I believe is some of the information you're looking for. RE: users "address" or "name" - I suspect you're looking for TCP/IP address, or DNS name. the code stub I have will extract the DNS name if it exists, or the TCP/IP address if the DNS name does not exist. However, The code is on a VMS machine somewhere else (still complaining about no home VMS box!) so email me at the following address (minus the spam filter part!!!) and I'll get it for you as soon as possible... heres the email: douniasm@remove-this-junk.seg.ndhm.gtegsc.com (remove-that-junk!!!) - leave the rest... Actually, I have a printout here, but it's longer than 132 columns and didn't wrap.... c ya! Minos Dounias (and yes - I WAS with the Process Support staff - and proud of it!!!) Cameron_C_Caffee@atlanticmutual.com wrote: > > > >From: Cameron C Caffee@ATLANTIC COMPANIES on 04/22/98 04:13 PM > > >To: Info-TCPware@process.com >cc: >Subject: Need source of user's TCP/IP address in process context > >I have a requirement that I can satisfy provided I can find a way to obtain >the source address of a user's TELNET connection within the user's process >context. The solution needs to provide the information in a form that is >useful to a program or DCL procedure (i.e. a screen display isn't good >enough). > >Bear in mind that I'm a novice programmer so if a program is suggested, a >code fragment will be much appreciated ! > >I've discovered some things that could be the basis of a partial solution. > >When one does a DCL SHOW USER/FULL for a TELNET connection, the user's node >name (if resolvable) or TCP/IP address is displayed. This information is >available to DCL via the lexicals F$GETJPI or F$GETDVI in item >TT_ACCPORNAM. If this is the best source of the information I'm looking >for, then I need a means of converting the node name to the address. > >Provided I'm on the right track, I suppose a small program that does the >correct call to the socket library can get the info but, alas, its beyond >my C coding skills. > >I'm open to any other approaches or pointers to shareware that does >something similar. > >I approached the Process Software support staff and they could only suggest >the obvious display commands (NETCU SHOW NODE, etc.) which doesn't satisfy >my requirement. > >All suggestions appreciated ! > >Cameron > >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >I Cameron Caffee, Sr Systems Manager Atlantic Mutual Companines I >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >I Internet : Cameron_C_Caffee@AtlanticMutual.Com I Snail Mail : I >I +++++++++++++++++++++++++I >I FAX : (540) 772-4116 I 1325 Electric Road, SW I >I Voice : (540) 772-4071 I Roanoke, VA 24018 I >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > ================================================================================ Archive-Date: Fri, 24 Apr 1998 17:42:27 -0400 From: eplan@kapsch.co.at (Peter LANGSTOEGER) Subject: Re: TCPware Programming Date: 24 Apr 98 21:28:10 GMT Message-ID: <354103ea.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article <353C89CC.80E@process.com>, James Gildea writes: >The TCPware development team is in the process of determining where we >can most effectively direct our resources. One area of discussion that >has arisen is TCPware's programming utilities. As readers of this >newgroup and TCPware users, do most of you program using DEC C or VAX >C? As always, your replies are appreciated. DEC C and UCX compatibility my 0.02 ------------------------------------------------------------------------ Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2382 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" ================================================================================ Archive-Date: Wed, 29 Apr 1998 23:23:53 -0400 Subject: Re: IP Message-ID: <1998Apr27.200531@process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 27 Apr 98 20:05:31 -0400 To: Info-TCPware@PROCESS.COM In article <35411008.4C3A9907@lamere.net>, John E Kimball writes: > Hey how do i display My Current IP Address on My webpage? > Which address do you want? The server's or the client's? Which server are you using? The client's is availabe in the CGI parameter "REMOTE_ADDR" (for Purveyor VMS, this is the WWW_REMOTE_ADDR symbol). The host name, if found, is in "REMOTE_HOST"). The server's NAME is available in the CGI parameter "SERVER_NAME" (for Purveyor VMS, this is WWW_SERVER_NAME symbol). To get the address, you'd have to look up the host name to get the address (gethostbyaddr). This can be done with the following Purveyor VMS page (call it something like WHOAMI.COM and place it in a directory that allows execution): $ say = "write SYS$OUTPUT" $ say "Content-Type: text/html" $ say "" $ say "Who am I?" $ say "" $ say "The client's address is ''WWW_REMOTE_ADDR' (''WWW_REMOTE_HOST')." $ say "

" $ netcu = "$tcpware:netcu" $ netcu validate/internet 'WWW_SERVER_NAME' $ say "The server's address is ''IA_S' (''WWW_SERVER_NAME')." $ say "" Note: The the NETCU VALIDATE/INTERNET command is TCPware specific and is *NOT* documented. Its function and existence could easily change in the future. For information on other CGI variables available with Purveyor VMS, please check-out the CGIINFO.COM provided with the product. - Bernie Volz Process Software ================================================================================ Archive-Date: Thu, 30 Apr 1998 19:14:44 -0400 Date: Fri, 1 May 1998 00:09:06 +0100 From: Steve Wakelin Reply-To: Info-TCPware@process.com Subject: DNS Question Technical Consultant Heron House 01-May-1998 00:09amWAKELIN.S To: info-tcpware Message-ID: <98May1.001830bst.17922@gate.bgep.co.uk> MIME-Version: 1.0 Content-Type: text/plain I have been given the task of combining serveral different DNS environments together within the company allowing lookups to be achived in all domains. Domains. bgep.co.uk bggrc.co.uk bgtransco.co.uk I was initially thinking of using forwarding records however testing has shown, because the other primaries in question have direct connection to the Internet, Internet lookups are then completed by the remote domain. Any pointers to a method of achiving this would be greatly appreciated. /Steve Wakelin BG plc