ca.portal.admin

Re:Re: S0F8 with Date Simulator & ZIIP : R17 0F8 zIIP date

Discussion created by ca.portal.admin on Mar 3, 2010
S0F8-4 problem with ZIIP=3DY explanation.
Date Simulator products require PTF RI05855 to be applied to the
RHDCOMVS
module and to the startup module if you do not use RHDCOMVS in your
startup.
This PTF was created for Date Simulator products which require that all
STORE CLOCK instructions issue an SVC that calls the DATE SIMULATOR
product.
*
If you are using zIIP processing, our code offloads work to zIIP
processors.
When running with ZIIP=3DY, you are actually running under an SRB and =
not
under
a TCB.
It is ILLEGAL to issue an SVC if you are not running in TCB mode.
Here is a description of S0F8 Reason Code 4.
S0F8 -
Explanation: The issuer of a Supervisor Call (SVC) instruction was
not in
the correct mode to issue the SVC. A hexadecimal reason code in the
RTM2CRC field of the RTM2WA data area explains the error:
=20
Code Explanation
=20
04 The issuer was in a mode other than task control block
(TCB)
mode.
*
Since Date Simulator products require that our STCK instructions be
zapped
with an SVC call, you can NOT run ZIIP=3DY on a CA IDMS CV that is =
using
Date Simulator products.
You will always get S0F8 abends when you have the SVC zap replacing the
STCK (STORE CLOCK) instructions and ZIIP=3DY on the startup parm.
*
CA IDMS CVs that use Date Simulator products must run with ZIIP=3DN.

Edward F McKinney
CA=20
Senior Sustaining Engineer
CA-IDMS
Tel: +1-508-628-8171
Fax: +1-508-628-8715
Edward.McKinney@ca.com
"
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: WTOREXIT under 17.0
"My parm list is similar

//DLP1CV EXEC PGM=IDMSDC,REGION=0M,TIME=1440,
// PARM=('S=80',
// 'MT=N',
// 'WTOEXIT=WTOEXIT',
// 'WTOREXIT=WTOREXIT',
// 'DMCL=DLP1DMCL')

Everything works with this configuration WITHOUT DB-SYNCHRO.

With this configuration and DB-SYNCHRO active the CV hangs. A series of
SYNCHRO messages appear

DB905004
DB905005
DB905008
DB905006

Then they repeat until I cancel the region.

When I run the ""old"" way (WTO/WTOR linked with the startup everything works
like it is supposed to.

Messages 4 and 5 are Synchro messages. 8 and 6 are for DB-SHARE. We don't
use the SHARE component in this environment. I'm going to try to deactivate
it and see what happens.

What my gut is telling me is that I might have an affinity problem. There
is a recently published APAR for the WTOEXIT that talks about this. We
found this while testing multitasking under 16.0. We started getting ACF2
violations from the journal submit when MT was turned on. The 16.0 version
takes about the problem extending beyond ACF2. I see that the same fix was
published for 17. I pulled the 17.0 version yesterday, but haven't
installed it yet. It's on the list of things to do today.

Mark Grindstaff

Outcomes