M204 Emulation Strategy

Database Programmer's Toolkit

Model 204 Emulation Strategy



The terms "Model 204" and "204" are trademarks of Rocket Software Inc., and that fact is acknowledged wherever those terms are used in this document.

Summary

This document describes the factors which were taken into account when deciding how to approach the emulation of Model 204. It also covers how features were prioritized so that early releases could be useful without being 100% complete. The partner "features cross reference" document answers all the specific "does DPT currently have a XXXXX feature?" questions via a set of feature tables.

Actually the term "emulator" is not quite right for DPT. That implies the replication of all system operation at all levels, whereas the DPT approach is more like WINE (the windows "not an emulator" for linux) which calls itself a "compatibility layer" rather than an emulator. Like DPT it is concerned with providing a compatible API that allows user code to be written and executed, but is happy to do things differently under the covers if it seems appropriate, and is transparent to the user code.

As well as not supporting some Model 204 features, there are also a number of places where DPT offers somewhat different functionality, and still others where it has significant extra functionality of its own, for example the web server, and other local I/O facilities added in Version 2. However, in the great majority of cases code written on DPT will run successfully and do the same thing when run on Model 204. The opposite is true in a much smaller set of cases, since of course code written on Model 204 is likely to take advantage of the full range of available features. With time, this will become less of a problem as more features are added to DPT.

The main issues involved in approaching the emulation were:



Issue 1: Model 204 is extremely feature-rich

This is the most obvious issue. How is it possible to produce a useful emulation of a platform that has 30+ years of development behind it? Put simply the answer is by leaving a lot out and simplifying most of the rest! (Omitting and simplifying isn't always a bad thing...)

As time goes on the range of Model 204 features emulated will be increased based on what users say are the top priorities. Ultimately in theory DPT could provide a completely "plug-compatible" alternative run-time platform for User Language applications, which can only be a good thing for everybody. If that sounds ambitious, remember that DPT is written in C++, and takes advantage of a vast worldwide repository of standard code libraries. This means it can be upgraded very quickly compared to the mainframe platform where code is painstakingly hand-crafted in assembler.

So down to business - let's see how we can trim some features away...

1a. Things a programmer-focused platform can (perhaps) do without

At least in its early releases, DPT is positioned more as a code-development tool than a production platform. This means there are a range of M204 features, namely those geared towards production operation, which seemed like the system would be more or less usable for writing, testing and debugging code without them. In this context the goal to provide a development platform can be thought of as a sort of halfway house to full production capability, and these features are ones which can be easily "bolted on" at a later stage.
1.1. Security
Initially none of Model 204's internal security features were emulated, working on the assumption that PC users typically deal with security at the OS level or with physical doors and locks. Within application code, calls to security-related functions returned default results. From DPT Version 2.16 however a small set of access-control features are available.
1.2. Connectivity
Most connectivity options, such as CICS, Connect*, DB2, MQ etc. Thread types supported are full-screen, interactive line at a time, file-based, and daemon. Version 2.0 adds web server and native Windows sockets connectivity.
1.3. Data access
SQL and any data access options apart from those provided by the 4GL, which is to say commands and User Language. Open-source C, C++ and Java APIs into the underlying DBMS also exist.
1.4. Data Dictionary
All configuration is via the command line, including creation of subsystems (i.e. no subsystem management screens).
1.5. Language support
Any kind of non-English language support (e.g. none of the $functions have language-related options).
1.6. Character sets
String and character processing, comparisons etc. in virtually all situations are based on the ASCII collating sequence. The exception is that DPT does have the ability to translate data to and from EBCDIC if necessary (e.g. $ASCII/$EBCDIC). There is no support for DCBS or KANJI.
1.7. Fancy configurations
This means MP, PQO, etc., although some aspects of DPT are similar to both those configurations as they work on the mainframe. The custom client can behave like an online batch user ("BATCH2").
1.8. Roll-forward recovery
There is no roll-forward, and no journal file, so none of the other stuff gets journaled either. Roll-forward can be thought of as a nice-to-have, but is not strictly necessary to maintain database integrity in the event of a crash. Checkpointing and roll-back protection are provided. There is no "extended quiesce" option.
1.10. Obsolete features
Some "obsolete" features mentioned in the manuals, such as line continuation within bracketed expressions, are not allowed on DPT.
1.11. Weird parameter settings
For example only the first 4 CUSTOM values are emulated.
1.12. Lesser-used features
Things like sorted and hashed files, and AT-MOST-ONE and UNIQUE fields. "Lesser used" is a highly subjective term of course!

1b. Simplified features

These things for one reason or another have not been developed completely. The main thing separating these from the above is that it didn't seem like it would be possible to go without them altogether. They are therefore implemented, but in a more or less simplified way. For example the database transaction and logical integrity strategy only has slight differences from M204, whereas statistics gathering is noticeably more straightforward.
1.21. Transaction back-out
On DPT, LPU and TBO always go together. What's more, they can only be turned on or off at the system level, not for individual files. TBO is a little simpler.
1.22. Statistics
The set of statistics gathered is somewhat reduced and consolidated, and there are no partial, performance or MP statistics. SMF is obviously not relevant.
1.24. Groups and subsystems
Both of these features are present, but there are is no permanent storage in the form of equivalents for CCASYS and CCAGRP. Groups and subsystems must be defined in each run. There are restrictions on the variation of field attributes between members of a group.
1.25. 3270 full screen handling
Given the range of 3270 screen attributes and functions, or even the subset provided within Model 204, a full emulation here would be extremely challenging. Nevertheless the DPT custom client does its best to provide a usable implementation, and should be OK for most applications.
1.26. User Language
There are only a few statements that are not supported at all, mostly to do with communication options (e.g. Horizon) that aren't emulated either. This category is also a catch all for a few rarely-used and generally unpopular features.
1.27. $Functions
At the time of writing at least 90% of the standard and math $functions work the same as on Model 204. A small number are not present because they relate to unsupported features (and might therefore not be present in a similar installation of M204 either). The rest return slightly different results usually reflecting platform differences. A subset of the Sirius function repertoire is also emulated. Users' existing custom $functions will not work initially, but a special document will appear soon describing the relatively straightforward process of adding them.
1.28. FLOD
The FLOD language is not supported. However from Version 3.0 DPT does include its own fast-load utility.

1c. Purely performance-oriented features

In many cases, Model 204 features are only there to improve performance, but do not offer any extra functionality over other available features. KEY indexes are an example; pre-allocated fields are a less clear-cut example; and the whole notion of an internal scheduler, when many operating systems provide thread scheduling services, is yet another example. Such features have been dropped more or less happily. At the end of the day a PC-based system is unlikely to win any races against a mainframe one.
1.41 Database index options
Any apart from ordered character and ordered numeric fields.
1.42 Database data storage options
Any apart from string, float(len 8), invisible, and from V3.0 BLOBs. This is somewhat related to the issue of field constraint options like at-most-one, none of which are emulated. ON FLC units are accepted in UL requests with a warning message.
1.43. Parts of APSY
At least in the initial release, there are no pre-compiled requests. The APSY feature has one or two other small differences in operation.
1.44. Assorted buffer management features
Such as pre-emptive writes and delayed disk writes. The buffer manager is somewhere that DPT takes an approach tailored to the requirements of the PC user.
1.45. NO FS
The default, "YES FS" implements a run-time performance optimization that DPT does not do. NO FS compiles but has no effect.



Issue 2. The PC environment and operating systems

The second main issue is that there are certain inescapable differences between the mainframe and PC environments. DPT attempts to strike a balance between being a PC application, and at the same time behaving a bit like its mainframe counterpart so as to be familiar to Model 204 users.
2.1. DPT has no internal scheduler
Instead it relies on the thread-scheduling capabilities of the operating system.
2.2. Memory Management
In most cases DPT leaves memory management to the operating system, which removes the need for some system-level parameters, while giving us a few new ones.
2.3. Database file IO
Low level disk IO has a distinct Windowsy flavour in many cases. This should be transparent to the user.
2.4. No VTAM
This makes a fairly large set of parameters and commands redundant, but adds a much smaller number of custom commands and parameters for controlling the socket interface. It also has implications for the parameters which control output line length and paging, particularly on interactive devices like IODev 7, since on the PC we can make much greater use of scrolling windows instead of sticking to the "page-based" nature of 3270.
2.5. Assorted general features
Including snaps, dumps, zaps, SMF parms and stats, anything to do with the operator console, anything to do with JCL (JOBNM, STEPNM, £JOB etc.) In addition this is a kind of catch-all category for some other features that are inappropriate on the PC, or that it didn't seem worth re-inventing, such as the MSG command (use email), detailed printer control (use Windows) etc.
2.6. File enqueueing
Database files are always enqueued exclusively as far as the OS is concerned (i.e. you can't share between onlines). This is not strictly an OS limitation, but does make things simpler internally. FRCVOPT is always effectively X'10' - no discontinuities allowed.
2.7. Number handling
A complete emulation of the low level floating-point functionality used by Model 204 on the mainframe, whilst possible, and maybe even fun, would not bring very much to the party. Therefore there will certainly be one or two differences in number handling, particularly when dealing with very large or very small numbers, or when very fine precision is required. Another minor potential issue is endianism.
2.8. Sequential files
PC file systems are different, especially when it comes to what constitutes a "record". This has implications for file allocation, image reading and writing, and USE.



Issue 3. DPT is written from scratch

This is the most interesting category, and covers those features where DPT has taken the opportunity to do things differently for reasons not covered in the above two categories.
3.1. Procedure handling
This is significantly different in implementation, but appears similar to the user. Procedures on DPT are text files, in file directories instead of in table D of a 204 file. In many ways this makes procedure handling much easier than on M204, but does have some implications for parameters and commands.
3.2. Database file structure
The DPT DBMS is in many ways different to Model 204's, although since both are based on standard data structures such as b-trees and bitmaps, they are also similar in many ways too. This means that many of the familiar file parameters and statistics have similar meanings, which is useful from a programmer point of view.
3.3. Assorted differences in messaging
Message numbers are different to M204's. The messages themselves are also often more helpful than M204's. Message control options are somewhat simplified. Also, importantly, messages can be "smart".
3.4. The audit trail
The DPT audit trail is similar to the Model 204 equivalent but its layout can be customized.
3.5. Reserved words handling
Field names can contain quoted sections (i.e. to "hide" unwisely-used reserved words), but no other entities can. For example procedures.
3.6. Front End facilities.
The provision of more functional and useful front ends is a key goal of DPT, and affects several areas. An emulation of the M204 full screen editor as such is definitely superfluous, since the EDIT command invokes a different, better, editor. The line editor is also unsupported despite the fact that it is sometimes used for utilities. The only debugging option is the interactive step debugger. This should eliminate the need for features like DEBUG SUBSYS, TEST DEBUG and SSTEST. From Version 3.0 database files (.dpt) can be opened directly by a GUI viewer utility, the File Wizard.
3.65. Windows platform I/O
This is a set of facilities added in Version 2 which, like the above, make DPT sit more comfortably as a PC development platform in its own right, rather than being something of a mainframe fish out of water.
3.7. The inevitable final "catch-all" of miscellaneous differences
For example the output from a number of commands looks somewhat different to M204's output, for a variety of reasons covered in this section. This catch-all category includes places where it proved irresistible to add new (i.e. DPT custom) commands, $functions etc. Custom options like this can be disabled using the CSTFLAGS parameter.
Top