If you use a technique like this, please be very careful of:

1) Concurrency... if multiple jobs can run your program at once, make sure they have separate object names, since they're sharing a library.

2) Security... one of the classic security holes found in Unix systems (which use a common 'global' temp area) is that people could see other people's temp files, which often had sensitive data in them. When people all share a common temp area, care must be taken to restrict the temp data to only the users that are using the object.

I would recommend using other techniques, such as pipes or sockets instead of temporary data if that's at all possible.


On 12/26/2014 2:04 PM, Roger Harman wrote:
To add to Rob's & Luis' discussion.....

We have a similar issue with QTEMP and a managed file transfer product. We wanted to give it access to a workfile which would usually be in QTEMP.

The solution we used was to create a real library ZZQTEMP (or whatever) that is NOT in any library list. Make a unique name (typically using job #) and place objects there. We call it our "Global" Qtemp and pass the name into the MFT process. You just have to cleanup after yourself.

Same principle for IFS work files - create a subdirectory under /tmp for the job and pass that name to the MFT product or, in your case, the QSH command.

Roger HarmanCOMMON Certified Application Developer – ILE RPG on IBM i on PowerOCEAN User Group – Vice-President, Membership (2014)

This thread ...


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

This mailing list archive is Copyright 1997-2020 by 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].