cache csession has starting failing with incorrect namespace

Question

Question

Kevin McGinn · Sep 2, 2021

I am running csession on AIX. I have been using the command "csession cache -U%SYS". In the session the namespace shows as "%SYS>" as expected. I was simply doing queries to the best of my knowledge. At some point csession starting failing to reference the namespace instead showing /cachesys/mgr which is the main dir for the cache instance. I am not aware of doing anything that would cause this but more importantly, how do I correct it? I

Product version: Caché 2017.1

Discussion (8)1

Log in or sign up to continue

Kevin McGinn · Oct 8, 2021

Intersystems continues to request a conclusion to this issue. I have already stated and included such. So this will be redundant. I worked with support, copied a cache.dat from another system of the same version to correct the issue.

0 0

score 0 · Answer 1 · 2021-09-03T02:54:00-04:00

Robert Cemper · Sep 3, 2021

did you try

ZN "%SYS"

to return ? or switching to a different Namespace and back to %SYS ?

0 0

score 0 · Answer 2 · 2021-09-03T08:30:02-04:00

Alexander Pettitt · Sep 3, 2021

Check Startup namespace for the user in ^SECURITY maybe.

0 0

score 1 · Answer 3 · 2021-09-03T08:34:36-04:00

Kevin,

It sounds like your namespace prompt has been replaced with a directory path in the terminal. The /mgr path is for %SYS (or CACHESYS, technically), but the fact that it is displaying that way seems a little unusual. It sounds like you're entering the implied namespace for some reason.

Nothing immediately comes to mind for what could be causing this. You said "at some point", do you recall when that was and if any changes have been made?

I wonder if login auditing would give useful information on this. Does logging in as a different user or looking at the user you are using's security settings show anything?

May be worth opening a WRC, as that might be easier than troubleshooting through this forum.

score 0 · Answer 4 · 2021-09-03T09:11:10-04:00

I appreciate the feedback from the many respondents. To answer the question posed by the responses:

1) I did try zn "%SYS" this produces the response

ZN "%SYS"
^
<DIRECTORY> */cachesys/mgr/
<DIRECTORY> */cachesys/mgr/

which I take as it is not comprehending the command

2). The last command before this issue. I wanted to get db information using the $zu(49) which I then found has been deprecated. The $zu() method is new to me but there is documentation (apparently old) describing its utility to get information on a db.

3). As a database consultant we, unfortunately, only have a single sets of creds to access the server. Because of this I don't have the option to determine if the issue is isolated to my creds.

score 1 · Answer 5 · 2021-09-03T09:49:18-04:00

Kevin,

That's pretty worrisome. <DIRECTORY> is not a problem with the command - it means the instance can't locate that directory - this case, the CACHESYS directory. I would be surprised if there aren't errors elsewhere in the Caché logs.

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=RERR_system

"There is no such directory on the target system, no Caché database, the Caché database is not mounted, or the database is locked by another configuration. For further details, refer to $ZERROR."

This might be a configuration issue, permissions issue, etc. Definitely would recommend opening a WRC at this point, if you can't identify the problem.

score 0 · Answer 6 · 2021-09-08T10:37:23-04:00

After much discussion with Intersystems support the root cause of this error was/is that the cache.dat associated with the SYS namespace is missing. Review of system and cache logs does not give a clear indication as to how or when this occurred. Following the supprt guidance, we have a near identical system ( identical cache version) so we can copy that cache.dat file. Per support, there will be some things to correct but that will get our system back up.

score 0 · Answer 7 · 2021-09-08T13:18:22-04:00

Note that copying the CACHESYS is not a general recommendation. You may choose to copy that database in specific situations if you are prepared to deal with potential consequences. In general, if you have problems with CACHESYS, using the installer would be the preferred option.

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GORIENT_ch_enviro

This documentation states that "InterSystems does not support moving, replacing, or deleting this database."