OnDemand User Group
Support Forums => z/OS Server => Topic started by: scott.walsh on January 29, 2024, 07:00:07 AM
-
I have question: We run CMOD on a sysplex with both ARSSOCKD running on 2 different LPARS as well as ARSLOAD running on 2 different LPARS. In looking at normal checking of the system we came across this anomaly. 2 different SEGMENTS open for the System Log. One record put into it. Odd that SL299 was opened without closing SL298. This installation stores the System log in CACHE. All Production AG data is in OAM.
This happened in both the Production Instance and the Dev instance. 2 different z/os datacenters. Prod on one, Dev on another. The system log only hangs around for 3-4 weeks (???) so it will probably go away on it's own. inquirying minds...
---------+---------+---------+---------+---------+---------+---------+---------+---------+---------+---------+--------
AG_NAME TABLE_NAME DATABASE_NAME START_DT CLOSED_DT LAST_UPDATE_DT INS_ROWS
---------+---------+---------+---------+---------+---------+---------+---------+---------+---------+---------+--------
System Log SL297 ARSDBAS8 2024-01-08 2024-01-23 2024-01-23-03.12.41.297427 10028002
System Log SL298 ARSDBAS8 2024-01-23 ---------- 2024-01-29-13.51.12.388742 4047185
System Log SL299 ARSDBAS8 2024-01-23 ---------- 2024-01-23-03.12.57.130152 1
DSNE610I NUMBER OF ROWS DISPLAYED IS 3
-
I've seen something similar, but more than a decade ago on an AIX server -- there were strange errors in db2diag.log, and after chasing it down for a day, it turned out two System Log tables were open. I closed it with the arstblsp command, and the issues went away immedately.
Having said that, z/OS / sysplex / LPARs are a totally different beast, but I just thought I'd mention the arstblsp command (not sure what the equivalent is in z/OS).
-JD.
-
Thanks. I thought of just closing the odd-ball segment. Might be wise.
-
Check with IBM - I'm not sure if this is normal behaviour for your config. Maybe Ed will see this and reply.
Also, I'm morbidly curious about the ONE inserted row in your database... Let us know what's in there.
-JD.
-
Would be interesting to see if both SL298 and SL299 were opened at the same time. Definitely looks like SL299 was opened right after SL297 was closed. If both were opened simultaneously that would tell me some sort of CMOD hiccup. If SL298 was opened first maybe something locked it up temporarily?
-
Seconds apart. Both the Prod instance and the Dev instance run on Parallel LPARS. (arssockd/loaders on two lpars for balancing). Possible that while loading at the exact same time, they both needed a new log. Only ONE record in the second segment.
the first one is PROD:
AG_NAME TABLE_NAME START_DATE START_TS CLOSED_DT INS_ROWS
---------+---------+---------+---------+---------+---------+---------+---------+---------+---------+---------+----
System Log SL297 1704756579 2024-01-08-23.29.39.030526 2024-01-23 10028002
System Log SL298 1705979559 2024-01-23-03.12.39.293026 ---------- 5101181
System Log SL299 1705979562 2024-01-23-03.12.42.171906 ---------- 1
Dev did the same thing:
AGID TABLE_NAME START_DATE START_DT POST_DT CLOSED_DT INS_ROWS
----+---------+---------+---------+---------+---------+---------+---------+---------+---------+---------+---------+-------
30798 SL138 1705461323 2024-01-17-03.15.23.618709 2024-01-17 ---------- 1977724
30798 SL139 1705461321 2024-01-17-03.15.21.378956 2024-01-17 ---------- 1
30798 SL137 1703798855 2023-12-28-21.27.35.117586 2023-12-28 2024-01-17 2501758
-
Justin,
In both environments its a type 30 record.
one is from the zos loader
the other is from an odwek server.
-
Well, since one record segment was an anomaly, I thought I'd just close it. I think Justin mentioned that too.
arstblsp -a 1 -I CMODU -g "System Log" -t SL139
Worked just fine because the instance wasn't using it.
AG_NAME TABLE_NAME START_DATE START_DT POST_DT CLOSED_DT
------+---------+---------+---------+---------+---------+---------+---------+---------+---------+-----
System Log SL138 1705461323 2024-01-17-03.15.23.618709 2024-01-17 ----------
System Log SL139 1705461321 2024-01-17-03.15.21.378956 2024-01-17 2024-01-16
System Log SL137 1703798855 2023-12-28-21.27.35.117586 2023-12-28 2024-01-17
From the 10.5 manual. might be true if you wanted to close the ACTIVE segment, but not in this case :D
Important: The ARSTBLSP program can run without an active server. The server must be down to update
the System Log table