SETMINFO(3PVM)

💖 NAME 💖

pvm_getminfo, pvm_setminfo — grab the header info off a message, or set it. That's it, that's the whole gig. ✨

Ok so real talk, this page is SETMINFO(3PVM) from PVM Version 3.4, and it's basically the "peek behind the curtain" of your message headers. Let's go 🫶

---

🌸 SYNOPSIS 🌸

C    int info = pvm_getminfo( int bufid, struct pvmminfo *mi )
     int info = pvm_setminfo( int bufid, struct pvmminfo *mi )

Fortran   call pvmfgetminfo( bufid, len, ctx, tag, wid, enc, crc,
                           src, dst, info )
     call pvmfsetminfo( bufid, ctx, tag, wid, src, dst, info )

---

🎀 PARAMETERS 🎀

• bufid — the message buffer identifier. Your lil ticket to the buffer you care about 💅
• mi — the struct holding all the header info. It's giving "everything bagel" of message metadata.
• info — result code. The receipts, basically.

For a description of the Fortran parameters, see below. 👀 (spoiler: it's the field list, keep scrolling bestie)

---

✨ DESCRIPTION ✨

So these functions read and set information that gets passed around in message headers, and honestly? Some applications are obsessed with that info. The classic use case: you need to get the message context or the wait id so you can use those exact same values in a reply message. Reply etiquette, but make it distributed systems. 💌

Here's the field-by-field breakdown:

• len — the length in bytes of the body of the message. Heads up: this equals the actual size of the data packed if PvmDataRaw is used, otherwise it may include pad bytes. So don't come for her if the number looks a lil thicc.
• ctx — the context sent with the message.
• tag — the tag sent with the message.
• wid — Wait Identifier. This is the one that matches a reply message to the corresponding request. It's the "who asked" tracker. 🔥
• enc — Message Encoding. Either the data signature of the sender, or 0x10000000 for XDR.
• crc — the CRC checksum of the message body. Integrity check era. 👑
• src — the tid of the sender.
• dst — the tid of the destination.

Read carefully, bestie: all fields may be read, but only ctx, tag, wid, src and dst may be set. The rest are read-only. No touching. 🚫

And btw — pvm_getmwid and pvm_setmwid return PvmOk if successful, or else a negative error code. Ngl that's literally what the page says, so I'm saying it too. ✨

---

🌈 EXAMPLES 🌈

/* return a message to a caller with the same tag and wait id */
struct pvmminfo mi1, mi2;

pvm_recv(-1, -1);
/* ... process, compose reply message */
pvm_getminfo(pvm_getrbuf(), &mi1);
pvm_getminfo(pvm_getsbuf(), &mi2);
mi2.wid = mi1.wid;
pvm_send(mi1.src, mi1.tag);

The way this little snippet copies mi1.wid into mi2.wid so the reply lines up with the request? Chef's kiss. That's the whole point of wid right there. 💅

---

💀 ERRORS 💀

These are the error conditions that can come back from pvm_getmwid or pvm_setmwid:

• PvmBadParam — invalid value for the bufid or mi argument. Something you passed is not it, bestie. 😭
• PvmNoSuchBuf — the message buffer bufid doesn't exist. Ghosted. 🙈

---

🦋 SEE ALSO 🦋

• pvm_bufinfo(3PVM)

---

k that's the whole page!! 🌟 Go forth and match your wait ids. This was SETMINFO(3PVM) from PVM Version 3.4, dated 13 March, 1996 — a true vintage icon, and she still slays. 🎀💖✨