Discussion:
SYSTEM NETID and CPUIDs
(too old to reply)
Judson West
2006-02-21 17:25:03 UTC
Permalink
I have never had a CPUID that began with anything other than
a 0 or 1. We are getting a new z890 with a CPUID of Exxxx.
The CPUID of our current z800 is 1xxxx. In the SYSTEM NETID
file, the format of the CPUID field is six HEX digits with
the first one being the LPAR number. When I Q CPUID on my
current system, it responds back with FF00xxxx... My point
is that the 1 does not show up as part of the current Q
CPUID response. Can I expect that the E of my new CPUID will
not show up either?

-----------------
Judson West
Teradata, a division of NCR Corporation
Judson West
2006-02-21 19:11:18 UTC
Permalink
"New Way" is defined as what? New z9, new z/VM, both, or
neither.

-----------------
Judson West
Teradata, a division of NCR Corporation

-----Original Message-----
From: VM/ESA and z/VM Discussions
[mailto:VMESA-***@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark
Sent: Tuesday, February 21, 2006 11:05 AM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: SYSTEM NETID and CPUIDs

Oh, one more thing about the New Way of CPU IDs and SYSTEM
NETID: You no
longer need to worry about which CPU you IPLed or the
quasi-variable LPAR
number. That means you only need a single SYSTEM NETID
entry per VM
system, rather than one entry per CPU per VM system.

Alan Altmark
Sr. Software Engineer
IBM z/VM Development
David Boyes
2006-02-22 01:35:35 UTC
Permalink
> CMS doesn't care what STIDP returns, it just uses it to look
> up entries in SYSTEM NETID. If you don't have RSCS, then you
> can have a SYSTEM NETID with just a comment line as CMS will
> use the CP system id as the default node id. I.e. By
> default, IDENTIFY will return <userid> AT <systemid> VIA *.

Which will cause some *very* strange behavior if you need to use LPR or
PPS for printing. That * for RSCSID gets PPS very confused -- it'll
transfer anything you try to print with PPS or LPR fn ft fm (ASYNC back
to your reader without explanation until you set the nodeid properly. .

Doesn't everyone have at least the LPR/LPD functions of RSCS? If so,
then setting the default SYSTEM NETID to have a RSCSid of RSCS should be
correct (and cause PPS and friends to work out of the box).
David Boyes
2006-02-22 12:39:02 UTC
Permalink
> > Doesn't everyone have at least the LPR/LPD functions of
> RSCS? If so,
> > then setting the default SYSTEM NETID to have a RSCSid of
> RSCS should
> > be correct (and cause PPS and friends to work out of the box).
>
> Sorry, I shouldn't have used the word "have". Everyone has
> RSCS now and can use it for LPR and LPD for free. I should
> have said "use".

In either case, doesn't it make sense to have IDENTIFY return a default
RSCSid of RSCS (if there is no SYSTEM NETID entry specifying otherwise)
instead of *, since everyone *does* have RSCS these days, and (unless
you know what you're doing and have deliberately changed the id) it's
always installed as userid RSCS?

It does no harm, and strikes me as something that is in the category of
picking sensible defaults (and in at least one case, a default that
avoids a problem and makes it easier to exploit useful function).

-- db
Rob van der Heij
2006-02-22 13:43:57 UTC
Permalink
On 2/22/06, Alan Altmark <***@us.ibm.com> wrote:

> Hey! I know! We'll do installation SYSPROF exits at the same time so you
> have a place to issue said SET commands! Yeah, that's the ticket! Some
> day... We've got round tuits on backorder. :-)

This sounds like accepting the requirement to page back through an
open console log, and respond to that by giving developers Fullscreen
CMS. I am certain there will be more important things to be done with
spare development resources.

PS I was waiting for you to dream up the things that you believe one
would want to do in the PROFILE EXEC, code those in the SYSPROF using
some weird scheme with NAMES files, and then tell us it is not allowed
anymore to modify your own PROFILE EXEC.

Rob
David Boyes
2006-02-22 16:52:01 UTC
Permalink
> It's been on my mind for some time to get rid of SYSTEM NETID
> anyway. One or two new SET commands, with defaults of
> <systemid> and RSCS, and all will be fine.

Until then, it would probably be good to put the step that configures
SYSTEM NETID back into the install docs so that basic stuff doesn't
misbehave in inscrutable ways. That step seems to have disappeared
somewhere along the way. I haven't found where that step moved to in the
4.4 and later docs, but it's no longer in CP planning and admin or the
install guide. I haven't sent in a RCF because I haven't found which
manual it's in now...*sigh*.

> Hey! I know! We'll do installation SYSPROF exits at the same
> time so you have a place to issue said SET commands! Yeah,
> that's the ticket! Some day... We've got round tuits on
> backorder. :-)

Plenty of 'em here. You know how to get them.

-- db
O'Brien, Dennis L
2006-02-22 20:11:30 UTC
Permalink
If you're going to change the default of IDENTIFY, I'd rather it default
to the CP node name (System_Identifier_Default from SYSTEM CONFIG) if it
doesn't find a match in SYSTEM NETID. Allowing wildcards for CPUID in
SYSTEM NETID would also be handy.


Dennis O'Brien

"Of all tyrannies, a tyranny exercised for the good of its victims may
be the most oppressive. It may be better to live under robber barons
than omnipotent moral busybodies. The robber baron's cruelty may
sometimes sleep, his cupidity may at some point be satiated; but those
who torment us for our own good will torment us without end, for they do
so with the approval of their own conscience."
-- C.S. Lewis

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On
Behalf Of David Boyes
Sent: Wednesday, February 22, 2006 04:39
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: SYSTEM NETID and CPUIDs


> > Doesn't everyone have at least the LPR/LPD functions of
> RSCS? If so,
> > then setting the default SYSTEM NETID to have a RSCSid of
> RSCS should
> > be correct (and cause PPS and friends to work out of the box).
>
> Sorry, I shouldn't have used the word "have". Everyone has RSCS now
> and can use it for LPR and LPD for free. I should have said "use".

In either case, doesn't it make sense to have IDENTIFY return a default
RSCSid of RSCS (if there is no SYSTEM NETID entry specifying otherwise)
instead of *, since everyone *does* have RSCS these days, and (unless
you know what you're doing and have deliberately changed the id) it's
always installed as userid RSCS?

It does no harm, and strikes me as something that is in the category of
picking sensible defaults (and in at least one case, a default that
avoids a problem and makes it easier to exploit useful function).

-- db
David Boyes
2006-02-22 21:02:57 UTC
Permalink
> I already posed the design point that it would default to AT
> <system_id> VIA RSCS. IDENTIFY already defaults to AT
> <system_id> VIA *.
>
> Is it sufficient to just change the default to VIA RSCS and
> still require the use of SYSTEM NETID if you want something
> else?

Works for me. That would fix PPS and LPR, and would be a Reasonable
Default (minimum surprise factor - IMHO).

> Do I really *need* SET commands to change these puppies?

I'd say not. The RSCSid field is not something you change unless you
know why you're making the change, and if you need to change it, you
know why (and you've already suffered through changing GCS and a few
other painful experiences). If you added a RSCS test id (lets say
RSCSTEST) to the default GCS configuration, that would remove almost all
the reasons to ever change SYSTEM NETID (if you make the proposed change
to default the RSCSid field to RSCS).

You do need to put the instructions back in the CP planning and admin
manual on *how* to change SYSTEM NETID, though. It's an integral part of
getting the system configured, even for a system that's only going to
support Linux -- at some point, you're gonna need to print something
from CMS, and odds are, that will be on a networked LAN printer, not a
channel-attached device.

It's also probably time to move PPS EXEC to MAINT 190, but that's a
different discussion.

-- db
Huegel, Thomas
2006-02-22 21:23:26 UTC
Permalink
What might be a nice default (this would have been great for me when I
worked in a lab with 20+ VM images that were constantly moving to different
processors) would be to be able to set the RSCS default id based upon the
SYSTEM_ID. That way no matter where I IPL'd my abcVM'x01' system I would get
RSCS'x01' as the RSCS id. Ofcourse I'd want to be able to set and over ride
the default. Maybe put the default in the SYSTEM CONFIG and the over ride in
the SYSTEM NETID?

Tom

-----Original Message-----
From: David Boyes [mailto:***@sinenomine.net]
Sent: Wednesday, February 22, 2006 3:03 PM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: SYSTEM NETID and CPUIDs


> I already posed the design point that it would default to AT
> <system_id> VIA RSCS. IDENTIFY already defaults to AT
> <system_id> VIA *.
>
> Is it sufficient to just change the default to VIA RSCS and
> still require the use of SYSTEM NETID if you want something
> else?

Works for me. That would fix PPS and LPR, and would be a Reasonable
Default (minimum surprise factor - IMHO).

> Do I really *need* SET commands to change these puppies?

I'd say not. The RSCSid field is not something you change unless you
know why you're making the change, and if you need to change it, you
know why (and you've already suffered through changing GCS and a few
other painful experiences). If you added a RSCS test id (lets say
RSCSTEST) to the default GCS configuration, that would remove almost all
the reasons to ever change SYSTEM NETID (if you make the proposed change
to default the RSCSid field to RSCS).

You do need to put the instructions back in the CP planning and admin
manual on *how* to change SYSTEM NETID, though. It's an integral part of
getting the system configured, even for a system that's only going to
support Linux -- at some point, you're gonna need to print something
from CMS, and odds are, that will be on a networked LAN printer, not a
channel-attached device.

It's also probably time to move PPS EXEC to MAINT 190, but that's a
different discussion.

-- db


__________________________________________________________________
<< ella for Spam Control >> has removed VSE-List messages and set aside
VM-List for me
You can use it too - and it's FREE! http://www.ellaforspam.com
O'Brien, Dennis L
2006-02-22 21:57:31 UTC
Permalink
Sorry,
I was misremembering what IDENTIFY returned when it didn't find a match
in SYSTEM NETID.


Dennis

"Of all tyrannies, a tyranny exercised for the good of its victims may
be the most oppressive. It may be better to live under robber barons
than omnipotent moral busybodies. The robber baron's cruelty may
sometimes sleep, his cupidity may at some point be satiated; but those
who torment us for our own good will torment us without end, for they do
so with the approval of their own conscience."
-- C.S. Lewis

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On
Behalf Of Alan Altmark
Sent: Wednesday, February 22, 2006 12:36
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: SYSTEM NETID and CPUIDs

On Wednesday, 02/22/2006 at 12:11 PST, "O'Brien, Dennis L"
<Dennis.L.O'***@bankofamerica.com> wrote:
> If you're going to change the default of IDENTIFY, I'd rather it
> default to the CP node name (System_Identifier_Default from SYSTEM
> CONFIG) if it doesn't find a match in SYSTEM NETID. Allowing
> wildcards for CPUID in SYSTEM NETID would also be handy.

I already posed the design point that it would default to AT <system_id>
VIA RSCS. IDENTIFY already defaults to AT <system_id> VIA *.

Is it sufficient to just change the default to VIA RSCS and still
require the use of SYSTEM NETID if you want something else? Do I really
*need* SET commands to change these puppies?

Alan Altmark
z/VM Development
IBM Endicott
David Boyes
2006-02-22 22:02:19 UTC
Permalink
What might be a nice default (this would have been great for me
when I worked in a lab with 20+ VM images that were constantly moving to
different processors) would be to be able to set the RSCS default id
based upon the SYSTEM_ID. That way no matter where I IPL'd my abcVM'x01'
system I would get RSCS'x01' as the RSCS id. Ofcourse I'd want to be
able to set and over ride the default. Maybe put the default in the
SYSTEM CONFIG and the over ride in the SYSTEM NETID?

I think you can do this now, if you have a comprehensive list of the
CPUID possibilities -- remember CPUID up to recently was a combination
of the processor id and the LPAR number (that discussion is what brought
all this on, I think -- this changes with a z9). In a situation where I
had about a dozen different places (processors and LPARs) where a VM
system could be IPLed, I just had a really long SYSTEM NETID with all
the possibilities listed. So long as one CPUID matched, I got the right
configuration of nodeid and RSCSid, otherwise I got DISASTER and RSCS (I
think if you leave off the CPUID, that's the default if nothing else
matches).

Was a PITA to maintain the list, but could be done easily with an exec.
.

-- db
Huegel, Thomas
2006-02-22 22:15:24 UTC
Permalink
Yes that is what I had to do 'maintain' large SYSTEM NETID files but with
processors coming and going on an almost daily basis (I worked for a major
computer manufacturer) and when you consider the z9 can have 60 lpars and we
ran about 12-15 mainframes in this lab alone the SYSTEM NETID was a major
PITA.

[Huegel, Thomas] -----Original Message-----
From: David Boyes [mailto:***@sinenomine.net]
Sent: Wednesday, February 22, 2006 4:02 PM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: SYSTEM NETID and CPUIDs





What might be a nice default (this would have been great for me when I
worked in a lab with 20+ VM images that were constantly moving to different
processors) would be to be able to set the RSCS default id based upon the
SYSTEM_ID. That way no matter where I IPL'd my abcVM'x01' system I would get
RSCS'x01' as the RSCS id. Ofcourse I'd want to be able to set and over ride
the default. Maybe put the default in the SYSTEM CONFIG and the over ride in
the SYSTEM NETID?

I think you can do this now, if you have a comprehensive list of the CPUID
possibilities -- remember CPUID up to recently was a combination of the
processor id and the LPAR number (that discussion is what brought all this
on, I think -- this changes with a z9). In a situation where I had about a
dozen different places (processors and LPARs) where a VM system could be
IPLed, I just had a really long SYSTEM NETID with all the possibilities
listed. So long as one CPUID matched, I got the right configuration of
nodeid and RSCSid, otherwise I got DISASTER and RSCS (I think if you leave
off the CPUID, that's the default if nothing else matches).

Was a PITA to maintain the list, but could be done easily with an exec. .

-- db



_____

<< ella for Spam Control >> has removed 2231 VSE-List messages and set aside
1264 VM-List for me
You can use it too - and it's FREE! www.ellaforspam.com
<http://www.ellaforspam.com>
Judson West
2006-02-22 22:36:58 UTC
Permalink
I would prefer to have to update this information in one
place a'la SYSTEM CONFIG. And since the default location for
SYSTEM NETID is the S-disk, changing this file also involves
resaving CMS. Which for many NOOBE's is pretty daunting.

-----------------
Judson West
Teradata, a division of NCR Corporation


-----Original Message-----
From: VM/ESA and z/VM Discussions
[mailto:VMESA-***@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark
Sent: Wednesday, February 22, 2006 2:32 PM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: SYSTEM NETID and CPUIDs

On Wednesday, 02/22/2006 at 03:23 CST, "Huegel, Thomas"
<***@Kable.com> wrote:
> What might be a nice default (this would have been great
for me when I
worked
> in a lab with 20+ VM images that were constantly moving to
different
> processors) would be to be able to set the RSCS default id
based upon
the
> SYSTEM_ID. That way no matter where I IPL'd my abcVM'x01'
system I would
get
> RSCS'x01' as the RSCS id. Ofcourse I'd want to be able to
set and over
ride the
> default. Maybe put the default in the SYSTEM CONFIG and
the over ride in
the
> SYSTEM NETID?

I, too, had considered some specification of system_id in
the SYSTEM NETID
so that CPU IDs need only be in SYSTEM CONFIG.

Alan Altmark
z/VM Development
IBM Endicott
Jeff Gribbin, EDS
2006-02-23 10:58:43 UTC
Permalink
A small detail about using CPUID rather than SYSTEMID which would have
mattered to me in a previous incarnation ...

The CPUID in question is the VIRTUAL CPUID.

Once upon a time I was required to provide the capability to flip between
default RSCS's with a user command. That is, sometimes you'd specify to
reach another system via RSCS-1 but at other times you'd say to reach it
via RSCS-2 and, having specified it, expect commands such as SENDFILE to
behave accordingly.

I implemented this capability by having two entries in SYSTEM NETID and
issuing SET (virtual) CPUID commands inside the CMS machines to flip
between RSCS targets. (This is simplified - there are a few flaming hoops
involved if you want to try if for yourself.)

My point is that the current criterion (cpuid) is dynamically variable
whereas the proposed criterion (SYSTEMID) is fixed. Once upon a time this
would have been an issue for me. Nowadays, for me, the convenience and
simplicity of SYSTEMID would win hands-down - but it DOES imply a tradeoff
and, if implemented, may irritate one or two remaining eccentrics such as
I used to be.

Regards
Jeff
A. Harry Williams
2006-02-23 12:18:07 UTC
Permalink
On Thu, 23 Feb 2006 04:58:43 -0600 Jeff Gribbin, EDS said:
>A small detail about using CPUID rather than SYSTEMID which would have
>mattered to me in a previous incarnation ...
>The CPUID in question is the VIRTUAL CPUID.
>Once upon a time I was required to provide the capability to flip between
>default RSCS's with a user command. That is, sometimes you'd specify to
>reach another system via RSCS-1 but at other times you'd say to reach it
>via RSCS-2 and, having specified it, expect commands such as SENDFILE to
>behave accordingly.
>I implemented this capability by having two entries in SYSTEM NETID and
>issuing SET (virtual) CPUID commands inside the CMS machines to flip
>between RSCS targets. (This is simplified - there are a few flaming hoops
>involved if you want to try if for yourself.)
>My point is that the current criterion (cpuid) is dynamically variable
>whereas the proposed criterion (SYSTEMID) is fixed. Once upon a time this
>would have been an issue for me. Nowadays, for me, the convenience and
>simplicity of SYSTEMID would win hands-down - but it DOES imply a tradeoff
>and, if implemented, may irritate one or two remaining eccentrics such as
>I used to be.

which is also used by the TCPIP DATA file to select labeled parameters.

>Regards
>Jeff
Dieltiens Geert
2006-02-23 14:36:29 UTC
Permalink
Wouldn't it be great if System_identifier didn't have to be based on the
CPU-id and LPAR-number. Why not provide a way to specify a
System_identifier_default in the LPAR-definitions on the HMC, or via
SAPL? Then, if you don't override it in the SYSTEM CONFIG, that will be
the System_Identifier that VM will use.

That way you could set the System_identifier value even before VM starts
up. And then, if RSCS, TCP, etc, would all use the System_identifier
instead of SYSTEM NETID, then you wouldn't need to worry about CPU-ids
anymore when you move to another CPU for whatever reason (DRP, new
hardware, another LPAR,...).

Just my 2 eurocents.

Geert.

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On
Behalf Of Alan Altmark
Sent: donderdag 23 februari 2006 15:02
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: SYSTEM NETID and CPUIDs

On Thursday, 02/23/2006 at 04:58 CST, "Jeff Gribbin, EDS"
<***@EDS.COM> wrote:
> My point is that the current criterion (cpuid) is dynamically variable
> whereas the proposed criterion (SYSTEMID) is fixed. Once upon a time
this
> would have been an issue for me. Nowadays, for me, the convenience and
> simplicity of SYSTEMID would win hands-down - but it DOES imply a
tradeoff
> and, if implemented, may irritate one or two remaining eccentrics such

as
> I used to be.

I do not propose to eliminate the current capabilities of "{nodeid,
rscsid} = f(cpuid)". But, rather, to add "{nodeid, rscsid} =
f(systemid)"
and a default of "{nodeid, rscsid} = {systemid, RSCS}".

And maybe, just maybe, we could have SET SYSTEMID just as we do SET
CPUID,
eh? How many times have people requested to be able to change the
systemid seen in the lower right-hand corner? :-)

But the real objective is to (a) not require any configuration of SYSTEM

NETID where none is needed, and (b) eliminate one of the annoying
pain-points during migrations. It doesn't necessarily mean making the
ability to change your nodeid and rscsid to something other than the
default any easier. (But it would be nice.)

Alan Altmark
z/VM Development
IBM Endicott
DISCLAIMER

This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity
to whom they are addressed. If you have received this email
in error please notify ***@vanbreda.be
This footnote also confirms that this email has been checked
for the presence of viruses.

Informatica J.Van Breda & Co NV BTW BE 0427 908 174
Rod
2006-02-23 14:53:12 UTC
Permalink
Geert wrote:

> Wouldn't it be great if System_identifier didn't have to be
> based on the CPU-id and LPAR-number. Why not provide
> a way to specify a System_identifier_default in the
> LPAR-definitions on the HMC, or via
> SAPL? Then, if you don't override it in the SYSTEM
> CONFIG, that will be
> the System_Identifier that VM will use.

Seems neat.

> That way you could set the System_identifier value even
> before VM starts up. And then, if RSCS, TCP, etc, would
> all use the System_identifier instead of SYSTEM NETID,
> then you wouldn't need to worry about CPU-ids
> anymore when you move to another CPU for
> whatever reason (DRP, new hardware, another LPAR,...).

Which is fine if you only have one instance of these
machines. When you get into multiple instances and
"logical VM systems" (to use a phrase I heard a lot) then
you need to have some way of getting the user
identified to the right set of machines when he/she logs on.

--
Rod
David Boyes
2006-02-23 21:13:39 UTC
Permalink
> I do not propose to eliminate the current capabilities of
> "{nodeid, rscsid} = f(cpuid)". But, rather, to add "{nodeid,
> rscsid} = f(systemid)"
> and a default of "{nodeid, rscsid} = {systemid, RSCS}".

So moved. Mr. Speaker, I call the question.


-- db
Huegel, Thomas
2006-02-23 21:37:05 UTC
Permalink
In the mean time it would be nice to get the TERMID from the IDENTIFY
command similiar to QUERY NAMES.

-----Original Message-----
From: Alan Altmark [mailto:***@us.ibm.com]
Sent: Thursday, February 23, 2006 3:34 PM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: SYSTEM NETID and CPUIDs


On Thursday, 02/23/2006 at 05:42 CET, Kris Buelens
<***@be.ibm.com> wrote:
> Since the move of 9672 to z9, my customer's VM systems share the machine
> with z/OS (and they create the IOCP).
> When we IPL, we get:
> HCPZPQ6816E Dynamic I/O changes are not allowed because the
> configuration token is not a valid VM token
> As a consequence we can no longer use Q LPAR as it says:
> No LPAR data is available
> This is in z/VM 4.4; will this change with z/VM 5.2 ?

Drats. (sigh) No. QUERY LPAR is dependent on information available to CP
only when CP can perform dynamic I/O changes. That's part of the
architecture, not something CP controls.

Alan Altmark
z/VM Development
IBM Endicott


__________________________________________________________________
<< ella for Spam Control >> has removed VSE-List messages and set aside
VM-List for me
You can use it too - and it's FREE! http://www.ellaforspam.com
Thomas Kern
2006-02-23 22:40:09 UTC
Permalink
If you do consider a 'SET SYSTEMID' command, please have both a virtual and a
real version of the command so that an authorized user can reset the
system-wide systemid and a general user can reset their own systemid for their
own purposes.

/Tom Kern

--- Alan Altmark <***@us.ibm.com> wrote:
> ...snipped...
> I do not propose to eliminate the current capabilities of "{nodeid,
> rscsid} = f(cpuid)". But, rather, to add "{nodeid, rscsid} = f(systemid)"
> and a default of "{nodeid, rscsid} = {systemid, RSCS}".
>
> And maybe, just maybe, we could have SET SYSTEMID just as we do SET CPUID,
> eh? How many times have people requested to be able to change the
> systemid seen in the lower right-hand corner? :-)
>
> But the real objective is to (a) not require any configuration of SYSTEM
> NETID where none is needed, and (b) eliminate one of the annoying
> pain-points during migrations. It doesn't necessarily mean making the
> ability to change your nodeid and rscsid to something other than the
> default any easier. (But it would be nice.)


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Jeff Gribbin, EDS
2006-02-24 08:45:51 UTC
Permalink
Alan,
Additional function (as opposed to replacement function) should cause very
few problems - it would certainly get my vote.

Browsing the later discussion I think I can summarise the needs that would
perhaps get a chance of being addressed with the likely available
resources as:

IDENTIFY checks SYSTEM NETID and, if it finds a match, uses it.

SYSTEM NETID syntax is extended to include keying on SYSTEMID (as in
response from QUERY USERID) as well as on virtual CPUID.

Somebody defines what happens if there are, "duplicates" in SYSTEM NETID.
(If it were me I'd just take first match found, scanning file from the
top, but YMMV.)

If there's no match in SYSTEM NETID, IDENTIFY uses a set of defaults.

The IBM-supplied default uses, "RSCS" as the, "SPOOL Networking Userid".

There is some way (probably SYSTEM NETID) of changing the, "Default
default".

Asterisk remains valid as a target userid.

------------------------------------------

The above would, I believe, achieve the goals of:
Making IDENTIFY use RSCS in the system-as-shipped (our primary goal).
Allowing current as-shipped behaviour (asterisk) to be restored in a
simple manner.
Making IDENTIFY use either SYSTEMID or CPUID as deciding criterion.

My prime assumption is that anybody who wants to restore the default of
asterisk or change the name of the RSCS userid is unlikely to be fazed by
the challenges associated with updating a file on MAINT's 0190.

(Why is it always the little things that generate the big discussions!)

Regards
Jeff
Rob van der Heij
2006-02-24 09:01:50 UTC
Permalink
On 2/24/06, Harding, Mike <***@eds.com> wrote:
> While I understand the arguments, I prefer the old "*" for the default net machine. I'm involved with a number of images which use a different userid for rscs. A "sp prt RSCS" on those images results in an error and the printer remaining routed "for <userid>".

And worse, SPOOL CONS RSCS START will not start console spooling when
RSCS does not exist, where the * would only cause the logging to be
misplaced.

Rob
--
Rob van der Heij
Velocity Software, Inc
Jim Bohnsack
2006-02-24 14:09:59 UTC
Permalink
At first I was pretty much in favor of the changes Alan was suggesting, but
Mike brought out an excellent point. I realize, or suspect, that IBM
Endicott and perhaps a lot of other shops may run with RSCS as the standard
userid for the RSCS machine, but in 2 out of the 3 companies for which I
have worked in my professional career, we didn't. One of them was IBM and
the shop I supported, starting in 1978 called it VNET and we didn't see a
good reason to change it to RSCS. Changing the system rscs (note small
letters) id to RSCS is not a trivial task given the tendency to imbed the
id in execs. Leaving the default or undefined as "*" has a lot of
merit. It at least causes an error that is noticeable and can easily be
fixed in one place rather than having errors drag out until all of the
execs that will be run get used and cause an error.

Jim

At 04:01 AM 2/24/2006, you wrote:
>On 2/24/06, Harding, Mike <***@eds.com> wrote:
> > While I understand the arguments, I prefer the old "*" for the default
> net machine. I'm involved with a number of images which use a different
> userid for rscs. A "sp prt RSCS" on those images results in an error and
> the printer remaining routed "for <userid>".
>
>And worse, SPOOL CONS RSCS START will not start console spooling when
>RSCS does not exist, where the * would only cause the logging to be
>misplaced.
>
>Rob
>--
>Rob van der Heij
>Velocity Software, Inc

Jim Bohnsack
Cornell Univ.
(607) 255-1760
Rob van der Heij
2006-02-24 14:39:11 UTC
Permalink
On 2/24/06, Jim Bohnsack <***@cornell.edu> wrote:

> At first I was pretty much in favor of the changes Alan was suggesting, but
> Mike brought out an excellent point. I realize, or suspect, that IBM
> Endicott and perhaps a lot of other shops may run with RSCS as the standard
> userid for the RSCS machine, but in 2 out of the 3 companies for which I
> have worked in my professional career, we didn't. One of them was IBM and

:soapbox type=long apologies.
Yep. Back in the old days (so I am told ;-) there were lots of
installations inside IBM with different teams running the new releases
and reveal the need for flexbility and robustness. This has been
optimized such that the remaining VM installations in IBM are enforced
to be customized by IGS in a standard way. This does not generate
sufficient requirements for the lab to deliver function that meets all
requirements. And obviously staff reductions have made it harder for
people to spend time on such things.

It was interesting to see a similar discussion in the Linux arena
recently. Novell had decided to simply build what they thought best
rather than involve the &community in the design. Their claim is that
such involvement leads to endless debates that take a lot of time and
in the end will be put aside anyway. Alan Cox pointed out in
http://lwn.net/Articles/171161/ the difference between "design by
community" and "design in the community" and stated stated that design
in the dark will lack the extra brains and eyes that are needed.

Something seems to encourage people to walk away with half an idea and
implement half of that without soliciting enough peers to get design
review. I don't know why that is.

It's not just Alan, and not just Endicott. We've seen the same with
Linux on zSeries. I remember heavy arguments with folks in Boeblingen
when I assured them that OS labels on S/390 DASD were a must, and they
insisted Linux would write its own incompatible labels. And yes, we
now do have standard OS labels on disk (and the old incompatible
format, with at least one scenario where your data will be lost
automatically).
:esoapbox.

Rob
--
Rob van der Heij
David Boyes
2006-02-24 14:19:20 UTC
Permalink
> While I understand the arguments, I prefer the old "*" for
> the default net machine. I'm involved with a number of
> images which use a different userid for rscs. A "sp prt RSCS"
> on those images results in an error and the printer remaining
> routed "for <userid>". Subsequent print operations send
> output to the user's print queue and the naïve user doesn't
> know what to do with it, if they even realize what happened
> to it when it fails to print. At least with the default of
> "*" it ends up visible (to rdrlist) in their rdr queue.

Are these outside DR systems that you're talking about (ie, systems that don't know what specific hardware they'll be running on)? If they're not, I think I'd argue that if you have a valid reason to change the RSCSid, you can be reasonably expected to update SYSTEM NETID appropriately. In that case, the default would never apply.

Given that most ISV products care about the CPUid as well, I'd think that could be handled by coding a default entry in SYSTEM NETID to use if no CPUid matched, and have that entry default to the correct RSCSid for that system (I use nodeid DISASTER and a RSCSid of RSCS for that).
Schuh, Richard
2006-02-24 16:32:42 UTC
Permalink
I like the idea of associating the NETID and Node with the logical system rather than the cpu hardware. I have been in the position of having to move systems around due to hardware considerations, so the designation by cupid was a real pain. At one shop where we had two systems, each with its own unique workload, we even disabled the use of SYSTEM NETID altogether because of the volatile nature of things - either system could be brought up on any of 4 cpus and could be switched from one to another at any time. The SYSTEM CONFIG file, perhaps a System_Name, is the proper place in my opinion. And I think that anyone who uses a node name that differs from the System_Name must have converted to VM from an MVS background. Having an identifier based on LPAR name is repugnant to me.

Regards,
Richard Schuh

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark
Sent: Thursday, February 23, 2006 7:05 AM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: SYSTEM NETID and CPUIDs

On Thursday, 02/23/2006 at 03:36 CET, Dieltiens Geert
<***@inf.vanbreda.be> wrote:
> Wouldn't it be great if System_identifier didn't have to be based on the
> CPU-id and LPAR-number. Why not provide a way to specify a
> System_identifier_default in the LPAR-definitions on the HMC, or via
> SAPL? Then, if you don't override it in the SYSTEM CONFIG, that will be
> the System_Identifier that VM will use.
>
> That way you could set the System_identifier value even before VM starts
> up. And then, if RSCS, TCP, etc, would all use the System_identifier
> instead of SYSTEM NETID, then you wouldn't need to worry about CPU-ids
> anymore when you move to another CPU for whatever reason (DRP, new
> hardware, another LPAR,...).

Override via SAPL. Verrrrrry interesting.....

I had thought about using the HMC-defined LPAR name as the index into the
SYSTEM_IDENTIFER table, along with a default SYSTEM_IDENTIFER that was the
same as the LPAR name. (Y'all know you can QUERY LPAR now, right?)

Alan Altmark
z/VM Development
IBM Endicott
David Boyes
2006-02-24 17:50:30 UTC
Permalink
> At first I was pretty much in favor of the changes Alan was
> suggesting, but Mike brought out an excellent point. I
> realize, or suspect, that IBM Endicott and perhaps a lot of
> other shops may run with RSCS as the standard userid for the
> RSCS machine, but in 2 out of the 3 companies for which I
> have worked in my professional career, we didn't.

I think we're discussing two things here:

1) what the default for new installs should be

2) what the logic for listing possibilities and selecting the RSCSid
should be

For #1, I don't see much reason to vary from Alan's proposal. A majority
of the people who are doing new VM installs have no reason (or
sufficient knowledge of how) to change the RSCS userid, and those who
do, can do so without any additional pain that isn't present now.
Implementing Alan's suggested solution breaks nothing that works now,
and fixes things that don't work properly now if the system RSCSid is
not set correctly (LPR (ASYNC and PPS as examples).

There are lots of historical reasons to change the RSCS id, but none
apply to new installs, and the old methods to do so still work without
change.

#2 doesn't depend on #1. Yes, it would be nice if the logic worked
differently or permitted different selections, but unless we go back to
telling people how to properly configure SYSTEM NETID as part of the
install, I say the default needs to serve the majority case, and allow
people to change it if they need to, which doesn't *require* any
additional change to the logic. The two are separate and distinct
issues.

> Changing the system rscs (note small
> letters) id to RSCS is not a trivial task given the tendency
> to imbed the id in execs. Leaving the default or undefined
> as "*" has a lot of merit. It at least causes an error that
> is noticeable and can easily be fixed in one place rather
> than having errors drag out until all of the execs that will
> be run get used and cause an error.

I guess I don't see how this is any different than any other case of
hard-coding constant values in programs. I see the following
possibilities:

If 'RSCS','VNET' etc. is hard-coded in an exec and that's not the system
RSCSid, you're going to lose and the default value returned by IDENTIFY
isn't gonna matter in the slightest, because the exec isn't paying any
attention to it in the first place. Response: fix exec to check output
of IDENTIFY.

If the exec checks the output of IDENTIFY, it should get the correct
RSCSid, unless you forgot to update SYSTEM NETID, and I don't see how
IBM can be expected to read our minds (at least not until the
z9-ICan'tBelieveItsNotAMD with optional Virtual Brain Stems becomes
available) and know that it's supposed to use RSCSVNET instead of the
default. Computer does what we tell it, and a default of '*' or 'RSCS'
are equally wrong in this case. Response: fix SYSTEM NETID.

If you change the system RSCS to some other id, don't update SYSTEM
NETID and leave the default RSCS userid in place, then the spool files
end up in spool for user RSCS, which will generate the same phone call
as having it end up in the user's rdr when what they expected to happen
with the output doesn't happen. No data is lost, and if the user didn't
notice a problem with the output not appearing, they're pretty unlikely
to find the files in their rdr and have any clue what to do with them
there. Response: fix SYSTEM NETID, fix exec to check output of IDENTIFY
if needed.

If you change the system RSCS to some other id, don't update SYSTEM
NETID, and remove the default RSCS userid (common practice these days to
be required to remove unused system userids as part of policy), then you
get a big bang when someone tries to generate output to RSCS, and it
generates the same phone call with the same response: fix SYSTEM NETID,
fix exec to check output of IDENTIFY if needed.

I don't see where this is taking away any flexibility that exists now,
and it's a change that doesn't impose a lot of work on IBM to 'just get
it right the first time' for 90 plus percent of modern VM systems.
Rod
2006-02-27 15:35:24 UTC
Permalink
> And I think that anyone who uses a node name that differs from the System_Name must have
> converted to VM from an MVS background.

Ever had to run multiple PROFS/OVVM 'systems'? Multiple nodeids on
the one VM system? Don't ask about running 2nd level VMs as that
takes up extra disk space etc. etc. I didn't make this decision, I arrived
just in time to support it. Oh yes, and the HPO system was hitting it's
supportable user limit. Luckily we managed to get things converted to
XA/SP 2 just in time.

Another place had logically isolated its bureau users from each
other utilising RACF/VM and a few CP mods. All different RSCS machines
and nodeids.

The (probably still current) VM std at a large VM using company of my
and Rob's acquaintance uses nodeids to set up various
things like default SFS pools, access to various tailored versions of
products etc. When you're running Europe on one box complex
with different requirements then you need some way of separating this lot
from each other. This seemed as good a way as any. Nice and
simple. If one box in the complex goes down the users just logon to
a different one. No need to bring up 2nd level VM systems etc. No MVS
converts in the building.

My particular favourite setup was that of the French speaking Swiss
users who logged onto a Belgian box that was physically located in
Germany but supported in The Netherlands via a network that was
supported out of England.

Ah yes... those were the days...

Rod
Rob van der Heij
2006-02-27 16:33:25 UTC
Permalink
On 2/27/06, Stracka, James (GTI) <***@ml.com> wrote:

> French keyboard had seven keys for the right hand that were different
> from the English keyboard. Of course, the instructors had to say "Hash
> CP", not "Pound CP" when speaking to the English students.

Tee hee... I believe the Swedish operators found "Uh, CP" in their
instructions :-)

Rob
--
Rob van der Heij
Velocity Software, Inc
Schuh, Richard
2006-02-27 16:34:58 UTC
Permalink
I give in on the node name, at least when there is more than one node on a machine. In that case, I would probably choose each one as a variant of the system name.

None of that seems particularly amenable to making the system name, node, etc. cupid specific. In fact, you have put forth some great reasons for naming according to use, not the hardware on which it runs. I never had to run multiple PROFS/OVVM instances. At the peak, there were only about 8100 OVVM users on our system. We were not even close to capacity.


Regards,
Richard Schuh

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On Behalf Of Rod
Sent: Monday, February 27, 2006 7:35 AM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: SYSTEM NETID and CPUIDs

> And I think that anyone who uses a node name that differs from the System_Name must have
> converted to VM from an MVS background.

Ever had to run multiple PROFS/OVVM 'systems'? Multiple nodeids on
the one VM system? Don't ask about running 2nd level VMs as that
takes up extra disk space etc. etc. I didn't make this decision, I arrived
just in time to support it. Oh yes, and the HPO system was hitting it's
supportable user limit. Luckily we managed to get things converted to
XA/SP 2 just in time.

Another place had logically isolated its bureau users from each
other utilising RACF/VM and a few CP mods. All different RSCS machines
and nodeids.

The (probably still current) VM std at a large VM using company of my
and Rob's acquaintance uses nodeids to set up various
things like default SFS pools, access to various tailored versions of
products etc. When you're running Europe on one box complex
with different requirements then you need some way of separating this lot
from each other. This seemed as good a way as any. Nice and
simple. If one box in the complex goes down the users just logon to
a different one. No need to bring up 2nd level VM systems etc. No MVS
converts in the building.

My particular favourite setup was that of the French speaking Swiss
users who logged onto a Belgian box that was physically located in
Germany but supported in The Netherlands via a network that was
supported out of England.

Ah yes... those were the days...

Rod
Dale Smith
2006-02-28 00:57:14 UTC
Permalink
I have been running for many years with two local mods to IDENTIFY.
Mod 1 ignores the first two digits of the CPUID (isn't this what IBM told
other vendors they should do when they do CPUID checking in their
products?) This could also be done by allowing a wildcard character, (like
%), to cause that position in the CPUID to be ignored.
Mod 2 will use the System Node Name if the NODEID is coded as an "*"
(asterisk). So my SYSTEM NETID file looks like this:

*CPUID NODEID NETID
050539 * TSSWRSCS

The "05" in the CPUID is ignored. Here is what IDENTIFY returns on my
production VM system:
TSSWDRS AT SDCVM01 VIA TSSWRSCS 2006-02-27 19:49:55 EST MONDAY
SDCVM01 is my System Node Name. Here is what IDENTIFY returns on my second
level VM test system using the same SYSTEM NETID file:
TSSWDRS AT VMTEST VIA TSSWRSCS 2006-02-27 19:51:35 EST MONDAY
VMTEST is the Sytem Node Name for my test system.

Maybe something like this could be done to make the SYSTEM NETID file
easier and more flexible to use.

Dale R. Smith
Technology Services Senior
IBM Global Services
***@nisource.com
1-614-481-1608
Stephen Frazier
2006-02-28 01:57:52 UTC
Permalink
I like your local mods. Can I get a copy of them?

***@NISOURCE.COM wrote:

> I have been running for many years with two local mods to IDENTIFY.
> Mod 1 ignores the first two digits of the CPUID (isn't this what IBM told
> other vendors they should do when they do CPUID checking in their
> products?) This could also be done by allowing a wildcard character, (like
> %), to cause that position in the CPUID to be ignored.
> Mod 2 will use the System Node Name if the NODEID is coded as an "*"
> (asterisk). So my SYSTEM NETID file looks like this:
>
> *CPUID NODEID NETID
> 050539 * TSSWRSCS
>
> The "05" in the CPUID is ignored. Here is what IDENTIFY returns on my
> production VM system:
> TSSWDRS AT SDCVM01 VIA TSSWRSCS 2006-02-27 19:49:55 EST MONDAY
> SDCVM01 is my System Node Name. Here is what IDENTIFY returns on my second
> level VM test system using the same SYSTEM NETID file:
> TSSWDRS AT VMTEST VIA TSSWRSCS 2006-02-27 19:51:35 EST MONDAY
> VMTEST is the Sytem Node Name for my test system.
>
> Maybe something like this could be done to make the SYSTEM NETID file
> easier and more flexible to use.
>
> Dale R. Smith
> Technology Services Senior
> IBM Global Services
> ***@nisource.com
> 1-614-481-1608

--
Stephen Frazier
Information Technology Unit
Oklahoma Department of Corrections
3400 Martin Luther King
Oklahoma City, Ok, 73111-4298
Tel.: (405) 425-2549
Fax: (405) 425-2554
Pager: (405) 690-1828
email: stevef%doc.state.ok.us
Dale Smith
2006-02-28 18:36:37 UTC
Permalink
Here are my local mods to DMSIDE (IDENTIFY). The usual caveats apply:
CopyLeft, all wrongs reserved, use at your own risk, I'm not responsible
for taxes, etc., etc.

/* DMSIDE AUXCMS */
*----------------------------------------------------------------------*
* DMSIDE AUXCMS *
* System Data Center Local Modifications *
*----------------------------------------------------------------------*
SDCLCL02 SDC TXSDC Use System NODEID if NODEID in SYSTEM NETID is '*'
SDCLCL01 SDC TXSDC Ignore First and Second Digit of the CPUID

/* DMSIDE SDCLCL01 */
./ R 02972970 $ 2973360 390 04/26/95 00:51:21
CLC IDECPUID+2(L4),TOKEN+4 No, See If Matching CPU SDCLCL01
./ R 03564990 $ 3566980 1990 04/26/95 00:51:21
CLC IDECPUID+2(L4),TOKEN+2 Is this the Correct CPU?SDCLCL01

/* DMSIDE SDCLCL02 */
./ I 03590000 $ 3592000 2000 04/26/95 00:54:21
CLI TOKEN,C'*' NODEID = '*' ? SDCLCL02
BNE NETNODE No, Use NODEID from FileSDCLCL02
MVC OUTNODE,IDENODE Yes, Use System NODE SDCLCL02
B NETRSCS Go Get RSCSID SDCLCL02
SPACE 1 SDCLCL02
NETNODE DS 0H SDCLCL02
./ I 03604990 $ 3605990 1000 04/26/95 00:54:21
SPACE 1 SDCLCL02
NETRSCS DS 0H SDCLCL02

/* End Local Mods */

I am currently running CMS 20 (z/VM 4.4.0), but there have been very few
changes to DMSIDE, (if any), over the years, so the mods will probably fit
on most releases of CMS. (As you can see, I haven't changed these mods in
over ten years!)

Dale R. Smith
Technology Services Senior
IBM Global Services
***@nisource.com
1-614-481-1608
Loading...