Hi,
ACF2 FDR needs to be changed to accommodate any changes in UID string of LID.
Which would result in access rules being changed all over the place.
Instead consider defining a resource class ex. JOBNAME and issue RACROUTE AUTH
to the class JOBNAME with ATTR(READ).
Example to define a class name "JOBNAME"
t c(gso)
insert CLASMAP.JOBNAME ENTITYLN(8) MUSID() RESOURCE(JOBNAME) RSRCTYPE(JOB)
cha infodir add types(r-rjob)
f acf2,refresh(infodir)
f acf2,rebuild(job),class(r)
create keys for each job name you are protecting
set r(job)
compile *
$key(TESTJOB0) type(job)
uid(xxx-) to prevent specific uid string or uid(*) prevent
uid(yyy-) allow
store
That would allow uid strings starting with yyy to use the jobname TESTJOB0.
HTH,
Natarajan
>>> "Joe D'Alessandro" <joseph.d'alessan...@fiserv.com> 1/26/2009 10:12 AM >>>
Hi:
Just to clarify: I believe the lengths of these fields are static. And the
LID is
8 bytes long in the delivered product. Some of us have 8 bytes LIDs (for CICS
or other non-TSO users). I am not sure what "static" meant in the chart
(values)?
In any case, we are talking about a UID string that is to look like this:
Field Len
----------- ----
DIVISION 2
DEPARTMENT 3
FUNCTION 3
JOBNAME 1-8
LOGONID 1-8
Is there already an eight byte empty /unused area in the UID now between
FUNCTION and LOGONID? That is, what does this @UID look like in the
ACFFDR source (for example, here is the vendor's source):
@UID LID
If you add a field to the UID (and expand it, rather than redefine a presently
unused field), any dataset or resource rules that specify non-asterisk/hyphen
values the UID beyond the FUNCTION field would likely need revision (which is
not a trivial task). If your UID already contains that 8 byte area under some
other name then the rules may be fine and you are just redefining the 8 byte
area. For example, UID(SPTEKSPRJOED****) would need conversion to UID
(SPTEKSPR********JOED****).
It is an interesting idea to add JOBNAME to a resource rule (after all, one
could always code ******** in the rules if it was to be ignored, or a partial
name like PROD**** for grouping jobs by that LID).
The pieces that need to be changed are the ACFFDR, the LIDs and then all of
the rules in both dataset and resource databases. To decompile, modify,
compile and store all of the rules would be a very interesting REXX or CLIST
exercise, or one could dump the dataset and resource database to flat files
and convert the rule strings that way (probably a lot easier) and then load
them into the KSDS files. Updating the LOGONID database is probably best
left to the ACF2 change command after the new ACFFDR is live, using a CLIST.
regards, Joe D'Alessandro
NOTICE OF CONFIDENTIALITY
The information contained in this communication, including but not limited to
any accompanying document(s) and/or attachment(s), is privileged and
confidential and is intended solely for the above-named individual(s). If you
are not the intended recipient, please be advised that any distribution,
copying, disclosure, and/or use of the information contained herein is strictly
prohibited. If you received this communication in error, please destroy all
copies of the communication, whether in electronic or hard copy format, and
immediately contact the Security Office at EDFUND at (916) 526-7539 or
securityoff...@edfund.org. Thank you.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
