× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



With the exit program you have access to the job information. From the job information you can obtain all sorts of stuff: Current user, IP addresses, network connection data, remote host name, etc.

As I said in another post...

There was/is an exit point program product out there that allows you to "define" your own server within its structures.
It supplied/supplies an API to access the authorization rules you set up for your server. It allowed/allows use of all its
functionality found for IBM's servers.

Just a thought, but the stored procedures you mentioned can call this API. It could also save you a ton of programming. You call the API with the necessary info and the structures and processes to swap profiles, audit, authorize, etc. are already in place and, supported by maintenance contract.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Buck Calabro
Sent: Wednesday, June 12, 2013 2:13 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: WHO is connecting via QRWTSRVR jobs and editing data?

On 6/12/2013 3:20 PM, Monnier, Gary wrote:
A simple phrase...

PUT AN EXIT PROGRAM ON THE DDM/DRDA EXIT POINT!

I am probably missing something because I can't see how the exit point is going to work. Won't all the DRDA requests be identical? The same user (APACHE) and the same PRDID? I could allow / deny based on library/file name but isn't that already handled by the authority of the generic user profile the OP is using?

Not an argument - I value your opinion.
--buck

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Eric Lehti
Sent: Wednesday, June 12, 2013 12:05 PM
To: Midrange Systems Technical Discussion
Subject: WHO is connecting via QRWTSRVR jobs and editing data?

Or stated more accurately . . .
When user BOB or TED or CAROL or ALICE edits IBM i records via our web portal, can I easily prove who the user is?

Our portal application, written in PHP, is hosted on a Windows server, and runs Apache.

The portal connects to our IBM i with QRWTSRVR jobs active in QUSRWRK subsystem, and runs under user profile APACHE which I created specifically for connections from that web server.
Is there a simple configuration so that:
1. when user BOB logs into our web portal, he runs a QRWTSRVR job
under profile BOB 2. when user TED logs into our web portal, he runs
a QRWTSRVR job under profile TED 3. when user CAROL logs into our web
portal, she runs a QRWTSRVR job under profile CAROL 4. when user
ALICE logs into our web portal, she runs a QRWTSRVR job under profile
ALICE

--
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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.