For example, when you have an interactive program (PGMA) that calls another interactive program (PGMB) that uses a different display file, when control is returned to PGMA from PGMB, if the display file for PGMA does not have RSTDSP(*YES), you could possibly receive this error.
Here's what the OS/400 V5R1 CL Reference manual has to say about it:
RSTDSP
Specifies whether data being shown on a display by this display file is saved at the time the file is suspended (made temporarily inactive) so that another display file can show different data on the same device. If the data for this file is saved, it is restored to the display of the device when the file is used again.
*NO: The data being shown by this file is not saved when the file is suspended. When control is returned to the programs using this file, the data is not restored.
*YES: The data being shown when the file is suspended is saved so it can be shown on the display when the file is used again."
So, how can a setting of *NO cause the "Data sent to device not valid" error?
Well, the answer to that question is buried in another iSeries manual that gets very little use (at least in my shop): Application Display Programming (SC41-5715). In the manual, refer to the section entitled "Saving Previously Displayed Information" (chapter 3, page 43). There, you will find that when the second display file was written to the display device, the first display file was suspended. The reason the error occurs when you return to the calling program is because, if not programmed properly, the program attempts to access the display file before completely rewriting the whole display.
You have two options that you can follow to avoid this problem:
1. Follow the instructions in the Application Display Programming manual on how to avoid this problem (seems like too much work for me).
2. Change the Create Display File (CRTDSPF) command default for RSTDSP from *NO to *YES and forget about it. Don't forget to change the default after each OS upgrade! This is typically what most iSeries shops that I am aware of choose to do.
Be aware that, according to IBM, setting RSTDSP(*YES) causes a "significant system and data transmission overhead" because approximately 3,000 bytes of data must be transmitted between the system and the display device. However, in this modern age of high-speed connections, you'll probably never notice the delay caused by transmitting the data, nor the extra load on your system.
In my opinion, the convenience of not having to worry about whether a display file should be RSTDSP(*YES) or RSTDSP(*NO) for each interactive program that I write far outweighs the performance implications. The one caveat to this is if you are working at an installation where there are a lot of remote devices connected to the iSeries via a slow connection. In this case, it might be worthwhile for you to go through the extra effort to make your programs function properly with RSTDSP(*NO).
John Fox is an IT Project Manager for MSC Industrial Supply Co. He can be reached by email at
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