QTEMP cleanup

[rob@xxxxxxxxx]

Aaron,

I'm not so sure I'd solely rely on the end of the job doing my cleanup of 
QTEMP objects.
I'm not saying that it won't do so.  My concern is if someone injects your 
program in the middle of another job stream.  For example if your program 
creates a file called TEMPFILE and now it gets added to the middle of a 
job stream where there was already a TEMPFILE in QTEMP then you're toast.

Granted, perhaps some sort of shop standard needs to be made, like 
expected length of use of QTEMP objects.  Obviously you can't limit it to 
within the same program because it's quite often that a file gets copied 
to qtemp in a cl program and then that cl program calls a rpg program.  I 
would encourage manual deletion immediately upon completion.  For example, 
if your little program did a 

CL1:
PGM
CRTDUPOBJ MYFILE TOLIB(QTEMP)
OVRDBF MYFILE TOFILE(QTEMP/MYFILE)
 /* yadda, yadda, yadda */

then you should add

DLTOVR MYFILE
DLTF QTEMP/MYFILE
ENDPGM

I would also discourage the use of:
CL1:
PGM
DLTF QTEMP/MYFILE
MONMSG CPF2105 /* Object not found */
CRTDUPOBJ MYFILE TOLIB(QTEMP)
OVRDBF MYFILE TOFILE(QTEMP/MYFILE)
 /* ... */
DLTOVR MYFILE
DLTF QTEMP/MYFILE
ENDPGM

Because, by doing so, if the previous program in the call stack relies 
upon MYFILE being a particular thing you just hosed it up royally.  Better 
your program should die and they could decide if they need to
- add the cleanup to delete their copy of MYFILE (if they were done with 
it and were assuming end of job would delete it and that's all they 
needed)
- change their temp file name to something else than MYFILE
- ask you to change your name
- just not use your routine.

Then we could start getting into the whole realm of:
CALL GENNAME PARM(&UNIQUE)
CRTDUPOBJ OBJ(MYFILE)  TOLIB(QTEMP) NEWOBJ(&UNIQUE)
OVRDBF MYFILE TOFILE(QTEMP/&UNIQUE)
  /* ... */
DLTOVR MYFILE
DLTF QTEMP/&UNIQUE
ENDPGM


Rob Berendt