On Thu, 17 Jun 2010 08:51:11 -0500, Mark Zelden <[email protected]> wrote:
>
>BTW, I just upgraded from R2 to R3 over the weekend mostly because I was
>interested in the deployment function (but there are some other nice features
>also). In trying to test a deployment, it looks like it will only work
>with "future"
>(from here on out) product packages and nothing that existed prior to a
>specific date. I tried a deployment with CA-MIM 11.7 SP1 which is the most
>current level and there is no deployment metadata. Also, we "deploy" by
>copying install libraries to an "ISV sysres" that is an extension of our
>maintenance sysres set and clone it along with our IBM sysres to roll out
>maintenance / upgrades via IPLs. The libaries are all indirectly cataloged as
>are all the sysres data sets. This means we copy them without cataloging
>them to the volume that gets cloned, and from what I can tell so far, there
>is probably not an option to do that. That may not be an issue if the
>process doesn't fail if the libraries are already cataloged - which they will
>be - indirectly - unless it is a new name / library for whatever product we
>are deploying. In that case, I would uncatalog the file after copy and
>indirectly catalog it.
>
I have deployment up and running in my environment and the indirect
cataloging of "run time" data sets and use of a "maintenance ISV sysres"
is a problem in our environment in regards to MSM deployment.
The problem isn't really with MSM, but it is with the design and use of
GIMUNZIP. Unless CA can convince IBM to change the behavior or
perhaps add another option in addition to "REPLACE" that can unzip
without cataloging or not check the current catalog status.
It worked as I suspected in my post above. I ran a deploy test and it copied
and cataloged to my maintenance ISV sysres. I then uncataloged and then
indirectly cataloged those data sets. I ran another deploy to the maintenance
ISV sysres and it also worked (GIMUNZIP worked) by updating / unzipping
to my target vol (maintenance ISV sysres) even though the data sets
were no no longer cataloged to that volume.
So here is my problem.
I have more than one set of ISV maintenance sysreses ... all on shared
DASD for installation, but cloned to IPLable vols in their respective sysplexes.
After I do the deploy as I described above (and indirect catalogs), the
2nd deploy to a different maintenance sysres gets this error:
----------------------------------------------------
GIM68301I ARCHIVE archive WILL BE EXTRACTED INTO THE DATA SET dataset
THAT IS CATALOGED ON VOLUME volume1, EVEN THOUGH THE
<ARCHDEF> TAG FOR THE ARCHIVE SPECIFIED VOLUME volume2,
BECAUSE THE DATA SET WAS NOT FOUND ON VOLUME volume2.
Explanation:
archive pathname or archid of the archive. If the name
exceeds 300 characters in length, only the first
300 characters will appear in this message
dataset destination data set name
volume1 volume on which the data set is cataloged
volume2 volume specified on <ARCHDEF> tag
GIMUNZIP will extract the archive into the existing cataloged
data set, even though the volume specified on the <ARCHDEF>
tag does not match the volume on which the data set was
allocated.
System Action: Processing continues.
Programmer Response: None
----------------------------------------------------
And now my production in use (indirectly cataloged) data set gets updated!
Sort of like SMP/E ignoring a DDDEF for SYS1.LINKLIB because it finds
a cataloged version already out there and uses that one.
I think this was an GIMUNZIP in SMP/E 3.3 enhancement, but is causing
my issue.
If the deploy process were to pre-allocate or verify that the data set(s)
specified in the VOLSER= tag existed (on the VOLSER volume) prior to
GIMUNZIP, it would work.
I have yet to discuss with CA, but will. :-)
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:[email protected]
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
