by Kim Collins
Many Model 204 users are well on their way toward Year 2000 compliance, at least with their Model 204 applications, if not the rest of their inventory. The message from those who have made good progress is fairly consistent. If you have a good understanding of your applications and your data, then the coding task is straightforward. The most important and time-consuming task is testing for functionality and performance.
There is an excellent Model 204 tool, used successfully by many developers, which is ideally suited for Year 2000 compliance projects. This tool, SoftSpy, is developed and supported by Information Technology Systems and distributed by CCA.
SoftSpy is a comprehensive suite of products, which provides the information you require to quickly debug applications, learn how they operate, perform thorough quality assurance testing, identify and eliminate performance bottlenecks, and learn the general underlying principles behind good performance.
SoftSpy consists of three distinct components that all share a common environment. All the options also share many capabilities, making familiarity with the product easy to attain. The three components are:
So, how can SoftSpy assist in Y2K conversion?
You can debug programs more productively when you have immediate access to the information you need to diagnose problems. Because SoftSpy has an interactive debugger, you do not have to submit BATCH work and wait for results; this component allows you to view the results as they happen.
This component allows you to clearly see which programs are executed at any point in the application cycle, as well as reviewing, within any program, each executable statement. Once you understand the application, you can then start making those necessary changes.
Interactive debugging also allows you to follow one or more %variables, fields, globals, or Screen/Image/Menu items in special windows. So, at any time during the execution, you can obtain a "snapshot" to ensure that the data you want to be held actually is. A timely usage of this feature might be to reassign a specific date %variable to a noncompliant format and then to review how your application handles it - does the correct error handling or reporting procedure get called?
While tuning your applications is often considered "taboo" during Year 2000 conversion, there are valid reasons why you might be interested in the performance of a particular program. If your proposed solution to a problem is to make some User Language (UL) changes to the program logic or flow, you might want to verify that this solution is not any less efficient than the prior solution. Finding out now if you are going to experience performance issues allows you the option to rethink that solution.
The performance tuning component of SoftSpy allows you to select various performance characteristics, which are displayed for each line of executable code run.
No matter how carefully a testing plan is designed, almost all have gaps in their coverage. This is not the time to have some UL code get through untested. Used correctly, this component gives you excellent testing coverage. And, because you can print the output, you have proof of a comprehensive and successful test to show your auditor.
This component identifies any lines of code that cannot be reached (that is, "dead" code). Given this information, you can determine whether you have encountered an error in the program logic, in which case you can rework the logic, or whether the code is, in fact, "dead" and you can delete it.
This component also identifies how much of the program code was tested during an execution, including how many times each line was executed, as well as identifying how much code was not tested. Given these statistics, your testing plan can be re-addressed.
The final result is a comprehensive test of your Model 204 environment in a shorter period of time.
A trial copy of SoftSpy is included in your Model 204 V4R1 installation kit. For more information, contact your CCA sales representative or see:
www.softspy.com
By Terry Eagan
Editor's Note: For those of us in North America and Europe, it will soon be time to turn back the clocks again. Occasionally, one or two customers encounter difficulties when turning back the clock, and then restarting their system too soon. So, we have decided to reprint the article from last October's CCAPRINT with modifications for Model 204 V4R1.
Whenever you reset your system clock to an earlier time (for example, sites in several time zones turn back the clock by 1 hour this month), you must not allow updating activity to Model 204 or System 1032 files until the new time is later than the time-stamp of the last file update prior to resetting the system clock. (Note that a time-stamp applies to System 1032 only if a journal file is active for a given dataset being updated. However, the concept also applies to system-updated attributes such as date/time of entry.)
Enforcing a time lag prevents problems with recovery, if a hardware/software system crash occurs during the window of "overlap" time. For example:
Because Model 204 copies a pre-image of any page about to be updated since the last checkpoint time, any pages that were updated after 1:05 in the original Online are assumed to be already logged to the checkpoint dataset. (If rollback is required, it is probably incomplete.)
In the System 1032 case, the example posts later sequential checkpoints using the now earlier time- stamp. This creates an ambiguous situation during a rollback attempt.
During restart/recovery processing, journal and checkpoint logic assumes EOF, if an earlier time- stamp is encountered, thus causing incomplete rollback (and subsequent roll-forward).
To ensure data integrity, take the following steps when turning back the system clock:
For Model 204 V4R1, if you set the system clock back and then try to open a file before the system clock is at least equal to the time of the last update, the file cannot be opened because of the future time- stamp, and you receive a message similar to the following:
M204.2473: FILE SRC340 HAS A FUTURE DATE AND CANNOT BE OPENED UNTIL 10/26/97 01:54:17
M204.0630: FILE OPEN COMMAND REJECTED
Note: Do not allow updating with Model 204 BATCH204 jobs during the overlap time.
by Tym Stegner
Question: In the System 1032 world, when there is a possibility that a dataset's stored data has become inconsistent, System 1032 flags the dataset as "damaged." You might initially get one or more of the following messages: DO YOU WISH TO CONTINUE?[Y,N]...
When you open the dataset, you get this message: %1032-W-DAM, possible damage detected in dataset... Or, your dataset won't open in BATCH, and you get the message:
%1032-E-DAM, possible damage detected in dataset... What do these messages mean and what can you do about them?
Answer: When you receive one or more of the previous messages, the following types of problems are possible:
The most common type of dataset damage is a key table inconsistency. This damage might occur when the values stored in the key tables and the values in the data records get out of synch. Question: How could your dataset have gotten damaged? Answer: The most common cause of dataset damage is an interrupted update. System 1032 generally notices that an update does not complete correctly, and marks the dataset as possibly damaged.
The major causes of dataset damage include:
Question: How can you tell if your dataset is damaged? How can you tell who damaged a dataset? Answer: When System 1032 detects that possible damage has occurred, it notifies the user. This can happen at OPEN time with the "W-DAM" message, or be signaled during an update, resulting in the "Do you wish to continue..." message.
The damage message is a Warning level message, unless the system variable $DAMAGE_ERROR is set TRUE. So, you might not see the messages, if warning messages have been suppressed in your application.
To check a dataset for damage, you can open the dataset for read-only access; this minimizes the structures that must be accessed, and prevents any further damage from occurring.
Once the dataset is open, issue a SHOW DAMAGE command. This command displays the recent history of damage caused by interrupted updates. Remember, an interrupted update means only that there is possible damage.
The damage history shows who, when, and how the damage report occurred. You can cross-check the user and date information in the System 1032 Error Log. You can locate this file of severe System 1032 errors using the logical name S1032_ERR.
SHOW DAMAGE records only those instances where System 1032 detects possible dataset damage. To perform your own check, it helps if you are familiar with the data stored in the dataset.
Issue a VALUES command on several of the keyed attributes of the dataset. The VALUES command scans the low-level key tables, so that, if there is inconsistency in the key structure, this command is likely to detect it. If the output looks questionable (spurious characters), or if the distribution of attribute values is incorrect, this attribute is probably damaged. Question: How can you suppress the damage messages? Answer: Updating a damaged dataset is dangerous. In extreme cases, a dataset can get so damaged that either data is lost, or the dataset no longer opens. Contact Customer Support for possible options to recover data from a dataset damaged in this manner.
With this restriction in mind, you can suppress the damage notification messages. Open the dataset for read-write access, and issue the IGNORE DAMAGE command. This command resets the "possible damage" flag in the dataset, and makes an entry in the damage history. Note, however, that while the IGNORE DAMAGE command resets the flag, it does not fix any damage that might have occurred. Answering Yes to the "Do you wish to continue..." message has a similar effect for that particular user.
If the $DAMAGE_ERROR system variable is set to TRUE, possible damage to a dataset is treated as an error condition, and the dataset cannot be subsequently opened. In addition, regardless of the setting of $DAMAGE_ERROR, a damaged dataset cannot be opened in BATCH. Question: What can you do to fix the damage? Answer: The recommended and surest method for fixing dataset damage is to recreate the dataset in question. This refreshes all dataset structures and also results in compressing the key tables.
A reload operation minimally involves recreating the dataset structure, then transferring the data from the damaged dataset into the fresh dataset. You can do this in one of the following ways:
Another method to fix dataset damage is not as dependable, but might be useful to try if a dataset is very large. In this method, you just re-key one or more attributes. You have to determine from your program log or by inspection which attributes are likely to be damaged. Question: How can you avoid damaging your dataset again? Answer: You can avoid most dataset damage by following these guidelines:
Other resources: See the System 1032 User's Guide, Module 3, Section 4: "Maintaining S1032 Data" for more information on detecting and curing dataset damage.
The Board of Directors of the Washington D.C. Model 204 User Group is proud to announce the date and location for the 1997 conference, "M204: A Strong Foundation for the Future."
The conference will be held at the 4-H Conference Center in Bethesda, MD on Thursday, December 4, 1997, from 8:30 to 4:00. The cost is $85, which includes a continental breakfast, lunch, and breaks. Three concurrent tracks of presentations (at least 10 in all) will provide many choices for participants.
The Washington Model 204 User Group is calling for speakers for the December conference. If you have a topic you would like to present, send email to carehart@erols.com. All topics are welcome, but technical ones with broad appeal and real-world application are most appreciated, as well as those that focus on strategies for leveraging Model 204 into the future. This includes Year 2000 discussions, as well as Web integration, application revitalization, and other recent advancements.
Vendors interested in participation with a table, presentation room, or general session should send email as soon as possible to carehart@erols.com.
Look for the Washington User Group Web site:
http://www.wugm204.com
500 Old Connecticut Path, Framingham, MA 01701 webmaster@cca-int.com Copyright 2005
