RE: Data access for non-AS400 devs?

>What might be considered a best practices approach

This is a server app? Just store the string, and move on. You asked for
the "best practice" and that's it.

Now, if you want to look at other options, ok... 

Option 1, store the string, but give the user read-only access. If the
programmers want to update files make them call stored procs which are
RPG (Cobol, whatever) programs that run as owner where the owner has
update rights. While this doesn't prevent someone from calling the SPs,
it does prevent updates like "update item set price = price * 0.9"
(unless of course you have a stored proc that does that)

Option 2, store the string, but don't give it any access. Make both
reads and updates go through stored procs. Now you've locked down not
only updates, but reads too. Again, anyone w/the connection string can
go call your procs, but now they can't even query data in an adhoc
manner.

Option 3, have the PC program request a temporary password from a
service on the iSeries. The iSeries will set the password on the userid,
hand back the password and then reset the password in a couple of
seconds. That "couple of seconds" is more than enough time for the PC
app to connect with the returned password.

Option 4, do option 3, but encrypt the returned password. Provide your
programmers with a DLL that they call to get a connection, the details
of the password retrieval, decryption and connection are hidden in the
DLL

Option 5, start looking at things like Kerberos. However, I don't know
the level of support for Kerberos in OLEDB/ODBC/.NET and I think by the
time you've gotten to this level of complexity you're way, way, way,
way, um, did I say way, to complex for your own good.

-Walden

------------
Walden H Leverich III
Tech Software
(516) 627-3800 x11
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Franz
Sent: Tuesday, September 13, 2005 12:48 PM
To: Midrange Systems Technical Discussion
Subject: Re: Data access for non-AS400 devs?

What might be considered a best practices approach as to how a
SQL Server or VB access to AS400 data would store a user id/profile?
Some of this might be server applications throughout the day making
requests.
The server programmers want a profile to "use" to read data (and I
expect
someday to update). We do have *public excluded from all files and
authority
by auth lists. I want something other than a hardcoded user id/pwd
inside
some text file on a windoze machine.
jim franz
----- Original Message ----- 
From: "Bill" <brobins3d@xxxxxxxxx>
To: "Midrange List" <Midrange-L@xxxxxxxxxxxx>
Sent: Tuesday, September 13, 2005 11:19 AM
Subject: Re: Data access for non-AS400 devs?


> Goodbar, Loyd (ETS - Water Valley) wrote:
> > I'm assuming he'll need an AS/400 user ID and security to the
> > library. I'm only familiar with iSeries Navigator for a GUI view of
> > the database and running SQL.
> >
> > How have you handled this situation, what tools are required? How
> > have you handled this situation, what tools are required?
>
> MS Query transferring data to either Excel or Access.
>
> I myself also use Visual FoxPro for the involved reporting needs.
>
> Bill
> -- 
> 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.
>
>