As others have said, there's unfortunately no equivalent to QTEMP for
stream files. (Though, depending on the application, you could
potentially store your data in a userspace in the "normal" QTEMP library.)
Be warned, however, that if you're using QtmmSendMail, it spreads it's
work across multiple jobs -- so QTEMP (or anything like it) wouldn't
work for that scenario.
As others have pointed out, there's an API named tmpnam() (if you're
calling it from RPG, it'd be _C_IFS_tmpnam) that returns a unique,
temporary name in the IFS. If you'd like an example of this, check out
the http_tempfile() subprocedure in HTTPAPI. (It's in the HTTPUTILR4
Another interesting technique is to create a stream file via the open()
API (possibly using tmpnam for the filename) and then removing the link
(filename) for that IFS file while it's still open. When you do that,
the file will remain on disk, accessible via it's file descriptor until
you close the file. Once you close it, the space will be freed up
automatically, because you unlinked it. (and, if your job ends
abnormally, that'll automatically close the file -- so in a way, it's
like a QTEMP. Sort of.)
fd = open( filename
: O_CREAT + O_RDWR + O_EXCL
: S_IRWX );
// file exists, and can be accessed via
// 'fd', but has no filename.
.. do other calculations/work here ..
// since the last reference to the file was via
// descriptor 'fd', when I closed it, the disk
// space was freed up.
Not sure if that makes sense for your particular scenario, but it's an
interesting technique. (But, again, won't work with QtmmSendMail, if
that's what you're working with.)
On 4/23/2012 9:31 AM, Stone, Joel wrote:
Would like to create a temp IFS dir to build email text for sending,
and would like the system to handle ensuring unique IFS work area for
each job. Also delete at EOJ.
How can this be handled so multiple jobs don't build in same IFS
area? Use job name? Or is there something like QTEMP for IFS?