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.
UPDATE AUGUST 2018: Things are not always as they seem!
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.ME MUTTERING “Dont blame the Operating System, blame the sloppy programmers” 🙂
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*
Luckily this is easy to fix – simply tell the DSPF that it can handle both 24×80 (known as *DS3) and 27×132 (*DS4) screen sizes.
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 I feel like I’ve done my good deed for the day 😉
Here is some DDS & RPG code to reproduce the problem
I created a dummy DSPF called TEST132.DSPF which is just a 27×132 screen which CALLS two programs to display windows over it:
- TESTWDW132 – Display a 27×132 window (as if you hadnt guessed) and
- TESTWDW80 – Display a 24×80 window (well it would, if it didnt splutter, cough and explode)
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;
and of course… drum roll please… the code that explodes if you try to the same thing with a file that is defined as 24×80 or *DS3 as the nerds like to call it:
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.
Always code *DS3 and *DS4 in DSPF that will be overlayed as a window using ASSUME. 🙂
Define both screen sizes as standard in every DSPF you code.
This means you display file will happily display on both screen sizes:
What release were you on before 7.3? We get this error when the IBM i Access Session is set to 24×80 and a 27×132 screen is called. So your experience is a little different than ours, but the same CPF4169 error. We are on 7.1.
We’ll be making the jump from 7.1 to 7.3 in the next month or so. Therefore, I’m now searching all the codebases for the string “DSPSIZ(24 80”.
We just recently went from V7r1 to V7r3 and this exact problem happened to me on the development syste
I changed the DSPSIZE on the dds to the following
DSPSIZ(27 132 *DS4 24 80 *DS3)
Another guy in my shop had this issue, and we are on 7.2. I don’t think it’s new… at least I think it’s the same issue. 24×80 in one program, calls another with help text that uses 27×132. I don’t think they were even the same program.
He had to do two display file opens in a caller program. Added a 27×132 display file to be able to call the other program.
Thanks, from this Padawan to you Master, to be prepared for an updrade.
Good coding practice — if coding a DSPF using the ASSUME keyword then always add DSPSIZ(*DS3 *DS4). This means that it will display regardless of wether its called from a 80 column or a 132 column screen layout.
Thanks a lot!!
Thanks for this – been head scratching for a while over this and just by adding that extra little *DS4 information its (magically) solved the 4169 issue. Brilliant.
Ahhh You are welcome! I am in the habit of using DSPSIZ(*DS4 *DS3) in every DSPF I code nowadays 😉
Nick, one further question off the back of this. My initial display is 27×132, and my window is 24×80. When the window is shown, the previous siren is no longer visible (ie blank screen behind the window). I have the ASSUME keyword in a “dummy” record format on the window display file. Is there anything else I may be missing?
No – this is a problem with switching screen sizes… I’ve seen the same thing! It will not overlay a *DS3 over a *DS4. If you change your WINDOW DSPF to include a layout at *DS3 (24×80) and also the same window using *DS4 that might solve the problem.