ca.portal.admin

Re:Another SVC ""learning opportunity""

Discussion created by ca.portal.admin on May 7, 2009
Do not, under any circumstances, do a refresh of your current production SVC while the CV's are up. It will sever all batch, CICS, and UCF connections to the CV's. The only solution is to cycle all of the CV's.

Gaining wisdom the hard way,

Kay Rozeboom
State of Iowa
Information Technology Enterprise
Department of Administrative Services
Telephone: 515.281.6139 Fax: 515.281.6137
Email: Kay.Rozeboom@Iowa.Gov
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
"the ""truth"" about SVCs"
"when an SVC is loaded into memory (via CAIRIM) - within the load module in
memory is an array of slots (255?) that hold addresses of IDMS address
spaces(fileld as the CV starts up) - batch / UCF / other ""external"" access
looks in this array in memory to find the CVs

there are as many ""arrays"" as there are SVCs in am LPAR - each external
entity knows what SVC to look for - and therefore walks this array to find
the address of the desired CV

so when a SVC is reloaded - this table is overlaid with low values - which
is why ""external"" requests cannot find the CV - internal tasks (vtam?
autotasks?) might not be affected


i only know this be cause one of our systems has a ""courtesy"" program -
the app on CV A jumps to CV B - but before it does - it calls this
""courtesy"" program to walk the SVC in memory to look to see if the address
in slot XX+1 (the slot for CV# XX) is empty - if it IS empty - it returns
a message to the calling program ""Sorry - CV XX is not available"" (rather
than try the connection and get a fugly message) . We found that the
location (and sometimes size) of this array of slots has changed from
release to release (going back to pre 12 days)

The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
"the ""truth"" about SVCs"
"when an SVC is loaded into memory (via CAIRIM) - within the load module in
memory is an array of slots (255?) that hold addresses of IDMS address
spaces(fileld as the CV starts up) - batch / UCF / other ""external"" access
looks in this array in memory to find the CVs

there are as many ""arrays"" as there are SVCs in am LPAR - each external
entity knows what SVC to look for - and therefore walks this array to find
the address of the desired CV

so when a SVC is reloaded - this table is overlaid with low values - which
is why ""external"" requests cannot find the CV - internal tasks (vtam?
autotasks?) might not be affected


i only know this be cause one of our systems has a ""courtesy"" program -
the app on CV A jumps to CV B - but before it does - it calls this
""courtesy"" program to walk the SVC in memory to look to see if the address
in slot XX+1 (the slot for CV# XX) is empty - if it IS empty - it returns
a message to the calling program ""Sorry - CV XX is not available"" (rather
than try the connection and get a fugly message) . We found that the
location (and sometimes size) of this array of slots has changed from
release to release (going back to pre 12 days)

The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
FW: R17 upgrade - SVC problem
"Kay,=20

=20

Now I see your problem resolved, I believe I can confirm the solution.
We had the same issue with the initial install of the R16 SVC. Prior to
R16, we had the R14 and R15 SVCs loaded. Since there were no more R14
CVs running in test, I replaced the R14 SVC with the R16 SVC in CAIRIM
and then neither the R15 nor the R16 CVs would start. Problem was solved
by adding the line:=20

=20

PRODUCT(CA-SECURITY/INIT) VERSION(S910) INIT(S910INIT)

=20

To CAIRIM. =20

=20

You should be good to go. I didn't twig on this earlier because we
haven't yet got R17 started.=20

=20

=20

Nigel Salway

Senior Analyst

1900 Albert Street

Regina, SK S4P 4K8

Telephone: (306) 761-4063 =20

Fax: (306) 761-4141 =20

=20

CONFIDENTIALITY NOTICE: Proprietary/Confidential Information belonging
to CGI Group Inc. and its affiliates may be contained in this message.
If you are not a recipient indicated or intended in this message (or
responsible for delivery of this message to such person), or you think
for any reason that this message may have been addressed to you in
error, you may not use or copy or deliver this message to anyone else.
In such case, you should destroy this message and are asked to notify
the sender by reply email.

=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
FW: R17 upgrade - SVC problem
"Kay,



Now I see your problem resolved, I believe I can confirm the solution.
We had the same issue with the initial install of the R16 SVC. Prior to
R16, we had the R14 and R15 SVCs loaded. Since there were no more R14
CVs running in test, I replaced the R14 SVC with the R16 SVC in CAIRIM
and then neither the R15 nor the R16 CVs would start. Problem was solved
by adding the line:



PRODUCT(CA-SECURITY/INIT) VERSION(S910) INIT(S910INIT)



To CAIRIM.



You should be good to go. I didn't twig on this earlier because we
haven't yet got R17 started.





Nigel Salway

Senior Analyst

1900 Albert Street

Regina, SK S4P 4K8

Telephone: (306) 761-4063

Fax: (306) 761-4141



CONFIDENTIALITY NOTICE: Proprietary/Confidential Information belonging
to CGI Group Inc. and its affiliates may be contained in this message.
If you are not a recipient indicated or intended in this message (or
responsible for delivery of this message to such person), or you think
for any reason that this message may have been addressed to you in
error, you may not use or copy or deliver this message to anyone else.
In such case, you should destroy this message and are asked to notify
the sender by reply email.


"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: R17 upgrade - SVC problem
"Nigel,

Do you not have the CA90's load library in linklist?

Steve=20

Outcomes