System 1032
A Case Study of Date Manipulation
By Tym Stegner
Ray Hochstatter, System Manager at Phoenix Union High School District in Arizona (USA), was directed to produce a depreciation report on capitalized assets. The report had to describe the depreciation costs of all qualified assets for a specified range of time.
Phoenix Union High School District assets include buildings, sports equipment, books, computers, furniture and so on. Although the data for the school assets is stored and accessed via System 1032, the systems group was evaluating a $20,000.00, specialized package to process the data and create the depreciation report.
As the systems group did their research, Ray did some research on his own. Although new to PL1032, he firmly believed that System 1032 could create the required report, if only he could figure out how to write the program. Here Ray was a bit stymied by the problem of how to select the appropriate records and how to make the appropriate calculations.
Meet the data
The Phoenix Union High School District capital equipment dataset, ASSETS, includes the following data elements:
Ray knew the makings of the report lay in those attributes. After trying several approaches, Ray decided to modify the dataset to contain a 360-element array, where each element was a date representing a depreciation month, as determined by the ACQDATE value. The following command would be used to find the qualifying records:
FIND array-value BETWEEN date1 AND date2
These array dates would be used solely to access records for the depreciation report.
Although this method seemed as though it would locate the records for the report, Ray was not happy about adding the 360-element array to the dataset. Before actually altering the dataset, he contacted System 1032 Customer Support to see if we had an alternate approach.
Getting an education in accounting
I took the call and Ray gave me a mini accounting course to help me understand the purpose of the report, so we could determine how it might be accomplished.
Basically, the report was to be a Straight-Line Depreciation (SLD) report, which is the cost of an asset depreciated (written off through wear and tear) over a set period of years, usually 30, at so much per month. Each asset (ITMNAME) has a purchase price (ITMCOST) and a purchase date (ACQDATE).
I was also unhappy about adding a 360-item array to the ASSETS dataset; this seemed a burdensome amount of extraneous data for the dataset. Furthermore, like Ray, I knew System 1032 did not have a depreciation function or a tool procedure to calculate depreciation.
However, also like Ray, I thought it possible to create the report directly in System 1032, without resorting to another application. Ray was heartened by this affirmation, and I began to brainstorm the required commands. My initial thought was to compare the acquisition date (ACQDATE), plus the lifetime depreciation, against the requested date range.
"I didn't know you could do that!"
As I explained my approach to Ray, he noted the implied date arithmetic in the selecting command. This led to a discussion of the System 1032 date arithmetic facility, which was news to Ray. To demonstrate the System 1032 date arithmetic feature, I used the classic Age Report, which gives a person's current age in fractional years. The following code illustrates the calculation involved:
1032> PRINT ( $NOW - 'birthdate' ) / 1 YEAR;
To display the current age in another time format, replace the YEAR keyword with any of the other System 1032 date constant specifiers, such as MONTH, DAY, HOUR, MINUTE, SECOND. Weeks can be determined by '7 DAYS', Lunar months by '30 DAYS', and fortnights by '14 DAYS'. In addition, in almost any instance where a date is used, a date expression can replace it, including within a selection command. The System 1032 date manipulation capability confirmed for Ray the possibility of creating an in-house report.
Qualifying records
As I explored the selection problem, I found that determining the qualifying records was more complex than I first thought. Working with the ASSETS dataset, which includes attributes:
ACQDATE date ! Date item purchased DEPLIFE integer ! Depreciation lifetime in years ITMCOST decimal ! Original cost of item ITMNAME text 50 ! Item's name
and three variables:
RPTBEG date ! Start of report period RPTEND date ! End of report period DPMTHS decimal ! Number of months within report range
I had to locate ASSETS records for which an asset (ITMNAME) had any depreciation cost within the date range, specified by the RPTBEG and RPTEND variables. A valid depreciation period could begin outside the reporting range or within the range; it could end outside or within the range.
In Figure A, the arrows represent assets and their relationships to a date range. The report should contain only those records that have a portion of their history within the dark gray area, Report Range.
Figure A. Depreciation scenarios for a range of dates
The scenarios, numbered in Figure A, are described by the following statements:
Examining the qualifying records
Since the records in scenarios 2 and 3 fall outside the reporting range of dates, we can exclude them from the selection set of qualifying records. We will examine only scenarios 1, 4, 5, and 6, which have depreciation history within the report dates. When the scenarios with qualifying records are rewritten in PL1032 code, they are represented, as follows:
Even if the ACQDATE attribute is keyed, the FIND command cannot utilize an attribute expression on the left side of the operator. The SEARCH command must be used, and as all search criteria must be applied at once to get all the qualifying records, individual query expressions are joined using the OR operator.
Calculating the depreciation cost
The first step to calculate the depreciation cost for each asset is to divide the original cost by the total number of depreciation months. The second step is to count how many months the asset had history in the report range of dates.
Doing the easy scenario first
Starting with the records from scenario 1, where the depreciation months match the reporting months, the following LET command counts the number of depreciation months.
LET DPMTHS = (RPTEND - RPTBEG)/ 1 month
The DPMTHS value is calculated only once for qualified records from scenario 1, as this value is the same for each of these records.
The following PRINT command displays how the depreciation costs might be calculated.
(ITMCOST/DEPLIFE*12) represents the amount of depreciation per month for the item in the current record, which is the cost of the item divided by the number of the months of the asset's lifetime.
The DPMTHS calculation multiplies the per month depreciation cost for the asset by the number of months in the reporting period.
In scenarios 4, 5, and 6, where the asset depreciation concludes or begins during the reporting period, the value of DPMTHS must be calculated for each record to determine how many months of the reporting period were included.
Passing the baton
The next day I sent this to Ray, who understood the approach I described, and coded his procedures to accommodate the other depreciation date ranges and calculation requirements.
Ray later reported the following: "After showing the preliminary report to the district controller this morning, we were told to continue our development, and we won't be purchasing new software to report depreciation."
Thus, the department saved $20K by using only existing software tools and a couple of day's work.
The CCA editorial staff would like to thank Ray Hochstatter and the Phoenix Union High School District for encouraging us to share their experience with the System 1032 user community. --The editor
Model 204 Multiuser Simulations Using IODEV=3 Threads
By James Damon
In the October 2001 CCAprint, I discussed using IODEV=3 threads to perform automated system monitoring. An even more significant application of this feature involves the testing and debugging of both APSY and non-APSY, full screen and non-full screen applications. When you employ multiple threads, you can simulate a multiuser environment and use it, not only for testing, but also to determine the performance characteristics of existing applications or those under development.
Setting up virtual users for testing
You might find setting up virtual users to do your testing a bit monotonous, but it is not difficult. Furthermore the Basic Sequential Access Method (BSAM) datasets you create can be reused to test your application in many different environments. You can increase or decrease the number of users, servers, disk buffers, and make changes to other CCAIN parameters to determine the effect each has on performance. You can also make changes to the application and observe how those changes affect performance.
Very often, the kinds of applications you want to test are full-screen APSY or non-APSY, using the READ SCREEN statement. Driving full screen applications from BSAM input is surprisingly easy to setup and run and requires no special add-on features. This facility is built into the Model 204 nucleus at all customer sites under all operating systems.
The most time consuming aspect of setting up a test environment is constructing typical user input, which is used to drive the application under test. The input a user might provide to a full screen display, as illustrated in Figure 1, must be supplied from a sequential dataset.
Figure 1. Example of the screen to test
IODEV=3 SCREEN TEST
CITY:
STATE:
Figure 1 illustrates the application screen that will be tested. Figure 2 illustrates the procedure that will be called to populate the screen.
Figure 2. Procedure code
The following JCL and IODEV=3 definitions would simulate three users simultaneously running the transaction in Figure 2:
Figure 3. Three virtual users to test the application
//IOD3OU1 DD DUMMY
//IOD3IN1 DD *
//IOD3OU2 DD DUMMY
//IOD3IN2 DD *
//IOD3OU3 DD DUMMY
//IOD3IN3 DD *
//CCAIN DD * parameters IODEV=3,INPUT=IOD3IN1,OUTPUT=IOD3OU1 IODEV=3,INPUT=IOD3IN2,OUTPUT=IOD3OU2 IODEV=3,INPUT=IOD3IN3,OUTPUT=IOD3OU3
Analyzing the JCL
During initialization, the IODEV=3 definitions are read, the associated input and output datasets are opened and the first record of the input dataset is read and processed. Output datasets must be provided, but generally they do not contain useful information, and are shown here as DUMMY datasets. However, DUMMY may be replaced by SYSOUT=* or by DSN=.
In Figure 3, A PAUSE 60 just after login allows initialization to complete before processing the thread begins in earnest. Following the INCLUDE IODEV3.T1, the application (Figure 2) is invoked and the READ SCREEN statement is evaluated. Each of the input fields, LNAME, CITY, STATE, and ZIP, defined in screen I3 is satisfied by the next record in the input dataset defined for the thread. When all screen input fields have been provided, the application resumes processing following the READ SCREEN statement. When end-of-file is reached on the input dataset, the thread is closed and the following messages are issued:
*** M204.1250: END OF INPUT DATA *** M204.1022: USER RESTARTING
The BSAM test environment
The BSAM test environment is an inexpensive way to test your code, look for record and resource locking conflicts, and evaluate the effect changes in various parameters have on performance. However, IODEV=3 threads do not simulate a VTAM network.
Generally, when performance testing is the objective, the user scripts provided by the input datasets contain correct and sanitized data, which passes all error detection algorithms. You can add completeness to your testing by constructing user scripts that do contain erroneous data to exercise your error detection code. However, this usually involves using the REREAD SCREEN statement; providing input data required by the statement adds considerable complexity to the test.
Transactions and threads
If you assume that each evaluation of a READ SCREEN statement represents one transaction, you can extrapolate from this example and see that constructing an environment simulating 100 users each running 100 transactions through a single application or through an APSY subsystem is a relatively easy simulation to perform.
In Summary
The data acquired from these kinds of multiuser simulations, in the form of evaluation and system final statistics, can be invaluable in predicting the effect a new application or new subsystem will have on overall system performance and on the allocation of system resources. These simulations also provide insight into the kind of multiuser effects, such as record locking, resource locking, database I/O, and server I/O, that are likely to occur in a production environment.
Copyright © 2003 Computer Corporation of America. All right reserved. Published in the United States of America.
500 Old Connecticut Path, Framingham, MA 01701 Contact CCA Webmaster Copyright 2005
