Re: CA's MSM

[Daniel McLaughlin]

So I date back to MFT and the honorable S360. However after attending the
demonstration for MSM my views are somewhat changed. Guess the old dog will
be learning some new tricks.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[Mark Zelden]

On Sun, 27 Jun 2010 23:14:44 -0700, Ed Gould  wrote:


>Well I was wrong *BUT* not totally. It seems as though that the glorious
folks at CA didn't want to really play the SMP/e rules.
>It came out after the following 5 (or so years) that indeed CA didn't want
to put in all the prereq on the SMP/e statements. This caused major gnashing
of teeth for many many sysprogs. CA's "brilliant" people well will tell
everyone to specify BYPASS(ID) on the apply (rather than fixing it).

For many products, that was true. 


>For 5 years CA got ripped regularly for not following the SMPe rules.
>So instead of simply following the simple rules they have gone off on
another >tangent and re-invented a CA install product. Which will take 5
years of getting >people trained in it and then you will the question asked
again why doesn't CA >use SMP/e .



MSM is just a GUI / front end for installing products via SMP/E.  Even if you
never look at using MSM, the CA client base is all benefiting from the work
that is
going into making all their products MSM compatible.   That means "SMP/E
installable and proper pre-reqs for maintenance".   MSM "downloads" the
same packages from CA's web site and processes them (GIMUNZIP) the same
way you would if you did a "manual install".  Just a whole heck of lot quicker.

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:mzel...@flash.net  
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[Ed Gould]

--- On Mon, 6/21/10, Mark Yuhas  wrote:
---SNIP--

Since CA is now going to distribute updates and releases via MSM, does
this mean that all of CA's products will follow the same methodology for
installation?  For example, Telon would send out various releases and
service packs.  None cumulative.  Upgrading required applying each
release and service pack individually.  Is Telon now going change this
method?  I haven't seen anything to indicate Telon will change.

Furthermore, CA-11 makes certain assumptions.  I was given a CA-11
installation tape with a service pack.  When I attempted to install it,
I found missing modules and JCL.  After some email discussions, I
learned the service pack tape was built with the assumption I had to
order and install the original release which had the missing elements.
Is CA-11 going to change?

We will eventually go to MSM, but, I sure would like to know if all CA
products are using the same disciplines?  If not, why not?
SNIP--Mark:
I know CA is always a fun topic (with a lot of merit I will add).
Somewhere around 15 years ago, it was a BIG announcement that CA was really 
going to use SMP/e . I smiled then and told a friend that it would never happen.
Well I was wrong *BUT* not totally. It seems as though that the glorious folks 
at CA didn't want to really play the SMP/e rules.
It came out after the following 5 (or so years) that indeed CA didn't want to 
put in all the prereq on the SMP/e statements. This caused major gnashing of 
teeth for many many sysprogs. CA's "brilliant" people well will tell everyone 
to specify BYPASS(ID) on the apply (rather than fixing it).
For 5 years CA got ripped regularly for not following the SMPe rules.
So instead of simply following the simple rules they have gone off on another 
tangent and re-invented a CA install product. Which will take 5 years of 
getting people trained in it and then you will the question asked again why 
doesn't CA use SMP/e .
I am sure in 5 years we will have another grand announcement that MSM is dead 
and SMP/e is alive (err again).  CA is probably the biggest leach out there on 
IBM's back and probably one of the biggest cash cows as the increase in 
software licensing when upgrade comes (for doing essentially nothing) all hurt 
the MF community and they sit back there and say whoh is is us we are not 
making big enough bonus check this year how can we squeeze some more out of the 
cash cows.
Call me bitter and sick and tired of CA games.
Ed





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: MSM R3 Deploy (was Re: CA's MSM)

[Mark Zelden]

On Thu, 17 Jun 2010 08:51:11 -0500, Mark Zelden  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.  

I found out from CA support that MSM compatible products that were GA
prior to May 2010 need to have a deployment PTF applied to enable
deployment.  In my example case of MIM 11.7 SP1, it was RO14200.  So
all I had to do was "refresh" MSM and apply that PTF via MSM (which did have
a manual action of allocating a new TGT/DLIB and updating the DDDEFs).  

After that, I was able to deploy MIM 11.7 SP1.  BTW, the PTF itself didn't
need to be "rolled out" to the running environment, it just had to exist in
the SMP/E environment to allow deployment.  

Kudos to CA once again on MSM.   Even though my last post on this subject 
talked about a problem with deployment in our environment, I can
imagine many other environments that I worked at in the past (and even
the shop I'm at now in the past)  where deployment wouldwork well.

The issue I face now is only due to our current method of indirectly 
cataloging the runtime libraries on our sysres set.  We didn't always do it
that way, but it made it much easier to support 30+ LPARs across 10 or 11
sysplexes / monoplexes with less staff.

Work smarter, not harder (and MSM can help). 

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:mzel...@flash.net  
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: MSM R3 Deploy (was Re: CA's MSM)

[Dell'Anno, Aurora]

Mark,

Yes please do contact our support team - we are VERY interested in
helping out our customers on serious issues like this. 



Thanks.
 

Aurora


 

Aurora Emanuela Dell'Anno
CA Technologies - MSC
Sr. Engineering Services Architect
Tel:  +44 (0)1753 577 733
Mobile:  +44 (0)7768 235 339
aurora.della...@ca.com

CA Limited
Ditton Park, Riding Court Road, Datchet, SL3 9LL, UK

CA Limited is a company registered in England and Wales under company
registration number 1282495 with its registered office at the address
set out above. VAT number 697904179.


http://www.ca.com/

 

P please don't print this e-mail unless you really need to!

 

 



-Original Message-
From: Mark Zelden [mailto:mzel...@flash.net] 
Sent: 23 June 2010 17:18
Subject: MSM R3 Deploy (was Re: CA's MSM)

On Thu, 17 Jun 2010 08:51:11 -0500, Mark Zelden 
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:



GIM68301IARCHIVE archive WILL BE EXTRACTED INTO THE DATA SET dataset

 THAT IS CATALOGED ON  VOLUME volume1,  EVEN THOUGH THE

  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  tag

 

 GIMUNZIP will extract the archive into the existing
cataloged   
 data set, even though the volume specified on the 

 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 y

Re: CA's MSM

[Scott Fagen]

On Mon, 21 Jun 2010 09:00:44 -0700, Mark Yuhas  wrote:

>Since CA is now going to distribute updates and releases via MSM, does
>this mean that all of CA's products will follow the same methodology for
>installation?  

_All_ is a hard word.  _Almost all_ is easier to defend (and achieve).  We
keep a scoreboard of products and their adherence to the various MSM
functions here:
http://www.ca.com/us/products/collateral.aspx?cid=205030

>Furthermore, CA-11 makes certain assumptions.  I was given a CA-11
>installation tape with a service pack.  When I attempted to install it,
>I found missing modules and JCL.  After some email discussions, I
>learned the service pack tape was built with the assumption I had to
>order and install the original release which had the missing elements.
>Is CA-11 going to change?

When a product joins the CA MSM family of supportable products and does not
behave properly under CA MSM, you should should open an issue with us (or,
in the future, the appropriate software vendor).

>We will eventually go to MSM, but, I sure would like to know if all CA
>products are using the same disciplines?  If not, why not?

By May 2011, _almost all_ of the entire portfolio will be manageable through
MSM.  Some products are functionally stabilized (may never be MSM
installable, but may become MSM maintainable, deployable, configurable) and
others are a much larger work to complete.  If you are interested in a
product that is not currently supported, please drop me a note at scott
(dot) fagen (at) ca (dot) com.

Thanks,
Scott Fagen
Chief Architect - Mainframe
CA Technologies

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

MSM R3 Deploy (was Re: CA's MSM)

[Mark Zelden]

On Thu, 17 Jun 2010 08:51:11 -0500, Mark Zelden  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:



GIM68301IARCHIVE archive WILL BE EXTRACTED INTO THE DATA SET dataset 
 THAT IS CATALOGED ON  VOLUME volume1,  EVEN THOUGH THE  
  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  tag 
 
 GIMUNZIP will extract the archive into the existing cataloged   
 data set, even though the volume specified on the  
 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:mzel...@flash.net  
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html 
Systems Programming expert at http://exp

Re: CA's MSM

[Mark Yuhas]

Since CA is now going to distribute updates and releases via MSM, does
this mean that all of CA's products will follow the same methodology for
installation?  For example, Telon would send out various releases and
service packs.  None cumulative.  Upgrading required applying each
release and service pack individually.  Is Telon now going change this
method?  I haven't seen anything to indicate Telon will change.

Furthermore, CA-11 makes certain assumptions.  I was given a CA-11
installation tape with a service pack.  When I attempted to install it,
I found missing modules and JCL.  After some email discussions, I
learned the service pack tape was built with the assumption I had to
order and install the original release which had the missing elements.
Is CA-11 going to change?

We will eventually go to MSM, but, I sure would like to know if all CA
products are using the same disciplines?  If not, why not?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[Shane Ginnane]

Of course if Phil was still around, there'd be no need to add some " color from 
the analyst community".
He provided that in spades.

Shane ...

On Sat, Jun 19th, 2010 at 7:47 AM, Scott Fagen wrote:

> To give at least some color from the analyst community about our
> efforts, ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[Scott Fagen]

To give at least some color from the analyst community about our efforts,
here are two links to briefs by EMA and Gartner (mind any wraps).

EMA:
http://www.ca.com/files/IndustryAnalystReports/emaworldmainframe0510ib_239016.pdf
(We host the EMA brief because we paid them for the right, it is a
flattering review.  The same report is available for a fee from their site at
http://www.enterprisemanagement.com/research/asset.php?id=1752 )

Gartner:
http://www.gartner.com/technology/media-products/reprints/ca/vol2/article1/article1.html

As with all things, opinions vary.  In the last year, we've had over 260
sites install and use CA MSM, from the largest financial institutions to
some of our smallest customers.

Scott Fagen
Chief Architect
Mainframe Business Unit
CA Technologies

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[john gilmore]

Paul Gilmartin has characterized my mercifully infrequent contributions to this 
forum and my only one to this thread as harangues.
 
One immediately accessible web definition of <> is:
 
An impassioned, disputatious public speech; A tirade or rant, whether spoken or 
written; To give a forceful and lengthy lecture or criticism to someone.

His characterization of my manner is thus, I think, exaggerated.  In particular 
I prize brevity.
 
Worse perhaps, it also reflects a failure, this time, to mug up the appropriate 
etymologies; and it is thus a disservice to his persona here.
 
He did, however, get the matter, my substantive views, right.  I think that the 
HLASM and its macro language are the appropriate vehicles for implementing 
products, things to be used by others; and I think that PL/I, never C, is the 
appropriate vehicle for teaching and illustrating algorithms and for 
implementing throwaway, investigational routines.  
 
His own contributions here do not always convince me, but even when they do not 
they do almost always elicit my sympathies, as do even implausible defenses of 
handicapped offstring and halbstarke anarchism.

 
John Gilmore Ashland, MA 01721-1817 USA



  
_
The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail.
http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[Paul Gilmartin]

On Thu, 17 Jun 2010 13:22:34 -0400, Brian France wrote:

>john gilmore wrote:
>> Brian Peterson wrote:
>>
>> 
>> It seems to me that one of the most significant results of this common 
>> installation tool initiative is actually not the tool itself. Rather, in my 
>> opinion, it is the fact that all of the "tribes" within the CA family now 
>> have ONE install methodology - one that is common across all products.
>> 
>>
>> This notion is hard, indeed all but impossible to disagree with in general.  
>> That said, we have SMP/E in hand; and we are all familiar with it, warts and 
>> all.  Do we need another quite ordinary installation/maintenance tool?  I 
>> think not.
>>
>This is my thinking exactly. We have SMP/e, why do I need a product
>that basically does that under the covers.
>>
>> I should feel different about it if it were radically innovative; it is not.
>>
Likewise, in some of John Gilmore's harangues it appears that he
believes that we have Assembler with its macro processor, why do
we need another "product that basically does that under the covers."
(Unless, of course, it's PL/I.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[Mark Zelden]

On Thu, 17 Jun 2010 17:05:23 +, john gilmore  wrote:

>
>I should feel different about it if it were radically innovative; it is not.
>

"Radically innovative" is subjective.   How many CA products do you need
to install and maintain across how many sysplexes and LPARs? 

I do think it is innovative in some ways.  Regardless of one's opinion
of it being innovative or not, it works and makes my job and my 
coworkers' jobs easier and saves us time.


On Thu, 17 Jun 2010 10:20:16 -0700, Norman Hollander on DesertWiz
 wrote:

>If Receive/Apply/Accept is all that you needed, and you have no newbies in
>your shop,
>you may be right.  But if you or the newbie need to easily deploy and
>configure CA
>software, you'd want the tools to help you get it done quicker.  IMHO, of
>course.
>

Similar comment.   We have nothing but experienced sysprogs at the
shop I'm at.  (going by years alone, I am the 2nd most inexperienced). 
But we have a large amount of ISV products we support - especially CA,
and this saves us time.   Not everyone on the team is an "SME" for a CA
product, but all the ones that are and have used MSM love it (after some brief
training I provided).  My client is large and thus far, only the OS team (MVS
and Comm Server) is using it.  I plan on introducing the other teams to
it also soon (CICS,  Database, etc.).  I know there are some CA products
they maintain and there is no reason this shouldn't benefit everyone.

If you have a small environment and only a couple of CA products, then
of course it isn't worth installing and maintaining a somewhat complex 
piece of software just to maintain a couple of other pieces of software. 

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:mzel...@flash.net  
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[Daniel McLaughlin]

Like the comparison of having an MCSE do it. ZOS is not 'shield' installed
and we don't need GUI tools that badly. Allow the NKOTB to plug and play a
product? Is that a wise choice. Besides we all know the mainframe is going
away...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[McKown, John]

IMO, this is all about "how to allow an MSCE to install z/OS software". 
Remember that people cost more than software. And software doesn't up and 
resign or retire, taking their expertise with them. One day, I expect the HMC 
to have the "install the latest z/OS" button. Management pushes it and "poof!" 
it is down automatically.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[Lizette Koehler]

I like MSM however, it does need some growth time.

My main issue is if you try to use MSM to install a product but that product is 
not ready for MSM, there is NOTHING I could find that MSM would say "NOT MSM 
Supported".

So I would spend days or hours trying to use MSM on something not ready for 
MSM.  I have a DAR request in for that.  That MSM should be able to present a 
panel that indicates the product/verion is not support by MSM.

Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[Brian France]

john gilmore wrote:

Brian Peterson wrote:

 




It seems to me that one of the most significant results of this common installation tool 
initiative is actually not the tool itself. Rather, in my opinion, it is the fact that 
all of the "tribes" within the CA family now have ONE install methodology - one 
that is common across all products.



 

This notion is hard, indeed all but impossible to disagree with in general.  That said, we have SMP/E in hand; and we are all familiar with it, warts and all.  Do we need another quite ordinary installation/maintenance tool?  I think not.  
  
   This is my thinking exactly. We have SMP/e, why do I need a product 
that basically does that under the covers.
 


I should feel different about it if it were radically innovative; it is not.

John Gilmore Ashland, MA 01721-1817 USA


 		 	   		  
_

Hotmail is redefining busy with tools for the New Busy. Get more from your 
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


  


--

--

Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Administrative Information Services - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu 

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[Norman Hollander on DesertWiz]

If Receive/Apply/Accept is all that you needed, and you have no newbies in
your shop,
you may be right.  But if you or the newbie need to easily deploy and
configure CA
software, you'd want the tools to help you get it done quicker.  IMHO, of
course.

zNorman 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of john gilmore
Sent: Thursday, June 17, 2010 Thursday 10:05 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: CA's MSM

Brian Peterson wrote:

 



It seems to me that one of the most significant results of this common
installation tool initiative is actually not the tool itself. Rather, in my
opinion, it is the fact that all of the "tribes" within the CA family now
have ONE install methodology - one that is common across all products.



 

This notion is hard, indeed all but impossible to disagree with in general.
That said, we have SMP/E in hand; and we are all familiar with it, warts and
all.  Do we need another quite ordinary installation/maintenance tool?  I
think not.  

 

I should feel different about it if it were radically innovative; it is not.

John Gilmore Ashland, MA 01721-1817 USA


  
_
Hotmail is redefining busy with tools for the New Busy. Get more from your
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:W
L:en-US:WM_HMP:042010_2
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[Gibney, Dave]

I've not seen R3.

I wish I could sing the praises like the well respected folks who have
so far, but IMO, CA-MSM was not really ready for prime time. Like many
other products, it seems to have been rushed to release by marketing
forces.

In reality, the portion of a CA install that MSM (R2) did (for a limited
set of products) was the trivial part. Even with the ESD method,
download, fake a tape, unload, allocate CSI, target, and dlib, SMPE
RECEIVE/APPLY/ACCEPT shouldn't take more than a few hours. Then the real
work begins.

CA-MSM (R2) was not CA-MSM installable! (Neither was the maintenance
package I needed)

It does do a good job of identifying and downloading your products and
the pax files. It does do a good job of identifying the maintenance you
need and downloading the fixes and SP packages. Actually, it does an
almost too good a job, I ended up with several fixes for parts I don't
actually need (especially in CA-Common Services). If the APPLY works,
does do a good job of RECEIVE/APPLY for fixes. Restarting after a space
error for example was more complicated.  

One product, seemed to be MSM installable, until the process croaked on
space, then it magically became not MSM installable. (after working with
CA support, it was determined that it never should have been MSM
installable)

Many products were not yet MSM installable, and the pax files (nicely
downloaded) are deep in the USS file system, several hundred characters
of directory specification deep! My next step when I left MSM for higher
priority work (z/OS 1.11 install continuation) was planning to implement
Dovetail's COZ to avoid the limitations of BPXBATCH trying to do pax
deep down there.

Tomcat (JAVA) is a CPU HOG (we have no ZAAP, are unlikely to get a
ZAAP). CA-DATACOM :(

I agree it has real potential to be useful. I am interested in exploring
R3. Interestingly, this thread is the first I've heard of R3. I know
that I need everything I can to streamline what is becoming more and
more a one person job (until the mainframe is gone :(

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Brian Peterson
> Sent: Thursday, June 17, 2010 9:28 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: CA's MSM
> 
> I've been working with CA MSM for a year or so - first the R2 release,
> then
> the R3 release.
> 
> I really like this new tool.  (I remember, and hated, aggrivator).
> 
> It seems to me that one of the most significant results of this common
> installation tool initiative is actually not the tool itself.  Rather,
> in my
> opinion, it is the fact that all of the "tribes" within the CA family
> now
> have ONE install methodology - one that is common across all products.
> 
> Recall that CA grew over time by bringing different development
> organizations into their company via acquisition.  Each of these
> organizations brought their own product packaging practices along with
> -
> some of which have changed little over the years.
> 
> Now, with the CA MSM initiative, a common set of packaging
requirements
> is
> in place.
> 
> Obviously, not every product has every feature of the new install
> methodology available today.  But, over the next (apparently short)
> period
> of time, more and more products are converting to the new methods.
> 
> Seems to me this effort in itself will bring significant long term
> benefits
> to us as customers.
> 
> Brian
> 
> On Thu, 17 Jun 2010 07:59:00 -0500, Daniel McLaughlin wrote:
> 
> >We've been invited to a D&P on this next week. After reviewing some
of
> the
> >demos and documentation I sure don't see how it makes life
> easier..comments
> >from those who have trod that road?
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[john gilmore]

Brian Peterson wrote:

 



It seems to me that one of the most significant results of this common 
installation tool initiative is actually not the tool itself. Rather, in my 
opinion, it is the fact that all of the "tribes" within the CA family now have 
ONE install methodology - one that is common across all products.



 

This notion is hard, indeed all but impossible to disagree with in general.  
That said, we have SMP/E in hand; and we are all familiar with it, warts and 
all.  Do we need another quite ordinary installation/maintenance tool?  I think 
not.  

 

I should feel different about it if it were radically innovative; it is not.

John Gilmore Ashland, MA 01721-1817 USA


  
_
Hotmail is redefining busy with tools for the New Busy. Get more from your 
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[Brian Peterson]

I've been working with CA MSM for a year or so - first the R2 release, then
the R3 release.

I really like this new tool.  (I remember, and hated, aggrivator).

It seems to me that one of the most significant results of this common
installation tool initiative is actually not the tool itself.  Rather, in my
opinion, it is the fact that all of the "tribes" within the CA family now
have ONE install methodology - one that is common across all products.

Recall that CA grew over time by bringing different development
organizations into their company via acquisition.  Each of these
organizations brought their own product packaging practices along with -
some of which have changed little over the years.

Now, with the CA MSM initiative, a common set of packaging requirements is
in place.

Obviously, not every product has every feature of the new install
methodology available today.  But, over the next (apparently short) period
of time, more and more products are converting to the new methods.

Seems to me this effort in itself will bring significant long term benefits
to us as customers.

Brian

On Thu, 17 Jun 2010 07:59:00 -0500, Daniel McLaughlin wrote:

>We've been invited to a D&P on this next week. After reviewing some of the
>demos and documentation I sure don't see how it makes life easier..comments
>from those who have trod that road?
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[Daniel McLaughlin]

Overall. Usual litany...legacy system, nothing new coming on-line, etc.
RARELY look askance at USS stuff. No websphere, and so on. Java? My coffee
cup has java in it. And no, it's not an attitude about USS, we just don't
play there.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[Mark Zelden]

On Thu, 17 Jun 2010 08:55:11 -0500, Daniel McLaughlin
 wrote:

>Well, to each his own. We are not blessed with USS knowledge and the install
>instructions for the product assume that the reader is. I've read many of
>the posts but some of the vendor info is nebulous to say the least.
>Thank you for your feedback.
>

Talk to you CA sales / account rep.  CA may be willing to send someone
out to your site on their dime to help you get it up and running.   They
have done so for many shops.

As an aside, IMO, it doesn't really take any more z/OS Unix knowledge to 
install & maintain CA-MSM than it does to install and maintain z/OS.  So what
are you doing to install and maintain z/OS?   Yes, a certain level of
knowledge / experience is needed.  So if you have more knowledgeable 
people at your shop that do the "OS" installs and don't typically deal with
ISV products, you will probably need their assistance.   But once the product
is set up and running, the whole idea is that a new sysprog can use it and be
productive and it also can save a ton of time for the experienced ones as
well.  I learned how to customize JCL,  allocate files and run SMP/E jobs
a few years ago, so I don't need to do it all the time now.  :-) 

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:mzel...@flash.net  
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[Paul Gilmartin]

On Thu, 17 Jun 2010 08:55:11 -0500, Daniel McLaughlin wrote:

>Well, to each his own. We are not blessed with USS knowledge and the install
>instructions for the product assume that the reader is.
>
Is that CA-peculiar or IBM-general?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[Daniel McLaughlin]

Well, to each his own. We are not blessed with USS knowledge and the install
instructions for the product assume that the reader is. I've read many of
the posts but some of the vendor info is nebulous to say the least.
Thank you for your feedback.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[Shane Ginnane]

Well this should generate some entertainment for when the soccer gets a bit 
slow ...

CA have an appalling history with regard to product maintenance - Russells lot 
have been the best 
of a bad bunch, and have been generally pretty good.
Other than that, uniformly terrible.

Scott has promised to fix that. Customers I've spoken to like it, although so 
far none has seen fit 
to let me loose on it.

Shane ...

On Thu, Jun 17th, 2010 at 10:59 PM, Daniel McLaughlin wrote:

> We've been invited to a D&P on this next week. After reviewing some
> of the demos and documentation I sure don't see how it makes life
> easier..comments from those who have trod that road?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA's MSM

[Mark Zelden]

On Thu, 17 Jun 2010 07:59:00 -0500, Daniel McLaughlin
 wrote:

>We've been invited to a D&P on this next week. After reviewing some of the
>demos and documentation I sure don't see how it makes life easier..comments
>from those who have trod that road?

Search the archives for past posts of mine.  I like it ... a lot.  And
realizing that
it is still a very new product and hasn't matured yet, I see tons of potential. 
I had a long laundry list of items I discussed with development after I 
installed and worked with R2 and many of those items are already addressed
in R3 which is now GA. 

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.   

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:mzel...@flash.net  
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

CA's MSM

[Daniel McLaughlin]

We've been invited to a D&P on this next week. After reviewing some of the
demos and documentation I sure don't see how it makes life easier..comments
from those who have trod that road?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html