Re: QTEMP objects and Different Users on the Same Job -- MIDRANGE-L

Seems to me that the OS should clear QTEMP when it resets the job for the
next request.

The problem I see with having clear it yourself at the end of your request
is that it's possible that something goes wrong and your cleanup code
doesn't run.

I suppose one should be using ILE and the Register Activation Group Exit
Procedure (CEE4RAGE) API to ensure that you cleanup after yourself...

Charles

On Tue, Mar 22, 2016 at 10:53 AM, Mark Murphy/STAR BASE Consulting Inc. <
mmurphy@xxxxxxxxxxxxxxx> wrote:

Each request runs in it's own job right? Unless things are running
multi-threaded, in which case using QTEMP as a local only library is a crap
shoot at best. Since each request is in it's own job, and there is no
guarantee that you will get the same job on your next request, QTEMP should
be able to be cleared at the end of the request since whatever is there is
either yours or from some random previously completed request.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx

-----"Jim Oberholtzer" <midrangel@xxxxxxxxxxxxxxxxx> wrote: -----
To: "'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
From: "Jim Oberholtzer" <midrangel@xxxxxxxxxxxxxxxxx>
Date: 03/21/2016 10:09AM
Subject: RE: QTEMP objects and Different Users on the Same Job

Clearing QTEMP after a web request is assuming all the web requests are
serial and not happening fast enough that more than one might be in process
at a time. I understand security paranoia, but a healthy look at what the
data that's in QTEMP is warranted to see if it's worth protecting.

--
Jim Oberholtzer
Agile Technology Architects

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Mark
Murphy/STAR BASE Consulting Inc.
Sent: Monday, March 21, 2016 8:51 AM
To: Midrange Systems Technical Discussion
Subject: Re: QTEMP objects and Different Users on the Same Job

I'm with Charles on this one. Particularly if user B shouldn't have access
to the data user A might have stored in QTEMP. Seems like a potential
security issue leaving things laying around, and then giving everyone
access
to them opens that hole a little wider. Just do a CLRLIB QTEMP at the end
of
each web request.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx

-----Charles Wilt <charles.wilt@xxxxxxxxx> wrote: -----
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
From: Charles Wilt <charles.wilt@xxxxxxxxx>
Date: 03/18/2016 09:58AM
Subject: Re: QTEMP objects and Different Users on the Same Job

Brad,

I'm thinking leaving the objects out there with data isn't the best idea...

Charles

On Fri, Mar 18, 2016 at 9:52 AM, Bradley Stone <bvstone@xxxxxxxxx> wrote:

Ah... good idea! I can try that if it's the only option. I guess I'd
rather have the object created automatically with *PUBLIC authority
somehow.

Brad
www.bvstools.com

On Fri, Mar 18, 2016 at 8:50 AM, Glenn Gundermann <
glenn.gundermann@xxxxxxxxx> wrote:

Hi Brad,

Can you place the users in a group profile and have authority as the

group

profile?

Yours truly,

Glenn Gundermann
Email: glenn.gundermann@xxxxxxxxx
Work: (416) 675-9200 ext. 89224
Cell: (416) 317-3144

On 18 March 2016 at 09:48, Bradley Stone <bvstone@xxxxxxxxx> wrote:

Interesting scenario here I thought I would throw out for some ideas.

An application uses QTEMP for temporary files. It builds files as

part

of

a process. For normal batch or interactive jobs it works fine.

QTEMP

is

unique to that Job.

The process looks like this:

1. Delete any existing QTEMP files
2. Create new QTEMP files
3. Put data in them to process
4. Done.

Now throw this into a web server situation. The jobs change the User

ID

for the process from QTMHHTTP to a real user ID.

A file in QTEMP is created, process completes, all is good. Files in

QTEMP

are left there.

A new user comes along and changes the User of the job. Now the

process

errors out because the new user doesn't have the right authorities to

the

object in QTEMP to clear it or remove it and start over.

Any ideas on how to make this work without having to change

authorities

to

the QTEMP objects or delete them each time? Or give users *ALLOBJ
authority?

I guess I'm looking for some sort of flag that we can say "when you

create

an object in QTEMP, make it so any User ID can work with it.". I'm
guessing there isn't such an animal, but I am curious.

Brad
www.bvstools.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)

mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.