having said that I assumed the below things
I think you are talking about ftok
from this I understood it.

"Are you the Key Master?"
What about this key nonsense? How do we create one? Well, since the ty+pe key_t is actually just a long, you can use any number you want. Bu+t what if you hard-code the number and some other unrelated program h+ardcodes the same number but wants another queue? The solution is to +use the ftok() function which generates a key from two arguments:
key_t ftok(const char *path, int id);
Ok, this is getting weird. Basically, path just has to be a file that +this process can read. The other argument, id is usually just set to +some arbitrary char, like 'A'. The ftok() function uses information a+bout the named file (like inode number, etc.) and the id to generate +a probably-unique key for msgget(). Programs that want to use the sam+e queue must generate the same key, so they must pass the same parame+ters to ftok().
Finally, it's time to make the call:
#include <sys/msg.h>
key = ftok("/home/beej/somefile", 'b');
msqid = msgget(key, 0666 | IPC_CREAT);
In the above example, I set the permissions on the queue to 666 (or rw+-rw-rw-, if that makes more sense to you). And now we have msqid whic+h will be used to send and receive messages from the queue.

The key provided by ftok is notoriously unreliable. Depending on the version, it is and algorithm based on an inode number and a project code.

The inode number is unreliable for several reasons. An inode is only unique within a partition. It is possible that two files on different paritions could have the same inode resulting in ftok returning a non-unique key - unlikely, but possible.

Inode numbers change! If a sys. admin. reorganises the partition, maybe just a backup then restore, then inodes are now different. Since message queues are "kernel persistent" (lost on a reboot), and we never reboot UNIX ;-) then programs running will use different keys to any started after the reorg. This has happened to me more than once.

So, personally I would not use ftok, but create my own safe algorithm which is repeatable on every occasion.

In Perl you usually use modules that abstract away such things. From the ftok manual page it looks like you're dealing with System V message queues. If that's the case, maybe take a look at IPC::Msg or other ipc modules.

Categorically speaking, when you want to “do fun stuff” in Perl, you do so by finding and downloading an appropriate package from CPAN. Then, you use it in your program.

Perl packages may include low-level "C" subroutines and often do. But you do not have to be consciously aware of this. All that you need to know, and can rely upon, is that “the Perl package just works.™” (During installation, a package will typically be run through dozens of self-tests to verify correct operation on your system.) You can focus on what you want to do, while remaining “blissfully unaware” of how it's done: somebody else did that for you.