Health Checker - LNKLST Datasets
Kenneth R Barkhau
Anyone know if there is a way to use the Health Checker to IDENTIFY the
SPECIFIC LNKLST datasets that are allocated with secondary extents? I
see that the Health Checker will discover if the condition exists, (ie.
IBMCSV CSV_LNKLST_SPACE
IBMCSV CSV_LNKLST_NEWEXTENTS
datasets)
I want to find WHICH datasets are the culprit.
Thanks much,
Ken
Kenneth R. Barkhau
DHTS
Duke University Medical Center
2424 Erwin Rd
HOCK Plaza
Durham, NC 27710
Sr. Systems Programmer
Office Phone - 919-681-2482
kenneth...@duke.edu
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Mark Zelden
<kenneth...@DUKE.EDU> wrote:
>Hello All-
>
>Anyone know if there is a way to use the Health Checker to IDENTIFY the
>SPECIFIC LNKLST datasets that are allocated with secondary extents? I
>see that the Health Checker will discover if the condition exists, (ie.
>IBMCSV CSV_LNKLST_SPACE
> IBMCSV CSV_LNKLST_NEWEXTENTS
>datasets)
>
>I want to find WHICH datasets are the culprit.
>
CSV_LNKLST_SPACE checks for data sets in the LNKLST with
secondary extents allocated. The only ones it lists are the ones
with secondary extents. For example:
====================================
CSVH0979I LNKLST set LNKLST00 data sets allocated with secondary space
VOLUME DSNAME
SYSRES SYS2.DSN.WITH.SECONDRY.XTNTS
* Low Severity Exception *
====================================
CSV_LNKLST_NEWEXTENTS will identify which data set(s) have ADDED
additional extents since the LNKLST set was activated. If this condition
exists, you won't miss finding the name in the output. For example:
====================================
CSVH0969I LNKLST set LNKLST00
The error status is in column one:
C = Confirmed error * = New error - = Unknown
ORIG CURR VOLUME DSNAME
* 1 2 SYSRES SYS2.SOME.LNKLST.LIBRARY
TOTAL EXTENTS ORIG: 132 CURR: 133
=====================================
* High Severity Exception *
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Anthony Thompson
SDSF will tell you. Use primary command 'CK E' to list triggered events, then use the 'S' line command next to the event you want the details about.
SDSF provides a nice REXX interface so you can use all that info programmatically if you want.
Cheers, Ant.
Northern Territory Government
Australia
SrinivasG
In My DFSMS , I have defined Stogroup and Storage Class for VIO as FINVIO.
In ACSROUTINES I have mentioned as
WHEN (&STORCLAS = 'FINVIO') DO
SET &STORGRP = 'FINVIO'
EXIT
END
And
WHEN (&UNIT = &DEV_VIO) DO
SET &STORCLAS = 'FINVIO'
EXIT
END
Here is the Esoteric List :
/ Esoteric VIO Token State
_ SYSDA Yes 100
_ TAPE No 200
But when I run RMF Sort Job
//RMFSORT EXEC PGM=SORT,REGION=4M
//SORTIN DD DISP=SHR,DSN=SYS2.SMFDUMPW.REST
//SORTOUT DD DISP=(NEW,PASS),UNIT=SYSDA,SPACE=(CYL,(200,600))
//SORTWK01 DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL,(100,250))
//SORTWK02 DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL,(100,250))
//SORTWK03 DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL,(100,250))
//SORTWK04 DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL,(100,250))
//SORTWK05 DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL,(100,250))
//SORTWK06 DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL,(100,250))
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSIN DD *
SORT FIELDS=(11,4,CH,A,7,4,CH,A),EQUALS
MODS E15=(ERBPPE15,500,,N),E35=(ERBPPE35,500,,N)
I get the error :
1ICE143I 0 BLOCKSET SORT TECHNIQUE SELECTED
ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS, EXAMPLES A ND MORE
ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R10 - 15:05 ON TUE N
0 SORT FIELDS=(11,4,CH,A,7,4,CH,A),EQUALS
MODS E15=(ERBPPE15,500,,N),E35=(ERBPPE35,500,,N)
ICE201I F RECORD TYPE IS V - DATA STARTS IN POSITION 5
ICE178I 0 REALLOCATING VIO SORTWK DATA SETS TO REAL SORTDK DATA SETS USING UNIT =3390
ICE179A 0 RESOURCES WERE UNAVAILABLE FOR VIO REALLOCATION OF WORK DATA SETS (0218)
ICE751I 0 C5-K90014 C6-K90014 C7-BASE C8-K42136 E4-BASE C9-BASE E5-K45240 E6-BASE E7-K44564
ICE052I 3 END OF DFSORT
Here is the Esoteric List :
/ Esoteric VIO Token State
_ SYSDA Yes 100
_ TAPE No 200
Any help is appreciated.
Regards,
Srinivas G
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are not
to copy, disclose, or distribute this e-mail or its contents to any other person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
every reasonable precaution to minimize this risk, but is not liable for any damage
you may sustain as a result of any virus in this e-mail. You should carry out your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
Vernooij, CP - SPLXM
real dasd, but apparantly you don't allow this.
Kees.
"SrinivasG" <SRIN...@INFOSYS.COM> wrote in message
news:<E5D4741C0D67254EA3601...@BLRKECMBX05.ad.infosys.
com>...
**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286
**********************************************************************
Vernooij, CP - SPLXM
You should check why you don't allow DASD and change this.
Kees.
-----Original Message-----
From: SrinivasG [mailto:SRIN...@infosys.com]
Sent: donderdag 5 november 2009 12:37
To: Vernooij, CP - SPLXM
Subject: RE: VIO Error
Thanks for the reply.
Now what should I do? Allocate some DASD Volumes? In What Storage Class?
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Kenneth R Barkhau
Thanks very much for the information regarding identifying those datasets.
This was just what I needed!
Regards,
Ken
Kenneth R. Barkhau
DHTS
Duke University Medical Center
2424 Erwin Rd
HOCK Plaza
Durham, NC 27710
Sr. Systems Programmer
Office Phone - 919-681-2482
kenneth...@duke.edu
Anthony Thompson <Anthony....@NT.GOV.AU>
Sent by: IBM Mainframe Discussion List <IBM-...@bama.ua.edu>
11/04/2009 09:41 PM
Please respond to
IBM Mainframe Discussion List <IBM-...@bama.ua.edu>
Mark Zelden
Which error are you referring to? ICE179A? Did you look up the message?
It tell you that you tried to use VIO, but the installation doesn't allow it so
it tried to allocated on real dasd and there wasn't enough space.
Mark
Mark Zelden
<Kees.V...@KLM.COM> wrote:
>DFSORT does not like SORTWK's on VIO. It tries to reallocate them to
>real dasd, but apparantly you don't allow this.
>
Although not recommended, VIO can be used for SORTWKxx. In the OP's
case, VIO=N is specified as an installation option so it is not allowed. I
think
this is one of those parms that can't be overridden at execution time.
Vernooij, CP - SPLXM
"Mark Zelden" <mark....@ZURICHNA.COM> wrote in message
news:<LISTSERV%20091105082...@BAMA.UA.EDU>...
> On Thu, 5 Nov 2009 11:11:56 +0100, Vernooij, CP - SPLXM
> <Kees.V...@KLM.COM> wrote:
>
> >DFSORT does not like SORTWK's on VIO. It tries to reallocate them to
> >real dasd, but apparantly you don't allow this.
> >
>
> Although not recommended, VIO can be used for SORTWKxx. In the OP's
> case, VIO=N is specified as an installation option so it is not
allowed. I
> think
> this is one of those parms that can't be overridden at execution time.
>
> Mark
> --
> Mark Zelden
Right, maybe I should elaborate my first (short) answer a little:
1. there is the DFSORT VIO=N intstallation paramemeter, that tells
DFSORT not to allow VIO for its SORTWK datasets, but to reallocate them
do dasd. It does this via the SORTDK ddname (not the D difference).
2. there are the ACS routines that should allow these SORTDK dataset to
dasd. Apparantely, in this case the ACS routines don't and DFSORT steps
out, because it can't get its workfiles on real dasd.
Kees.
**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286
**********************************************************************
----------------------------------------------------------------------
David Betten
that DFSORT is attempting to reallocate with UNIT=3390. Check to see what
your ACS routines assign when &UNIT is 3390.
Have a nice day,
Dave Betten
DFSORT Development, Performance Lead
IBM Corporation
email: bet...@us.ibm.com
1-301-240-3809
DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/
IBM Mainframe Discussion List <IBM-...@bama.ua.edu> wrote on 11/05/2009
04:41:30 AM:
> [image removed]
>
> VIO Error
>
> SrinivasG
>
> to:
>
> IBM-MAIN
>
> 11/05/2009 04:44 AM
>
> Sent by:
>
> IBM Mainframe Discussion List <IBM-...@bama.ua.edu>
>
> Please respond to IBM Mainframe Discussion List.
SrinivasG
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Vernooij, CP - SPLXM
Sent: Thursday, November 05, 2009 8:19 PM
To: IBM-...@bama.ua.edu
Subject: Re: VIO Error
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are not
to copy, disclose, or distribute this e-mail or its contents to any other person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
every reasonable precaution to minimize this risk, but is not liable for any damage
you may sustain as a result of any virus in this e-mail. You should carry out your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
----------------------------------------------------------------------
SrinivasG
We want to have a DNS Name for our new Z10 BC mainframe. Any suggestions?
Please also share your Mainframe names.
Regards,
_________________________________________________________
Srinivas G
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are not
to copy, disclose, or distribute this e-mail or its contents to any other person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
every reasonable precaution to minimize this risk, but is not liable for any damage
you may sustain as a result of any virus in this e-mail. You should carry out your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
----------------------------------------------------------------------
Sam Siegel
We use,
MVS1.xxx.net
MVS5.xxx.net
MVS7.xxx.net.
Where xxx is company name.
Keep the DNS name closely related or identical to the system name. It will
make your life easier.
These defined to the internal network (that is 10.x.x.x ip address) only.
They are not accessible from the outside world.
Regards,
Sam
McKown, John
> From: IBM Mainframe Discussion List
> Sent: Tuesday, November 10, 2009 2:51 AM
> To: IBM-...@bama.ua.edu
> Subject: Z10 BC DNS Name
>
> Hi,
>
> We want to have a DNS Name for our new Z10 BC mainframe. Any
> suggestions?
> Please also share your Mainframe names.
>
> Regards,
> _________________________________________________________
> Srinivas G
How about "old.reliable" ? <grin> We don't have our mainframe in our DNS. The DNS people don't want to be bothered with it.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Ted MacNEIL
Why is it up to them?
-
Too busy driving to stop for gas!
Maarten Slegtenhorst
where the host originated.
Most of our dns-names are nowadays something like
<servername>.qual1.qual2 or <printername>.qual1.qual2 where
qual1.qual2 is the common denominator.
So I requested my own domain mf.qual1.qual2 and gave every host a
dns-name:
<lpar>.mf.qual1.qual2
E.g lpar ab01:
Internal VIPA : ab01.mf.qual1.qual2 ( intranet )
External VIPA : ab01-ext.mf.qual1.qual2 ( internet )
The OSA's : ab01-osag1l.mf.qual1.qual2
Distributed VIPA's: ab01-dv1.mf.qual1.qual2
Dynamic XCF : ab01-dx.mf.qual1.qual2
We have our own subnets of 512 addresses/location.
Every ip-address we use, is in the dns.
This way we can keep track of the used ip-addresses.
Btw. We can update our own subnet in the dns-servers, which saves the
LAN-network people some work.
All the legacy dns-names are now aliases.
Somehow we can't seem te get rid of them :-/
The mainframenames are CPCxxy where xx is the two-letter location and y
is a number.
--
Maarten
-----Oorspronkelijk bericht-----
Van: IBM Mainframe Discussion List [mailto:IBM-...@BAMA.UA.EDU] Namens
McKown, John
Verzonden: dinsdag 10 november 2009 14:20
Aan: IBM-...@BAMA.UA.EDU
Onderwerp: Re: Z10 BC DNS Name
Administrative Services Group
HealthMarkets(r)
-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.
Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------
McKown, John
> From: IBM Mainframe Discussion List
> Sent: Tuesday, November 10, 2009 7:52 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: Z10 BC DNS Name
>
> >The DNS people don't want to be bothered with it.
>
> Why is it up to them?
>
> -
> Too busy driving to stop for gas!
Because nobody really cares much and isn't willing to "fight" with them about it. And, as with all IT right now, there just aren't enough people around to do the things that really need to be done, much less things that nobody cares about.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
Maarten Slegtenhorst
During a disaster recovery, we move the dns-name to the new ip-address,
so nobody has to change anything. ( except maybe for a local dns-flush )
What do you do when a DR occurs?
Do the users change the destination ip-address on their servers and
workstations?
--
Maarten
-----Oorspronkelijk bericht-----
Van: IBM Mainframe Discussion List [mailto:IBM-...@BAMA.UA.EDU] Namens
McKown, John
Verzonden: dinsdag 10 november 2009 14:20
Aan: IBM-...@BAMA.UA.EDU
Onderwerp: Re: Z10 BC DNS Name
How about "old.reliable" ? <grin> We don't have our mainframe in our
DNS. The DNS people don't want to be bothered with it.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.
Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------
----------------------------------------------------------------------
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Maarten Slegtenhorst
> Sent: Tuesday, November 10, 2009 8:10 AM
> To: IBM-...@bama.ua.edu
> Subject: No mainframe dns : Was: RE: Z10 BC DNS Name
>
> John,
>
> During a disaster recovery, we move the dns-name to the new
> ip-address,
> so nobody has to change anything. ( except maybe for a local
> dns-flush )
>
> What do you do when a DR occurs?
> Do the users change the destination ip-address on their servers and
> workstations?
>
> --
> Maarten
At DR, we insist that the MF continues to have the identical IP address. Well, we in Tech Services don't really care much. It is the Desktop Services and Server people who would be tasked with reconfiguring all the 3720 emulators and servers to point to the new IP address. Better to have one "open system" group insisting that another "open system" group do something. The MF does not have Internet visibility in either location.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
Pommier, Rex R.
just as a reminder to show the squatty boxes who's boss. :-)
Rex
>
> Hi,
>
> We want to have a DNS Name for our new Z10 BC mainframe. Any
> suggestions?
> Please also share your Mainframe names.
>
> Regards,
> _________________________________________________________
> Srinivas G
How about "old.reliable" ? <grin> We don't have our mainframe in our
DNS. The DNS people don't want to be bothered with it.
--
John McKown
Systems Engineer IV
IT
----------------------------------------------------------------------
Ted MacNEIL
The last shop I was in just used the 4-character system name.
Since the only people who had to know were TSO users, and they had to know the system they were signing onto, that sufficed.
-
Too busy driving to stop for gas!
----------------------------------------------------------------------
Chris Mason
A "mainframe" - by which you may mean a "Central Electronic Complex" (CEC)
or "Central Processing Complex" (CPC) or, in the approximate terminology of
casual conversation, a "footprint" - doesn't have a name. Neither does an
individual LPAR running in the CEC/CPC. Only IP *interfaces* have a name.
However, you may set up a name using a static flavour of Virtual IP address
(VIPA) and use that in order to represent a particular LPAR of a particular
CEC/CPC - see later.[1]
My approach does as follows:
- A name is for the benefit of clients
- Clients access server applications
- Server applications may be hosted on different LPARs on different CEC/CPCs
("mainframes") at different times
Therefore it's the server application to which a name should be assigned.
How is this done? Virtual IP addresses!
Specifically, because I indicated that server applications might be moved and
we don't want to bother clients with that, to them, trivial matter, we should
be using *dynamic* VIPAs for the purposes of referring to these server
applications.
If not now but in the future you may set up many instances of a server
application in order to support a service, you will be happy you decided to use
a dynamic VIPA because it can easily be converted into a distributed dynamic
VIPA. And still your clients will not be aware anything changed - except
perhaps that the responsiveness of the server application improved!
In fact, you could start today with static VIPAs and convert them to dynamic
VIPAs all without any disturbance of your unruffled clients.
The point behind all of this is *not* to tie your names to individual LPARs of a
CEC/CPC because it doesn't make sense - with one exception.
There can be some applications which indeed are tied to a particular LPAR of a
particular CEC/CPC. The example I always use - rather lazily since there may
well be others - any suggestions anyone? - is that of the SNMP agent.
For such applications you should use a static VIPA and you can regard such a
name as being intimately associated with the particular LPAR on a particular
CEC/CPC. The reason is that that association is implicit in the function the
application performs. This, incidentally, is my "see later".
The point here is that, having decided sensibly that your names will refer to
your server applications because that's what matters to those who actually
need to use names, you need to be sure you understand the nature of the
server application to which you are assigning a name. If it could move use a
dynamic VIPA. If it will never move use a static VIPA.
Having discovered that names belong to IP interfaces and not IP nodes
("mainframes" or specific LPARs defined on specific CEC/CPCs), is there any
purpose in assigning names to IP interfaces - or other IP entities? IMNSHO no!
If no client ever needs to refer to such an IP entity, why bother?
Actually, before deciding on that point, it's worth considering what function
names - as opposed to raw IP addresses - serve. Using names you can refer
to IP entities, principally interfaces (VIPAs are a way of making applications
look like interfaces), in a way which need not change when you redefine your
IP intranet in some way, for example, you decide that IPv4 is too restrictive
for you and you just have to convert to IPv6 to pick a case with maximum
attendant upheaval! If names would help you, use them; if not, don't. My
rather limited imagination can consider only that the multitude of clients need
protecting from changes to the identification of server application destinations.
But I'm willing to hear of other considerations ...
Incidentally, questions regarding the use of the IP component of
Communications Server are best posed in the following list:
For IBMTCP-L subscribe / signoff / archive access instructions, send email to
LIST...@VM.MARIST.EDU with the message: INFO IBMTCP-L
Chris Mason
[1] Honesty compels me to mention that, an individual instance of an IP node
such as the IP component of Communications Server, in principle has many
interfaces to each of which an IP address is assigned. If one were to set up a
name which referred to all of the addresses, one could claim that such a name
is associated with the IP node. Indeed, if a client's objective were to connect
to a server application running on that IP node, the logic employing the
gethostbyname() call, given just the one name, ought to try each of the
returned interface IP addresses in turn in order to try to connect to the
application. Thus, in effect, the name refers to the IP node. It's never that
simple!
On Tue, 10 Nov 2009 14:21:08 +0530, SrinivasG <SRIN...@INFOSYS.COM>
wrote:
>Hi,
>
>We want to have a DNS Name for our new Z10 BC mainframe. Any
suggestions?
>Please also share your Mainframe names.
>
>Regards,
>_________________________________________________________
>Srinivas G
----------------------------------------------------------------------
Chris Mason
> We don't have our mainframe in our DNS. The DNS people don't want to be
bothered with it.
And quite right they are too. Now *applications* would be a different matter.
Chris Mason
On Tue, 10 Nov 2009 07:20:11 -0600, McKown, John
<John....@HEALTHMARKETS.COM> wrote:
>> -----Original Message-----
>> From: IBM Mainframe Discussion List
>> [mailto:IBM-...@bama.ua.edu] On Behalf Of SrinivasG
>> Sent: Tuesday, November 10, 2009 2:51 AM
>> To: IBM-...@bama.ua.edu
>> Subject: Z10 BC DNS Name
>>
>> Hi,
>>
>> We want to have a DNS Name for our new Z10 BC mainframe. Any
>> suggestions?
>> Please also share your Mainframe names.
>>
>> Regards,
>> _________________________________________________________
>> Srinivas G
>
>How about "old.reliable" ? <grin> We don't have our mainframe in our DNS.
The DNS people don't want to be bothered with it.
>
>--
>John McKown
----------------------------------------------------------------------
Chris Mason
I don't believe name servers were designed for the purposes of "keeping track"
of intranet addresses.
Their primary purpose - and sole purpose until I am persuaded otherwise - is
to provide an indirect reference for people who need to specify destination
addresses so that, if the address changes, the name need not with all the
benefits that arrangement brings.
And the people most affected by this consideration are the multitude of
clients or client workstations.
Incidentally, as a committed VIPA user, I'm very surprised that you have
included the identification of the LPAR ("mf" presumably) in your naming
convention. Did nobody consider that LPAR Q might be a better place to run
the application one day that LPAR P?
I would also like to know what benefit you derive from assigning names to the
OSA and XCF interfaces - other than this odd address "book-keeping"! In
other words, are there anywhere any actual references to these names?
Chris Mason
>--
>Maarten
>
>-----Oorspronkelijk bericht-----
>Van: IBM Mainframe Discussion List [mailto:IBM-...@BAMA.UA.EDU] Namens
>McKown, John
>Verzonden: dinsdag 10 november 2009 14:20
>Aan: IBM-...@BAMA.UA.EDU
>Onderwerp: Re: Z10 BC DNS Name
>
>> -----Original Message-----
>> From: IBM Mainframe Discussion List
>> [mailto:IBM-...@bama.ua.edu] On Behalf Of SrinivasG
>> Sent: Tuesday, November 10, 2009 2:51 AM
>> To: IBM-...@bama.ua.edu
>> Subject: Z10 BC DNS Name
>>
>> Hi,
>>
>> We want to have a DNS Name for our new Z10 BC mainframe. Any
>> suggestions?
>> Please also share your Mainframe names.
>>
>> Regards,
>> _________________________________________________________
>> Srinivas G
>
>How about "old.reliable" ? <grin> We don't have our mainframe in our
>DNS. The DNS people don't want to be bothered with it.
>
>--
>John McKown
>Systems Engineer IV
>IT
>
>Administrative Services Group
>
>HealthMarkets(r)
>
>9151 Boulevard 26 * N. Richland Hills * TX 76010
>(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com
>* www.HealthMarkets.com
----------------------------------------------------------------------
Maarten Slegtenhorst
John wrote:
> At DR, we insist that the MF continues to have the identical IP
address.
Nice! I wish we had that, but, alas, it is not possible in our current
LAN-network.
Now we have to search for those who use an ip-address instead of a
dns-name,
because they have to change their settings in case of a DR.
It would save us a lot of trouble if we could use the same ip-address in
a disaster recovery.
--
Maarten
-----Oorspronkelijk bericht-----
Van: IBM Mainframe Discussion List [mailto:IBM-...@BAMA.UA.EDU] Namens
McKown, John
Verzonden: dinsdag 10 november 2009 15:17
Aan: IBM-...@BAMA.UA.EDU
Onderwerp: Re: No mainframe dns : Was: RE: Z10 BC DNS Name
Administrative Services Group
HealthMarkets(r)
-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.
Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------
----------------------------------------------------------------------
Maarten Slegtenhorst
First of all, a small correction on my earlier post.
Our distributed VIPA's have the naming convention:
ab-dv1.mf.qual1.qual2 and not ab01-dv1.mf.qual1.qual2
Static and dynamic VIPA's have the same naming convention.
--------
"mf" in the domain stands for "mainframe" ;)
All ip-addresses used by the lpar's are in the .mf.qual1.qual2 domain.
--------
>I would also like to know what benefit you derive from assigning names
>to the OSA and XCF interfaces - other than this odd address
"book-keeping"!
>In other words, are there anywhere any actual references to these
names?
No! We (VTAM-TCP/IP) are the only ones to use them.
The LAN network department ( who manages the dns ) requires that each
used address is registered in the dns-servers.
We don't mind because we just have to do a nslookup from a DOS-box to
see to which host an ip-address belongs.
--------
We have prepared for application instance vipa's in our naming
convention, but do not use them yet.
So for now everyone uses the static/dynamic/distributed vipa to
communicate with the host
--
Maarten
-----Oorspronkelijk bericht-----
Van: IBM Mainframe Discussion List [mailto:IBM-...@BAMA.UA.EDU] Namens
Chris Mason
Verzonden: dinsdag 10 november 2009 17:56
Maarten
Chris Mason
-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.
Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------
----------------------------------------------------------------------
Don
>> suggestions?
>> Please also share your Mainframe names.
>>
>> Regards,
>> _________________________________________________________
>> Srinivas G
I'd think that you would want to use a name that reflects whatever standards
you already have for other servers on the network.
On my local LAN the servers typically have more than one DNS name. One is
used to point to the physical device (for those clients that really *do*
want to connect to a specific box. Other DNS names are used to identify
specific applications without referring to a specific piece of hardware.
For example there might be an ftp.mydomain.com and a
"srv12345.mydomain.com". If I need the FTP server I use the ftp name, if I
need to run a remote console I use the srv12345 name. Multi-NIC servers
usually have one IP assigned to management, so that's the interface that
gets the "srv12345" name.
--
be seeing you ... Don
Don Melton, Sr. Consultant, Vatic Technologies Limited
P S
Maarten.Sl...@mail.ing.nl> wrote:
> Nice! I wish we had that, but, alas, it is not possible in our current
> LAN-network.
> Now we have to search for those who use an ip-address instead of a
> dns-name,
> because they have to change their settings in case of a DR.
> It would save us a lot of trouble if we could use the same ip-address in
> a disaster recovery.
>
Perhaps you can share why it's not possible? Just curious.
Paul Gilmartin
>On Wed, Nov 11, 2009 at 12:37 AM, Maarten Slegtenhorst <
>Maarten.Sl...@mail.ing.nl> wrote:
>
>> Nice! I wish we had that, but, alas, it is not possible in our current
>> LAN-network.
>> Now we have to search for those who use an ip-address instead of a `
>> dns-name,
>> because they have to change their settings in case of a DR.
>> It would save us a lot of trouble if we could use the same ip-address in
>> a disaster recovery.
>>
>Perhaps you can share why it's not possible? Just curious.
>
And why does anyone use an IP address rather than a domain name?
As long as you nurture that behavior, they won't get better.
-- gil
Maarten Slegtenhorst
We are dead against using ip-addresses!
Somewhere in the mists of time there was apparently once a problem with
the dns-servers.
Typical user-behaviour is to remember this for all eternity and to try
to
use ip-addresses or hosts-files because the dns-servers are not
dependable :-/
Luckily most people nowadays use dns-names.
To find the others, I had to define another vipa and move the dns-name
to this vipa.
Everyone who made a connection to the first vipa uses ip-addresses,
while the dns-users automatically switched to the new vipa.
So, we are hunting down the ip-address users and force them to better
their lives, but it's slow going.
--
Maarten
-----Oorspronkelijk bericht-----
Van: IBM Mainframe Discussion List [mailto:IBM-...@BAMA.UA.EDU] Namens
Paul Gilmartin
Verzonden: woensdag 11 november 2009 15:54
Aan: IBM-...@BAMA.UA.EDU
Onderwerp: Re: No mainframe dns : Was: RE: Z10 BC DNS Name
On Wed, 11 Nov 2009 09:07:56 -0500, P S wrote:
-- gil
-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.
Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------
----------------------------------------------------------------------
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Paul Gilmartin
> Sent: Wednesday, November 11, 2009 8:54 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: No mainframe dns : Was: RE: Z10 BC DNS Name
<snip>
> >
> And why does anyone use an IP address rather than a domain name?
> As long as you nurture that behavior, they won't get better.
>
> -- gil
"Because it's not a Windows box." is the usual reason for the "open" systems people to refuse to do anything WRT the z/OS system. They apparently think that z/OS contains many Windows viri that they must beware of. Or something like that.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
Paul Gilmartin
>
>"Because it's not a Windows box." is the usual reason for the "open" systems people to refuse to do anything WRT the z/OS system. They apparently think that z/OS contains many Windows viri that they must beware of. Or something like that.
>
Consider the questions about connectivity regularly asked on this list
that could never arise for connectivity among Windows, Linux, and
Solaris platforms.
- gil
Chris Mason
So we warn Srinivas that he may be confronted with a consultant who claims
that it is "good practice" to log each IP interface address[1] in the name
server - for want of work for the network folk in the installation! I guess this is
what happened to your "LAN network department".
My approach to the required function of IP address book-keeping would be to
have one recognised person - with a deputy - who is responsible. He or she
would then probably keep a spreadsheet which logged all IP addresses - and
dismissal awaits anyone who tries to define an IP address which has not been
approved by this authorised person first - probably you'd better insist that he
or she sends an confirmation e-mail which is promptly "backed-up"!
Obviously I had imagined that "mf" was substituted with something just as
clearly you intended "qual1" and "qual2" were.
I guess putting "mf" in the name is fine - just so long as the application to
which the name refers doesn't change platform architecture at some time in
its life - say, from what you and I know to be a reliable platform to a
thoroughly shaky one - not so unlikely a possibility as we hear of examples
from time to time.
Chris Mason
[1] If the consultant is sufficiently long in the tooth to know about RFC 952,
he or she will probably insist that all *networks* are similarly logged - and
named!
>--
>Maarten
>
>-----Oorspronkelijk bericht-----
>>--
>>Maarten
>>
>>-----Oorspronkelijk bericht-----
>>Van: IBM Mainframe Discussion List [mailto:IBM-...@BAMA.UA.EDU]
Namens
>
>>McKown, John
>>Verzonden: dinsdag 10 november 2009 14:20
>>Aan: IBM-...@BAMA.UA.EDU
>>Onderwerp: Re: Z10 BC DNS Name
>>
>>> -----Original Message-----
>>> From: IBM Mainframe Discussion List
>>> [mailto:IBM-...@bama.ua.edu] On Behalf Of SrinivasG
>>> Sent: Tuesday, November 10, 2009 2:51 AM
>>> To: IBM-...@bama.ua.edu
>>> Subject: Z10 BC DNS Name
>>>
>>> Hi,
>>>
>>> We want to have a DNS Name for our new Z10 BC mainframe. Any
>>> suggestions?
>>> Please also share your Mainframe names.
>>>
>>> Regards,
>>> _________________________________________________________
>>> Srinivas G
>>
>>How about "old.reliable" ? <grin> We don't have our mainframe in our
>>DNS. The DNS people don't want to be bothered with it.
>>
>>--
>>John McKown
>>Systems Engineer IV
>>IT
>>
>>Administrative Services Group
>>
>>HealthMarkets(r)
>>
>>9151 Boulevard 26 * N. Richland Hills * TX 76010
>>(817) 255-3225 phone * (817)-961-6183 cell
>john....@healthmarkets.com
>>* www.HealthMarkets.com
----------------------------------------------------------------------
P S
> On Wed, 11 Nov 2009 09:31:32 -0600, McKown, John wrote:
> >
> >"Because it's not a Windows box." is the usual reason for the "open"
> systems people to refuse to do anything WRT the z/OS system. They apparently
> think that z/OS contains many Windows viri that they must beware of. Or
> something like that.
> >
> It does impose some peculiar support (at least help desk) requirements.
> Consider the questions about connectivity regularly asked on this list
> that could never arise for connectivity among Windows, Linux, and
> Solaris platforms.
>
Use SSL everywhere, that'll fix 'em ...
Chris Mason
Google Groups. I noticed text in a post supposedly in this thread which did
*not* appear in the archives. This happens from time to time and, if the
subject of the thread is of interest, I repost so that everyone can benefit
from the contribution - in one way or another!
This post looks like it should be shown since it supports in a practical context
the theoretical approach I gave in my initial response.
<quote verbatim>
I'd think that you would want to use a name that reflects whatever standards
you already have for other servers on the network.
On my local LAN the servers typically have more than one DNS name. One is
used to point to the physical device (for those clients that really *do* want
to connect to a specific box. Other DNS names are used to identify specific
applications without referring to a specific piece of hardware. For example
there might be an ftp.mydomain.com and a "srv12345.mydomain.com". If I
need the FTP server I use the ftp name, if I need to run a remote console I
use the srv12345 name. Multi-NIC servers usually have one IP assigned to
management, so that's the interface that gets the "srv12345" name.
</quote verbatim>
The contributor goes by the name of Don with an - unhelpful for the purposes
of identification - e-mail address. He is otherwise an infrequent contributor to
a "group" which has something to do with "apple". Perhaps, with such useful
contributions to make, he may care to subscribe to IBM-MAIN and ensure his
contributions can be seen by *all* subscribers.
It seems, incidentally, that whatever the software is that runs on Don's
servers - I could guess some software from Apple, it does not have the option
to assign IP addresses independent of interfaces - virtual IP addresses
(VIPAs) in the z/OS Communications Server IP component world - which is
ideally what he would use for IP addresses to identify server applications to
clients - or - to identify the IP node itself.
-
I was interested to check all posts supposedly in this thread as the thread is
identified in "Google Groups":
http://groups.google.com/group/bit.listserv.ibm-main/t/92eaeef8d37e6ff9?
hl=en
in case there were other "lost contributions" such as Don's.
Surprisingly the thread is initially identified as "Health Checker - LNKLST
Dataset" from 4/11 - that'll be 11/4 in some quarters! - and, surprisingly, there
are all of 35 posts!
Then, on 5/11 (11/5), "Srinivas G" changed the thread to "VIO Error". I'm not
quite sure how this is done but I suspect it involves pretending that you are
responding to an existing post, in this case "Health Checker - LNKLST Dataset"
and then changing the subject line in order to initiate a new thread. It seems
that there is some internal linkage which at least "Google Groups" tries to use
in order to maintain a thread - and so get thoroughly confused - except that
it can identify the subject change.
The thread then reverted to "Health Checker - LNKLST Datasets" on the same
day courtesy of the original poster and then jumped back again to "VIO Error"
where it stayed until, after a 5 day gap on 10/11 (11/10) "Srinivas G" kindly
thanked all who had assisted him - I'm guessing, it could be "her" - with the
topic of "VIO Error".
And so on the same day probably ostensibly responding to perhaps his/her
own "Thank You" post, "Srinivas G" initiates the thread I thought I was dealing
with all along.
We stay with "Z10 BC DNS Name" until a rather more legitimate change of
subject is introduced as follows:
"Discussion subject changed to "No mainframe dns : Was: RE: Z10 BC DNS
Name" by Maarten Slegtenhorst".
Subsequently we have a slightly irritating alternation but - either I don't know
how so to manipulate Google Groups that I could get a more logical hierarchy
of threads - or - Goggle Groups does not offer any such option.
Chris Mason