Sri h Kolusu kindly wrote: >DFSORT already have some examples of creating ICETOOL reports based on output >files from the RACF database unload utility (IRRDBU00) or the SMF data unload >utility (IRRADU00). The SYS1.SAMPLIB member IRRICE contains DFSORT statements >for record selection and ICETOOL statements for report formatting for a wide >variety of reports.
I'm absolutely very familiar with them and have reviewed them before I posted. But Many Thanks. >Also Mark Nelson from RACF has given a presentation at share "As Cool as Ice: >Analyzing Your RACF Data Using DFSORT™ and ICETOOL" which can be found here I also have this ice cool presentation. ;-) >Also RACF has a downloadable utility JCL to create reports using DFSORT. Thanks. I need to hover there again, was there many moons ago. >I hope this will get you started and if you still need help with creating a >specific report, I don't need help with writing. I am asking whether it is a good thing or not to protect individual DFSORT and ICETOOL commands/keywords just like you do it with DFDSS ADMINISTRATOR keyword for example. From all the online and off-list comments I see and agree: It is a bad idea. Just protect the data (input+output) and be finished. I will tell my auditors it is not a good idea to try to protect tools and commands+keywords. John McKown wrote: >To me, DFSORT/ICETOOL is basically a "programming language" which is used to >read some input, transform, and produce output. Good analogy. DFSORT is a ‘programming language’ used to manipulate data. Shane Ginnane wrote: >Both banks as it happened, but shows your folks just need to get properly >motivated. and Ed Finnell wrote: >It goes further nowadays. After it's processed by a program it's on spool or >report writer and can be modified again. Over on AFP list one group wanted to >change leading spaces to '*' maybe in a PAGEDEF. It was pointed out that if >you allowed this somebody else could change leading spaces to '9'.. The big >cut sheet all-in-ones also serve as copiers! Ouch. And so on with all subsequent parts of data. Lizette Koehler wrote: >Would you not protect the input (SORTIN) and output(SORTOUT) with RACF from >update where appropriate? Like any 4GL, DFSORT control cards is not where I >would rely on security. It would be with the files themselves. and Martin Packer wrote: >Just this week I had a discussion with an IBM specialist supporting a European >customer where the companion topic of stopping sysprogs from subverting SMF >records came up. Protect the data is the key. And SMF 15 might be useful for >tracking updates. and retired mainframer wrote: >Based on your examples, it appears the input data to SORT is produced by the >RACF database and SMF unload tools. Indeed. I agree with all, you protect the data, not the tools used. >Why should some further minor tweaks be a concern? If the auditors want the >unvarnished facts, they should be working from a database dump and the raw >SMF. Oh yes, I can always demonstrate that I can repeat the reporting/sorting/dumping using same source of ‘unvarnished facts’. Many thanks to all. I really appreciate your ice cool ideas and suggestions. Thanks for sorting me out! ;-) Groete / Greetings Elardus Engelbrecht! “When getting advice, believe half of what you read and none of what you hear.” ;-) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
