RE: QUSER on ODBC requests

> From: rob@dekko.com
>
> But in this case we are doing centralized control by the host.  The 400
> needs data from a PC in another state, at 2am in the morning.  Now I
> suppose we could hire someone to come in at 2am and key the user id and
> password.  Or we could hire someone to walk over to the PC in the remote
> site and click on some silly icon - but there goes your centralized
> control.

My suggestion does not require any of this, so the logistics aren't relevant
to the discussion.  The PC can simply send a request in at 2AM, and the
AS/400 can then poll the PC and retrieve the data.  No user intervention,
and completely centralized control.  Or you can send the data to an
intermediate box and let it hold it for transfer to the AS/400.  In this
scenario, the data transfer from the remote location can occur even if the
AS/400 is down for whatever reason.


> Yes, you are right we could write some sort of sockets thing or
> whatever to do this, but we decided to do it this way.  It's our choice.

This, then, is the crux of your reasoning.  You decided to do it this way.
The pretty much knocks the wind out of any silly discussion on my part about
security or business requirements.


> The password is not tacked up for everyone to find.  Anyone who has access
> to the objects which have this buried can get to it but we assume that
> people that have this kind of access are trusted employees.  After all,
> sooner or later you have to be productive.  I am not interested in the
> 'cones of silence' from that old Get Smart movie.

Allowing only specific requests from trusted addresses is neither a cone of
silence nor counterproductive.  It is simply good, sound security practice.


> In the case of the Domino (a different project) - we are running a stored
> procedure.

The same concerns apply.  If the user profile and password is public, make
sure your AS/400 is locked down tight.  Better yet, move the data to an
unsecured box and change your stored procedure to access that box.

Joe Pluta
www.plutabrothers.com