Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Switching SMS CDSses

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM
View previous topic :: :: View next topic  
Author Message
Willem Vermeer

New User


Joined: 31 Oct 2007
Posts: 38
Location: Amsterdam, the Netherlands

PostPosted: Wed Jan 20, 2010 10:31 pm    Post subject: Switching SMS CDSses
Reply with quote

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
View user's profile Send private message

dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Thu Jan 21, 2010 4:53 am    Post subject:
Reply with quote

Hello and welcome to the forum,

Hopefully, one of our system programmers will reply later or in the morning.
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8593
Location: Back in jolly old England

PostPosted: Thu Jan 21, 2010 5:14 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Willem Vermeer

New User


Joined: 31 Oct 2007
Posts: 38
Location: Amsterdam, the Netherlands

PostPosted: Thu Jan 21, 2010 6:59 pm    Post subject:
Reply with quote

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
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Thu Jan 21, 2010 7:08 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Willem Vermeer

New User


Joined: 31 Oct 2007
Posts: 38
Location: Amsterdam, the Netherlands

PostPosted: Thu Jan 21, 2010 10:28 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Pete Wilson

Active User


Joined: 31 Dec 2009
Posts: 437
Location: London

PostPosted: Mon Jan 25, 2010 3:32 pm    Post subject:
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Switching from Mainframe to Java Tech... ponrenjith42 General Talk & Fun Stuff 3 Tue Aug 26, 2014 9:23 am
No new posts Require information for Job switching Avanti All Other Mainframe Topics 5 Fri Jun 18, 2010 5:31 pm
No new posts Prob with ORDER BY switching from a C... Melwyn Mark DSouza DB2 2 Tue Jun 02, 2009 3:23 pm
No new posts Performance benefits for switching 24... Mistermind TSO/ISPF 2 Thu Apr 30, 2009 12:09 am
No new posts Switching from PLATINUM to DB2HPU xsray DB2 1 Sun Oct 19, 2008 9:10 am


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us