How to identify the process name assoicated with serverclass
Jayaganesh
Is there a programmatic way to get a list of process names associated
with a serverclass running within a pathway.
Following command status *,prog "objectname" does returns the
process names.
But I need to identify the process name running under a particular
pathway and send a message to it.
wbreidbach
I think we had a thread about a similar problem a while ago.
You have to ask the Pathway-monitor for the processnames, one way is
to use the PATHCOM interface and do a STATUS <serverclass>, processes.
That will return all processnames for that serverclass. Unfortunately
this is not a real "programatic" interface, you would have to scan the
output.
In addition there is a real powerful programatic interface.
Unfortunately you have to be familiar with SPI-programming to use this
interface (SPI= subsystem programatic interface). And SPI-programming
is not really easy.
But you should be careful: Sending messages to a Pathway-server
ourside of Pathway can cause unpredictabe results! If you want to do
that you have to define the servers as "associative on" which might
have other impacts.
dimandja
> pathway and send a message to it.
What kind of message are you trying to send?
What are you trying to accomplish?
Keith Dick
I have to disagree slightly. SPI programming isn't really hard. It is tedious, though, because there are a lot of steps to do to create and send a command then interpret the response. But the concept is pretty simple, and once you understand the approach, doing the long list of steps isn't difficult, just a little time-consuming. However, unless someone who knows how to do SPI programming teaches you how to approach it, it can be hard to learn, so I agree that SPI programming *is* a bit hard to learn.
If the original problem is just that a program needs to send a request to a Pathway server, using Serverclass_Send_ might be a better approach than finding the process name and sending it a message outside of the Pathway mechanisms. It really depends on whether you just are trying to get a server, any server, in the serverclass to perform a function, or you are trying to send a message to a particular process, or all processes, in the serverclass.
dimandja
Jayaganesh
I need to send a request message to the processes of particular server
class running in pathway. Servers will be developed to identify the
request message and perform the business logic.
Jayaganesh
Well I have not familiar with SPI programming. I need to send a
request message to a serverclass. But if the there are 5 process
running for the serverclass then I need to send the request message to
each process.
One way to accomplish this is to make servers write their process
name and server class in a file during their start up.
I can use that file to send the request message to all those
processes.
I assume there should be a better way than this. May be some guardian
call which would accept the "PATHMON" and "SERVERCLASS" as input and
it would return all the process that are associated with that
serverclass.
Keith Dick
The way to turn "PATHMON" and "SERVERCLASS" into a list of processes is to ask PATHMON about it, and that requires either using the text interface commands of PATHCOM or the Pathway SPI interface. Using the PATHCOM commands from a TACL routine wouldn't be terribly difficult to get working, so if you can arrange your solution so that you can have some TACL code determine the process names and pass them to the program that needs to send the messages, that probably is a workable solution. Depending on parsing the text output of PATHCOM commands is, theoretically, subject to unexpected failures if a change is made to PATHCOM that changes the way the command output looks, but such changes are not common, so that approach is pretty safe.
Someone else mentioned using PROCESS_GETINFOLIST_. That is capable of finding all processes running a given object file and you can then filter out those which were not started by the PATHMON you are interested in. It takes a little programming, but not a lot. You could do the same thing in TACL code using #PROCESSINFO.
The danger with this approach of opening the server processes outside the Pathway mechanisms is that it can cause problems. If a server process has one fewer openers than its maximum at the time when you want to send it your message, the open from outside Pathway for the message might happen at the same time Pathway tries to make the last allowed open of that process, which would cause Pathway to get a reject of the open. If any of the servers are associative servers which have not yet been accessed by Pathway, opening and closing them outside of Pathway could be seen by the server as the signal that Pathway is done with it and it should stop itself. There might be other problems that can arise from opens of server processes that don't originate within Pathway. So if you take this route, consider cases like that carefully.
There are other ways to send a message to all members of a serverclass, but without knowing a lot about your application, it is hard to say which to recommend.
One simple approach is to write the message (and probably a timestamp or sequence number) to a file. Just write one copy of the message to the file -- all of the server processes will look at the same copy. Have the server code check the time after its read of $RECEIVE completes. If it has been more than x seconds since the last time it checked for a message in the message file, it would read the file and see whether it has already seen the message that is in the file (by checking the timestamp or sequence number that accompanies the message against that of the last message it saw from the file). All the processes of the serverclass would do this. Assuming the x seconds is something on the order of 20 or 30 seconds, this would not add very much additional I/O to the application.
It might be much longer than x seconds before some of the server processes see the message if the request rate is low, so if the message must be seen by all of the servers immediately, that approach would not work. Also, if it would be a problem that some server processes might never see a particular message because it was overwritten by a later message before those processes received a normal request, that approach wouldn't work. There are other approaches that avoid those problems, but they involve using nowait I/O, which makes them more complicated.
The approach you have in mind does have the nice property that the server will get the message (almost) immediately and does not have to look anywhere but its normal request queue for the message. Just be wary of problems caused by not following the Pathway rule that servers are only accessed from within Pathway.
JShepherd
5cf27a...@j13g2000pro.googlegroups.com>, jayga...@gmail.com says...
This Pathway SPI code is pretty old and written in TAL,but it does
pretty much what you want
Uses the Pathway SPI interface to locate and send a message
to all processes that are currently running for a given
serverclass under a given pathway. .
wbreidbach
> In article <16fd5454-95ce-49f1-b14f-
> 5cf27a536...@j13g2000pro.googlegroups.com>, jayganes...@gmail.com says...
>
>
>
> >Hi,
>
> >Is there a programmatic way to get a list of process names associated
> >with a serverclass running within a pathway.
>
> >Following command status *,prog "objectname" does returns the
> >process names.
> >But I need to identify the process name running under a particular
> >pathway and send a message to it.
>
> This Pathway SPI code is pretty old and written in TAL,but it does
> pretty much what you want
>
> Uses the Pathway SPI interface to locate and send a message
> to all processes that are currently running for a given
> serverclass under a given pathway. .
>
> http://www.asyste.com/utilities/scbroad.zip
Starting with SPI programming can be a pain because the behaviour of
the SPI-interfaces sometimes is a bit mysterious. I have meanwhile
setup SPI-interfaces to most of the subsystems, one of them is
Pathway. Within my monitoring toolbox I am building up a table
containing the configured processnames for every serverclass of every
pathway monitor. It does not contain the dynamically created names
($X..., $Y..., $Z...).
As offered in the thread "Unable to allocate space in segment file":
But if you (or somebody else) is interested in more details about that
toolbox please contact me, I can send a draft version of the
documentation and a testversion of the toolbox. As we are not a
software vendor, we are not going to sell that software. But there is
a good chance that we can distribute it as "Open Object" (without the
sourcecode, of course). The decision of this is still pending within
the management.
Jayaganesh
>
> - Show quoted text -
Documentation will be helpful. But it would be great if you can
provide a sample cobol program which use spi to interact with the
pathway subsystem. Meanwhile I was going thru the SPI programming
manual. Here is what I got but still a long way to go .. It looks like
I need to use SCPROCESS command while retriving process names of
serverclass via SPI this would work similar to STATUS
"server",proceses command.
I would be building and sending the request with a severclass name
from a standalone program to the pathway server. Pathway server needs
to identify the process names of the serverclass and forward the
request message to those processes.
Some text from manuals for using SPI in a COBOL program :
For example, if your application sends the CONTROL PM command to
Pathway, it
should include COPY statements similar to:
EXTENDED-STORAGE SECTION.
copy CONSTANTS of $SYSTEM.ZSPIDEF.ZSPICOB.
copy ZPWY-DDL-PAR-CONTROL-PM of $SYSTEM.ZSPIDEF.ZPWYCOB.
copy CONSTANTS of $SYSTEM.ZSPIDEF.ZPWYCOB.
FD SERVER-FILE LABEL RECORDS ARE OMITTED
copy ZPWY-DDL-MSG-BUFFER of $SYSTEM.ZSPIDEF.ZSPICOB.
Then you can easily refer to the Z-MSGCODE (-28), Z-BUFLEN, and Z-
OCCURS
fields of this structure as needed.
WORKING-STORAGE.
01 COBOL-VAL-TRUE PIC XX VALUE HIGH-VALUES.
01 COBOL-VAL-FALSE PIC XX VALUE LOW-VALUES.
MOVE COBOL-VAL-TRUE TO ZTMF OF ZPWY-DDL-DEF-PROG.
or
IF ZTMF OF ZPWY-DDL-DEF-PROG = COBOL-VAL-FALSE . . .
or
IF ZTMF OF ZPWY-DDL-DEF-PROG NOT = COBOL-VAL-FALSE . . .
ENTER TAL "SSINIT"
USING buffer
buffer-length
ssid
header-type
command
[ object-type ]
[ max-resp ]
[ server-version ]
[ checksum ]
[ max-field-version ]
GIVING status.
ENTER TAL "SSNULL"
USING token-map
struct
GIVING status.
ENTER TAL "SSPUT"
USING buffer
token-id
[ token-value ]
[ count ]
[ ssid ]
GIVING status.
ENTER TAL "SSGET"
USING buffer
token-id
[ token-value ]
[ index ]
[ count ]
[ ssid ]
GIVING status.
ENTER TAL "SSMOVE"
USING token-id
source-buffer
[ source-index ]
dest-buffer
[ dest-index ]
[ count ]
[ ssid ]
GIVING status.
wbreidbach
>
> - Zitierten Text anzeigen -
To find the predefines processes I am doing an "INFO" on "SCPROCESS".
To check if a dedicated process is running, I use "STATUS" on that
process. A status using ZPWY-VAL-ALLSCPROCESS as processname should
give you all processes for that serverclass.
But as was said before, do not underestimate the efford. You have to
deal with the context-token to get more than 1 process.
Rich S
I have a working COBOL85 subroutine that uses SPI to perform the
equivalent of a "STATUS TERM XXXX" command. It receives the pathmon
name and term name in linkage.
You might be able to adapt it to retrieve the status of server class
processes. If you're interested, contact me via e-mail and I'll send
you the source code.
Randall
You may also want to try to do this using CORBA instead. It has the
capability of directing messages to a server class or to a specific
instance, depending on the type of CORBA object you instantiate. It is
substantially easier than SPI and leaves the details to the middleware.