OnDemand User Group
Support Forums => z/OS Server => Topic started by: mamararj on November 27, 2017, 01:01:04 PM
-
Hello OnDemand User Group.
First time posting for help.
Recently upgraded DB2 to V11 Conversion Mode on z/OS 2.1. At the start of ARSSOCKD, it fails with
a CC=0006.
BPXP011I THREAD 212E2C0000000001, IN PROCESS 83953187, WAS
TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
SCEACT01I STEP ARSSOCKD ARSSOCKD CPU 00:00:00.06 CC=0006
IEF404I ARSSOCKD - ENDED - TIME=11.27.10
There are no other messages in the syslog or db2 messages I can see.
Also, the UID is not running UID=0.
We upgrade on Sandbox with no issue and experience this on dev.
Has anyone encountered this issue?
Appreciate any assistance or direction.
Regards,
Ray Mamaradlo
-
Hello Mamararj -
That return code doesn't help much, is very generic.
What level of 8.5 are you running? 8.5.0.what ?
Also, paste in here what your OMVS settings are. I doubt that's the problem but what is the output from the operator command D OMVS,O (display OMVS options)
The easiest way to start to debug would be with an ODBC trace as DB2 is what has changed.
To take an ODBC trace:
Add the following entries [placed in the common section] to the
version of cli.ini pointed to by the DSNAOINI DD for ARSSOCKD:
APPLTRACEFILENAME=/tmp/arsodbctrace
APPLTRACE=1
An example cli.ini file:
[COMMON]
MVSDEFAULTSSID=DSNO
PLANNAME=DSNACLI
APPLTRACEFILENAME=/tmp/arsodbctrace
APPLTRACE=1
The output can be found in the HFS file pointed to by the
APPLTRACEFILENAME value.
Ed
-
Hi Ed.
Fortunately, we figured out the root cause. The DB2 loadlib and DBRMLIB were out-of-sync. In prior DB2 maintanence upgrades, we would get a -805 for package DSNCLIC1 and cc=6, and we know to rebind the DSNACLI packages. In this case, we only got the cc=6. After tracing our steps, figured out that our runtime dbrmlib and smpe db2 dbrmlib were out-of-sync with changes in DSN@LIF4 member. After rebinding with the smpe dbrmlib, ARSSOCKD successfully started and its operational.
Thanks for your help on the issue and with setting an ODBC trace. I'll put this in my toolbox.
Regards,
Ray Mamaradlo
Answers to questions
Ondemand 8.5.0.6
D OMVS,O
RESPONSE=A0
BPXO043I 09.12.27 DISPLAY OMVS 505
OMVS 0011 ACTIVE OMVS=(00,A0)
CURRENT UNIX CONFIGURATION SETTINGS:
MAXPROCSYS = 5000 MAXPROCUSER = 200
MAXFILEPROC = 64000 MAXFILESIZE = NOLIMIT
MAXCPUTIME = 1000 MAXUIDS = 300
MAXPTYS = 800 MAXIOBUFUSER = 2048
MAXMMAPAREA = 40960 MAXASSIZE = 41943040
MAXTHREADS = 10000 MAXTHREADTASKS = 5000
MAXCORESIZE = 4194304 MAXSHAREPAGES = 10000000
IPCMSGQBYTES = 1048576 IPCMSGQMNUM = 20000
IPCMSGNIDS = 20000 IPCSEMNIDS = 20000
IPCSEMNOPS = 32767 IPCSEMNSEMS = 32767
IPCSHMMPAGES = 25600 IPCSHMNIDS = 500
IPCSHMNSEGS = 100 IPCSHMSPAGES = 2621440
SUPERUSER = BPXROOT FORKCOPY = COPY
STEPLIBLIST =
USERIDALIASTABLE=
PRIORITYPG VALUES: NONE
PRIORITYGOAL VALUES: NONE
MAXQUEUEDSIGS = 1000 SHRLIBRGNSIZE = 67108864
SHRLIBMAXPAGES = 4096 VERSION = RESA04
SYSCALL COUNTS = NO TTYGROUP = TTY
SYSPLEX = YES BRLM SERVER = N/A
LIMMSG = NONE AUTOCVT = OFF
RESOLVER PROC = RESOLVER LOSTMSG = ON
AUTHPGMLIST = NONE
SWA = BELOW NONEMPTYMOUNTPT = WARN
SERV_LINKLIB =
SERV_LPALIB =
ALTROOT =
MAXUSERMOUNTSYS = 30 MAXUSERMOUNTUSER= 3
MAXPIPEUSER = 8730 PWT = ENV
UMASK = NONE
-
Glad you got it resolved.
Were you to continue on z I would make the following recommendations:
MAXASSIZE = 41943040
change to
MAXASSIZE = 2147483647
and make
LIMMSG = ALL
and
SWA = ABOVE
_______
Something to consider if you do end up moving forward.
Ed
-
Thanks for the tip...Ed.
Regards,
Ray Mamaradlo