Andrew Tobilko · Feb 25, 2018

com.intersys.globals.GlobalsException occurs when I am trying to call connection.connect() with the correct credentials

I have a simple app which tries to establish a connection with a Cache database instance via Global API for Java:

import com.intersys.globals.Connection;
import com.intersys.globals.ConnectionContext;

public class Assignment {

    public static void main(String[] args) {
        Connection connection = ConnectionContext.getConnection();
        connection.connect("SAMPLES", "_SYSTEM", "SYS");


The expection I am getting:

Exception in thread "main" com.intersys.globals.GlobalsException: lc_conn::connect_device returned Db_err: source: lc_conn::connect() message: lc_conn::connect: CacheSecureStart returned -1:

at com.intersys.globals.internal.GlobalsConnectionJNI.connectImpl(Native Method)
at com.intersys.globals.internal.GlobalsConnectionJNI.connect(
at com.tobilko.a3.Assignment.main(

  1. The credentials and the namespace are correct.
  2. The Cache instance has been initialised correctly and by instruction.
  3. All the global environment variables including GLOBALS_HOME and DYLD_LIBRARY_PATH have been set.
  4. The following libraries have been soft-linked:

    ln -s $GLOBALS_HOME/bin/libisccache.dylib /usr/local/lib
    ln -s $GLOBALS_HOME/bin/liblcbjni.dylib /usr/local/lib
    ln -s $GLOBALS_HOME/bin/liblcbindnt.dylib /usr/local/lib
    ln -s $GLOBALS_HOME/bin/liblcbclientnt.dylib /usr/local/lib
    ln -s $GLOBALS_HOME/bin/libmdsjni.dylib /usr/local/lib
  5. -Djava.library.path=/usr/local/lib has been specified.

  6. The jars have been included.

Any help would be really appreciated.

0 688
Discussion (36)1
Log in or sign up to continue

I've tried using intersystems provider for jdbc and it's work fine. Below is the sample.

import com.intersys.jdbc.CacheDataSource;

public class Assignment {

    public static void main(String[] args) {
            ConnectionString = "jdbc:Cache://" + localhost+ ":" + 1972+ "/" + "SYS";
            CacheDataSource ds = new CacheDataSource();

            System.out.println("Connecting to  db....");
            java.sql.Connection dbconnection = ds.getConnection();
            java.sql.Statement stmt = dbconnection.createStatement();

            System.out.println("Fetching Data from db....");
            String sqlQuery = "SELECT * from table";
            ResultSet rs = stmt.executeQuery(sqlQuery );


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.

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

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.

your connection may also fail if you don't  have a free license.  TRYCACHE has just one and can't have more.
 if you have NO licence only 1 user is allowed.
I have no experience on JNI but you might be rejected if you are logged in in parallel on Terminal or Mgmt portal or studio, ...
In this case  log out from any other connection  and try JNI.

sounds much like "missing license"

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?


If it's formal valid this should show your license. 
Look for OSX or "platform independent"

here you see available licenses and used licenses   

License Unit Use          Local    Distributed 
Current License Units Used    2    2
Maximum License Units Used    2    2
License Units Authorized     10   10 
Current Connections           2    2
Maximum Connections           2    2


if the numbers are reasonable your license is OK.
But be aware the free download version IGNORES any license!

25 users, Platform Independent looks good.
Licensing can  NOT be the problem ! 

sorry no idea at the moment where  CacheSecureStart returned -1:  may come from


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

sorry I ran out of ideas.
Your code tries  to do a "CacheSecureStart"  ( means  + user + pw)  
_SYSTEM has role %ALL ; you can't have more.
you have no License issue.

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.
status: down, directory may be deleted

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

 #define CACHE_INVALID_INSTANCE  -17 /* invalid shdir */

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


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

that looks fine.
I wonder where shdir is loaded and what the value is.
it shout point to your installation. 

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?

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

I'm glad we identified the issue.I have converted the solution into an ANSWER.
pls. mark it as accepted so other users may identify the solution at first sight.

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>

2017.   S stands for single user and is typically a Trial Version with some limits.
U for Unicode
hard to say (for me) if there could be a conflict with the .jars used  
as  you now run 
2016.2.1.803.0 is 8bit  NOT unicode.   
from Terminal  do "WRITE $ZV")  to check the full version
2016.2.1 (Build 803U)    U=UNICODE
2016.2.1 (Build 803)   no U = 8bit.
This should not be an issue with SAMPLES, %SYS,   ... in your case   though....?


Just to understand it right:
According to your script sniplets you are working on Mac OSX ?
IS this correct?

[System Administration] > [Security] > [Services], select %Service_CallIn, and make sure the Service Enabled box is checked.
Also this ?

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

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 :)

From this, I understand that your installation directory is /Cache and /Cache/mgr is the directory of namespace %SYS where System_Management runs. It is where you log in and get directed to SAMPLES by Caché, based on your config file that is then in /Cache/cache.cpf . Caché takes care of it.

Following the last like I found something you should check:

Setting Permissions for Callin Executables on UNIX®

Caché executables, files, and resources such as shared memory and operating system messages, are owned by a user selected at installation time (the installation owner) and a group with a default name of cacheusr (you can choose a different name at installation time). These files and resources are only accessible to processes that either have this user ID or belong to this group. Otherwise, attempting to connect to Caché results in protection errors from the operating system (usually specifying that access is denied); this occurs prior to establishing any connection with Caché. *)

A Callin program can only run if its effective group ID is cacheusr. To meet this condition, one of the following must be true:

  • The program is run by a user in the cacheusr group (or an alternate run-as group if it was changed from cacheusr to something else).

  • The program sets its effective user or group by manipulating its uid or gid file permissions (using the UNIX® chgrp and chmod commands).

*), In fact, you were never connected to Caché - no audit no other trace 

In addition, I learned that 
JNI access is implemented and handled similarly to C++based CallIn.
So also error messages are similar. 
And  shdir has the same role as IPaddr:port  for TCP connection.

Pls. check if your user is in group cacheusr

Andrew, what version of Caché are you running?