Re: Display file field

On 1 June 2015 at 20:32, Fajardo, Eduardo <eduardo.fajardo@xxxxxxxxx> wrote:

I'm just surprised to know why the data didn't get dropped but instead moved to the next field. A colleague from way back says it is related to what he calls "5250 data stream" which I'm now googling.

Your colleague is almost right.
Here's a simple example.

Display file fields:
CUST# 5
NAME 30

When RPG sends to the screen, it sends 35 characters. The DDS
interprets the first 5 as the customer number and the next 30 as the
name. Which it displays according to the specifications. Now let's
change the program. The two fields are in a data structure (which is
unusual, but that's a different thread...) We make the customer
number 6 long in the RPG and don't compile the DDS.

The buffer in the RPG program is 36 characters long and the buffer in
the DDS in still 35. You send the 36 bytes to the screen and the DDS
interprets the first 5 as the customer number and the next 30 as the
name. But column 6 actually contains the last character of the
customer number, because that's where the RPG program put it. So the
NAME field gets the 'extra' character.

This is the key point: RPG does not send individual fields to the
screen, it sends a single block of data, very much like a data
structure. If you change the DS on one side but not the other, the
field mapping will be all wrong.

I can't say that I have ever had a use for LVLCHK(*NO) on a display file.
--buck