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

The Wings "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 Wings presentation layer.

The Wings presentation layer is a Micrsoft ASP.NET Web app. You don't need to write any code to create this Web app. Wings creates its for you and then, using Wings 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.

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


Wings 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. Wings provides display file fidelity in two ways:

  1. Display fidelity The Wings 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 Wings display also has a high level of operational fidelity. The new Wings display obeys all of the conditional indicator-driven rules (eg, input prohibited or cursor positioning) that powered the orginal display. Wings imposes no changes in programming logic in RPG applications.


Wings uses IBM's Open Access to intercept RPG workstation file data. This intercepted data is then sent to the Wings presentation layer, which was derived from the DDS display file source definition. The four primary steps that move the workstation file to the Wings 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 Wings. 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 Wings 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 Wings Open Access handler is registered with the RPG program which causes IBM i to pass the display file record format data to the Wings Open Access handler.
  3. The Wings Open Access handler translates the raw display file record format data into a Wings display file dataset. Unlike typical screen scrapers, Wings does not emit a 5250 data stream. The Wings dataset contains all of the fields in the display file record format, hidden fields, and all 99 indicators.
  4. The Wings browser page receives the Wings 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 Wings.
The display file record format data is captured from the user by the Wings 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.

Wings 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 Wings and Open Access.

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

ASNA BTerm, our browser-based emulator, is packaged with Wings. 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! Wings 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 Wings.

The code the Wings ASP.NET Website needs is generated entirely, and automatically, by Wings. 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 Wings 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.

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

ASNA Wings 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 Wings modernized apps or simply using the ASNA BTerm emulator on a tablet. Using Wings or BTerm on a tablet essentially provides users a great mobile workstation. The general use case the Wings/tablet satisfies are those sitatuations when you need to provide access to existing to existing RPG applications with a "portable" terminal.

Wings 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 Wings 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, Wings 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.