In the old days, AS/400 trends and directions changed slowly (if they changed at all). There was a time when knowledge of CL, DDS, and RPG (or COBOL) empowered a programmer to do everything and anything with the AS/400. Alas, todays AS/400 lives in a changed world: TCP/IP has replaced SNA, Windows desktops are the workstations of choice, new-hire users think green-screen is an environmentally friendly suntan lotion, and everyone wants GUIs.
Today, AS/400 programming teams are squeezed between user demands and management demands for GUIs. Its a no-win situation; either you deliver applications with the user interface that your users demand, or the programmer who takes your place will! Users demand snazzy GUIs because theyre used to using GUIs with their spreadsheets and word processors and because they perceive GUIs as easier to use. Managers and decision-makers want snazzy GUIs because GUIs keep them competitive at the country club, because they also perceive GUIs as easier to use, and because they equate GUIs with modern applications.
Whats an AS/400 programmer to do? Can you leverage your traditional AS/400 programming skills to deliver the kinds of applications demanded of you today? Can you bootstrap what you know about the AS/400 to deliver modern AS/400 applications without investing hundreds of hours of your free time to learn a new programming model? Can you learn to leave SEU behind and still enjoy programming? The answer is a resounding yes!
A handful of Windows-based development environments target the AS/400 for application development. As a category, these tools create Windows executables (EXEs) that connect in real time to the AS/400 database. This article focuses on the RPG skills transference that ASNA Visual RPG (AVR) offers. AVR offers a Windows-based Integrated Development Environment (IDE) powered by good ol RPG. With AVR, you put your RPG skills to work immediately, creating freestanding Windows EXEs with all the bells and whistles the Windows interface has to offer to connect in real time to the AS/400, NT Server, or local PCs.
Is there a learning curve for Windows development? Of course there is, but as this article explains, youre quite likely to be pleasantly surprised at how low that learning curve is. Youll also be amazed at how quickly you can create robust, deployable, line-of- business applications for both Windows and the Web.
Maintaining Your Self-confidence
As you move from traditional AS/400 programming languages to modern development environments, the first speed bump you need to clear is culture shock. Gone are your old friends SEU, PDM, and RLU. At first, if youre like most RPG programmers, moving from RPG to a Windows-based development environment is like hopping from behind the wheel of a VW Beetle into the cockpit of a 747. First and foremost, you mustnt lose your self-confidence because of your early lack of control in the new development environment. Its easy for RPG programmers to take for granted how hard theyve worked to acquire the green-screen development skills they have today. Think back to the period when you were learning AS/400 subfiles; now, there is a tricky technology to master completely. (Does anyone ever really master green-screen subfiles?)
The point is that youve worked hard to learn subfiles. Youll also have to work hard to learn other models of programming. However, it can be done; you already have the basic skill set. Windows programming isnt inherently any more mysterious than working with RPG subfiles. Remember, too, that while you may not be able to render a fractal as well as a PC cowboy can, you have very valuable experience building business applications. (When did you last need to make a general ledger application fractal-friendly?) Concepts such as record locking, appropriate use of indexed files, and subfile knowledge all map directly into Windows programming.
Learning the Event-driven Programming Model
A lot has been written about how most Windows-based application development environments use event-driven programming, so its easy to blow the event-driven programming concept out of proportion. Event-driven simply means that an internal event monitor is implicitly present in Windows programs. This monitor watches for mouse clicks or keystrokes and then directs action to the appropriate chunk of code.
Its often written that, with event-driven programming, the program, not the user, is in control. Nonsense! Polling for a mouse click in a Windows program is no more sophisticated than watching for an F7 stroke in RPG. Event-driven programming is hardly a mysterious Zen science. In fact, although you may not have realized it, youve been doing event-driven programming since day one with CLs Monitor Message (MONMSG) command.
With MONMSG, an event monitor calls the appropriate stub of CL code. Just as MONMSG works with a CL GOTO, Windows programs let you easily associate subroutines with Windows events. In fact, as bizarre as it may seem, all Windows programs have an implicit loop, just as RPG programs do. This Windows loop polls for events (such as buttons being pressed) and implicitly directs code execution to the programmer-provided code for the corresponding event. Imagine a program with two events: an Exit button press and a Find Customer button press. The programmer doesnt write logic for the loop (its there in Windows programs implicitly), only for subroutines that should be activated when the button is pressed. The only thing the programmer does explicitly in this link between the internal polling loop and writing code is to identify, in the code, which subroutine goes with which event.
Learning to Program by Form
Windows applications dont use display files; they use Windows forms. As you create Windows programs, you need to change your mental model of application segregation from display file formats to forms. This challenge actually transforms itself very quickly into a huge visual programming asset because creating forms is done visually by dragging and dropping user interface components on forms. Unlike RPG or COBOL, most Windows programming environments do not separate creating the user interface from creating the application.
In fact, not only do Windows development environments tightly integrate creating the user interface with creating the application, but they also provide built-in debugging and on-the-fly program testing. Beyond being extremely productive, the tight edit/compile/run/debug cycle helps you to overcome visual programming culture shock quickly. Its often as easy to write code and test its behavior as it is to check documentation.
Understanding Database Access
Another huge challenge of creating Windows-based applications is mastering typical Windows database access methods. These are the three most widely used ways to connect Windows applications to the AS/400:
ODBC. For ad hoc query and reporting use, ODBC is a de facto standard. Unless you use ActiveX Data Objects, ODBC requires programming with a complex set of APIs; for the best performance, you should also use OS/400 stored procedures. ODBC drivers are very mature, and 25 major database platforms currently support ODBC databases access.
OLE DB. OLE DB is the follow-on technology to ODBC. It uses an object-based programming interface (as opposed to ODBCs API interface). OLE DB is quickly becoming the de facto standard for cross-platform database access. However, the quality of OLE DB access is directly proportional to the quality of the OLE DB database provider (OLE DBs analog to an ODBC driver).
Record-level access. Many Windows-based AS/400 application development environment eschew both ODBC and OLE DB for database access. These environments all use a variation of an AS/400-hosted server program tightly coupled to the Windows environment. With AVR, all of your RPG data access techniques (i.e., CHAIN, SETLL, READ, and UPDAT) work unchanged.
In addition to making AS/400 database access easy, AVR also makes cross- platform applications a snap. By deploying AVR's Acceler8DB (ADB) database on NT Server or local PCs, you can, at runtime, easily point your AVR application to any of the three supported database locations (AS/400, NT Server, and local PCs). This database support is identical across the three platforms. Through ADB's interactive user interface, you manage the databases independent of their platform locations. AVR's multiplatform support makes it easy to deploy NT Server or local PC versions of what would otherwise be typically considered an AS/400-only application. Many AVR customers use AVR to create NT Server-specific applications.
Using Components to Build Software
Most Windows development environments make extensive use of Windows ActiveX controls. ActiveX controls are components you drag and drop into your application and are most widely used to provide user interface widgets such as buttons or input fields. However, an ActiveX control occasionally doesnt provide a user interface, as is the case with a timer control or custom control written to include business logic.
Green-screen programming has no direct analog to Windows component-based architecture. ILE service programs, with their inherent reusability, are perhaps the best RPG concept mappable to ActiveX controls. To create a display file in RPG, you must first handwrite the DDS and then handwrite the RPG code to fill the subfile. AVR and most other Windows programming environments use ActiveX controls to create user interface widgets. For example, AVR provides a subfile control that, using drag-and-drop capability, is placed on a form. There, you assign it properties (such as the column widths and number of rows) and add event-driven code to fill the subfile.
Most Windows development environments also allow you create ActiveX controls. Thus, you could use a tool such as AVR or Visual Basic to create a file-specific subfile
control for your customer master file. Once created, you could easily drop that file-specific subfile control into 10 different programs.
Another thing that ActiveX controls do for you is to enable specialized, sophisticated user interfaces. One programmer used third-party ActiveX controls to add mapping and geo coding to his AS/400 law enforcement dispatching application. Adding these mapping facilities to a green-screen application would be all but impossible.
Taking Your Applications to the Web
You dont need to be told how important the Web is today. Virtually every organization wants some part of its business put on the Web in some fashion. Because of the popularity of the Web, almost every AS/400-Windows development tool offers some way of putting AS/400 data on the Web. AVRs method is to support Microsofts Component Object Model (COM), the low-level interface through which Windows processes communicate. With AVR, you can use your RPG skills to create AVR COM objects that build superb interactive Web sites.
Build for Today, but Prepare for Tomorrow
As an RPG programmer looking to move beyond host-based RPG, remember to think long-term. Its important to select a tool that helps you to create deliverables for your business quickly and to prepare you personally for the future. Although such features may seem way off to you now, you should factor in Web-based development capabilities, cross-platform database access, and tool extendability. Dont waste your time with stopgap solutions; focus on those that can serve as long-term enterprise application development tools.
An old RPG dog can learn new tricks. Its simply a matter of selecting new development tools that let you leverage your existing programming skills and are sophisticated enough to let you build next-generation applications.