These frequently asked questions and answers address general issues about ASNA WingsRPG. If you'd like to ask a question not listed here, please use this site's "Contact Us" form.

The WingsRPG "stack" uses the IBM i to provide the RPG application/data server and a Windows Web server to provide the presentation layer. At runtime, the IBM Open Access API intercepts workstation file data from RPG programs on the IBM i and redirects that display data to the new WingsRPG presentation layer.

The WingsRPG presentation layer is a Micrsoft ASP.NET Web app. You don't need to write any code to create this Web app. WingsRPG creates its for you and then, using WingsRPG features, IBM i display files (from DDS source) into this Web app. Any one display file translates to a single ASPX page which redefines the display file's record formats into an HTML-based rendering.

WingsRPG translates original record format elements (such as inputs and constants) into IBM i-aware ASP.NET controls. WingsRPG pages obey all original function defintions.

 

WingsRPG imports IBM i display files directly from their DDS source. For each display file member imported a single Web page is created that contains the underlying record formats. WingsRPG provides display file fidelity in two ways:

  1. Display fidelity The WingsRPG display, albeit with its look and feel vastly updated, does its best to display the elements in the same areas of the display. The general operation of he original display, including function keys, is preserved.
  2. Operational fidelity Beyond its display fidelity, the WingsRPG display also has a high level of operational fidelity. The new WingsRPG display obeys all of the conditional indicator-driven rules (eg, input prohibited or cursor positioning) that powered the orginal display. WingsRPG imposes no changes in programming logic in RPG applications.

 

WingsRPG uses IBM's Open Access to intercept RPG workstation file data. This intercepted data is then sent to the WingsRPG presentation layer, which was derived from the DDS display file source definition. The four primary steps that move the workstation file to the WingsRPG UI are shown below.

  1. The RPG program writes to a display file record format--just as it always has. You don't change any logic in your RPG to use WingsRPG. This results in a populated display file record format ready to send to a display file. At this step, the RPG has no knowledge that this record format data will be redirected to the WingsRPG display.
  2. In normal circumstances, the display file record format data is passed to the workstation controller in Step 2. However, the IBM i OS knows that the WingsRPG Open Access handler is registered with the RPG program which causes IBM i to pass the display file record format data to the WingsRPG Open Access handler.
  3. The WingsRPG Open Access handler translates the raw display file record format data into a WingsRPG display file dataset. Unlike typical screen scrapers, WingsRPG does not emit a 5250 data stream. The WingsRPG dataset contains all of the fields in the display file record format, hidden fields, and all 99 indicators.
  4. The WingsRPG browser page receives the WingsRPG display dataset and scatters the field values to the appropriate elements on the page. DDS rules, generally driven by indicator values, are enforced. For example, if in the original display indicator 40 caused a given field to have the cursor position, that same field will have focus with WingsRPG.
The display file record format data is captured from the user by the WingsRPG UI and sent back to the RPG program by reversing these four steps.

When you install the PTF that adds the Open Access API to your IBM i, a Handler continuation keyword for RPG's workstation declaration is also added. This keyword registers an Open Access handler with the RPG program. Having registered an Open Access handler, IBM i knows to redirect display file record format data to the specified handler. This is the only change required for your RPG programs to use Wings--no programming logic changes, special built-in functions, or third-party APIs are required.

WingsRPG requires IBM's Open Access API and that API only works with ILE RPG. If you have RPG/400 (aka RPG III) applications, you could easily use IBM i's CTVRPGSRC command to convert them to ILE RPG for use with WingsRPG and Open Access.

Because of its dependence on IBM i's Open Access API, WingsRPG only supports RPG programs written with ILE RPG. See the question below about how WingsRPG' browser-based emulator gracefully resolves this conflict with COBOL programs.

ASNA BTerm, our browser-based emulator, is packaged with WingsRPG. It provides seamless 5250 emulation for those displays that you can't want, or can't, modernize. Examples of screens you can't modernize are programs written in Cobol or RPG/400 (which if you wanted to modernize, would be easy to do by using IBM i's CVTRPGSRC with programs)

Absolutely not! WingsRPG automates the process of creating the new UI for you. No PC code (ie, C#, VB.NET, or ASNA Visual RPG) needs to be written to modernize RPG applications with ASNA WingsRPG.

The code the WingsRPG ASP.NET Website needs is generated entirely, and automatically, by WingsRPG. The only time you'd need to have some experience with a .NET language is if you intend to make modifications or enhancements to the presentation layer. The degree to which your team would need .NET knowledge in that case is directly related to the sophistication of the UI enhancements you need to make. For simple presentation layer enhancements, including Excel integration and some Ajax enhancements, most of the code you'd need is provided with ASNA examples.

No. ASNA WingsRPG creates an ASP.NET Website for you, out of your choice of either C#, VB.NET, or ASNA Visual. If you select the latter, you'll need a licensed copy of ASNA Visual RPG. Generally, the MS languages are the best choice for shops that don't use ASNA Visual RPG; and, also generally, ASNA Visual RPG is the best choice for shops that use (and therefore already have) ASNA Visual RPG.

WingsRPG works with Chrome and Firefox, and IE 8 and up. While we don't test it on the Mac, we have many customers using WingsRPG apps successfully on Safari browsers on the Mac.

ASNA WingsRPG application work great on tablets. The form factor of even a mini tablet provides good rendering for most traditional RPG applications. This includes running either WingsRPG modernized apps or simply using the ASNA BTerm emulator on a tablet. Using WingsRPG or BTerm on a tablet essentially provides users a great mobile workstation. The general use case the WingsRPG/tablet satisfies are those sitatuations when you need to provide access to existing to existing RPG applications with a "portable" terminal.

WingsRPG displays (again, either modernized displays or those in the BTerm emulator) would most likely also render on a smartphone's browser. However, most of the success of using a WingsRPG app on a smartphone would depend on your expections. We've generally found that apps that traditional RPG applicatons don't work well with smartphones because the workflow the app requires doesn't lend itself well to the smartphone user experience. If you're looking for a way to provide casual mobile RPG application use on a smartphone, WingsRPG would probably be satisfactory. However, we don't think using Wings-modernized apps on a smartphone is a good strategy for heavy-duy mobile users. For that you'd probably be happier with ASNA Mobile RPG.

RPG