PMFETCHARCHIVE(3)

💖 PMFETCHARCHIVE 💖

okay bestie, gather round, because we're talking about a library functions manual entry and honestly? she's giving main character energy. this is pmFetchArchive from the Performance Co-Pilot crew, and she does exactly one thing but she does it flawlessly. 🎀

✨ NAME ✨

pmFetchArchive, — get performance metric values directly from archives. no cap. that's the whole vibe. 💅

---

🌸 C SYNOPSIS 🌸

here's the summoning ritual, copy it exactly, do not freestyle:

#include <pcp/pmapi.h>

int pmFetchArchive(pmResult **result);

cc ... -lpcp

link against -lpcp or she will simply not show up to the function call. periodt. 🫶

---

🦋 DESCRIPTION 🦋

so pmFetchArchive is a variant of the pmFetch(3) interface, and the tea is: you can only use her when the current Performance Metrics Application Programming Interface (PMAPI) context is associated with a set of archives. that's the vibe check. if your context isn't archive-coded, she's not answering. 💀

the result gets instantiated with all of the metrics (and instances) from the next archive record. which means — and this is the part that trips people up — there is no notion of a list of desired metrics, and the instance profile of the PMAPI context is ignored. she doesn't want your wishlist. she brings everything. iconic behavior honestly. ✨

lowkey important: pmFetchArchive may return a result in which numpmid is zero. that's a <mark> record, and it indicates a temporal discontinuity in the time series of performance metrics. not a bug, just her being dramatic. 😭

when does that happen? two situations, bestie:

• 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, and 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 expected that pmFetchArchive will be used to create utilities that scan sets of archives, while the more common access to the archives would be via the pmFetch interface. so like… she's the niche girlie for the archive-scanning girlies. 🧚

to skip records within the set of archives, use pmSetMode(3) to change the collection time within the current PMAPI context, then call either pmFetchArchive 🔥

⚠️ big warning, no cap: the result returned by pmFetchArchive is dynamically allocated, and must be released using pmFreeResult(3), but not free(3). do not use free(3). i'm serious. see pmFetch(3) and pmFreeResult(3) for further details.

and the happy ending: pmFetchArchive returns zero on success. slay. 💜

---

🌈 DIAGNOSTICS 🌈

• PM_ERR_NOTARCHIVE — the current PMAPI context is not associated with a set of archives. yeah. she said what she said. 🙈

---

👑 COMPATIBILITY 👑

history lesson time, stay with me:

• Prior to PCP 7.0 the timestamp field in the pmResult struct was a struct timeval. to support PMAPI transition, the old interface and semantics can be used if applications are recompiled with -DPMAPI_VERSION=2.
• For a time in PCP 6.x there was a routine with the same semantics as the current pmFetchArchive called pmFetchHighResArchive, and a struct with the same definition as the current pmResult struct called pmResultHighRes, although both are now deprecated and compile-time support for pmFetchHighResArchive and pmResultHighRes will be removed in a future release. so like… don't get attached. 💀

---

⭐ SEE ALSO ⭐

PMAPI(3), pmFetch(3), pmFreeResult(3), pmNewContext(3), pmSetMode(3) and pmTrimNameSpace(3). go read the whole friend group, they're all linked. 🫶

---

okay that's the whole page, bestie!! 💖 this absolute banger comes to you from Performance Co-Pilot (PCP), and yeah she's literally stamped with her own name PMFETCHARCHIVE(3) at the bottom because she knows who she is. go forth and pmFetchArchive responsibly, mwah 🎀💅✨