Upgraded our IBM i systems to IBM i V7.3 yesterday and so far everything is running nicely except for this one weird little glitch: some of the existing DDS WINDOW SCREENS are bombing with CPF4169 The device file does not contain an entry for screen size when they seem to have been quietly working for years, decades, eons.
After feedback from several IBM i Propeller heads, who tested this at various levels of IBM i, we can confirm this problem can be reproduced at previous levels, so its not related to IBM i. This is just a sloppy coding practice that nobody had ever reported as a problem. It was only reported after the IBM i 7.3 upgrade and reported to be happening everywhere! “Yikes” I thought – 7.3 has blown this up. But after lots of digging that is just not the case.
LESSON “Dont blame the Operating System, blame the sloppy programmers” 🙂
SPOILER “Always code *DS3 and *DS4 in DSPF that will be overlayed as a window using ASSUME”
Now, these old screens are sometimes crashing on open with this error:
After much head scratching – I found what appears to be a feature in IBM i V7.3
If you use DSPSIZ(24 80 DS3) and use the ASSUME KEYWORD on a format… when the format is displayed after being called from a 27×132 screen, it fails with “The device file does not contain an entry for screen size.”
This is basically saying — the ASSUME keyword is assuming that the 24×80 Window *DSPF is on the screen but because it’s being called from a 27×132 screen it cannot assume that so … *BOOM*
Lets document it, since I googled/binged/yahood without any success trying to find what this was.
If it helps someone else in the #IBMi community then cool beans.
I created a dummy DSPF called TEST132.DSPF which is just a 27×132 screen which CALLS two programs to display windows over it:
Here is the source:
A DSPSIZ(27 132 *DS4) A CA03(03) A R BASESCRN A CA07(07) A CA08(08) A 2 4'This is a sample screen pretending- A to be a 27x132 format base screen - A something like order entry or other- A fat screen' A DSPATR(HI) A 12 4'Press F7 to call a 27x132 window u- A sing assume' A 50 12 51'27X132 bombs under IBM i 7.3' A DSPATR(RI) A DSPATR(BL) A 14 4'Press F8 to call a 24x80 window us- A ing ASSUME' A 51 14 51'24X80 bombs under IBM i 7.3' A DSPATR(RI) A DSPATR(BL) A MOUSECLICK 2Y 0B 25 3PSHBTNFLD A PSHBTNCHC(1 '>Enter') A PSHBTNCHC(3 'F>3 Exit' CA03)
**FREE // This is a sample program to reproduce the problem encountered after upgrading to IBM i 7.3 // This code style works fine with all previous releases of IBM i // // Overview: // // if you use DSPSIZ(24 80 DS3) and use the ASSUME KEYWORD on a format... when the format is // displayed after being called from a 27x132 screen, it fails with "The device file does not // contain an entry for screen size // // Work around Solution // // We can resolve this problem by removing the assume keyword or by adding DSPSIZ(*DS3 *DS4) and // recompiling the DSPFILE but they have been working before V7R3. // // Permanent solution // // IBM need to provide a software fix to allow ASSUME keyword to function as it did on previous // // FUNCTION OF THIS CODE // Here we are displaying a screen using 27x132 dimension *DS4. This DDS is called TEST127 // This code will display two further DDS files: // TESTWDW80 - a sample WINDOW DSPF using ASSUME and size *DS3 // TESTWDW127 - a sample WINDOW DSPF using ASSUME and size *DS4 // This technique has been used for decades (prior to IBM's nice WDW keywords) // // Pressing F7 will display a 127 window - which ASSUMES over the existing 127 screen // Pressing F8 will *BOMB* using a 24x80 window because the ASSUME cannot find its screen size // // Author ............. Nick Litten // Date coded ......... August 9th 2018 ctl-opt copyright('| TEST127 2018.09.09 V001'); dcl-f TEST132 workstn; // base screen in 27x132 which will call the windows dcl-pr dsp27x132 extpgm('TESTWDW132'); end-pr; dcl-pr dsp24x80 extpgm('TESTWDW80'); end-pr; /title mainline for TEST132 - POC for IBM i crashing when detecting incorrect scrn size with ASSUME dou *in03; exfmt basescrn; // reset error messages *in50 = *off; *in51 = *off; // if PFkey(07) then attempt to display widescreen widow if *in07; monitor; dsp27x132(); on-error; // if 27x132 window bombed then display error *in50 = *on; endmon; endif; // if PFkey(08) then attempt to display widescreen widow if *in08; monitor; dsp24x80(); on-error; // if 24x80 window bombed then display error *in51 = *on; endmon; endif; enddo; *inlr = *on;
as you can see – this code will call two window programs.
The first is a 132 wide screen – which happily works because the 132 screen can ASSUME itself over the top of the previous 132 screen:
A DSPSIZ(27 132 *DS4) A R WINDOW132 A ASSUME A BLINK A OVERLAY A 5 5' - A - A ' A DSPATR(RI) A 6 5' ' A DSPATR(RI) A 6 7'This is an example window using AS- A SUME to overlay the previous screen- A . This is defined at 27x132' A 6105' ' A DSPATR(RI) A 7 5' ' A DSPATR(RI) A 7 7' - A - A ' A 7105' ' A DSPATR(RI) A 8 5' ' A DSPATR(RI) A 8 7'Press ENTER TO RETURN - A - A ' A 8105' ' A DSPATR(RI) A 9 5' - A - A ' A DSPATR(RI)
// just display an old fashioned fake window using OVERLAY and ASSUME
// Size………. 27×132
// Author …………. Nick Litten
// Date coded ……… August 9th 2018
ctl-opt copyright(‘| TESTWDW132 2018.09.09 V001’);
dcl-f TESTWDW132 workstn; // 27×132 window with ASSUME
*inlr = *on;
A DSPSIZ(24 80 *DS3) A R WINDOW80 A ASSUME A BLINK A OVERLAY A 5 5' - A ' A DSPATR(RI) A 6 5' ' A DSPATR(RI) A 6 7'This is an example window using AS- A SUME to overlay' A 6 57' ' A DSPATR(RI) A 7 5' ' A DSPATR(RI) A 7 7'the previous screen. This is defin- A ed at 24x80 ' A 7 57' ' A DSPATR(RI) A 8 5' ' A DSPATR(RI) A 8 7'Press ENTER TO RETURN - A ' A 8 57' ' A DSPATR(RI) A 9 5' - A ' A DSPATR(RI)
**FREE // just display an old fashioned fake window using OVERLAY and ASSUME // Size.......... 24x80 // // Author ............. Nick Litten // Date coded ......... August 9th 2018 ctl-opt copyright('| TESTWDW80 2018.09.09 V001'); dcl-f TESTWDW80 workstn; // 24x80 window with ASSUME exfmt window80; *inlr = *on;
So this source code should help you, dear reader, the reproduce the same problem.
NOTE Scratching my head here. So we have approx 15 windows that have this problem “they are defined as 24×80 ASSUME windows and fail overlaying existing 27×132 screens from Agilysys LMS” But after talking to many users, and trying to reproduce the problem in our test LPAR it seems that this problem (failing to overlay a 24×80 window over a 27×132 screen) has been out there for a long time… but unbelievably it was never found in any QA/TSTing nor has any user ever reported it as a problem. #seriously. Apparently, I am the only person to ever document this error on our production system. :rolleyes So lesson learned. Always code *DS3 and *DS4 in DSPF that will be overlayed as a window using ASSUME. 🙂
ME - after testing on 7.2 and 7.1 boxes
IBM i Software Developer, Digital Dad, AS400 Anarchist, RPG Modernizer, Alpha Nerd and Passionate Eater of Cheese and Biscuits. Nick Litten Dot Com is a mixture of blog posts that can be sometimes serious, frequently playful and probably down-right pointless all in the space of a day. Enjoy your stay, feel free to comment and in the words of the most interesting man in the world: Stay thirsty my friend.
Using QSNRTVMOD to find the last displayed screen size
Handling Fat screens in RPG with IBM i API’s QsnQryModSup and QuiLngTx
IBM i 5250 Screen Sizes – Widescreen for the Win!
Forget MAGA Vote MGWA – Make Greenscreen Wide Again
How to update RDi – Rational Developer for IBM ‘i’ Programmers
Cleaning messy IBM i Integrated File System (IFS) file names