OnDemand User Group
Support Forums => z/OS Server => Topic started by: hakan_carlberg on December 27, 2010, 06:52:36 AM
-
Hi
I'm running in a Sysplex environment with 4 started task running ARSSOCKD-pgm for one of my OD-instance. 2 are for Intranet and 2 are for Internet(another IP-stack).
If I look in my ARSUSER.ARSSEG-table I see two !! System Logs-tables that are in use ?!?!
I didn't expect that!!!!
If I run a query:
"
SELECT * FROM ARSUSER.ARSSEG
WHERE TABLE_NAME LIKE 'SL%'
FETCH FIRST 10 ROWS ONLY
WITH UR;
AGID TABLE_NAME START_DATE STOP_DATE
--+---------+-------+---------+---------+---------+-
5001 SL2 1114082059 1212401118
5001 SL3 1212401123 1275631463
5001 SL4 1212401123 1245868532
5001 SL5 1275631463 1293456132
5001 SL6 1275631463 1275631463
"
Some other SQL:
"
SELECT TABLE_NAME, INS_ROWS, START_DATE
FROM ARSUSER.ARSSEG
WHERE TABLE_NAME LIKE 'SL%'
FETCH FIRST 10 ROWS ONLY
WITH UR;
---------+---------+---------+---------+---------+-------
TABLE_NAME INS_ROWS START_DATE
---------+---------+---------+---------+---------+-------
SL2 10005432 1114082059
SL3 10003345 1212401123
SL4 10007996 1212401123
SL5 6640223 1275631463
SL6 1 1275631463
"
"
SELECT * FROM ARSUSER.SL6
FETCH FIRST 2 ROWS ONLY WITH UR;
---------+---------+---------+---------+---------+---------+---------+---
TIME_STAMP USERID
---------+---------+---------+---------+---------+---------+---------+---
1275631463 SEIP03PR
DSNE610I NUMBER OF ROWS DISPLAYED IS 1
DSNE612I DATA FOR COLUMN HEADER MSG_TEXT COLUMN NUMBER 5 WAS TRUNCATED
DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100
---------+---------+---------+---------+---------+---------+---------+---
SELECT * FROM ARSUSER.SL5
FETCH FIRST 2 ROWS ONLY WITH UR;
---------+---------+---------+---------+---------+---------+---------+---
TIME_STAMP USERID
---------+---------+---------+---------+---------+---------+---------+---
1275631463 SEKA03PR
1275631464 SEKA03PR
DSNE610I NUMBER OF ROWS DISPLAYED IS 2
"
How can it come that I have 2 active System Logs ?????
Have any of you seen this before ?
Regards
/H Carlberg
-
Hi
since I did cut and paste I lost some columns at my first SQL:
"
SELECT * FROM ARSUSER.ARSSEG
WHERE TABLE_NAME LIKE 'SL%'
FETCH FIRST 10 ROWS ONLY
WITH UR;
-------+---------+---------+---------+---------+--
POST_DATE CLOSED_DATE
-------+---------+---------+---------+---------+--
1114082060 14033
1212401123 14765
1212401123 14420
1275631466 0
1275631466 0
"
regards
/H Carlberg
-
I've seen this before in the Multiplatforms version. I used arstblsp to close the open tables, then let CMOD create a new one. I'm not sure if this happens by design, but I figured it was very unusual -- but after closing the two tables, the problem that was being experienced went away.
-JD.
-
Hakan - are you running arsload NOTCPIP?
No guarantees on this, but if you are, please install PM24351.
PM24351 fixes a serialization problem in a SYSPLEX environment.
Besides fixing the lack of serialization when manipulating cache files, it also fixes the lack of serialization when getting a new segment for an applgrp.
APPLICABLE COMPONENT LEVEL/SU:
R84A PSY UK62063 UP10/12/01 P F011
R841 PSY UK62064 UP10/12/01 P F011
-
Hi,
UK62064 not applied
I've opened an PMR to IBM for this error as well, and waiting for the feedback in that
/H Carlberg
-
How easy would it be for you to go ahead and install that PTF?
I have a nephew who is a veterinarian who always says, "Couldn't hurt, might help." ;D
-
Hi
IBM came back with this answer on my PMR:
"
According to Steen you have instances with different names.
The instance name is used as part of the ENQ RNAME to serialize
application group access, including creating new system logs.
If the instance names are not the same, there is a lack of
serialization, leading to the double system log table creations.
Fortunately there is an easy solution:
In the ars.cfg, you can use ARSMVS_SYSZARSL_INSTANCE= to
specify the instance name to be used in the RNAME.
Pick one of the instance names, and use that in all the ars.cfg files.
For example, specify:
ARSMVS_SYSZARSL_INSTANCE=ARSSTEEN
in all of the ars.cfg files (again, where ARSSTEEN is one of your
instance names).
"
The issue was that I had 1 ARSSOCKD in a LPAR running with one instance-name, and another ARSSOCKD running with a different instance-name. The reason for that is that I one instance is running on another IP-stack, and hence needs another STC-name.
Regards
/H Carlberg