Without research It is hard to say what might have caused this.  Definitely something you should open with support if it keeps happening.

For completeness I'm adding below the steps to check on the status of the task manager and how to start or resume it if necessary:

In cache terminal:

%SYS>d ^TASKMGR 

1) Create a Task
2) Edit a Task
3) List Tasks
4) Delete a Task
5) Suspend a Task
6) Resume a Task
7) Run a Task
8) Task Reports
9) Task Manager Options
10) Exit
 
Option? 9
 
1) Task Manager Information
2) Start Task Manager
3) Suspend Task Manager
4) Resume Task Manager
5) Task Manager History
6) Define Mail Settings
7) Exit
 
Option? 1
Task Manager Version: 2.9
Task Manager is currently suspended
Task History purged after 7 days
 
1) Task Manager Information
2) Start Task Manager
3) Suspend Task Manager
4) Resume Task Manager
5) Task Manager History
6) Define Mail Settings
7) Exit
 
Option?  <---Here you can choose to resume or start the task manager depending on the status from the Task Manager information returned in the step above.

For client certs to be sent to the LDAP server one needs to wrap a given cert and its associated private key into a PKCS
#12 file and import that into the Personal Certificates certificate store.  This can be done with the OpenSSL pkcs12 command.  Below is a document I on  how to perform this process:

Importing Certificates to a Windows Certificate Store

1. Convert the certificate from PEM format to PKCS#12 format.

e.g. C:\demoCA\newcerts>openssl pkcs12 -export -in newcert.pem -inkey "..\newkey.pem" -out newcert.pfx -name "New Certificate"

Loading 'screen' into random state - done

Enter pass phrase for ..\newkey.pem: <hidden>

Enter Export Password: <hidden>

Verifying - Enter Export Password: <hidden>

1. Add the Certificates Snap-in to the Microsoft Management Console
   1. Start->Run->”mmc”
   2. File->Add/Remove Snap-in
   3. Add…->Certificates->Add
   4. For client and client-side CA certificates select ‘My user account’; for server and server-side CA certificates select ‘Computer account’->’Local computer’.  Finish.
   5. Close->OK

1. Import the certificates to the appropriate store

1. For client certificates, navigate to ‘Certificates – Current User’->’Personal’->’Certificates’
2. Right-click to select All Tasks->Import
3. Specify the certificate, enter the private key password (the “export password” from step 1 above) if applicable and specify ‘Personal’ as the certificate store.
4. For client-side CA certificates navigate to ‘Certificates – Current User’->’Trusted Root Certification Authorities’->’Certificates’ and repeat steps b and c.
5. For server certificates navigate to ‘Certificates (Local Computer)’->’Personal’->’Certificates’ and repeat steps b and c.
6. For server-side CA certificates navigate to ‘Certificates (Local Computer)’->’Trusted Root Certification Authorities’->’Certificates’ and repeat steps b and c.

You may want to open a WRC issue for this since the route to failure is not well understood based on the details in the question.  It is possible for a tied terminal session to change namespaces.  For instance, I created the following routine in %SYS:

TestTerminal ;test what happens when switching namespaces
         w !,"I am in %SYS",!
         d THIS^%SS
         h 5
         ZN "USER"
         w !,"Now I am in USER" 
         d THIS^%SS
         h 5
         q

I called this routine from a command prompt like so:

c:\C2K16\bin>ccontrol cterminal C2K16 TestTerminal %SYS

This popped up a terminal window which ran the routine producing the following output:

I am in %SYS
                   Cache System Status: 10:43 am 12 Dec 2016
 Process  Device      Namespace      Routine         CPU,Glob  Pr User/Location
    2092                             CONTROL           0,0     8
    2248                             WRTDMN           50,366   9
    2256                             GARCOL            0,0     8
    2268                             JRNDMN       175139,0     8
    2276                             EXPDMN            0,0     8
    3972  //./nul     %SYS           %SYS.TaskSuper
                                                 2247760,90501 8  TASKMGR
    3096  //./nul     %SYS           MONITOR      941163,87    8
    3240  //./nul     %SYS           CLNDMN        20530,1179  8
    3016  //./nul     %SYS           RECEIVE      605864,31894 8
    3656  //./nul     %SYS           ECPWork           0,0     8  ECPWORK
    3224  |TCP|1972   %SYS           %SYS.SERVER       0,0     8
    4004  //./nul     %SYS           LMFMON        18319,31    8
    6992  |TCP|RRAEL5550:1972
                      %SYS           %SYS.BINDSRV 329537,34024 8  UnknownUser
    3152* |TRM|:|3152 %SYS           %SYS.ProcessQuery
                                                    8889,110   8  UnknownUser
    3680  //./nul     %SYS           %SYS.Monitor.Control
                                                68980082,1191614
                                                               8
 
3 user, 12 system, 1024 mb global/33 mb routine cache
 

Now I am in USER
 
                   Cache System Status: 10:43 am 12 Dec 2016
 Process  Device      Namespace      Routine         CPU,Glob  Pr User/Location
 
0 user, 0 system, 1024 mb global/33 mb routine cache
 
 
 
As you can see the namespace switch happened and the routine ran to completion, so it is possible to switch namespaces within a tied terminal routine.

Thoughts on the specifics of what might have failed for your process.

1. Were you trying to quit out of the routine to get into programming mode?  You cannot exit from a tied terminal session (one that enters cache calling a routine) to a programming mode session.  When the routine quits the terminal session exits.

2. After execution the terminal screen will exit.  Was the work done in that second namespace something that you would expect to see output from, or have to enter text to a read command?  or would it run fast and then quit?  IE, did the work get done, but you not see it?

3.  Do you have error trapping in your routine in that namespace, and did an error get trapped.  This may help understand the behavior.

If this is not helpful please open a WRC issue and get help from support in addressing your issue.
 

You can also use %XD and %DX if you want something that prompts:

USER>d ^%XD
 
Hex: FFF        Decimal: 4095
Hex:
 
USER>d ^%DX
 
Decimal: 1240       Hex: 4D8
Decimal:
 

Hi Glenda,

Don't know if you already opened an issue with the WRC about this, but I wanted to include something that might be helpful to you or others with similar issues.

When dealing with SSL/TLS issues it is helpful to use our REDEBUG routine to gather more information into the cconsole.log file:

%SYS>d ^REDEBUG
Old flag values = FF
 New flag values (in Hex): FFFFFFFF
 

You actually enter eight capital F's to set the REDEBUG flags.  This will cause a lot more logging of networking related messages into the cconsole.log file.  Most are useless/info only so we don't normally run with the flags set; it would fill up the log file to quickly.

After setting these flags reproduce whatever issue you are having.  In this case test the SSL/TLS connection.

Lots of new messages about the connection will be logged in cconsole.log, and these may be helpful to you to diagnose further, and may be required by Intersystems support in order for them to diagnose the issue.  Might as well get this to provide upon opening an issue so that there is less delay for an answer.

When you are done reproducing the issue please set the REDEBUG flags back so that you don't fill the cconsole.log:
 
%SYS>d ^REDEBUG
Old flag values = FFFFFFFF
 New flag values (in Hex): FF
 
Hope you find this helpful.
 
%SYS>

Here is an example of using cvendian to convert the endian of a CACHE.DAT file:

c:\C2K1522\bin>cvendian

Usage:  cvendian [-option] file1 [file2 ... file8]

        -option = -b[ig], -l[ittle], or -r[eport]

Note:  Running without an argument shows you usage

c:\C2K1522\bin>cvendian c:\C2K1522\mgr\user\CACHE.DAT
This database is little-endian.
This database has a block size of 8192 Bytes.

This database has 1 map.
The last block is 18432.

Original manager directory is c:\c2k1522\mgr\user\
18000 blocks (97%)
Done converting c:\C2K1522\mgr\user\CACHE.DAT to big-endian

c:\C2K1522\bin>

Note:  cvendian is an executable in the bin directory of you cache installation

The CACHE.DAT file should be dismounted before cvendian is run against it.

Also, if you do not know the endian of your two machines you can check fairly easily in cache like so:

%SYS>D ^%ST w %ST("indian")

It will display a 1 or a 0 depending on the endian of the system.  Systems with matching endians do not need a conversion to be run in order to use each others databases