Time Trials Determining workstation response time and more on Lotus date formats
From "VS Workshop",  Access to Wang, June 1989
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

System performance measurement is a gray area. The range of "acceptable" performance is always up for speculation, and the measurement tools are often inadequate. Without good measurement tools, subjective observations must replace objective measurement to determine the effects of system tuning efforts; this makes it difficult to evaluate the true effect of these changes.

Nowhere is this more visible than in the measurement of workstation response time. If you are in a systems support position, undoubtedly you've been approached at some time with complaints about system performance. Often these complaints are based on the time required to perform an update to the workstation screen - an area that cannot be measured meaningfully using Wang's System Activity Monitor (SAM) or other tools. Ironically, this response time is one of the most visible aspects of performance from the user's view.

Measuring workstation response

How can you measure relative response time on a workstation? A response test would probably consist of the following two activities:

1. Standard load: the workstation would be subjected to a repeatable task that would provide a uniform load to the system.

2. Logging: the time to complete this task would be timed and recorded. Test times would be compared to expected times for that workstation (i.e. the baseline).

One method of accomplishing this measurement is to sit by the workstation with a stopwatch and record times between screen updates. This is both tedious and potentially inaccurate, since the short duration between screens on most applications may make it impossible to manually time them.

When setting up data communications lines, I have used the CLOCK program (available from ISWU) to test the response speed. After setting up the line and logging onto the VS, I run CLOCK and note the number of seconds between screen updates. For example, a typical response on a 2400-baud asynchronous dial-up connection (using 2110 emulation) is three seconds; that is, the seconds display from CLOCK will be updated every three seconds. Similarly, a 1200-baud line will often skip six seconds. While not very scientific, I have found this measurement helpful in diagnosing response issues.

CLOCK is not as helpful for measuring local workstation response because the system is usually able to refresh the screen every second. There is also no provision to record workstation response over time to see the effects of the daily processing loads.

Measuring workstation response with WSSPEED

With no other visible means of performing this measurement, I turned instead to creating one. Procedure WSSPEED (see listing, Figure 1) was designed to be run whenever desired to illustrate the approximate workstation response time. It works by performing a standard task repeatedly on the workstation screen and checking the elapsed time to do it. The difference between the start and stop times is computed (in seconds) and displayed on the screen, along with a average value for all workstation tests during the session (see Figure 2). Finally, the workstation screen is captured in a print file to record the times.

Step by step, the process is as follows:

1. After declaring variables, the DATE subroutine (a VSSUB) is called to get a formatted date and time.

2. The PROMPT statement is used to stop the procedure and wait to begin. A ROW statement is included to locate the first line of the screen message on row six. If the (RETURN) key is pressed, the beginning time is extracted from the system and stored; if PF(16) is pressed, the procedure ends.

3. After capturing the beginning time in variable &BEG, an internal subroutine (SCRN:) is performed five times; this functions as the standard workstation task. SCRN places characters from HEX(21) (the exclamation point) to HEX(7E) (the tilde) on the screen, using the &BYTE built-in function of Procedure language and specifying a range from 33 to 126 (the decimal equivalents of the characters).

4. When the task is complete, the ending time is captured in &END and the difference computed. The average for all runs is computed by dividing the number of runs (&N) into the sum of all times (&SUMX).

5. The run times for the last run and the average for all runs to date are incorporated into messages and displayed on the screen. The SCREEN subroutine (another VSSUB) is called to print a copy of this screen for reference, and the procedure returns to the PROMPT screen at START to start the test again or exit.

WSSPEED makes use of several advanced features of Procedure language. Workstation features include the use of the PROCMSG option and the ROW and ERASE options within the PROMPT and MESSAGE verbs. PROCMSG is normally used to suppress the usual screen messages (e.g. "Procedure WSSPEED in progress"); it is required here so that the SCREEN subroutine will function properly. (For additional information see the "The NEWMENU Procedure" in the October 1986 ACCESS 86). Both the PROMPT and MESSAGE statements include ERASE = NO and ROW statements to update selected portions of the screen at a time; be sure to type in the PROMPT and MESSAGE statements carefully, as the screen lines overlay others.

Advanced math features of interest include simple subtraction and multiplication and the use of string information for numeric purposes. One the little-used strengths of Procedure language is its ability to automatically convert string values to numeric. An example of this is the statement computing the elapsed time (&X) where substring values of &BEG and &END are used to convert the hours, minutes, and seconds format to seconds, then subtract these values for the elapsed time.

Some variations on WSSPEED I have tried include one that loops continuously, using the PAUSE subroutine to wait a fixed interval between tests. In another version I added a call to a program that would log the response information in a file for later reporting and analysis. Many other possible approaches are also possible.

More on Lotus Import files

If you are working in a programming language and wish to create consecutive files for the Lotus 1-2-3 Import function (see last month's column), you can pass dates from your VS files to Lotus as string information (characters), but they cannot be used for computations within the spreadsheet without first converting them to Lotus internal date format. (Simply stated, Lotus dates are integers that represent the number of days from December 31, 1899 through the target date.)

One method around this is to convert the formatted dates on the VS to Lotus date format and passing the information to the PC as an integer. This value can be calculated using the DATE subroutine (another VSSUB) for the difference in days. A demonstration procedure to test this approach is shown in Figure 3. This should be easy to translate to any application language.

Note that there are two small annoyances, though: the earliest starting date accepted by DATE is January 1, 1900, and there is no provision to indicate century. Also, be careful to use four-byte integer values if you are working in COBOL, since the number of days can easily exceed the two-byte maximum of 32,768, causing errors.

Once the value is calculated, use this as numeric information instead of the character date field. After importing the file, change the display options of the column to "date" and normal, formatted dates will appear on the spreadsheet.

Items mentioned:

• CLOCK is distributed by the ISWU Software Library as a part of their GAMES package. ISWU Software Library, Wang Laboratories, Inc., One Industrial Drive, M/S 019-350, Lowell, MA 01851.

• DATE and SCREEN are VSSUBS - subroutines supplied with the operating system and supported by Wang Laboratories. Earlier versions are also available as USERSUBS from the International Association of Wang Users (see address above). Documentation is available in the VSSUBS Reference (#715-0599), which is supplied with operating system 7.20.

Figure 1: Procedure WSSPEED

PROCEDURE WSSPEED - workstation speed test OPTIONS PROCMSG = NO DECLARE &DISP STRING (94) DECLARE &DATETIME STRING (45) DECLARE &KEY INTEGER DECLARE &MESS1, &MESS2 STRING (70) DECLARE &BEG, &END STRING (06) DECLARE &S, &I, &X, &C INTEGER DECLARE &AVG, &N, &SUMX INTEGER START: RUN DATE IN USERSUBS [ on volume ] USING "HL", &DATETIME PROMPT PFKEY = &KEY, ERASE = NO ROW 06 CENTER BRIGHT LINE "Workstation Speed Test";; CENTER "Press (RETURN) to run test"; CENTER "Press PF(16) to exit";;;; CENTER &DATETIME (1,*); IF &KEY = 16 RETURN ASSIGN &BEG = &TIME ASSIGN &I = 0 LOOP: ASSIGN &C = 33 ASSIGN &DISP = " " CALL SCRN ASSIGN &I = &I + 1 IF &I < 6 GOTO LOOP [ loop 5 times ] ASSIGN &END = &TIME ASSIGN &X = ((&END(1,2)*3600)+(&END(3,2)*60)+&END(5,2)) - ((&BEG(1,2)*3600)+(&BEG(3,2)*60)+&BEG(5,2)) IF &X < 0 ASSIGN &X = &X + 86400 ASSIGN &N = &N + 1 ASSIGN &SUMX = &SUMX + &X ASSIGN &AVG = &SUMX / &N ASSIGN &MESS1 = "Previous test concluded in " !! &X !! " seconds" ASSIGN &MESS2 = "Average of " !! &N !! " tests = " !! &AVG !! " seconds" MESSAGE ERASE = NO ROW 15 CENTER BRIGHT &MESS1 (1,*); CENTER BRIGHT &MESS2 (1,*); RUN SCREEN IN USERSUBS [ in volume ] USING "C", &S, "P", "##TIME" GOTO START SCRN: ASSIGN &DISP ((&C-32),1) = &BYTE (&C) MESSAGE ERASE = NO ROW 08 CENTER &DISP (01,31), " "; CENTER &DISP (32,32) ; CENTER &DISP (64,31), " ";; ASSIGN &C = &C + 1 IF &C < 127 GOTO SCRN END

Figure 2: Sample Workstation Display

******************************************************** Workstation Speed Test Press (RETURN) to run test Press PF(16) to exit Tuesday June 20, 1989 12:43 PM Previous test concluded in 71 seconds Average of 5 tests = 85 seconds ********************************************************

Figure 3: Example Lotus Date Format Calculation

PROCEDURE LOTUSDAT DECLARE &TODAY STRING (06) INITIAL &DATE DECLARE &START STRING (06) INITIAL "000101" DECLARE &OFFST INTEGER INITIAL +2 DECLARE &DAYS, &RC &KEY INTEGER ASSIGN &TODAY = &TODAY (5,2) !! &TODAY (1,4) S01: PROMPT PFKEY = &KEY CENTER "&TODAY =", NUMERIC &TODAY, " (format YYMMDD)";; CENTER BRIGHT "Press PF(16) to exit";; IF &KEY = 16 GOTO S99 RUN DATE IN USERSUBS [ on volume ] USING "G-", &START, &TODAY, &DAYS, &RC ASSIGN &DAYS = &DAYS + &OFFST PROMPT PFKEY = &KEY CENTER "&START = ", &START;; CENTER "&TODAY = ", &TODAY;; CENTER "&DAYS = ", &DAYS ;; CENTER BRIGHT "Press PF(16) to exit";; IF &KEY <> 16 GOTO S01 S99: RETURN