×
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.
Hi, Walden:
A user profile name is stored as text in some places, e.g. a *JOBD, but
this does not mean they are ALWAYS stored that as text, internally.
The UID and GID you mention were added at V3R1/V3R6 solely for Unix
compatibility (the IFS, etc.). I don't think those are used anywhere
else, except for the Unix compatible APIs in OS/400. Below the MI layer,
objects often "point to" other objects via a (16 byte) system pointer.
If you delete a user profile, then re-create it, consider what would
happen to all of the objects "owned by" that profile... they must be
assigned to a different profile, when you delete a user profile in i5/OS
or OS/400. And all private authorities to all objects for a given user
are stored within the *USRPRF object. So if you delete the *USRPRF and
recreate it again, ALL private authorities to ANY objects on the system
for that user would be "gone." (You could change object owner for each
object that was owned by the profile, before it was deleted, and assign
them to be owned by the new profile of the same name. But, that will NOT
restore any of the private authorities.) And there are many other
things in the system that would disappear and cannot be automatically
recreated, including SNADS network files in the distribution queues for
that user, SNA system directory entries, etc., when you delete and then
attempt to recreate a user profile.
The 10-character user profile name was used as (part of) the key for
one-way encryption of the password for that user profile. So, if you
rename the user profile, this would invalidate any stored encrypted
passwords, with no way to recover. That may be a fundamental
architectural reason why CPF, OS/400 and i5/OS (and the underlying MI
instructions) have never allowed renaming a *USRPRF object.
Regards,
Mark S. Waterbury
> Walden H. Leverich wrote:
Yes, there are. But they're settable, and while I've not looked in a
release or two, the internal references to user profiles are by name in
OS/400. Last I looked, for example, at the internals of a jobd, they
stored the user name in the jobd as the user to run as, not the UID or
GID of the account.
-Walden
--
Walden H Leverich III
Tech Software
(516) 627-3800 x3051
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com
Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
midrange.com
