PMGETARCHIVEEND(3)

💖 PMGETARCHIVEEND 💖

okay bestie, so this one is a libpcp manual page — PMGETARCHIVEEND(3) — from the Library Functions Manual, and it's literally here to help you find the logical end of file for a set of archives. no cap. let's get into it 🦋

---

✨ NAME ✨

pmGetArchiveEnd — locate logical end of file for a set of archives

---

🌸 C SYNOPSIS 🌸

#include <pcp/pmapi.h>

int pmGetArchiveEnd(struct timespec *tp);

cc ... -lpcp

---

💅 DESCRIPTION 💅

so. assuming your current PMAPI context is associated with a set of archives, pmGetArchiveEnd will attempt to find the logical end of file (like, right after the last complete record in the set of archives), and hand you back the last recorded timestamp via tp. 🎀

that timestamp? you can pass it to pmSetMode(3) to reliably position the context at the last valid archive record, e.g. when you're getting ready to read in reverse chronological order. iconic behavior honestly.

for archives that are not concurrently being written, the physical end of file and the logical end of file are co-incident. they're the same thing. twinning. 💖

but — and this is the plot twist — if an archive is being written by pmlogger(1) at the same time an application is trying to read the archive, the logical end of file may be before the physical end of file, because of write buffering that is not aligned with the logical record boundaries. so like, the vibes are off, and the file looks longer than it logically is. 🙈

pmGetArchiveEnd returns an error less than zero if the context is neither valid, nor associated with a set of archives, or if the set of archives is seriously corrupted. otherwise, the return value is 0 if there has been no change of state since the last call, or 1 if the logical end of file has advanced since the last call. so 1 = it grew, 0 = same as before, <0 = we're in trouble. 💀

in the absence of an error, the result returned via tp is well-defined. periodt.

both pmGetArchiveEnd preserve the positioning state of the archive file prior to this function call. so it doesn't mess with where you were. queen shit. 👑

---

🌈 COMPATIBILITY 🌈

prior to PCP 7.0 and libpcp.so.4, the tp argument was a struct timeval. yes, a whole different type. 😭

to support PMAPI transition, the old interface and semantics can be used if applications are linked with libpcp.so.3 or recompiled with -DPMAPI_VERSION=2.

also, for a time in PCP 6.x there was a routine with the same semantics as the current pmGetArchiveEnd called pmGetHighResArchiveEnd, although this is now deprecated and compile-time support for pmGetHighResArchiveEnd will be removed in a future release. so if you're still using it… bestie. let her go. 🫶

---

🎀 DIAGNOSTICS 🎀

• PM_ERR_NOCONTEXT — the current PMAPI context is either invalid, or not associated with a set of archives
• PM_ERR_LOGREC — the set of archives is sufficiently damaged, that not a single valid record can be found

---

⭐ PCP ENVIRONMENT ⭐

environment variables with the prefix PCP_ are used to parameterize the file and directory names used by PCP. on each installation, the file /etc/pcp.conf contains the local values for these variables. 🌸

the $PCP_CONF variable may be used to specify an alternative configuration file, as described in pcp.conf(5).

values for these variables may be obtained programmatically using the pmGetConfig(3) function. iykyk.

---

🦋 SEE ALSO 🦋

PMAPI(3), pmFetch(3), pmFetchArchive(3), pmGetArchiveLabel(3), pmGetConfig(3), pmSetMode(3), pcp.conf(5) and pcp.env(5).

---

that's the whole page bestie, no skips, no gaps 💜 this lil masterpiece comes to you from Performance Co-Pilot — aka PCP — and it's PMGETARCHIVEEND(3) out of the Library Functions Manual. go read your archives, main character. 💅✨