[U2] A question of dictionaries.
Hi Stuart. Yes, modifying a dictionary is an issue. Sarbanes-Oxley is primarily concerned with financial fraud. There are other regulations that are more focused on other things. In the case of SOX if you could modify report output by manipulating a dictionary there is the potential for financial fraud. In theory the auditors would spot check only reports or dictionaries that directly impact financial reporting. But you may as well implement a universal strategy. Changing the permissions on all the dictionaries might not be my choice because - you are on SB+, I think? There are things that get updated into the dictionary at runtime. My approach usually includes a combination of file permissions and triggers but primarily I lean toward controlling the tools. With remote vocs you can very tightly control the tools. Susan p.s. or, you could just buy PRC and voila! ;) Date: Thu, 24 May 2007 11:23:20 +1000 From: Boydell, Stuart [EMAIL PROTECTED] Subject: [U2] A question of dictionaries. We are implementing source control here and I was wondering, in light of data protection and source control best practice and the US list members experience of Sarbanes-Oxely, if anyone is currently running their production systems using OS level (D_filename) read-only dictionaries. I know that EVAL and SQL NEXT.ACCUMULATOR statements which write back to the dictionary will fail but have you encountered any other gotcha's? Or if you have contemplated the idea of locking dictionaries, but abandoned it, why? I'm also curious to find out (as Australia legislation has been influenced by it) what the implications as far as SOX is concerned where a user can potentially [if they gain access to a writable dictionary] change a reporting column, or doesn't it go that far? Cheers, Stuart Boydell --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] A question of dictionaries.
Hi Stuart Another option is to use the security features in the voc, ie Field 4 of the Voc item. You could restrict who has access to Revise and Editor and could even log what they are doing. Regards David Jordan Managing Consultant --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] A question of dictionaries.
Bottom line, dictionaries should be controlled. Period. I lock the dicts with os-level permissions. Just live wth EVAL restrictions. SQL not used much. For those few cases where EVAL is important: - references a limited copy of the full dictionary where the user can write. - via a 2nd F-pointer - via the USING keyword - or run the affected reports in background by dict owner We happily use PRC here, it emphasizes control of the tools such as ED, as Susan suggests. So we do both, control tools OS permissions. For other shops I have written UV frontends to RCS and MS Visual SourceSafe. One can control: - each dict item as a separate flat file, where there is a source controlled directory for each dictionary. - the entire dictionary in one controlled flat text file, using a utility to pack and unpack. I favour this with RCS because then you can use rcs keywords in a header section. And complicated dicts use I-, PH-items correlatives that reference one another, so entire dict needs tracking recompilation when one dict item is changed. Chuck Stevenson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] A question of dictionaries.
Mark, In my early days of consulting, many years ago, I had a client whose CFO insisted that anything that I wrote that *could* be written in English (UniQuery under its original Microdata name) be written that way, even if it was less efficient, because then if it needed changing when I was not on-site, he could do it himself. After he was let go, I got a frantic call from his assistant - a million dollar order was missing on the system. Turns out he had modified one of my dictionaries and created his own version of a report to only show an order once, not on subsequent months, because the production team did not want to get flak from upper management about orders that had not yet completely shipped. It took me a while to figure out what he had done and fix it so that they did not suddenly find themselves losing track of the huge orders. It also appeared that some reports had been modified (either in the dictionaries or in the selection criteria) so that some cash audit reports were, shall we say, less than clear in terms of what was not reported. So, *that* kind of user (no inhibitions at all!) does need to be constrained, if only so that there will be documentation of what the system is doing after they leave the company! Susan Lynch F W Davison Company, Inc. - Original Message - From: MAJ Programming [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, May 24, 2007 11:41 AM Subject: Re: [U2] A question of dictionaries. I should add a comment to your post regarding the user changing a reporting column. This borders on a very slippery topic regarding the user's access to the system. In my travels, many systems prevent their access to TCL. Those that allow access only give the users a very, very limited set of commands like LIST and SORT and perhaps SELECt but never EDIT or BASIC etc. Plus the user's natural inhibitions prevent them from learning (retaining) what they may see us typing. So I guess my question is what kind of 'user' could actually change a reporting column to begin with. In many of my clients' systems there are formal, menu-driven reports with specific indicators in the headings for report identification. The users who make their own English report never, never use HEADING so that would be my first sign of a renegade report. I don't use EVAL or other live dict items and I can't imagine the most serious non-MV user crossing over that line. We programmers, having the keys to the entire castle, sometimes feel that the users are only one small step behind us. Everytime I think that they're near me, I'm reminded of how contained they actually are. For over a quarter of a century I've been trying to show users the simplicity of creating their own reports in English. I've found that you can lead a horse to water but you cannot make them drink. I've seen users decline retaining education after attending Crystal Reports classes, Excel Classes, Powerpoint classes and even MS Access classes. I don't think they will take a liking to our dictionaries. My 2 cents Mark Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] A question of dictionaries.
I have a feeling that this one could go on a bit. Far be it for me to break the chain... We have separate accounts that exist solely for the purpose of users who have tcl access. Within those accounts, is a minimum of potentially damage causing verbs. But, if security is a BIG priority, the most potent method that I know of, is to make every 'attribute' that needs guarding, an itype, that is hooked to an 'attribute.security' subroutine that contains a test which returns the field's attribute number contents if the user can see all of the fields and maybe null if the user isnt supposed to see the contents. The sub parses everything in the sentence that is a LIST or SORT etc, throwing out key words and verbs. The security file contains allowed , disallowed ( or both), file names that probably can be keyed by user id or some class of users, such as a function oriented job code. Field 1 might contain strings of file.names that the user has even potential access to, and field 2, contains the attribute names, subvalued according to file name, or maybe an asterisk if the user can see anything in that file. Separate security is also placed upon the other VERBs in the account that could be used to side step attribute security (using VOC REC1=R, VOC REC4=*VERB.SECURITY.ROUTINE',) but verbs that would be really nice to have for those who have to maintain accounts... such as copy, ED (all the ED's maybe even EV) etc. And dont forget to delete or rename the EVAL keyword. So when the 'PAUL SARBANES (D-MD)' auditors come by and say, 'how do you PROPOSE to limit the view resulting from ad hoc queries, you can have an answer for them? . On 5/24/07, Susan Lynch [EMAIL PROTECTED] wrote: Mark, In my early days of consulting, many years ago, I had a client whose CFO insisted that anything that I wrote that *could* be written in English (UniQuery under its original Microdata name) be written that way, even if it was less efficient, because then if it needed changing when I was not on-site, he could do it himself. After he was let go, I got a frantic call from his assistant - a million dollar order was missing on the system. Turns out he had modified one of my dictionaries and created his own version of a report to only show an order once, not on subsequent months, because the production team did not want to get flak from upper management about orders that had not yet completely shipped. It took me a while to figure out what he had done and fix it so that they did not suddenly find themselves losing track of the huge orders. It also appeared that some reports had been modified (either in the dictionaries or in the selection criteria) so that some cash audit reports were, shall we say, less than clear in terms of what was not reported. So, *that* kind of user (no inhibitions at all!) does need to be constrained, if only so that there will be documentation of what the system is doing after they leave the company! Susan Lynch F W Davison Company, Inc. - Original Message - From: MAJ Programming [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, May 24, 2007 11:41 AM Subject: Re: [U2] A question of dictionaries. I should add a comment to your post regarding the user changing a reporting column. This borders on a very slippery topic regarding the user's access to the system. In my travels, many systems prevent their access to TCL. Those that allow access only give the users a very, very limited set of commands like LIST and SORT and perhaps SELECt but never EDIT or BASIC etc. Plus the user's natural inhibitions prevent them from learning (retaining) what they may see us typing. So I guess my question is what kind of 'user' could actually change a reporting column to begin with. In many of my clients' systems there are formal, menu-driven reports with specific indicators in the headings for report identification. The users who make their own English report never, never use HEADING so that would be my first sign of a renegade report. I don't use EVAL or other live dict items and I can't imagine the most serious non-MV user crossing over that line. We programmers, having the keys to the entire castle, sometimes feel that the users are only one small step behind us. Everytime I think that they're near me, I'm reminded of how contained they actually are. For over a quarter of a century I've been trying to show users the simplicity of creating their own reports in English. I've found that you can lead a horse to water but you cannot make them drink. I've seen users decline retaining education after attending Crystal Reports classes, Excel Classes, Powerpoint classes and even MS Access classes. I don't think they will take a liking to our dictionaries. My 2 cents Mark Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- john --- u2-users mailing list u2-users@listserver.u2ug.org
[U2] A question of dictionaries.
We are implementing source control here and I was wondering, in light of data protection and source control best practice and the US list members experience of Sarbanes-Oxely, if anyone is currently running their production systems using OS level (D_filename) read-only dictionaries. I know that EVAL and SQL NEXT.ACCUMULATOR statements which write back to the dictionary will fail but have you encountered any other gotcha's? Or if you have contemplated the idea of locking dictionaries, but abandoned it, why? I'm also curious to find out (as Australia legislation has been influenced by it) what the implications as far as SOX is concerned where a user can potentially [if they gain access to a writable dictionary] change a reporting column, or doesn't it go that far? Cheers, Stuart Boydell ** This email message and any files transmitted with it are confidential and intended solely for the use of addressed recipient(s). If you have received this communication in error, please reply to this e-mail to notify the sender of its incorrect delivery and then delete it and your reply. It is your responsibility to check this email and any attachments for viruses and defects before opening or sending them on. Spotless collects information about you to provide and market our services. For information about use, disclosure and access, see our privacy policy at http://www.spotless.com.au Please consider our environment before printing this email. ** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
