2

I'm aware of the existence of DDS files which allow programming of display graphics on the as/400, but is there another way?

Specifically, what I want to do is manipulate the terminal buffer directly to be able to display anything else than just text. For example, the terminal looks like that:enter image description here

Let's say, in memory, there would be a two dimensional char array: text[20][80] for the text menu and lower than that, there would be a pixel buffer array of size [200][800].

Is there a way to access either of those arrays directly? I would like to be able to create a displayable menu entirely in C without the need of a display file and also display other kind of graphics (images) directly in the pixel buffer.

aganm
  • 1,245
  • 1
  • 11
  • 30
  • Are you a developer with command line access? If so, what happens if you enter a STRPTL command and prompt it with F4? Is the command installed? – user2338816 Sep 04 '16 at 00:36
  • @user2338816 Yes I have command line access. The as400 I work with is version V6R1M0. It doesn't have STRPTL command installed. – aganm Sep 04 '16 at 09:50
  • It's not clear what you mean by "graphics", especially with C. Commonly nowadays, it might be a browser UI via Java. If C is **required**, you might otherwise want an X-window display, so look into downloading/installing [IBM Tools for Developers (product ID 5799PTL)](https://www-356.ibm.com/partnerworld/wps/servlet/ContentHandler/pw_com_porting_tools_index). But if you can edit your question, you might explain more of what you really need. – user2338816 Sep 04 '16 at 23:46
  • @user2338816 I did made it a lot clearer. Thank you, my question was indeed underdeveloped. – aganm Sep 05 '16 at 10:59

3 Answers3

5

Is there a way to access either of those arrays directly?

That's easy enough, though a "display file" that has no formatted fields will still be needed. The 'file' will be the connection between the program and the physical device (or the emulator). You can define a single large area that contains whatever "text" you want your program to put into it. This can even include display field attributes that delimit input areas.

For the most control, the DDS USRDFN keyword is appropriate. But for simple stuff like lists of menu items, almost any large text field can be output to.

Outputting simple text is easy. For detailed stuff like USRDFN formatting, detailed understanding of the 5250 protocol is needed.

One kind of alternative would be to use User Interface Manager (UIM) APIs to update a PANEL's "text area" (:TEXT) via its USREXIT= application program. The UIM handles everything as far as any "display file" definition and actual I/O goes. The UIM can be thought of as a HTML interface for 5250 and uses a very similar markup language to define PANELs.

Another alternative is the Dynamic Screen Manager (DSM) APIs. These give much finer control than the UIM or DDS methods (though DDS USRDFN gets very close). But as with USRDFN, actual device control will require 5250 protocol knowledge.

...and also display other kind of graphics (images) directly in the pixel buffer.

There is no "pixel buffer" for 5250 nor even 'pixels'. It's a character-based protocol, like telnet. If you're going for images or 'pixels', you're into browser interfaces, or perhaps Java and NAWT, or X-windows, etc.

Now, granted that with TCP/IP and sockets, you can do essentially anything that you're able to program. Whatever you can figure out how to do, including downloading/installing 3rd-party code libraries, you can do -- within the network restrictions surrounding your server. But it is in fact a server, so GUI kinds of apps generally shouldn't run on it. That's the same as for almost all types of servers. Code the GUI on the client system rather than the server. But you can do it if you really want to.

user2338816
  • 2,163
  • 11
  • 11
  • OS/400 once had Fax support, and a DSPFAX command. It required the raw G4 TIFF data to be converted into a MO:DCA document prior to viewing with CVTFAX. Probably it's not exactly a conversion but a container. According to the older documentation about Fax support, IBM emulators, or graphics capable terminals are required. My guess is that the modern 3479 or a bit older 3486 terminals — being capable of displaying enhanced user interface widgets instead of char based elements — can display Faxes, and thus pixel data, too. I'm not aware of public documentation about that feature, though. – PoC Mar 22 '22 at 19:06
2

I'm not sure why you'd want to do this...

Now-a-days, it'd be much easier to simply generate your output as HTML and serve it up via the integrated apache web server.

But if you really want to do graphics via 5250, it can be done...theoretically at least. In 20+ years on the platform, I've never seen it.

But way back when (1994?), IBM added support for Graphical Data Display Manager (GDDM) and Presentation Graphics APIs into OS/400. "GDDM is a means of displaying, printing, or plotting pictures. Presentation Graphics routines are a means of displaying, printing, or plotting business charts."

The support is still in the OS. However, client side support is NOT available in IBM i Access for Windows or the most recently released client, IBM Access Client Solutions (ACS). It appears that the standalone IBM Personal Communications product may support GDDM.

For complete control of the character buffer, take a look at the Dynamic Screen Manager (DSM) APIs. The DSM APIs are "a set of screen I/O interfaces that provide a dynamic way to create and manage screens for the Integrated Language Environment® (ILE) high-level languages. Because the DSM interfaces are bindable, they are accessible to ILE programs only."

PoC
  • 521
  • 3
  • 13
Charles
  • 21,637
  • 1
  • 20
  • 44
  • I've used GDDM for both print and display. For display, though, you need a graphics-capable 5250 terminal or emulator. The last emulator I'm aware of that did 5250 graphics was the old IBM DOS emulator via SNA. (Maybe color 3279 could work?) Of course, nothing stops someone from writing a modern one. IIRC, GDDM has been native in the OS for a few versions, not requiring installing a separate option or product. – user2338816 Sep 06 '16 at 23:33
  • @user2338816... Yeah, I built a little demo...and it appears that neither ACS nor iAW support GDDM. But it does look like PCOMM might. – Charles Sep 07 '16 at 14:53
  • The IDEAcomm Midrange Client v6.10 (and later) is a very crude 16 bit Windows application, but it supports GDDM when setting the correct terminal type (5292-2). It runs e. g. on Windows 2000. – PoC Jul 01 '23 at 15:47
0

There is a way to do it in ILE C/C++. This was very fun to investigate since I haven't tried it myself.

The only documentation on it (page 183+) I could find is from 5.1, but you are able to cross reference the functions used to this 7.3 manual (possibly page vii/7) to see if they're still used the same.

Hope this helped!

Barry
  • 448
  • 5
  • 10
  • Which function names exactly are you referring to in the ILE C/C++ Programmer's Guide (SC09-2712)? And which functions are you talking about in the C/C++ Runtime Library Functions (SC41-5607)? Your reply leaves more questions dangling than it answers. – PoC Jul 01 '23 at 15:43