Hi all,
When making DMCL changes in preparation for a ""Space Maintenance
Release"", occasionally we have to defer the implementation. So then we
reverse the DMCL changes by (re-)modifying both the Segment & the DMCL,
and genning the DMCL. NB: Basically we convert it back to what it was
previously. And it can be a time-consuming process.
However, I came up with a ""new method"" of doing this quickly; ie: backup
the IDD catalog component (3 datasets), before making any DMCL changes.
And if we have to roll-back, I just simply restore the IDD Catalog. And
it seems to work sweet. (NB: Have only used this in the test region).
However, the senior DBA is uncomfortable with this, as he is unsure what
it might affect.
Can someone please shed some light on this, as to whether it is an okay
thing to do. All feedback gratefully received.
NB: As a comparable practise - our production IDD migration procedure is
done by copying the IDD Base Component (2 datasets) from the Acceptance
environment to the Production environment, and it has been done this way
for many years, with no problems.
Thanks very much.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
Re: IDD and reversing DMCL changes
"Mike,
Note that the DMCL is not kept in the ""IDD"" dictionaries, it is in the
catalog (DCCAT, DCCATX and DCCATLOD). You have probably already figured
that out in your test region.
We have a process that works well, and we typically do dozens or scores
of space changes in a single maintenance window. Here is a high-level
sketch of what we do.
In the days or weeks before the maintenance window, we create a ""local""
set of catalog datasets and a small, local loadlib by copying the
Production catalog dictionaries DCCAT, DCCATX and DCCATLOD to alternate
named datasets, then unlocking these local areas.
We run the syntax for the ALTER SEGMENT, INCLUDE FILE, GENERATE DMCL,
and PUNCH DMCL LOAD MODULE in the local catalogs. The link step gives
the output DMCL load module a slightly different name than the ""real
DMCL"". Note that if we mess up some syntax, we can easily just run the
copy jobs to recerate them.
This allows the local load module to be used in the ... RELOAD USING
DMCL ..."" clause of the unload/reload. Of course, if you are doing an
XPAGE, you use the real DMCL (old), not the new one.
After the unload/reloads run successfully, we then apply the ALTER
SEGMENT, INCLUDE FILE, GENERATE DMCL, and PUNCH DMCL LOAD MODULE to the
real catalog, and the output is the real DMCL module into the real loadlib.
Hope this gives you some ideas on alternatives.
Jim Ritterbusch
Mike Baker wrote:
Hi all,
When making DMCL changes in preparation for a ""Space Maintenance Release"",
occasionally we have to defer the implementation. So then we reverse the
DMCL changes by (re-)modifying both the Segment & the DMCL, and genning
the DMCL. NB: Basically we convert it back to what it was previously. And
it can be a time-consuming process.
However, I came up with a ""new method"" of doing this quickly; ie: backup
the IDD catalog component (3 datasets), before making any DMCL changes.
And if we have to roll-back, I just simply restore the IDD Catalog. And it
seems to work sweet. (NB: Have only used this in the test region).
However, the senior DBA is uncomfortable with this, as he is unsure what
it might affect.
Can someone please shed some light on this, as to whether it is an okay
thing to do. All feedback gratefully received.
NB: As a comparable practise - our production IDD migration procedure is
done by copying the IDD Base Component (2 datasets) from the Acceptance
environment to the Production environment, and it has been done this way
for many years, with no problems.
Thanks very much.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
Re: IDD and reversing DMCL changes
"Hi all
At runtime the DMCL is just a Load Module.
We generate ALL DMCL Load Modules in our development environment - we maintain separate Dev and Prod DMCLs.
We never update our production catalog ( we are not using the SQL Option!).
We back up a DMCL load module before a re-gen.
""Space Maintenance"" needs 2 DMCLs; old and new sTo:
our back out is a simple load module replacement (and the obvious database restore). If we need to back out the DMCL changes we do it at our leisure!
Cheers
Martin
________________________________
From: IDMS Public Discussion Forum on behalf of Mike Baker
Sent: Sun 03/06/2007 21:53
To:
IDMS-L@LISTSERV.IUASSN.COM
Subject: IDD and reversing DMCL changes
Hi all,
When making DMCL changes in preparation for a ""Space Maintenance Release"",
occasionally we have to defer the implementation. So then we reverse the
DMCL changes by (re-)modifying both the Segment & the DMCL, and genning
the DMCL. NB: Basically we convert it back to what it was previously. And
it can be a time-consuming process.
However, I came up with a ""new method"" of doing this quickly; ie: backup
the IDD catalog component (3 datasets), before making any DMCL changes.
And if we have to roll-back, I just simply restore the IDD Catalog. And it
seems to work sweet. (NB: Have only used this in the test region).
However, the senior DBA is uncomfortable with this, as he is unsure what
it might affect.
Can someone please shed some light on this, as to whether it is an okay
thing to do. All feedback gratefully received.
NB: As a comparable practise - our production IDD migration procedure is
done by copying the IDD Base Component (2 datasets) from the Acceptance
environment to the Production environment, and it has been done this way
for many years, with no problems.
Thanks very much.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
Re: IDD and reversing DMCL changes
"Don't forget that the SYSTEM Catalog may also have Schemas, Tables, Views
and restraints besides Segments, DMCL's, DBNAME's and DBTABLE's.
Bill Allen