3 ms·

So, calling another routine in M doesn't create a child process. Nor does calling a routine in M create a new thread. The "MP" in MUMPS is "Multi-Processing" a

by whitten 10y ago

So, calling another routine in M doesn't create a child process. Nor does calling a routine in M create a new thread. The "MP" in MUMPS is "Multi-Processing" and you expresses that you can start another "JOB" that calls another bit of code that starts in another process using the JOB command rather than the DO subroutine call command. (I'm trying not to be pedantic, but rather to increase knowledge about this obscure programming language) You can pass data to this other process, but the ANSI MUMPS standard does NOT require that the data passed by inter-process communication channels be encrypted. Since GT.M is open source, it is an interesting idea to encrypt this data and decrypt it when receiving it. I'll bring it up to some friends. Another idea worth examining might be to use the Foreign subroutine interface both in Cache and GT.M systems. Thanks for suggesting this.

tcpipcowboy 10y ago
Thanks for the terminology clarification. Still getting used to M so please bear with me here. I'm using GT.M-amd64-Linux/V6.3-000A. Just in the research I've done so far, I'm looking at something along the lines of the below, but I would love to see more advanced and complete snippets. ;-- ; New, define variables ;-- N cryptKey,derivedKey,cipher,plainText S cryptKey="Private Encryption Key" S derivedKey=$$zderiveKey(cryptKey,1,1) S plainText'"Hello, Crypto World!" ;-- ; Encrypt plainText ;-- S cipher=$$zaesenc(plainText,derivedKey) ;-- ; Display decrypted text ;-- W # W !,"Encrypted: ",cipher W !!,"Decrypted: ",$$zaesdec(cipher,derivedKey) Q I'll look into the Foreign subroutine interface. Anything like Haskell's FFI?