PMFETCHARCHIVE(3)

💖 PMFETCHARCHIVE(3) 💖 — Library Functions Manual

okay bestie, sit down, hydrate, and let's talk about pmFetchArchive and pmFetchHighResArchive — two lil functions whose entire job is getting performance metric values directly from archives. yes, straight out of the archive, no middleman. slay. 🎀

---

✨ NAME ✨

pmFetchArchive, pmFetchHighResArchive — get performance metric values directly from archives. 🦋

---

✨ C SYNOPSIS ✨

#include <pcp/pmapi.h>

int pmFetchArchive(pmResult **result);
int pmFetchHighResArchive(pmHighResResult **result);

cc ... -lpcp

---

✨ DESCRIPTION ✨

so pmFetchArchive and pmFetchHighResArchive are literally variants of the pmFetch(3) and pmFetchHighRes(3) interfaces, but with one big rule: you can only use them when the current Performance Metrics Application Programming Interface (PMAPI) context is associated with a set of archives. no archive context? no vibes. it's giving "read the room." 😭

the result gets instantiated with all of the metrics (and instances) from the next archive record. so there's no notion of a list of desired metrics — like, none — and the instance profile of the PMAPI context is ignored. we don't ask, we just take everything. periodt. 💅

now, plot twist 🫶: both pmFetchArchive and pmFetchHighResArchive may return a result in which numpmid is zero. that's a <mark> record, and it means there's a temporal discontinuity in the time series of performance metrics. dramatic, i know. this can happen at the boundary between archives in a set, or if the archive associated with the current PMAPI context was created using pmlogextract(1) to concatenate two or more PCP archives — in that case the <mark> record marks a point in time between the end of one input archive and the start of the next input archive. it's the little gap between eras, bestie. ⭐

the expectation is that pmFetchArchive and pmFetchHighResArchive get used to create utilities that scan sets of archives, while the more common access to the archives would be via the pmFetch and pmFetchHighRes interfaces. different tools, different jobs. iykyk. 💜

want to skip records within the set of archives? okay so use pmSetMode(3) or pmSetModeHighRes(3) to change the collection time within the current PMAPI context, then call either pmFetchArchive or pmFetchHighResArchive. that's it, that's the move. 🌸

🚨 bestie, LISTEN. the result returned by both pmFetchArchive and pmFetchHighResArchive is dynamically allocated, and it must be released using either pmFreeResult(3) or pmFreeHighResResult(3) — but not free(3). not free(3). i'm so serious. do not do it. 🙈

if you want further details, go peek at pmFetch(3), pmFetchHighRes(3), pmFreeResult(3) and pmFreeHighResResult(3). they have the lore. 📚

also, both pmFetchArchive and pmFetchHighResArchive return zero on success. zero is the good number here. 👑

---

✨ DIAGNOSTICS ✨

• PM_ERR_NOTARCHIVE — the current PMAPI context is not associated with a set of archives. (yeah. that's the one. the archive-less crime.) 💀

---

✨ SEE ALSO ✨

PMAPI(3), pmFetchHighRes(3), pmSetModeHighRes(3), pmFreeHighResResult(3), pmFetch(3), pmFreeResult(3), pmNewContext(3), pmSetMode(3) and pmTrimNameSpace(3). 🌈

---

and that's the whole page, bestie!! 🫶 this lil manual page came to you from Performance Co-Pilot / PCP — the PMFETCHARCHIVE(3) era — and honestly? iconic. go read your archives, free your results properly, and stay hydrated. mwah. 💖✨🎀