Could be 2 things.. Check the DDS code and see what the size is set for.DSPSIZ(24 80 *DS3)   or the other is if you are using client access it may not be set to allow a 132 display. Look under communication then configure and see if it says 27×132 ?

I have everything set as it should be. Client Access 27×132 and the DSPSIZ(24 80 *DS3). As I mentioned the calling screen is a 132 which displays fine. It is only one program that is causing the bomb. Other programs set the same with a DSPSIZ(24 80 *DS3) that are called from the 132 program do not bomb just the new one.

*DS3 isn’t valid for a 132-char display. It should be *DS4, or at least it should include *DS4. — Tom

Okay I added the *DS4 like this and it works (although this specific screen is not using 132) wierd huh? DSPSIZ(24 80 *DS3           –             27 132 *DS4)     Thanks for your time.Paula                                    

Some parts don’t seem to fit together.
 
I am in a screen program which is set to 132 length.
…and:
…(although this specific screen is not using 132)
 
There is a “program”, a display file and a “screen”. The program opens a display file, within which there is at least one screen defined. The DSPSIZ() keyword is a file-level keyword. Programs aren’t “132 length”; display record formats (screens) can be though. A display file that must accomodate a 132-char record format must include *DS4.
 
Some additional detail is missing that would explain it.
 
Tom

If others are working fine with the same settings and only the new one is having an issue I’d check for a duplicate object that may be causing the issue.  Sometimes a programmer may compile a display, accidentally,  to a different library and it will grab what ever it finds first based on your LIBL.

Tom,I apologize for my lingo.. I might have not explained the problem very well. The calling program is an interactive program with a display screen defined with a 132 length screen. In this interactive program there are calls to multiple programs that are also interactive programs which have display files defined with 80 length screen and no reference to 132 length screen. When they are called I am not getting any CPF errors. I have added a call to a new  interactive program where the display file is defined the same but I  was getting the CPF error.(CPF4169). I made the change that was suggested to the display file with 27 132 *DS4 and now it works fine. Just in a hurry explaining. Working on a dead line.. ha!Thanks everyone!

@Paula: There’s no need for apologies. Terms might be clarified at any time by anyone. These threads might be read years later by someone who understands things a little differently, and there are many international members. We’re all subject to being clarified (or corrected) here.
 
When a display file is opened on a device, the device capabilities are checked to ensure that the display file and device are compatible. When PGMA opens DSPFA, the device is checked to be sure that DSPFA can work on this device.
 
Okay, so now PGMA has DSPFA open and then calls PGMB. The first file has set device requirements. If PGMB opens DSPFB, there is a chance that the two file might require different device capabilities.
 
Now, you log on to the system with an emulator that requests a device with basic capabilities, and you get assigned device QPADEV0001. It’s set as a 24×80 device, so DSPFA works fine. But when PGMB is called, DSPFB messes things up.
 
That’s not saying that it happened that way for you. It just illustrates that a given sequence of events can make something work for many users on many days, but might not work for one user on some day who signs in through a different emulator session.
 
The best method might be to assume that a 27×132 device can be needed at any time by any user. Nested programs could contradict requirements. Compile a program and display file with default compile parameters on V5R4, then compile a new program and file with different command defaults (and source defaults) on i 7.1. There’s the chance that they might conflict when the new objects are mixed with old.
 
Job defaults, user defaults, command defaults, compiler defaults… all can potentially change just from a PTF. Explicit lists of attributes can be best. Setting standards for the site is advisable.
 
Tom