Enterprise Storage Management Solutions

SIMULATE 2000 Technical Overview

  • Introduction
  • Key Features
  • Key Points

The Year 2000 problem highlights the difficulty of testing whether mainframe applications will function correctly at some future date.

SIMULATE 2000 was developed to facilitate such testing, by enabling programmers to specify a simulated date and time to be returned when their programs access the system clock. Creating a separate LPAR or IPLing a test machine is just not practical given the volume of such tests involving different programmers, applications and dates.

The effectiveness of a date simulation product depends on its ability to detect all the methods that programs use to access the clock: in all your batch, online and DBMS environments; in all the ways you choose to test; and with low overhead.

While the concept is simple, the development of such a product is difficult. Our more than 20 years experience in developing system software, and the vast systems programming experience of our developers, have enabled us to overcome the many complexities of MVS and deliver a product that provides flexibility and ease-of-use, while minimizing risk and maximizing coverage of system clock accesses.

Flexibility and Ease-Of-Use

  • Date/time can be set for Region, Terminal, User and Transaction in CICS and IMS/DC
  • Fixed date/time or "Running Clock" for Job, Step or Transaction
  • Access through TSO/ISPF, CICS, JCL, TSO commands, Rules Language
  • Multiple date formats, absolute or relative time

Maximum Coverage

  • SVC 11 support including LINKAGE=SYSTEM
  • Full support for EIBDATE in CICS
  • STCK (Store Clock) support for DB2, Natural, CA-IDMS, LE 370 and others
  • "DynaMod" Option dynamically zaps all STCK usage, CVTDATE in MVS and IO-PCB-DATE in IMS/DC
  • JobNet simulates a running clock for a series of jobs with a single entry

Performance, Security and Control

  • Extremely low overhead
  • Auditing, logging and messaging in all environments
  • Comprehensive Rules Language to enforce usage standards
  • RACF protection to determine date simulation authority

Key Points

Communicating the desired date/time

To provide the user with greater flexibility and ease-of-use, SIMULATE 2000 provides many ways for the user to specify the simulated date and time. For batch jobs, the desired date and time are usually communicated through JCL. For security reasons, some sites prohibit this method and instead maintain a protected table of jobs, programs, user IDs, transaction IDs, terminal IDs, etc., with the desired date/time. SIMULATE 2000 provides online facilities under TSO/ISPF, CICS and IMS/DC to maintain this table. SIMULATE 2000 provides a further capability (see Security and Control), which offers greater security and more flexibility than any table with pre-defined columns.

For maximum ease-of-use, SIMULATE 2000 supports both YYYY.DDD and YY/MM/DD date formats (and variations). Time is specified as HHMM. Users may also specify an offset to the real time, which is useful for simulating different time zones on one machine. In batch jobs, the date/time can be specified for either the job or for individual steps, and can be specified as fixed or as a "running clock" where the date/time returned on successive calls to the clock will be updated relative to the start of the job or step.

In batch, as different clients have different operating standards, SIMULATE 2000 provides a choice of using its own //PTL DD card; passing the date/time through the accounting parameters in normal JCL; or using extended JCL. Online, we supply transactions to set the date/time for individual user IDs, terminal IDs, transaction IDs or for individual workspaces in which CICS, IMS/DC or DB2 are operating.

Return to Key Points

Ensuring maximum coverage-SVC 11

SIMULATE 2000 captures all SVC 11 direct accesses to the system clock. Most programs get the date and time directly from the system clock in one of two ways: SVC 11 or the STCK (Store Clock) instruction.

The most common way is via a supervisor call (SVC 11). ACCEPT ..... FROM DATE in COBOL, for example, generates an SVC 11. Supervisor calls can be intercepted, and that's exactly what SIMULATE 2000 does. If, after matching the information about the calling program (job, transaction ID, user ID etc.), SIMULATE 2000 determines that a simulated date/time is required, it returns the date supplied and either a fixed or running clock. Otherwise, it returns the actual date/time retrieved from the system clock.

SIMULATE 2000 has the flexibility to handle a variety of special situations. For example:

  1. Almost all systems products issue SVC 11's with a PSW in Supervisor State and KEY from 0-7, while almost all application programs use a PSW in Problem State and KEY from 8-15. By default, SIMULATE 2000 allows the latter to accept a simulated date/time while excluding the former. A handful of products do not follow the implied standard (CLIST is one example). SIMULATE 2000 has special processing rules to handle these exceptions.
  2. Problems can also occur when testing programs under interactive debuggers. The debugger product itself requires the use of the system clock. If a simulated date is passed to the debugger product, it may terminate with a message that your product license has expired. To avoid this problem, SIMULATE 2000 has the ability to pass the actual date to the debugger and the simulated date to the application being tested.

Return to Key Points

Ensuring maximum coverage-STCK

SIMULATE 2000 captures all STCK (Store Clock) direct accesses to the system clock. Some 4GLs and DBMSs, CICS's ASK TIME, the LE 370 date routines and some application routines written in assembler use the more efficient STCK (Store Clock) instruction. STCKs are low-level commands which cannot be intercepted and therefore pose more of a problem. The most common solution is to ZAP (modify) each STCK instruction in such a way that an SVC 11 is called instead. SIMULATE 2000 provides zaps for the most widely used products. In addition, SIMULATE 2000 also offers a solution which does not require a physical zap of the load module but changes the STCK instruction at run time (see DynaMod Option).

Return to Key Points

Ensuring maximum coverage-CICS EIBDATE

SIMULATE 2000 captures CICS EIBDATE indirect accesses to the system clock. To minimize overhead, CICS provides a work area (EIBDATE) where it stores date/time information that can be accessed by user programs faster than the system clock. SIMULATE 2000 is able to trap all accesses to these areas and provide the program with the simulated date and time.

Return to Key Points

Ensuring maximum coverage-DynaMod Option

Powerful option provides dynamic zaps. Load module integrity is maintained and version management is simplified. SIMULATE 2000 is delivered with zaps to handle widely used products that are known to issue STCKs. However, any assembler programmer could issue a STCK instruction. Consequently, you may have applications for which a zap is not supplied (or you install a new version of an existing product that needs a different zap, which you have not yet received). SIMULATE 2000's DynaMod option offers protection against these surprises and support for those installations where systems programmers are reluctant to physically zap widely used modules even for a test environment. DynaMod scans the designated load module after it is brought into memory. It searches for (a) STCKs, (b) accesses to CVTDATE in MVS and (c) accesses to IO-PCB-DATE in IMS/DC, and applies the necessary zap in memory without touching the load module itself.

Two main benefits are derived from the use of this technique:

  1. Load module and system integrity are maintained. Since we are not modifying the load module itself, the integrity of the load module is maintained and its quality is assured.
  2. Version management is simplified. If load modules are modified, additional versions may be created for backup or security reasons. Managing these versions would become an additional production responsibility. The use of DynaMod eliminates this need.

Return to Key Points

Ensuring maximum coverage-JobNet Support

Most major applications include a number of batch jobs, often involving passing datasets from one to the other. In production, they are often defined as a Net to the system scheduler with a definition of precedence relationships or indications that certain jobs or steps can run in parallel. During system testing, users want to test an entire Net with a single running clock so that any timestamps or dates and times passed from one job or step to another will be consistent. They also want the convenience of submitting the Net as a whole. One solution is to use a separate machine or LPAR, but this adds significant cost and has some well documented inconveniences. Another is to run the Net one step at a time and manually insert the date/time to be simulated before each step. SIMULATE 2000 provides a much more convenient solution.

With SIMULATE 2000, users can specify a running clock to start with a particular job or, in the event that more than one job can run in parallel at the start of a Net, to start with the first job to execute. Subsequent steps can be instructed to use the simulated date or to ignore the simulated date and use the real date/time. Normally, for those sites that are carefully logging all their tests as a protection against possible litigation or for other reasons, SIMULATE 2000 would write a log record for just those jobs and steps that actually access the system clock. A combination of JobNet support and the rules language lets SIMULATE 2000 write a log record for each job and step.

Return to Key Points

Security and Control

As programs enter the testing phase, management often determines they need more control and security than the online control table provides. SIMULATE 2000 answers this need with its easy-to-use 4GL type Rules Language or via a direct link to RACF security. The Rules Language can enforce installation standards by defining the date simulation functions allowed by individual users. As an example, it can require that date simulation for a particularly sensitive transaction only be performed from a specific terminal at certain times, or that no date simulation can take place when online transaction volumes are at their peak and the top priority is response time.

The Rules Language also allows the user to set the precedence of multiple rules rather than relying on the built-in logic associated with a fixed format table. Additionally, a particular user group can specify its own log dataset, and multiple programming teams in different countries can specify their own messages.

The Rules Language provides added security by furnishing access to a wide range of system variables. A typical example would be to prohibit date simulation on production jobs, ensuring that date simulation JCL is not copied into production and executed by mistake after testing is complete. Rules processing cannot be bypassed; although, you do not have to specify any rules where none are needed.

Example of rule to limit testing

DEFRULE NEVER_ON_MONDAY_AM IF CURDAY = MONDAY CURTIME(1,2) = (10,11) THEN EXIT /* Test first 2 characters of time */

Example of rule to protect production

DEFRULE NOT_IN_PRODN IF JOBCLASS=(P,Q,R) THEN EXIT

Finally, installations may also develop RACF security rules to define the authorized use of SIMULATE 2000. Before honoring a date simulation request, SIMULATE 2000 will verify that the requesting job or user has the appropriate RACF authority.

These control functions are designed to provide Systems Management with the confidence and security of protecting the production environment while giving the Year 2000 team the flexibility they desire.

Return to Key Points

Cross Subsystem Testing

Tracking which program generated the access to the system clock is essential to determine whether it needs a simulated date/time and, if so, what that value should be. MVS is a very complex environment where hundreds of programs simultaneously co-exist. Some software products (CICS, IMS/DC, TSO, DL1 and DB2, for example) are very complex systems that either manage or may be called by other programs concurrently. MVS manages this environment by allocating separate address spaces to each of these systems, and provides a facility called Cross Memory Services to communicate between these address spaces.

Why does this affect SIMULATE 2000? Since application programs may use the facilities provided by more than one such system, SIMULATE 2000 must track each program's date and time request via these systems, and identify the program that generated the request in order to provide it with its simulated date and time.

Take, for example, a CICS transaction that accesses a DB2 database. That transaction originates from a terminal managed by a CICS terminal handling region, is passed to a CICS transaction processing region (of which there can be several, perhaps even on different mainframes) and then asks for data from a DB2 region. Each of these regions could have a different date/time specified and the date/time could be requested anywhere along the chain. SIMULATE 2000 is capable of identifying the original caller to determine which date/time should be returned-a non-trivial task.

Another problem when operating with Cross Memory Services is that a program can only issue certain SVCs, which means that performing I/O is extremely difficult and has a high overhead. How then is a date simulator to issue messages and log actions? We solved this by implementing one part of SIMULATE 2000 (we call it DIF) in its own address space. Since all system interfaces and I/O are handled from DIF, SIMULATE 2000 can issue messages and log actions by sending a message to DIF. Without DIF, this could not be accomplished directly in cross-memory mode.

Return to Key Points

Messaging and Logging

Messaging and logging of SIMULATE 2000 actions allow a user to verify that simulated dates were set, and provides management the ability to track what testing has taken place. Messages are user defined and can include a variety of system parameters (including actual and simulated date/time, user ID, jobname, etc.). They can be directed to terminals, batch output and/or datasets defined by the user. Logging is simply a form of deferred messaging and is normally used to create an audit trail of SIMULATE 2000 actions. Log messages can be directed to SMF or to separate datasets by user group, or both-a great convenience for semi-autonomous teams separated by application or geographical location.

Return to Key Points

Auditing

SIMULATE 2000 is normally thought of as a testing tool, but it is often used during the planning phase of the Year 2000 project as an auditing tool as well. The audit facility records the name of all application modules that access the system clock-applications that require future date test scenarios for Year 2000 compliance. Records can be written to SMF or to a dataset of the user's choice. In applications where several modules may be statically linked to form a single load module, SIMULATE 2000 will identify the specific module that accessed the system date. In applications where a common date routine is widely used, direct auditing of date requests will yield the date routine's name rather than the name of the application module that called it. To overcome this problem, SIMULATE 2000 provides a backtrace facility that traces the calling chain to find the object module and the offset within the module where the clock access was initiated.

Return to Key Points

Optimum Performance

SIMULATE 2000 provides critically needed high performance (low overhead). When testing, most users are initially more concerned about human productivity than the performance of the testing tool. However, in online environments and when stress testing major applications, high performance (low overhead) is critical.

No matter how the conversion is performed (field expansion or century window, for example), newly Year 2000 compliant applications will almost certainly use more machine resources than before. Applications involving large numbers of online terminals may need to be stress tested to monitor response time and end-user productivity.

The typical MVS environment may issue hundreds, even thousands of SVC 11 calls per second in performing its normal functions. The overwhelming majority of these calls has no relevance to Year 2000 testing and should therefore be ignored. Date simulation products that use a simple approach of scanning the online table for every SVC 11 have been reported to add as much as 20% overhead, far too much for accurate stress testing. SIMULATE 2000, in contrast, normally uses just four machine instructions to determine if the date/time needs to be changed-an insignificant amount of overhead.

SIMULATE 2000 has been designed to minimize overhead. The Rules Language is compiled rather than interpretive. Additionally, when SIMULATE 2000 processes an SVC 11, it captures information about the particular terminal or transaction, so that subsequent accesses from the same terminal or transaction need not be processed again through the Rules Language, saving time and reducing overhead.

Return to Key Points

Summary

Testing MVS application programs for future dates is much more complex than is immediately obvious. MVS has become a very sophisticated environment where there are many ways to retrieve a date and time from the system clock. Some are faster than others, while some do not guarantee accurate data in all circumstances. For maximum effectiveness, a date simulator needs to cover all known variations.

In summary, the product must:

  • Have the ease-of-use and flexibility that allows all programmers to use it without a significant learning curve.
  • Have features that fit the Year 2000 project structure and allow management to implement the level of security they feel necessary.
  • Ensure maximum coverage by identifying all access to the system clock.
  • Operate efficiently enough to not distort response time in online environments.

SIMULATE 2000 has been designed to meet all these requirements.

Return to the SIMULATE product page