View previous topic :: View next topic
|
Author |
Message |
Willem Vermeer
New User
Joined: 31 Oct 2007 Posts: 38 Location: Amsterdam, the Netherlands
|
|
|
|
Greetings.
We're in the process of renaming our SMS CDSses. I know I can use SETSMS SAVESCDS and COPYSCDS to save my current configuration, but what exactly do I do with the COMMDS?
What I wanted to do was [1] SAVESCDS, [2] COPYSCDS (both into datasets with the new name) and then setup an empty COMMDS (with the new name). I then IPL with the new config and was hoping that SMS would prime the empty COMMDS with info from the new config.
Would this work and if not, what should I do instead?
By the way, we're running z/OS 1.9 but are in the process of moving over to z/OS 1.10. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello and welcome to the forum,
Hopefully, one of our system programmers will reply later or in the morning. |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
|
|
|
|
Eeeeek, a long while since I played with the COMMDS.
I can't see a reason it wouldn't work, but what's wrong with the current COMMDS ? |
|
Back to top |
|
|
Willem Vermeer
New User
Joined: 31 Oct 2007 Posts: 38 Location: Amsterdam, the Netherlands
|
|
|
|
There's nothing wrong with the current COMMDS nor with any of the CDSses.
It's just that we are going over to a new naming-convention for all our SMS datasets and I was wondering how to move towards the new CDSses / COMMDS without losing any info / running any unnecessary risks.
Setting up the new CDSses is no problem, but since I don't know exactly what kind of info the COMMDS contains and at what point in time it's initialized/primed, I decided to ask first and act later. |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
This is what i found for the SETSMS command
(z/OS V1R9.0 MVS System Commands SA22-7627)
COMMDS(dsname)
SMS is to use the named data set as the new communications data set.
If the replacement COMMDS is empty, SMS primes it with information from the active configuration. If the data set is not empty, SMS determines which ACDS was used to prime the new data set. If the ACDS named on COMMDS is the same as the one that is active, processing continues with the new COMMDS. Otherwise, SMS prompts the operator (by message IGD076D) to decide whether SMS should use the ACDS named on COMMDS or continue to use the current ACDS.
Notes:
1.If SMS cannot re-access the previously active communications data set, the operator must issue the command to change the COMMDS on each MVS system in the SMS complex.
2.The COMMDS parameter is mutually exclusive with ACDS, SCDS, and SAVEACDS. |
|
Back to top |
|
|
Willem Vermeer
New User
Joined: 31 Oct 2007 Posts: 38 Location: Amsterdam, the Netherlands
|
|
|
|
Ok. Looks like setting up 2 new CDSses + an empty (new) COMMDS, followed bij an IPL with the new config (not just for this rename!) will do the job.
Thnx. |
|
Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009 Posts: 580 Location: London
|
|
|
|
Willem, an IPL shouldn't be necessary. Be careful if any LPARs in the 'plex are at different levels of ZoS though as this can sometime cause issues. It's probably best to switch from the higher level LPAR(s) first.
From the DFP Storage Admin Reference the following procedure is recommended:
Recovering a COMMDS
If you cannot access the COMMDS, you can recover from the error if you allocated
a spare data set. All permanent errors that make the COMMDS unreadable require
intervention. For permanent I/O errors to the COMMDS, the messages IGD041I and
IGD070D appear on an operator console. Reply 'S' on the operator console and
issue the following command from a system in the SMS complex:
SETSMS COMMDS(spare.commds)
One of three situations results.
1. If the spare COMMDS is empty it gets formatted automatically, and SMS writes
the in-storage copy of the current COMMDS into the spare.commds. You then
need to issue the following command on each of the remaining systems in the
SMS complex:
SETSMS COMMDS(spare.commds)
2. If the spare COMMDS is not empty but describes an ACDS that is not currently
active in the SMS complex, then SMS issues the message IGD076D. This
message asks if you want to use the contents of the COMMDS and the ACDS
to which it points. Reply 'C' to cause SMS to replace the contents of the
spare.commds with the in-storage copy of the current COMMDS. You then need
to issue the following command on each of the remaining systems in the SMS
complex:
SETSMS COMMDS(spare.commds)
3. If the spare COMMDS is not empty but describes the ACDS that is currently
active in the SMS complex, you need to issue the following command on each
of the remaining systems in the SMS complex:
SETSMS COMMDS(spare.commds)
A response of āSā to IGD070D is recommended when recovering from the current
COMMDS because a response of āCā might result in an unrecoverable error when
trying to re-access the current COMMDS. When access to the current COMMDS is
suspended, SMS is able to access the new COMMDS without accessing the current
COMMDS and resulting in further errors.
Without a usable COMMDS, the systems in the SMS complex have no means of
communication. Other systems in the SMS complex are aware of the error, but they
are unaware of the switch to a new COMMDS until you inform them.
If you can access the current COMMDS but you want to use an alternate one, you
only need to issue the SETSMS command from one system. The other systems in the
SMS complex detect the change from the old COMMDS to the new COMMDS and
they automatically switch to the new one. |
|
Back to top |
|
|
|