In V2R3, a set of bindable OS/400 APIs called Dynamic Screen Manager (DSM) APIs became available, giving programmers a higher-level interface to the previously tedious method of 5250 data stream programming. Like 5250 data stream programming, DSM APIs provide the ability to dynamically read and write screens without the use of DDS display files or User Interface Manager (UIM) panel groups. The main advantage of this type of programming is that it allows you to dynamically build screens at run time rather than statically build screens at design time. However, because these APIs are bindable, they can only be used by ILE languages.
In V2R3, the only language that could be used with the DSM APIs was ILE C/400. In V3R1, with the release of RPG IV (which operates in the ILE environment), these APIs became accessible to RPG programmers. To demonstrate how these APIs can be used in an RPG program, I wrote the example shown in 6. The purpose of this program is to display the message "Hello World!" in the center of the screen. While it's not a particularly useful program, it does provide you with a starting point to build your own programs using these APIs.
In V2R3, the only language that could be used with the DSM APIs was ILE C/400. In V3R1, with the release of RPG IV (which operates in the ILE environment), these APIs became accessible to RPG programmers. To demonstrate how these APIs can be used in an RPG program, I wrote the example shown in Figure 6. The purpose of this program is to display the message "Hello World!" in the center of the screen. While it's not a particularly useful program, it does provide you with a starting point to build your own programs using these APIs.
To give you a better understanding of how this program works, I'll briefly explain the purpose of the various API calls. The program starts by calling the Create Command Buffer (QsnCrtCmdBuf) API. A command buffer is simply an area in memory where subsequent DSM API calls will place instructions until the API that "puts" the command buffer is called to execute those instructions. The Create Command Buffer API returns a handle that is used by the subsequent DSM API calls to locate the address of the buffer.
Next, the program calls the Clear Screen (QsnClrScr) API to place instructions into the command buffer that will clear the screen. The third call is to the Write Data (QsnWrtDta) API, which puts instructions into the command buffer to write data to the display. The data to display, as well as the row and column to display it at, are passed as parameters to this API. The next API call is to the Put Command Buffer (QsnPutBuf) API to execute the instructions that reside in the command buffer. At this point, the data is written to the screen. However, the program doesn't stop to wait for user input. Instead, it continues to execute. That's the reason for the last API call, which is to the Get AID (QsnGetAID) API. This API stops the program and waits for user input before continuing.
That's a quick overview of a sample program that uses the DSM APIs. Many more DSM APIs are available for you to try writing this type of code yourself. You'll find them documented in OS/400 System API Reference V3R1 (SC41-3801, CD-ROM QBKAVD00).
- Robin Klima
TechTalk: Getting started with the ILE Dynamic Screen Manager APIs.
Figure 6: Sample Program Using the DSM APIs
*=============================================================== * To compile: * * CRTBNDRPG PGM(XXX/DSM001RG) SRCFILE(XXX/QRPGLESRC) + * DFTACTGRP(*NO) * *=============================================================== *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 D Size S 9B 0 INZ(4500) D Increment S 9B 0 INZ(50) D BufHandle S 9B 0 D Mode S 1A INZ('0') D Data S 12A INZ('Hello World!') D DataLength S 9B 0 INZ(12) D Row S 9B 0 INZ(13) D Column S 9B 0 INZ(35) * Create command buffer C CALLB 'QsnCrtCmdBuf' C PARM Size C PARM Increment C PARM *OMIT C PARM BufHandle C PARM *OMIT * Clear screen C CALLB 'QsnClrScr' C PARM Mode C PARM BufHandle C PARM *OMIT C PARM *OMIT * Write data C CALLB 'QsnWrtDta' C PARM Data C PARM DataLength C PARM *OMIT C PARM Row C PARM Column C PARM *OMIT C PARM *OMIT C PARM *OMIT C PARM *OMIT C PARM BufHandle C PARM *OMIT C PARM *OMIT * Put buffer C CALLB 'QsnPutBuf' C PARM BufHandle C PARM *OMIT C PARM *OMIT * Get AID key C CALLB 'QsnGetAID' C PARM *OMIT C PARM *OMIT C PARM *OMIT C EVAL *INLR = *ON
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online