Commands to be included in the system are made ready to be run in the system after lexer design, syntax and semantic controls by Piricihain Virtual Machine. In addition, malicious (devil codes) codes for locking the system from the logical side are detected (if found, they are reported to the Pirichain system) and bad codes are extracted.
Each scenario code written on the system is given an execution time of maximum 50 seconds. Every process that has not finished running (throwing runtime timeout error) within this time scale is canceled. Each canceled scenario is administratively reported by the server. A certain number of scenarios that tire the system (receiving a timeout error) are removed without notice. Addresses that frequently repeat the same situation in the system are blocked regardless of the balances of the assets in them. These addresses cannot operate in the system and cannot access the system. An example of cross-scenario work is briefly shown in Figure 2.3. The data sent by the user with a certain balance in the scenario is sent to Scenario B. Before Scenario B is run, “Scenario Execution Authorization” is checked. Otherwise, the Program is terminated. If available, it is sent to Scenario C and Scenario C is run. The program is terminated without running any scenario for the user with no balance.
Figure 2.3: Working example between scenarios
In Figure 2.4, a structure constructed between scenarios in detail has been created. As seen in the structure, it shows that the data requested from the school and the Ministry of Education of a student applying to X university is run on the scenario of X university.
Figure 2.4: Detailed operational view of scenarios