Top Secret

Here's a weird one: After I gave a user permission to DATASET(OTRAN.VWSM.VEH.WHSE.SHIP.OPT16), her access should have worked correctly, but TSSUTIL said it failed with SRC/DRC code *08*-70, which the legend says means "DATASET NOT AVAILABLE THROUGH THIS FACILITY".  It admitted, however, that the requested access level is READ and that her allowed access is READ.  So what means "DATASET NOT AVAILABLE"?

Some additional data, possibly relevant:

1) The dataset doesn't actually exist.  As implied by the HLQ, this is how this installation lets CICS transactions query TSS regarding authority to specific options; "OTRAN" is an HLQ that corresponds to no actual dataset, and "VWSM" identifies the transaction involved.  The rest of the DSN is invented by the CICS programmer.

2) The problem was fixed by my permitting her DATASET(OTRAN.VWSM.) ACC(ALL).  I don't know whether it's the ACC(ALL) part that made the difference, or the broader DSN.  I'm reluctant to believe either hypothesis, simply because TSSUTIL reported the exact DSN and access level required (and, again, admitted that she had the access).

3) Although I'm new to this installation, I'm assured that both the transaction involved and the specific DSN for this option are at least six years old.  I haven't heard that anyone else has suddenly started complaining about this access in the last few hours.

Can someone tell me what the heck is going on here?  Start, please, by explaining the *08*-70 code:  What can it mean?

70=Dataset Accessed through unauth  Facility

What, you mean like maybe I gave her the access only in the test CICS region?  No, I didn't specify a region on that PERMIT statement.  And of course she already had access to CICSPROD.  Besides, I admit you had me going a minute but it won't fly:  If the problem was actually the facility, then the problem wouldn't have been solved by my broadening the dataset access to OTRAN.VWSM.; an actual facility problem would have objected to the dataset in that case too.

However, that certainly sounds like the intended meaning of that line from the legend.  Maybe the problem isn't my reading after all, but something I should open a case for.  Anyone have other ideas?  I still expect it's just me missing something obvious.

Hold everything!  I got you, sucker!  (I'm talking to to the problem, Robert, not to you.)  Far up this user's profile list, 'way ahead of one I added, is a profile with this permission:

DSNAME    = OTRAN.**
 ACCESS   = READ    
 FACILITY = CICSTEST

I saw it before, but assumed that it wasn't significant because it was about CICSTEST, not CICSPROD; therefore (I thought) TSS wouldn't consider it a a match to the current situation.  But I went to TSSSIM to be sure of what's going on and it's pretty clear.  I supposed that DATASET(OTRAN.**) FAC(CICSTEST) means "if FAC(CICSTEST) then the user has DATASET(OTRAN.**).  But TSS apparently thinks this means "if DATASET(OTRAN.**) then the permission is granted but only in CICSTEST".  That's a very odd way of behaving (he says discontentedly), but it's easy to see how I must fix things.

So you were right after all, Robert Lynch.  Thanks.  Oh, and the reason that my adding DATASET(OTRAN.VWSM.) worked is that I added it to her ACID directly rather than in some profile at the end of the line.

You have found the answer anyway, so just as an additional hint:

To answer questions like this, TSSSIM (+TRACE Option) could be helpful

LOL, thanks, Josef; that's exactly how I found the above, by using TRACE in TSSSIM.  It pointed me straight to that profile.  I gotta get used to using TSSSIM more, I think.

 ... well, I had discovered TSSSIM as really helpful, when security has to be reworked, but "negative impacts" to business have to be avoided: Transform AUDIT/TSSUTIL-data into TSSSIM-Batch-Statements and compare TSSSIM of original and reworked security. And, not only for this purpose, TSSSIM-Batch could even be improved ... Complete TSSSIM BATCH