What is QTEMP?
lieven vanhaverbeke
If an other user needs the same program he creates his own workfile without
disturbing your job. Sometimes its verry useful.
If you start the interactive source debugger he will create some files in
Qtemp
Eugene Astanovsky heeft geschreven in bericht <36B099...@optiva.ee>...
>May be it is a stupid newbie question,
>but can someone explain me who the hell is QTEMP?
>I understand that is library. But that is all I understand.
>WRKLIB for it is not allowed. O'k. WRKOBJ QTEMP shows nothing
>even with QSECOFR authority.
>At the same time I know that there are about a hundred data areas
>with the same name, which are created by the application, we are running
>on the /400. More of that if I create that data area manually, I see it.
>If someone else online creates it, he sees only his instance, but not
>mine. I have a feeling that QTEMP is some dummy library which is unique
>for each job and my QTEMP has nothing common with my friends QTEMP.
>Is it true?
>I have a feeling that I am missing something very basic!
>Any help will be highly appreciated.
>TIA,
>Eugene Astanovsky.
Eugene Astanovsky
Karl Hanson
>
<snip>
> I have a feeling that QTEMP is some dummy library which is unique
> for each job and my QTEMP has nothing common with my friends QTEMP.
> Is it true?
Yes - each job has its own unique QTEMP library. There is no intent to
share objects in a job's QTEMP library with other jobs. Also, as its
name implies, the library is temporary and destroyed at job end.
--
Karl Hanson
Charles R. Pence
> <<SNIP>> If someone else online creates
> creates it [data area in QTEMP], he [secofr] sees only his instance, but not
> mine. I have a feeling that QTEMP is some dummy library which is unique
> for each job and my QTEMP has nothing common with my friends QTEMP.
> Is it true?
> I have a feeling that I am missing something very basic!
You seem to understand it well enough. If you are appropriately authorized and
need to see a data area in another user's job, you can issue STRSRVJOB on their
job, and then issue DMPSYSOBJ DtaAraName QTEMP OBJTYPE(*DTAARA).
Regards, Chuck
All comments provided "as is" with no warranties of any kind whatsoever.
Obelix
<jev...@optiva.ee> wrote:
> have a feeling that QTEMP is some dummy library which is unique
>for each job and my QTEMP has nothing common with my friends QTEMP.
>Is it true?
>I have a feeling that I am missing something very basic!
You're quite right. A QTEMP library is a library wich is created for
each single job, and it's related and visible only from that job. More
on, as soon as the job ended, the lib and all fo it's content will be
destroyed. So, if you need to use some temp files, instead of create
it and 'remeber' to remove it (and, maybe, leaving them somewhere in
the job end abnormally...), just create it in QTEMP and you'll be sure
they will be removed by the system
Obelix
Gary Guthrie
> each single job, and it's related and visible only from that job.
This is not absolutely, technically true. There are ways to get at another job's QTEMP.
It's a context, like other libraries are contexts. QTEMP is not the context's real object
name. OS/400 recognizes QTEMP as a "special case" and rather than resolve a pointer to it
when it is referred to, the operating system retrieves a pointer to the QTEMP that is
assigned to the job from the job's PCO (an internal structure). This can be exploited to
get at another job's QTEMP with some low level programming.
> More on, as soon as the job ended, the lib and all fo it's content will be
> destroyed. So, if you need to use some temp files, instead of create
> it and 'remeber' to remove it (and, maybe, leaving them somewhere in
> the job end abnormally...), just create it in QTEMP and you'll be sure
> they will be removed by the system
I don't think this is absolutely, technically true, either. The QTEMP context remains on
the system and is re-assigned to another job when it starts up.
Gary Guthrie
Editor, The RPG Source
Technical Editor, NEWS/400
Obelix
<ggut...@airmail.net> wrote:
>The QTEMP context remains on
>the system and is re-assigned to another job when it starts up.
Yes, but files and other object create 'inside' it are destorjed as
the job end.
Obelix