Subfile Interaction with other Display Files

5 pts.
IBM iSeries
I am trying to write my first subfile program. I thought I could use a subfile to display a file and allow users to select a record from that file to update a field in another file. In my case I'm maintaining client data and have a file with languages (English, Spanish, etc). I would like to user to be able to select the code from the subfile and populate the language code on another Display File and eventually the client's record in the client master file. I have other fields to be updated in this program but when I run the job I get my initial client data screen, press a function key to get my language subfile, select a language (and whether I press Enter or a Function Key I set up to get back to my original screen I just get kicked out back to my client selection screen. How is the subfile supposed to return control to the original screen with the client data on it?

Answer Wiki

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


Is this all in one program? Are you using the same field names?


Martin Gilbert.

Discuss This Question: 1  Reply

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.
  • Sloopy
    This sounds like a flow-of-control issue. You first show a subfile containing Client records. User selects a Client record and sees that record on a screen. User presses a function key to show the language subfile. Now, whatever function key is pressed, the user is back at the client record selection subfile. As Martin asked, is there more than one program involved in this? If so, how do you go from one program to the next? Often, with applications like this, the first subfile selection is (say) Program A. This program may also have the screen that shows the selected Client record. But Program B contains the language subfile. The proper way to call Program B from Program A is from the subroutine that contains the Client detail screen. Then control returns to that point when Program B ends. Program B MUST pass back a parameter containing the information to be updated. As an aside, the easiest way to do this is by passing a parameter which is an externally-described renamed data structure, based on the record to be changed. When Program A get control back from Program B, it must check what the user wanted to do from Program B - again, as an aside, Program B will return a return-code parameter to say : a) User changed data, and the changed data is passed in a parameter b) User did not change anything If (a), then Program A must act on the user changes, and then will redisplay the Client detail screen. Usually, this screen is in a loop which the user ends by pressing a function key which will either return her to the client selection subfile or back to the menu (that is, leave Program A). So, check how you are calling Program B, and make sure you are not ending the loop around the detail screen until the user wants to end it. Of course, this is the preferred method. But it's also possible that you are ENDING Program A and then calling Program B; then ending Program B and calling Program A again. This makes things more difficult, and can easily lead to the effects you describe. Unless there is some really good reason for doing it that way, you should alter the code to make Program A call Program B directly. Sloopy
    2,195 pointsBadges:

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.

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


Share this item with your network: