Rob, all good points and I think we are in agreement.
My main scenario of QTEMP is in the use of *USRSPC and *USRIDX objects to
have a single one per job/user. This keeps me from having to gen a unique
name for each object in a "global" library (like you were alluding to).
Though I am rethinking my approach with QTEMP *USRIDX usage, because with a
*USRIDX I really wouldn't need a QTEMP object. I could separate entries
within a single *USRIDX by qualifying the entries with the job number. That
would lessen the number of total *USRIDX objects and instead leave a single
big one on the system. I haven't ventured down that path much because QTEMP
has worked so good for me.
Thanks for your comments,
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Monday, January 14, 2008 9:16 AM
To: midrange-l@xxxxxxxxxxxx
Subject: QTEMP cleanup
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
midrange.com
