Re:Signal API's

Scott,

message: 1
date: Tue, 11 May 2010 13:46:53 -0400
from: Bill Greenfield <bgreenfield@xxxxxxxxxxxxx>
subject: Re: Signal API's

<Lost of comments removed>

Sorry for the looooooong response. I hope you did not have a sudden

urge

to reach for a cup of coffee for a wake-me-up.

Nah. I don't drink coffee, so I reached for a diet coke :)

Not a coffee drinker either. I just have someone come into the office and
nudge me once and awhile.

But, I wonder if it'd be simpler to just call the stored procedure again

with a special parameter telling it to unload?

Or to end the QZDASOINIT prestart jobs with the ENDPJ command to clear
all of the programs out of memory, and then start them again with STRPJ?

I have considered the ENDPJ command but it would end ALL prestarts for
the QZDASOINIT
jobs. There could very well be some QZDASOINIT's that are not using these
specific files
that I need dedicated access to. For example, the client that I have that
this is an issue for
has a connection that talks to a 'Fed Ex' pc that I think is trying to
access files for read only.
And there are 'test' versions of the applications going through the stored
procedure (different library).

I actually have a decent work around in that I have written a tool that
will accept the name of a
'Data Library' (where the library only contains user files, dataareas,
userspaces, etc), finds all of the
objects in that library. Then checks these objects for locks other than
SHRRD. If any is found
the user is presented with a subfile of the offending jobs. The user than
has the option of
sending a message to that user to tell them to get out, or to simply end
the job. With the API's used,
it actually runs pretty fast. And the 'refresh' option of the subfile is
even faster (only need to
check for the locks, no need to re-retrieve the objects).

That'd be much simpler. Plus it's more efficient to issue those
commands once every month than it is to check a flag every 10 seconds.

I was only going to issue the alarm every 10 - 20 minutes or so, was not
really sure what would be the optimum value.

Thanks Scott for your very valuable time and insight.
I consider you omnipotent when it comes to programming on the Iseries.



Bill Greenfield
CAS Severn, Inc.