Format Level Identifier

45 pts.
Tags:
AS/400
Display File
DSPF
Format Level Identifier
RPG Program
Dear All,
I am having and Display file, and  i want to change the some header on that file. The Problem is that i dont have the source file of the RPG program which is using the display file. Is it possible change and compile the DSPF without changine the File Level Identifier, if yes, How??
Your swift action is highly appericiated :)
Regards
Praveen


Software/Hardware used:
iSeries

Answer Wiki

Thanks. We'll let you know when a new response is added.

You can compile the DDS with Level Check NO. This will only work if you are changing the constants on a screen and data field changes will cause problems. Make sure you have a back up of the object before you try this.

Discuss This Question: 9  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    ...without changine the File Level Identifier... The "File Level Identifier" is not important for this. But you wrote "Format Level Identifier" in the question subject, so I assume that you know the difference. Without seeing what you are changing, we can't tell. Please show the original lines from the DDS source and then show the changed lines. The format level identifier is a kind of 'signature' that is generated from the field definitions in the I/O buffer for the record format. Its purpose is to identify the data types, data lengths and order of the fields in the I/O buffer. The program needs to know that the fields will be in the same positions when the program runs as when the program was compiled. If the DSPF put a field in a different place in the buffer, the program would access the wrong part of the buffer when it tried to access the field. If the DSPF put a different data type or data length into the buffer, the program would read invalid or unexpected values. The format ID is embedded in the program at compile time. You can see the format IDs in the program by running DSPPGMREF. You can see format IDs in a file by running DSPFD or DSPFFD. You can compare them by looking at them. You can change many things about a DSPF without changing its format IDs. For example, you can change constant text fields, either changing the text, the length or the position on the display. You can add and remove constant fields. You can change the positions on the screen for any of the fields on the screen. But you can't change the order that the fields are defined in the source because the order determines the order in the buffer. You can't change the length of an input or output field. That would cause a change in the I/O buffer because other fields would need to be moved to different parts of the buffer to account for the new length. You can always compile a copy of the DSPF into a test library and look at the new format IDs. If they didn't change, then you can use the new DSPF without recompiling the program. Tom
    125,585 pointsBadges:
    report
  • TomLiotta
    Come to think of it, if you can't recompile the program, then you probably aren't changing the definitions of any input or output fields. You are probably only changing text constants on the screen or changing line and/or column positions. As long as you don't rearrange the order of the input/output fields in the DDS source, you will probably be okay. Compile into a test library first, and review the format IDs to make sure they didn't change. As long as they stayed the same, you should be fine. If they change, let us know exactly what was different. It's a good idea to keep a spare copy of the unchanged DDS. Tom
    125,585 pointsBadges:
    report
  • PPR
    Dears, to be more precise. I have a display file and it has a Heading - our company name-- say XYZ Company Now the company name been changed to ABC Company, How can i incorporate this change in the display file without compiling the Source of display file. Also please note that i don't have the source file for the RPGLE
    45 pointsBadges:
    report
  • philpl1jb
    Are you saying that you don't have the source of the display file, either? Is this hardcoded in the display or loaded by the program from a file or data area? Phil
    49,720 pointsBadges:
    report
  • PPR
    i do have the source of the display file. I dont have the source of the RPG program which is using the file. also the company name is hard codded in program.. Please help
    45 pointsBadges:
    report
  • Splat
    Is the company name on the display a variable provided via the executing program or a constant defined in the DDS? If the former, you'll need to determine where the program derives it from (if possible). If the latter, Tom has the right of it. If necessary, retrieve the DDS for the display to determine the current buffer layouts (see this thread for more information on how to accomplish that).
    7,035 pointsBadges:
    report
  • philpl1jb
    So as I understand it, your RPG program is sending the company name as a variable to your display file which is displaying it as an output field. 1. add the keyword DSPATR(ND) which will cause this field to not display but shouldn't change the record format 2. add the company name as a text entry in the display file .. I think you will need it to start a character before the postion of the old field. But put it in the display file after the current field. Adding text, as Tom advised won't change the record format. Spin your chair around twice, pat your head and rub your stomach. Phil
    49,720 pointsBadges:
    report
  • Splat
    PPR, sorry. I skimmed that last comment and missed your note about the source of the company name. I think Philpl1jb has the right of it.
    7,035 pointsBadges:
    report
  • TomLiotta
    Show us the lines that need to be changed in the DDS. If you're very lucky, the field will have a MSGID() keyword, which is possibly what it should have. If it does, you won't need to recompile anything -- just change the indicated message description. But that's probably hoping too much. Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following