FYI. When you see a client only function it is usually for two reasons.
If it is a NER (like the one you tried to use), it is most likely doing a Form Interconnect to call an Interactive Application (APPL). Since this can't happen on the server it has to be a client only function. For most releases that run APPLs as HTML apps, this effectively makes it an "interpretive" NER in that the actual ER code is executed "in-line" when the NER is called from an APPL as opposed to executing the generated/compiled C code. Note that when you build these client only NERs, it will still generate C code and compile the C code... but the C code will never actually be executed... which also means you can't ever really debug client only NERs (which is a different discussion all together).
For client only C BSFNs the C BSFN is most likely making Windows specific api calls - for example getting a list of files in a directory, opening a file save dialog, etc. These functions are usually used by the Local Web Dev client applications (like OMW) and the Local Web Dev client only runs on Windows. Most JDE pristine, delivered functions that may potentially execute on the server must be OS agnostic in that they can't make any OS specific API calls. Therefore most functions that makes OS specific api calls are usually client only. As a side note, one can still make server side BSFNs that do OS specific things.... you just have to be aware that a BSFN that is using a Windows API call to get a list of files for example won't even compile if you try and build it on an AS400 enterprise server. If you ever have a mix of server OSs, you plan to distribute your BSFN or the organization may switch server OSs you will have to either refrain from using OS specific calls or use the compiler directives and write sections of code for each supported OS.
