I really have no issues about the LVLCHK(*NO) as I'm fully aware of it being set to no and that it has its own purpose in the scheme of things.

I am just curious to know why the program/display did what they did. I may have encountered this before but I guess I didn't pay attention to it or just corrected the installation/deployment and never really asked why it happened, until now. Your explanation clears up that one for me. Thanks Marvin.




-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Marvin Radding
Sent: Tuesday, June 02, 2015 1:08 AM
To: 'rpg400-l@xxxxxxxxxxxx'
Subject: Display file field

Eduardo,

Your display file was compiled with LVLCHK(*NO) otherwise the program would not have work because the difference between the size of the field in the program and the display file would have generated a CPF4131 error. Under the circumstances you describe this is the behavior when there is a disagreement between the program and the display file. What you need to understand is that the program prepares the display record with only the data that is needed, in this case the field you described and the others following it. When the program sends the buffer to the screen manager, it extracts the data in the display record according to the field descriptions in the display file. This is the reason why the field was not truncated. The extra character was extracted as part of the next field as you indicated in your description of the problem. The only work around that I am aware of is revert back to the previous program that has the same display file description. Otherwise promote the new display file ASAP.

Thanks,

Marvin

message: 2
date: Mon, 1 Jun 2015 08:35:18 +0000
from: "Fajardo, Eduardo" <eduardo.fajardo@xxxxxxxxx>
subject: Display file field

Hi,

I have a program and a display file. A screen field, say CCCCCCC, is defined in the display header format as 7char. The same field is defined in the program DS as 7char, initialized to a certain value.

I am working on a project which aims to increase the length of field C from 7 to 8 so I changed and recompiled the program as well as the display file. I forgot to deploy the display file and went on to test the new changes which means I am now using the latest program(8char fieldC) over an old display file (7char fieldC). Initially, I assumed it will just drop/truncate the last character. I was wrong. The last character of field C was placed in the next field and the rest of the fields in the screen format moved a character to the right as seen below.

I know it is best practice to deploy both but given this instance, I'd like to know if this is the correct behavior. If so, are there workarounds aside from deploying the latest display file?




Before

FldA FldB FldC FldD FldE
PGMNM ENQ XXXXXXX TITLE CCYYMMDD <-- Data value


After

FldA FldB FldC FldD FldE
PGMNM ENQ XXXXXXX XTITL ECCYYMMD <-- Data value

"Misys" is the trade name of the Misys group of companies. This email and any attachments have been scanned for known viruses using multiple scanners. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing.


Notice: This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. This message may also contain Protected Health Information (PHI) and must be treated confidentially and handled in accordance with HIPAA and other federal and state privacy laws. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately and delete this e-mail (and any accompanying attachments).
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.

"Misys" is the trade name of the Misys group of companies. This email and any attachments have been scanned for known viruses using multiple scanners. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.