Re: Can access to QDLS via Windows Explorer

On 30-Mar-2014 09:35 -0700, Mark S Waterbury wrote:

On 3/30/2014 9:58 AM, gio.cot wrote:

<<SNIP>> Keep in mind that the user that works, was created
copying my user that don't work

You said that you "copied" the user ... but you did not say how you
did that ... if you used option 3=Copy on the WRKUSRPRF panel, that
will NOT copy or create directory entries. <<SNIP>> Without this, you
cannot access any QDLS folders or documents. <<SNIP>>

That reply [mostly snipped] seemed to discuss how the copied-to user would not be functional for access to the /QDLS, until after being registered to the directory. While that is accurate, the OP states in an overall summary of the post [relevant snippet left intact], that the non-functional user is the copied-from user.

So the OP seems to be perplexed, after having created the new user profile plus having registered that new user to the system directory, why that new user has no problems but the old user profile has the problem. Such an issue would likely be something to do either with the authorities held by, or with the directory entry for, the old user.

Trying to find a specific authority, by comparison of the two profiles, is generally not a simple task; notably, because the existing profile has a history, but the new user has just a concise set of authorities per not having been in use over time. Simpler, is enabling auditing and reviewing for a T-AF entry after the attempt to use the function fails.

Comparing the directory entries is a bit easier, because the DSPDIRE presents a "Display Directory Entry Details" and the details can be verified to be consistent between the two profiles; AFaIK the only requirement is that the "User Profile" be named in an entry, such that neither the USRID and Network User ID are immaterial. If the old entry exists and compares as expected, then given the new user was functional after presumably ADDDIRE, then some relational data in the entry may be in error, such that a RMVDIRE followed by re-inserting the directory entry with a new ADDDIRE could resolve.

And if removing the existing and then adding a fresh directory entry for the old User Profile resolves the issue, then there is very possibly either a problem with the database file network for the QAOK* files or perhaps the data. Issues with those files, mostly arisen from improper restore [unsupported and improper "upgrade" activity] have often resulted in unpredictable results for features dependent on the data; notably, some files or members in QUSRSYS would have a TEXT attribute similar to "Old name QAO...". Less likely, an anomaly would be specific to just the data for that one user; unless that was the only user defined when the DBF network or data was corrupted.