RE: [U2] [BB] U2 Enhancement Request - WRITE
I *think* this is historical. It used to be that ON ERROR didn't exist (I don't think ELSE existed initially!). So I guess that ELSE was added to deal with failed writes but not with file isn't there type problems, then ON ERROR was added to deal with those. I think originally, when even ELSE didn't exist, *any* problem with a WRITE would cause your program to bomb. But that was in the days before networks were the norm, and absent hardware failure any failure in a WRITE was almost certain to be a programming error of some sort. Cheers, Wol -Original Message- From: Perry Taylor [mailto:[EMAIL PROTECTED] Sent: 23 May 2007 21:08 To: u2-users@listserver.u2ug.org Subject: RE: [U2] [BB] U2 Enhancement Request - WRITE Be wary of ON ERROR. There are a few conditions under which ON ERROR is not taken where I really think it should and some anomalous return values from STATUS(). Here is an example from a support case I submitted to IBM some time ago ... WRITE ITEM ON F.VAR, ITEM.ID ON ERROR CRT 'ERROR': END THEN CRT 'THEN': END ELSE CRT 'ELSE': END CRT ', STATUS()=': STATUS() When I run this on a uniVerse hashed file for which I do not have write permissions I get… Program PTEST2: Line 23, WRITE attempt on read-only file. ELSE, STATUS()=-2 1) Why do I get the message 'Program PTEST2: Line 23, WRITE Attempt on read-only file.' when I am using the ON ERROR clause. 2) Shouldn't the ON ERROR clause have been taken rather than ELSE? 3) Why does STATUS() return -2, which according to the documentation is The record was unlocked before the WRITE operation.? 4) Looking at all the possible return codes from STATUS() after a WRITE it does not appear that there is a way to determine that the cause for failure is a permissions denial. Is this not possible to detect? The answers I got ... 1) (In a nut shell) No way to suppress this. 2)ON ERROR is only branched to on a fatal error which, in your test case (no permission), is not considered fatal - and as such the testing of status() is invalid. Fatal errors are file not opened, file handle is null, a part file for a distributed file is not found. 3) Unknown 4) No there is not. Have to write your own permissions-checking routine There are similar issues with OPENSEQ relating to permissions issues. FYI. Perry Taylor ZirMed, Inc. 626 West Main St , 6th Floor ● Louisville, KY 40202 www.zirmed.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Cipollina Sent: Wednesday, May 23, 2007 2:48 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] [BB] U2 Enhancement Request - WRITE Like anyone could ever know that! Thanks, Nick Cipollina -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Karen Bessel Sent: Wednesday, May 23, 2007 1:11 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] [BB] U2 Enhancement Request - WRITE Use the write ON ERROR clause to display info about the error using STATUS, FILEINFO, etc. Any time that I've ever encountered an abort in a BASIC program due to a write error, it's given me the source code line #. I can then look at the source code to see what file was being written to and start my investigation there. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Joslyn Sent: Wednesday, May 23, 2007 12:33 PM To: u2-users@listserver.u2ug.org Subject: [U2] [BB] U2 Enhancement Request - WRITE When a BASIC program in either U2 flavor attempts a write to a file that cannot be written to the program bombs completely out to TCL and no information is given about the file, nor about the specifics (is it the owner, the group, the RWX permissions?). There are system commands in both flavors that can be used to query a file's write-ability before attempting the WRITE. Before I go try to find every write in the system and put that check into place, I'm wondering why can't the write itself do this? Ideally not bomb out of the program, but even if that is hard to correct, reporting the NAME OF THE FILE that couldn't be written to would save many hours of system scouring! Susan Joslyn --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail
RE: [U2] UVODBC port
DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please delete it and notify the sender immediately. Please note that there is no guarantee that this email or any attachment is virus free or has not been intercepted or amended. Answering my own question here, but it may be of use to someone else. If you edit the uni.config file in C:\IBM\UniDK\Config and append the host address with a colon and the new port number it will use the specified port. The default is 31438 and the example below shows the client is now set to use 31439 for the localhost connection. This is set per server so you can connect on different ports to different servers. (remember to make the change on the server too to listen on the right port) localuv DBMSTYPE = UNIVERSE network = TCP/IP service = uvserver host = localhost:31439 Andy Moore Selima Software Tel : 0114 2815000 Fax : 0114281 Support : http://tracker.selima.co.uk Forum : http://forum.selima.co.uk -Original Message- From: Andy Moore Sent: 22 May 2007 16:54 To: u2-users@listserver.u2ug.org Subject: [U2] UVODBC port DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please delete it and notify the sender immediately. Please note that there is no guarantee that this email or any attachment is virus free or has not been intercepted or amended. Hi all, On the old style UVODBC I know how to change the client to use any port from 512 to anything. However we have a problem with the new UVODBC and I need to change it's port. I know how to do it on the server, but does anyone know how to tell the clients to use a different port? Thanks Andy Moore Selima Software Tel : 0114 2815000 Fax : 0114281 Support : http://tracker.selima.co.uk Forum : http://forum.selima.co.uk --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[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/
[U2] [BB] Enhancement - WRITE
Well, gang . I think that the U2's should be smarter about reporting what file can't write and WHY and also failing more gracefully than a SPLAT to TCL. Nevertheless, since IBM is not interested in my idea now that I'm on a PE edition and y'all didn't jump all over the idea - I'll go revamp all WRITEs through a subroutine (particularly obnoxious since you can't pass file variables as arguments in one of the flavors, I forget which). So now, I'm digging around looking for a command in BASIC that will let you test the waters - check a file for write-ability. And I'm coming up dry. I have stuff that does status on files but I don't see that I can test write permissions from there. Anyone? [If you could copy me on your reply I'd appreciate not having to wait for the digest. ] Thanks a mil! Susan ([EMAIL PROTECTED]) --- 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
Re: [U2] [BB] Enhancement - WRITE
If you do a STATUS [not to be confused with STATUS()] on a file, you can check read-write permissions, as well as uid/gid. type this at TCL: HELP BASIC STATUS which will give you both Windows and Unix help. HTH, Karl quote who=Susan Joslyn Well, gang . I think that the U2's should be smarter about reporting what file can't write and WHY and also failing more gracefully than a SPLAT to TCL. Nevertheless, since IBM is not interested in my idea now that I'm on a PE edition and y'all didn't jump all over the idea - I'll go revamp all WRITEs through a subroutine (particularly obnoxious since you can't pass file variables as arguments in one of the flavors, I forget which). So now, I'm digging around looking for a command in BASIC that will let you test the waters - check a file for write-ability. And I'm coming up dry. I have stuff that does status on files but I don't see that I can test write permissions from there. Anyone? [If you could copy me on your reply I'd appreciate not having to wait for the digest. ] Thanks a mil! Susan ([EMAIL PROTECTED]) --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- Karl Pearson Director of I.T. ATS Industrial Supply, Inc. [EMAIL PROTECTED] http://www.atsindustrial.com 800-789-9300 x29 Local: 801-978-4429 Fax: 801-972-3888 To mess up your Linux PC, you have to really work at it; to mess up a microsoft PC you just have to work on it. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
