Re: Accessing TCPIP.DATA from Perl on os390
[email protected] ("M. Ray Mullins") Tue, 9 May 2017 11:53:40 -0700
| Newsgroups | perl.mvs |
|---|---|
| Message-ID | <[email protected]> |
--------------83E50599638D279A6B9D827F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit (CC'd back to the mailing list.) On 2017-05-04 20:22, Dick Franks wrote: > > On 5 May 2017 at 01:08, M. Ray Mullins <[email protected] > <mailto:[email protected]>> wrote: > > Hello Dick, > > This appears to be a duplicate of an email you sent yesterday. Did > you receive my answer sent to the mailing list later that day? > > > Thanks > > I was not subscribed to the list. No reply came, so I assumed that > posting was restricted to subscribers, signed up and reposted Makes sense. I was a bit surprised to see the same thing twice. :) > > > If not, here is what I sent: > > ----- > > Hi Dick, > > As the UNIX® System Services component of z/OS is certified UNIX- and > POSIX-compliant, whatever method you use currently to interrogate the > UNIX and brethren OSes should work. > > But does not because /etc/resolv.conf not the only place this could be > found. > > Having said that, of course, we are talking z/OS and EBCDIC, so, of > course, I'm sure it won't work out of the box and would require a tweak > or three. > > EBCDIC issues fixed in Net::DNS 1.10 Yay! EBCDIC, the forgotten code set. :D > > Tested, working, just no default nameserver config. It is possible to read traditional data sets from the UNIX servers, however to be fair, I personally have not tried it. In z/OS C, if you prefix a file specification with //, the C run-time knows that this data set resides in the traditional file system. If you don't prefix with single quotes, it prepends a high-level qualifier consisting of the userid. For example, in my environment (one of my userids is RMULLIN), "//MISC.ASM" would cause the C run-time to access data set RMULLIN.MISC.ASM. Likewise, to access TCPIP.DATA, you'd specify "//'TCPIP.DATA'". I've never tried open(FHAND, "<//'data.set.name'") or die "Not found: $!". I don't have perl installed on our system (I should talk to TPTB). Also, be aware that although those are the default and most common data set names used for the TCP/IP server, they can be changed. Having said all that…I believe the information you are looking for is available through calls to system routines. This might require dropping into C, though. I've been a bit busy, but I'll look at the relevant z/OS C run-time library and TCP/IP manuals later this week. Best regards, Ray Mullins > > Is there a specific issue you've encountered so far? > > > ----- > > Best regards, > Ray Mullins > > > On 2017-05-04 16:24, Dick Franks wrote: >> All, >> >> Is it possible to access the content of TCPIP.DATA and >> GLOBALTCPIPDATA from a Perl script? >> >> Where do these files live? Are they readable and parseable? >> >> Alternatively, is there some easy way of interrogating the OS to >> find the value associated with an individual parameter name? >> >> I am specifically interested in finding the local DNS nameserver >> addresses, searchlist, etc. to provide the default values for >> Net::DNS so that it works the same way on all supported platforms. >> >> Any help you can provide would be much appreciated, an example, >> even better. >> >> P.S. I know next to nothing about MVS, so have a strong >> preference for succinct and straightforward answers. >> >> >> Dick Franks >> ________________________ >> > > > -- > M. Ray Mullins > Roseville, CA, USA > > German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi > French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson > English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté] > > -- M. Ray Mullins Roseville, CA, USA German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté] --------------83E50599638D279A6B9D827F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">(CC'd back to the mailing list.)<br> <br> On 2017-05-04 20:22, Dick Franks wrote:<br> </div> <blockquote type="cite" cite="mid:CAKW6Ri41UKhuU=3KEze9ZhpQUVAQ2Fm+9YiTXHwKx2v8O1QfEQ@mail.gmail.com"> <div dir="ltr"> <div class="gmail_extra"> <br> <div class="gmail_quote">On 5 May 2017 at 01:08, M. Ray Mullins <span dir="ltr"><<a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#FFFFFF"> <div class="m_8480399116907371252m_-733638286560945308moz-cite-prefix">Hello Dick,<br> <br> This appears to be a duplicate of an email you sent yesterday. Did you receive my answer sent to the mailing list later that day?<br> </div> </div> </blockquote> <div><br> </div> <div>Thanks<br> <br> </div> <div>I was not subscribed to the list. No reply came, so I assumed that posting was restricted to subscribers, signed up and reposted<br> </div> </div> </div> </div> </blockquote> <br> Makes sense. I was a bit surprised to see the same thing twice. :)<br> <blockquote type="cite" cite="mid:CAKW6Ri41UKhuU=3KEze9ZhpQUVAQ2Fm+9YiTXHwKx2v8O1QfEQ@mail.gmail.com"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#FFFFFF"> <div class="m_8480399116907371252m_-733638286560945308moz-cite-prefix"> <br> If not, here is what I sent:<br> <br> -----<br> <pre style="color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">Hi Dick, As the UNIX® System Services component of z/OS is certified UNIX- and POSIX-compliant, whatever method you use currently to interrogate the UNIX and brethren OSes should work.</pre> </div> </div> </blockquote> <div>But does not because /etc/resolv.conf not the only place this could be found.<br> <br> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#FFFFFF"> <div class="m_8480399116907371252m_-733638286560945308moz-cite-prefix"> <pre style="color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">Having said that, of course, we are talking z/OS and EBCDIC, so, of course, I'm sure it won't work out of the box and would require a tweak or three.</pre> </div> </div> </blockquote> <div>EBCDIC issues fixed in Net::DNS 1.10<br> </div> </div> </div> </div> </blockquote> Yay! EBCDIC, the forgotten code set. :D<br> <blockquote type="cite" cite="mid:CAKW6Ri41UKhuU=3KEze9ZhpQUVAQ2Fm+9YiTXHwKx2v8O1QfEQ@mail.gmail.com"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div><br> </div> <div>Tested, working, just no default nameserver config.<br> </div> </div> </div> </div> </blockquote> <br> It is possible to read traditional data sets from the UNIX servers, however to be fair, I personally have not tried it.<br> <br> In z/OS C, if you prefix a file specification with //, the C run-time knows that this data set resides in the traditional file system. If you don't prefix with single quotes, it prepends a high-level qualifier consisting of the userid. For example, in my environment (one of my userids is RMULLIN), <font face="Consolas">"//MISC.ASM"</font> would cause the C run-time to access data set <font face="Consolas">RMULLIN.MISC.ASM</font>. Likewise, to access <font face="Consolas">TCPIP.DATA</font>, you'd specify <font face="Consolas">"//'TCPIP.DATA'"</font>. <br> <br> I've never tried <font face="Consolas">open(FHAND, "<//'data.set.name'") or die "Not found: $!"</font>. I don't have perl installed on our system (I should talk to TPTB).<br> <br> Also, be aware that although those are the default and most common data set names used for the TCP/IP server, they can be changed.<br> <br> Having said all that…I believe the information you are looking for is available through calls to system routines. This might require dropping into C, though.<br> <br> I've been a bit busy, but I'll look at the relevant z/OS C run-time library and TCP/IP manuals later this week.<br> <br> Best regards,<br> Ray Mullins<br> <blockquote type="cite" cite="mid:CAKW6Ri41UKhuU=3KEze9ZhpQUVAQ2Fm+9YiTXHwKx2v8O1QfEQ@mail.gmail.com"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div><br> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#FFFFFF"> <div class="m_8480399116907371252m_-733638286560945308moz-cite-prefix"> <pre style="color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">Is there a specific issue you've encountered so far? </pre> -----<br> <br> Best regards,<br> Ray Mullins <div> <div class="m_8480399116907371252h5"><br> <br> On 2017-05-04 16:24, Dick Franks wrote:<br> </div> </div> </div> <div> <div class="m_8480399116907371252h5"> <blockquote type="cite"> <div dir="ltr"> <div> <div> <div> <div> <div> <div>All,<br> <br> </div> Is it possible to access the content of TCPIP.DATA and GLOBALTCPIPDATA from a Perl script?<br> <br> </div> Where do these files live? Are they readable and parseable?<br> <br> </div> Alternatively, is there some easy way of interrogating the OS to find the value associated with an individual parameter name?<br> <br> </div> I am specifically interested in finding the local DNS nameserver addresses, searchlist, etc. to provide the default values for Net::DNS so that it works the same way on all supported platforms.<br> <br> </div> Any help you can provide would be much appreciated, an example, even better.<br> <br> </div> P.S. I know next to nothing about MVS, so have a strong preference for succinct and straightforward answers.<br> <br> <br clear="all"> <div> <div class="m_8480399116907371252m_-733638286560945308m_-2514824133157951309m_-8690520156766544074gmail_signature"> <div dir="ltr">Dick Franks<br> <span><font color="#888888">________________________<br> </font></span><br> </div> </div> </div> </div> </blockquote> <br> <br> </div> </div> <span class="m_8480399116907371252HOEnZb"><font color="#888888"> <pre class="m_8480399116907371252m_-733638286560945308moz-signature" cols="72">-- M. Ray Mullins Roseville, CA, USA German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]</pre> </font></span></div> </blockquote> </div> <br> </div> </div> </blockquote> <br> <br> <pre class="moz-signature" cols="72">-- M. Ray Mullins Roseville, CA, USA German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]</pre> </body> </html> --------------83E50599638D279A6B9D827F--