The 4GL Problem and Solution. 3GL Solution by Bart Z. Lederman System Resources Corp. I volunteered to do a 3GL solution to the problem to provide a comparison between traditional programming languages and the 4GL solutions. Although some people requested a COBOL solution as being the 'typical' traditional business solution language (which point could be disputed), and while I might have preferred FORTRAN for this, it happens that where I work now only C is available (except for Macro-32, which is not a good choice) and so that is the language I plan to use. If I had a forms package such as FMS or TDMS available I would probably have used it, because the screen painting, and especially the requirement to scroll through data in both directions, takes a lot of programming effort: but again, it happens that none are available on the system I use, and I did not want to have to develop an application remotely. I therefore used SMG routines (which are supplied with VMS) for the screen management functions. This greatly simplified the presentation and selection from menus, the bi-directional scrolling regions, and integration of help messages: but it may place some limits on browsing in the way the original problem was defined. I do have a choice between using an Rdb relational database for the data, or using RMS files. I ended up using Rdb, which made some of the retrievals easier, and would ultimately allow database triggers to do update the content of some MASTER records from the DETAIL records. However, nothing I did so far would be difficult to migrate to RMS or other file systems. An advantage to using SMG and a 3GL is that once the program is compiled and linked, it can be run on any VMS system. Since permission to use Run Time Only Rdb is now included with a VMS license, using it requires that a media kit be purchased and installed but no extra licenses should have to be purchased: and this is where the greatest cost is. Conversion to RMS would even eliminate this. Not having to buy a run-time license for a 4GL can be a significant cost savings, and would simplify program distribution, if the application is intended to run on a large number of systems. If it has to be distributed to a large number of users the savings in license fees can pay for the additional development time. Another advantage to a 3GL is that there is nearly total freedom to design the application the way one wants. With 4GLs one is often forced into a particular style of application development or operation or "feel". The HELP which was built into the application uses a standard VMS HELP library. This means that HELP can be accessed with DCL and from other applications as well as from this particular application, only a normal text editor is needed to create and maintain the HELP text source, and that HELP can be changed (for example, translated into another language) without making any changes to the application source or executable image. At least some 4GLs require that HELP be built into the application using only their special format, the HELP cannot be accessed from outside of the 4GL application or from other applications, and changing HELP requires changing the application with the 4GL development tools. There is also the advantage that the project could have been split up into modules so that more than one programmer could have worked on it at a time, and there could have been an additional person working on the HELP file. At least some 4GLs allow only one person at a time to edit an application, and the application cannot be divided into 'pieces' which can be worked on by more than one person. Most of the Browse phase was implemented. All of the selection types are allowed, and the no record and one record selected cases are correct. However, I mis-read the description and the display of multiple records is not the way the problem originally specified: only the MASTER part of the information (with the number of donations, and total dollar amount of all donations) is displayed for browsing. I discovered this part way through the problem and decided to try to finish as much of the problem as I could rather than try to go back and fix that. The multiple records are displayed in the specified sort order, and the user can browse forwards and backwards on them. Once a MASTER record is selected it is displayed along with all DETAIL records: the DETAIL records are in a scrolling region so that if there are more than will fit on the screen the user can browse forwards and backwards, and they are in correct date order. I did not have time to get to the processing phase or the report phase. I estimate the report would take between one and two hours. 1. Data was loaded into an Rdb database using Datatrieve. Datatrieve was also used later to add the count of detail records and total of donations to the master record. Very little database design or optimization was done other than allocating storage areas for various indices. 2. The count of DETAIL records and the total of donations for each donor were made real fields in the MASTER record, because I thought they would be needed this way. They do simplify some processing, and can act as a validation check on the database. 3. The date of donations was stored as a 64-bit binary VMS date data type. 4. The fund code was retained in the DETAIL records. A database view was defined which linked the FUNDCODE table to the DETAIL table to make it easy to display the fund abbreviation and full name during the browse phase, and I intended to use this table to simplify storing or modifying records. 5. Adding and modifying MASTER records was not done. 6. The MASTER table was indexed on ID_NUMBER, LAST_NAME, and LAST_NAME_SOUNDEX, because records will be retrieved on all of these fields as specified for the problem. The DETAIL table was indexed on ID_NUMBER (because records are matched to the MASTER record this way) and FUND_CODE (which may not actually be needed). The FUNDCODE table was indexed on FUND_CODE because they are retrieved often when matching with DETAIL records, though the table is so small that indexing might not actually be necessary. 7. Modifying or adding DETAILS was not done. Session Reporting Information: 1. The experience of the developer with 3GLs: I have over 15 years experience programming in 3GLs, with about 3 years of programming in C and about 1 year of accessing Rdb from within programs. I had only about 1 month of experience using SMG and ran into a few new problems during the 4GL problem solution. 2. What background knowledge of the user has been assumed: The intention was to provide an application for a user who would already know the intent of the application (donation management), but who would have little knowledge of computers and would receive an hour or so of training with the application. This does not include training the user to log into a VAX system. 3. What training is, or would be required, for the user to operate the browse and processing phases of the application. The browse phase should require less than one half hour of training. 4. What software is required to run the application (all licensed products): To run the product currently requires only VAX/VMS and an Rdb Run-time kit. The license for Rdb-RTO is bundled with VMS. 5. What part or parts of the application is done in a 3GL: All of the application is done in C except for the Soundex algorithm, of which I already had a working routine available in Macro-32. 6. What part or parts of the application could not be done in their 4GL: Everything is possible using a 3GL. 7. How long it took to develop each part of the application Starting with a working database, it took about 9 hours to get to the point where I could select MASTER records by all of the specified methods. This included linking some sample HELP into the first two menus of the application, and some documentation. I also had to fix a few SMG problems I ran into during this time which I probably would have known about if I had been using SMG longer. Adding retrieval of matching DETAIL records took about 4 hours: at this point most SMG problems were solved and most of the work was in testing for error conditions (not trying to retrieve details when there are none, for example). A major problem I encountered is that I had to work on the problems when bits of time were available: mostly in 1/4 or 1/2 hour segments. The only time I could work on it for longer stretches is when I dialed into our system from home, and that meant that I had to work at 2400 Baud, and with no manuals. It also required working on a Zenith / Heath H19 terminal which doesn't do VT100 emulation quite right, and I had to modify some of the SMG screen layouts compensate for this. If I had been able to work on it as a dedicated project I believe it would have taken less time. I would estimate that adding processing for the DETAIL records (add or delete) would take about 1 hour, now that I have all of the problems of working with SMG and Rdb solved. Modifying a record would take a bit longer, as I would have to work out a way to select the fields to be modified (possibly with another menu). Deleting a MASTER record and it's DETAIL records would be fairly simple: probably 1/2 to 1 hour. 8. How long does it take to find and display a single record which has 36 detail records for a system with a specific CPU and disk: With a MV 3500 (equivalent) and RA81 disks, after the first retrieval has been performed, retrieval of a specific MASTER record with 36 DETAIL records (which include full fund names) take less than 1 second. The very first retrieval of any kind is slower as it is at this time that the initial attach to the database is done.