Schedule Server Switches
Schedule Server switches can be set remotely through the Schedule Administrator by clicking . Alternatively, in the Schedule Server window, click .
| Switch | Type | Description |
|---|---|---|
| Boolean | If ON, the server populates the DirectDistance field on the Events table, as
well as the RunDirectDistance and RevenueRunDirectDistance fields on the
EventStrings table for Para runs. If OFF, these fields are only populated if dictated by the contract (DistanceCalcRule = 1 on the ProviderCostValidity table. |
|
| Boolean | Toggles the schalg.log file on and off. | |
| Integer ≥ zero (0) | Interval, in seconds, between executing queued up asynchronous scheduling
requests in a batch update. Typically, this only affects requests from MDT Servers. |
|
| Boolean | If ON, batch updates go to the head of the main request queue when they are
ready for update. If OFF, they go to the end of the queue like other requests. |
|
| Boolean | Turns asynchronous batch updates on or off. | |
| Boolean | If ON, allows a break to be taken early (prior to minimum work) if the only
solution. If OFF, results in the break being just before the pull-in and causing a run late violation. |
|
| Boolean | If ON, allows auto-breaks to appear just after the pull-out or just before the pull-in, even if the garage deadhead rule prohibits it. In the case where this is the only viable auto-break solution and the only alternative is for there to be no auto-break at all, the auto-break would appear with a BrR violation. | |
| Boolean |
If ON, auto driver breaks are enabled. Restart the Schedule Server after changing this value. You must run the correct version of the Schedule Server (32-bit or 64-bit) for your machine. |
|
| Boolean | If ON, the auto-breaks algorithm traces a summary to the log of each solution it considers for a run before selecting one. | |
| Integer ≥ zero (0) | Time in minutes that the TimeStamp of the NextETA must be within to use the
NextETA value provided by the MDT. If the TimeStamp has expired, the NextETA value is reset to NULL. Default value is 10. |
|
| Integer ≥ zero (0) | Bad Trip Locator interval in minutes: how often the Bad Trip Locator should scan the schedule for bad trips to either reschedule or move to the bump run. For example, scan the schedule every 30 minutes. Set to 0 to disable. | |
| Boolean | If ON, the automated Bad Trip Locator tries to reschedule trips that are over the Bump Cost before moving them to the bump run. | |
| Integer ≥ zero (0) | The Bad Trip Locator tries to reschedule trips that have a cost greater than
than this cost but less than the Bump Cost. To disable this feature set to zero. If set greater than the Bump Cost this feature will also be disabled. |
|
| Integer ≥ zero (0) | The automated Bad Trip Locator tries will only bump trips that have a cost greater than this cost. | |
| Integer ≥ zero (0) | The maximum total run provider cost allowed for the default bump run at any
given time. Effectively limits the number of trips that can remain on the default bump run based on a sum of their provider costs. Set to zero to disable this rule. |
|
| Integer ≥ zero (0) | Bump run provider cost overdraft limit. The additional provider cost over the Bump Run PC Max that is allowed for temporarily placement of trips on the default bump run. Expressed as an integer in hundredths of a monetary unit. For example, $230.50 would be expressed as 23050. |
|
| Integer ≥ zero (0) | The maximum number of trips allowed to remain on the default bump run. Can be used in combination with Bump Run PC Max in which case the combined rule means the lesser of the two. Set to zero to disable this rule. |
|
| Integer ≥ zero (0) | Default bump run trip overdraft limit. The number of trips over Bump Run Trips Max that is allowed for temporarily placement of trips on the default bump run. |
|
| Integer ≥ zero (0) | The bump manager will not proceed beyond this time on the day before the
schedule. Sites that print run manifests the night before might want to use this setting to ensure that the schedule does not change (due to bumping) after this time. Type the time as the number of seconds from midnight. For example, 64800 for a cutoff of 18:00. If 0, the cutoff time has no effect. |
|
| Boolean | Enables/Disables the default bump run manager and bad trip locator. Not to be confused with Schedule Job Agent Bad Trip Locator jobs. |
|
| Integer ≥ zero (0) | Maximum number of worker threads used by the bump manager. Set to zero to allow the Schedule Server to automatically select an optimum number of threads (recommended). |
|
| Integer ≥ zero (0) | Type an interval in minutes for re-evaluating bumped trips (that is, how
often the bump manager should try to reschedule the trips on the bump run back
into the schedule at below the Bump Cost). For example, re-evaluate the bumped
trips every 60 minutes. Set to 0 to turn off. |
|
| Boolean | If ON, the bump manager attempts to reschedule trips that were moved to the bump run manually or though classic bumping as soon as they are received on the bump run. | |
| Integer ≥ zero (0) | Provides the start of the window as a time offset (in minutes) from the
current time. For example, if it is 480 minutes, no bumping is allowed for trips that have a pick-up time within 8 hours of the current time. The true bump window start time is the greater of now + date offset and now + time offset. |
|
| Trace level | Trace level for bump trip list manager. | |
| Integer ≥ zero (0) |
Level of verbosity when Trace is set to Verbose:
|
|
| Integer ≥ zero (0) | Offset on today's date which provides the start of the schedule date window
in which bumping is allowed. For example, 0 = today, 1 = tomorrow. |
|
| Integer ≥ zero (0) | Length of the bump window in days. | |
| Integer ≥ zero (0) | The Schedule Server will service batch requests at the same priority for the
same schedule in a round robin style. The Schedule Server will attempt to schedule a number of bookings specified by this value before yielding control to the next batch request at the same priority. Requests at higher priority can interrupt the current batch request immediately. |
|
| Boolean |
Specifies whether the capacity swapping algorithm will be applied prior to matching. Runs that exist in both the template schedule (source for the match) and the live schedule (target for the match) and have no capacity type in the live schedule may be assigned a capacity type/vehicle type prior to the matching algorithm commencing for that run. (Note that runs that are only in the live schedule are ignored during matching). Specify one of the following options:
|
|
| Boolean |
Specifies whether AVL break events will be stored in the database, visible in Schedule Editor, and persist after a schedule is unloaded. When disabled, AVL events will persist only in memory and will not be visible in the application. Specify one of the following options:
|
|
| Integer ≥ zero (0) |
Specifies whether cyclic redundancy checking (CRC) logging is enabled for detecting, analyzing, and debugging unexpected deviations in batch scheduling results. Specifically, if you run a batch schedule, return all trips to the state they were in before the batch (for example, unschedule all trips), and then run the batch again with the exact same parameters, one would expect the second batch to produce the exact same result as the first batch, assuming no other changes were made to the trips. However, sometimes a batch may produce a different result than expected. Using CRC logging during batch scheduling records a CRC number for each booking in the batch that represents the solution chosen for that booking. The batch can then be re-run so that Schedule Server reads the CRC log, instead of writing to it, and compares the recorded CRC to the CRC calculated for each booking solution in the new batch. If the CRC numbers are different, it means that a different booking solution was chosen than the last time, which causes the batching process to stop, thereby leaving the offending booking unscheduled, and the offending booking details are traced to the log. These traces are used by a Trapeze developer to analyze or debug the solutions suggested for that booking. Specify a CRC log mode:
|
|
| Integer ≥ zero (0) |
When CRC Log Mode is set to 2, this switch determines which comparison criteria
will be used:
|
|
| Integer ≥ zero (0) |
When the CRC Log Mode is set to 2, the batch will stop after it has scheduled this bookingId and this booking's solutions appear in the log. To log all booking IDs, set this value to 0 (default). |
|
| Boolean | For diagnostic purposes only. Should be set to OFF. |
|
| Boolean | If ON and if the Dump Batch Sort Order is enabled, then the sort order of the trips in the batch will be dumped to the BatchSortOrder table. | |
| Integer ≥ zero (0) | When this number of bookings in a row fails to schedule to the current run
being examined then the group optimizer moves on to the next run. This saves time when scheduling very large groups that can't all fit on one vehicle anyhow. Set to zero disable this cutoff. |
|
| Boolean | If ON, when the group optimizer is in effect, partial groups are also
considered. Such groups of bookings have either a common origin or a common destination, and are within 30 minutes in time. The group optimizer will attempt to minimize the number of runs required to service each partial group. This feature can require significantly more computational time, depending on the number of partial groups. |
|
| Boolean | If ON, the alternate group optimizer sort order will be dumped to the log. | |
| Boolean | If ON, the alternate group optimizer (GrpOpt2) is used. This group optimizer clusters group trips by geography. |
|
| Boolean | If ON, the alternate group optimizer (GrpOpt2) can transport a group of
passengers to one group center, then depart and pick up or drop off more
passengers at a different group center, by re-applying the clustering rules (Max
Angle Threshold, Min Cluster Size, N, Y, and Z switches) only on the new group
center’s trips, disregarding the existing group center trips. If OFF, once a run has trips for a group center, the alternate group optimizer (GrpOpt2) will not consider it eligible to receive new trips to a different location. Recommended setting is ON. |
|
| Boolean | If ON, a step is enabled prior to the clustering of group center X that
allows existing runs traveling to group center A, B, C, and so on, to accept
single trips bound for group center X. This method places trips on existing runs, but does so without honoring the Max Angle, Min Cluster Size, N, Y, and Z switch values. Recommended setting is OFF. |
|
| Boolean | If ON, at the conclusion of the clustering of group center X, the repair step
re-evaluates all trips bound for group center X, and considers moving each of them
to another run already bound for group X, if doing so will lessen the total
driving distance. If even one trip is moved to a different run as a result, the repair step continues, starting over with the first trip bound for group center X, up to the number of iterations specified by the Repair Step Iterations switch. Recommended setting is ON. |
|
| Boolean | If ON, batch scheduling with the alternate group optimizer (GrpOpt2) ends
after trips that qualify for scheduling with the group optimizer are
scheduled. Should be set to OFF. |
|
| Integer ≥ zero (0) | When scheduling using the alternate group optimizer (GrpOpt2) , specifies the
maximum angle between a location and group booking locations. If set to a value other than zero (0), no passenger can be added to a run if this would expand the arc of passengers around the group center beyond the value typed here. Set to 0 for no maximum. |
|
| Integer ≥ zero (0) | When scheduling using the alternate group optimizer (GrpOpt2) , specifies the
minimum distance in meters from a location to a group booking location for the restriction to be applied. Passengers less than this distance from the center are exempted from the Max Angle test. |
|
| Integer ≥ zero (0) | The alternate group optimizer (GrpOpt2) only works on groups with at least
this many riders going to or from a common group center. If the optimizer yields a cluster with fewer than this many passengers, then the cluster is dismissed and trips are scheduled by the regular batch algorithm. Set to zero (0) to disable this feature. |
|
| Integer ≥ zero (0) | Specifies the number of bookings that the alternate group optimizer (GrpOpt2)
looks back when adding a booking to a cluster and measuring the distance from a
possible booking to the existing bookings. Bookings are scheduled in order based on their proximity to the group center and other scheduled group events. |
|
| Boolean | If ON, the group optimizer reverses the search order for the alternate group optimizer (that is, it operates on the bookings farthest from the location, and schedules toward the location). | |
| Integer ≥ zero (0) | Number of times that the repair step re-evaluates all trips bound for group
center X, and considers moving each of them to another run already bound for group
X, when the is on. Recommended starting value is 3. |
|
| Boolean | If ON, when the alternate group optimizer (GrpOpt2) cannot add the selected trip on a run without an ineligible violation, it continues looking for another trip to add on the run. | |
| Boolean | The first group center chosen in a time period is the one with the largest
number of trips heading to it. This switch controls how subsequent locations are chosen. If ON, the next location is the one closest to the previous location. If OFF, the next location is the one with the next highest number of trips (within that time period). |
|
| Integer ≥ zero (0) |
Used to penalize the proximity of a booking which would expand the arc of passengers around the group center. A value of 100 means 100%, and has no effect. Recommended value is 150. When scheduling using the alternate group optimizer (GrpOpt2), specifies a value for weighting possible group booking distance scores based on angles between possible bookings, a location, and other booking locations. The algorithm increases the distance weight of the two closest possible group bookings by (y/100) * (1 + a/360), where a = the largest subtended angle between the location and booking locations in degrees, and y = the value specified by this switch. |
|
| Integer ≥ zero (0) |
Designed to favor a multi-load stop when choosing the next stop to schedule. Recommended value is 100. When scheduling using the alternate group optimizer (GrpOpt2) , specifies a value for weighting distance scores for possible group bookings based on the numbers of passengers being picked up or dropped off. The algorithm increases the distance weight of the two closest possible group bookings by (z/100) * (r+p)/r , where r = the number of group riders already on board, p = the number of passengers being picked up or dropped off at the event location, and z = the value specified by this switch. |
|
| Boolean | If ON, when running a batch to match to a template the driver and vehicle
information will be copied from the template runs for para runs with trips
scheduled on the template. The switch is OFF by default. |
|
| Boolean | If ON, when FX trips are matched from template to live, the trips'
InfoFromDate and InfoToDate are cross-checked against the schedule's live
date. If the dates do not match, the match will fail for the trip and it will remain unscheduled. |
|
| Boolean | If ON, then all batch statistics are output to the PassAgentLog table, even those batches not started from the Schedule Job Agent. | |
| Integer ≥ zero (0) | The batch will save its results to the database each time it modifies this
many runs since the last save. The default value is zero. Setting to zero will allow the Schedule Server to auto-select the cycle size. To turn Periodic Save off set to zero. |
|
| Integer ≥ zero (0) |
Settings are:
Auto on (3) is the same as (2) plus turns on for other schedules whenever their batch is interrupted. |
|
| Integer ≥ zero (0) |
How long (in milliseconds) the batch should pause for before resuming after it is preempted by another client request. A single client request for the same schedule can preempt the batch for the length of the client request. The resume delay is designed to keep the batch paused a bit longer after the client request finishes to allow any additional pending client requests to execute without having to re-pause the batch (pausing can take time because it requires the batch to save its current results to the database.) A recommended value for this switch is between 1000 and 5000 milliseconds (default is 2000). |
|
| Boolean | Trips that are bumped during the batch will be automatically rescheduled. If they cannot be rescheduled, they will be unscheduled. | |
| Boolean | If ON, the system creates shadow versions of the current schedule and allows users to simultaneously schedule bookings on a booking-by-booking basis. Solutions selected from shadow schedules are merged back into the original schedule on save. | |
| Boolean | Turns the shadow scheduling option ON or OFF in the batch. | |
| Integer ≥ zero (0) | Maximum cost differential (as a percent) to allow when selecting the next best solution to resolve a solution collision. For example, a value of 10 will accept the next best solution if its cost is no more than 10% higher than the original best solution. | |
| Integer ≥ zero (0) | Maximum number of solutions to consider per booking during the batch. Typically, the top solution is chosen. However, if that solution is no longer valid by the time the shadow solution is applied, then the batch may select from one of these additional shadow solutions before attempting to find new solutions. | |
| Integer ≥ zero (0) | Maximum number of threads (and shadow schedules) to use during a batch schedule. Set to zero to allow the batch to auto-select the max. | |
| Boolean | If ON, the batch shadow scheduling ensures that
bookings are scheduled in the same order that they appear in the batch sort order.
This reduces performance somewhat but increases the likelihood of the batch
reproducing the same schedule results each time it is repeated with the same data.
If OFF, the shadow scheduling makes more efficient use of the available processing power (and is faster) but may schedule bookings in a slightly different order each time. This can result in repeat batches producing slightly different results. |
|
| Trace level | Trace level for batch shadow scheduling. | |
| Boolean | If ON, includes detailed tracing of all solution collisions. | |
| Boolean | If ON, shadow batch search thread tasks are scheduled with a lower priority than non-shadow tasks. This helps reduce delays for other non-batch tasks when the Schedule Server is running one or more shadow batches. | |
| Boolean | Auto-groups are those that are not tagged with a group code, but are a group
of people who happen to be traveling to and from the same coordinates at the same
time. When enabled, this switch will see to it that the auto-groups are included in the group sorting for the batch sort order irrespective of whether or not the group optimizer is enabled. Works in tandem with the Consider Partial Groups switch. |
|
| Boolean | If a location is within the Radius around group location setting, it will be merged with the location with higher number of visits. | |
| Integer ≥ zero (0) | The minimum number of visits at a particular coordinate for it to be treated as a cluster of trips that are sorted contiguously by batch sort order 10. | |
| Integer ≥ zero (0) | The distance, in meters, around a group location that will encompass nearby non-group trips that get sorted after all group trips of that location by batch sort order 10. | |
| Integer ≥ zero (0) | Size of the periods in minutes used by the batch sort process to calculate a
trip count histogram by time of day. Used to determine an A.M. and P.M. peak time period. |
|
| Integer ≥ zero (0) | Size of the periods in minutes used by the batch sort process to calculate the relative distance of a trip's time period from either the A.M. and P.M. peak time period. | |
| Integer ≥ zero (0) | Offset of the time period used by the batch sort process (added to the hour in minutes). | |
| Integer ≥ zero (0) | Size of the time period used by the batch sort process in minutes. | |
| Integer ≥ zero (0) | Size of the travel time period (in minutes) used by some of the batch sort
orders. Set to zero to allow the batch to determine the ideal period size on its own. |
|
| Integer ≥ zero (0) | Stop the batch after this many bookings. For testing and analysis only. |
|
| Integer ≥ zero (0) | For analysis purposes, you may wish to stop the batch just prior to the scheduling of a particular booking. This way, you may then schedule it in the schedule booking wizard to ascertain why a particular solution is chosen. | |
| Boolean | For testing only. The batch will proceed to search for solutions for each booking, but not actually insert the solution. Can be used to identify bookings that cannot be scheduled. | |
| Boolean | If ON then batch threads are run at 1 point below normal Win32 thread
priority. This yields better performance for other applications running on the
same machine during a lengthy batch. It is particularly useful when running single machine Trapeze installations (such as on a laptop.) Not recommended for live server installations. Default is OFF. |
|
| Boolean | Provides a booking-by-booking performance output during a batch. | |
| Trace Level | Specify the trace level for the Group Optimizer. | |
| Boolean | If ON, a report of the group optimizer results is traced at the end of the
batch. The report shows the groups and which runs they were scheduled to. |
|
| Trace Level | Trace level for the batch-matching algorithm. Set to verbose for details on a booking-by-booking basis. |
|
| Boolean | If ON and is ON, the statistics of each run at the end of the batch are traced to the log. | |
| Boolean | If ON, information about the current batch schedule plus the batch results are traced to the log. | |
| Integer ≥ zero (0) | Controls tracing level for the bulk single insert algorithm. | |
| Integer ≥ zero (0) | Default Mixed Run Tolerance to be used if value is unspecified. | |
| Integer ≥ zero (0) | Sets level of tracing for bulk batch. Set to zero for no tracing, or higher numbers for increasing level of detail. |
|
| Boolean | If ON, the Schedule Server is free to swap capacity types among runs that are not assigned a vehicle. | |
| Trace level | Trace Level for Capacity Type Swapping feature. Verbose level logs everything. |
|
| Boolean | If ON, bumping attempts to insert a trip onto a run if there is already a
trip on that run with the same pick-up and drop-off coordinates. In this mode, the proximity settings are ignored and any trip could be bumped from this run in order to pair up the two trips with the same coordinates. |
|
| Boolean | If ON, for any booking that is to be moved onto a bump run, it must support the Taxi mode of transport. | |
| Integer ≥ zero (0) | For selection of candidate runs to allow bumping on. The trip being inserted must be in a position where the additional distance traveled must not be greater than this percentage, compared to the original distance between the two events surrounding the insert position. For example, if trip B is inserted between trip A and C, then the sum of A->B and B->C must not be this percentage greater than the original distance from A->C. This rule combines the sum of the pick-up and drop-off insertions. |
|
| Integer ≥ zero (0) |
For selection of candidate trips for bumping. The trip will be bumped if it is in a position where the additional distance traveled to reach this trip is be greater than this percentage, compared to the original distance between the two events surrounding the removed trip. For example, if trip B is currently positioned between trip A and C, then the distance from A->B + B->C must be this percentage greater than the distance from A->C, in order for B to be considered for bumping. |
|
| Boolean |
Enables the bumping rules to be used in the schedule wizard solution searches. Note: The Schedule Wizard currently has no way to display
if a trip is being bumped or to where it is to be bumped. This feature is
provided for experimentation only at this time.
|
|
| Integer ≥ zero (0) | For selection of candidate runs to allow bumping on. The trip being inserted must have a total distance from its nearest neighbor events in at least one insert combination on the candidate run of < = this amount; otherwise, bumping is not attempted on the run. The total is the sum of the pick-up and drop-off's nearest neighbor distances. Value is in meters. |
|
| Integer ≥ zero (0) | For selection of candidate trips for bumping. The trip being bumped must have a total distance from its nearest neighbor events of at least this much otherwise it is not bumped. The total is the sum of the pick-up and drop-off's nearest neighbor distances. Value is in meters. |
|
| Integer ≥ zero (0) | This value is only used if Dynamic Remove Proximity is enabled. It is a value expressed as a percentage. The check for the trip being bumped will still use the Remove Proximity (distance from neighboring events must be at least this much) () but the proximity has an additional check based on the Remove Proximity Factor. The dynamic value of the remove proximity is proportional to the proximity of the candidate trip being inserted. The sum of the candidate trip's pick-up and drop-off's neighbor distances, multiplied by the Remove Proximity Factor, becomes an additional floor proximity value which the trip to be bumped must exceed. |
|
| Boolean | With this switch enabled, the check for the trip being bumped still uses the
Remove Proximity (distance from neighboring events must be at least this much) but
additionally the proximity will have an additional check based on a dynamic
value. The dynamic value is proportional to the proximity of the candidate trip being inserted. The sum of the candidate trip's pick-up and drop-off's neighbor distances, multiplied by the Remove Proximity Factor switch setting, becomes an additional floor proximity value which the trip to be bumped must exceed. |
|
| Boolean | If ON, bumping is based on the classic insert and remove proximity
checks. If OFF, the standard checks will not apply, but the dynamic remove proximity and/or distance ratio may apply if enabled. |
|
| Boolean | For testing purposes only. | |
| Boolean | If ON, the Distance Ratio settings are used in addition to the proximity
settings. If OFF, only the proximity settings for determining the candidate trips to be insert and bumped is applied. |
|
| Boolean | If ON, the Schedule Server confirms whether the trip has been dispatched immediately before scheduling it. Dispatched trips will not be scheduled. | |
| Integer ≥ zero (0) | Database connections that are idle for longer than this number of seconds
will be closed. The default is 600 (10 minutes). Set to zero for no timeout. |
|
| Trace Level | Message level traces opening and closing of database connections in the
pool. Verbose level adds tracing of gets and puts to the pool. |
|
| Boolean | Set to ON if the Oracle database is 9i or greater. Set to off if it is Oracle 8 or lower. | |
| Boolean | Set to ON to use Rule-based optimizer hints for selected Oracle database queries. | |
| Boolean |
Settings are:
|
|
| Boolean | Inflation factor for deadhead weight. Set to zero for auto-select, or between 1 and 25 for manual values. |
|
| Boolean | The maximum amount of deadhead distance, in meters, that is allowed before a
violation is incurred. This does not apply to garage deadhead. Set to zero to disable. |
|
| Boolean |
Settings are:
|
|
| Boolean |
If ON, the booking accessibility masks are enforced in the search routines through violations. If OFF, the Schedule Server will not accessibility masks and will not create violations. Restart Schedule Server after changing this value. You must run the correct version of the Schedule Server for your machine (32-bit or 64-bit). |
|
| Boolean | If ON, when a critical error is experienced by the Schedule Server during the calculation of event times, the run is automatically frozen in order to prevent further trips from being scheduled on it. | |
| Boolean | If ON then only one thread at a time in the Schedule Server can perform a
database transaction or query. Turning this feature ON can help prevent the Schedule Server from creating self deadlock situations with some DBMS's. Turning this feature OFF can improve throughput and performance of scheduling operations. This switch should be left OFF unless too many self-deadlocks are occurring. |
|
| Boolean | When enabled, a event with a floating geocode (for example, a break) assumes
the geocode of either the previous or following event, depending on slack time,
travel time, and scheduled times. When disabled, the event assumes the geocode of the prior event. |
|
| Boolean | If ON, automatic ferry crossing events may be created for live same day inserts. | |
| Boolean | If OFF, the multi-load time reduction feature is disabled. | |
| Boolean | If ON, the OBT calculation uses the time from the last passenger loading at
the pick-up location to the first passenger unloading at the drop-off location. It
will not depend on the client loading order when multiple passengers are picked
up. If OFF, the OBT calculation uses each client's specific load and unload times at the pick-up and drop-off locations. OFF by default. |
|
| Boolean | Internal Use Only. | |
| Boolean | Enables improved EstTime calculation on taxi runs. If
ON, the following improvements are included in taxi run
EstTime calculations:
If OFF, the old method for calculating taxi EstTimes is used. |
|
| Boolean |
Allows the Schedule Server to generate the preview for the top-ranked solution of a solution set automatically. Enabling this switch might improve performance by reducing the number of transactions that the Schedule Server performs to deliver a list of solutions and a preview of the top-ranked solution to the Schedule Booking Wizard. |
|
| Boolean | On drag and drop, calculate schedule times of the booking that is being
scheduled for the first time. If ON, this action will apply SchMultiParameter
values. If OFF, new bookings will adopt the negotiated times as their scheduled times. |
|
| Boolean |
If ON, the booking mode of transport flags are enforced in the search routines and through TM violations. If OFF, the Schedule Server does not enforce mode of transport and does not create TM violations. Restart Schedule Server after changing this value. You must run the correct version of the Schedule Server for your machine (32-bit or 64-bit). |
|
| Boolean | If ON, as a performance enhancement for escort searches, one find one solution on an empty run for each <ProviderId, FromGarageId, ToGarageId> run combination. | |
| Boolean | If ON, for an escort to be scheduled onto a run, the employee ProviderId must match the run's ProviderId (if neither one is zero). | |
| Boolean | If ON, the booking escorts will be processed. | |
| Boolean | If ON, escort searches use fast costing only, without re-costing under street
routing. This may result in very poor escort solutions being chosen, and should only be used if the improvement in search performance warrants it. |
|
| Integer ≥ zero (0) | The maximum number of simultaneous clients to which an escort is able to
attend. For example, if the value is set to 8, and a ninth client who requires a general escort is added, a second general escort is needed. Users who do not have a maximum can set the value to zero. |
|
| Integer ≥ zero (0) | As a search time optimization, ignore any escort who is to be picked up this
many meters away from the client's pick-up location. Set to 0 to disable this switch. |
|
| Integer ≥ zero (0) | A hard upper bound on the number of general escorts to be considered from the
general escort pool for any solution. This setting does not effect bookings that have specific dedicated escorts, or bookings that are scheduled to runs with assigned escorts. |
|
| Integer ≥ zero (0) | A solution that sees an escort on board with no clients requiring escorts
during an event with slack time greater than this many minutes, is considered a
Hostage violation. Set to zero to have no maximum. |
|
| Integer ≥ zero (0) | The maximum percentage of clients allowed on-board at the same time who
require an escort. Used in conjunction with the Maximum Escortable Clients Pct Takes Effect At switch. |
|
| Integer ≥ zero (0) | The percentage of clients allowed on-board at the same time who require an escort is allowed to be 100% if the number of clients requiring escorts is less than this value. In other words, the Maximum Escortable Clients Pct takes effect when this many clients are on board. | |
| Boolean | In order to minimize the number of permutations for escorts, only solutions that involve the escorts being picked up immediately before they are needed, and dropped off immediately after the last client requiring an escort is dropped off will be considered. | |
| Trace level | Trace level for escort scheduling. | |
| Boolean | If ON, then escort-specific Event table Activity values will be employed. | |
| Integer ≥ zero (0) | Set the switch to 2 (DCES Zonal Cache). Previously, fast costing distances were determined by triangulation (0). |
|
| Boolean | If ON, fast costing results are returned as is without being re-costed using the normal approach. This is only used for analysis of fast cost results. | |
| Integer ≥ zero (0) | The average speed is multiplied by this factor when calculating travel times
using fast costing. It is desirable for fast costing to not under estimate the speed so that it does not miss any valid solutions. Value is the factor times 100 where 100 means a factor of 1 and 120 means a factor of 1.2, and so on. |
|
| Boolean | If ON, statistical information about fast costing efficiency is traced to the log. | |
| Boolean | If ON, all final distance and travel times are calculated using the same
formula that is used in fast costing. This is useful only for analysis of fast costing performance. |
|
| Integer ≥ zero (0) | Similar to fast cost depth. It determines how many candidates to recost with street routing (or whatever the official distance method is) before stopping. |
|
| Boolean | Enables an experimental algorithm based on an approximation of best-to-worst
search order. For testing only. Currently does not support transfers. |
|
| Integer ≥ zero (0) | Trace the FastFind algorithm. | |
| Boolean | Sorts the final solutions by the way they where roughly costed by the
candidate generator rather than by the official cost weights costing. Turn ON to see how accurate (or inaccurate) the fast find candidate costing is compared to the cost weights. |
|
| Integer ≥ zero (0) | Sets the CapacityType when auto-create runs is used (only sets it upon creation). | |
| Integer ≥ zero (0) | Sets the From GarageId when auto-create runs is used (only sets it upon creation). | |
| Integer ≥ zero (0) | Sets the From GarageId when auto-create runs is used (only sets it upon creation). | |
| Integer ≥ zero (0) | Sets the Provider ContractId when auto-create runs is used (only sets it upon creation). | |
| Integer ≥ zero (0) | Sets the ProviderId when auto-create runs is used (only sets it upon creation). | |
| Boolean | If ON, the Schedule Server performs an extra check at the time the FX run is loaded to verify that the stop times and stop numbers for each trip are synchronized. Any discrepancies are reported to the log file. | |
| Boolean | If ON, the auto-create fixed runs feature generates runs that represent
entire line directions. If OFF, it generates runs that represent blocks. Does not affect Flex run activation. |
|
| Boolean | If ON, Schedule Server reads AllowedLines.txt for a comma-separated list of
LineDirId's to be considered for solutions. For experimental usage only. |
|
| Boolean | When a flag stop drop-off is encountered, if a corresponding flag stop pick-up can be found, the two events will replaced with a new booking pick-up and drop-off. | |
| Boolean | If ON, Schedule Server will identify FX runs that are associated with a
signUp that is no longer part of the schedule, and will attempt to move the trips
from such runs to corresponding (by LineDirIdConst) runs that are consistent with
the schedule's signUps. This action is performed at the time a schedule is loaded. |
|
| Integer ≥ zero (0) | Events will be migrated to the runs with valid signUps only if the stop times are within this many seconds of the original events' stop times. | |
| Trace level | Sets the level of tracing for the FX Signup Migration logic. | |
| Boolean | If ON, the server imports existing SchMultiParameter records into the new Context Property mechanism. | |
| Boolean | If ON, the Schedule Server ignores attempts to set actual coordinates on an event if the coordinates have either a latitude or longitude of zero. | |
| Boolean | If ON, an incident will be created if a scheduled booking has its pick-up and/or drop-off coordinates updated, and the booking is kept in its position on the run. | |
| Boolean | If ON, incidents are not created for events with an arrived status (except for cancellations). | |
| Boolean | If ON, incidents are not created for taxi runs (except for cancellations, bookings moved to different runs, or requested time changes). | |
| Boolean | Trace level for incident set/get processing. | |
| Boolean | Enables lazy publishing of RTV updates (that is, updates, deletions and
creation of runs). Turn ON to alleviate the risk of RTV events causing a bottleneck in Schedule Server performance due to an outage or slow network traffic. Default is ON. |
|
| Integer ≥ zero (0) | When the lazy publisher is given new work to do it will wait this long before
starting the work. Default is 200 milliseconds. |
|
| Boolean | Enables lazy writing of faring and passenger updates on Booking tables. Does not affect updates to Events table. Turn ON for improved performance under high load. | |
| Integer ≥ zero (0) | Maximum bookings updated per transaction. | |
| Integer ≥ zero (0) | When the lazy writer is given new work to do, it waits this long before starting the work. | |
| Integer ≥ zero (0) | When the lazy writer is writing, it introduces this delay between
transactions to help reduce the load on the database server. Can be set to zero for no delay. |
|
| Integer ≥ zero (0) | Increasing this value above the default of 500 increases the load balancing
costing weight. The formula multiples the percent of maximum work used by this value, then multiples the costing weight setting (0–25). |
|
| Integer ≥ zero (0) | Specify the number of high priority threads available on top of worker
threads for requests such as GetScheduleList, which may block the Workstation
GUI. Set to zero to disable the feature. |
|
| Integer ≥ zero (0) |
Defines how maximum OnBoard time factor units are interpreted:
|
|
| Integer ≥ zero (0) | Defines how many requests can be processed at the same time. Note that
requests for the same SchId are still processed individually. The minimum value is 0, and the maximum value is 16. Trapeze recommends setting this switch to 0 to allow the server to determine the optimum number of worker threads based on the number of processors in the system. |
|
| Integer ≥ zero (0) | Trace level for the run mirroring algorithm. | |
| Integer ≥ zero (0) |
Trace level for tracing mobility aid solution searches:
|
|
| Integer ≥ zero (0) |
|
|
| Boolean | If ON, the search algorithm uses parallel processing to speed up fast cost
recosting. Enable this switch and to control multi-threading. |
|
| Boolean | If ON, parallel processing is used for the operation. | |
| Integer ≥ zero (0) | Maximum number of schedules that will be loaded at the same time during start
up or schedule load list refresh. Default is 4. |
|
| Integer ≥ zero (0) | Type the maximum level of concurrency for parallel operations. Set the value to zero (0) to allow automatic selection of concurrency level. |
|
| Integer ≥ zero (0) | Maximum number of schedules that will have their estimated times recalculated
at the same time in response to operations like invalidating the DCES
cache. Default is 4. |
|
| Boolean | If ON, the search algorithm uses parallel processing to speed up the solution
search. Enable this switch and to control multi-threading. |
|
| Boolean | If ON, parallel processing statistics related to Solution Search and Fast Costing are traced. | |
| Boolean | If ON, activity performance profile statistics will be reset every 24 hours at midnight. | |
| Integer ≥ zero (0) | Traces the activity performance profile statistics to the log. The frequency
of tracing is determined by the number of minutes specified in this switch. Set to zero to turn off. Takes immediate effect. |
|
| Integer ≥ zero (0) |
|
|
| Integer ≥ zero (0) |
Settings are:
|
|
| Boolean |
If ON, a banded cost (such as banded mileage) is enforced to use the rate exclusively specified by the band that the total falls into. Set to OFF to enforce the rate applied to the portion of the total that falls into each band. For example, if you have two bands (0–1000m @ $2 per km, and 1001m+ @ $1.5 per km) and the total is 1.5 km, the cost is 1.5 × 1.5 if this switch is ON. If OFF, the cost is 1 × 2 + 0.5 × 1.5. |
|
| Boolean | If ON, provider costing is enabled. If OFF, provider costing is disabled. |
|
| Boolean | If ON, provider quotas are enabled. If OFF, provider quotas are disabled. |
|
| Trace Levels | Trace level for provider quota calculations. | |
| Boolean | Trace level for provider costing calculations. | |
| Integer ≥ zero (0) | Event string (run) ID filter for Trace. Zero for all. Used in combination with Trace SchId, allows tracing to be limited to a single run for simpler analysis (recommended). | |
| Integer ≥ zero (0) | Schedule Id filter for Trace. Zero for all. |
|
| Integer ≥ zero (0) | Will trace a snapshot of the current contents of the request queue with an
interval of this many seconds. Set to zero to turn this trace off. Default is 0 (off). Takes effect immediately. |
|
| Integer ≥ zero (0) | When traced, will display no more than this many items from the head of the
queue. Takes effect immediately. |
|
| Integer ≥ zero (0) | The request queue will only be trace if it contains > = this many
items. Takes effect immediately. |
|
| Integer ≥ zero (0) | A warning will be logged for discrepancies between forward and reverse travel
time. Calculations that reach or exceed this number of seconds. Set to zero to turn off all warnings. |
|
| Boolean | If ON, Reverse Travel Algorithm are enabled for speed by time of day
calculations. If OFF, the original, a less accurate method is used. |
|
| Integer ≥ zero (0) |
During run optimization, up to this many positions are considered for each booking, given the current state of the run at that point in the process. Recommended values are 2 or 3. Higher values result in excessive solution times. |
|
| Integer ≥ zero (0) | After this many seconds, the optimization process on all runs terminates immediately. | |
| Integer ≥ zero (0) | After this many seconds, the branching factor is reduced to 1 to ensure a quick end to the optimization process (though results are likely not optimal). | |
| Trace Level | Trace the run optimization process. Verbose for all details. |
|
| Boolean | If ON, when the user drags and drops a booking into a run itinerary, the
pick-up will be placed at the indicated position, but the algorithm will search
for the best position for the drop-off. If OFF, the drop-off will be placed immediately after the pick-up. |
|
| Boolean | If ON, the Schedule Server searches beyond the FCostDepth limit in order to
reach the Itinerary Search Depth. This setting can increase the quality of itinerary solutions but will require the server to expend more time searching. |
|
| Boolean | If ON, the Schedule Server controls the number of possible solutions at deeper levels in the itinerary search tree when the itinerary has more than 2 bookings. | |
| Integer ≥ zero (0) | Maximum number of top solutions per booking in itinerary scheduling to
combine with the solutions for the next booking in the itinerary. For example, if set to 2 and there are 3 bookings in the itinerary, the total maximum number of combined solutions returned would be 2×2×2 = 8. If 3 it would be 3×3×3 = 27. |
|
| Integer ≥ zero (0) | Time out (in milliseconds) to use during solution searches when the search timeout parameter is set to zero. | |
| Integer ≥ zero (0) | Closes single insert solution sets that are idle for this number of minutes. | |
| Boolean | If ON, only the best ranked solution per run will be shown when
Show All Run Variations is not checked. If OFF, multiple runs per solution may be shown if they vary by walking distance or schTime when Show All Run Variations is not checked. |
|
| Boolean | If ON, enables an algorithm speed-up whereby potential solutions are
dismissed up front based on the candidate run's polygon May inhibit performance if the site has a large number of and/or complex polygons. |
|
| Boolean | If ON, when performing a search on a scheduled booking, the current solution
will always be included in the results, even if the current solution is invalid
due to violations or other problems. If OFF, the current solution of a booking is not added to the result set automatically, and will only be considered if the solution is still viable. |
|
| Boolean | If ON, the same day single insert and batch searches will avoid suggesting
solutions that involve inserting new events into positions that are already
history. This feature can be used in combination with the auto driver layover feature. |
|
| Integer ≥ zero (0) |
Specifies the tracing level for the solution search process:
|
|
| Boolean | If ON, the old pull-out cost behavior is use. If OFF, the improved pull-out cost behavior is used. |
|
| Boolean | Enable the Space Time Cone heuristic speed-up. | |
| Integer ≥ zero (0) | Level of tracing for space time cone calculations:
|
|
| Integer ≥ zero (0) | Sets the speed (in kilometers per hour) for space-time cone model to
eliminate solution candidates that violate space-time constraints. Set to 0 for pre-calculated times to be used. |
|
| Trace Level | General trace level switch for the scheduling service. | |
| Boolean | If ON, the server traces additional information about all currently active client requests. | |
| Trace level | Sets the level of tracing for advance notice profile logic. | |
| Trace level | Specify the trace level for the AgentThreads process. | |
| Boolean | Trace out the run itinerary before and after the AVL break event is added to
a run. To debug cases where the EventOrder field appears to change on all subsequent events. |
|
| Boolean | If ON, the server traces DCES statistics. If OFF, the server does not trace DCES statistics. |
|
| Integer ≥ zero (0) |
Settings are:
|
|
| Boolean | If ON, the server traces a message to the log whenever it has to renumber all the EvOrder values on a run due to running out of gaps between events. | |
| Integer ≥ zero (0) |
Settings are:
|
|
| Trace level | Sets level of tracing for Schedule idle time processing. | |
| Boolean | If ON, all incoming requests will be traced to the log file at the moment they are received. | |
| Boolean | For developers only. Traces out timing information on schedule locks. |
|
| Trace level | Trace level for OPS service integration calls such as OPS Day Activation. | |
| Boolean | If ON, contents of each response sent back by the server to the client are traced. | |
| Boolean | If ON, additional trace information is gathered during schedule loads. Use this switch to diagnose loading errors. |
|
| Trace Level | For developers only. Trace level for worker threads. |
|
| Boolean | If ON, uses the PASS 480 InfoTransfers table, which stores transfer
information in a signup-independent manner. If OFF, the old Transfers table will be used, which does not have an interface in PASS 480. |
|
| Boolean | If ON, transfer solutions are found more quickly. If OFF, less memory is used. |
|
| Boolean | If ON, solutions involving different trips on the same route will be considered. | |
| Boolean | If ON, the deprecated ParaPolyTransfer table is used. This table should be used only if you have old transfer data involving polygons that has not been merged into InfoTransfers. If OFF, ParaPolyTransfer will be ignored. |
|
| Integer ≥ zero (0) | Maximum distance a flex route bus is assumed to be able to deviate from its
fixed route for a pick-up or drop-off. This value should be set as low as possible as it has a similar effect to expanding the walking distance on search speed. Value is in meters. |
|
| Integer ≥ zero (0) | For internal use only. | |
| Integer ≥ zero (0) | For internal use only. | |
| Boolean | If ON, maximum transfers are limited to one more than the solution with the
fewest number of transfers found so far (not including no transfer para
solutions). This helps to speed up the search but may cause some valid solutions to not be returned. |
|
| Integer ≥ zero (0) | Maximum number of transfer patterns to consider for any from/to service combination. | |
| Integer ≥ zero (0) | Minimum direct distance (in meters) that the booking must have in order for transfer solutions to be considered. | |
| Integer ≥ zero (0) | Minimum ride length in meters for any given transfer inner leg in a transfer solution. An inner leg is a bus that does not do the first pick-up or final drop-off. | |
| Integer ≥ zero (0) | Minimum ride length in meters for any given start or end leg in a transfer solution. | |
| Boolean | If ON, when solutions are found for a particular from/to service and #transfers, additional solutions for the same pattern where only the origin or destination stops differ are skipped. | |
| Integer ≥ zero (0) | Indicates how many of the nearest bus stops per line direction are considered for the origin/destination points during the search for transfer solutions. | |
| Integer ≥ zero (0) | Controls tracing level for transfers algorithm. | |
| Boolean | If ON, the From/To Services search queue is traced as the search progresses. | |
| Integer ≥ zero (0) |
Adds this amount of time (in seconds) to every travel time calculation regardless of the length of the original travel time. This value is added BEFORE the Minimum travel time rule is applied, and does not apply when distance is zero. Restart the Schedule Server after changing this value. This is an experimental feature. You must run the correct version of the Schedule Server for your machine (32-bit or 64-bit). |
|
| Integer ≥ zero (0) | When tabulating slack time for a run's statistics, a segment of slack must be
at least this many minutes for it to be added to the total. A segment of slack less than this many minutes will be omitted from the statistical slack totals. Set to 0 for all slack to be included. |
|
| Integer ≥ zero (0) |
Enforces a minimum travel time. Any travel time calculated as less than this value will be increased to equal this value. Does not apply when distance is zero. Value is in seconds. Restart the Schedule Server after changing the value. (This is an experimental feature.) You must run the correct version of the Schedule Server for your machine (32-bit or 64-bit). |
|
| Integer ≥ zero (0) | Only applies if Angular Backtrack Check is being used. If the arc formed between a client pick-up, any intermediate event, and a client drop-off is greater than this many degrees, backtracking does not qualify. |
|
| Integer ≥ zero (0) | Only applies if Angular Backtrack Check is being used. If the distance to a client drop-off increases from its minimal distance from an intermediary stop prior to the drop-off by more than this percentage, a backtrack violation applies. Disabled by setting to 0. |
|
| Integer ≥ zero (0) | Only applies if Angular Backtrack Check is being used. The Destination Retrenchment Ratio check will not apply once travel enters a circle around the destination of radial length defined by this setting. If travel then leaves this circle, a BT violation may be incurred. Note that for the origin, the Distance Threshold switch setting applies. |
|
| Integer ≥ zero (0) | Only applies if Angular Backtrack Check is being used. If either vector forming the arc between a client pick-up, the applicable intermediate event, and a client drop-off is less than this many meters, backtracking does not qualify. |
|
| Integer ≥ zero (0) | Only applies if Angular Backtrack Check is being used. If the distance from a client pick-up decreases from its maximum distance from an intermediary stop prior to the drop-off by more than this percentage, then a backtrack violation applies. Disabled by setting to 0. |
|
| Boolean | If ON, client backtracking is determined by measuring the angle between the
arc formed by the client pick-up coordinate, any intermediate event coordinate and
the client drop-off coordinate. Use in conjunction with the Angle Threshold and Distance Threshold switches. If OFF, the original circular-intersection method is used. |
|
| Boolean | If ON, disables OBT (on-board time) violations for Para runs. The switch is OFF by default. |
|
| Boolean | If ON (the default setting), then estimated time calculations for linked
trips will consider duration of stay constraints with the intent of minimizing
violations which are induced by unscheduling/rescheduling trips between runs. For
example, DUR violations (which occur when the stay is too short or too long
between linked trips) and HO violations. In other words, if a trip is rescheduled from run A to run B, new violations on run A will prevent a new solution on run B from being allowed. With this change, the algorithm may now take slightly longer, it may find solutions that it did not find previously, and it may possibly reject solutions that were previously reported. To restore previous behavior, set to OFF. |
|
| Boolean | Cache service area rule polygon check as a performance improvement. | |
| Boolean | Tells the schedule wizard search to ignore the current violation set and allow any violations when searching for solutions. | |
| Boolean | Tells the schedule wizard search to ignore the current violation set and allow any violations, but only if it can't find any solutions with the current violation set. |