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

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:

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.

SOLUTION

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:

DSPSIZ(*DS4 *DS3)