Sdaemons: Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (Created page with "Many of the <var class="product">Sirius Functions</var> interact with a facility provided with the <var class="product">Sirius Mods</var> called an '''sdaemon'''. Sdaemons are th...")
 
(add pointer to other parms affected)
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
Many of the <var class="product">Sirius Functions</var> interact with a facility provided with the <var class="product">Sirius Mods</var>
Many of the [[List of $functions|SOUL $functions]] interact with a facility provided with version 7.5 and greater of Model&nbsp;204 and formerly with the <var class="product">[[Sirius Mods]]</var>
called an '''sdaemon'''.
called an '''sdaemon'''.
Sdaemons are threads which do work on behalf of another user.
Sdaemons are threads which do work on behalf of another user.
They accomplish this by automatically logging onto a requesting user's ID (under
They accomplish this by automatically logging onto a requesting user's ID (under
the covers), then issuing standard <var class="product">Model 204</var> commands as if the user was issuing
the covers), then issuing standard <var class="product">Model&nbsp;204</var> commands as if the user was issuing the commands himself.
the commands himself.
This makes it possible to have <var class="product">Model&nbsp;204</var> commands executed on
This makes it possible to have <var class="product">Model 204</var> commands executed on
behalf of a user while that user is running a <var class="product">[[SOUL]]</var> procedure.
behalf of a user while that user is running a <var class="product">User Language</var> procedure.
   
   
Associated with sdaemons is the concept of '''family''':
Associated with sdaemons is the concept of '''family''':
Two threads are in the same family if one is a synchronous child sdaemon
Two threads are in the same family if one is a synchronous child sdaemon
of the other via a <var>$Comm</var> function or a <var class="product">[[Janus SOAP]]</var> Daemon object.
of the other via a <var>$Comm</var> function or a <var class="product">SOUL</var> <var>[[Daemon class|Daemon]]</var> object.
In addition, all families with common threads are considered to be a
In addition, all families with common threads are considered to be a
single family.
single family.
Line 17: Line 16:
same family.
same family.
Furthermore, if in this example, thread B had two other synchronous
Furthermore, if in this example, thread B had two other synchronous
children (via <var>[[Daemon class|Daemon]]</var> objects), threads D and E, then threads A, B, C,
children (via <var>Daemon</var> objects), threads D and E, then threads A, B, C,
D, and E would all be considered part of the same family.
D, and E would all be considered part of the same family.
   
   
Before <var class="product">Sirius Mods</var> 6.8, threads in a family could get record locking
One condition exists under which two threads in the same family can still
conflicts with each other.
suffer a record locking conflict: if they both try to update the same
This greatly limited what could be done on sdaemon threads.
As of <var class="product">Sirius Mods</var> 6.8,
the one condition under which two threads in the same family can still
suffer a record locking conflict is if they both try to update the same
record, which would require both threads to have an exclusive pending
record, which would require both threads to have an exclusive pending
update lock on the record being updated.
update lock on the record being updated.
This possible conflict is eliminated if the sdaemon is a <var class="product">Janus SOAP</var>
This possible conflict is eliminated if the sdaemon is a <var class="product">SOUL</var>
[[Daemon class#Transactional daemons|transactional daemon]].
[[Daemon class#Transactional daemons|transactional daemon]].
   
   
For more information on setting up sdaemons,
==Defining Sdaemon threads==
see the [http://www.sirius-software.com/maint/download/siri.pdf Sirius Mods Installation Guide].
Many of the Model&nbsp;204 add-on products make use of sdaemon threads to offload
processing from the Online user's thread. These Model&nbsp;204 threads are analogous to <code>IODEV=3</code> threads.
For proper operation of these products, you must have sufficient numbers of
sdaemon threads defined in your <var>ONLINE</var> configuration. The [[Janus products]] Janus
Web Server, Janus Sockets (for server ports), Janus Specialty Data Store, and Janus
Open Server all use sdaemon threads to process client connections. Many [[RKTools]] products also require sdaemon threads for brief units of work.
 
It is recommended that a site have at least four sdaemon threads if using any RKTools products, and have an sdaemon thread for each concurrent connection that will be maintained by a Janus product.
To define the sdaemon threads for an <var>ONLINE</var>:
<ol>
<li>Specify the <var>[[IODEV parameter|IODEV]]</var> number to be used for sdaemon threads.
Use the User 0 parameter <var>[[SDAEMDEV parameter|SDAEMDEV]]</var>. The <var>SDAEMDEV</var> parameter can be any odd number from 1 to 53.
 
<blockquote class="note">
<p><b>Note:</b> The <var>IODEV</var> number selected for <var>SDAEMDEV</var> will be unavailable for its normal function. Thus if <var>SDAEMDEV</var> is set to 7, <var>IODEV</var> 7's will not be available for their normal function (VTAM full screen support). </p>
<p>
The recommended setting for <var>SDAEMDEV</var> is 15, unless a site is using BTAM TTY terminals. Adding a line to the User 0 parm card like the following will indicate that any <var>IODEV</var> 15 thread is to run as an sdaemon thread: </p>
<p class="code">SDAEMDEV=15 </p>
</blockquote></li>
 
<li>Increase <var>[[NUSERS parameter|NUSERS]]</var> by the number of sdaemon threads to be defined.
<p class="note"><b>Note:</b> Increasing <var>NUSERS</var> might require adding space to the Model&nbsp;204 server data sets. </p>
<p>
Depending on the number and type of sdaemon threads you will be using, you may also need to adjust the settings of the <var>[[MAXDAEM parameter|MAXDAEM]]</var> and <var>[[MAXBG parameter|MAXBG]]</var> parameters. See [[Daemons#Thread limits|Thread limits]].</p></li>
 
<li>Add <var>IODEV</var> statements to CCAIN for each sdaemon thread.
It is recommended that the <var>[[LECHO parameter|LECHO]]</var> parameter be set to 0 for sdaemon threads.
<p>
The following statements define six sdaemon threads (assuming <var>SDAEMDEV</var> was set to 15): </p>
<p class="code">IODEV=15,POLLNO=1,NOTERM=6,LECHO=0
IODEV=15,POLLNO=2
IODEV=15,POLLNO=3
IODEV=15,POLLNO=4
IODEV=15,POLLNO=5
IODEV=15,POLLNO=6 </p></li>
</ol>


[[Category:Overviews]]
[[Category:Overviews]]

Latest revision as of 23:07, 2 February 2016

Many of the SOUL $functions interact with a facility provided with version 7.5 and greater of Model 204 and formerly with the Sirius Mods called an sdaemon. Sdaemons are threads which do work on behalf of another user. They accomplish this by automatically logging onto a requesting user's ID (under the covers), then issuing standard Model 204 commands as if the user was issuing the commands himself. This makes it possible to have Model 204 commands executed on behalf of a user while that user is running a SOUL procedure.

Associated with sdaemons is the concept of family: Two threads are in the same family if one is a synchronous child sdaemon of the other via a $Comm function or a SOUL Daemon object. In addition, all families with common threads are considered to be a single family. So, if thread A is a synchronous parent of thread B, which is a synchronous parent of thread C, threads A, B, and C are all considered part of the same family. Furthermore, if in this example, thread B had two other synchronous children (via Daemon objects), threads D and E, then threads A, B, C, D, and E would all be considered part of the same family.

One condition exists under which two threads in the same family can still suffer a record locking conflict: if they both try to update the same record, which would require both threads to have an exclusive pending update lock on the record being updated. This possible conflict is eliminated if the sdaemon is a SOUL transactional daemon.

Defining Sdaemon threads

Many of the Model 204 add-on products make use of sdaemon threads to offload processing from the Online user's thread. These Model 204 threads are analogous to IODEV=3 threads. For proper operation of these products, you must have sufficient numbers of sdaemon threads defined in your ONLINE configuration. The Janus products Janus Web Server, Janus Sockets (for server ports), Janus Specialty Data Store, and Janus Open Server all use sdaemon threads to process client connections. Many RKTools products also require sdaemon threads for brief units of work.

It is recommended that a site have at least four sdaemon threads if using any RKTools products, and have an sdaemon thread for each concurrent connection that will be maintained by a Janus product. To define the sdaemon threads for an ONLINE:

  1. Specify the IODEV number to be used for sdaemon threads. Use the User 0 parameter SDAEMDEV. The SDAEMDEV parameter can be any odd number from 1 to 53.

    Note: The IODEV number selected for SDAEMDEV will be unavailable for its normal function. Thus if SDAEMDEV is set to 7, IODEV 7's will not be available for their normal function (VTAM full screen support).

    The recommended setting for SDAEMDEV is 15, unless a site is using BTAM TTY terminals. Adding a line to the User 0 parm card like the following will indicate that any IODEV 15 thread is to run as an sdaemon thread:

    SDAEMDEV=15

  2. Increase NUSERS by the number of sdaemon threads to be defined.

    Note: Increasing NUSERS might require adding space to the Model 204 server data sets.

    Depending on the number and type of sdaemon threads you will be using, you may also need to adjust the settings of the MAXDAEM and MAXBG parameters. See Thread limits.

  3. Add IODEV statements to CCAIN for each sdaemon thread. It is recommended that the LECHO parameter be set to 0 for sdaemon threads.

    The following statements define six sdaemon threads (assuming SDAEMDEV was set to 15):

    IODEV=15,POLLNO=1,NOTERM=6,LECHO=0 IODEV=15,POLLNO=2 IODEV=15,POLLNO=3 IODEV=15,POLLNO=4 IODEV=15,POLLNO=5 IODEV=15,POLLNO=6