The Configuration jump event modifies all properties of the NewServerConfiguration object, at the jump event's trigger time, except the ServerPerf property, which is modified using the Performance jump event object.

The Performance jump event modifies the scalar rating of the NewServerConfiguration object by applying the PerformanceJumpPercent property value to the ServerPerf property value at the trigger time of the jump event.

For example, in Base Model A, the ServerPerf property value is 560. In jump event #2, the PerformanceJumpPercent property value of 88.6% is applied to 560, results in 1056.16, and updates the ServerPerf property to the rounded value of 1056. In jump event #4, the PerformanceJumpPercent property value is 66.7%, which is applied to then current ServerPerf property value of 1056, results in 1760.35. The ServerPerf property is updated to the rounded value of 1760.

The Configuration jump event modifies all properties of the NewServerConfiguration object including the Rack-based properties, at the jump event's trigger time, except the ServerPerf property, which is modified using the Performance jump event object.

The Performance jump events are the same as specified in the "Modify server config & performance" example.

In this example, the rack size and rack server quantity (i.e., server quantity within a rack) are not changed from what is defined in Base Model B. The server configuration changes are the same as specified in the "Modify server config & performance" example.

In the example above, the PerformanceType property value of "Pool" triggers an increase of 5% to the ServerPerf property value of all existing server inventory and the NewServerConfiguration object.

For example, re-rating the performance of an entire pool may be due to a network upgrade that significantly reduces I/O wait time of pool CPUs.

The Demand Jump Event DemandType property with value 'GrowthPercent" modifies the ServiceDemandGrowthPercent property value to 30 at trigger time 1.25 years. The DemandPercent property value represents an absolute value that replaces the value of the ServiceDemandGrowthPercent property in the EvolutionRules object.

The DemandPercent property value must be a positive number. A simulation cannot be evolved, over time, based on a negative demand percentage (e.g., -10).

The Demand Jump Event DemandType property with value 'AbsPermanent" will increase absolute demand by 15% at 1.25 years. This is a onetime modification and does not modify the ServiceDemandGrowthPercent property in the EvolutionRules object.

The DemandPercent property value represents a relative change that is applied to current absolute demand at the selected trigger time. This value may be positive or negative. A value of zero will fail validation.

In the above example, the DemandPercent property value will increase absolute demand by 15% at 1.25 years for 1 month. Because this is transitory demand, Zypr will automatically add an additional Demand jump event, with a trigger time at 1.33 years (i.e., 1 month later), that reverses the initial transitory demand increase.

The ServiceDemandGrowthPercent property value in the EvolutionRules object is not modified, but service demand is assumed to continue during the transitory period. Therefore, the automatically generated demand value of the reversing Demand jump event will be higher than the initial demand increase.

The DemandPercent property value must be a positive number. The valid values for the TransitoryDurationMonths property are (1-6), inclusive.

This type of material shift in demand often arises in retail sales events, business functions with narrow windows of higher demand (e.g., healthcare insurance enrollment period), etc.

Shifting a pool's utilization boundaries upward can delay adding new servers to the pool to satisfy demand growth. This is a one-time event when the interval duration time increases as the upper utilization boundary is shifted from 65% to 70%.

Alternatively, it may be more desirable to remove this "extra" capacity (physically or logically) from the pool for use somewhere else. This is accomplished by setting the RemoveServers property to 'true'. How that is accomplished by Zypr depends on the type of simulation selected.

When the simulation type is 'Optimal', removing excess servers from the pool is based upon the preferred queue order (see InventoryQueueBias property). If the simulation type is 'Fixed', the queue order is oldest to newest and therefore will remove the oldest chronological age servers regardless if it meets the refresh age threshold set in ServerReplacementTime property in the SimulationRules object.

A constraint is an expression of a desired limitation: what is not permitted. The above constraint therefore reads as follows:

"The server inventory balance is not permitted to be greater than 226 at or after the time of 1.5 years."

Constraints are particularly useful when other resources - software, space, power, network - are approaching a hard limitation and the cost to remove the resource limitation is significant. Constraints provide a means to 'bound' a forecast to respect the limitation, determine if a feasible solution even exists, and if so, at what cost. This can then be compared to the cost of a solution without the constraint plus the cost to remove the resource limitation itself.

In the above code block, the ConsumptionRules object is highlighted. The counting rule is conditional because the LicenseMetric property value is 'Processor' but the counting method is based on different thresholds of 'Core' quantity.

The first level Operator property is set to 'Or', which indicates the rules contained in the Rule array are mutually exclusive. If the rules in the array prove not to be mutually exclusive when compared to actual physical inventory, it will cause the simulation to fail.

The MetricName property value specifies the physical inventory unit to evaluate. The consumption rules in the above code block reads as follows:

"When the physical quantity of cores per processor is less than or equal to 32, the required quantity of processor licenses is 1. When the physical quantity of cores per processor is greater than 32, the required quantity of processor licenses is 2."

The code block above illustrates rules for two different outcomes. The code block below extends the above example to demonstrate rules for three different outcomes.

"ConsumptionRules": {
      "Operator": "Or",
      "Rules": [
        {
          "Id": "1",
          "RequiredLicenseQty": 1,
          "MetricName": "CoreSetSize",
          "Operator": "LessThanOrEqual",
          "TargetValue": 32
        },
        {
          "Id": 2,
          "Operator": "And",
          "RequiredLicenseQty": 2,
          "Rules": [
            {
              "Id": "2.1",
              "MetricName": "CoreSetSize",
              "Operator": "GreaterThan",
              "TargetValue": 32
            },
            {
              "Id": "2.2",
              "MetricName": "CoreSetSize",
              "Operator": "LessThanOrEqual",
              "TargetValue": 64
            }
          ]
        },
        {
          "Id": "3",
          "RequiredLicenseQty": 3,
          "MetricName": "CoreSetSize",
          "Operator": "GreaterThan",
          "TargetValue": 64
        }
      ]
    }

Rule Id 1 is constructed to illustrate rule nesting. When nesting boolean logic, the RequiredLicenseQty property is set to the same rule level in the hierarchy.

The more concise way to write Rule Ids 1.1 and 1.2 would be:

{
  "Id": "1",
  "RequiredLicenseQty": 1,
  "MetricName": "ProcessorSetSize",
  "Operator": "LessThanOrEqual",
  "TargetValue": 2
}

The consumption rules in the full code block above reads as follows:

"When the physical processor set size of a server is 1 or 2, the required server license quantity is 1. When the physical processor set size of a server is 4, the required server license quantity is 2. When the physical processor set size of a server is 8, the required server license quantity is 4."

The ConsumptionRules object need only define counting rules for the type servers initially included in the ServerInventory object and any new type of servers that might be added to the pool, at later times, as defined by the then current state of the NewServerConfiguration object.

The consumption rules in the full code block above reads as follows:

"When the physical processor set size of a server is 1 or 2, the required server license quantity is 1. When the physical processor set size of a server is 4, the required server license quantity is 2. When the physical processor set size of a server is 8, the required server license quantity is 4."

The ConsumptionRules object need only define counting rules for the type servers initially included in the ServerInventory object and any new type of servers that might be added to the pool, at later times, as defined by the then current state of the NewServerConfiguration object.

The code block above modifies the Fee property, of the SoftwareItem object with license #3, to 550 at the trigger time 1.5 years.

A Software Price Change may be used to modify a software item whose ContractType property is 'Instance' or 'Coterminous'. However, this jump event object may only be used for 'Coterminous' contract types only if all Schedule properties of all Rate objects in the CostRules are set to 'None'.

In other words, the Software Price Change jump event cannot be used to change a license fee or support percentage when the Cost Rules object is also attempting to change the same license fee or support percentage.

The example above sets a price schedule for the 'Perpetual' license Fee property of the SoftwareItem object that is increased 5% annually. Support is defined as a percentage of the perpetual license fee (see PerpetualSupportPercent property in SoftwareItem). In this example, the support cost will automatically increase by way of the perpetual license fee.

Alternatively, if a vendor is setting their price schedule for support by increasing the percentage rate, use the ChangePercent property for 'PerpetualSupport'.

For software items with the LicenseClass property of 'Perpetual', the LicenseType property of the CostRules must be either 'Perpetual', 'PerpetualSupport', or both. If the desired price schedule is for software items with the LicenseClass property of 'Subscription', the LicenseType property of the CostRules, if included, must equal 'Subscription'.

The example above sets a fixed fee, based on a fixed duration, of 50% of the target schedule duration. In this example, the schedule is based on annual true-up. When an incremental license is added, the fixed fee will be based on 6 months, regardless of actual usage time.

A fixed duration rule may also be defined for a 'Subscription' license. It cannot be applied to a 'Perpetual' license, which does not have a Duration object.

In the example above, when an incremental 'Perpetual' license fee is incurred, the cost for that license will be posted to the evolution time-interval when it is first required/used. In contrast, the associated costs for 'PerpetualSupport' is posted at the evolution time-interval that contains the next true-up date.

The SoftwareStackRegistry array defines the composition of a pool's initial software stack at time zero. In the code block above, the software stack only includes license #1. Only software items in the software stack may incur a cost.

To add one or more software items to a pool's software stack at a future time, the software items need to be defined in the SoftwareInventoryTerms array. The SoftwareStackAdd jump event object must reference software items not already in the software stack.

In the above code block, license #2 is added to the SoftwareStackRegistry at trigger time .5 years.

To designate the initial license position of license #2 at trigger time .5 years, use the InitialPosition property to set a value. In the above code block, license #2 has an initial license position of 0. If the InitialPosition property was set to null, Zypr will set the initial license position to the actual hardware unit balance at the trigger time of .5 years.

To remove a software item from a pool's software stack at a future time, the software item must already be included in the SoftwareStackRegistry. Use the SoftwareStackRemove jump event object to define when the software item should be removed from the SoftwareStackRegistry. After a software item is removed from the software stack, no further costs associated with the license are incurred by the pool.

In the code block above, license id #2 is being remove from the pool's stack at trigger time 0.5 years.

Actual consumption for 'Coterminous' contract types is based on maximum (peak) quantity consumed, which carries forward to the next true-up or contract term. Zypr will attempt to reduce license positions, at contractually permissible windows, in a manner that doesn't later cause positions to "re-acquire" a higher license position resulting in higher costs. Therefore, Zypr cannot guarantee a reset to a lower position is feasible.

For the example above, the RenewalSchedule property is set to 'Contract'. Only at each contract anniversary date (i.e., 3-year intervals), Zypr will attempt to reduce license positions. Alternatively, by setting the RenewalSchedule property to 'TrueUp', Zypr will attempt to reduce license positions annually corresponding to the true-up date.