ca.portal.admin

Re:Re: z/os 1.11

Discussion created by ca.portal.admin on Aug 20, 2010
Short answer - Yes.

Long answer - You can find this info in CA Support Online by following
the
compatibilities link. It will lead you to APAR GI93034 which states R16
is
compatible with z/OS 1.11, but with caveats. You must also look at
QI82743
(details about 'ALLOWCSAUSERKEY') and RO20143 (details about 'VSM
USEZOSV1R9RULES').

We are R16 SP4 and have successfully tested with z/OS 1.11 in VM guest
and
isolated environments. We will be upgrading our development systems to
1.11
this weekend.

Thanks - Tom W
413-229-5072 (Telecommuter)

Team Mail: CID_OLTP_IDMS
Remedy CTI: SOFTWARE / DATABASE / IDMS
Remedy Group: CV IDMS SUPPORT
Theme Song: ""Been Down So Long, Look Like Up To Me""



""Barta, Michael""
<Michael.Barta@IN
FOCROSSING.COM>
To
Sent by: IDMS IDMS-L@LISTSERV.IUASSN.COM
Public Discussion
cc
Forum
<IDMS-L@LISTSERV.
Subject
IUASSN.COM> z/os 1.11


08/20/2010 09:26
AM


Please respond to
IDMS Public
Discussion Forum
<IDMS-L@LISTSERV.
IUASSN.COM>






Does anyone know if IDMS Rel. 16 SP05 is z/OS 1.11 certified?



Michael J. Barta

Mainframe Database || Infocrossing, a Wipro Company || 11707 Miracle
Hills Drive, Omaha NE, 68154|| ': 402.496.8564 ||7: 402.496.8676 || ::
michael.barta@infocrossing.com **Think Green - Please print
responsibly**





Confidentiality Note: This e-mail, including any attachment to it, may
contain material that is confidential, proprietary, privileged and/or
""Protected Health Information,"" within the meaning of the regulations
under
the Health Insurance Portability & Accountability Act as amended. If it
is
not clear that you are the intended recipient, you are hereby notified
that
you have received this transmittal in error, and any review,
dissemination,
distribution or copying of this e-mail, including any attachment to it,
is
strictly prohibited. If you have received this e-mail in error, please
immediately return it to the sender and delete it from your system.
Thank
you.

Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or ""Protected Health Information,"" within the meaning of the regulations under the Health Insurance Portability & Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Question about user exit #1 - signon exit
"Here is what my testing showed:

1) User exit #1 is invoked only when RHDCSNON is explicitly called. It is not invoked for the automatic UCF signons.

2) User exits #28 and #29 (security exits) are invoked for all signons, both explicit and automatic. This appears to be true regardless of whether or not resource type SGON in the RHDCSRTT table is secured. Note that both of these exits are invoked before the signon actually occurs, so some things you want may not exist yet.

3) I was unable to discover a user exit that could be invoked after an automatic signon.

For geeks only: I was able to solve my problem using exit #29. I need to modify the autotask in the LTE. Although the LTE is not yet available, SRBSGLTT points to the ""address of LTE signing on"". This seems to always be the LTE that is later assigned, so I modify it. This is working fine on test. If anyone knows of any reason not to do this, I would sure appreciate hearing from you before we implement this in production.

Outcomes