ADDSVRAUTE & DDM files

pts.
Tags:
Application development
AS/400
I am writing an Order Entry application that requires use of file on a remote system, which I will access via DDM. The problem is that we have hundreds of order entry clerks and turn around is great. I do not want to open a can of worms by having to create and maintain remote system user id's and local Server Authority Entries. The other issue, any output created from the order entry process must be stamped with the user id for obvious reasons. Therefore, a generic id (a solution we've used in a batch scenario) isn't feasible here. Is anyone aware of a way to create a DDM file using a group profile or a technique that will get around creating individual target user ids and local authority entries? -Alison
Asked: Last updated:
Related Questions
1

Answer Wiki

Thanks. We'll let you know when a new response is added.

ok – several ways to do this – depending on our requirements

for example you can change user at the remote end to work as the logged on user, you can adopt authority to permit the intersystem access, while still working as the original user id, or (normally easiest) stamp the name of the user making the transaction to an audit file, this can be written directly from the calling program

Discuss This Question: 1  Reply

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • TomLiotta
    The requirements are contradictory. You reject generic profiles due to a requirement to have transactions stamped with actual user IDs. And you reject individual user IDs because you don't want to maintain them. One requirement or the other has to be dropped if DDM over TCP/IP is used. Note that DDM over TCP/IP without requiring passwords opens the system to the world (as would running any server without requiring passwords). Near as I can tell, DDM isn't the appropriate technology for this. Perhaps DRDA/SQL and stored procs would be a better fit. The stored procs might accept an additional parm for job user while the connection itself would be through a generic CurrentUser. You might switch to the current user before running the update. It might be possible to do something similar over DDM, but you might need to invoke a remote program rather than update/access a remote file directly. Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.

Following

Share this item with your network: