Introducing TPF Visual Workshop
by Jeff Robinson
(Part 2 of the "Is TPF Ready For A CASE Tool?" Series)
Imagine this: your boss has just assigned you to a project that must be done within an impossible timeline with very few people (not so hard to imagine, huh?). Very little design has been done but you already know that there'll be a lot of new programs to write and some old ones to update. Around about this time, you start wishing you had taken that job in Albuquerque.
If this situation sounds all too familiar to you, you are not alone. This is one of the side effects of the data processing industry--not just TPF. The computer-services user community comes up with an idea for a brilliant way to increase sales and customers; however, the idea must be implemented on the computer NOW before its stale. The urgency of this implementation is then communicated to the data processing management; these same managers are made to feel that the company has to meet this timelineor risk looking ineffective and inefficient. Finally, all of this urgency trickles down to you. It's do or die time.
RAPID APPLICATION DEVELOPMENT
Tools have been introduced on the market to ease the horror of just this type of situation. They're called Rapid Application Development (or RAD) platforms and they exist mostly on personal computers for client-server applications. Names such as Delphi, PowerBuilder and Oracle come to mind. Although they do NOT follow the original mentality of the traditional CASE tool, they are in essence the de facto CASE tools of the nineties. These applications make use of visual design and programming paradigms that were unheard of and unthought of ten years ago. But best of all--they've been proven to work. Application programmers versed in this technology have shown dramatic improvements in the time it takes to develop programs in comparison to the traditional method (the way we do it now in TPF).
Taking suggestions from readers, friends and co-workers since Part I of this series, I've decided that maybe such a tool for TPF was the best way to go as a step in TPF's need for a paradigm shift. Such a tool as this would not require too large of a mental shift for the average TPFer. Whereas a traditional CASE tool requires a sudden and steep change in programming style and thought, a RAD tool is much more lenient.
TPF VISUAL WORKSHOP
Now, lets go back to our fictitious scenario begun earlier. Suppose you and your teammates go back to your workstations and began designing your application using the graphical design tools of a new RAD application for TPF. I'll describe each part of this tool and how it works as I step you through this scenario.
Object Reference Domain
After analyzing the requirements, the team is ready to declare the object s that will be used in the Object Reference Domain (ORD) tool. What's an object? An object is the data groups your application will be acting upon. In TPF, this may be a fixed or pool file, a general dataset, a TPFDF record, or a DB2 table accessible via TPFAR. Even the ECB maybe considered a pseudo-object. If you have to make changes to an object's structure, you'll be required to "check-out" the object from the Object Reference Library. This will let others know what's changing and who's doing it. Also, this library will contain information on what programs makes references to each object in the library. Just think, if you need to know which programs update that inventory file, you only have to look in this comprehensive library to find your information.
Process Structure Declaration
After you know what data you're going to be accessing, this tool will be used to describe how you modules will interact with one another. This tool will be like the Structure Chart tool utility introduced earlier in this newsletter (see the July 1995 issue). After you're done with this feature, you'll have a graphical view of all programs needing to be created and/or updated in your project. This tool is flexible: you don't have to give a complete picture of all your modules if you're not sure yet.
Program Design Template
Next, you're ready to begin putting together your programs. Remember, this step has to enable you to work more rapidly than you usually would. Thus, the Program Design template allows you to create a "skeleton" of your program from the following sources: previous templates, Reusable Code Libraries, and Design Wizards. What's a Reusable Code Library? It's a library which contains an ordered collection of code snippets, program subroutines, and maybe even whole programs that are commonly used throughout the shop. For example, what TPF programmer hasn't coded the call to FACE numerous times? And its always the same old sequence with a few minor changes:
LA R0,ORDNUM Load Ordinal number
LA R6,RECTYPE Get the record type
LA R7,CE1FA3 Location to place file address
LTR R0,R0 Was there an error?
BZ ERRLBL Yes, go to error label
The Reusable Code library would allow to quickly retrieve this routine and ask you for the new names of those parameters that change (Ordinal number, record type, file address reference word and error branch labels). Then, that snippet of code is inserted automatically in your program template. This same method would be used on subroutines, program sections and even comment blocks stored in the library. What's more, the Code Librarian would keep track of which templates made use of which library entries. If any member the library was changed, the Code Librarian would give a report of which program templates were affected.
Design Wizards would enable you to quickly create new code by stepping you through the design of hard to remember Assembler commands and TPF macro calls. Of course, you'll have the ability to insert brand new code sections in the template and optionally save them to the Code Library as a reusable routine. Don't forget, what you're creating are program templates; these templates will use graphical symbols to reference the program header and end blocks, reusable library code and code inserted by the wizards. This allows you to change the template at will, and to see a high-level overview of the final program and all the code pieces.
Remember the Object Reference Domain? Well, this tool would also ensure that all the code you're using only references objects declared in that area. When you're done with all of your program templates, all you have to do is click "CodeGen" from the main menu and watch your programs and macros be generated automatically. More than likely, you'll probably want to go over the generated code and maybe even "massage" it before you begin testing.
A RAD Sampler
The preceding scenario is how my new utility, TPF Visual Workshop, will work. There's much more to it but time nor space does not permit me to detail everything here. Free trial copies of the complete TPF Visual Workshop should be available by the next issue of this newsletter. If you don't have a subscription to ACP/TPF Today, you'll definitely want to get one so that you can stay directly informed of this revolutionary development in TPF.
For now, if you'll like to have more information and/or a short sample demo of the Visual Workshop application, contact me via the newsletter, by way of the ACP/TPF Today Development Forum on the World Wide Web, or via the Internet at: email@example.com
You can email ACP/TPF Today on the Internet at firstname.lastname@example.org
You can reach the ACP*TPF Today Forums at: http://www.webventures.com/acptpf
Delphi, PowerBuilder, and Oracle are either registered trademarks, trademarks, or copyrighted names of their respective companies. TPF Visual Workshop is a trademark of RobiSoft Development.