Archive-Date: XXX, 6 May 1993 22:50:07 -0500 From: volz@process.com Subject: Re: Name Server Problem (was ) Message-ID: <1993May6.225007.73@process.com> Date: 6 May 93 22:50:07 -0500 References: <1993May5.154551.569@condor.navsses.navy.mil> In article <1993May5.154551.569@condor.navsses.navy.mil>, system@condor.navsses.navy.mil (Mike Jacobi; NAVSSES 012C; VAX SYSTEM MANAGER) writes: > > Today I came in to find that the name resolver on one of my machines was > not answering queries. I was able to restart it by performing a "@SHUTNET DNS" > followed by a "@STARTNET DNS". This is a VAX 6000-440, running OpenVMS VAX > V5.5-2, TCPware for OpenVMS Vax V 3.1-3. This machine is configured as a > primary nameserver. Has anybody seen this happening before? > > -- > Mike Jacobi > NAVSSES VAXCluster system manager > System@Eagle.Navsses.Navy.Mil > System@Condor.Navsses.Navy.Mil > > Disclaimer - I speak for myself. No-one else. ================================================================================ Archive-Date: XXX, 7 May 1993 09:53:23 -0500 From: volz@process.com Subject: Re: Name Server Problem (was ) Message-ID: <1993May7.095324.74@process.com> Date: 7 May 93 09:53:23 -0500 References: <1993May5.154551.569@condor.navsses.navy.mil> (This is a reposting ... for some reason the first post didn't include my response.) In article <1993May5.154551.569@condor.navsses.navy.mil>, system@condor.navsses.navy.mil (Mike Jacobi; NAVSSES 012C; VAX SYSTEM MANAGER) writes: > > Today I came in to find that the name resolver on one of my machines was > not answering queries. I was able to restart it by performing a "@SHUTNET DNS" > followed by a "@STARTNET DNS". This is a VAX 6000-440, running OpenVMS VAX > V5.5-2, TCPware for OpenVMS Vax V 3.1-3. This machine is configured as a > primary nameserver. Has anybody seen this happening before? > > -- > Mike Jacobi > NAVSSES VAXCluster system manager > System@Eagle.Navsses.Navy.Mil > System@Condor.Navsses.Navy.Mil > > Disclaimer - I speak for myself. No-one else. Mike, Do you still have the TCPWARE:NAMESERVER.LOG file from that "hung" name server. Also, is it a primary, secondary, forwarding, caching name server? Did you notice anything odd about the state of the process or was there anything else unusual? Please email that to me (volz@process.com) or send it to support@process.com. I'm not aware of any outstanding problems with the name server since Version 3.1-3. - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: Mon, 10 May 1993 21:11:27 GMT Subject: VAX/VMS -- Zmodem? Message-ID: <1993May10.171127.1@ulkyvx.louisville.edu> From: jfharr01@ulkyvx.louisville.edu Date: Mon, 10 May 1993 21:11:27 GMT Sender: news@netnews.louisville.edu (Netnews) I hope this is the proper place to ask this question: Is there a way, from my account on a university's VAX/VMS to transfer files from the VAX to my PC using Zmodem? Currently, Kermit is the only protocol available and it is very slow. Could I execute a program from my account that would enable Zmodem file transfers? Please reply E-mail. Thank you, ******************************************************************************* _/_/_/_/_/_/_/_/_/ _/ John F. Harris -- Computer Consultant _/ _/ _/ _/ . Internet: jfharr01@ulkyvx.louisville.edu _/ _/_/_/ _/_/_/_/ .. .. Bitnet: jfharr01@ulkyvx.bitnet _/ _/ _/ _/ . ..... Cogito ergo sum Rene Descartes _/_/_/ _/ _/ _/ . ........ Esse est percipi George Berkeley ..................................... Ignoceeeees me! Steve Martin Zoology Major ******************************************************************************* ================================================================================ Archive-Date: XXX, 10 May 1993 19:01 MST Subject: RE: Misleading Advertising Message-ID: <10MAY199319015944@spades.aces.com> From: gavron@spades.aces.com (Ehud Gavron) Date: 10 May 1993 19:01 MST Reply-To: gavron@ACES.COM In article Heff Carat, writes: .. #sales droids. Speaking of which, their advertisements in Digital Review #quote some wierdos saying tat TCPware is the choice of everybody. Does #anybody know which magazine they are supposedly reprinting??? I've never seen the original magazine they claim to quote, and NOTHING in the ad says what it is. Looks like another case of East Coast Marketing Slime*. ... #looks like bullshit to me. Big surprise. NOT! Ehud -- Ehud Gavron (EG76) gavron@aces.com *East Coast Marking Slime is a direct reference to Process Software Corp's methods of hawking their product. It is not meant as a reflection on other business on the East Coast of the US. ================================================================================ Archive-Date: XXX, 12 May 1993 12:05:53 PDT Subject: How do I preserve QIO interface? Message-ID: <1993May12.120553.69@dcs.simpact.com> From: jmeinke@dcs.simpact.com Date: 12 May 93 12:05:53 PDT What's the best way to preserve a large base of applications which use the QIO interface to I/O devices which won't be supported in the future, but whose functions will be supported by similar devices connected to a server via Process Software's TCPware. The applications as currently written perform simple reads, writes, setmodes, etc. However, it looks as though substantial revisions will be required for the applications to communicate with the server to do the same functions. We could use the TCPware socket library, of course, or the tcpdriver qio interface. However, since we have so many applications, maybe it would make sense to write a pseudodriver in order to preserve the existing QIO interface. (Easier said than done, I know.) Is it possible to use the alternate I/O entry point on tcpdriver? How about any of the other drivers, such as udpdriver or ipdriver? Is this technically feasible? What sort of problems would I run into? Are there other solutions which would allow us to use the existing QIO interface? Thanks. Please email; I'll summarize. -- Jim Meinke, Simpact Associates 619-565-1865 9210 Sky Park Court jmeinke@dcs.simpact.com San Diego, CA 92123 "I really didn't say everything I said." -- Yogi Berra ================================================================================ Archive-Date: XXX, 13 May 1993 12:10:40 -0500 From: volz@process.com Subject: Re: How do I preserve QIO interface? Message-ID: <1993May13.121040.75@process.com> Date: 13 May 93 12:10:40 -0500 References: <1993May12.120553.69@dcs.simpact.com> In article <1993May12.120553.69@dcs.simpact.com>, jmeinke@dcs.simpact.com writes: > What's the best way to preserve a large base of applications > which use the QIO interface to I/O devices which won't be > supported in the future, but whose functions will be supported > by similar devices connected to a server via Process > Software's TCPware. > > The applications as currently written perform simple reads, > writes, setmodes, etc. However, it looks as though substantial > revisions will be required for the applications to communicate > with the server to do the same functions. We could use the > TCPware socket library, of course, or the tcpdriver qio > interface. > > However, since we have so many applications, maybe it would > make sense to write a pseudodriver in order to preserve the > existing QIO interface. (Easier said than done, I know.) > > Is it possible to use the alternate I/O entry point on > tcpdriver? How about any of the other drivers, such as > udpdriver or ipdriver? > > Is this technically feasible? What sort of problems would I > run into? Are there other solutions which would allow us to > use the existing QIO interface? > > Thanks. Please email; I'll summarize. > -- > Jim Meinke, Simpact Associates 619-565-1865 > 9210 Sky Park Court jmeinke@dcs.simpact.com > San Diego, CA 92123 > > "I really didn't say everything I said." -- Yogi Berra 1. Probably the best way to preserve existing applications is to write emulation device drivers for those devices that talk to the server. However, this is complex and involved. The advantage is that you don't have to modify the applications. Without knowning the number of applications and the complexity of each application (and if source code is even available), it is hard to determine whether the pseudo driver is worth the effort. If you have just a few applications, it may be easier to change them. 2. TCPDRIVER, UDPDRIVER, and IPDRIVER do support an alt-start I/O interface. However, as most alt-start I/O interfaces it is private and not documented for external use. The main reasons for this are that we want the flexibility to change it and won't have this flexibility if we let customers make use of it; and one has to be very careful as to how this interface is used so it tends to be more difficult to support. We may be able to supply the information for specific applications with the understanding that it is subject to change in future releases. Indicentally, all of the QIO functions can be issued through the alt-start I/O interface (not just reads and writes). 3. An alternative solution to using the alt-start I/O interface is to write a pseudo driver (or drivers) that pass the requests to another application (via some special QIO functions or via the ACP mechanism). This application can then use the normal QIO functions to perform the necessary requests. This also moves a lot of the complex code from the driver into an application which is typically easier to debug (especially if it only dives into kernel mode when it needs to). The disadvantage is that performance suffers a bit because of context switching and other overhead. Good luck, - Bernie Volz Process Software Corporation