On 10/07/2008, at 4:25 AM, vhamberg@xxxxxxxxxxx wrote:

FYI - I have a scenario where product libraries get rather messy and actually don't seem to work.

I have a command or a menu that has PRDLIB(VMHLIB) in it.
I run the FNDSTRPDM command over a file in VMHLIB but I use *LIBL.
I get a message that the file is not found.

My PRDLIB was replaced by QPDA, as set in FNDSTRPDM - so my library is no longer in the list - can't find my file.

That's a risk you run whenever you have strings of commands from different vendors. There are TWO active product library positions so generally you can run your command (with PRDLIB1 set) which invokes another command (with PRDLIB2 set) and both commands have access to their own product libraries. I notice on my system which has both PDM and ADM installed that any PDM or ADM command adds BOTH QPDA and QADM to the PRDLIB portion of the library list thus "stealing" both slots. That seems like a design flaw and may be contributing to your observed behaviour.

If there were to be a DCR, I'd lobby for letting the library that was pushed onto the PRDLIB stack (Chuck - excuse my loose terminology!) still be in the search path. The system knows it is there, because when the command is done, then that PRDLIB is back.

Bad idea. That will just make the PRDLIB portion of the library list large and we'll be back to having ridiculous numbers of libraries in the search path. Bad enough that Rochester caved-in to increase USRLIBL from 25 to 250--don't pester them with an increase in PRDLIB too.

Simon Coulter.
FlyByNight Software OS/400, i5/OS Technical Specialists

Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
ASCII Ribbon campaign against HTML E-Mail / \

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page