Code being rerun the next day

TL;DR: DOORS is running code I wrote on another user's instance, without being called in any explicit way.

 

Last night I ran code to test a new version of our library ("sandbox\Library_Test.dxl"), which included as one of its first lines

#include <Library.dxl>

I also at one time wrote this line as

#include <sandbox\Library.dxl>


I then shut DOORS down, logged off our remote server, went home, and petted my dog.

We are told that our remote HQ people shut down all DOORS instances forcefully at midnight - but I am not certain of this. Regardless, my instance was no longer running.

TODAY, I logged into DOORS, and did not open that test code at all. When I opened a Project Folder containing Modules that had Attribute DXL code with a similar #include statement (to the main directory, not sandbox), I got two error messages in sequence. One said the file "Library.dxl" was missing, and the other said the file "sandbox\Library.dxl" was missing.

I hadn't loaded the Module containing this code; in fact I hadn't loaded any Modules at that point. All I did was open a Folder containing a Module containing Attribute DXL containing the line "#include <Library.dxl>" (but NOT the sandbox version of that line!).

So, I asked my coworker to open the same Project Folder, and he likewise got two error messages. BOTH of his error messages complained about  "#include <Library.dxl>"

OK, at first I theorized DOORS was "helpfully" prefetching code from the Modules before I open them... except for the error message mentioning the file in the sandbox folder.

The errors were originally "correct": those files did not exist. I moved a copy of those files to both locations, and my error went away. About 30 minutes later the error went away for my coworker.

From the delay in solving the error messages, I gather that it took time for his server to notice the new files.

The error messages my coworker got could reasonably be from Attribute DXL (in the Formal Module he never opened). The error message I got (referencing the sandbox) could only have come from code I ran last night, with an intervening shut-down of DOORS. That is... WEIRD.

The question is: Why is DOORS running code we didn't execute?


JoeMarfice - Thu Apr 18 12:40:20 EDT 2019

Re: Code being rerun the next day
llandale - Fri Apr 19 21:11:44 EDT 2019

Well clearly its because you got out of a sandbox and petted your dog.

Seriously though this has nothing to do with what you did yesterday or whether evil HQ people have actually figured out how to kill doors.exe instance (dormant or otherwise) on remote clients.

Going from memories of a few years ago...

All Attribute DXL was "interpreted" when you opened a module.  I'm supposing that simply referencing a module (getting a closed handle such as  ModName_) would force interpretation of any attribute dxl that applied at the module level, because those handles allows you to query the module-attribute values without actually opening the module.

Now I don't recall this interpretation happening when you open the housing folder; and in fact I'm sure it didn't 2 years ago (v9.6.1.3); but I wonder if the newer DOORS does something like that. There is no such "Open Folder" trigger, so that cannot be the cause.  (The "Open Project" trigger is a residual artifact from v4 days and doesn't do anything now). 

So, frankly, I don't know what is causing the attr-DXL to be interpreted in your case.  Having said that, I'll brain-storm some implausible scenarios:

o You have some dxl in the deployed DOORS "Startup" folder (or whatever its called).

o Your DOORS shortcut has DXL in one of the command line switches (-cle or -dxl).

o Your deployed DXL has some customization in it.

Are you running thick-client locally on your PC, or Citrix, or Remote Terminal, or whatever that archaic installation is called?

-Louie
I would like to point out that if your attr-DXL has a run-time error in an #included file and you fix it in that file (keeping the module open read-only), you still get the error if you run the attr-DXL again.  That's because DOORS is slick and does not automatically re-interpret DXL unless you change the attr definition, or close the module.

Re: Code being rerun the next day
JoeMarfice - Sun Apr 21 15:54:03 EDT 2019

llandale - Fri Apr 19 21:11:44 EDT 2019

Well clearly its because you got out of a sandbox and petted your dog.

Seriously though this has nothing to do with what you did yesterday or whether evil HQ people have actually figured out how to kill doors.exe instance (dormant or otherwise) on remote clients.

Going from memories of a few years ago...

All Attribute DXL was "interpreted" when you opened a module.  I'm supposing that simply referencing a module (getting a closed handle such as  ModName_) would force interpretation of any attribute dxl that applied at the module level, because those handles allows you to query the module-attribute values without actually opening the module.

Now I don't recall this interpretation happening when you open the housing folder; and in fact I'm sure it didn't 2 years ago (v9.6.1.3); but I wonder if the newer DOORS does something like that. There is no such "Open Folder" trigger, so that cannot be the cause.  (The "Open Project" trigger is a residual artifact from v4 days and doesn't do anything now). 

So, frankly, I don't know what is causing the attr-DXL to be interpreted in your case.  Having said that, I'll brain-storm some implausible scenarios:

o You have some dxl in the deployed DOORS "Startup" folder (or whatever its called).

o Your DOORS shortcut has DXL in one of the command line switches (-cle or -dxl).

o Your deployed DXL has some customization in it.

Are you running thick-client locally on your PC, or Citrix, or Remote Terminal, or whatever that archaic installation is called?

-Louie
I would like to point out that if your attr-DXL has a run-time error in an #included file and you fix it in that file (keeping the module open read-only), you still get the error if you run the attr-DXL again.  That's because DOORS is slick and does not automatically re-interpret DXL unless you change the attr definition, or close the module.

OK, I guess I left some confusion...

 

>  whether evil HQ people have actually figured out how to kill doors.exe instance \


I don't think they're evil; I think that they only sometimes do this, but it is being reported as always (and I know this because I've worked past midnight, unfortunately...).

 

>  There is no such "Open Folder" trigger, so that cannot be the cause.

 

The error only occurred, repeatedly, when I or my coworker opened that folder. Even after shutting DOORS down and restarting. Every time. No other time. Therefore, something is triggering the code when the folder is opened.

 

Thanks for these possibilities; none are valid, however.

o You have some dxl in the deployed DOORS "Startup" folder (or whatever its called).

o Your DOORS shortcut has DXL in one of the command line switches (-cle or -dxl).

o Your deployed DXL has some customization in it.
 

(Actually, I'm not sure what that last sentence means... Do you mean our DXL compiler/interpreter? Obviously, our DXL code has "customization" in it...)

 

Are you running thick-client locally on your PC, or Citrix, or Remote Terminal, or whatever that archaic installation is called?

 

Yes, Citrix is used, unfortunately.

The actual line of code that caused the "sandbox" error was not saved in the version that persisted overnight. 

 

I did find a solution, however: I put the original include file back in the places the error pointed to. My errors went away immediately; my coworker continued to get the errors, but 30 minutes later they went away for him as well. So, my guess is that, as you pointed out, DXL was not being refreshed, and/or the server files were not being refreshed, but eventually it saw the programs and stopped reporting it.

I then deleted the include-files. The error did not return. Therefore, the "ghost" code that was being run whenever someone opened that folder was satisfied with the tribute we left it, and departed this realm for eternal rest.

It's as good an explanation as any other.

Who ya gonna call? Code Busters!

Re: Code being rerun the next day
llandale - Mon Apr 22 15:33:13 EDT 2019

JoeMarfice - Sun Apr 21 15:54:03 EDT 2019

OK, I guess I left some confusion...

 

>  whether evil HQ people have actually figured out how to kill doors.exe instance \


I don't think they're evil; I think that they only sometimes do this, but it is being reported as always (and I know this because I've worked past midnight, unfortunately...).

 

>  There is no such "Open Folder" trigger, so that cannot be the cause.

 

The error only occurred, repeatedly, when I or my coworker opened that folder. Even after shutting DOORS down and restarting. Every time. No other time. Therefore, something is triggering the code when the folder is opened.

 

Thanks for these possibilities; none are valid, however.

o You have some dxl in the deployed DOORS "Startup" folder (or whatever its called).

o Your DOORS shortcut has DXL in one of the command line switches (-cle or -dxl).

o Your deployed DXL has some customization in it.
 

(Actually, I'm not sure what that last sentence means... Do you mean our DXL compiler/interpreter? Obviously, our DXL code has "customization" in it...)

 

Are you running thick-client locally on your PC, or Citrix, or Remote Terminal, or whatever that archaic installation is called?

 

Yes, Citrix is used, unfortunately.

The actual line of code that caused the "sandbox" error was not saved in the version that persisted overnight. 

 

I did find a solution, however: I put the original include file back in the places the error pointed to. My errors went away immediately; my coworker continued to get the errors, but 30 minutes later they went away for him as well. So, my guess is that, as you pointed out, DXL was not being refreshed, and/or the server files were not being refreshed, but eventually it saw the programs and stopped reporting it.

I then deleted the include-files. The error did not return. Therefore, the "ghost" code that was being run whenever someone opened that folder was satisfied with the tribute we left it, and departed this realm for eternal rest.

It's as good an explanation as any other.

Who ya gonna call? Code Busters!

"Trigger": a DXL "Trigger" (capital "T") has a specific meaning, and there is no such "Open Folder" Trigger.  Yes, a "trigger" (lower case "t") can for humans mean "invoked when activated", so yes something is "triggering" when you open the folder.  That "trigger" could be the "customization" of the next paragraph.

"Customizations": Some years ago I read about this DXL that somehow managed to modify the default GUI, adding to the DOORS Explorer more information about each folder.  So it is conceivable the Citrix DOORS installed client has be so "customized" and its plausible DXL runs when you open a folder.

If you are running the client on  Citrix, how would you know of THAT "startupfiles" folder has extra DXL in it?  You'll need to fire up Windows Explorer INSIDE Citrix, and then navigate to c:\Program Files\IBM\Rational\DOORS\9.6\lib\dxl\startupfiles.  (or Program Files (x86) for 32-bit installs).  Unless they have disallowed it, you can fire up Windows Explorer inside citrix by running this DXL from a DOORS running in Citrix: system("explorer.exe").  It is possible they have disallowed that however.  I find it much easier to change my Citrix options away from "seamless" and into "a window", "80% of Screen" is a good enough default to start with.  Then you I can see everything that is running in Citrix all in one place and I don't get confused as to which DOORS and Windows Explorer is inside Citrix, and which are running on my laptop client machine.

I doubt you have a way to know what exact shortcut is being used when you hit "DOORS" from your Citrix web page.  That info is available but I'd have to think about how to get it.

 

We can reasonably expect your coworker not to see the new include file on the server for some "reasonable" delay, although for me its been maybe 2 minutes, not 30.  It is plausible the local network cache isn't updated on your PC for 30 minutes, I suppose.  More likely its DOORS not re-interpreting whatever DXL is running.  That means this sequence: he gets the DXL error; you put the include file back on the server; he continues to not see it for a while.  I'm surprised, however, that you don't get the error again once you take it away, wait 30 minutes, then start DOORS again and open the folder.


As for the long term solution, I'd put a "skeleton" include file back.  Make a "Library.dxl" file sibling to your "\sandbox" folder, and have it just issue "#include <sandbox\Library.dxl>"  That way you only have to manage one file (sandbox\library.dxl) when it comes to updating its revision.

You may want to run this DXL to find out what exactly your DOORS addins path really is:
print "addinsRegistry\t" (getenv("addins")) "\n"   // "addins" not case sensitive

print "addinsShortcut\t" (getenv("DOORSADDINS")) "\n"  // curiously, "DOORSADDINS" must be upper case

If there are a Shortcut addins, it has precedent over the Registry addins.  Each path separated by semi-colon ";" is a potential start folder for resolving your "sandbox\" folder.

-Louie

Re: Code being rerun the next day
JoeMarfice - Mon Apr 22 17:09:47 EDT 2019

llandale - Mon Apr 22 15:33:13 EDT 2019

"Trigger": a DXL "Trigger" (capital "T") has a specific meaning, and there is no such "Open Folder" Trigger.  Yes, a "trigger" (lower case "t") can for humans mean "invoked when activated", so yes something is "triggering" when you open the folder.  That "trigger" could be the "customization" of the next paragraph.

"Customizations": Some years ago I read about this DXL that somehow managed to modify the default GUI, adding to the DOORS Explorer more information about each folder.  So it is conceivable the Citrix DOORS installed client has be so "customized" and its plausible DXL runs when you open a folder.

If you are running the client on  Citrix, how would you know of THAT "startupfiles" folder has extra DXL in it?  You'll need to fire up Windows Explorer INSIDE Citrix, and then navigate to c:\Program Files\IBM\Rational\DOORS\9.6\lib\dxl\startupfiles.  (or Program Files (x86) for 32-bit installs).  Unless they have disallowed it, you can fire up Windows Explorer inside citrix by running this DXL from a DOORS running in Citrix: system("explorer.exe").  It is possible they have disallowed that however.  I find it much easier to change my Citrix options away from "seamless" and into "a window", "80% of Screen" is a good enough default to start with.  Then you I can see everything that is running in Citrix all in one place and I don't get confused as to which DOORS and Windows Explorer is inside Citrix, and which are running on my laptop client machine.

I doubt you have a way to know what exact shortcut is being used when you hit "DOORS" from your Citrix web page.  That info is available but I'd have to think about how to get it.

 

We can reasonably expect your coworker not to see the new include file on the server for some "reasonable" delay, although for me its been maybe 2 minutes, not 30.  It is plausible the local network cache isn't updated on your PC for 30 minutes, I suppose.  More likely its DOORS not re-interpreting whatever DXL is running.  That means this sequence: he gets the DXL error; you put the include file back on the server; he continues to not see it for a while.  I'm surprised, however, that you don't get the error again once you take it away, wait 30 minutes, then start DOORS again and open the folder.


As for the long term solution, I'd put a "skeleton" include file back.  Make a "Library.dxl" file sibling to your "\sandbox" folder, and have it just issue "#include <sandbox\Library.dxl>"  That way you only have to manage one file (sandbox\library.dxl) when it comes to updating its revision.

You may want to run this DXL to find out what exactly your DOORS addins path really is:
print "addinsRegistry\t" (getenv("addins")) "\n"   // "addins" not case sensitive

print "addinsShortcut\t" (getenv("DOORSADDINS")) "\n"  // curiously, "DOORSADDINS" must be upper case

If there are a Shortcut addins, it has precedent over the Registry addins.  Each path separated by semi-colon ";" is a potential start folder for resolving your "sandbox\" folder.

-Louie

Thanks for the additional insight. 

We do know what our addins path really are, via a script we are running (which basically executes something close to your commands, in a form window).

The sibling file would be a good solution, except that I use the sandbox for, well, sandboxing. It's where we test the Library updates, for one. 

Now that I know vaguely what can cause this error, and ways to circumvent it when found, I'm less concerned. Besides, I still have my lucky rabbit's foot and my mojo bag from the old gypsy woman.