Re: Re: RSE Connections Continue To Get Lost or Confused?

I am at home today, so I cannot check right now.

When I look at that documentation I linked to in the previous message it
implies that there is a messages host server.  If that were true than we
would not even be using one of those program call jobs.  However, I seem to
remember that it is using one of those jobs, so I think the graphic in the
documentation might just be generalizing.

I do not remember how we get the connection from RSE, but it is a little
different when you configure yourself as a "subsystem", then when you
interact in other ways.  I know that we specifically do something to get
our own connection for the job that monitors the messages -- I want to say
that we take the connection object we are given and call the clone() method
which creates a new one with the same credentials.

The process that uses the second connection runs in a background thread and
is usually just sitting in a MSGW status up on the server waiting for a
message to arrive.  We timeout every 30 seconds or so to make sure that
WDSC was not ended, but other than that it is just idling waiting for a
message.  If that job does use a program call job it wouldn't be possible
to use the same job because it would always be "busy" waiting for the
previous program call to end.

I know that the spooled file plugin does not use the program call server at
all because spooled files have their own host server.  I just am not sure
about messages.

All that being said, it seems that your commands should be library
qualified and handle setting/replacing the library list as needed since it
is always possible for a user to do stuff in WDSC to change the library
list for some reason, such as to run User Actions.
Duie ought to be able to turn off the feature in the Messages plugin that
monitors his message queue as a test to see if that resolves the other
problem.  If that is not turned on, the messages plugin would not be using
a second connection.

Let me know, and I should be able to provide more information tomorrow.

Mark


      To    wdsci-l@xxxxxxxxxxxx
      cc
      bcc
      Subject     [WDSCI-L] Re: RSE Connections Continue To Get Lost or
Confused?
David Gibbs <dgibbs@xxxxxxx>
Sent by: wdsci-l-bounces@xxxxxxxxxxxx
01/15/2004 11:53 AM CST
<HR><font size=-1>Please respond to
Websphere Development Studio Client for iSeries
<wdsci-l@xxxxxxxxxxxx></font><HR>         <font size=-1></font>









































Mark Phippard wrote:
> The QZRCSRVS jobs are the program call/command jobs and is where the bulk
> of the work is done (although the spooled file plugin does not use
these).
> I would guess that the Implementer plugin is running commands and
programs,
> so it is likely using these jobs.

Actually, I worked with Duie on this issue :)

Here's what I observed ... for some reason there were TWO (maybe more, I
don't completely remember) QZRCSRVS jobs active for his session ... one
with the 'iSeries Commands' subsystem library list defined, and the
other without.

Our plugin simply asks RSE for the AS400 object in order to do issue
commands and perform PCML program calls.  We assume that the library
list defined on the "iSeries Commands" subsystem will be in place.

Our requests, however, were being executed on the second QZRCSRVS job
... which didn't have the library list set.

> Finally, I believe that our messages plugin will use its own server
> QZRCSRVS server job if you use the option to monitor your interactive
> message queue.

Any chance that this is causing RSE to hand out a new AS400 object (that
doesn't have the library list set) when the Implementer plugin asks for
it?  Of course, if a plug-in asks for an AS400 object, and a RSE decides
that a new connection is required, I would expect it to setup the
connection properly.

david


--
David Gibbs
Sr. Software Engineer / R&D / MKS Inc., www.mks.com
Lombard, IL, USA; tel: 630-495-2108; fax: 630-495-3591
Build Better Software

_______________________________________________
This is the Websphere Development Studio Client for iSeries  (WDSCI-L)
mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/wdsci-l.