Raymond,
Regarding the variance of users local attribute values between your
production and DR servers, I have found mine to be exactly the same, with
the exception of the user, MGR and the account itself. The only provision I
make is to once a night, create the buldjob1 and buldjob2 JCL's via
buldacct ( I re-equate their names to ABLEJOB1 and 2, see below example A)
and FTP them over and use the "SITE STREAM" command to execute a simple JCL
I call ABLEJOBS (see example B). The local job stream (ABLEJOBS.JOBS)
streams the ABLEJOB1 and ABLEJOB2 and corrects the deficient local
attribute both at the account and user MGR level (see example C). This
pretty much keeps us in alignment with the correct users and local
attribute assignments ( It does not address of course users which have been
deleted from the production server, but this is a mute point as you have
application tools which allow you to equalize that variance as you
mentioned in your e-mail).
One other note I should make is that, perhaps in your environment, users
attributes are periodically modified within the application in order for
them to perform specific tasks within the application. If, in the event
that this does happen (I.e. FRANK.ABLE was originally assigned via the
application a local attribute = 13 and later given the attribute of 26 to
augment his capability within the application, the buldjob1 JCL would alter
that users local attribute correctly on the DR server to 26 as well as it
does a 'NEWUSER' and in the event that the user already exists, does a
'ALTUSER').
So, if you are not running buldacct nightly, then your mirror application
might not be being updated with the 'newest' local attribute for a given
user.
Hope this helps.
Example A
!if b1sysnum = 1
!
! tellop;
! tellop; ***************************
! tellop; ** Create Ablejob1 and 2 **
! tellop; ***************************
! tellop;
!
! file buldjob1=ablejob1
! file buldjob2=ablejob2
!
! buldacct able@
!
!endif
Example B
!if b1sysnum = 1 and bkpbuldacct
!
! tellop;
! tellop; ********************************
! tellop; ** Begin FTP Of File Ablejob1 **
! tellop; ** And Ablejob2 To Com4h003 **
! tellop; ********************************
! tellop;
!
! purge BKPBLDAT
! file BKPBLDAT;rec=-90,,f,ascii
! echo open com4h003 > *BKPBLDAT
! echo user manager.sys >> *BKPBLDAT
! echo xxxx >> *BKPBLDAT
! echo cd /SYS/PUB >> *BKPBLDAT
! echo ascii >> *BKPBLDAT
! echo mput /SYS/PUB/ABLEJOB# >> *BKPBLDAT
! echo site stream ablejobs.jobs >> *BKPBLDAT
! run ftp.arpa.sys <BKPBLDAT
! purge ablejob#
!endif
!
Example C
!job ablejobs,manager.sys;outclass=lp,1
!
!comment JCL Version 1.2
!comment ****************************************************
!comment ** This JCL is used to reflect the creation of **
!comment ** users/groups created on the production server **
!comment ** via the application interface. **
!comment ****************************************************
!
!stream ablejob1
!pause job="BULDJOB1,MANAGER.SYS"
!
!stream ablejob2
!pause job="BULDJOB2,MANAGER.SYS"
!
!purge ablejob#
!
!altacct able;locattr=-1
!altuser mgr.able;locattr=-1
!
!altacct ableprod;locattr=-1
!altuser mgr.ableprod;locattr=-1
!eoj
Regards,
Reid E. Baxter
Raymond Familar
<far_north_flip@y To: [log in to unmask]
ahoo.com> cc:
Sent by: HP-3000 Subject: Re: [HP3000-L] MPE local attribute on userid
Systems
Discussion
<[log in to unmask]
tc.edu>
12/06/2005 02:02
PM
Please respond to
Raymond Familar
Hi Reid.
I have seen the issue you are describing and it is a documented bug in
BULDACCT starting 6.5 I think.
I see you are running the same app. The issue I have here is that the app
tracks the user's LOC ATTR. This should be the same on both systems - at
last test, it was. There were a handful of users that the LOC ATTR was
different on DR than on PROD. I ran a User Audit report to find the app
users that this affected, and their LOC ATTR was changed to match.
But I don't know how it may have been changed to begin with. Does a
password change affect this attribute? What user admin tasks may affect
the
LOC ATTR?
Ray
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
