JPS6410866B2 - - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION Technical Field of the Invention The present invention relates to an automatic recovery method when a total system goes down in a totalizer system.

PRIOR ART AND PROBLEMS At public velodromes and racetracks, totalizer systems using computers are used to automate ticket issuance, refunds, etc. FIG. 1 is a schematic diagram showing an example of the system, and 1 and 2 are computers in a master and slave relationship, which are the heart of a packaged ticket issuing and refund system called a totalizer. 3
are provided in multiple terminal control processing units (TCM),
A large number of unit terminals 4 are connected to each lower level. These terminals 4 are distributed and installed at each voting station within the venue. One terminal 4 is provided with two operation consoles, and the sale (issuance) of voting tickets desired by the customer is performed from these operation consoles. In other words, the information on the voting ticket to be issued, such as the race number, the combination of voting horse numbers, etc., is simultaneously transferred to computers 1 and 2 and tallied by each computer, and a ticket issuance command is sent to the TCM 3, where it is collated and if they match. The ticket is returned to the terminal that made the request, and the voting ticket desired by the customer is sold at that terminal. The above-mentioned sales operation of each terminal 4 is performed randomly, and mutual diagnosis (abnormality detection) is performed between the computers 1 and 2, for example, every minute. 5 is a large outdoor display that displays the approximate expected payout rate (odds) for each race, and customers refer to this display when voting. The odds are updated, for example, every minute based on the total number of votes. 6 is a small indoor display such as a television, which similarly displays information such as Otsuzu. When the start notification is issued, the display is fixed to the content at that time, and when the race is over and the finish order is determined, the judge will notify the finish order, and computers 1 and 2 will calculate the payout based on it, and It is displayed on the displays 5 and 6. 7 is a card reader, 8 is a line printer, and 9 is a main console, all of which are controlled by the computer 1 on the master side.

Even if a failure occurs on one side of the system, for example, if a failure occurs on the master side, there is no problem because the slave side takes over. However, if both the master and slave become faulty at the same time due to a memory parity error or abnormal software execution (both systems fault), the system will eventually go down. In the totalizer system, it is not possible to leave the system down for a long time, so it is necessary to recover it quickly, but conventionally this has been left to manual operation by the operator, which has the disadvantage that it takes 5 to 7 minutes to recover.

OBJECTS OF THE INVENTION The present invention aims to automate restarting the system immediately after it goes down, thereby quickly recovering the system.

Structure of the Invention The present invention is characterized in that terminals for issuing tickets, refunds, etc. are distributed at each voting ticket sales office, and the center side performs processing such as aggregation, calculation of expected dividends, calculation of refund amount, etc. based on data from the terminals. In a totalizer system, a master computer and a slave computer are installed, the master computer and slave computers perform mutual diagnosis, and when a failure occurs in the master computer, the slave computer takes over the processing. When both slave computers go down at the same time, the memory contents of that computer, such as the bet pool file, are kept on an external storage medium immediately before the downtime, and then the user iPL routine is started by the management program of that computer.
The present invention is characterized in that recovery processing is automatically performed on the condition that a separately provided automatic recovery switch is turned on, and this will be explained in detail below with reference to the illustrated embodiment.

Embodiment of the Invention FIG. 2 is a flowchart showing an embodiment of the present invention, and the solid line frame indicates the process immediately before down. "CKPT file KEEP" is a step to keep (KEEP) the contents of the checkpoint file (CKPT) in the bulk core memory (BCM). The next step, ``Core BPF KEEP,'' is a step to keep the contents of the bet pool file (BPF) in the BCM as well. Here, the contents of BPF are multiplication factors related to races currently on sale (1-2, 1
-3, etc.), and based on this, the odds are calculated, and the expected or final dividend is calculated. Please note that voting tickets will be sold in order of race, not all at once for each race, for example, from 10:00 to 10:50 for the first race.
The second race will be held from 10:50 to 11:10. Since the access time of BCM is long, the race for the currently on sale is stored in the CPU's memory, and when the next race is released, it is stored in the BCM, but in the event of a failure, the BPF on the memory is transferred to the BCM. Keep it. ``Failure message output'' is a step for outputting a message indicating what type of failure it is. The message indicates, for example, the type of hardware check failure, memory parity error, CPU abnormality, program check abnormality, etc., and is output to the console typewriter. At this time, in order to later check the cause of the failure, the SE or CE (maintenance engineer) will check the CPU
Keeps all memory contents of on disk (DiSK). The contents of this DiSK include inspection after every race,
Output from a line printer during repair.

The following steps are necessary for recovery,
These and the above routines are added according to the present invention. The "iPSW routine" is located in the OS (management program) of the computers 1 and 2 shown in FIG. 1, and when the user jumps into it, the "user iPL routine" is started. The routine determines whether the startup is a normal startup or a startup after a system failure (recovery startup). Specifically, 13 of the 16 entry switches
It is determined whether the th ENTRY S/W 13 (described later) is turned on. Here, turning on the switch means starting up recovery. If it is on, move on to the recovery routine.

"CBBR GET" is the step to obtain (GET) the common branch bus (CBBR).
That is, as shown in FIG. 3, master A and slave B have changeover switches, and the 0th and 1st switches are used to select DiSK-A and DiSK-B.
DiSK-A is the disk on the CPU-A side (master side), and in addition to 200 to 300 programs,
Approximately 30 types of data files are stored.
The same applies to DiSK-B. The second and third switches are for CBBR, these are low speed i/
Switch O (card reader 7, line printer 8, main console 9, etc.) to the master side and slave side. The fourth and fifth switches are magnetic tapes.
This is for switching between MT-A and MT-B. The second to fifth switches are left in the neutral state, and the A side and B side are selected by software. If these switches are manually pushed up or down (with A or B selected), they cannot be switched using software. Therefore, it is always kept neutral and the software selects A or B, but this is released when the system goes down. Therefore, it is necessary to acquire (GET) CBBR again after the system goes down. This is the step. The next "Dispatch TR KEEP" is terminal (voting ticket vending machine) 4
This step is to keep the status of the system just before the system goes down, specifically the transaction status (transaction) TR of each console connected to each terminal, in list format on the magnetic tape MT. By printing out this list later and comparing it with the information (history) on the computer side, it is possible to determine whether, for example, the system was down before the voting tickets were actually issued even though the voting tickets were processed and the sale instructions were issued. Alternatively, it is possible to determine whether a system failure has occurred before performing aggregation processing and issuing a ticket issuing instruction, and thereby processing such as reconciling ledgers and cash can be performed. The next "FiLE restoration" is the vote count file BPF, the total number of tickets issued for each console file TiP,
Since the checkpoint file CKPT was kept on the BCM just before the system went down, this step is to expand it onto the core (computer memory).

The next "MODE instruction" will be explained with reference to FIG. There are a plurality of TCMs (terminal control processing units) 3 shown in FIG. 1, and each TCM consists of two microcomputers L#1 and L#2. These two microcomputers L#1 and L#2
is for multiple terminals, one from top to bottom and the other from bottom to top (assuming that the terminals are numbered,
Data is collected at high speed by performing double bowling in the opposite direction (on one side from the smallest number to the largest number, and on the other from the largest number to the smallest number).
However, there is no interaction between L#1 and L#2. For this reason, the master 1 side or slave 2 side
The side asks the TCM whether L#1 and L#2 are currently operating as dual units (two units) or as a single unit (one unit).
It informs you of the operating mode, such as whether the machine is operating on the machine or not. This is the "MODE instruction". As an example, there are 4 TCMs and 48 terminals are connected to each TCM, so the number of terminals is 192, and the number of operation consoles is 2 times that, 384. This "MODE instruction" also includes an instruction as to whether the TCM should transfer data to the master or slave, or in other words, whether the master or slave is dual mode or kangle mode.

The following "operation control" is a step for instructing, for example, whether or not the terminal is in a state where it can issue tickets, or whether or not subtraction processing after ticket issuance is possible. The next step, ``Status List Output,'' is a step in which the number of races that have currently been completed is output on a form using a typewriter (line printer).
The last "ONL START processing (OST)" is when master and slaves 1' and 2' are added as options, and online (ONL) is performed on the sub side, that is, the added master and slaves 1' and 2'. This is a step to notify that the master and slaves 1 and 2 on the main side have started up, and is not necessary in a standard system with only the master and slaves 1 and 2.

Conventional user iPL routines do not consider automatic startup at all, so the OS jumps to the user iPL routine and ends with the iPL, waiting for the user to enter an initial startup command manually (stop). ). However, in the present invention, the start of the iPL routine is automated (however, it is necessary to keep the aforementioned switch 13 on while driving).
Since the recovery start-up operation by the operator is no longer necessary, the recovery time, which used to take 5 to 7 minutes, is shortened to about 2 to 3 minutes. Also, this system
It was equipped with a BCM and a disk, and files were stored in these to make them redundant, and the operator decided whether to restore files from the BCM or the disk. Therefore, the operator may have trouble deciding whether to start up from BCM or disk, but with this invention, it is automatically started up from BCM,
No operator judgment is required. Also, since the conventional "all memory KEEP" is not performed, it takes about an hour to perform it manually by the operator.
It was difficult to resume operations immediately. On the other hand, with "KEEP all memory", you can complete keeping all memory contents to disk in a few seconds to a few seconds, so you can enter iPL immediately after this.

Effects of the Invention As described above, the present invention has the advantage that even if a total system failure occurs in a totalizer system that performs operations such as ticket issuing and refunds at public stadiums, it can be quickly and automatically recovered.

[Brief explanation of drawings]

Fig. 1 is a schematic configuration diagram showing an example of a totalizer system, Fig. 2 is a flowchart showing an embodiment of the present invention, Fig. 3 is an explanatory diagram of common branch bus acquisition, and Fig. 4 is an explanatory diagram of mode instruction. It is. In the figure, 1 and 2 are totalizers (computers), and 4 is a terminal.

Claims (1)

[Scope of Claims] 1. Terminals for issuing tickets, refunds, etc. are distributed at each voting ticket sales office, and the center side performs processing such as aggregation, calculation of expected dividends, calculation of refund amount, etc. based on data from the terminals. In a totalizer system, a master computer and a slave computer are installed, mutual diagnosis is performed between the master computer and the slave computer, and when a failure occurs in the master computer, the slave computer takes over the processing. When both slave computers go down at the same time, the memory contents of that computer, such as the bet pool file, are kept on an external storage medium immediately before the downtime, and then the user iPL routine is started by the management program of that computer, and a separately provided automatic An automatic recovery method for the totalizer system that automatically performs recovery processing on the condition that the recovery switch is turned on.