Re: Remnants of group profiles...

The problem is this.  Let's say we have a file library called DHTDIVF.  It 
is a separate legal company.  Objects are all owned by SSA70.  Now we have 
another file library called PVCDIVF.  It, too, is a separate legal 
company.  All objects in it are owned by SSA52.  However, there are people 
who work on both.  Let's say they outsource their accounting department to 
people in company 01.  Tried supplemental group profiles - never again! 
Not only did it take a SAVSYS (not to be confused with GO SAVE - 21 
although many people wrongly call that menu option SAVSYS), that normally 
ran in 4 minutes and stretch it out to 44 minutes, but it causes all sorts 
of other issues.

We also have fun concerns like "What if user ROB01 runs a program for 52 
that creates a file on the fly?"  Even if ROB01 has a supplemental group 
profile of SSA52 the owner of that object sure isn't SSA52.  Instead, it 
is the primary group profile associated with ROB01.  Granted, most 
applications that are not poor migrations from the S/36 do not create a 
lot of files on the fly, however, there are some that sure create a lot of 
data areas, etc.

With authorization lists we simply do a 
GRTOBJAUT OBJ(DHTDIVF) OBJTYPE(*LIB) AUTL(SSA70F)
CHGLIB LIB(DHTDIVF) CRTAUT(SSA70F)
And all new objects created in that library automatically get that 
authorization list assigned to it, regardless of owner.  (Well, there are 
a few commands that we had to CHGCMDDFT.  Like CRTSAVF AUT(*LIBCRTAUT) 
versus the shipped default.)

Rob Berendt