ca.portal.admin

Re:Re: IDMSMSVA

Discussion created by ca.portal.admin on Nov 24, 2009
Chris,

We're running the latest IDMSMSVA (as delivered by RO12844) on our SP0 R17 CVs.
No problems so far (crosses fingers, touches wood).
These are SP0 CVs with PTFs applied, including RO09452.

We had the test version of RO12844 for a problem we hit on test and on our UTE system - we saw S378 abends on batch jobs.

We've been told by CA that it is possible to bring the new IDMSMSVA in with CVs up.
There should be no batch (CV or local mode) running, as if they try to do an LMP key check at the exact moment MSVA is being refreshed, they'll fail with a S0C1

Iain Robertson
BT Operate, Senior DBA
Email: iain.dk.robertson@bt.com

-----Original Message-----
From: IDMS Public Discussion Forum
Subject: [IDMS-L] IDMSMSVA

R17.0 - z/OS 1.9.

Has anybody out there used the SP1 or post
RO09452,RO11237,RO12844 version of IDMSMSVA with an SP0 system?

I am assured by a ""reliable source within CA"" that the latest IDMSMSVA
is downward compatible. This allows you to run both a SP0 and a SP1 or
APARed IDMS system on a single LPAR with the new version of IDMSMSVA
CAIRIMed into the LPA.

Somebody has clearly done some kind of work in this area to make CA
create RO12844 which was issued today.

I am going to attempt this at the weekend. Has anybody else
done it already?

______________________________________________________________

Chris Trayler, IXD
Bank Julius Baer & Co. Ltd.
P. O. Box, CH-8010 Zürich, Switzerland Telephone +41 (0)58 887 4332,
Fax +41 (0)58 887 4969 www.juliusbaer.com <http://www.juliusbaer.com/>
*****JuliusBaer Disclaimer***** This e-mail is for the intended recipient only and may contain confidential or privileged information. If you have received this e-mail by mistake, please contact us immediately and completely delete it (and any attachments) and do not forward it or inform any other person of its contents. If you send us messages by e-mail, we take this as your authorization to correspond with you by e-mail, however, we will not accept the electronic transmission of orders/instructions without a specific agreement being in place to govern the same. If you do not wish to receive any further e-mail correspondence please let us know. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, amended, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Neither the Julius Baer Group nor the sender accept liability for any errors or omissions in the content of this message which arise as a result of its e-mail transmission. Please note that all e-mail communications to and from the Julius Baer Group may be monitored. This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: IDMSMSVA
"Chris,

RO12844 has a pre-req of RO11237, which has a pre-req of RO09452. We
were in a similar situation with another fix which had RO09452 as a
pre-req. CA's advice was 'apply all the changes, or it's on your own
head'. That was a fix to RHDCOESA though - I suspect (and it's just my
feeling) that you could get away with the new MSVA without having all
the other RO09452 modules in place.

I think I'm saying the same thing as your 'CA reliable source'
CAIRIM can be run to refresh MSVA with the CV up. No problem there. Any
batch job which tries an LMP key check at the same time as MSVA is
being refreshed (i.e. while CAIRIM is running) will S0C1. Once the new
MSVA is loaded, everything should be fine. If the batch job doesn't
issue an LMP key check while CAIRIM is running, it'll be OK.


Iain Robertson
BT Operate, Senior DBA
Email: iain.dk.robertson@bt.com
=20
-----Original Message-----
From: IDMS Public Discussion Forum=20
Subject: Re: [IDMS-L] IDMSMSVA
=20
Thanks Iain.
=20
But I am really talking about using the new IDMSMSVA with an=20
SP0 wthout RO09452 applied. RO09452 introduced changes to=20
IDMSMVSA plus a whole load of updates to ordinary loadlib=20
modules. Our current system is without RO09452 and I need=20
that one to run from ist own loadlib but with the new=20
IDMSMSVA in LPA. It is running so far without a problem. I=20
shall cross my fingers.
=20
""Ca reliable source"" also says that you only experience the=20
batch abends during the CAIRIM itself with the CV up. Your=20
mail implies otherwise - or does it?
=20
Chris=20
=20
-----Original Message-----
From: IDMS Public Discussion Forum=20
Subject: Re: IDMSMSVA
=20
Chris,
=20
We're running the latest IDMSMSVA (as delivered by RO12844)=20
on our SP0 R17 CVs.
No problems so far (crosses fingers, touches wood).
These are SP0 CVs with PTFs applied, including RO09452.
=20
We had the test version of RO12844 for a problem we hit on=20
test and on our UTE system - we saw S378 abends on batch jobs.
=20
We've been told by CA that it is possible to bring the new=20
IDMSMSVA in with CVs up.
There should be no batch (CV or local mode) running, as if=20
they try to do an LMP key check at the exact moment MSVA is=20
being refreshed, they'll fail with a S0C1
=20
Iain Robertson
BT Operate, Senior DBA
Email: iain.dk.robertson@bt.com
=20
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: IDMSMSVA
"Chris,

RO12844 has a pre-req of RO11237, which has a pre-req of RO09452. We
were in a similar situation with another fix which had RO09452 as a
pre-req. CA's advice was 'apply all the changes, or it's on your own
head'. That was a fix to RHDCOESA though - I suspect (and it's just my
feeling) that you could get away with the new MSVA without having all
the other RO09452 modules in place.

I think I'm saying the same thing as your 'CA reliable source'
CAIRIM can be run to refresh MSVA with the CV up. No problem there. Any
batch job which tries an LMP key check at the same time as MSVA is
being refreshed (i.e. while CAIRIM is running) will S0C1. Once the new
MSVA is loaded, everything should be fine. If the batch job doesn't
issue an LMP key check while CAIRIM is running, it'll be OK.


Iain Robertson
BT Operate, Senior DBA
Email: iain.dk.robertson@bt.com

-----Original Message-----
From: IDMS Public Discussion Forum
Subject: Re: [IDMS-L] IDMSMSVA

Thanks Iain.

But I am really talking about using the new IDMSMSVA with an
SP0 wthout RO09452 applied. RO09452 introduced changes to
IDMSMVSA plus a whole load of updates to ordinary loadlib
modules. Our current system is without RO09452 and I need
that one to run from ist own loadlib but with the new
IDMSMSVA in LPA. It is running so far without a problem. I
shall cross my fingers.

""Ca reliable source"" also says that you only experience the
batch abends during the CAIRIM itself with the CV up. Your
mail implies otherwise - or does it?

Chris

-----Original Message-----
From: IDMS Public Discussion Forum
Subject: Re: IDMSMSVA

Chris,

We're running the latest IDMSMSVA (as delivered by RO12844)
on our SP0 R17 CVs.
No problems so far (crosses fingers, touches wood).
These are SP0 CVs with PTFs applied, including RO09452.

We had the test version of RO12844 for a problem we hit on
test and on our UTE system - we saw S378 abends on batch jobs.

We've been told by CA that it is possible to bring the new
IDMSMSVA in with CVs up.
There should be no batch (CV or local mode) running, as if
they try to do an LMP key check at the exact moment MSVA is
being refreshed, they'll fail with a S0C1

Iain Robertson
BT Operate, Senior DBA
Email: iain.dk.robertson@bt.com
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Dialog/modules cleanup
"If your program pools are large enough to hold all of the programs (i.e. th=
ey never reach 100% full) then you can get a list of all the programs that =
have been used since the CV started up by doing DCMT displays of the progra=
m pools. Doing this over several CV outages should get you a list of all t=
he active programs. =20

You can then compare this list to a list of dictionary load modules.

Outcomes