Compaq ACMS for OpenVMS
Getting Started


Previous Contents Index

16.3 Customer Checks Out a Car (Beginning the Rental)

Bertram Simpson now has a reservation for a compact vehicle rental from April 19, 1991, until April 22, 1991. He shows up at the reservations counter at AVERTZ later in the day on April 19, after having made his reservation earlier that day. The following dialog takes place while Bertram Simpson checks out the car to begin the rental period:

Figure 16-6 Checkout Panel


Figure 16-7 Checkout Update Panel


Figure 16-8 Car Selection Panel


Figure 16-9 Checkout Completion Panel


Clerk: "Hi, can I help you?"
Customer: "Yes, my name is Bertram Simpson and I have a reservation for a compact car for today."
Clerk: "OK, Mr. Simpson, let me call up your reservation."

The clerk enters the following at the AVERTZ Rental Menu (Figure 16-1 shows the AVERTZ Rental Menu):

Selection: 2 [Return]


AVERTZ displays the checkout panel shown in Figure 16-6.

Clerk: "OK, Mr. Simpson, could I have your reservation number?"
Customer: "Sure, I have reservation number 2."
Clerk: "Thank you."

The clerk enters the following:

2 [Return]


AVERTZ displays the checkout update panel shown in Figure 16-7, with the cursor positioned at the Credit Type field.

Clerk: "Are you still planning on paying with cash, Mr. Simpson?"
Customer: "Yes, I am."
Clerk: "Great."

The clerk enters the following:

[Return]


AVERTZ displays a list of available vehicles, as shown in Figure 16-8.

Clerk: "Do you have any options that you want with your vehicle?"

The clerk uses the following table to determine what each option code means:
Code Option
00 Standard transmission
01 Cruise control
02 Tape deck
03 Sunroof
04 4-wheel drive
05 Roof rack
06 Bulletproof glass and body

Customer: "Well, I have a bit of a drive into the mountains, so if you have a car with a tape deck, that would be great."
Clerk: The clerk presses the down-arrow key and the Select key to select the first available vehicle with option 2.
AVERTZ now displays the checkout completion panel, as shown in Figure 16-9.
Clerk: The clerk enters the following to complete the checkout:

[Do]


AVERTZ displays a message indicating that the checkout is completed, and then prompts the clerk to press [Return] to continue.

"OK, Mr. Simpson, you're all set. Here are the keys to a Chevrolet, NH license plate 899BHV. The vehicle does have a tape deck, and is located in the parking area just to the left of our front door. When you return the car, please record the odometer reading before you check the car back in. Do you have any questions?"

Customer: "No, that's great. Thank you very much."
Clerk: "You're welcome. Have a good weekend and see you on Monday."

The clerk enters the following to return to the AVERTZ Rental Menu:

[Return]


AVERTZ returns to the AVERTZ Rental Menu.

16.4 Customer Checks In a Car (Ending the Rental)

Bertram Simpson had a great weekend and is now ready to return the car to AVERTZ. He shows up at the reservations counter at AVERTZ on April 22. The following dialog takes place while Bertram Simpson checks in the car to end the rental period:

Figure 16-10 Checkin Panel


Figure 16-11 Checkin Update Panel


Clerk: "Hi, can I help you?"
Customer: "Yes, my name is Bertram Simpson and I'm returning a car that I rented over the weekend."
Clerk: "OK, Mr. Simpson. Let me call up your reservation."

The clerk enters the following at the AVERTZ Rental Menu (Figure 16-1 shows the AVERTZ Rental Menu):

Selection: 3 [Return]


AVERTZ displays the checkin panel shown in Figure 16-10.

Clerk: "OK, Mr. Simpson. Could I have your reservation number?"
Customer: "Sure, I have reservation number 2."
Clerk: "Thank you."

The clerk enters the following:

2 [Return]


AVERTZ displays the checkin update panel shown in Figure 16-11, with the cursor positioned at the Credit Type field.

Clerk: "Are you still planning to pay with cash, Mr. Simpson?"
Customer: "Yes, I am."
Clerk: "OK."

The clerk enters the following:

[Return]


AVERTZ moves the cursor to the Return Date field. Because that field displays the current date (22-Apr-1991), the clerk enters the following to move to the Mileage In field:

[Tab]


"Can you tell me what the return odometer reading was, Mr. Simpson?"

Customer: "Yes, it was 357."
Clerk: The clerk enters the following:

357 [Tab]


The Adjustment field allows for adjustments to the bill due to special circumstances (such as charges when customers return cars without the gas tank filled). Entering a negative amount increases the bill; a positive amount decreases the bill. There are no special circumstances associated with this rental, so the clerk enters the following to process the checkin:

[Return]


AVERTZ flashes the total cost of the rental.

"Mr. Simpson, the total cost is $30 dollars."

Customer: "Here's the $30 and the keys. Thanks."
Clerk: "You're welcome. And thank you for renting with AVERTZ!"

The clerk enters the following to return to the AVERTZ Rental Menu:

[Return]


AVERTZ returns to the AVERTZ Rental Menu.


Chapter 17
Behind the Scenes

You have seen the AVERTZ application from the system manager's and user's points of view. This chapter takes a brief look at some of the work involved in designing and developing an ACMS application from the system designer's and application developer's views. The design and development details of AVERTZ are discussed extensively throughout the ACMS documentation set.

Before designing a transaction processing application, you must begin by analyzing the business problem. For AVERTZ, the business problem is how data entry personnel can quickly and efficiently create, access, and update car rental information.

Each business problem has separate business areas that must be addressed. For AVERTZ, business areas might include reservation processing, site management, car information, and customer accounts. The AVERTZ sample application focuses on the business area of reservation processing.

In turn, each business area consists of business functions that support the business area. There are three different business functions that support the reservation processing business area:

Once the business problem has been categorized into areas and then into functions, you can begin solving the business problem with ACMS.

17.1 Applications and Procedures

An ACMS application consists of a set of tasks that relate to the functions of a business and can be selected for processing by either a terminal user or another task. Figure 17-1 shows the basic structure of an ACMS application.

Figure 17-1 Structure of an ACMS Application


The AVERTZ application is made up of three menu choices: RESERVE, CHECKOUT, and CHECKIN. Each of these menu choices selects a corresponding task. The AVERTZ application also contains two tasks that are called by tasks not visible to the clerk:

The ability of tasks to call other tasks means that it is easy for you to design applications to share common code.

Just as each application is made up of one or more tasks, each task is made up of one or more steps that coordinate the work for that task. There are three types of steps within ACMS:

A considerable amount of control must take place to manage an application like AVERTZ. ACMS is designed to make such complex coordination and control easy to manage. Figure 17-2 illustrates how ACMS tasks coordinate the flow between forms that collect input from users and databases that store information.

Figure 17-2 Example of Execution Flow for an ACMS Task Definition


ACMS tasks are written using the ACMS Task Definition Language (TDL), which is based on a call and return model. Task definition steps perform calls to the presentation service in exchange steps, and to step procedures in processing steps. The presentation service and procedures perform their work and then return control to the task definition. Upon return to the task definition, subsequent parts of a step can evaluate the results of the call and, if necessary, handle any error conditions.

17.2 Task Definition Language

Example 17-1 shows portions of the code that are part of the reservation task in AVERTZ. Table 17-1 includes a description of each portion of code, based on the callout numbers in the example.

Example 17-1 Code from the Reservation Task Definition

REPLACE TASK avertz_cdd_task:vr_reserve_task                         (1)
 
USE WORKSPACES  vr_control_wksp,                                     (2)
                vr_customers_shadow_wksp, 
                vr_customers_wksp, 
                vr_rental_classes_wksp, 
   .
   .
   .
DEFAULT FORM IS vr_form;                                             (3)
   .
   .
   .
get_car_now:                                                         (4)
 
BLOCK WITH TRANSACTION                                               (5)
   .
   .
   .
    PROCESSING                                                       (6)
        CALL PROCEDURE  vr_store_cu_proc 
        IN      vr_cu_update_server 
        USING   vr_control_wksp, 
                vr_customers_wksp, 
                vr_trans_wksp; 
        
    ACTION IS                                                        (7)
        IF (ACMS$T_STATUS_TYPE = "B") THEN 
                GET MESSAGE INTO vr_control_wksp.messagepanel; 
                RAISE EXCEPTION vr_update_error; 
        END IF ; 
!+ 
! If want to check car out now (=GTCAR) then call 
! vr_complete_checkout_task to do that. 
!- 
    PROCESSING                                                       (8)
        CALL TASK       vr_complete_checkout_task 
        USING           vr_sendctrl_wksp, 
                        vr_control_wksp, 
                        vr_reservations_wksp, 
                        vr_trans_wksp, 
                        vr_vehicles_wksp; 
END BLOCK;                                                           (9)
 
    ACTION IS                                                        (10)
        MOVE "     " TO vr_control_wksp.ctrl_key, 
             "ACTWT" TO vr_sendctrl_wksp.sendctrl_key; 
        COMMIT TRANSACTION; 
        GOTO STEP disp_stat; 
!+ 
! If the vr_store_cu_proc has an error because of constraint violation 
! goto fix customer info exchange. If the transaction failed Retry the 
! distributed transaction 5 times before canceling task. The retry_count 
! is incremented in vr_store_cu_proc. 
!- 
    EXCEPTION HANDLER                                                (11)
        
        SELECT FIRST TRUE OF 
            ( ACMS$L_STATUS = vr_update_error ): 
                MOVE "TRAGN" TO vr_sendctrl_wksp.sendctrl_key; 
                GOTO STEP fix_cust_info; 
            ( (ACMS$L_STATUS = ACMS$_TRANSTIMEDOUT AND 
                vr_control_wksp.retry_count < 5) ): 
                REPEAT STEP; 
            NOMATCH: 
                GET MESSAGE INTO vr_control_wksp.messagepanel; 
                MOVE "ACTWT" TO  vr_sendctrl_wksp.sendctrl_key, 
                     "     " TO vr_control_wksp.ctrl_key; 
                GOTO STEP disp_stat; 
        END SELECT; 
   .
   .
   .
END DEFINITION; 

Table 17-1 Description of Code Excerpt
Callout Description
(1) The REPLACE command is the first command in a task definition. It replaces an old dictionary definition with the current task definition or creates a new definition if one does not already exist.
(2) The USE WORKSPACES clause names one or more workspaces to which the task needs access. Workspaces are buffers used to pass data between steps in a task, between a task and a procedure, between a task and a form, and between tasks. As you see in (6), some of the workspaces are used to pass information to a step procedure.
(3) The DEFAULT FORM clause names the DECforms form used by the exchange steps within the task.
(4) The get_car_now: label is used to identify the section of code that begins with the BLOCK clause. Labels allow for the transfer of control to different parts of the task.
(5) The BLOCK clause groups multiple steps as a logical unit. TRANSACTION is a block phrase that marks the start of a distributed transaction (a distributed transaction makes more than one database update as a single "all or nothing" transaction). This example of the BLOCK clause consists of multiple processing steps ( (6) (8) ). The processing steps include ACTION ( (7) (10) ), and EXCEPTION HANDLER ( (11) ) clauses, which are part of the processing steps.
(6) The PROCESSING clause identifies work that is part of a processing step. In this example, the PROCESSING clause calls the COBOL procedure named VR_STORE_CU_PROC, which resides in a server named VR_CU_UPDATE_SERVER. Procedures perform all computation and database work. (The VR_STORE_CU_PROC procedure stores a customer record in the database, for example). Note that the USING keyword identifies workspaces that are passed to the procedure as parameters.
(7) The ACTION clause defines actions you want ACMS to take at the end of an exchange step, processing step, or block step. In this example, the ACTION clause tests the return status from the procedure. If the procedure fails for some reason (STATUS_TYPE=B), the ACTION clause uses the RAISE EXCEPTION clause to send control to the exception handler ( (11) ).
(8) This PROCESSING clause calls another task, VR_COMPLETE_CHECKOUT_TASK, to check out the vehicle. Note that again workspaces are identified as parameters.
(9) This END BLOCK clause ends the entire block step, which consists of the two processing steps, the action parts, and the exception handler part.
(10) This ACTION clause performs some workspace work and then commits the transaction. The COMMIT clause signals the end of the current distributed transaction and makes permanent any changes made since the start of the distributed transaction.
(11) By default, if ACMS encounters an error that prevents it from executing a task, ACMS cancels the task. The EXCEPTION HANDLER clause lets you handle the error and continue task execution. In this example, if the exception was a transaction timeout, it retries the transaction five times before cancelling the task. If the exception was an update error, control goes to a step labelled fix_cust_info, which allows the user to correct the data.

17.3 More AVERTZ ...

The AVERTZ sample application demonstrates an ACMS transaction processing application from many perspectives. As you learn more about ACMS, you can modify the AVERTZ application to test what you have learned. Furthermore, you can use the design model for AVERTZ as a starting point for how to approach designing your own ACMS application.

For more detailed information on the design and coding aspects of AVERTZ, consult the following ACMS documentation:

All these documents make extensive use of AVERTZ code examples to illustrate ACMS concepts and features.


Previous Next Contents Index