‘device file does not contain an entry for screen size’

IBM i

Aug 09

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.

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.

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:

TEST132.DSPF

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)

TEST132.RPGLE

**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:

TEST132.DSPF

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)

TEST132.RPGLE

**FREE
// 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

exfmt window132;

*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:

TESTWDW80.DSPF

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)

TESTWDW80.RPGLE

**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

Follow

About the Author

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.

  • Michael Eck says:

    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.

  • Michael Delk says:

    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”.

  • Edd Erriccssonn says:

    Same thing here Michael. I’m getting this on a 7.1 box as well.

  • Nick Litten says:

    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.

  • Nick Litten says:

    I have just updated the blog to say this is just a rare condition and not OS related. I have coded DSPF using DS3 and DS4 for years (*cough* decades) as a habit so never stumbled across this problem. Most of the ERP systems I have historically worked with run at 24×80 so using widescreens is fairly rare.

    However, since starting a new gig a couple of months back, one of the main applications is 27×132 but DSPF written by the offshore team pops up 24×80 windows – or fails to in this case – this problem has been happening to nearly a year. Unbelievably, not a single developer, QA tester nor user reported it as a problem. I only found it when testing after OS upgrade and then, mistakenly, assumed it was OS related. #duh

    Lesson learned – “never assume users report errors when they see them” 😉

  • Trutherator says:

    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.

    IIRC…

  • Mario Salgado Montenegro says:

    Thanks, from this Padawan to you Master, to be prepared for an updrade.

  • >