RE: [U2] [UV] SETREM & REMOVE (bug in SETREM)
A quick test on uv 10.0.8 And results was A A A A A A As expected. Regards, Stewart -Original Message- From: Ray Wurlod [mailto:[EMAIL PROTECTED] Sent: Friday, 10 June 2005 15:42 To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UV] SETREM & REMOVE (bug in SETREM) What happens if you use different SETTING variables? Maybe setting DUMMY when removing from B(1) interferes with the REMOVE from A. From your example it appears to be REMOVE that's not working properly rather than SETREM. - Original Message - From: "Womack, Adrian" <[EMAIL PROTECTED]> To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UV] SETREM & REMOVE (bug in SETREM) Date: Fri, 10 Jun 2005 09:05:28 +0800 > > Here's a simple example: > > DIM B(2) > A = "A":@VM:"B":@VM:"C" > B(1) = A > FOR X = 1 TO 3 > SETREM 0 ON A > SETREM 0 ON B(1) > REMOVE A1 FROM A SETTING DUMMY > REMOVE B1 FROM B(1) SETTING DUMMY > CRT A1,B1 > NEXT X > END > > And this is the output... > A A > A B > A C > --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ** This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete the original message and all copies. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. ** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] SETREM & REMOVE (bug in SETREM)
Changing the second DUMMY variable to DUMMY2 makes no difference. I tried the same code in a "PICK" flavour account and it worked properly! I checked VLIST on the SETREM statement and the code produced in PICK flavour is different to that produced in PI/Open flavour! So, maybe it's a PI/Open flavour specific problem. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Wurlod Sent: Friday, 10 June 2005 2:12 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UV] SETREM & REMOVE (bug in SETREM) What happens if you use different SETTING variables? Maybe setting DUMMY when removing from B(1) interferes with the REMOVE from A. From your example it appears to be REMOVE that's not working properly rather than SETREM. DISCLAIMER: Disclaimer. This e-mail is private and confidential. If you are not the intended recipient, please advise us by return e-mail immediately, and delete the e-mail and any attachments without using or disclosing the contents in any way. The views expressed in this e-mail are those of the author, and do not represent those of this company unless this is clearly indicated. You should scan this e-mail and any attachments for viruses. This company accepts no liability for any direct or indirect damage or loss resulting from the use of any attachments to this e-mail. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] Triggers, RAID and SQL 2005
We use them. they're good, though slower than i-type pseudo triggers, they give more flexibility. Triggers begin a transaction, which you aren't supposed to be able to step through using a debugger. Regards, -- Stuart Boydell [EMAIL PROTECTED] wrote on 10-06-2005 13.57.58: > I have found what I believe to be a problem with implementing triggers > in UniVerse. > > If I have a trigger on a file and a developer is trying to resolve a > problem in a program which happens to update/delete that file an issue > using 'RAID' the debugger ;-) When the developer steps over the > write statement, which in itself can be hard to determine when that will > be given RAID's ability to not display the real debug position, then the > trigger fails as no input is allowed within a trigger, and the program > does not complete as normal. > > Granted you normally do not debug a program in production, but sometimes > you may have to, and in any case in development you would still have > triggers in, so as I see it this issue must be resolved. For if not I > cannot see how I can propose using triggers at all. > > On a philosophical note, I cannot see why you cannot debug trigger code > or indeed have an input statement if that is what you inclined to > dolet the developer hang themselves... > > As a matter of interest how many people are using triggers? > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ** 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 email in error please notify the Spotless IS Support Centre (61 3 9269 7555) immediately who will advise further action. This footnote also confirms that this email message has been scanned for the presence of computer viruses. ** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Stuart Boydell is on annual leave.
I will be out of the office starting 10-06-2005 and will not return until 14-06-2005. I will respond to your message when I return. ** 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 email in error please notify the Spotless IS Support Centre (61 3 9269 7555) immediately who will advise further action. This footnote also confirms that this email message has been scanned for the presence of computer viruses. ** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] Triggers, RAID and SQL 2005
I know that are good as they are very powerful. My point is I cannot deploy them, if developers cannot debug programs which happen to contain writes to files which have a trigger on them. I also know they start an implicit transaction. This in itself does not mean that you cannot use a debugger as when I state an explicit transaction in BASIC this is not the case. Personally, I do not see the need to restrict a user from being able to debug a trigger program, or indeed have an input statement, if there is an interactive user on the end of it, if the developer wants to do such a thing ;-). However as IBM is unlikely to change this, I would at the very least hope to be able to use the debugger on a program which writes to the file with the trigger on it, and for the write not to fail when the write occurs with a message saying no input is allowed. Universe should be able to determine that the code is a trigger and that execution should continue until control returns to the program being debugged. I will try when I get a chance to see if I can set a break point after the write to see if the program still fails on the write to the file with the trigger on it. Although that is still not ideal... Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, 10 June 2005 8:16 p.m. To: u2-users@listserver.u2ug.org Subject: Re: [U2] [UV] Triggers, RAID and SQL 2005 We use them. they're good, though slower than i-type pseudo triggers, they give more flexibility. Triggers begin a transaction, which you aren't supposed to be able to step through using a debugger. Regards, -- Stuart Boydell [EMAIL PROTECTED] wrote on 10-06-2005 13.57.58: > I have found what I believe to be a problem with implementing triggers > in UniVerse. > > If I have a trigger on a file and a developer is trying to resolve a > problem in a program which happens to update/delete that file an issue > using 'RAID' the debugger ;-) When the developer steps over the > write statement, which in itself can be hard to determine when that > will be given RAID's ability to not display the real debug position, > then the trigger fails as no input is allowed within a trigger, and > the program does not complete as normal. > > Granted you normally do not debug a program in production, but > sometimes you may have to, and in any case in development you would > still have triggers in, so as I see it this issue must be resolved. > For if not I cannot see how I can propose using triggers at all. > > On a philosophical note, I cannot see why you cannot debug trigger > code or indeed have an input statement if that is what you inclined to > dolet the developer hang themselves... > > As a matter of interest how many people are using triggers? > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ** 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 email in error please notify the Spotless IS Support Centre (61 3 9269 7555) immediately who will advise further action. This footnote also confirms that this email message has been scanned for the presence of computer viruses. ** --- 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/
RE: [U2] access via disabled accounts (solution) - How?
I like the sounds of this type of data security. I'm still kind of new with VB.NET and UniObjects, but have a healthy concern for security. Could someone please answer this for me: How can you pull data from a U2 file, via UniObjects, manipulate it in VB.NET, and write it back to the file, via UniObjects, via stored procedures, and without directly accessing the files from UniObjects? I'm just looking for basic general info, but if you happen to have code snippets, too, that would be greatly appreciated. I'm having trouble envisioning how this works. Thanks, in advance! - Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jordan Sent: Thursday, June 09, 2005 8:58 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] access via disabled accounts (solution) << Within UniVerse you can do the same thing. You can restrict user read, write, delete access to the database either setting OS level file access or by SQL security access. With the AUTHORIZE statement, you can allow subroutines to have a different access rights. Thus from UniObects one can only access the database through subroutines and they cannot do anything else. >> <> Within UniVerse Basic is an AUTHORIZE Statement which allows you to give the program different access rights to the user running the program. Ie AUTHORIZE "Administrator" This would give the program the access rights of Administrator at SQL security or OS file security level. The program has to be compiled by the user who the authorize statement will adopt as user rights ie the example above would have to be compiled by Administrator. ED BP TEST AUTHORIZE "Administrator" ... OPEN "","TEST" TO FV ELSE... ... WRITE REC TO FV,KEY User Joe has no access rights to the UniVerse data files either by setting OS file level security or by not GRANTing access if SQL level security installed. IF Joe did ED TEST 123 the system would not grant him access But if Joe runs the program TEST it would write the record to TEST file. Regards David Jordan --- 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/
RE: [U2] [UV] Triggers, RAID and SQL 2005
Just to add fuel to the fire - UniData triggers have no such constraints. In fact, using the debugger was how I discovered that our (old) development team thought it would be a good idea to install triggers on a large client site at the end of the day. The next morning wasn't a good day in support as the triggers weren't quite production ready. The worst part was that support started 3 hours before development (although in this case it probably saved lives...). Colin Alfke Calgary, AB >-Original Message- >From: phil walker > >I know that are good as they are very powerful. My point is I >cannot deploy them, if developers cannot debug programs which >happen to contain writes to files which have a trigger on >them. I also know they start an implicit transaction. This in >itself does not mean that you cannot use a debugger as when I >state an explicit transaction in BASIC this is not the case. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] access via disabled accounts (solution) - How?
Hi Dave
<>
A Stored Procedure is just a UniBasic Subroutine. From UniObjects .Net you
would only get data from and write data to the database through the
subroutines (unirpc). The subroutines would have the AUTHORIZE Statement.
You would not use the UniObjects File IO routines.
Ie UniBasic
SUBROUTINE TESTIO(METHOD,FILE,KEY,REC,ERROR)
AUTHORIZE "Administrator"
IF METHOD = "READ" THEN
OPEN '',FILE TO FV ELSE
READ REC FROM FV, KEY ELSE
RETURN
END
FROM VB.NET
Dim Subr = Uvo.CreateUniSubroutine("TESTIO", 5)
SUBR.SETARG(0,"READ")
SUBR.SETARG(1,"VOC")
SUBR.SETARG(2,"RELLEV")
SUBR.CALL
REC = SUBR.GETARG(3)
...
Hence you restrict all File IO through UniBasic Subroutines
Regards
David Jordan
Managing Consultant
DACONO Holdings Pty Ltd
PO Box 909
Lane Cove
NSW 2066
Australia
Phn: 61 2 9418 8329
Fax: 61 2 9427 2371
Mobile: 0428 669 730
Email: [EMAIL PROTECTED]
www.dacono.com.au
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
[U2] [AD] Kansas City UniVerse Users - Complimentary consulting visits available
This is your opportunity to get answers to some of those "burning questions" you have. I will be in the Greater Kansas City area the week of July 18th and have three complimentary four-hour on site consulting visits still available. This visit consists of two presentations of your choice from a list of UniVerse technical or Best Practices topics followed by a two hour free-form question and answer period. This is your chance to ask those nagging questions of a UniVerse product expert and instructor with 30 years experience in the MultiValued database environment. To request one of these appointments, get more information, or to find out when I will be in your area, please send your contact information to [EMAIL PROTECTED] -- Regards, Clif http://www.oliver.com/bio.html ~~~ W. Clifton Oliver, CCP CLIFTON OLIVER & ASSOCIATES Tel: +1 619 460 5678Web: www.oliver.com ~~~ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] Triggers, RAID and SQL 2005
No, you can't get past the write statement if you are running a program in RAID. If you hit a DEBUG statement then execute a GO, you're still not going to be able to get past the WRITE statement to a triggered file. At least that's been my experience not too long ago on UV 10.1. BobW > -Original Message- > From: [EMAIL PROTECTED] [mailto:owner-u2- > [EMAIL PROTECTED] On Behalf Of phil walker > Sent: Friday, June 10, 2005 2:50 AM > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] [UV] Triggers, RAID and SQL 2005 > > I know that are good as they are very powerful. My point is I cannot > deploy them, if developers cannot debug programs which happen to contain > writes to files which have a trigger on them. I also know they start an > implicit transaction. This in itself does not mean that you cannot use a > debugger as when I state an explicit transaction in BASIC this is not > the case. > > Personally, I do not see the need to restrict a user from being able to > debug a trigger program, or indeed have an input statement, if there is > an interactive user on the end of it, if the developer wants to do such > a thing ;-). However as IBM is unlikely to change this, I would at the > very least hope to be able to use the debugger on a program which writes > to the file with the trigger on it, and for the write not to fail when > the write occurs with a message saying no input is allowed. Universe > should be able to determine that the code is a trigger and that > execution should continue until control returns to the program being > debugged. > > I will try when I get a chance to see if I can set a break point after > the write to see if the program still fails on the write to the file > with the trigger on it. Although that is still not ideal... > > Phil > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Friday, 10 June 2005 8:16 p.m. > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] [UV] Triggers, RAID and SQL 2005 > > We use them. they're good, though slower than i-type pseudo triggers, > they give more flexibility. > Triggers begin a transaction, which you aren't supposed to be able to > step through using a debugger. > Regards, > -- > Stuart Boydell > > [EMAIL PROTECTED] wrote on 10-06-2005 13.57.58: > > > I have found what I believe to be a problem with implementing triggers > > > in UniVerse. > > > > If I have a trigger on a file and a developer is trying to resolve a > > problem in a program which happens to update/delete that file an issue > > > using 'RAID' the debugger ;-) When the developer steps over the > > write statement, which in itself can be hard to determine when that > > will be given RAID's ability to not display the real debug position, > > then the trigger fails as no input is allowed within a trigger, and > > the program does not complete as normal. > > > > Granted you normally do not debug a program in production, but > > sometimes you may have to, and in any case in development you would > > still have triggers in, so as I see it this issue must be resolved. > > For if not I cannot see how I can propose using triggers at all. > > > > On a philosophical note, I cannot see why you cannot debug trigger > > code or indeed have an input statement if that is what you inclined to > > > dolet the developer hang themselves... > > > > As a matter of interest how many people are using triggers? > > --- > > u2-users mailing list > > u2-users@listserver.u2ug.org > > To unsubscribe please visit http://listserver.u2ug.org/ > > > > ** > 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 email in error please notify the Spotless IS Support > Centre (61 3 9269 7555) immediately who will advise further action. > > This footnote also confirms that this email message has been scanned for > the presence of computer viruses. > ** > --- > 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/
RE: [U2] access via disabled accounts
Don't you folks think this is a bit of yelling "The sky is falling!"? I mean, who's going to produce a system that doesn't have audit trails, account verifications, or some other way of protecting against such illegal operations. Locks only keep honest people honest, and the same can be said of logins. This is an extreme example of what MIGHT happen but, again, how real is this threat? Maybe a documentation enhancement might be in order, but I don't see this as being something that IBM should have a finger shaken at them for. The person doing the criminal action is a crook and is risking jail time and probably will never working in the computer field again, once they are caught. Plan for being able to track what goes on and have a little faith that the people you hire to program around the "corporate jewels" are trustworthy. BobW > -Original Message- > From: [EMAIL PROTECTED] [mailto:owner-u2- > [EMAIL PROTECTED] On Behalf Of Martin Phillips > Sent: Thursday, June 09, 2005 9:14 AM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] access via disabled accounts > > > I'm not so sure I would call this a security hole. If I could figure > > it out, it might just be a security feature in that one could shut > > down access via UniObjects for users who have no business accessing > > the system that way. > > I go back to my original argument, perhaps explained more clearly (I hope) > this time > > Imagine you run a bank. Your employees log in each day from their desktop > PC > using a UniObjects based application and shuffle money about between > accounts. The application must have write access to the database files and > controls who can do what via its own internal security checks. > > A clever employee now writes a simple VB program that uses UniObjects and > puts it on his PC. This program connects to the server using his > username/password but, instead of calling the usual application modules, > uses UniObjects to open the files and transfer funds into his own account > totally outside the security of the application. > > Using any of the operating system or database security mechanisms shuts > out > the business application as well as the rogue user. > > The only way that I can see to close this hole is for UniObjects to have > an > option to restrict which operations the client end can request. At the > highest level, this should restrict the client so that all he can do is > call > existing catalogued programs that are compiled with some special compiler > mode directive. > > Come on... Someone convince me I'm wrong! > > > Martin Phillips > Ladybridge Systems > 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB > +44-(0)1604-709200 > --- > 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/
RE: [U2] access via disabled accounts
Don't you folks think this is a bit of yelling "The sky is falling!"? I mean, who's going to produce a system that doesn't have audit trails, account verifications, or some other way of protecting against such illegal operations. Locks only keep honest people honest, and the same can be said of logins. This is an extreme example of what MIGHT happen but, again, how real is this threat? Maybe a documentation enhancement might be in order, but I don't see this as being something that IBM should have a finger shaken at them for. The person doing the criminal action is a crook and is risking jail time and probably will never working in the computer field again, once they are caught. Plan for being able to track what goes on and have a little faith that the people you hire to program around the "corporate jewels" are trustworthy. BobW > -Original Message- > From: [EMAIL PROTECTED] [mailto:owner-u2- > [EMAIL PROTECTED] On Behalf Of Martin Phillips > Sent: Thursday, June 09, 2005 9:14 AM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] access via disabled accounts > > > I'm not so sure I would call this a security hole. If I could figure > > it out, it might just be a security feature in that one could shut > > down access via UniObjects for users who have no business accessing > > the system that way. > > I go back to my original argument, perhaps explained more clearly (I hope) > this time > > Imagine you run a bank. Your employees log in each day from their desktop > PC > using a UniObjects based application and shuffle money about between > accounts. The application must have write access to the database files and > controls who can do what via its own internal security checks. > > A clever employee now writes a simple VB program that uses UniObjects and > puts it on his PC. This program connects to the server using his > username/password but, instead of calling the usual application modules, > uses UniObjects to open the files and transfer funds into his own account > totally outside the security of the application. > > Using any of the operating system or database security mechanisms shuts > out > the business application as well as the rogue user. > > The only way that I can see to close this hole is for UniObjects to have > an > option to restrict which operations the client end can request. At the > highest level, this should restrict the client so that all he can do is > call > existing catalogued programs that are compiled with some special compiler > mode directive. > > Come on... Someone convince me I'm wrong! > > > Martin Phillips > Ladybridge Systems > 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB > +44-(0)1604-709200 > --- > 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/
RE: [U2] [UV] Triggers, RAID and SQL 2005
Hi, I will be out of the office from June 13th through June 15th. I will return on June 16. I will not have access to e-mail or voice mail. If a you need an immediate response to your e-mail please e-mail [EMAIL PROTECTED] or you can call Frank at extension 467. Thanks and have a great day! Josh --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] Triggers, RAID and SQL 2005
No DEBUG statement is involved, although the equivalent I guess in either a control-C followed by entering D or RAID from the command line. This is very frustrating as I know how powerful triggers can be, and I want to deploy them widely, but I cannot do this while this design BUG is there. Cheers, Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Woodward Sent: Saturday, 11 June 2005 10:01 a.m. To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UV] Triggers, RAID and SQL 2005 No, you can't get past the write statement if you are running a program in RAID. If you hit a DEBUG statement then execute a GO, you're still not going to be able to get past the WRITE statement to a triggered file. At least that's been my experience not too long ago on UV 10.1. BobW > -Original Message- > From: [EMAIL PROTECTED] [mailto:owner-u2- > [EMAIL PROTECTED] On Behalf Of phil walker > Sent: Friday, June 10, 2005 2:50 AM > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] [UV] Triggers, RAID and SQL 2005 > > I know that are good as they are very powerful. My point is I cannot > deploy them, if developers cannot debug programs which happen to contain > writes to files which have a trigger on them. I also know they start an > implicit transaction. This in itself does not mean that you cannot use a > debugger as when I state an explicit transaction in BASIC this is not > the case. > > Personally, I do not see the need to restrict a user from being able to > debug a trigger program, or indeed have an input statement, if there is > an interactive user on the end of it, if the developer wants to do such > a thing ;-). However as IBM is unlikely to change this, I would at the > very least hope to be able to use the debugger on a program which writes > to the file with the trigger on it, and for the write not to fail when > the write occurs with a message saying no input is allowed. Universe > should be able to determine that the code is a trigger and that > execution should continue until control returns to the program being > debugged. > > I will try when I get a chance to see if I can set a break point after > the write to see if the program still fails on the write to the file > with the trigger on it. Although that is still not ideal... > > Phil > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Friday, 10 June 2005 8:16 p.m. > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] [UV] Triggers, RAID and SQL 2005 > > We use them. they're good, though slower than i-type pseudo triggers, > they give more flexibility. > Triggers begin a transaction, which you aren't supposed to be able to > step through using a debugger. > Regards, > -- > Stuart Boydell > > [EMAIL PROTECTED] wrote on 10-06-2005 13.57.58: > > > I have found what I believe to be a problem with implementing triggers > > > in UniVerse. > > > > If I have a trigger on a file and a developer is trying to resolve a > > problem in a program which happens to update/delete that file an issue > > > using 'RAID' the debugger ;-) When the developer steps over the > > write statement, which in itself can be hard to determine when that > > will be given RAID's ability to not display the real debug position, > > then the trigger fails as no input is allowed within a trigger, and > > the program does not complete as normal. > > > > Granted you normally do not debug a program in production, but > > sometimes you may have to, and in any case in development you would > > still have triggers in, so as I see it this issue must be resolved. > > For if not I cannot see how I can propose using triggers at all. > > > > On a philosophical note, I cannot see why you cannot debug trigger > > code or indeed have an input statement if that is what you inclined to > > > dolet the developer hang themselves... > > > > As a matter of interest how many people are using triggers? > > --- > > u2-users mailing list > > u2-users@listserver.u2ug.org > > To unsubscribe please visit http://listserver.u2ug.org/ > > > > ** > 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 email in error please notify the Spotless IS Support > Centre (61 3 9269 7555) immediately who will advise further action. > > This footnote also confirms that this email message has been scanned for > the presence of computer viruses. > ** > --- > 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 mailin
[U2] Best practice for Sequential IDs using TRANSACTION START & COMMIT/ROLLBACK
For files with sequential numbers as record IDs, it is common practice to use a control item (in dictionary or in a special control table) to get the next sequential id counter, then write back the incremented counter ASAP so it is available for the next process that needs to do the same. Some variation on this theme (probably involving a utility subroutine): READVU SEQ.ID FROM ctrl.fvar, ctrl.id, n ... WRITEV SEQ.ID+1 TO ctrl.fvar, ctrl.id, n WRITE NEW.REC TO fvar, SEQ.ID === BUT: === If that happens inside an explicit transaction bounded by TRANSACTION START and TRANSACTION COMMIT (or TRANSACTION ROLLBACK), the Sequential ID control record will not actually be written and/or released until all updates are done/ditched during commit/rollback. If the transaction is extensive and involves many updates, this could be a serious bottleneck. Making sure that you read the next sequential id as close to the moment of executing the commit would be helpful, but that is not always an option in complicated transactions. What is the best practice for handling this? What is your experience? Bottlenecks? Ideally, I know what I'd prefer: I wish U2 would handle sequential ids internally for variants of Type-2 or dynamic SEQ.NUM files. That should have happened a couple decades ago in PI and Pick. But back to the real world. What is the best way to handle sequential IDs when using explicit TRANSACTIONs? cds --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] access via disabled accounts
Hey didn't you use to work at WorldCom or Enron? :) Security people are trained to be nervous around holes. Will Johnson Fast Forward Technologies -Original Message- From: Bob Woodward <[EMAIL PROTECTED]> To: u2-users@listserver.u2ug.org Sent: Fri, 10 Jun 2005 14:44:02 -0700 Subject: RE: [U2] access via disabled accounts Don't you folks think this is a bit of yelling "The sky is falling!"? I mean, who's going to produce a system that doesn't have audit trails, account verifications, or some other way of protecting against such illegal operations. Locks only keep honest people honest, and the same can be said of logins. This is an extreme example of what MIGHT happen but, again, how real is this threat? Maybe a documentation enhancement might be in order, but I don't see this as being something that IBM should have a finger shaken at them for. The person doing the criminal action is a crook and is risking jail time and probably will never working in the computer field again, once they are caught. Plan for being able to track what goes on and have a little faith that the people you hire to program around the "corporate jewels" are trustworthy. BobW > -Original Message- > From: [EMAIL PROTECTED] [mailto:owner-u2- > [EMAIL PROTECTED] On Behalf Of Martin Phillips > Sent: Thursday, June 09, 2005 9:14 AM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] access via disabled accounts > > > I'm not so sure I would call this a security hole. If I could figure > > it out, it might just be a security feature in that one could shut > > down access via UniObjects for users who have no business accessing > > the system that way. > > I go back to my original argument, perhaps explained more clearly (I hope) > this time > > Imagine you run a bank. Your employees log in each day from their desktop > PC > using a UniObjects based application and shuffle money about between > accounts. The application must have write access to the database files and > controls who can do what via its own internal security checks. > > A clever employee now writes a simple VB program that uses UniObjects and > puts it on his PC. This program connects to the server using his > username/password but, instead of calling the usual application modules, > uses UniObjects to open the files and transfer funds into his own account > totally outside the security of the application. > > Using any of the operating system or database security mechanisms shuts > out > the business application as well as the rogue user. > > The only way that I can see to close this hole is for UniObjects to have > an > option to restrict which operations the client end can request. At the > highest level, this should restrict the client so that all he can do is > call > existing catalogued programs that are compiled with some special compiler > mode directive. > > Come on... Someone convince me I'm wrong! > > > Martin Phillips > Ladybridge Systems > 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB > +44-(0)1604-709200 > --- > 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/
Re: [U2] access via disabled accounts (solution)
On Fri, Jun 10, 2005 at 10:57:53AM +1000, David Jordan wrote: > < Thanks > Will Johnson>> > > Within UniVerse Basic is an AUTHORIZE Statement which allows you to give the > program different access rights to the user running the program. Ie > AUTHORIZE "Administrator" In case anybody else is looking into this, here's a small correction. The statement seems to be "AUTORIZATION". I don't see any alternate synonyms. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Best practice for Sequential IDs using TRANSACTION START & COMMIT/ROLLBACK
One approach is to determine in advance how many keys you'll need then generate and store these in a text file. As you work through the main loop, read them from the text file and write the successfully-used ones into another text file. (Sequential file I/O is not counted as part of the transaction.) When it comes time to commit, you can grab the successfully used ones and do whatever you need to do with them. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] access via disabled accounts (solution) - How?
How can you pull data from a U2 file, via UniObjects, manipulate it in VB.NET, and write it back to the file, via UniObjects, via stored procedures, and without directly accessing the files from UniObjects? That question contains a heavy duty internal inconsistency. It you write it back to the file via UniObjects then you ARE, necessarily, directly accessing the files from UniObjects. If you don't like the UniObjects methodology there are others, such as ADO, OLEDB, ODBC and so on. A bit more setting up required on the server side, but you only do that once. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Best practice for Sequential IDs using TRANSACTION START & COMMIT/ROLLBACK
As a quick thought to this, could you use a multi-part sequential number that uses the port/user ID? Something like PORT.NO:".":SEQ.ID? Since you are asking with the thought that someone else may need a lock to get a new record key, I am assuming that John after Jane after Jack sequencing is not important, just assurance that record key duplication does not happen and that down to the second is not enough accuracy to use date/time as the record key. Depending on other possible needs, it may just be a necessary evil/delay to hold a record lock until a transaction completes. BobW > -Original Message- > From: [EMAIL PROTECTED] [mailto:owner-u2- > [EMAIL PROTECTED] On Behalf Of Stevenson, Charles > Sent: Friday, June 10, 2005 3:40 PM > To: u2-users@listserver.u2ug.org > Subject: [U2] Best practice for Sequential IDs using TRANSACTION START & > COMMIT/ROLLBACK > > For files with sequential numbers as record IDs, it is common practice > to use a control item (in dictionary or in a special control table) to > get the next sequential id counter, then write back the incremented > counter ASAP so it is available for the next process that needs to do > the same. Some variation on this theme (probably involving a utility > subroutine): >READVU SEQ.ID FROM ctrl.fvar, ctrl.id, n ... >WRITEV SEQ.ID+1 TO ctrl.fvar, ctrl.id, n >WRITE NEW.REC TO fvar, SEQ.ID > > === > BUT: > === > > If that happens inside an explicit transaction bounded by TRANSACTION > START and TRANSACTION COMMIT (or TRANSACTION ROLLBACK), the Sequential > ID control record will not actually be written and/or released until all > updates are done/ditched during commit/rollback. If the transaction is > extensive and involves many updates, this could be a serious bottleneck. > > Making sure that you read the next sequential id as close to the moment > of executing the commit would be helpful, but that is not always an > option in complicated transactions. > > What is the best practice for handling this? What is your experience? > Bottlenecks? > > Ideally, I know what I'd prefer: I wish U2 would handle sequential ids > internally for variants of Type-2 or dynamic SEQ.NUM files. That should > have happened a couple decades ago in PI and Pick. But back to the real > world. What is the best way to handle sequential IDs when using > explicit TRANSACTIONs? > > cds > --- > 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/
RE: [U2] Best practice for Sequential IDs using TRANSACTION START & COMMIT/ROLLBACK
Well, there's no law that says that you can't "waste" id's. Get the next id & update before entering the transaction, I'd say. Or, if your transactions are in batches, get the id, add a hundred(or some other arbitrary but large enough number), and use all of those sequentially in this process. Here's one I encountered recently that I don't recommend: randomly generate each of 8 integers, then read the file to see if it already exists. If it does, generate 8 more... there were times where it took 20 minutes to find an unused one. The idea was to avoid this kind of bottleneck, but once files started to contain millions of records, there was a problem. Solution? prefix with a julian date... "Our greatest duty in this life is to help others. And please, if you can't help them, could you at least not hurt them?" - H.H. the Dalai Lama "When buying & selling are controlled by legislation, the first thing to be bought & sold are the legislators" - P.J. O'Rourke Dan Fitzgerald From: "Stevenson, Charles" <[EMAIL PROTECTED]> Reply-To: u2-users@listserver.u2ug.org To: Subject: [U2] Best practice for Sequential IDs using TRANSACTION START & COMMIT/ROLLBACK Date: Fri, 10 Jun 2005 18:39:30 -0400 For files with sequential numbers as record IDs, it is common practice to use a control item (in dictionary or in a special control table) to get the next sequential id counter, then write back the incremented counter ASAP so it is available for the next process that needs to do the same. Some variation on this theme (probably involving a utility subroutine): READVU SEQ.ID FROM ctrl.fvar, ctrl.id, n ... WRITEV SEQ.ID+1 TO ctrl.fvar, ctrl.id, n WRITE NEW.REC TO fvar, SEQ.ID === BUT: === If that happens inside an explicit transaction bounded by TRANSACTION START and TRANSACTION COMMIT (or TRANSACTION ROLLBACK), the Sequential ID control record will not actually be written and/or released until all updates are done/ditched during commit/rollback. If the transaction is extensive and involves many updates, this could be a serious bottleneck. Making sure that you read the next sequential id as close to the moment of executing the commit would be helpful, but that is not always an option in complicated transactions. What is the best practice for handling this? What is your experience? Bottlenecks? Ideally, I know what I'd prefer: I wish U2 would handle sequential ids internally for variants of Type-2 or dynamic SEQ.NUM files. That should have happened a couple decades ago in PI and Pick. But back to the real world. What is the best way to handle sequential IDs when using explicit TRANSACTIONs? cds --- 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/
RE: [U2] access via disabled accounts
<> 1. SOX and a number of international regulations have criminal liabilities for senior executives and directors to ensure that they prevent issues. 2. A major reason why big organisations are replacing U2 systems is a perception of security risks. In having the answers to such questions and IBM ensuring that there are no such holes then we can guarantee a viable future for the U2 product line. Even Microsoft can be hurt in sales by the perception of security issues and it is not one IBM can ignore. Regards David Jordan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Best practice for Sequential IDs using TRANSACTION START & COMMIT/ROLLBACK
One thing I would add to this is to always check to see if the key exists on the file that you are writing to before stepping on an existing record. Depending on how long your records live and how many characters you choose for your sequential key, you can theroetically have dups. We do exactly this kind of thing to generate inventory control numbers. We use 6 digits for our sequential number. So, when we hit 99 the number rolls back to 01. Those numbers are barcoded and the space for barcodes is limited and fixed. Anthony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stevenson, Charles Sent: Friday, June 10, 2005 6:40 PM To: u2-users@listserver.u2ug.org Subject: [U2] Best practice for Sequential IDs using TRANSACTION START & COMMIT/ROLLBACK For files with sequential numbers as record IDs, it is common practice to use a control item (in dictionary or in a special control table) to get the next sequential id counter, then write back the incremented counter ASAP so it is available for the next process that needs to do the same. Some variation on this theme (probably involving a utility subroutine): READVU SEQ.ID FROM ctrl.fvar, ctrl.id, n ... WRITEV SEQ.ID+1 TO ctrl.fvar, ctrl.id, n WRITE NEW.REC TO fvar, SEQ.ID === BUT: === If that happens inside an explicit transaction bounded by TRANSACTION START and TRANSACTION COMMIT (or TRANSACTION ROLLBACK), the Sequential ID control record will not actually be written and/or released until all updates are done/ditched during commit/rollback. If the transaction is extensive and involves many updates, this could be a serious bottleneck. Making sure that you read the next sequential id as close to the moment of executing the commit would be helpful, but that is not always an option in complicated transactions. What is the best practice for handling this? What is your experience? Bottlenecks? Ideally, I know what I'd prefer: I wish U2 would handle sequential ids internally for variants of Type-2 or dynamic SEQ.NUM files. That should have happened a couple decades ago in PI and Pick. But back to the real world. What is the best way to handle sequential IDs when using explicit TRANSACTIONs? cds --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.6.6 - Release Date: 6/8/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.6.6 - Release Date: 6/8/2005 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Best practice for Sequential IDs using TRANSACTION START & COMMIT/ROLLBACK
I feel like Winnie-the-Pooh here, Ray. I'm not following you. Are you saying reserve a block of N IDs before starting the transaction, by incrementing by N the traditional next-seq-id control record thereby freeing the ctrl item for use by other processes? What's the point of the 2 sequential io text files? They are private to the particular process reserving said block of N IDs, right? Why not just manage in memory? "Christopher Robin tried to teach it to me once, but it didn't." "What didn't?" said Rabbit. "Didn't what?" said Piglet. Pooh shook his head. "I don't know," he said. "It just didn't. - A A Miln, "The House at Pooh Corner" cds -Original Message- From: Ray Wurlod One approach is to determine in advance how many keys you'll need then generate and store these in a text file. As you work through the main loop, read them from the text file and write the successfully-used ones into another text file. (Sequential file I/O is not counted as part of the transaction.) When it comes time to commit, you can grab the successfully used ones and do whatever you need to do with them. --- --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Best practice for Sequential IDs using TRANSACTION START & COMMIT/ROLLBACK
> One thing I would add to this is to always check to see > if the key exists on the file that you are writing to > before stepping on an existing record. I'm not concerned about fleshing out my little READVU SEQ.ID . . . WRITEV SEQ.ID+1 . . . Yes, you have to check for existing records and worry about the else clauses, etc.. Nevermind about that. That's for a different thread. The point of this thread is about how to best do it when TRANSACTION START & COMMIT are used. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Best practice for Sequential IDs using TRANSACTION START & COMMIT/ROLLBACK
How about replacing: > Some variation on this theme (probably involving a utility > subroutine): > READVU SEQ.ID FROM ctrl.fvar, ctrl.id, n ... > WRITEV SEQ.ID+1 TO ctrl.fvar, ctrl.id, n > WRITE NEW.REC TO fvar, SEQ.ID with some variation of: OPENSEQ path TO ctrl.fseq ELSE ... READSEQ SEQ.ID FROM ctrl.fseq ELSE ... SEEK ctrl.fseq, 0, 0 ELSE ... WRITESEQ SEQ.ID+1 TO ctrl.fseq ELSE ... CLOSESEQ ctrl.fseq WRITE NEW.REC TO fvar, SEQ.ID All that would be inside the TRANSACTION START / COMMIT. It uses Ray's sequential I/O idea so that the write would happen immediately. OPENSEQ locks the control "item", CLOSESEQ releases it. A little timing test shows it is about 30% slower than the original. (My test did not do the WRITE NEW.REC TO fvar, SEQ.ID, just to be clear.) cds --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
