PMGETARCHIVEEND(3)

🌸 PMGETARCHIVEEND 🌸

okay bestie, so the manual page we're vibing with today is pmGetArchiveEnd(3) — it lives in the Library Functions Manual, and honestly? it's giving "let me find where the archive actually ends" energy. 🎀

---

✨ NAME ✨

pmGetArchiveEnd, pmGetHighResArchiveEnd — locate logical end of file for a set of archives 🦋

---

✨ C SYNOPSIS ✨

#include <pcp/pmapi.h>

int pmGetArchiveEnd(struct timeval *tp);
int pmGetHighResArchiveEnd(struct timespec *tp);

cc ... -lpcp

---

✨ DESCRIPTION ✨

so here's the vibe 💅 — assuming the current PMAPI context is associated with a set of archives, pmGetArchiveEnd and pmGetHighResArchiveEnd will attempt to find the logical end of file (right after the last complete record in the set of archives), and hand you back the last recorded timestamp via tp. 📌

and like… that timestamp is usable, okay? you can pass it to pmSetMode(3) or pmSetModeHighRes(3) to reliably position the context at the last valid archive record — for example, in preparation for subsequent reading in reverse chronological order. main character energy, truly. 👑

okay now, for archives that are not concurrently being written, the physical end of file and the logical end of file are co-incident. no drama, they line up. ✨

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 that archive, then the logical end of file may be before the physical end of file. why? because of write buffering that isn't aligned with the logical record boundaries. it's giving "the file looks longer than it is" fr fr.

pmGetArchiveEnd and pmGetHighResArchiveEnd return 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
• 1 — if the logical end of file has advanced since the last call 🚀

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

both pmGetArchiveEnd and pmGetHighResArchiveEnd preserve the positioning state of the archive file prior to this function call. they're polite like that. 🌸

---

✨ 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), pmFetchHighRes(3), pmFetchHighResArchive(3), pmGetArchiveLabel(3), pmGetConfig(3), pmGetHighResArchiveLabel(3), pmSetMode(3), pmSetModeHighRes(3), pcp.conf(5) and pcp.env(5). 💖

---

and that's the whole page bestie — brought to you by the absolute icons at Performance Co-Pilot (that's the PCP crew, the source of this little gem, PMGETARCHIVEEND(3)), who wrote it all down so we didn't have to. slay, honestly. ⭐👑💜