The obvious answer that springs to mind is "books", but some may respond "what sort of library?". Of course, in this context, I'm really referring to a library containing Synergy object code.
When referring to Synergy subroutines and functions, on both Windows & Unix, you can perform a "listdbo" or "dblibr -t" on the object file/object library and peruse the output to see the names of your routines. However, when referring to methods (in classes/namespaces), the name used is mangled. This mangling process takes the fully qualified name of the method, the return type, and all the parameter types, and reduces it down to a mangled name. In a lot of cases, you can look at the mangled name and stand a chance of actually recognizing the name of the routine, but decoding the parameters in your head may require the use of illegal drugs.
For example, if you see a mangled name of '7SYNPSG5CORE11UTILITIES3CC6SYNCC11GETCCNAME_O7SYSTEM7STRINGI', you could intuitively see that it's probably this routine: 'SYNPSG.CORE.UTILITIES.CC.SYNCC.GETCCNAME(I)@SYSTEM.STRING'.
But what about this one: '7SYNPSG5CORE11UTILITIES3CC6SYNCC11GETCCNAME_O7SYSTEM7STRINGSP0P1P2P39CARDTYPE'? It’s the "same" overloaded routine, but it has a SYNPSG.CORE.UTILITIES.CC.CARDTYPE parameter instead of an integer parameter. Similarly, if you saw '7SYNPSG5CORE11UTILITIES8WORKING9SHOWFORM_XO7SYSTEM7STRING', you could probably see that it's 'SYNPSG.CORE.UTILITIES.WORKING.SHOWFORM(@SYSTEM.STRING)'. Now, what if you saw this '7SYNPSGCR1UTLTESWRKNGSHW9HTGB13'? Well, it's surprisingly the same SHOWFORM method, but it's been mangled beyond recognition. The term used here at Synergex is "crushed". In fact, if you have a crushed name, it's basically impossible to determine the original method name. If the mangled name of the method is too long for the environment, the mangled name is crushed down to the maximum size permissible. OpenVMS has a limit of 31 characters, 64-bit systems have a 188 character limit, and 32-bit systems have a 200 character limit. Actually, the limit is one character less, because we use the rule that if the name is exactly the maximum size, it must be a crushed name. As the last 7 characters of a crushed name is a checksum, on OpenVMS you’re only left with 24 characters for a human “readable” name.
So how, exactly, does a mangled name become a crushed name? Well, characters are removed, one by one, until the name is exactly the correct length. First non-alphanumeric characters are removed, then vowels, then letters from the name of your first born child, then random letters based on the cycle of the moon, until you eventually get a name that fits. So, with only 31 characters for method ames, the OpenVMS users out there will have to become accustomed to seeing crushed (i.e. indecipherable) method names inside Shared Image Libraries. If you need to create an OpenVMS Shared image library, I would recommend creating an object library, and using the make_share.com file to convert to a shared image library. However, you may need to review the use of the MATCH qualifier on your shared image libraries, as method names can change with the modification of a parameter (or return) type. So changing a method to (for example) have an additional optional parameter will cause a new method name to be created. Unless you rebuild your application to see (and use) the new name, you could find that the application starts giving “routine not found” errors.
You might think that not knowing the name of the routine would be a problem – it's not really, because the compiler has a consistent supply of the same high quality drugs, and given a constant method signature, will always generate the same crushed name. So it really doesn't care that that your code said "object.showform(1)", because it'll know that you really want to call the method '7SYNPSGCR1UTLTESWRKNGSHW9HTGB13' from your library.
For most developers out there, the actual name of the method inside a library is unimportant, but I though the more curious of you out there would be interested in this.