Program Conversion - Mainframes - Look, Don't TouchFoundation elements would include, for example: the record classes, data services, data service stored procedures, presentation user controls, interfaces, enumerations, and base classes. As these are generated (where possible with automated tools) unit tests are created in parallel. Some of the unit tests are 'stress tests', they try to create the transaction volume expected when the system goes into production. This, in turn, exposes assumptions about database, web server, and middleware performance and bottlenecks. This makes it possible to 'tune' the server farm, which might involve adding hardware, shifting the balance from web servers to database servers or vice versa, or upgrading the routers and firewalls. A few 'critial' programs should be coded at this point, for the purpose of exposing omissions and naming conflicts. If the core order entry system is developed, for example, the programmers will be asking for database or libary objects that no one anticipated. In developing this one chunk of code, it may become clear that these objects will be needed for many other application blocks. While setting a 'production' deadline on this application is a good idea, it should be kept in mind that the program is not being developed principally for production at this point: the objective is to stress-test the foundation. While the automation tools are converting CICS DSEGs to user controls, the development of one or more core applications helps create the coding conventions for event names, command buttons, and helper classes. These get their respective unit tests in turn. Large systems usually have data import and export functionality, such as EDI, agency-to-agency updates, vendor master files, etc. These take the form of CSVs, XML, JSON, or flat files, sometimes archived and exchanged via FTP. The new system analogs of the mainframe equivalents should be developed during this phase, since they expose another round of issues and name conflicts, as well as exposing needs for database objects and helper classes. They are part and parcel of the server farm stress testing: they are contributing to the data volume that will impact space use, index degradation, and server contention. The original 'green screen' terminals supported 80 or 132 horizontal by 24 or 25 line vertical character resolutions. On 19 inch monitors this takes up the upper left corner of the screen. The older systems tended to shift between 'search' mode and 'edit' mode, where one used certain fields as search parameters. Once a record was selected the same field was used to 'edit'. With the extra room, it is possible to split the screen in half, using the left (for example) as a search panel and the right as the 'edit' panel. The framework (perhaps generated by automation tools) at this point is used to query tables and views by search terms, populate lists of returned records in the search controls, and present a selected record on the 'edit' side. This would add a user functionality benefit for those who aren't keying anything in. To run these programs, the entire program navigation menu would have to be laid out. This, in turn, would expose the security issues associated with read-only access. With this part of the system complete, developers and users can see the light at the end of the tunnel. Most of the infrastructre is in place. This so-called middle phase could be done largely with automation tools, since most of the outputs have a close correspondence to a code file or object in the prototype system. For those that feel like their system is way overdue for an upgrade, please call 210-734-5575 for free initial consultation. Or, eMail us at Info@ResourceLogic.net |