GDDME by Lingo Allegro — Update

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 35

This is effectively an addendum to the ‘first look’ in Vector 10.2. GDDME is an independent task which communicates with Dyalog APL/W via shared variables. It provides a very thorough emulation of IBM’s mainframe ‘Graphical Data Display Manager’ as accessed via AP126 from APL2 and VS APL.

The initial version managed the emulation very solidly, but had a number of interesting deficiencies on the interface front! These all appear to have been fixed at release 2.2 (Dec 93), and the product has acquired some useful extra functionality along the way. I feel it can now be unreservedly recommended as a simple way of lifting a mainframe application and dropping it more or less unchanged on a Windows platform.

Bugs Fixed or Worked Around¶

The problem with non-interlocked shared variables is basically a deficiency of Windows DDE as opposed to mainframe ⎕SVO — I never ever bother to refer to a mainframe GDDM variable after an assignment unless there is some possibility of failure. This speeds things up no end, but unfortunately is not tenable with ⎕SVO on the PC. Accordingly, the rule is now to reference the variable after every assignment, and this is well documented in the GDDME manuals. Here is an amended test function, which works fine:

    ∇ xx;fmt;nmod;rc
[1]   ⍝ Simple GDDME test (X is shared)
[2]   ⍝ Make a simple format and set up screen ...
[3]    fmt←2 5⍴1 4 10 1 24,2 8 10 5 12
[4]    X←(402,(⍴fmt),,fmt)'' ⋄ rc←X
[5]    X←(407 1 4,407 2 3)'' ⋄ rc←X
[6]   ⍝ Fill top field with green underscores ...
[7]    X←(424 1 24)(24⍴'_') ⋄ rc←X
[8]   ⍝ ... and lower field with red dots
[9]    X←(424 2 60)(60⍴'.') ⋄ rc←X
[10]  ⍝ Set Cursor and Hold it ...
[11]   X←(430 1 1 1)'' ⋄ rc←X
[12]   X←(,101)'' ⋄ nmod←⊃X ⋄ 'Read result was: '(5↓nmod)
[13]  ⍝ Query modified fields ...
[14]   nmod←⊃⌽nmod
[15]   X←(420,nmod)'' ⋄ 'Flds to read: '(5↓⊃X)
    ∇

The problems with the imprisoned mouse have been fixed, as has the function-key mapping — shift+F1 reports F13, which I think is the best choice. You now have a choice of colour schemes (set on startup with a b=n parameter) which should cover most requirements. My old DRAW and FSM code all looks quite acceptable with no modification to the colours.

GDDME now uses the MSDOS-CP437 fonts, which are bitmapped at a variety of sizes. This gives a much-improved readability, particularly at the smaller sizes.

Improvements¶

The main improvement is support for screens other than 24 by 80. GDDME accepts r=nn and c=nn parameters on startup, and correctly reports the chosen screen size with FSQDEV. It will run up to 132 columns and 43 rows at a very respectable speed (although a decent PC screen resolution is essential to get the benefit).

The other promised improvement is an implementation as a Windows DLL rather than an independent task. This should make it go a little faster, and I assume it will be as easily called from APL*PLUS III as from Dyalog/W. I do not yet have this version to check.

Remaining Limitations¶

One small thing to check is whether you use the line-draw characters in your mainframe screen layouts. Nestlé certainly do (to put nice boxes around fields), and we will need to convert these to standard ASCII characters as they are not in the MS DOS font.

Apart from this, my only reservation is on the graphics front: should GDDME emulate the GDDM line-styles and shadings? At the moment a request for line-5 (GDDM code for long-dash) gives an invisible line (the Windows interpretation). Similarly the excellent GDDM dog-tooth tweed patterns render as rather tacky Windows hatchings. Perhaps it might be more work for the emulation, but the quality of the finished products would probably be worth it.

Summary¶

There is not a lot wrong with this product if you need to shift a mainframe system in a hurry. Even in its shared-variable implementation it feels faster than any mainframe ever did, and with DLL calls it should absolutely fly. Definitely recommended.