SysStatusSFDataPending after upgrade

This tag is independent for the "tier 1" and "tier 2" (e.g. the "tier 2" will not set this simply because it was set in the "tier 1"; it will only be set if it applies to sources directly sending to the "tier 2"), so treat them as separate issues.

There aren't any system tags which would help isolate the specific source still reporting store-forward data. You might query for "full" retrieval on "SysStatusSFDataPending" to see if it has changed at all since it first became "true"--if it has, manually comparing those timestamps with OCMC Logger messages reporting connections could help you isolate the specific source. 

Not very convenient, but you can also check the contents of each store-forward folder on the source system looking for the one(s) with "original.dat" (and potentially, "original-N.dat") files--these will be in the subfolder "A000000_001". Some may also have an "Events" subfolder with it's own "A000000_001" subfolder. 

I did compare with one 2023 R2 (RTM) test system and I see "SysStatusSFDataPending" working as expected (e.g. sometimes NULL when first starting up, goes to "0" quickly, goes to "1" quickly, then returns to "0" not long after that and stays that way for a long time). One potential difference compared to your system is that all of the sources in my scenario are also on 2023 R2 and are using the new "HCAL" (gRPC-based) and not the "HCAL (classic)" (the older WCF-based one). Of course, this isn't supposed to make any difference, but it is an area of related code changes between 2023 and 2023 R2. 

If none of that proves helpful, suggest following up with Tech Support. 

This tag is independent for the "tier 1" and "tier 2" (e.g. the "tier 2" will not set this simply because it was set in the "tier 1"; it will only be set if it applies to sources directly sending to the "tier 2"), so treat them as separate issues.

There aren't any system tags which would help isolate the specific source still reporting store-forward data. You might query for "full" retrieval on "SysStatusSFDataPending" to see if it has changed at all since it first became "true"--if it has, manually comparing those timestamps with OCMC Logger messages reporting connections could help you isolate the specific source. 

Not very convenient, but you can also check the contents of each store-forward folder on the source system looking for the one(s) with "original.dat" (and potentially, "original-N.dat") files--these will be in the subfolder "A000000_001". Some may also have an "Events" subfolder with it's own "A000000_001" subfolder. 

I did compare with one 2023 R2 (RTM) test system and I see "SysStatusSFDataPending" working as expected (e.g. sometimes NULL when first starting up, goes to "0" quickly, goes to "1" quickly, then returns to "0" not long after that and stays that way for a long time). One potential difference compared to your system is that all of the sources in my scenario are also on 2023 R2 and are using the new "HCAL" (gRPC-based) and not the "HCAL (classic)" (the older WCF-based one). Of course, this isn't supposed to make any difference, but it is an area of related code changes between 2023 and 2023 R2. 

If none of that proves helpful, suggest following up with Tech Support. 

Hi Elliott, thank you pointing in the right direction. After spending some time inspecting store-forward folders, I could see that both the T1 and T2 Historian had a "original.dat" file in the "/StoreForward/LocalAutoSummaryReplication" folder. To resolve the problem I had to do the following:

1. Stop & disable Historian.

2. Delete the "LocalAutoSummaryReplication" folder.

3. Start & enable Historian.

4. Verify that the "LocalAutoSummaryReplication" is recreated and check logs.