How would multiple segments be opened?

[scott.walsh]

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                                                                               

[Justin Derrick]

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.

[scott.walsh]

Thanks.  I thought of just closing the odd-ball segment.  Might be wise.

[Justin Derrick]

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.

[Greg Ira]

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?

[scott.walsh]

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 

[scott.walsh]

Justin,
   In both environments its a type 30 record.

one is from the zos loader
the other is from an odwek server.

[scott.walsh]

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 

Important: The ARSTBLSP program can run without an active server. The server must be down to update
the System Log table