Re: Sort order for Generic processing
Okay, My first choice was originally to sort the generics last, and since it's good enough for RACF, it's good enough for me. I wrote a little routine to test the processing out and found that my sort routine can sort between 2 and 1,000 entries fast enough that I can't tell the difference between sorting and not sorting the array. So I guess there is no reason to limit the array to 1,000 entries. Thank you very much for your opinions on this, it was driving me nuts with not being able to decide one way or the other. Thanks again, Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Sort order for Generic processing
On Tue, 8 Apr 2008 10:08:29 -0500, Rick Fochtman [EMAIL PROTECTED] wrote: In RACF sorts, the generic names usually follow the more specific names. RACF treats the '' as x'FE' and the '*' as x'FF' for sorting purposes. You might try the same; a simple translate on each name will set it up and you can use the same translate table to go the other way after the sort. Roughly right, Rick. He doesn't really care about (for which RACF uses x'FA' in the general case). For % we use often use x'FB' and for * we often use x'FC'. There are some subtle fine points that can change those values a little, but he probably doesn't need to worry about them. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Sort order for Generic processing
---snip Roughly right, Rick. He doesn't really care about (for which RACF uses x'FA' in the general case). For % we use often use x'FB' and for * we often use x'FC'. There are some subtle fine points that can change those values a little, but he probably doesn't need to worry about them. -unsnip-- Apologies for my inaccuracies. The last time I even LOOKED at this was RACF 1.4, so it's been a while. Forgive me for my confusion in the details. But I think the general idea will be helpful to the OP. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Sort order for Generic processing
On Tue, 8 Apr 2008 13:04:04 -0500, Rick Fochtman [EMAIL PROTECTED] wrote: Apologies for my inaccuracies. The last time I even LOOKED at this was RACF 1.4, so it's been a while. Forgive me for my confusion in the details. But I think the general idea will be helpful to the OP. I certainly agree with that, Rick. The idea was the important part; not specific details. I should have made sure to say so. Sorry. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Sort order for Generic processing
Hi All, I've been thinking this over for a while and have coded it up several ways (they all seem to be about the same amount of CPU time in the small tests) and I'm still wondering about the overhead of the various processes. I have a feature that allows the user to enter options that I will perform for various JOBNAME/TASKNAMEs, and I would like to be able to provide the ability to use generic name processing for the JOB/TASK names like: ABC%%%G and ABC*, etc. I sort the names internally, then process them sequentially, (I use logic to limit the processing pretty well), but I keep thinking that there must be a better/more efficient way to do this. I control the sort (I wrote my own), and that's another thing, I keep flip/flopping on whether or not the % and * should be first or last in the search sequence, there seem to be advantages both ways. I want to be sure that I always use the more specific name first, but I don't want to do too much processing either. I figured that I would allow for no more than 1,000 entries, (any more than that and they better be thinking of using more generics anyway:), but I can see that at some point I might want to expand it to more entries), so even if I ended up doing it inefficiently, I don't think that the overhead would be noticed, but it still bothers me. So to end my agony of this, (and I'm probably thinking about it too much), I wanted to ask if anyone had any suggestions on what they thought might be the best approach. Any comments would be appreciated, Thanks, Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
