The Janus Debugger is designed to debug Janus Web Server applications. With software installed on the Model 204 Online as well as on a workstation with a browser that can access a proxy server, the Debugger lets you examine in statement-by-statement detail the User Language code that the Web Server executes.
When a Janus Web Server is about to run a request on your behalf, and you are running under the Janus Debugger:
Although limited to Janus Web Server applications (for example, if a program does a 3270-screen read, the Debugger session terminates), the programs you debug may be, or contain, the following:
The Debugger follows execution of code requested by terminal and Batch2 requests. It does not process HTTP Web Server requests (though it can debug HTTP client applications that use the Janus Sockets HTTP Helper).
When an application is about to run a Model 204 3270-terminal or Batch2 request,
Although limited to 3270 or batch stream applications (unless you also license the Janus Debugger), the programs you debug may be, or contain, the following:
The following image of the Debugger Client (debugging a Janus Web Server program) has numbered labels that point to the principal areas of the Debugger and that are linked to descriptive text below the image:
The main display window is used by any of several tabbed pages (the Web Buffer tab is not present for TN3270 Debugger sessions; Daemon tabs display dynamically if the program invokes daemons):
The Proc Selection page lets you select the Model 204 procedure at which the Debugger will stop for debugging, after running normally the program code that precedes the procedure. From this page you can also operate the White List feature, which lets you specify the particular set of procedures to which debugging will be limited. The Debugger will stop to debug only the procedures on the list.
The text area above the Watch Window labeled Variable or Field lets you add an item to the Watch Window or provide dynamic input to a user-defined macro.
The Status area displays messages that describe the state of the Debugger after each operation you invoke.
The Top, Bottom, Search, and Search Next buttons provide navigation on the currently active tab. You can rearrange the order of the buttons and can even replace them with different functionality.
Like the page navigation buttons, the order and functionality of these buttons is user-configurable.
The Debugger Client has multiple menus; many of the menu options duplicate the actions of default Client buttons and keyboard shortcuts, and most menu options are associated with Client commands.
In addition to a configuration file you edit at the time of product installation to provide Online and workstation TCP port numbers, the Debugger Client has a number of configuration options that are dynamically settable from the File > Preferences menu:
These items control optional points at which the Debugger might pause program execution for user input.
Web Browser Options
If Internet Explorer is the browser you are using with the Janus Debugger, you can enable a Debugger Client feature that automatically specifies and maintains the definition of the Debugger Client as Internet Explorer's proxy server. The proxy takes over when the Client is started, and its settings are removed when the Client is closed.
The first of these options lets you limit the number of items displayed when you view the entire contents of a $list or StringList object. The second option lets you trim leading and trailing blanks from text you copy to a separate display window.
Web Server Selection
At any time, you can selectively deactivate or reactivate debugging for browser requests sent to any Janus Web Server defined to the Debugger Client.
After some experience using the Debugger, you have further customization options:
The Debugger provides several options for tracing the effects of your program execution. You run part or all of your program, and the Debugger collects tracing data in a separate page, the Execution Trace tab.
The simplest form of tracing starts from the current execution point and notes which lines were executed. You click the Trace button below the main window, the program executes, and a list of the statements executed is displayed in the Execution Trace tab.
Clicking the Trace Changes button invokes tracing that lists all statements that modify a selected variable and specifies the new value that was assigned to the variable:
You can also have the Debugger stop program execution whenever the value of a variable changes. Once you click the Run to Change button, the statement that modifies the specified variable, as well as the new variable value, are shown in the Execution Trace tab.
Finally, a variation of the Run To Change feature lets you continue program execution unless or until a selected variable's value becomes equal to a value you specify. This lets you verify whether a variable ever becomes a certain value.
An XML example
Applications using Janus SOAP XML document objects (XmlDocs) are becoming increasingly common due to the prominence of Web Services. The Janus and Sirius Debuggers make it easy to display the contents of your XML document objects, and thus let you examine an XmlDoc as it is being built by your application code.
Ordinarily in the Janus SOAP XML API, you can inspect the contents of an XmlDoc only if it is serialized by an XML document serializing method like Serial, WebSend, Xml, or Print. As a result, if you want to know the contents of an XmlDoc sometime before the code contains a statement that serializes the XmlDoc, you have to intervene. If you were editing your own code by hand, you might simply insert Print method statements to view the contents. The Debugger provides a solution that avoids any modification of your code.
Say you are debugging request code in which a statement like the following is executed:
Instead of directing the Debugger to display the value of %x — the way you display the value of other variables in the GUI — you specify the value %x:serial. When you click the Value button, the Debugger Client displays in a separate window the result of the XmlDoc Serial method applied to the object variable %x:
For your convenience, the Debugger formats the return value with carriage-return/line-feed character sequences and three-blank character sequences for the indent of nested elements. The XML documents you are building or receiving (say, via an HTTP Helper Web Services client application) are readily visualized, thus easier to debug.
With version 7.1 or higher of the Sirius Mods, you can display for a given object variable the names and values of the Variables (public and private) defined for its class.
This feature is supported for Janus SOAP system classes and for user-defined classes. For any class, the display does not include class methods (Functions, Subroutines, Properties, or Constructors).
For example, for an object variable whose value you are watching in the Debugger Watch Window, you simply right-click the variable and the Debugger enables an Expand Object option (as shown to the right):
If the current object variable value is other than Not-null, the Expand Object option is not enabled.
Once you select the Expand Object option, a Value window opens, displaying the names and current values of the Variables in the class (as shown below):
Both the Janus Debugger and the TN3270 Debugger support Model 204 V5R1 and higher on the MVS, VM, and VSE operating systems.
Version 6.8 or higher of the Sirius Mods is required.
The Debugger Client application runs only on Windows workstations. The Janus Debugger requires a web browser that supports proxy servers.
SoftSpy provides interactive debugging, performance tuning, quality assurance testing, and error audit options for User Language. These features greatly increase your productivity while developing, testing and maintaining user language applications.SoftSpy provides the detailed information required to quickly and efficiently pinpoint the precise cause of a problem. SoftSpy users routinely report solving problems in minutes rather than the hours they believe it would have taken without SoftSpy.
Debugging User Language requests can be a frustrating and time-consuming process. Faced with the symptom of application error, such as a runtime message, you must determine the cause. Without quick access to the proper information, even simple bugs can take hours to fix.
SoftSpy provides the detailed information required to quickly and efficiently pinpoint the precise cause of a problem. This transforms debugging from an art into a science. It becomes straightforward to track down a problem when appropriate information is available. Productivity of both junior and senior level staff members is increased tremendously.
SoftSpy users routinely report solving problems in minutes rather than the hours they believe it would have taken without SoftSpy.
SoftSpy lets you quickly track down runtime errors. After intercepting a typical error like divide by zero, SoftSpy displays a detailed diagnostic screen.
The name of the request being evaluated is shown on the second line of the screen followed by a window into the complete request with all includes expanded.
The current line (indicated by => in the prefix area) is positioned on the line that caused the error. The values of variables at the time of the error are displayed in the monitor window.
If you need additional information, you can easily examine the values of any variables, look at any portion of the program, or find out the sequence of statements executed prior to the error. This information makes it simple to determine the cause of the problem.
SoftSpy also simplifies tracking down compilation errors. When they occur, SoftSpy displays the User Language request. Compilation error messages are embedded within the request immediately following the offending statement.
The current line is positioned on the first line that contains a syntax error. Function keys are provided to jump forward to the next line containing an error or backward to the previous error line.
Understanding how an application works requires that you run the application to learn the user interface. It also requires that you study the procedures and data used by the application.
SoftSpy allows you to quickly learn how applications work by integrating these activities together. You can clearly see which procedures are responsible for which portions of the user interface, and you can watch the interaction between the program and the data. Seeing this interaction allows rapid, in-depth understanding of an application.
The speed with which SoftSpy helps staff members understand applications has substantial benefits. It enables organizations to accomplish objectives that would otherwise be virtually impossible. Staff members can be transitioned to new projects since the systems they know can be more easily understood and maintained by others. Employee turnover and reorganizations can be handled with much less disruption. Enhancements can be made to older systems that are not well understood by the remaining staff. SoftSpy even makes it easy to decipher applications written using statement numbers.
The interactive debugging option provides a number of features that augment the basic SoftSpy environment to provide a robust interactive debugging environment.
Information about the following types of operands is provided:
SoftSpy can precisely identify which statements have been tested and which have not. This allows you to test your application, and determine afterward if test coverage was complete. It also allows you to test what code is executed for specific business functions.
High quality applications can be delivered only when thorough quality assurance testing is part of the application development process. Organizations that are serious about reliability try to develop detailed test plans that identify every feature to test. However, even the most carefully designed test plans inevitably have some gaps in their coverage. SoftSpy allows a new approach to testing: it can precisely identify which statements have been tested and which statements have not been tested. This allows you to test your application, and determine afterward if test coverage was complete. You can then adjust your test plans based upon this feedback. The result is your ability to test applications more rigorously, in less time, and with more confidence.
QA Test Coverage Profile
SoftSpy can produce a detailed quality assurance test coverage profile. A message summarizes how thoroughly the current request has been tested.
The column labeled "U" contains the letter "U" for each line with an untested executable statement. If an executable statement has been tested then the column labeled "TIMES TESTED" indicates the number of times it was executed.
Function keys are provided to allow you to move forward and backward among untested statements. You can also print the test coverage profile for review at a later time.
It is possible to have "dead" or unreachable code in requests. For example, code that is unconditionally branched around is unreachable. Similarly, code in a subroutine that can never be called is also unreachable.
SoftSpy can perform a complete flow analysis of your request in order to identify unreachable code. This allows statements to be classified as either tested, untested and unreachable, or untested and reachable. The presence of untested statements that are reachable indicates that further testing is required.
The column labeled "R" indicates whether an executable statement is reachable or unreachable.
The quality assurance testing option provides a number of features that augment the basic SoftSpy environment to provide a robust quality assurance testing environment.
The following information is provided.
SoftSpy provides the information required to quickly track down performance bottlenecks. SoftSpy shows precisely which lines within requests consume the most system resources.
Tuning User Language applications can be a difficult process. Faced with poor response time or excessive resource consumption, you must determine the cause. Without the proper information, even simple performance bottlenecks are difficult to isolate and correct.
SoftSpy provides the information required to quickly track down performance bottlenecks. SoftSpy shows precisely which lines, within the request user language code, consumes the most system resources.
SoftSpy also provides detail illuminating the underlying activities associated with system level resource consumption. Armed with this information, it is possible to quickly determine the root cause of performance problems.
SoftSpy lets you generate detailed performance profiles. Performance profiles can be tailored using an extensive repertoire of statistics that show all facets of an application's behavior. Resource use can even be displayed graphically using histograms.
For example, a performance profile can have a "CPU" column that shows the total milliseconds of CPU time and an "AVG CPU" column that shows the average milliseconds of CPU time spent executing each statement. A "PAGE REQ" column can show the number of page requests performed by the disk buffer monitor for each statement.
This type of performance profile shows statements with excessive CPU consumption. It also shows statements that generate excessive page requests. Excessive page requests very clearly pinpoint performance-related problems like the thrashing of images in and out of the buffer pool. Thus SoftSpy can provide detailed information to explain the cause of a CPU or I/O bottleneck.
In addition to all normal statistics, SoftSpy can show CCATEMP use by line. The use of CCATEMP is a critical performance factor. Excessive use causes buffer pool thrashing that becomes much worse as overall system load increases. Monitoring CCATEMP use lets you see the real problem, even on a lightly loaded system.
Server Table Usage
SoftSpy can show detailed statement level usage of server tables. Cumulative server table use can be shown for all server tables, and individually for tables such as QTBL and VTBL. This line by line information allows you to understand and optimize an application's server table use.
SoftSpy lets application developers display performance information during the normal testing of User Language requests. How well a chosen approach works is easy to observe. This feedback naturally results in application developers learning the best way to use Model 204.
The interactive performance tuning option provides a number of features that augment the basic SoftSpy environment to provide a robust performance tuning environment.
A variety of different types of performance-related information is available:
The SoftSpy provides the detailed information required to quickly and efficiently pinpoint the precise cause of a runtime problem. This transforms debugging from an art into a science. It becomes straightforward to track down a problem when SoftSpy makes the appropriate information available. Productivity of both junior and senior level staff members is increased tremendously.
Debugging runtime errors in User Language requests in a production environment can be a frustrating and time-consuming process. Faced with a runtime error message that doesn't identify the offending program statement, it can be quite difficult to determine the cause. Without quick access to the proper information, even simple bugs can take hours to locate and fix.
The SoftSpy Error Audit option provides the detailed information required to quickly and efficiently pinpoint the precise cause of a runtime problem. This transforms debugging from an art into a science. It becomes straightforward to track down a problem when appropriate information is available. Productivity of both junior and senior level staff members is increased tremendously.
SoftSpy users routinely report solving problems in minutes rather than the hours they believe it would have taken without SoftSpy.
With the SoftSpy Error Audit feature enabled in your production environment, additional audit messages are produced when an error occurs during the evaluation of a User Language request. These messages identify the exact location that the error occurred within the request. Using this information in conjunction with the SoftSpy Error Audit environment you are quickly able to locate the statement causing the problem.
The sample below shows a segment of a Model 204 audit trail containing a typical divide by zero runtime error with the additional SoftSpy Error Audit information.
12284180520 27 3 0 MS *** M204.1168: INCLUDE TESN.LOGIN 12284180520 28 3 0 ST $$$ USERID='USERZERO ' ACCOUNT='USERZERO ' LAST='CMPL' SUBSYSTEM='DEMO ' PROC-FILE='AEYPROC' 12284180520 29 3 0 XX PROC='TESN.LOGIN' NTBL=5 QTBL=17 STBL=73 VTBL=10 PDL=620 CPU=2 PCPU=666 RQTM=3 DKPR=21 12284180520 30 3 0 ER *** SPY>>> Runtime Procedure Error in Subsystem: DEMO Procfile: AEYPROC 12284180520 31 3 0 ER *** SPY>>> Procedure: TESN.LOGIN 12284180520 32 3 0 ER *** SPY>>> QTBL quad offset: 188 12284180520 33 3 0 ER *** SPY>>> Call issued from QTBL quad offset: 68 12284180520 34 3 0 ER *** SPY>>> Call issued from QTBL quad offset: 0 12284180520 35 3 0 MS *** M204.0554: DIVIDE BY ZERO 12284180520 36 3 0 ST $$$ USERID='USERZERO ' ACCOUNT='USERZERO ' LAST='EVAL' SUBSYSTEM='DEMO ' PROC-FILE='AEYPROC' 12284180520 37 3 0 XX PROC='TESN.LOGIN' NTBL=5 GTBL=345 QTBL=17 STBL=73 VTBL=10 PDL=620 CPU=2 OUT=1 PCPU=2000 RQTM=1
The sample screen below shows the program that caused the divide by zero error above using the SoftSpy Error Audit environment. In the Audit environment you can quickly identify the statement that caused the problem.
12 of 16 Next 1 SoftSpy for Model 204 15 OCT 2012 12:00:00 IN AEYPROC I TESN.LOGIN SUBSYSTEM DEMO ============================================================================= CMPL NEST QTBL == 20 CALL MAIN ----------MONITOR---------- == 52 %X = $SETG('NEXT','EXIT') - - == 52 - - == /------- 68 MAIN: SUBROUTINE - - == | 88 CALL DIVIDE.LOOP - - == \------- 96 END SUBROUTINE MAIN - - == 96 - - == /------- 112 DIVIDE.LOOP: SUBROUTINE - - == |/------ 172 FOR %I FROM 10 TO 0 BY -1 - - => || 220 %J = 10 / %I - - == |\------ 224 END FOR - - == \------- 232 END SUBROUTINE DIVIDE.LOOP --------------------------- == 232 == 276 END => QUAD OFFSET 188 IS WITHIN THE HIGHLIGHTED LINE 1=HELP 2=WINDOW 3=QUIT 4=STEP 5=GO 6=BREAK 7=BACKWARD 8=FORWARD 9=REPEAT 10=WATCH 11=QUAD 12=RETRIEVE
The audit error option provides a number of features that augment the basic SoftSpy environment to provide a robust runtime error debugging environment.
Information about the following types of operands is provided:
Provides a highly productive integrated environment for the development and maintenance of Model 204 applications. SirPro efficiently manages very large procedure files while providing high performance search and global replace features. SirPro also provides a full screen interface for commonly used Model 204 commands.
SirPro is a set of productivity tools for programmers, analysts, DBAs, and anybody else who has ever wanted to work efficiently inside the Model 204 environment.
SirPro centralizes all the tools necessary for managing procedures, group definitions, passwords and privileges, and helps organize daily tasks by providing a consistent, ISPF-like work environment. A profile is defined for each user that includes file and procedure selection criteria, commonly executed commands, destination files for copies and moves, print specifications, and more. Each user's profile is saved from session to session.
Up to four search strings may be specified during procedure selection
SirPro takes advantage of Sirius $functions and special data structures that allow for small server sizes and extremely efficient processing. This emphasis on efficiency, the hallmark of all Sirius Software's products, allows SirPro users to manipulate an unlimited number of procedures, and to perform operations such as searches for a string in a list of procedures that would otherwise consume prohibitively high levels of CPU.
Built around a set of " list" handling functions, SirPro has no practical restrictions on the length of procedure lists. In addition, these " lists" can be scrolled or quickly sorted by date, time, user id, procedure name, or size.
Search delivers output list in seconds
Programmers and analysts benefit through SirPro's fast and efficient interface to the Model 204 procedure editor. Database Administrators, File Managers, and Systems Managers benefit through SirPro's ability to facilitate the administration of system security and Model 204 group definitions. Because of the consistent interface to all of these functions, it is very easy for one person to perform tasks across functional areas.
Programmers and Analysts
SirPro operates in either file or group context and provides a range of procedure selection criteria that includes an extremely efficient string search capability. SirPro users can specify as many as four character strings simultaneously, creating a list of procedures from the file or group which contain any of the strings. This search feature is extremely fast. It takes only seconds to build a list of the subset of procedures (out of thousands) that contain a specific string. Once the list is loaded, procedures may be selected to edit, copy, move, rename, delete, include, print, or browse.
SirPro's browse is actually a powerful multifunction utility that allows a browse without placing enqueues on the procedure. In addition, SirPro provides an expanded browse in which all included code is displayed. SirPro can also display all the undeclared variables within the procedures.
DBA and Systems Managers
SirPro offers a full-screen front end that simplifies maintenance of passwords, privileges and group definitions, as well as a screen for managing a list of frequently-executed commands.
CCASTAT passwords may be updated, users deleted, privileges, priorities, and access levels changed for users, files and groups: all from a single, intuitive set of screens that allow the user to visually verify new passwords, or keep them hidden as they are entered.
A full screen interface is provided for all user, file, group entries in CCASTAT
Permanent group definitions stored in CCAGRP may be updated via a similar panel that enhances the standard method of handling groups by allowing the user to update a group definition rather than deleting each one and re-creating it from scratch. Similar to the functions for managing CCASTAT entries, group definitions may be added, updated, deleted, renamed or copied to new definitions, making maintenance of permanent groups as simple as the maintenance of procedures.
SirPro's highly optimized user interface provides maximum utility and efficiency. It provides a comprehensive set of functions that are highly integrated and professionally packaged. SirPro takes advantage of custom enhancements to the Model 204 environment that increase its speed and power. SirPro's comprehensive manual and its extensive on-line help facility easily and quickly answer any question about its usage.
SirPro runs under all supported version of Model 204. It is available under MVS, VM/CMS and VSE operating systems.
Managing changes in User Language-based environments is one of the most challenging tasks facing managers in Model 204 shops. To address those tasks, most managers rely on some type of management system--automated or manual in nature. The simplest system for managing changes must be able to track programmer activity, prevent changes from being overwritten, move procedures and files across environments, allow for backout of changes, and provide a host of reporting and scheduling functions.
SirLib is a system for managing User Language changes that handles all aspects of change control and that is fully integrated into a package of programmer efficiency tools. SirLib allows managers to quickly and accurately track work in progress, apply and backout changes, and distribute new releases. SirLib addresses both management and technical needs of projects, whether they are being newly designed and implemented or are in long-term maintenance mode.
Programmers using SirLib will find that the integrated edit environment increases productivity.: Ffast and efficient search capabilities as well as, full-screen procedure edit, browse, copy, move, delete, and rename functions significantly ease common tasks, while a facility for along with full-screen capture of Model 204 commands provides an otherwise unavailable capability.
SirLib commands for managing changes are part of this integrated environment and a package designed to enhance programmer efficiency, not reduce programmer productivity. From the programmer's point of view, the change management portion of SirLib is transparent. Programmers using SirLib spend more time programming and less time trying to figure out who changed what code, creating paper histories of changes, making backup copies of procedures, or maintaining home-grown change management utilities, making backup copies of procedures, or creating paper histories of changes.
SirLib allows each project manager to determine the mount of control and security to use on a project. Updates may be limited to a single programmer or to a procedure. Managers may force all updates to go through SirLib. Reconfiguration may be limited to only the project leader. The project leader may insist that no changes occur until a logical change identifier is entered in SirLib. Or, all these controls can be bypassed and SirLib used on an honor-system basis while still providing significant benefits in tracking, applying, and reporting on changes to code.
SirLib doesn't dictate a particular promotion scheme to users. With SirLib a shop standardizes on a mechanism for change control while allowing each project to manage versions and maintenance releases, and apply bug fixes and back-outs, via the change promotion path to which it is best suited.
Change Management using SirLib; XCOMPARE utilities produce change decks in development allowing for small distribution datasets. Sirlib applies these changes in each
environment, allowing for quick and simple reconfiguration.
Accommodating Different-sized Shops and Projects
In some Model 204 shops, one project will consist of a half-time programmer, two users, and a set of files so insignificant nobody remembers their organization type, while the next project will have 50 programmers, hundreds of users, and design details agonized over by teams of business analysts. Using SirLib as the mechanism for change control allows each project to determine the appropriate amount of control to be exercised over programmers, procedure integration, and releases. SirLib allows straight-forward promotion for simple projects, system sign-offs, and complex integration paths for closely managed projects.
And Different Levels of Control
SirLib can be configured to allow only one programmer at a time to "chec "checkout" a User Language procedure. Alternatively, a number of programmers can work on the same procedure at the same time and SirLib will apply each programmer's change during a "re-configuration" of the procedure file. Possible update collisions are handled early in the development process and the possibility of one programmer writing over the top of another programmer's changes is eliminated.
Change Control Process
SirLib is based around a set of XCOMPARE utilities that reduces the granularity of a change to a section of a procedure. When programmers complete updates they use the XCOMPARE facilities to generate change decks: small procedures containing only the lines of code altered by the programmer. SirLib applies these change decks to base procedures in the procedure file. Multiple change decks can affect the same section of code, and, in the rare case that a change prevents another change from applying correctly, the user is informed and the offending change deck can be re-generated.
Identifying and Reporting Changes
Because it is based around the concept of "change decks", identifying changes in a release is simple and highly accurate. Precise line-counts of changed code can be reported for a release, along with exact functional descriptions of those changes,. Programmers don't have to remember each change they made, and managers can see directly how much work has been done. The changed code can be reviewed for conformity to shop standards and construct efficiency. Along with making possible this type of manual review, SirLib supplies managers with a set of reports that summarize code changes and programmer activity.
To provide these benefits without burdening the programmer with clerical tasks, none of the extensive data used in SirLib reports need manual input. All reporting data is generated directly by program activities. Managers can elect to use SirLib documentation facilities to enter an unlimited amount of text and to associate text with a particular change or a particular version release.
Distributing and Migrating Changed Code
SirLib allows users to distribute changes, whether it be by Model 204 DUMP/RESTORE, by sharing update files across onlines, by IEBGENER, or by a networked distribution system. SirLib, however, gives users the advantages of distributing small procedure files containing nothing but change decks, thus massively reducing the size of distribution datasets and adding the ability to select custom configurations from those change decks. With SirLib all changes to all procedure files can be distributed in a single small Model 204 file.
Handling Emergency Fixes
Most inhouse-developed change control allow for violations of promotion paths to address the need for quick fixes. Sometimes these fixes need to be put into production without going through integration, QA, testing, and staging. This creates a situation where these ad-hoc fixes will not be integrated into the application system, or will be written over by some other programming change.
SirLib eliminates the need for programmers to circumvent the proper change control procedures.
Easy Backout of Problematic Code Changes
Fixes are distributed in change decks, and applied one change-at-a-time. The ability to remove a single change from a set of change decks and to reconfigure a procedure file is almost infinite and is extremely fast. There is no longer a need for ad-hoc fixes, on-call programmers, or backward copying of production procedures. Further, because reconfiguring a procedure file to a particular version is so simple, dependence upon external backups is virtually eliminated.
Configuration Management to Suit Your Needs
In shops with multiple environments, changes are applied in each when it is convenient and appropriate for that environment, and without the need to time procedure file reconfiguration to dependencies in the batch cycle.
SirLib is one member of a family of tools designed to increase the efficiency and effectiveness of the User Language programmer. If you have User Language applications, you would benefit by using SirLib and related Sirius Software products, SirPro and SirXref.
Sir2000 Field Migration Facility is a Y2K specific tool designed to assist a DBA in specifying a storage format and semantics of a date field or fields. Sir2000 Field Migration
Facility intercepts updates to date fields and verifies formats and validates values. It allows a DBA to define an alias or aliases and allows for complete control over access to field
names and aliases.
The Sir2000 Field Migration Facility decouples database logic from the application logic so that an application remains unchanged.
Sir2000 User Language Tool is a package of products designed to help you change and test User Language applications for correct operation across the millennium