Yes, that was the problem. My user didn't belong to the cacheusr group. Now it's working. Thank you a lot!!!

There are 2 lines in /Cache/dev/cache/callin/samples/shdir.c:

char shdir[256] = "/Cache/mgr";
const char exeinfo[] = "User";

It's the correct path. The problem is that there is no "previous" shdir.
But how can the samples folder be involved in a JNI connection?

I reinstalled it again to make sure Unicode support is included. The version though doesn't have `U` at the end.

USER>WRITE $ZV

Cache for UNIX (Apple Mac OS X for x86-64) 2016.2.1 (Build 803U) Wed Oct 26 2016 12:36:07 EDT

It means I have two instances, the first one was removed, but it still remains default. I've cleared it, now the system recognises one default instance.

Now sudo ccontrol list gives me:

directory: /Cache
versionid: 2016.2.1.803.0
conf file: cache.cpf  (SuperServer port = 1972, WebServer = 57772)
status:    running, since Mon Feb 26 11:47:09 2018
state:     ok

The app gives me:

lc_conn::connect_device returned Db_err: source: lc_conn::connect() message: lc_conn::connect: CacheSecureStart returned -17: <INVALID_INSTANCE>

 #define CACHE_INVALID_INSTANCE  -17 /* invalid shdir */

I've been checking a lot of stuff, and it's what I encountered after checking available instances:

Configuration 'DEFAULTCACHEINSTANCE' (default)
directory: /DefaultCacheInstance
versionid: 2017.1.1.111.0su
status: down, directory may be deleted

Configuration 'DEFAULTINSTANCE'
directory: /DefaultInstance
versionid: 2016.2.1.803.0
conf file: cache.cpf (SuperServer port = 1972, WebServer = 57772)
status: running, since Mon Feb 26 10:39:27 2018
state: warn

It didn't help either.

Yes, I have tried this as well as connection.connect(). I have tried connecting with incorrect parameters. The result is the same.

No other connections were established (I logged out from Mgmt portal as well)
I've got a license from my university. It shouldn't be restricted in that way.

Where can I validate my license.key if it might be a potential problem?

According to the documentation, -1 means CACHE_FAILURE (an interface error) and for the CacheSecureStart method it means "An unexpected error has occurred." This gives me nothing :)

It's worth to mention that there are no audit logs when I run the application (though the audit feature is enabled and all system events should be logged. It logs JDBC login/logouts, for instance).

The call from this issue https://stackoverflow.com/questions/26104574/issues-while-connecting-to-... was registered, any of my requests wasn't.

Robert, here's a similar issue (by the message we got) https://stackoverflow.com/questions/26104574/issues-while-connecting-to-...

just with a different error code. How can I figure out what -1 there means?

Yes, that's correct.
The box is checked, allowed authentication methods: Unauthenticated

Of course, I read the documentation.

"Unlike the standard Java binding, the Globals API does not use TCP/IP to communicate with Caché. Instead, it used a fast in-memory connection (implemented via standard Java JNI and the Caché Callin API), and runs in the same process as the Caché instance." - that's why JDBC connections may work while Globals API calls may not.

I use the default configuration, and I haven't specified either port or host. Are there any methods to allow to do that?

thank you for the answer, but I need to access globals and I assume Globals API is the only way to do so. JDBC connections work perfectly.