A General Reset (GRS) cycle is a sequence of messages initiated by the PMS to update the System database to match that of the PMS. The GRS message signals to the system that a sequence of Check in/out messages will be sent to the system concluding with a GRS END message. During the GRS cycle, any message initiated by the system (Maid Status, Message Waiting, Alert, Message Registration) will be queued until the completion of the GRS cycle.
The PMS initiates the GRS cycle by sending an ENQ messages followed by a GRS message. The regular PMS-to-System handling for this message occurs including any timeout/retry handling. Upon receiving the GRS message the system will create a Hotel Log indicating that a GRS Message is Received. In 3300 Release 8.0 or greater, the GRS message is also forwarded to all the hospitality ICPs in the cluster so that all ICPs can act on the message. (In SX2000 or 3300 prior to Release 8.0, only the node connected to the PMS will act on the message.) The PMS is immediately sent a response. Each ICP that receives this GRS message will perform the necessary system action.
The system(s) that receive the GRS message will:
Create a cache (in memory) for all the rooms to indicate that all the rooms are to be considered checked in.
Provide a response to the Hospitality Gateway to indicate the memory was allocated properly.
A failure to distribute the GRS message to the necessary ICPs and receive its response within 10 seconds will result in the GRS cycle being abandoned.
A failure to allocated cache memory in any of the hospitality nodes will result in the GRS cycle being abandoned.
In 3300 Release 8.0 and later, abandoning the GRS cycle simply clears the cache and no further database updates related to the GRS cycle are performed. A hotel log is generated for this case. The system remains in GRS mode, the PMS is not notified of this failure, and any subsequent check-in/out messages will not be acted upon by the system until the system returns to normal mode. In 3300 Release 8.0 or earlier, abandoning the GRS cycle means that the system will update the database according to the GRS data for all the rooms that it has received so far.
Note: If a system receives the GRS message when a GRS cycle has already been started, then the system will re-initialize its cache.
The PMS continues the GRS cycle by sending ENQ followed by check-in/out requests to the system. The regular PMS-to-System handling for this message occurs including any timeout/retry handling. During the GRS cycle only check-in/out messages are expected from the PMS. The PMS can send check-in/out status to indicate the occupancy status of each guest room. In a clustered environment (3300 Release 8.0 or later), the check-in/out message is also forwarded to the hospitality ICP that hosts the guest room. The PMS is immediately sent a response. Each ICP that receives this GRS check-in/out message will perform the necessary system action.
The system(s) that receive the check-in/out message during the GRS cycle will:
Update the cache to reflect the status from the PMS.
Provide a response to the Hospitality Gateway to indicate that the memory was updated properly.
A failure to distribute the check-in/out message during the GRS cycle and receive its response within 10 seconds will result in the GRS cycle being abandoned.
A GRS check-in/out message must be received within 20 seconds of the previous GRS check-in/out message or the GRS message. Otherwise a timeout of the GRS cycle will occur, and the GRS cycle will be canceled and the system returns to normal mode.
A GRS check-in/out received without being able to allocate the GRS cache is a failure, and will result in the GRS cycle being abandoned.
In SX2000 or 3300 Release 8.0 UR3 or4 or earlier, if a check-in/out message specifies a non-guest room, then the GRS cycle will be abandoned.
In 3300 Release 8.0 UR4 or later, if a check-in/out message specifies a DN that the hospitality gateway does not recognize as a guest room, then this transaction is logged, but the GRS cycle continues. If the check-in/out message specifies a DN that is a guest room on the hospitality gateway but not a guest room on the hospitality ICP, then the transaction is logged (at the hospitality ICP) and the GRS cycle is abandoned.
Any other messages received by the system during a GRS cycle (for example, Name) will result in the system canceling the GRS cycle, and acting on the received message. The system returns to normal mode.
Any error distributing a GRS message to a hospitality ICP will result in the GRS cycle being abandoned.
Canceling a GRS cycle results in abandoning the cycle and returning to normal operation mode. The next request is processed as outside the GRS cycle.
Note: Check-in/outs should be performed on guest rooms, and not suite members.
The PMS terminates the GRS cycle by sending an ENQ messages followed by an END message. The regular PMS-to-System handling for this message occurs including any timeout/retry handling. This END message is used by the system to indicate that the PMS is attempting to finish a GRS cycle. A Hotel Log is created indicating that a GRS Message is Received. In a clustered environment (3300 Release 8.0 or greater), the END message is also forwarded to all the hospitality ICPs in the cluster. The PMS is immediately sent a response. Each ICP that receives this END message will perform the necessary system action.
The system(s) that receive the END message during the GRS cycle will:
Attempt to lock its database. The system will only continue to the next step once the database is locked. If it cannot lock the database (possibly due to a database write by another process), it will retry the lock again in 5 seconds. The system must lock the database to ensure data consistency and therefore attempts the lock forever with a 5 second delay between each attempt.
Once the database is locked, the system compares the data in the database and the value in cached memory and performs the necessary actions for all rooms.
If the database indicates that a room is checked in and the cache indicates the room is checked-out, then the room is checked-out.
If the database indicates that a room is checked out and the cache indicates that the room is checked-in, then the room is marked as occupied. A check-in operation is not performed.
If the room is checked-in via a GRS cycle, only the occupancy is changed to occupied. Other hospitality data will be left intact. If the room is checked-out via a GRS cycle, then the all the regular database updates done upon a regular check-out are also done.
The hospitality ICPs will provide a response to the Hospitality Gateway to indicate that the memory was updated properly.
A failure to distribute the END message during the GRS cycle and receive the responses response within 30 minutes will result in a hotel log on the hospitality gateway indicating that the GRS database updates took too long, and that the databases may be out of sync.
A GRS END message must be received within 20 seconds of the previous GRS check-in/out message or the GRS message. Otherwise a timeout of the GRS cycle will occur, and the GRS cycle will be abandoned.
A GRS END message received without ever receiving the GRS message is a failure, and will result in the GRS cycle being abandoned.
Once the GRS END is received, the Hospitality gateway and ICPs will independently commit their changes to the database. Prior to 3300 8.0 UR4, all messages from the PMS are rejected with a NAK during this phase. In 3300 8.0 UR4 and later, messages may be NAK'd a number of times but eventually will succeed and will be buffered for processing once the database is again available.
