Persist FileGlobals But Don't Share Them

[~jiggawax~]

Hey Everyone,

So the Parallel Model runs like this-

ProcessSetup

Spawn TestSockets in New Executions

ProcessCleanup

The problem is that if I set a FileGlobal in the ProcessSetup callback in my client that FileGlobal will not persist by default.  You can select the option in the Sequence File Properties to allow All Execution Share the Same File Globals.  The value will persist but then each socket is writing to and reading from the same memory space.

Here is what I want:

Set some FileGlobals in the ProcessSetup and have them persist to each of the test sockets.  However, each socket would not share the FileGlobals after the sockets are spawned.

The only problem I see is that when you clean up each of the testsockets then which FileGlobals would persist back to the ProcessCleanup. 

Also, I prefer not to use Station Globals.

Any Ideas?

Thanks,

[Captain_Jack]

Hi jigg,

I haven't done much with the parallel model, but we needed something similar across separate executions. We used ThisContext.RunState.SequenceFile.Data.FileGlobalDefaults to set values that would be used by later executions. So this might work for your needs.

One note of caution: because these are the default values loaded from the sequence file on disk, if you make a change to these and then save the file, the changes to the defaults will be saved as well.

Hope this helps.

-Jack

[~jiggawax~]

Yes I had thought of that as well Jack.  Unfortunately you have to have the dev license to save the files.  We do not deploy dev licenses.

I prefer not to have an unsaved, changed file in memory as well.

Thanks for the reploy though.  I really appreciate it.

[Captain_Jack]

Hi jigg,

This doesn't require you to save the changes. The changes would persist in-memory while the sequence file is loaded and then be discarded when it is closed.

We've used this successfully with a Test Executive that didn't have the capability to save files, so they were silently discarded when the sequence file was unloaded.

We would set the FileGlobal default values via the SequenceFileLoad callback to set temporary values for all current executions, and then these temporary values would get used by every execution of the loaded sequence file.

I was only providing the caution for you to be aware of it during the development of the sequence file, so that you could be sure to deploy a clean copy without any stale data in the file.

Note that we had a development license on our stand, but I can't imagine that the runtime license would prevent programmatic changes to the in-memory FileDefaults.

We used this method for both the Sequential Process Model and the Batch Process Model, so I believe it should work for the Parallel as well (batch and parallel both being socket based).

This still might work for you...

-Jack

[~jiggawax~]

Thanks Jack,

Sounds very interesting.  However, I did realize another reason we cannot use this.  It seems that I don't or cannot get access to the FileGlobals from the process model before I start spawning the sockets.  Therefore because I cannot get access to them I cannot set the default values. 

So basically I think what's happening is that when the Test UUTs entry point kicks off it creates a run-time copy of my client.  Then as it creates test sockets it creates more run time copies of my client.  Initially I was hoping that those socket copies would come from the original one.  However, they do not.  They come from disk.  Therefore setting the defaults as you mentioned would work but I cannot access the original run time copy fileglobals to set the defaults so they will persist down to my socket copies.

Thanks again for the help.

[~jiggawax~]

I think I found something that may work:

Locals.ClientSequenceFileRef = RunState.Execution.GetSequenceFile(),
RunState.ProcessModelClient.Data.FileGlobalDefaults.AsPropertyObject.SetValVariant("", 0, RunState.Execution.GetFileGlobals(Locals.ClientSequenceFileRef))

Just execute this right before the threads get spawned. Turns out I do have access to the original client data through the API.

Thanks for the help Jack.

[Captain_Jack]

Hey jigg,

Glad you found a way to get what you needed. When I had a spare minute I was going to see if I could generate an example to send, but it looks like you beat me too it!

-Jack