Archive-Date: Mon, 3 May 1999 15:48:31 -0400 From: "Carl G. Cioffi" Reply-To: Info-TCPware@process.com To: "'Info-TCPware" Subject: PASCAL Interface Date: Mon, 3 May 1999 15:47:21 -0400 Message-ID: <000101be959d$c2363890$13faff0a@carl.splusnet> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Has anyone out there used PASCAL and QIO calls to setup a TCP/IP connection on OpenVMS. More specifically. In the TCPDRIVER_SERVER.C program there is the following line: struct dsc$descriptor ecb_dsc; What is dsc$descriptor? carl@canvaslink.com ================================================================================ Archive-Date: Mon, 3 May 1999 16:43:48 -0400 Sender: DLUTES@textron.com Message-ID: <372DC3D1.6771348@cessna.textron.com> Date: Mon, 03 May 1999 15:42:09 -0500 From: Dale Lutes Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: PASCAL Interface References: <000101be959d$c2363890$13faff0a@carl.splusnet> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Carl G. Cioffi wrote: > Has anyone out there used PASCAL and QIO calls to setup a TCP/IP connection > on OpenVMS. I haven't done that. > In the TCPDRIVER_SERVER.C program there is the following line: > > struct dsc$descriptor ecb_dsc; > > What is dsc$descriptor? But I can answer this. dsc$descriptor is a C structure that looks like a standard VMS descriptor. There are various descriptor types, For fixed or varying length strings, for arrays, etc. The DEC language compilers usually pass string arguments by descriptor. In C, however, strings are null-terminated and passed by reference. What this means to a programmer is that in order to use the system services (like QIO$) or run-time library routines from C, you must add some extra code to construct the string descriptor. As an example, consider LIB$DATE_TIME which returns a string in its only argument. Here is a complete Pascal program: [INHERIT('SYS$LIBRARY:PASCAL$LIB_ROUTINES')] PROGRAM test (OUTPUT); VAR buffer : PACKED ARRAY [1..23] OF CHAR; BEGIN LIB$DATE_TIME (buffer); WRITELN (buffer) END. Here's the equivalent in C: #include #include #include #define DATE_TIME_LEN 23 main () { struct dsc$descriptor_d buffer_dsc; char buffer[DATE_TIME_LEN+1]; /* fill in the string descriptor */ buffer_dsc.dsc$b_dtype = DSC$K_DTYPE_T; buffer_dsc.dsc$b_class = DSC$K_CLASS_S; buffer_dsc.dsc$a_pointer = &buffer[0]; buffer_dsc.dsc$w_length = DATE_TIME_LEN; lib$date_time (&buffer_dsc); buffer[DATE_TIME_LEN] = '\0'; printf ("%s\n", buffer); } ================================================================================ Archive-Date: Mon, 10 May 1999 11:02:40 -0400 Date: Mon, 10 May 1999 10:59:13 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: NETCP_V533P030 To: TCPware-Announce@PROCESS.COM Message-ID: <01JB134UXMOY0028RJ@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: NETCP_V533P030 Description: Fix SS$_IVLOCKID error with secondary address Release date: 10-MAY-1999 Versions: 5.3-3, 5.3-2 ftp://ftp.process.com/support/53_3/netcp_v533p030.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. ----------------------------------------------------------- NETCP Patch kit revision 3.0 for TCPware version 5.3-3 23-APR-1998 Copyright (c) 1998, 1999 by Process Software Corporation This VMSinstallable saveset provides new versions of NETCP.EXE for TCPware for OpenVMS. This patch is applicable to TCPware version 5.3-2 and 5.3-3 and all supported versions of OpenVMS. The following change[s] has been made: - A problem with handling cluster alias addresses has been corrected. This problem could cause a node to not fail over to the cluster address and a NETCU REMOVE SECONDARY would return an IVLOCKID error status. This kit also includes the following fixes/enhancements from the previous kits: - An important security problem was discovered where non-privileged users could gain privileged access. - NETCP was starting one more server process than the limit on the service. This problem can affect DHCP in particular since many errors may result if there is more than one DHCP server. - TCPware 5.3's enhancement to display ACCPORNAM with the remote port number fails in these circumstances: a) If the host name string is exactly 20 characters long, then a TELNET login from that host gets SS$_IVBUFLEN and the user can not log in (the connection is closed). b) If the host name string is greater than 20 characters long, then the first 20 characters are dropped when setting the ACCPORNAM (in Remote Port Info). This problem can be overcome by: a) Installing this patch. b) Configuring TCPware to report the internet address (old style ACCPORNAM string) instead of the reporting the host name. (See TELNET_CONTROL.COM for adding mask value 256 to TELNETD_FLAGS.) The old version of TCPWARE:NETCP.EXE will be renamed to TCPWARE:NETCP.EXE_OLD Once installed, you may undo this patch by renaming the file back to TCPWARE:NETCP.EXE NOTE: You do not need to reboot but you must start or restart TCPware to enable this patch. [End of ECO announcement] ================================================================================ Archive-Date: Tue, 11 May 1999 07:46:04 -0400 From: "Andy Williams" Reply-To: Info-TCPware@process.com Subject: Re: Patches for TCPware V5.3-3 Date: Tue, 11 May 1999 12:27:26 +0100 Message-ID: <7h942e$5sm$1@gatekeeper.liffe.com> To: Info-TCPware@PROCESS.COM Well, that kit announcement for NETCP answered my question. I've had a quick play with the ECO search facility & there seems to be a couple of anomalies when the results are compared against the V5.5-3 patch directory listing. In particular, the ECO search doesn't seem to find DNS_MAIN_V533P012 when specifying V5.3-3 as the version to search for. Instead it seems to always display the (empty) DNS_MAIN_V533P011 zipfile. Finally, it would appear from the accompanying release notes that DRIVERS_V533P020 supersedes DRIVERS_V533P010, yet the '010' version hasn't been moved to the 'obsolete' directory. Is there a particular reason for this or am I safe just installing the 020 variant ? Cheers, -Andy Andy Williams wrote in message news:7h6gh4$mde$1@gatekeeper.liffe.com... > Just a quick sanity check really... > > I've just installed TCPware V5.3-3 onto my VAXstation running OpenVMS V6.2. > I've also downloaded all the patches from the V5.3-3 patch site at > > http://vms.process.com/support/53_3/ > > Is that the complete list of patches or are there some applicable ones on > the V5.3-2 page that could/should be applied to V5.5-3 as well ? > > Thanks for your help, > > Andy Williams > OpenVMS System Specialist > Andy.Williams@LIFFE.com > +44 171 379 2581 > > > > ================================================================================ Archive-Date: Tue, 11 May 1999 08:31:13 -0400 Date: Tue, 11 May 1999 07:30:22 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <009D7F08.97D5A7C5.5@ALPHA.WKU.EDU> Subject: Re: Patches for TCPware V5.3-3 "Andy Williams" writes: > >Well, that kit announcement for NETCP answered my question. I've had a quick >play with the ECO search facility & there seems to be a couple of anomalies >when the results are compared against the V5.5-3 patch directory listing. > >In particular, the ECO search doesn't seem to find DNS_MAIN_V533P012 when >specifying V5.3-3 as the version to search for. Instead it seems to always >display the (empty) DNS_MAIN_V533P011 zipfile. > Thanks. I'll check this out later today. The P012 kit may not be in the database (ooops!). >Finally, it would appear from the accompanying release notes that >DRIVERS_V533P020 supersedes DRIVERS_V533P010, yet the '010' version hasn't >been moved to the 'obsolete' directory. Is there a particular reason for >this or am I safe just installing the 020 variant ? > You're safe installing the 020 variant. We'll create the [.OBSOLETE] directory and populate it later this week. Thanks, Andy! Hunter ------ Hunter Goatley, Process Software, http://www.process.com http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Wed, 12 May 1999 16:17:12 -0400 Message-ID: <3739DD74.3C45CC11@SMTP.DeltaTel.RU> Date: Wed, 12 May 1999 23:58:44 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: POP3 server with SSL Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi All! I think that VMS world wondering about it, is there any plan to implement it in the TCPWare ? -- Regards. +.....................pure personal opinion..........................+ HTTP://WWW.RadiusVMS.COM - Frying only on VMS ================================================================================ Archive-Date: Wed, 12 May 1999 16:56:39 -0400 Message-ID: <5D22E2A981E53F70@mail.cooperhealth.edu> In-Reply-To: <3739DD74%.3C45CC11@mail.cooperhealth.edu> Date: Wed, 12 May 1999 16:47:00 -0500 From: "Eric Reich-it-idx-consultant" Sender: "Eric Reich-it-idx-consultant" Reply-To: Info-TCPware@process.com To: info-tcpware@process.com Subject: re: POP3 server with SSL MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit On Wednesday, May 12, 1999 2:58 PM, Info-TCPware@process.com wrote: > >Date: 12-May-99 14:58:44 -0500 >From: Info-TCPware@process.com >To: Info-TCPware@PROCESS.COM >Subject: POP3 server with SSL > >Hi All! > I think that VMS world wondering about it, is there any plan to >implement it in the TCPWare ? > >-- >Regards. >+.....................pure personal opinion..........................+ > HTTP://WWW.RadiusVMS.COM - Frying only on VMS ============================== Does OpenVMS v7.1-1H2 have POP3 w/ SSL??? ************************************************* ERIC K. REICH Technical Consultant NovaSoft Information Technology, Inc. NovaSoft Plaza 4014 Quakerbridge Road Lawrenceville, NJ 08648 NovaSoft Email: ereich@novasoftinfo.com Client Site Email: reich-eric@cooperhealth.edu Client Site Phone: 609-968-7129 Client Site Pager: 609-427-8719 Personal Email: Eric@Reich.net ************************************************* ================================================================================ Archive-Date: Thu, 13 May 1999 09:50:08 -0400 Sender: bryant@process.com Date: Thu, 13 May 1999 09:49:14 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009D80AE.52E1A9CF.13@process.com> Subject: Re: Patches for TCPware V5.3-3 Andy, Thanks for your patience and careful looking at the patches. The actual ftp directory is the ultimate place to look. We have been using that for many years and all patches are released there. The ECO Database web page lists information about patches in those directories. It has been recently created and indeed does not have all patches installed in the database. I hope that going forward we will have all new patches listed in the database. It will take awhile to get the old ones in the database. So, always refer to the ftp directory as the ultimate authoratitive place. As far as the superseding of patches go, we have a naming scheme that should help you: componenet_VxxxPyyy component - The TCPware component to patch xxx - The highest TCPware version the patch applies to yyy - Version of the patch kit Note that we do cumulative patch kits, so version 2.0 (020) should supersede patch kit 1.0 (010) and include fixes from patch version 1.0. Our source control system should take care of that automaticly for us. Hope that helps. "Andy Williams" writes: > >Well, that kit announcement for NETCP answered my question. I've had a quick >play with the ECO search facility & there seems to be a couple of anomalies >when the results are compared against the V5.5-3 patch directory listing. > >In particular, the ECO search doesn't seem to find DNS_MAIN_V533P012 when >specifying V5.3-3 as the version to search for. Instead it seems to always >display the (empty) DNS_MAIN_V533P011 zipfile. > >Finally, it would appear from the accompanying release notes that >DRIVERS_V533P020 supersedes DRIVERS_V533P010, yet the '010' version hasn't >been moved to the 'obsolete' directory. Is there a particular reason for >this or am I safe just installing the 020 variant ? > >Cheers, > >-Andy > > >Andy Williams wrote in message >news:7h6gh4$mde$1@gatekeeper.liffe.com... >> Just a quick sanity check really... >> >> I've just installed TCPware V5.3-3 onto my VAXstation running OpenVMS >V6.2. >> I've also downloaded all the patches from the V5.3-3 patch site at >> >> http://vms.process.com/support/53_3/ >> >> Is that the complete list of patches or are there some applicable ones on >> the V5.3-2 page that could/should be applied to V5.5-3 as well ? >> >> Thanks for your help, >> >> Andy Williams >> OpenVMS System Specialist >> Andy.Williams@LIFFE.com >> +44 171 379 2581 ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Fri, 14 May 1999 10:45:55 -0400 Date: Fri, 14 May 1999 10:41:49 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: FTPD_PIP_V533P020 To: TCPware-Announce@PROCESS.COM Message-ID: <01JB6NOOYJPE002AMS@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: FTPD_PIP_V533P020 Description: Fix logging of intrusion records Release date: 14-MAY-1999 Versions: 5.3-3, 5.3-2 ftp://ftp.process.com/support/53_3/ftpd_pip_v533p020.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 1.0) for TCPware version 5.3-2 6-May-1999 Copyright (c) 1999, by Process Software Corporation This VMSinstallable saveset provides a new version of FTPD_PIP.EXE for TCPware for OpenVMS. TCPWare V5.3-2 and later VMS/VAX V5.5-2 and later VMS/ALPHA V6.1 and later The following change[s] has been made: Intrusion records on VAX will now be logged with a source of FTP::ip_address instead of SYSTEM (DE 524) [End of ECO announcement] ================================================================================ Archive-Date: Wed, 19 May 1999 07:24:43 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: PPPD Examples wanted Date: 19 May 1999 13:18:40 +0100 Message-ID: <37429e10.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM I would like to connect my VAXstation 4000 / 90 with PPP (so far only possible with TCPware as OpenVMS VAX and so UCX does not support PPP) to 1) a NT [R]RAS Server (if its possible) 2) a LUCENT Portmaster 3) a DECserver 900 (DNAS) for no particular order I think an unnumbered PPP Interface would be the solution. But as a DHCP Client is still missing (PSC are you listening ?) I need a fixed IP Address, which may give problems with the Access-Server, but this problems will be addressed (if needed) after that client problem... Does anyone already succeeded ? Does anyone have (Outgoing Dialup Lines) example(s) to shorten my learning period ? I already started reading the TCPware V5.3 Management Guide (chapter 4). I so far found two errors (Figure 4-2 ".NES." instead of ".EQS." and on pg 4-13 at -IP "TCPWARE:PPPDOPTIONS.DAT" instead of "TCPWARE:PPPOPTIONS.DAT") but did not come very far so far (and CKERMIT script are also news to me)... Many TIA ------------------------------------------------------------------------ Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Wed, 19 May 1999 09:32:53 -0400 Subject: Re: PPPD Examples wanted Message-ID: <1999May19.085947@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 19 May 99 08:59:47 -0400 To: Info-TCPware@PROCESS.COM In article <37429e10.0@nevada.kapsch.co.at>, eplan@kapsch.net (Peter LANGSTOEGER) writes: > I would like to connect my VAXstation 4000 / 90 with PPP (so far only > possible with TCPware as OpenVMS VAX and so UCX does not support PPP) to > > 1) a NT [R]RAS Server (if its possible) > 2) a LUCENT Portmaster > 3) a DECserver 900 (DNAS) > for no particular order > > I think an unnumbered PPP Interface would be the solution. But as > a DHCP Client is still missing (PSC are you listening ?) I need a > fixed IP Address, which may give problems with the Access-Server, but > this problems will be addressed (if needed) after that client problem... > > Does anyone already succeeded ? Does anyone have (Outgoing Dialup Lines) > example(s) to shorten my learning period ? > > I already started reading the TCPware V5.3 Management Guide (chapter 4). > I so far found two errors (Figure 4-2 ".NES." instead of ".EQS." and on pg > 4-13 at -IP "TCPWARE:PPPDOPTIONS.DAT" instead of "TCPWARE:PPPOPTIONS.DAT") > but did not come very far so far (and CKERMIT script are also news to me)... > > Many TIA > > ------------------------------------------------------------------------ > Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 You don't need a DHCP Client ... PPP already handles address assignment in the protocol and you get the address for your end of the PPP link from the remote side (the RAS server there will either use a preassigned pool or might use DHCP to obtain the address). But, the TCPware end does not need a DHCP Client to do this; PPP handles it. Regarding the documentation errors, thanks. They've been forwarded to our Tech Pubs people and will be corrected in the next version of the Management Guide. - Bernie Volz Process Software ================================================================================ Archive-Date: Wed, 19 May 1999 16:53:03 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: PPPD Examples wanted Date: 19 May 1999 22:50:52 +0100 Message-ID: <3743242c.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article <1999May19.085947@alcor.process.com>, volz@process.com (Bernie Volz) writes: >In article <37429e10.0@nevada.kapsch.co.at>, eplan@kapsch.net (Peter LANGSTOEGER) writes: >> I would like to connect my VAXstation 4000 / 90 with PPP (so far only >> possible with TCPware as OpenVMS VAX and so UCX does not support PPP) to >> >> 1) a NT [R]RAS Server (if its possible) >> 2) a LUCENT Portmaster >> 3) a DECserver 900 (DNAS) >> for no particular order >>[snip] >You don't need a DHCP Client ... PPP already handles address assignment >in the protocol and you get the address for your end of the PPP link >from the remote side (the RAS server there will either use a preassigned >pool or might use DHCP to obtain the address). But, the TCPware end >does not need a DHCP Client to do this; PPP handles it. Does PPP handle all the other config info that's normally needed and provided by a DHCP server to a DHCP client ? eg. Default Router, Nameservers, Timeservers, ... I don't think so. But maybe I'm wrong. I think, there should be a DHCP client in TCPware. Maybe not for my particular case, but in general. May I suggest an PIR ? There are still VMS clients out there (maybe DEC does not know it)... btw: I would like to use a fixed IP adress on the (TCPware client) because I want my machine to be found in BIND/DNS. But first I want only _a_ connection and later try to get a _better_ connection. (eg. CKERMIT dialup script, CHAP Authentication, fixed IP Address, ...) >Regarding the documentation errors, thanks. They've been forwarded to >our Tech Pubs people and will be corrected in the next version of the >Management Guide. Thanks for responding, but no examples ? -Peter PS: What has happened with V5.4 ? Shouldn't it be already out now... ------------------------------------------------------------------------ Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Mon, 24 May 1999 14:10:07 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86014136B1@lespaul.process.com> From: Lauren Maschio Reply-To: Info-TCPware@process.com To: "'info-tcpware@process.com'" Subject: TCPware 5.4 Beta Date: Mon, 24 May 1999 14:08:38 -0400 MIME-Version: 1.0 Content-Type: text/plain Process Software is looking for beta sites to test TCPware 5.4. Beta is scheduled to begin in early July and includes the following new features: - DHCP redundant safe-failover - This allows the ability to configure primary and secondary DHCP servers to ensure DHCP reliability. - Dynamic DNS (DDNS) - When the DHCP server activates, renews, or terminates address leases to clients, the DNS server is automatically updated of these changes as specified in RFC 2136. - Support for the latest releases - BIND 8.12 and OpenVMS 7.2 file names. - New SMTP server with anti-spamming capabilities - New FTP server which supports UNIX emulation for directory listings and additional logical names for more control of the FTP server. All beta participants will receive a Process Software sweatshirt and will be entered into a drawing to receive a free Palm Pilot. If you are interested in participating in this beta program, send an e-mail to maschio@process.com or call (800) 722-7770 ext. 525 or (508)626-7525. -------------------------------------------- Lauren Maschio Senior Product Manager Process Software 959 Concord Street Framingham, MA 01701-4682 (508) 626-7525 -------------------------------------------- ================================================================================ Archive-Date: Mon, 24 May 1999 16:15:48 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: UCX or Multinet??? pro's and cons... Date: 24 May 1999 22:12:53 +0100 Message-ID: <3749b2c5.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article , "Mark Levy" writes: >Erm, I'd say that Multinet (and TCPWare) have increased that "step or two" >to more like several large jumps. UCX V5 may improve the situation, but >Multinet & TCPWare are proven products. I second that, with the exception that I believe that OpenVMS system management via SNMP will be handled better by UCX/DEC. Means PSC should consider supporting the OpenVMS eSNMP extensions of UCX instead of providing their own and then ever lagging one step behind... -Peter PS: added vmsnet.networks.tcp-ip.tcpware to fup ------------------------------------------------------------------------ Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Tue, 25 May 1999 08:46:35 -0400 From: Cameron_C_Caffee@atlanticmutual.com Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <8525677C.0045BA06.00@AtlanticMutual.com> Date: Tue, 25 May 1999 08:43:43 -0400 Subject: DSNlink 2.2 over TCPware - a small success story MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Cameron C Caffee@ATLANTIC COMPANIES on 05/25/99 08:43 AM To: Info-TCPware@process.com cc: Subject: DSNlink 2.2 over TCPware - a small success story Like others I have seen posting on this list of late, I have an interest in utilizing DSNlink's ability to communicate with the Compaq/DEC support center via the Internet. My interest was initially fueled by the DSNlink 2.2 software's design specification which discontinued support for the DECserver 200 leaving me with the difficult choice of converting to Internet or purchasing a DECserver 700 for no other reason than to support this service offering. I began with the DSNlink 2.2 kit and my current release of TCPware (5.3-2) on OpenVMS 7.1-2 Alpha. In the end, the modifications to utilize TCPware were minor but difficult to define since neither Compaq not Process Software had an established script for making the adjustment. These problems were compounded by a VMSinstal error in the kit and a bug in the DSNlink configuration utility. Here is a summary of the customizations required to implement DSNlink 2.2 with TCPware : (1) product start-up file (SYS$STARTUP:DSN$STARTUP.COM) Modified the UCX service definition commands to utilize TCPware NETCU commands as follows : (VMS DIFF) --------------------------------------------------------------------------- -------------------------------------------------------- File SYS$COMMON:[SYS$STARTUP]DSN$STARTUP.COM;3 | File SYS$COMMON:[SYS$STARTUP]DSN$STARTUP.COM;1 -------------------------------- 471 -------------------------------------- ----------------------- 471 ---------------------------- $! ucx enable service dsn_nsd | $ ucx enable service dsn_nsd $! ucx enable service dsn_mail | $ ucx enable service dsn_mail $! ucx enable service dsn_its | $ ucx enable service dsn_its $! ucx enable service dsn_k2 | $ ucx enable service dsn_k2 $! ucx enable service dsn_login | $ ucx enable service dsn_login $! ucx enable service dsn_netex | $ ucx enable service dsn_netex $! ucx enable service dsn_sra | $ ucx enable service dsn_sra $! ucx enable service dsn_file | $ ucx enable service dsn_file -------------------------------- 1201 ------------------------------------- ----------------------- 1201 --------------------------- $! call Remove_UCX_Service 'name' | $ call Remove_UCX_Service 'name' $ call Remove_UCX_Service 'port' | $ ! Setup the service $ ! Setup the service | $ ucx set service 'name' - $! ucx set service 'name' - | /port = 'port' - $! /port = 'port' - | /file = 'file' - $! /file = 'file' - | /user = 'user' - $! /user = 'user' - | /proc = "''proc'" - $! /proc = "''proc'" - | /flags = 'flags' - $! /flags = 'flags' - | /limit = 32767 - $! /limit = 32767 - | /log = (all,file="''logfile'") $! /log = (all,file="''logfile'") | $ ! Enable the service $ ! Enable the service | $ ucx enable service 'name' $! ucx enable service 'name' | $ ! done $ ! done | $ netcu := $tcpware:netcu | $ netcu add service 'port' bg_tcp - | /input='file' - | /username='user' - | /routine=create_server_process | $ netcu show service/full 'port' bg_tcp | -------------------------------- 2202 ------------------------------------- ----------------------- 2195 --------------------------- $! ucx disable service 'p1' | $ ucx disable service 'p1' $! ucx set noservice 'p1'/noconfirm | $ ucx set noservice 'p1'/noconfirm $ netcu := $tcpware:netcu.exe | $ netcu remove service/abort 'p1' bg_tcp | -------------------------------- 2267 ------------------------------------- ----------------------- 2258 --------------------------- $! | $! Revision History | $! | $! 05/11/99 CCC Removed UCX commands via comment (using TCPware | $! | --------------------------------------------------------------------------- -------------------------------------------------------- Number of difference sections found: 4 Number of difference records found: 37 DIFFERENCES /IGNORE=()/OUTPUT=SOFT01:[SYSCCC1]DSN.TXT;1/PARALLEL- SYS$COMMON:[SYS$STARTUP]DSN$STARTUP.COM;3- SYS$COMMON:[SYS$STARTUP]DSN$STARTUP.COM;1 (2) TCPware services file (TCPWARE:SERVICES.) Added the following lines : # # DSNlink Services # dsn_nsd 2370/tcp # DSNlink dsn_mail 2372/tcp # DSNlink dsn_its 2373/tcp # DSNlink dsn_login 2374/tcp # DSNlink dsn_netex 2375/tcp # DSNlink dsn_sra 2376/tcp # DSNlink dsn_k2 2377/tcp # DSNlink dsn_file 2379/tcp # DSNlink The DSNlink configuration bug results in an error like the following in the node's configuration file : $ diff DSN$ROOT:[DAT.BOZO]DSN_CONFIG.DAT;2 ************ File DSN$ROOT:[DAT.BOZO]DSN_CONFIG.DAT;2 84 Transport.LocalName.TCP: bozo.atlanticmutual.com 85 SRA.OpSys: "VMS V7.1" ****** File DSN$ROOT:[DAT.BOZO]DSN_CONFIG.DAT;1 84 Transport.LocalName.TCP: bozo. 85 SRA.OpSys: "VMS V7.1" ************ Number of difference sections found: 1 Number of difference records found: 1 DIFFERENCES /IGNORE=()/MERGED=1- DSN$ROOT:[DAT.BOZO]DSN_CONFIG.DAT;2- DSN$ROOT:[DAT.BOZO]DSN_CONFIG.DAT;1 The VMSinstal error is related to the use of a rooted logical name (e.g. SYS$COMMON) for the location of DSNlink. In my case I was able to use SYS$SYSDEVICE:[SYS0.SYSCOMMON] successfully. A few additional modifications, which Compaq/DEC was able to assist with, enabled me to further configure for my firewall. I understand there is a DSNlink 2.2C kit which may help with some of the product problems. At this writing, there is a problem with implementing a DSNlink "A" node (formerly called the DSNlink communications node) on a mixed architecture cluster. The product assumes a shared system disk which makes configuring the other nodes very difficult. This probably applies to heterogeneous clusters as well. There is also a problem configuring a mixture of "A" and "B" type nodes in any type of cluster. The product assumes that all nodes in a cluster will be of one type. This makes configuring a single node for communication (as I need for firewall reasons) and others as "B" nodes impossible. Compaq support is aware of these issues and tells me they are being worked by their engineering group for a future release. Hope this helps other folks with the same problem. 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 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++