histsdk/docs/reverse-engineering/wcf-status-localhost.md

WCF Status Evidence

Commands:

dotnet run --no-build --project tools\AVEVA.Historian.ReverseEngineering -- wcf-status localhost 32568
dotnet run --no-build --project tools\AVEVA.Historian.ReverseEngineering -- wcf-status localhost 32568 Version

Confirmed:

• The local status endpoint is net.tcp://localhost:32568/Stat.
• IStatusServiceContract2 is a static WCF contract named Stat in namespace aa. The managed definitions now include GetSystemParameter, GETHI, PNGS, and PNGP.
• GetInterfaceVersion returns code 0, version 0 on the local 2020 install.
• The decompiled CStatusConnectionWCF.GetServerTime implementation is a WCF-path stub that returns success without calling the Stat service. The managed direct call likewise returns code 0 with size 0 and no buffer.

Observed sanitized localhost results:

• GetSystemTimeZoneName(handle: 0) returns code 4 and no value.
• IsDBCaseSensitive(handle: 0) returns code 4.
• GetSystemParameter(handle: 0, "Version") returns false with no error buffer.

Re-tested 2026-06-20 with a real authenticated client handle (full Open2 auth chain), not handle: 0:

• GetSystemParameter(handle, "HistorianVersion") → real version string (works; shipped as GetSystemParameterAsync).
• GetSystemTimeZoneName(handle) → return code 0x00000000 (success) but an empty value string. Same channel/handle that makes GetSystemParameter return real data, so this is the op's own behavior, not an auth/marshalling gap. GetSystemTimeZoneName is a member of the GetServerTime stub family: the 2020 WCF path returns success without producing a value (the native client computes the zone locally). It only becomes a real round-trip on the 2023 R2 gRPC front door (Status.GetSystemTimeZoneName), which is absent on this box.

Interpretation:

• Stat endpoint routing is confirmed, but status operations that require a real client handle are not usable until managed session open is solved.
• GetServerTime should not be promoted into the public SDK as a real server time call from this WCF path; native evidence shows it is a no-op stub here.
• GetServerTimeZoneAsync (roadmap R1.3) is NOT a trivial WCF op on 2020 — it is a stub returning empty. Do not ship it over the 2020 WCF transport. Deliver it only against a live 2023 R2 gRPC server. Reclassified in docs/plans/hcal-roadmap.md.

GETRP / GetRuntimeParameter (roadmap R1.2) — DONE, live-verified 2026-06-20

Captured the native HistorianAccess.GetRuntimeParameter(List<string>, out List<object>) WCF traffic with scripts/Capture-RuntimeParam.ps1 (instrument-wcf-{write,read}message). Findings:

• The WCF op is aa/Stat/GETRP — bool GETRP(string handle, byte[] pRequestBuff, out byte[] pResponseBuff, out byte[] errorBuffer), i.e. the same string-handle + request/response-buffer shape as GETHI, not the simple GetSystemParameter(uint, string) shape the roadmap originally assumed.
• The string handle is the Open2 storage-session GUID (the value ParseOpenConnectionResponse reads from outBuff[5..21]), sent UPPERCASE, dash-separated, no braces (ToString("D").ToUpperInvariant()).
• Unlike GETHI (which the earlier probe found blocked), GETRP succeeds from the pure-managed client with that handle: GetRuntimeParameter("HistorianVersion") → 20,0,000,000.
• pRequestBuff = 54 67 01 00 (sig+version) + uint nameCount + per name(uint charCount + UTF-16LE). pResponseBuff = version(1) + uint resultCount + CRetVariant(0x43 VT_BSTR + uint16 payloadLen + uint16 charCount + UTF-16LE).

Shipped as HistorianClient.GetRuntimeParameterAsync(name). See HistorianRuntimeParameterProtocol, golden WcfRuntimeParameterProtocolTests, and the handle-format lead in wcf-string-handle-wall.md §Update (retry GETHI/ExeC uppercased).

R1.3 timezone + R1.4 EventStorageMode — re-confirmed bounded out (2026-06-21)

Both were already classified 2023R2/gRPC-only; re-verified from two fresh angles that corroborate it more strongly than the original op-level probes:

• Runtime DB schema (Runtime.dbo, the server's own source of truth): the SystemParameter table has no timezone parameter and no EventStorageMode (only EventStorageDuration / EventStorageLogPath). The server timezone exists only as per-block storage artifacts (HistoryBlock.TimeZoneOffset = e.g. 240 min, wwTimeZone = e.g. "Eastern Daylight Time") and a TimeZone reference/lookup table; StorageShard.TimeZoneId is NULL. So the timezone is a DST-specific, SQL-only, OS-derived value, not a clean server-config field exposed by any op.
• Parameter-op probe (StringHandleProbeDiagnosticTests.TimezoneAndStorageMode_ParameterProbe): GetSystemParameter and GetRuntimeParameter (GETRP) were asked for every timezone candidate (TimeZone/ServerTimeZone/SystemTimeZone/TimeZoneName/SystemTimeZoneName/TimeStampRule/ ServerTime) and every storage-mode candidate (EventStorageMode/StorageMode/EventStorage/ EventStorageDuration). All returned null (GetSystemParameter) or threw ProtocolEvidenceMissingException (GETRP — non-string/empty response); only the HistorianVersion control returned a value (20,0,000,000). Note: TimeStampRule/EventStorageDuration do exist in the SystemParameter table yet GetSystemParameterAsync returns null for them — the shipped op only surfaces a whitelisted subset (a possible future widening, unrelated to R1.3/R1.4).

Conclusion: R1.3 GetServerTimeZoneAsync and R1.4 GetHistorianInfoAsync (EventStorageMode) are not deliverable as server ops on 2020. The only 2020 route to the timezone is a SQL read of HistoryBlock/TimeZone via ExecuteSqlCommand (R1.1) — a DST-specific value over a different mechanism than the roadmap's Status.GetSystemTimeZoneName. EventStorageMode has no 2020 representation at all (it is a 2023 R2 event-storage-architecture field). Deliver both only against a live 2023 R2 gRPC server.