RE: [U2] Named Common Issues in UV
I used UV subroutines extensively from VB6 and never had any problems. I am not sure at this point how named common was used in that area. I can tell you that my previous company tried to use named common in a manner similar to what you are trying, but this was in straight UV programming. We did experience strange problems with the file variables too. In the end we had to back off on using named common to track file variables as a global solution. This was back in UV 9.6.?. Rich Taylor | Senior Programmer/Analyst| VERTIS 250 W. Pratt Street | Baltimore, MD 21201 P 410.361.8688 | F 410.528.0319 [EMAIL PROTECTED] | http://www.vertisinc.com Vertis is the premier provider of targeted advertising, media, and marketing services that drive consumers to marketers more effectively. The more they complicate the plumbing the easier it is to stop up the drain - Montgomery Scott NCC-1701 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kryka, Richard Sent: Tuesday, January 11, 2005 12:57 PM To: u2-users@listserver.u2ug.org Subject: [U2] Named Common Issues in UV Has anyone seen any issues with using named common in UV subroutines called by VB6? I ran some tests and determined that named common works in this environment, but have experienced some strangeness since implementing it. We have around 300 UV subroutines, with named common in fewer than 25. The goal is to keep from having to open the files every time the subroutine is called. The problems seem to occur in the routines with named common. Strangeness includes not being able to find a file, and getting data from the wrong file or ID. These 25 routines are used extensively, but the failures happen very rarely and sporadically, so are difficult to monitor. I have temporarily removed the named common to see if the strangeness goes away. All named common names are unique.UniVerse 10.0.10-2 on MS2000 Server. Sample VB6 code: Public Sub Get_Notes() On Error GoTo Form_Err Dim NoteObj As Object Dim ResultArray As Object Dim ArrayIndex As Integer Dim ArrayEnd As Integer Const RETURN_PARAM = 3 Const TOTAL_PARAM = 4 Const PAGE_RETURN = 1 lstNotes.Clear Set ResultArray = CreateObject(UV_DARRAY_OBJECT) Set NoteObj = uvSession.subroutine(VBNOTEPAGE3, TOTAL_PARAM) NoteObj.SetArg 0, txtNoteID.Text NoteObj.SetArg 1, CurPageNo NoteObj.SetArg 2, txtTypeNote.Text NoteObj.Call ResultArray = NoteObj.GetArg(RETURN_PARAM) ArrayEnd = ResultArray.Count If ArrayEnd = 1 Then For ArrayIndex = 1 To ArrayEnd lstNotes.AddItem ResultArray.Field(ArrayIndex) Next ArrayIndex End If txtPageDisplay = Page CurPageNo of PageLimit Form_Exit: Exit Sub Form_Err: MsgBox Error # Err.Number vbCrLf vbCrLf Err.Description, , frmNoteMaint: Get_Notes Resume Form_Exit End Sub Sample UV code: 0001: SUBROUTINE VBNOTEPAGE3(NOTE.ID,NOTE.PAGE,FILE.ID,RET.ARRAY) 0002: * -- 0003: * PROGRAM NAME : VBNOTEPAGE3 0004: * CREATED BY: TODD C. SELLS 0005: * PROGRAMMER: TSELLS 0006: * DATE CREATED : 0007: * -- 0008: * LAST MODIFIED : 0009: * 09/30/04 KRYKA - DISPLAY ONLY FIRST OCCURANCE OF DATE, SHIFT AUTO NOTE S TO RIGHT 0010: * 10/14/04 KRYKA - CLONED FROM VBNOTEPAGE. ADD USER AND TIME 0011: * 10/20/04 KRYKA - ADD NAMED COMMON 0012: * 01/11/05 KRYKA - REMOVE NAMED COMMON 0013: * -- 0014: * -- 0015: * INITIALIZE STANDARD VARIABLES AND INCLUDE FILES 0016: * -- 0017: EQU TRUE TO 1 0018: EQU FALSE TO 0 0019: * -- 0020: * INITIALIZE VARIABLES 0021: * -- 0022: COMMON /VBNOTEPAGE3/ INIT.PATH, 0023: CLIENT.NOTE.MASTER, 0024: DELETED.NOTES, 0025: APPT.NOTES, 0026: CRED.NOTES, 0027: POLICY.NOTES 0028: * 0029: IF INIT.PATH # @PATH THEN 0030: OPEN CLIENT-NOTE-MASTER TO CLIENT.NOTE.MASTER ELSE 0031: RET.ARRAY = CANNOT OPEN CLIENT-NOTE-MASTER FILE 0032: RETURN 0033: END 0034: OPEN DELETED.NOTES TO DELETED.NOTES ELSE 0035: RET.ARRAY = CANNOT OPEN DELETED.NOTES FILE 0036: RETURN 0037: END 0038: OPEN APPT-NOTES TO APPT.NOTES ELSE 0039: RET.ARRAY = CANNOT OPEN APPT-NOTES FILE 0040: RETURN 0041: END 0042: OPEN CRED-NOTES TO CRED.NOTES ELSE 0043: RET.ARRAY = CANNOT OPEN DELETED.NOTES FILE 0044: RETURN
Unclassified RE: [U2] Named Common Issues in UV
Dick, We use named commons extensively in UniBasic programs called from the database layer (COM components, written in VB6 using the UniObjects interface) of our web applications. One of the principal uses is to hold file handles, as you illustrated, except that we keep up to 650 files open that way. One difference is that we use dimensioned arrays, like this:- - Begin code snippet - COMMON /LFILES/LOW.FILES(250) EQUATE LOW.FILES.OPEN.FLAG TO LOW.FILES(1) EQUATE ADDRESSES TO LOW.FILES(2) EQUATE ADDRESSES.ARC TO LOW.FILES(3) EQUATE ADDRESSES.RET TO LOW.FILES(4) -- End code snippet -- We have been doing this since UV 9.5 (on HP-UX), we are now running UV 10.0 on Windows Server 2003. I have never seen the kinds of 'strangeness' you refer to. HTH Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kryka, Richard Sent: Wednesday, 12 January 2005 06:57 To: u2-users@listserver.u2ug.org Subject: [U2] Named Common Issues in UV Has anyone seen any issues with using named common in UV subroutines called by VB6? I ran some tests and determined that named common works in this environment, but have experienced some strangeness since implementing it. We have around 300 UV subroutines, with named common in fewer than 25. The goal is to keep from having to open the files every time the subroutine is called. The problems seem to occur in the routines with named common. Strangeness includes not being able to find a file, and getting data from the wrong file or ID. These 25 routines are used extensively, but the failures happen very rarely and sporadically, so are difficult to monitor. I have temporarily removed the named common to see if the strangeness goes away. All named common names are unique.UniVerse 10.0.10-2 on MS2000 Server. [snip] Dick Kryka Director of Applications CCCS of Greater Denver, Inc. Paragon Financial Services 303-632-2226 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Named Common Issues in UV
In UniData (not sure about UniVerse) the named common name is only significant for the first 7 digits. So your VBNOTEPAGE3 will be the same as VBNOTEPAGE1. IE. you may think the name is unique but the system doesn't. The name looks like there might be others with a similar name so this could be your problem. hth Colin Alfke from chilly and soon to get dang cold Calgary -Original Message- From: Kryka, Richard Has anyone seen any issues with using named common in UV subroutines called by VB6? I ran some tests and determined that named common works in this environment, but have experienced some strangeness since implementing it. We have around 300 UV subroutines, with named common in fewer than 25. The goal is to keep from having to open the files every time the subroutine is called. The problems seem to occur in the routines with named common. Strangeness includes not being able to find a file, and getting data from the wrong file or ID. These 25 routines are used extensively, but the failures happen very rarely and sporadically, so are difficult to monitor. I have temporarily removed the named common to see if the strangeness goes away. All named common names are unique.UniVerse 10.0.10-2 on MS2000 Server. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: Unclassified RE: [U2] Named Common Issues in UV
We also use a dimensioned array to hold our file handles. I'm not convinced, personally, that this has much benefit to system performance but the system works pretty well so who am I to complain? smile BobW -Original Message- From: [EMAIL PROTECTED] [mailto:owner-u2- [EMAIL PROTECTED] On Behalf Of HENDERSON MIKE, MR Sent: Tuesday, January 11, 2005 11:19 AM To: u2-users@listserver.u2ug.org Subject: Unclassified RE: [U2] Named Common Issues in UV Dick, We use named commons extensively in UniBasic programs called from the database layer (COM components, written in VB6 using the UniObjects interface) of our web applications. One of the principal uses is to hold file handles, as you illustrated, except that we keep up to 650 files open that way. One difference is that we use dimensioned arrays, like this:- - Begin code snippet - COMMON /LFILES/LOW.FILES(250) EQUATE LOW.FILES.OPEN.FLAG TO LOW.FILES(1) EQUATE ADDRESSES TO LOW.FILES(2) EQUATE ADDRESSES.ARC TO LOW.FILES(3) EQUATE ADDRESSES.RET TO LOW.FILES(4) -- End code snippet -- We have been doing this since UV 9.5 (on HP-UX), we are now running UV 10.0 on Windows Server 2003. I have never seen the kinds of 'strangeness' you refer to. HTH Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kryka, Richard Sent: Wednesday, 12 January 2005 06:57 To: u2-users@listserver.u2ug.org Subject: [U2] Named Common Issues in UV Has anyone seen any issues with using named common in UV subroutines called by VB6? I ran some tests and determined that named common works in this environment, but have experienced some strangeness since implementing it. We have around 300 UV subroutines, with named common in fewer than 25. The goal is to keep from having to open the files every time the subroutine is called. The problems seem to occur in the routines with named common. Strangeness includes not being able to find a file, and getting data from the wrong file or ID. These 25 routines are used extensively, but the failures happen very rarely and sporadically, so are difficult to monitor. I have temporarily removed the named common to see if the strangeness goes away. All named common names are unique.UniVerse 10.0.10-2 on MS2000 Server. [snip] Dick Kryka Director of Applications CCCS of Greater Denver, Inc. Paragon Financial Services 303-632-2226 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. --- 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] Named Common Issues in UV
We have used named common in subroutines called from UV Basic to hold file variables and dimensioned file variables without problems for over 5 years. There was a quirk, if I remember right, that I had to play around with the common. I remember reducing the number of items to a named common and removing spaces. There may be something funny about the way variables are stored in memory that I had tripped up, but works fine now. My suggestion, put common variables in an include file, it makes it easier to play around with the common statement. Also try putting all the common variables on one line and see if that helps. Also maybe use a common name that is different to the subroutine names. Check the logic of initpath is working properly. If you are only using the variable to check if the file is open, consider using the FILEINFO command. (there is bug in early releases of 10.0 10.1 in testing Dimensioned File variables). If you are changing directory, the documentation states that you cannot open files in a remote directory and you maybe falling over this Hope this helps Regards David Jordan Founding U2UG Director I ran some tests and determined that named common works in this environment, but have experienced some strangeness since implementing it. We have around 300 UV subroutines, with named common in fewer than 25. The goal is to keep from having to open the files every time the subroutine is called. The problems seem to occur in the routines with named common. Strangeness includes not being able to find a file, and getting data from the wrong file or ID. These 25 routines are used extensively, but the failures happen very rarely and sporadically, so are difficult to monitor. I have temporarily removed the named common to see if the strangeness goes away. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Named Common Issues in UV
Colin Alfke wrote: In UniData (not sure about UniVerse) the named common name is only significant for the first 7 digits. So your VBNOTEPAGE3 will be the same as VBNOTEPAGE1. IE. you may think the name is unique but the system doesn't. The name looks like there might be others with a similar name so this could be your problem. In UniVerse, the first 31 characters of the name are used according to the documentation. I tested for this issue when I set up the names because I am used to this limitation on UniData. Thanks. Dick Kryka --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Named Common Issues in UV
Richard, Besides the 7 character name limit, here's another scenario that would cause grief. Don't know if it applies to you. It has nothing particularly to do with VB. Consider a single session that LOGTOs different accounts: 1. VBNOTEPAGE3 successfully runs in account A. common is initialized. INIT.PATH set to A. 2. LOGTO account B 3. VBNOTEPAGE3 is run in account B. 3b. INIT.PATH does not match @PATH. 3c. Suppose it can't open APPT-NOTES in account B. 3c. Line 40 RETURN executes before rest of common is set 3d. You have a mix of variables: INIT.PATH still points to Account A CLIENT-NOTE-MASTER points to Account B's file DELETE.NOTES '' '' ''B'' APPT-NOTES is no longer a file variable. CRED.NOTES points to Account A's file POLICY.NOTES '' '' ''A'' 4. LOGTO Account A again. 5. VBNOTEPAGE3 runs. 5a. INIT.PATH still points to Account A, 5b. so no re-initialization occurs. 5c. It runs with the mixed set of file pointers described in 3d. Solution: Reset INIT.PATH to something impossible before attempting any opens: 0029: IF INIT.PATH # @PATH THEN 0030: INIT.PATH = 0 That way any aborted attempts will leave the INIT.PATH needing reinitialization. cds P.S. For newbies listening in: these commons resides in a process's private memory. It is available to all programs called _by_that_user_. It is _NOT_ 'common' to all other processes. People often get confused about this if I just muddied the waters worse, speak up someone more articulate will doubtless chime in. -Original Message- 0001: SUBROUTINE VBNOTEPAGE3(NOTE.ID,NOTE.PAGE,FILE.ID,RET.ARRAY) 0022: COMMON /VBNOTEPAGE3/ INIT.PATH, 0023: CLIENT.NOTE.MASTER, 0024: DELETED.NOTES, 0025: APPT.NOTES, 0026: CRED.NOTES, 0027: POLICY.NOTES 0028: * 0029: IF INIT.PATH # @PATH THEN 0030: OPEN CLIENT-NOTE-MASTER TO CLIENT.NOTE.MASTER ELSE 0031: RET.ARRAY = CANNOT OPEN CLIENT-NOTE-MASTER FILE 0032: RETURN 0033: END 0034: OPEN DELETED.NOTES TO DELETED.NOTES ELSE 0035: RET.ARRAY = CANNOT OPEN DELETED.NOTES FILE 0036: RETURN 0037: END 0038: OPEN APPT-NOTES TO APPT.NOTES ELSE 0039: RET.ARRAY = CANNOT OPEN APPT-NOTES FILE 0040: RETURN 0041: END 0042: OPEN CRED-NOTES TO CRED.NOTES ELSE 0043: RET.ARRAY = CANNOT OPEN DELETED.NOTES FILE 0044: RETURN 0045: END 0046: OPEN POLICY-NOTES TO POLICY.NOTES ELSE 0047: RET.ARRAY = CANNOT OPEN POLICY-NOTES FILE 0048: RETURN 0049: END 0050: * 0051: INIT.PATH = @PATH 0052: END --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Named Common Issues in UV
I've used named common in an include - I set it up as a dimensioned array like DIM OPEN.FILES(500). Then my file-open subroutine checks the current account to see if it's the same as OPEN.FILES(1)1 - if not this indicates an account-change or new logon and I clear the entire array. I keep OPEN.FILES1 set to the current account name with a couple of spaces appended to the front and back to insure account-name uniqueness (from file names). Then a simple attribute LOCATE in open.files for the file name I want to open - points me to the proper subscript (2 to 500) of the open file variable or where to place the open file variable during my OPEN statement. My subroutine passes the file name to open and the file variable of the opened file. I also have a function code I pass that says whether to create the file if it's missing, to open a port-based 'private work file', whether to 'clearfile' the file, etc. A common file-open subroutine allows standardized error handling too. There may or may not be performance improvements using this method (depends on your OS), but there's certainly an advantage to having the file opening and file error handling standardized. Rick Ramsey Healthpac Computer Systems, Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Jordan Sent: Tuesday, January 11, 2005 3:02 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Named Common Issues in UV We have used named common in subroutines called from UV Basic to hold file variables and dimensioned file variables without problems for over 5 years. There was a quirk, if I remember right, that I had to play around with the common. I remember reducing the number of items to a named common and removing spaces. There may be something funny about the way variables are stored in memory that I had tripped up, but works fine now. My suggestion, put common variables in an include file, it makes it easier to play around with the common statement. Also try putting all the common variables on one line and see if that helps. Also maybe use a common name that is different to the subroutine names. Check the logic of initpath is working properly. If you are only using the variable to check if the file is open, consider using the FILEINFO command. (there is bug in early releases of 10.0 10.1 in testing Dimensioned File variables). If you are changing directory, the documentation states that you cannot open files in a remote directory and you maybe falling over this Hope this helps Regards David Jordan Founding U2UG Director I ran some tests and determined that named common works in this environment, but have experienced some strangeness since implementing it. We have around 300 UV subroutines, with named common in fewer than 25. The goal is to keep from having to open the files every time the subroutine is called. The problems seem to occur in the routines with named common. Strangeness includes not being able to find a file, and getting data from the wrong file or ID. These 25 routines are used extensively, but the failures happen very rarely and sporadically, so are difficult to monitor. I have temporarily removed the named common to see if the strangeness goes away. --- 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] Named Common Issues in UV
oops - line below should have read: Then a simple attribute LOCATE in open.files(1) . . . -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Ramsey Sent: Tuesday, January 11, 2005 4:07 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Named Common Issues in UV I've used named common in an include - I set it up as a dimensioned array like DIM OPEN.FILES(500). Then my file-open subroutine checks the current account to see if it's the same as OPEN.FILES(1)1 - if not this indicates an account-change or new logon and I clear the entire array. I keep OPEN.FILES1 set to the current account name with a couple of spaces appended to the front and back to insure account-name uniqueness (from file names). s for the file name I want to open - points me to the proper subscript (2 to 500) of the open file variable or where to place the open file variable during my OPEN statement. My subroutine passes the file name to open and the file variable of the opened file. I also have a function code I pass that says whether to create the file if it's missing, to open a port-based 'private work file', whether to 'clearfile' the file, etc. A common file-open subroutine allows standardized error handling too. There may or may not be performance improvements using this method (depends on your OS), but there's certainly an advantage to having the file opening and file error handling standardized. Rick Ramsey Healthpac Computer Systems, Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Jordan Sent: Tuesday, January 11, 2005 3:02 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Named Common Issues in UV We have used named common in subroutines called from UV Basic to hold file variables and dimensioned file variables without problems for over 5 years. There was a quirk, if I remember right, that I had to play around with the common. I remember reducing the number of items to a named common and removing spaces. There may be something funny about the way variables are stored in memory that I had tripped up, but works fine now. My suggestion, put common variables in an include file, it makes it easier to play around with the common statement. Also try putting all the common variables on one line and see if that helps. Also maybe use a common name that is different to the subroutine names. Check the logic of initpath is working properly. If you are only using the variable to check if the file is open, consider using the FILEINFO command. (there is bug in early releases of 10.0 10.1 in testing Dimensioned File variables). If you are changing directory, the documentation states that you cannot open files in a remote directory and you maybe falling over this Hope this helps Regards David Jordan Founding U2UG Director I ran some tests and determined that named common works in this environment, but have experienced some strangeness since implementing it. We have around 300 UV subroutines, with named common in fewer than 25. The goal is to keep from having to open the files every time the subroutine is called. The problems seem to occur in the routines with named common. Strangeness includes not being able to find a file, and getting data from the wrong file or ID. These 25 routines are used extensively, but the failures happen very rarely and sporadically, so are difficult to monitor. I have temporarily removed the named common to see if the strangeness goes away. --- 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: Unclassified RE: [U2] Named Common Issues in UV
Bob, Our Named Common / Dimensioned Array method of managing file handles goes back w-a-y before the web, to our Pr1me Information machines (before my time here). Opening files only once per session made a very big difference indeed in those days. Maybe it's not be so influential on today's machines, but it's not broken, so we won't fix it! On the other hand, I've seen postings here recently that said that taking a file open outside of a subroutine call did make an application run significantly faster. Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Woodward Sent: Wednesday, 12 January 2005 08:39 To: u2-users@listserver.u2ug.org Subject: RE: Unclassified RE: [U2] Named Common Issues in UV We also use a dimensioned array to hold our file handles. I'm not convinced, personally, that this has much benefit to system performance but the system works pretty well so who am I to complain? smile BobW [snip] The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
