Resource selection rules

Request selection rules are used to order queues of requests for resources when requests are being removed from the queue. This occurs when a resource becomes available.

Before you create your own tailored selection rules and write the corresponding selection functions, you should understand the logic used by the selection function. When the following occurs: a resource becomes available, then the selection function is called. The request queues are contained in internal lists owned by the respective resource that are initially ordered by the sequencing rule. When the selection function is called, it reorders this list and returns the maximum number of requests to be considered in the allocation process. If the whole list is sorted, it returns the size of the list. Thus, if the number of requests returned is less than the size of the list, the sorted list for allocation may be only part of the queue of requests.

The allocation process begins by attempting to restart the operation for the first request on the sorted list for allocation that requires the number of available units or fewer. If the allocation process fails, the next request on the sorted list for the number of available units or fewer is considered. Successive requests on the sorted list for allocation are considered until the available units have been allocated or the end of the sorted list for allocation is reached. If there are available units after the last request is considered, they remain idle.

Selection functions differ from sequencing rules in that they may modify a request’s position in the request list each time that the resource becomes available. This allows requests to “age”. Consider the example from the preceding section where requests are both sequenced and selected by time until due date. At 1 p.m. today a load with a due date at 4 p.m. today places a request and is given a ranking value of 3. At 3 p.m. today, a load with due date at 5 p.m. today places a request and receives a ranking value of 2. Assume that these are the only requests in the queue. Suppose that a resource becomes available at 3:30. The request list would then be re-sorted with the request having ranking value of 3 first, because it has only 0.5 hours until it is due. The request with ranking value 2 would be second because it has 1.5 hour until it is due.

Your user defined selection function can have any name that is not the name of a standard system function. The selection function accepts as its only argument, a pointer to the resource (Type: RESRC*). All return a value (Type: int) which is the maximum number of requests to be processed. Here is an example of a resource selection function based on minimum setup:

int slrl (RESRC *rp)
/*-----------------------------------------------------------------
   Selection function to process a resource request list by using
   the minimum setup time for this resource on the first downstream 
   setup or setup/operation operation for each load. Loads which 
   have no downstream setup or setup/operation operation are assumed

   to have a setup time of zero.

   NOTES:
   * The estimate flag is set to false for jscmsu so that it will
    use the current conditions to find the setup time. Since the
    jobstep could be downstream, there is no guarantee that the
    current conditions for the resource in question will still
    be appropriate when the setup actually occurs. Therefore, 
    this rule should only be used when the structure of the model 
    guarantees that the conditions for the downstream resource 
    will be constant till the setup occurs.

   ARGS:
    rp - pointer to resource to resequence

   RETURNS: number of requests in the request list
-----------------------------------------------------------------*/
{
   RREQ *rq;
   JOBSTEP *jsp;
   int i;

   for ( rq = (RREQ *) csfsls(rp->rsrqls);
      rq != NULL;
      rq = (RREQ *) csnxls((CSENTITY *) rq) ) 
   {

     /* Find first downstream setup jobstep. */
     for ( jsp = rq->rrload->lojspt, i = 0;
        jsp != NULL && jsp->jstype != 4 && 
        jsp->jstype != 13 && i < 1000;
        jsp = jsp->jspnxt, i++);

     /* Compute setup time (zero if no setup jobstep). */
     if (jsp == NULL || i >= 1000) 
     {
       rq->rrprio = 0.0;

     } 
     else 
     {
      /* Place a tag for the resource. This allows the step
        time to be computed properly for the downstream
        jobstep assuming that the load allocates the 
        resource before any other load. */

      dumrtag->rtrsrc = rp;
       cspols(rq->rrload->lorsls, (CSENTITY *) dumrtag, CSLIFO, NULL);
      rq->rrprio = jscmsu(0, rq->rrload, jsp);
      csgpls(rq->rrload->lorsls, (CSENTITY *) dumrtag);
     }
   }
   /*Sort list based on rankings.*/
   cssols (rp->rsrqls, serqor);

   /*return number in list*/
   return (csszls(rp->rsrqls));
}

To make your custom resource selection function available to the Scheduler, you must “install” it from the first user-initialization function ucini1 by calling the function sedfsl. This function has two arguments in the following order:

1. The number of the selection rule for which your selection function contains custom logic.
2. The address of your selection function.

Notice that if you select a dynamic selection rule, the system will ignore your sequencing rule and use FIFO. If you write a “dynamic” selection rule, you should also emulate the system and force the use of FIFO. To do this, invoke function setosq on the applicable request list.