AS/400: Read multi-member physical file in RPGLE

450 pts.
Tags:
AS 400
AS/400 physical file
RPGLE
What is the use of multi-member physical files? How can I read a multi-member physical file in RPGLE?
1

Answer Wiki

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

I worked for a company years ago the had multi member files. There were members like PROD, TEST, ENG, DEV.

Not our decision, it was prepackaged software. 

PROD was for production work, TEST for programmer code testing, DEV for the product development team and ENG for the product engineers. 
This was so we could have data unique for each business sector. It prevented us from changing the data that did not belong to us, It was also a pain to code for. You had to do a lot of OVRDBF commands to point to the correct member to use. It would have been much easier to just have a duplicate file in another library that could be controlled by a JOBD or LIBL. 
The other issue is if you have a system or file crash, it takes them all down until recovered or restored. 

Discuss This Question: 12  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.
  • TheRealRaven
    The use is to have multiple members. Avoid them for database files; it's better to have a column identifier that partitions the rows. You read them in RPG exactly as you read any database file.
    35,090 pointsBadges:
    report
  • Splat
    Multi-member files are particularly useful for work files, allowing multiple jobs to access the same file while keeping the data isolated to the particular job.
    12,875 pointsBadges:
    report
  • azohawk

    The topic of "why multi-member files" has been discussed in this forum in the past month, so I will refer you ther for the why.

    For using a specific member my first choice would be to use OVRDBF in a calling CL program to specify the member.  If you must specify which member, i suggest you look at the EXTMBR keyword for the F-Spec. I don't ever recall using it, so I can't be much more help.

    4,055 pointsBadges:
    report
  • ToddN2000
    I agree with Azohawk, using the EXTMBR kind of defeats the purpose. You would need to change the program and recompile for each member you want to process. Using the CL OVRDBF is much easier. You can pass the member name as a parameter and never have to compile a program to process any number of members.
    132,760 pointsBadges:
    report
  • Splat
    ToddN2000, you can use a variable in the EXTMBR keyword. I use it frequently for work file members. Just remember to define the file as user open (usropn).
    12,875 pointsBadges:
    report
  • ToddN2000
    @splat: Never tried that, I'll have to give it a try...I guess old coding habits die hard. We code what we are comfortable with. 
    132,760 pointsBadges:
    report
  • Splat
    Between that & the QCAPCMD API it's a rare occurrence for me to use CL for member handling.
    12,875 pointsBadges:
    report
  • GregManzo
    Wouldn't putting the workfile in QTEMP be simpler than having your own member in a multi-member file? And you get free 'clean-up'. We've only ever used multi-member workfiles for batch jobs that need to keep the data lying around for a while.
    2,960 pointsBadges:
    report
  • mmanley
    We use multi-member files regularly, to separate the work of various users. With a combination of OVRDBF and use of the EXTMBR (with a variable) in the RPG program, you can keep each user in their own "space", while allowing overall reporting, inquiry, etc. to be done on the entire file. It's a very useful technique.
    470 pointsBadges:
    report
  • Splat
    GregManzo, I don't care for QTEMP for work files much - debugging can be a nightmare.
    12,875 pointsBadges:
    report
  • ToddN2000
    In my opinion putting files in QTEMP can have it's advantages at times but not necessarily for multi member files.  The file is only accessible from the job that created it. There should be no conflict with other jobs so a single member should suffice if you are putting files in QTEMP.

    I worked at a company years ago that went a different route.
    The job would pull in the user from the data structure. The multi member file was set up as a user controlled file.
    WE would access a table of what that users member was then do a QCMDEXEC to OVRDBF then do an open and close at the end of the job. 
    132,760 pointsBadges:
    report
  • GregManzo
    @Todd: Yes - the whole purpose of QTEMP is because it is only accessible from this job you don't need to bother with multi-members. In fact I'd rather try to avoid multi-member files because SQL doesn't handle them well.

    @Splat: I understand the debugging problems, but I'd rather put up with that than deal with cross-corruption issues when users accidentally update each others' data. But I've found 2 ways of dealing with it: If still in initial development turn off the dupobj to QTEMP and let it use the base file in your permanent lib so you can see the data. For debugging issues in batch jobs after deployment I sometimes use a switch to create the duplicate for this job in QRPLOBJ instead. You need appropriate authority but, again, you can see the data - and you still get auto-cleanup, just delayed to next IPL.
    2,960 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.

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

Following

Share this item with your network: