DNS question
Hi, VM here has a connection to the LAN, but this has always been used for access *to* the mainframe rather than *from* the mainframe. As a result I never bothered to set up any DNS in VM's tcpip. I am now trying to do this, on a test stack. I copied TCPIP DATA to its 191 and added these lines: DOMAINLOOKUP DNSONLY NSINTERADDR 10.230.2.76 NSINTERADDR 10.230.2.77 I got those two DNS addresses by doing ipconfig /all on a windows PC on the lan. After IPLing that user to start up the stack, I am able to ping both IP addresses, and another IP of a host on the network, but when I try to ping that host by its name I get: DTCPIN014W PING: UNKNOWN HOST xxx Pinging that name *does* work from the PC. -- Q CPLEVEL Z/VM VERSION 4 RELEASE 4.0, SERVICE LEVEL 0404 (32-BIT) -- NETSTAT level VM TCP/IP NETSTAT LEVEL 430 IBM 2086; Z/VM VERSION 4 RELEASE 4.0, SERVICE LEVEL 0404 (32-BIT), VM TCP/IP LEV EL 430; RSU 0301 -- What am I forgetting? Thanks, Shimon -- ** ** Shimon Lebowitzmailto:[EMAIL PROTECTED] VM System Programmer . Israel Police National HQ. http://www.poboxes.com/shimonpgp Jerusalem, Israel phone: +972 2 530-9877 fax: 530-9308 ** **
Re: DNS question
On 12/19/06, Shimon Lebowitz [EMAIL PROTECTED] wrote: What am I forgetting? The TCPIP DATA goes on the 592 disk. It's the client code (e.g. PING, TELNET) that has to talk to the DNS to translate the host name into an IP address. The stack has no clue about that. We used to say that it was a good idea to run the cache-only resolver that comes with VM TCP/IP (i.e. NAMED) to avoid excessive DNS lookups going outside VM. Some installations also used it to prime the cache with a set of important host names (in case the outboard DNS was not available). But the VM DNS implementation has become a bit dated, so if you can you should probably avoid that route. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: Moving On
Best of luck to you Ellen and thank you for being part of this group! ___ James Vincent Systems Engineering Consultant Nationwide Services Co., Technology Solutions Mainframe, z/VM and z/Linux Support One Nationwide Plaza 3-20-13 Columbus OH 43215-2220 U.S.A Voice: (614) 249-5547Fax: (614) 677-7681 mailto:[EMAIL PROTECTED] The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 12/18/2006 05:56:49 PM: IBMVM@LISTSERV.UARK.EDU Dear VM Community, After many years as a VM Systems Programmer and Manager, I'll be leaving Interactive Data at the end of December to pursue other interests. My thanks to those of you whom I've known throughout the years and to all the VM Community for your support. I'd especially like to thank the VM Developers whose talent, creativity, and dedication make VM such a great system. The VM mainframe continues to be a key component of Interactive Data's IT operation. Very best wishes for a Happy Holiday season and a Peaceful New Year. Ellen
LPR link terminating
Hi, I started an LPR link in RSCS with this command: SMSG RSCS DEFINE PDF01PO ASTART TYPE LPR FORM * PARM EXIT=LPRXONE HOST=10.240.1.128 PRINTER=PDF01PO ITO=0 USER=Y SYS=Y EPARM='S=N FF=N C=LPRCFG' For some reason, after every print job, this printer is stopping. Here is part of the RSCS console. A file was waiting for printing, until VMUTIL sent a START command to the printer. Immediately after printing the file, the printer was again deactivated. (And needed to be STARTed again for the next file, etc etc etc...) 12:20:59 DMTCMX005I LOCATION TEST(VMUTIL) EXECUTING: START PDF01PO 12:20:59 DMTCMY700I ACTIVATING LINK PDF01PO LPR LINE= CLASS=* QUEUEING=PRIORITY 12:20:59 DMTLPR012I LINK PDF01PO EXIT ROUTINE LPRXONE LOADED AT 00FB5140 12:20:59 DMTLPR181I LINK PDF01PO READY FOR SESSION INITIATION 12:20:59 DMTAXM109I FILE QUEUE REORDERED 12:20:59 DMTLPR193I LINK PDF01PO CONNECTING TO HOST 10.240.1.128 PORT 515 PRINTER PDF01PO 12:20:59 DMTLPR146I SENDING FILE 5126 (5126) ON LINK PDF01PO FROM TEST(XMSL), RECORDS 4 12:20:59 DMTLPR147I SENT FILE 5126 (5126) ON LINK PDF01PO TO PDF01PO(SYSTEM) 001 FILE PURGED 12:20:59 DMTAXM105I FILE 5126 PURGED 12:20:59 DMTLPR193I LINK PDF01PO DISCONNECTING FROM HOST 10.240.1.128 PORT 515 PRINTER PDF01PO 12:20:59 DMTLPR570I LINK PDF01PO NOW SET TO DEACTIVATE 12:20:59 DMTLPR183I LINK PDF01PO SESSION TERMINATED 12:20:59 DMTMAN002I LINK PDF01PO DEACTIVATED 12:20:59 DMTAXM109I FILE QUEUE REORDERED Why should this be? It does not seem to be happening to other printers defined the same way (the DEFINE command is generated by an exec). Thanks, Shimon -- ** ** Shimon Lebowitzmailto:[EMAIL PROTECTED] VM System Programmer . Israel Police National HQ. http://www.poboxes.com/shimonpgp Jerusalem, Israel phone: +972 2 530-9877 fax: 530-9308 ** **
Re: RSCS LPR Printer Name w/spaces
Here is my solution to send print from RSCS to a Windows printer named: 'eSCRIP-SAFE Printer on https://x.xxx-.us/printers/default' I have determined the the real printer name on Windows is eSCRIP-SAFE Printer and does not include the URL that it is printing to. I have also determined that RSCS truncates the PRINTER= name at the first space. It doesn't matter whether the printer name is enclosed in single quotes: PRINTER='ESCRIP-SAFE Printer' This is correct according to Alan Altmark who wrote to me: However, using blanks in LPR queue names violates RFC 1179 (LPR), since blanks are significant to the protocol for 'query' and 'remove' functions. The vendor and I have tried to change the .inf file for installation to not have an embedded space. It seemes that Windows XP SP2 is adding the word Printer to the name. So my solution is to use a third party LPD program called RPM (Remote Print Manager) from Brooks Internet Software: http://www.brooksnet.com/ This LPD server allows me to use my own name for the receiving queue so I chose TRANSCRIPT. RPM then prints to any Windows printer no matter how it is named. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 43 years [EMAIL PROTECTED] +1.724.738.2153 Yes, Virginia, there is a Slippery Rock -- On Tue, 12 Dec 2006 11:54:31 EST Fran Hensler said: I have set up an RSCS LPR link that prints to a Hummingbird LPD server on a PC. The PRINTER name has no spaces and is 27 characters. This is working just fine. Now I want to do the same thing but the printer name has embedded spaces. When I click on properties for the printer I do not get an option to rename the printer. It is a network printer. I enclosed the printer name in single quotes but I get a NAK when I try to print to it. PRINTER='eSCRIP-SAFE Printer on https://x.xxx-.us/printers/default' Does anyone know how I could either rename this printer to remove spaces or how to make RSCS print to printer name with embedded spaces. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 43 years [EMAIL PROTECTED] +1.724.738.2153 Yes, Virginia, there is a Slippery Rock
Re: z/VM 5.3
No. And nothing about 5.2.1 nor 6.1.0 either. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rob Schwartz Sent: Tuesday, December 19, 2006 9:40 AM To: IBMVM@LISTSERV.UARK.EDU Subject: z/VM 5.3 Has anyone heard when z/VM 5.3 is going to be available? Rob If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
Re: z/VM 5.3
There's been no announcements regarding a new release of z/VM. Rob Schwartz wrote: Has anyone heard when z/VM 5.3 is going to be available? Rob -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - May 18-22, 2007
Re: DNS question
We used to say that it was a good idea to run the cache-only resolver that comes with VM TCP/IP (i.e. NAMED) to avoid excessive DNS lookups going outside VM. Some installations also used it to prime the cache with a set of important host names (in case the outboard DNS was not available). But the VM DNS implementation has become a bit dated, so if you can you should probably avoid that route. Or replace it with a minimal Linux guest.
Re: z/VM 5.3
I think it is public enough knowledge that the DB2 for VM and VSE folks are working on a DB2 Client only code. Perhaps not tailored for but more for the DB2/UDB (perhaps under zLinux). My guess, is that we are eventually going to get a package that is some sort of zLinux DB2/UDB simular to GCS/VTAM (for example). That might run directly under VM or may be in a dedicated LPAR (which would work for those VSE only installations). I could also see a zLinux ??? as a way of replacing some TCPIP functions (DNS, ssh, etc). Anyway, right now, it seems a lot of VM development is due to or headed to, zLinux support. Of course, there is also changes for the large shops (better support for 32, 64, processors). Tom Duerbusch THD Consulting Huegel, Thomas wrote: Any guesses as to what might be in a new release?
Re: DNS question
PING does not run on the TCP/IP stack, it runs on the userid that issued the command. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Shimon Lebowitz Sent: December 19, 2006 12:59 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DNS question Quoting Rob van der Heij [EMAIL PROTECTED]: On 12/19/06, Shimon Lebowitz [EMAIL PROTECTED] wrote: What am I forgetting? The TCPIP DATA goes on the 592 disk. It's the client code (e.g. PING, TELNET) that has to talk to the DNS to translate the host name into an IP address. The stack has no clue about that. confused I don't think I understand what you are saying. I put the altered version of TCPIP DATA on TCPIP2's (my test stack userid) so that the stack would see the DNS lines, doesn't PING run in the TCPIP2 user itself? The 191 is accessed ahead of 592, so doesn't TCPIP2 know about the DNS? /confused We used to say that it was a good idea to run the cache-only resolver that comes with VM TCP/IP (i.e. NAMED) to avoid excessive DNS lookups going outside VM. Some installations also used it to prime the cache with a set of important host names (in case the outboard DNS was not available). But the VM DNS implementation has become a bit dated, so if you can you should probably avoid that route. H used to say it was a good idea you should probably avoid that route? I actually tried to start NAMSERV )or whatever the builtin DNS is called), including putting the two DNS server addresses in FORWARDERS(?), but it didn't help. I am home now, so I might not remember keywords correctly. Thanks for responding, Shimon ._._._*_|_*_*_*_* The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot by guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner.
Re: DNS question
Shimon ... The stack does not perform DNS resolution. The applications handle it (even if by way of some library function). This is true in other TCP/IP implementations, not just VM TCP/IP: the apps resolve hostnames. -- R; Shimon Lebowitz [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 12/19/2006 12:59 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU From Shimon Lebowitz [EMAIL PROTECTED] To IBMVM@LISTSERV.UARK.EDU cc Subject Re: DNS question Quoting Rob van der Heij [EMAIL PROTECTED]: On 12/19/06, Shimon Lebowitz [EMAIL PROTECTED] wrote: What am I forgetting? The TCPIP DATA goes on the 592 disk. It's the client code (e.g. PING, TELNET) that has to talk to the DNS to translate the host name into an IP address. The stack has no clue about that. confused I don't think I understand what you are saying. I put the altered version of TCPIP DATA on TCPIP2's (my test stack userid) so that the stack would see the DNS lines, doesn't PING run in the TCPIP2 user itself? The 191 is accessed ahead of 592, so doesn't TCPIP2 know about the DNS? /confused We used to say that it was a good idea to run the cache-only resolver that comes with VM TCP/IP (i.e. NAMED) to avoid excessive DNS lookups going outside VM. Some installations also used it to prime the cache with a set of important host names (in case the outboard DNS was not available). But the VM DNS implementation has become a bit dated, so if you can you should probably avoid that route. H used to say it was a good idea you should probably avoid that route? I actually tried to start NAMSERV )or whatever the builtin DNS is called), including putting the two DNS server addresses in FORWARDERS(?), but it didn't help. I am home now, so I might not remember keywords correctly. Thanks for responding, Shimon ._._._*_|_*_*_*_*
Re: DNS question
On Tuesday, 12/19/2006 at 07:59 ZE2, Shimon Lebowitz [EMAIL PROTECTED] wrote: confused I don't think I understand what you are saying. I put the altered version of TCPIP DATA on TCPIP2's (my test stack userid) so that the stack would see the DNS lines, doesn't PING run in the TCPIP2 user itself? The 191 is accessed ahead of 592, so doesn't TCPIP2 know about the DNS? /confused No, PING does not run in the stack. There is a low-level ICMP ECHO (ping) function in the stack that is invoked by the PING program, but that interface expects an IP address as input. DNS resolution is always done in the client virtual machine. We used to say that it was a good idea to run the cache-only resolver that comes with VM TCP/IP (i.e. NAMED) to avoid excessive DNS lookups going outside VM. Some installations also used it to prime the cache with a set of important host names (in case the outboard DNS was not available). But the VM DNS implementation has become a bit dated, so if you can you should probably avoid that route. H used to say it was a good idea you should probably avoid that route? I actually tried to start NAMSERV )or whatever the builtin DNS is called), including putting the two DNS server addresses in FORWARDERS(?), but it didn't help. I am home now, so I might not remember keywords correctly. A caching-only DNS server is useful if you have a lot of CMS-based DNS lookups and you're having DNS-related performance problems. Other operating systems maintain their own caches, so pointing them to VM's DNS server doesn't have much value. It's far easier if you just point your NSINTERADDR entries to your normal DNS servers. Then, whatever the DNS problem du jour is, it isn't your fault. :-) Faster machines and faster networks have all done much to erase the benefit of a caching-only DNS server. Having said that, would there be torches and pitchforks awaiting us at the next conference if we chose to remove the VM DNS server from the suite of supported apps? (No plans...just a Grinchy idea.) Alan Altmark z/VM Development IBM Endicott
Re: DNS question
Having said that, would there be torches and pitchforks awaiting us at the next conference if we chose to remove the VM DNS server from the suite of supported apps? (No plans...just a Grinchy idea.) Mr. Grinch, We would not object to you removing the VM DNS server. We have always used NSINTERADDR to point to our local Windows name servers and have not ever seen any performance related issues. Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: DNS question
We have not run the VM DNS server since z/VM 3.0. We are now on 5.1, wait ing for 5.3. We would not have any problem with the removal of the VM DNS ser vice. Are there other VM TCP/IP services that you would consider removing? /Tom Kern On Tue, 19 Dec 2006 14:03:37 -0500, Alan Altmark wrote: ...snipped... Faster machines and faster networks have all done much to erase the benefit of a caching-only DNS server. Having said that, would there be torches and pitchforks awaiting us at t he next conference if we chose to remove the VM DNS server from the suite o f supported apps? (No plans...just a Grinchy idea.) Alan Altmark z/VM Development IBM Endicott
Re: DNS question
And of course the programming needed to make this change would be known as The DaGrinchy Code. Laugh now, they don't get any better. Peter Having said that, would there be torches and pitchforks awaiting us at the next conference if we chose to remove the VM DNS server from the suite of supported apps? (No plans...just a Grinchy idea.) Alan Altmark z/VM Development IBM Endicott The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot by guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner.
Re: DNS question
Quoting David Boyes [EMAIL PROTECTED]: We used to say that it was a good idea to run the cache-only resolver that comes with VM TCP/IP (i.e. NAMED) to avoid excessive DNS lookups going outside VM. Some installations also used it to prime the cache with a set of important host names (in case the outboard DNS was not available). But the VM DNS implementation has become a bit dated, so if you can you should probably avoid that route. Or replace it with a minimal Linux guest. How will that help? If the DNS didn't work using the servers in our LAN, why would it work better talking to a linux guest? And I would get the extra fun of building a linux DNS server instead of just forwarding all requests to the windows boxes? No thanks. What I still don't understand is why adding the addresses of the servers to the TCPIP DATA didn't have the expected result. Shimon
Re: DNS question
We have never used the VM DNS server, so we would not object too strongly. Laugh now, they don't get any better. And probably not any worse, either. :-) -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, December 19, 2006 11:14 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DNS question And of course the programming needed to make this change would be known as The DaGrinchy Code. Laugh now, they don't get any better. Peter Having said that, would there be torches and pitchforks awaiting us at the next conference if we chose to remove the VM DNS server from the suite of supported apps? (No plans...just a Grinchy idea.) Alan Altmark z/VM Development IBM Endicott The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot by guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner.
Re: DNS question
Quoting Alan Altmark [EMAIL PROTECTED]: On Tuesday, 12/19/2006 at 07:59 ZE2, Shimon Lebowitz [EMAIL PROTECTED] wrote: confused I don't think I understand what you are saying. I put the altered version of TCPIP DATA on TCPIP2's (my test stack userid) so that the stack would see the DNS lines, doesn't PING run in the TCPIP2 user itself? The 191 is accessed ahead of 592, so doesn't TCPIP2 know about the DNS? /confused No, PING does not run in the stack. There is a low-level ICMP ECHO (ping) function in the stack that is invoked by the PING program, but that interface expects an IP address as input. DNS resolution is always done in the client virtual machine. OK, I have that straightened out in my mind now. :-) Thanks to all who helped with that. So, PING is a program that runs in *my* virtual machine. And my machine is linked to 592 in order to see the PING MODULE. And 592 has the production version of TCPIP DATA, with no NSINTERADDR records. It's far easier if you just point your NSINTERADDR entries to your normal DNS servers. Then, whatever the DNS problem du jour is, it isn't your fault. :-) So, I need to access the updated DATA file in MY virtual machine, so that PING will know where to do DNS. I will try all this tomorrow. THANKS Shimon ._._._*_|_*_*_*_*
Re: DNS question
On Dec 19, 2006, at 2:03 PM, Alan Altmark wrote: Having said that, would there be torches and pitchforks awaiting us at the next conference if we chose to remove the VM DNS server from the suite of supported apps? (No plans...just a Grinchy idea.) Yes, unless you tossed in a minimal DNS server, say in a 16M Linux guest with, say, a tiny little filesystem in a shared segment. Adam
Re: DNS question
I'd disagree with the assertion that you no longer need an internal DNS; there's still value to having the ability to not go out on the wire, and also to periodically lie to various things about the real setup for a subset of the environment. Remember, you're attaching network segments with the Linux stuff, and it's real handy to cache stuff in common for them. The antique CMS implementation is a royal PITA to do this with, however. Having said that, would there be torches and pitchforks awaiting us at the next conference if we chose to remove the VM DNS server from the suite of supported apps? (No plans...just a Grinchy idea.) Ditch the DB/2-requiring abomination. I'll create a small Linux appliance for the folks that need a real DNS server for VM systems.
Re: DNS question
On Dec 19, 2006, at 2:23 PM, Shimon Lebowitz wrote: Quoting David Boyes [EMAIL PROTECTED]: We used to say that it was a good idea to run the cache-only resolver that comes with VM TCP/IP (i.e. NAMED) to avoid excessive DNS lookups going outside VM. Some installations also used it to prime the cache with a set of important host names (in case the outboard DNS was not available). But the VM DNS implementation has become a bit dated, so if you can you should probably avoid that route. Or replace it with a minimal Linux guest. How will that help? If the DNS didn't work using the servers in our LAN, why would it work better talking to a linux guest? Because the Linux bind9 implementation is a modern implementation of DNS. Yes, for it to be a useful caching server it's still going to have to be able to talk to some other network servers. And I would get the extra fun of building a linux DNS server instead of just forwarding all requests to the windows boxes? The idea would be that *you* wouldn't have to do it. Just another virtual machine that you power on and something is providing name service to things on the VM host. Adam
Re: DNS question
Mr. Grinch - Cindy Loo Who asked if z/OS is using BIND now and if that could run on OpenVM. She's a bright kid! I was going to ask her more about the idea, but some Opie-looking guy kept yelling cut! cut! and chased us off the set. - ho ho ho - Sir Santa -- R;
Re: DNS question
We used to say that it was a good idea to run the cache-only resolver that comes with VM TCP/IP (i.e. NAMED) to avoid excessive DNS lookups going outside VM. Some installations also used it to prime the cache with a set of important host names (in case the outboard DNS was not available). But the VM DNS implementation has become a bit dated, so if you can you should probably avoid that route. Or replace it with a minimal Linux guest. How will that help? If the DNS didn't work using the servers in our LAN, why would it work better talking to a linux guest? In your case, it was actually a different problem (what interprets the NSINTERADDR lines is in the client VM, not the stack VM); I was commenting on Rob's comment about no longer running the caching server on VM. The reasons it helps with the issue of running the caching server on VM in that the Linux appliance allows you to cache efficiently (as the current code does), but also supply real usable DNS services that can supply answers different than the ones supplied by your external DNS for test or policy reasons, as well as support the latest security and authentication requirements. The biggest problems with the CMS DNS server are that it is based on really, really ancient interpretations of the DNS RFCs and that it requires DB/2 VM to provide anything more than caching services. Given the neglect of DB/2 VM over the past years and the cost, running DNS doesn't really work on CMS other than if it's absolutely required by some procurement wonk with a checklist. Can't do DNSSEC, can't do zone transfer restrictions, can't do DDNS, can't do a lot of things. All of which 'bind' on Linux does trivially at zero additional cost. It's handy for test purposes because you could force the Linux guest to give any answer you wanted w/o having to convince your Windows admins to break the real DNS for your purpose. It's also useful in the case where you're hosting Linux guests that provide network services to not have a dozen different systems beating the tar out of your external DNS servers; get one internal one set up, cache results, and have all the extras consult the internal one. Significantly less network traffic for busy services that way.
Re: z/VM 5.3
On Tuesday, 12/19/2006 at 09:42 EST, Stracka, James (GTI) [EMAIL PROTECTED] wrote: No. And nothing about 5.2.1 nor 6.1.0 either. And just in case no one noticed, they also haven't announced 5.4 through 5.11, 6.1 and 6.2 (APPC Lives!), or 8.1, taking them out through 2089. (No V7, for the same reason there's no IPv5.) There are probably some others they haven't announced, but they don't know what they'll have in them or when they'll deliver them. The dopes. Oh, yeah, before I forget, bah, humbug! I mean, have a happy holiday season, even those who like MVS. May you have a healthy and properous new year. (If sufficiently prosperous, please remember who arranged it for you. 10s and 20s are fine.) If you do get a rash, don't blame me. Enjoy yourselves, don't worry about work. It is perfectly capable of piling up on its own, waiting for you when you return. In any case, there's nothing like taking a WHOLE day off to rejuvenate your soul. If you find yourself wondering if your e-mail mailbox will fill up and start rejecting mail, then you should take TWO days off. Be considerate to the environment this year: Give the grandkids noisy gifts that don't wear out too quickly and don't use batteries. Mom Dad will appreciate your thoughtfulness. If you will be drinking and driving during the holidays, don't be an idiot. Drink responsibly (designated drivers only, please) and, before YOU get behind the wheel, consider whether you've written down the I/O changes you made last week or noted the new sysres address on the yellow sticky by the console. Other people DO care what happens to you. Even if it isn't me. Peace. -- Chuckie
Re: DNS question
On 12/19/06, David Boyes [EMAIL PROTECTED] wrote: It's handy for test purposes because you could force the Linux guest to give any answer you wanted w/o having to convince your Windows admins to break the real DNS for your purpose. It's also useful in the case where you're hosting Linux guests that provide network services to not have a Yeah... depending on how fluent you are in DNS it will either bite you very soon or only later... The DNS protocol has been stretched and the de-facto standard extended beyond the RFCs. When you make your DNS claim authority over a domain that you don't own, real world effects may vary. Things like negative caching can make you go bold very fast. I learned a lot of those tricks when I did my own DNS server on CMS. And I learned from my network colleague that you can also contaminate the cache of the NAMESERV freebie with names that you made up yourself. Can do for several evenings happy searching. For an occasional telnet or ping command, the impact of going out to resolve the name is neglectable. The best case imho for having a DNS cache local on VM is for reverse lookup of client IP address when you run a web server on VM. The typical visit may contain several hits and going out to the LAN for each of them is a waste because probably the web server will wait for the response before serving the client. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: DNS question
On Tuesday, 12/19/2006 at 02:56 EST, Adam Thornton [EMAIL PROTECTED] wrote: Yes, unless you tossed in a minimal DNS server, say in a 16M Linux guest with, say, a tiny little filesystem in a shared segment. B. IBM is not a Linux distributor and it doesn't qualify as an imbedded system. You may take your seat now. Next, please! Alan Altmark z/VM Development IBM Endicott
Re: DNS question
On 12/19/06, David Boyes [EMAIL PROTECTED] wrote: It's handy for test purposes because you could force the Linux guest to give any answer you wanted w/o having to convince your Windows admins to break the real DNS for your purpose. It's also useful in the case where you're hosting Linux guests that provide network services to not have a Yeah... depending on how fluent you are in DNS it will either bite you very soon or only later... Life is seldom risk free; your gun, your foot. If you don't know what you're doing, you shouldn't play with sharp objects. Cache poisoning tools are a lot more difficult to control than zone files are. It's also a lot simpler to always list a local DNS server first in the standard list in your configuration and just shut it down when it's not in use. For caching purposes it works fine, and in test or DR situations, you bring it up with a minimal set of zone files, and DNS Just Works, the way it's supposed to -- long before any of the Windows guys have gotten past reinstalling to get a fresh SID. The VM resolver code is fine with retrying the next one in the list if the first one isn't there. The DNS protocol has been stretched and the de-facto standard extended beyond the RFCs. And bind happens to *be* the de-facto standard implementation. Another reason to run it instead of the VM DNS server code. For an occasional telnet or ping command, the impact of going out to resolve the name is neglectable. True. The best case imho for having a DNS cache local on VM is for reverse lookup of client IP address when you run a web server on VM. The typical visit may contain several hits and going out to the LAN for each of them is a waste because probably the web server will wait for the response before serving the client. Mail is another high volume one (also lots of reverse lookups, even if you just do outgoing from VM). Or LPR/LPD for heavily-used printers. Or any high-connection-volume service, really.
Peggy Williams/Endicott/IBM is out of the office.
I will be out of the office starting 12/19/2006 and will not return until 01/02/2007. If you need technical assistance, please contact Susan Timashenka.
Re: DNS question
On Dec 19, 2006, at 9:25 PM, Jack Woehr wrote: Adam Thornton wrote: Yes, unless you tossed in a minimal DNS server, say in a 16M Linux guest with, say, a tiny little filesystem in a shared segment. It's called 'Bind' Well, no. A minimal DNS server would be, say, tinydns. But then you'd have to deal with djbware. Or, you know, several of the things listed at http://www.debianadmin.com/open-source-domain-name-systemdns- servers.html. bind is, these days, anything but minimal. Don't get me wrong--I like bind9 quite a bit. But it's kinda...well...it's gonna have to let that prom dress out a little, is what I mean. And I'd say it has a nice personality, only, um, it's only slightly less cranky than djbware, really. However, as Chuckie has pointed out, my post is moot because IBM is not going to get into the Linux distribution market. So...has anyone invested any time in a CMS port (OpenVM or otherwise) of one of the lightweight DNS servers? Adam
Re: DNS question
On Dec 19, 2006, at 11:01 PM, Jack Woehr wrote: Adam Thornton wrote: bind is, these days, anything but minimal. We should port OpenBSD to the 390. You could probably run OpenBSD + bind in a 12MB VM. Way back in '99 I suggested a port to the NetBSD guys (back when NetBSD's big claim to fame was its portability), and instead of saying hey, neat idea, or what would it take? they subjected me to a tirade about how much Linux sucked. That sort of soured me on finding BSD porters for the architecture. I haven't ever approached Theo about a 390 port. But with Hercules, you could get started for very very cheap Adam
