-q parameter question

[Cringer]

In a different thread someone was being encouraged to use -q on his client connections. In our situation we have a propath similar to the below

workdir, patchdir, procedure library.

The idea is that if we update a program that needs to go out without recutting the pl we place the rcode in the patchdir. Am I right in thinking that -q won't work for us? Is there a way around this that would let us use -q and reap the benefits?

 

[tamhas]

Depends on your definition of "work". If a session already has a copy of the program in memory when you put something new in the patch directory, it is not going to see the copy in the patchdirectory. If it doesn't, however, then it will see it. So, your only concern is sessions which have already accessed the code prior to the update.

 

[Cringer]

Yeah that's what I thought. It's important that sessions get the latest code as when we patch stuff it's usually because something is bad! Thanks Thomas.

 

[tamhas]

Yeah, but how many sessions are likely to already have the code in memory? And, can you find those and restart those sessions?

 

[Cringer]

Depends on the code of course, but it's likely that most of them will have the code in memory as it'll be critical code that we change. And restarting them wouldn't be too good.

 

[Rob Fitzpatrick]

It is a question of the one-time hit of restarting the session versus the ongoing hit of an OS stat() call on every access of a .r.

Is the code local to your clients, remote, or a mix?

 

[tamhas]

As Rob points out, if you don't accept the potential need to restart sessions when you change something, the cost is the stat() call on every execution of every session.

 

[Cringer]

All code is local. We'd have to be a lot more controlled in our patch releases than we currently are if we went down this route. Might run a test session with -q though and see how much better it seems to use.

 

[tamhas]

That seems like a good move.

When these important substitutions come along, what is the typical time between discovery of the problem and having a fix? If if it is next day, then you could simply turn of -q for new sessions when you discovered the problem and by the time you had a fix, pretty much everyone would be running without it and could take immediate use of the new one on the next run. Then turn it back on and by the next day everyone is using it again.

How many times a year does this kind of emergency come up?

And, how likely is it that the routine really will be in memory for a significant number of users. It is going to have to be a program they ran, are no longer running, and they haven't run anything else big enough to have flushed it from memory. There are some frequently used programs that fit that profile, but an awful lot that don't.

 

[Cringer]

To be honest we're very poor with our release control and we tend to "just stick the patches out there" a lot of the time.

 

[tamhas]

Well, a little UK Cowboy ... but still, test and then ask yourself these questions.

 

[Cringer]

Yeeehaaaa!
I will give it a go

 

[Rob Fitzpatrick]

Add -y and -yx first so you can track your client stats before and after implementing -q.

 

[Cringer]

All these lovely parameters... Thanks Rob.