To test process logic in dialog XXXDADD, you will:
To invoke the Department application from DC/UCF, you enter the task code (XXXDEPT) for the application. For example, when using CA IDMS/DC, you invoke the Department application as shown:
ENTER NEXT TASK CODE:
xxxdept
[Enter]
For more information on invoking the Department application, see Instructions For Executing the Application.
While testing dialog XXXDADD in this chapter, it is recommended that you write down the ID number of each sample department record that you add to the database. This will help you later in this manual, when you need to locate, modify, and delete your sample department records.
From DEPTMENU, you can display the ADDDEP function and try out dialog XXXDADD:
x ADD
[Enter]
Enter sample information.
Note: You must specify a unique ID number for each department. Try entering the last four digits of your home phone number.
Entering Sample Information
FUNCTION: ADDDEP DATE....: 10/30/99 DEPARTMENT INFORMATION DEPARTMENT ID .......: 9876 NAME .....: test department HEAD ID ..: 1234 RESPONSE:
Data is Redisplayed
The data is redisplayed after it is added.
FUNCTION: ADDDEP DATE....: 10/30/99 DEPARTMENT INFORMATION DEPARTMENT ID .......: 9876 NAME .....: TEST DEPARTMENT HEAD ID ..: 1234 RESPONSE: DEPARTMENT ADDED
Notice the message you defined in response process XXXDADD-RESPONSE. It confirms that the redisplayed data has been added to the database.
When you press [Enter] to add a new department, response process XXXDADD-RESPONSE is executed. Statements in this response process test your input data and, for a new department, add the data to the sample database. The following diagram shows how components of dialog XXXDADD are executed at runtime when you use the dialog to add a department to the database. Dialog XXXDADD allows you to add new departments to the database. Execution remains in the dialog until the user requests another function (for example, MOD).
In dialog XXXDADD, you add a new department to the database by pressing [Enter]. To verify that your process logic keeps you from adding duplicate departments, try pressing [Enter] again to add the redisplayed department information.
After you press [Enter], the screen redisplays the department values along with an error message:
TRY AGAIN, OR SELECT: MOD, BACK, OR EXIT
You defined this error message in process module XXXDADD-RESPONSE. The message is displayed whenever the specified department record already exists in the database. In this case, the duplicate record is not added to the database.
Try seeing what happens if you enter a new department record and also specify a valid response:
Continuing to test the XXXDADD dialog
FUNCTION: ADDDEP DATE....: 10/30/99 DEPARTMENT INFORMATION DEPARTMENT ID .......: 5432 NAME .....: sample department HEAD ID ..: 1111 RESPONSE: mod TRY AGAIN, OR SELECT: MOD, BACK, OR EXIT
Notice the message displayed when you added TEST DEPARTMENT above does not affect your current add operation.
After you press [Enter], dialog XXXDADD's screen is redisplayed with the following message:
DEPARTMENT ADDED
Mode of Execution
Even when you specify a valid response, control remains in dialog XXXDADD when you add a new department. This type of execution is called STEP mode execution. In STEP mode, the screen is always redisplayed with a confirming message after a successful add, modify, or delete operation.
Dialog XXXDADD executes in STEP mode because of the following conditional command that you coded at the beginning of response process XXXDADD-RESPONSE:
IF AGR-CURRENT-RESPONSE NE SPACES ◄-- If the user specifies
a valid response
AND DEPT-ID-0415 NOT CHANGED ◄-- and doesn't enter a new
department ID,
THEN
EXECUTE NEXT FUNCTION. ◄-- control transfers to the
next function.
Dialogs do not have to execute in STEP mode. As an application developer, you can make use of the following execution strategies when developing an application:
This strategy benefits experienced users, who can input data and advance directly to the next function without any extra keystrokes.
This strategy ensures that users do not inadvertently alter the database when transferring to another function. To make a function immediately executable, you use the ADSA Response Definition screen.
For more information on immediately executable functions, see the CA ADS Reference Guide.
Another Test
Now, test whether your process logic allows users to transfer control to other functions. According to your application design, for example, you can transfer to function MODDEP in either of the following ways:
When you request transfer to MODDEP:
If you haven't already, transfer to MODDEP:
RESPONSE: mod
[Enter]
Since you didn't enter a department record along with the response name, control transferred to the indicated function. This processing was handled by the following conditional command at the beginning of process module XXXDADD-RESPONSE:
IF AGR-CURRENT-RESPONSE NE SPACES ◄-- You entered a valid response
AND DEPT-ID-0415 NOT CHANGED ◄-- and didn't enter a new department;
THEN
EXECUTE NEXT FUNCTION. ◄-- therefore, control transferred.
How Components are Executed
The following diagram shows how components for dialog XXXDADD are executed at runtime when you request transfer to another application function. Dialog XXXDADD has a response process associated with [Enter]. No response process is associated with [PF5], the control key defined for the MOD response.
It is unnecessary to test function MODDEP at this time since you have not yet defined any process logic for the associated dialog. You can exit from the Department application by specifying the EXIT response in the RESPONSE field:
RESPONSE: exit
[Enter]
|
Copyright © 2013 CA.
All rights reserved.
|
|