RE: [U2] Programs slowing down after many iterations
COMMON behaves similarly to passing variables in a SUBROUTINE command - with the benefit of not being copied back and forth... For Example: PROGRAM PROGA ZZ = 123 BB = "Hello" CALL PROGB(ZZ,BB) END SUBROUTINE PROGB(VAR1,VAR2) PRINT VAR1 PRINT VAR2 END When that runs, the CALL to PROGB copies the variables from one routine's 'space' into the next, and then on the way back out, copies the changed results back. NAMED COMMON lets those variables persist and live across your LOGIN session -- PROGRAM PROGA COMMON \BLOCKA\ BLOCKA1,BLOCKA2,BLOCKA3 COMMON \BLOCKB\ BLOCKB1,BLOCKB2,BLOCKB3 BLOCKA1 = 'Hi' BLOCKB2 = 'There' CALL PROGB CALL PROGC CALL PROGD PRINT BLOCKA1 Would now say 'Bye' END -- SUBROUTINE PROGB COMMON \BLOCKA\ BLOCKA1,BLOCKA2,BLOCKA3 PRINT BLOCKA1 Would print Hi PRINT BLOCKB2 Would return an UnInit Var, as that common block was not included in the program RETURN -- SUBROUTINE PROGC *Does NOT include the Common Block BLOCKA1 = 'This is NOT overwriting the common' RETURN -- SUBROUTINE PROGD COMMON \BLOCKA\ BLOCKD1,BLOCKD2,BLOCKD3 ... Note rename for varialbles... COMMON \BLOCKB\ BLOCKB1,BLOCKB2,BLOCKB3 PRINT BLOCKD1:' ':BLOCKB2 Would print Hi There BLOCKD1 = 'Bye' RETURN -- So a named common block of FileHandles is a great way to go... BUT - it IS easier to do COMMON in an include statement, mainly so if you add three items to the common, you just have to recompile, and it ensures each file has the exact same names for the common block items across your whole system - which is NOT required - Common block mapping is POSITIONAL - But I personally find making the names 'constant' will avoid a large number of issues!! DW -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chauhan, Savita Sent: Friday, September 02, 2005 8:07 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Programs slowing down after many iterations Hi, I read all these emails related to COMMON. I am not too old into the U2 world. It seems like an interesting thing that I should be doing in my programs too. Can someone give me a COMMON-101 or direct me to some manual/document which has basic information about 'common'? Thanks, Savita Chauhan IT SW Process Coord Central Texas College (254)526-1754 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Programs slowing down after many iterations
I second that request. I've only inherited regular COMMONs with the occasional COMMONs buried in an INCLUDE. I've never come across NAMED COMMONS. Thanks Mark Johnson - Original Message - From: "Chauhan, Savita" <[EMAIL PROTECTED]> To: Sent: Friday, September 02, 2005 9:07 AM Subject: RE: [U2] Programs slowing down after many iterations > Hi, > I read all these emails related to COMMON. I am not too old into the U2 > world. It seems like an interesting thing that I should be doing in my > programs too. Can someone give me a COMMON-101 or direct me to some > manual/document which has basic information about 'common'? > > Thanks, > > Savita Chauhan > IT SW Process Coord > Central Texas College > (254)526-1754 > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tony Gravagno > Sent: Thursday, September 01, 2005 4:06 PM > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] Programs slowing down after many iterations > > Yes David, you're right. Note below that I did mention using flags for > this, and I do check for such things in code that's used across > accounts. > I was just trying to simplify the code and I swear I started itching as > soon as I tweaked that reference to check the file descriptor instead of > a > flag. So much for trying to keep it simple. > > Thanks for keeping me honest. :) > T > > David Wolverton wrote: > > But -- don't test if an open file pointer exists as this > > example would suggest if you are multi-account -- If you > > move from account to account, the open file **would** > > persist, but likely be wrong. We've seen that MANY a time > > where the report is giving data totally unrelated to the > > account we are in. > > > > Do as others have shown - add the account name into the > > variable list and confirm that the account name is > > assisgned AND matches the current account. > > > > David W. > > > > -Original Message- > > From: Tony Gravagno > > > > IF UNASSIGNED(FILE1) THEN > [snip] > >...I recently accidentally made a change that > >didn't set "FirstTime" type flags... > [snip] > ...to reset the FilesAreOpened flag... > --- > 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] Programs slowing down after many iterations
Hi, I read all these emails related to COMMON. I am not too old into the U2 world. It seems like an interesting thing that I should be doing in my programs too. Can someone give me a COMMON-101 or direct me to some manual/document which has basic information about 'common'? Thanks, Savita Chauhan IT SW Process Coord Central Texas College (254)526-1754 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Gravagno Sent: Thursday, September 01, 2005 4:06 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Programs slowing down after many iterations Yes David, you're right. Note below that I did mention using flags for this, and I do check for such things in code that's used across accounts. I was just trying to simplify the code and I swear I started itching as soon as I tweaked that reference to check the file descriptor instead of a flag. So much for trying to keep it simple. Thanks for keeping me honest. :) T David Wolverton wrote: > But -- don't test if an open file pointer exists as this > example would suggest if you are multi-account -- If you > move from account to account, the open file **would** > persist, but likely be wrong. We've seen that MANY a time > where the report is giving data totally unrelated to the > account we are in. > > Do as others have shown - add the account name into the > variable list and confirm that the account name is > assisgned AND matches the current account. > > David W. > > -Original Message- > From: Tony Gravagno > > IF UNASSIGNED(FILE1) THEN [snip] >...I recently accidentally made a change that >didn't set "FirstTime" type flags... [snip] ...to reset the FilesAreOpened flag... --- 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] Programs slowing down after many iterations
But -- don't test if an open file pointer exists as this example would suggest if you are multi-account -- If you move from account to account, the open file **would** persist, but likely be wrong. We've seen that MANY a time where the report is giving data totally unrelated to the account we are in. Do as others have shown - add the account name into the variable list and confirm that the account name is assisgned AND matches the current account. David W. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Gravagno Sent: Thursday, September 01, 2005 2:38 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Programs slowing down after many iterations I'll echo the concept of using named common to cache file handles to avoid re-opening. I use this as a key technique in web applications. Funny enough, right before I got to this thread I wrote a paper to explain to one of my clients how it works. The key thing is to use Named common, not regular common. I use code like this: COMMON \APP1\ FILE1,FILE2 IF UNASSIGNED(FILE1) THEN * note in D3 and maybe other MV platforms that's *IF ASSIGNED(...) ELSE or IF NOT(ASSIGNED(...)) THEN ... GOSUB OPEN.FILES ; * file1 is assigned there IF ERR THEN RETURN ; * always handle errors from file opening END ... Continue with code here, secure that at some point the files were opened --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Programs slowing down after many iterations
Yes David, you're right. Note below that I did mention using flags for this, and I do check for such things in code that's used across accounts. I was just trying to simplify the code and I swear I started itching as soon as I tweaked that reference to check the file descriptor instead of a flag. So much for trying to keep it simple. Thanks for keeping me honest. :) T David Wolverton wrote: > But -- don't test if an open file pointer exists as this > example would suggest if you are multi-account -- If you > move from account to account, the open file **would** > persist, but likely be wrong. We've seen that MANY a time > where the report is giving data totally unrelated to the > account we are in. > > Do as others have shown - add the account name into the > variable list and confirm that the account name is > assisgned AND matches the current account. > > David W. > > -Original Message- > From: Tony Gravagno > > IF UNASSIGNED(FILE1) THEN [snip] >...I recently accidentally made a change that >didn't set "FirstTime" type flags... [snip] ...to reset the FilesAreOpened flag... --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Programs slowing down after many iterations
And add CLEARCOMMON to Login paragraph. -Original Message- But -- don't test if an open file pointer exists as this example would suggest if you are multi-account -- If you move from account to account, the open file **would** persist, but likely be wrong. We've seen that MANY a time where the report is giving data totally unrelated to the account we are in. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Programs slowing down after many iterations
I'll echo the concept of using named common to cache file handles to avoid re-opening. I use this as a key technique in web applications. Funny enough, right before I got to this thread I wrote a paper to explain to one of my clients how it works. The key thing is to use Named common, not regular common. I use code like this: COMMON \APP1\ FILE1,FILE2 IF UNASSIGNED(FILE1) THEN * note in D3 and maybe other MV platforms that's *IF ASSIGNED(...) ELSE or IF NOT(ASSIGNED(...)) THEN ... GOSUB OPEN.FILES ; * file1 is assigned there IF ERR THEN RETURN ; * always handle errors from file opening END ... Continue with code here, secure that at some point the files were opened It doesn't sound like this is the case, but might someone have a unique version of the code that bypasses this code? That will provoke re-opening the files. I have my code like this in a standard item that is Included by all code in a given app module. I recently accidentally made a change that didn't set "FirstTime" type flags, and I introduced recursion which had symptoms as you describe. Any similar issues? Is there some file that changed permissions so that it can't be opened, so now your open logic fails and all files are being opened every time you come into the code? David A Barrett wrote: > This just started happening. Furthermore, when we > checked our test system, we found that it also exhibited > exactly the same behaviour. This would seem to rule out > any system or hardware specific event. This is a clue to what happened - you need to find something that happened in common to these systems, some new test code that just went production, some change to flags in a control file, maybe new I-descriptors that call somewhere to reset the FilesAreOpened flag... Good luck. Tony --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Programs slowing down after many iterations
Clif Oliver & Tim Snyder already said it better than I, but I cannot be silent. This is NOT a "workaround". Your fix is the correct way of doing it. Richard Kryka's initialization example is good, too. I don't know why the sudden difference in performance, though. It is curious that the sme problem cropped up on the test system,unless both had similar config changes recently. Could it be that the problem has been there to some extent or another for some time and was just noticed now for the first time? cds --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Programs slowing down after many iterations
Clifton Oliver <[EMAIL PROTECTED]> wrote on 09/01/2005 10:31:10 AM: > Your named COMMON "trick", especially with the "second step" of > avoiding the file reopen is not a work-around. It is considered by > most to be the "correct" way to code one of these subroutines. I agree with Clif - I've seen this approach make a huge difference many times. Don't consider it a work-around, but rather embrace this approach throughout the application. That being said, the original question is why this particular query became an issue all of a sudden. Although UniVerse hasn't been upgraded on this box recently, *something* has clearly changed. Maybe one of the impacted files has dramatically outgrown its configured size. Maybe somebody performed a uvregen that changed the size of the rotating file pool or something else. Maybe the user load has changed recently. Maybe a file design has been changed. Maybe something else has changed in the application environment, such as installing an application modification that is consuming disk or memory resources. Maybe there's a problem with some component of the disk subsystem. The list of possible causes is long; whatever changed may not have directly caused the problem with your query, but it may have been enough to cause a bottleneck in some system resource. What is the operating system being used? Is it possible that something changed there? Was any performance monitoring done at the O/S level while the problem was occurring? That would provide some valuable clues. Bottom line - sorry, no easy answers. ;-) Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Programs slowing down after many iterations
Part of original message: We scratched our heads over this for quite a while. Eventually, we put a named COMMON statement in the program and listed all of the file variables as part of it. Then we put some code to check if the files were already open in front of the OPEN statements, to avoid re-opening. I'm not sure if this second step was really necessary. Response: I use named common extensively, and always use a convention like this because we have several accounts (including a test account) that look alike. COMMON /COMMONNAME/ FILE1, FILE2, ETC, ETC, INIT.PATH IF INIT.PATH # @PATH THEN OPEN FILES ETC INIT.PATH = @PATH END This way, the named common cannot jump to another account and reference files on a different account. Dick Kryka Director of Applications CCCS of Greater Denver, Inc. Paragon Financial Services 303-632-2226 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David A Barrett Sent: Thursday, September 01, 2005 7:52 AM To: u2-users@listserver.u2ug.org Subject: [U2] Programs slowing down after many iterations Here's the situation. We noticed this first with a subroutine intended to be used as part of an I-descriptor in Universe. It's a program that we use all over the place because it looks into a number of places and comes up with the status of a policyholder on a particular date. It needs to open a number of files to do this. We did a SELECT using a dictionary item calling this routine, and noticed that it was taking forever. This was unusual. We killed it and started it again, and when it didn't improve we did some more investigation. What we found was that the LIST or SELECT started off very fast, but then got slower and slower over time. If we stopped the LIST/SELECT and restarted it right away it would start off very slow. If we stopped the LIST/SELECT, then QUITted out of UV, and then went back in and restarted it, it would start up fast but then eventually slow down. When we restested, we found that the LIST/SELECTs really flew, and set new speed records for completing. Something about file handling was the issue. This system has been in place for 10 years. We haven't upgraded Universe for several years (we're on version 10). This just started happening. Furthermore, when we checked our test system, we found that it also exhibited exactly the same behaviour. This would seem to rule out any system or hardware specific event. I consider the named common trick to be a work-around. Has anyone else noticed the same thing? If so, does anyone know any other way to stop this from happening? thanks, Dave Barrett, Lawyers' Professional Indemnity Company --- 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] Programs slowing down after many iterations
Your named COMMON "trick", especially with the "second step" of avoiding the file reopen is not a work-around. It is considered by most to be the "correct" way to code one of these subroutines. Avoiding reopening files on every call to a subroutine, whether called from an I-descriptor or from another program, is a very important performance issue. -- Regards, Clif ~~~ W. Clifton Oliver, CCP CLIFTON OLIVER & ASSOCIATES Tel: +1 619 460 5678Web: www.oliver.com ~~~ On Sep 1, 2005, at 6:52 AM, David A Barrett wrote: Here's the situation. We noticed this first with a subroutine intended to be used as part of an I-descriptor in Universe. It's a program that we use all over the place because it looks into a number of places and comes up with the status of a policyholder on a particular date. It needs to open a number of files to do this. We did a SELECT using a dictionary item calling this routine, and noticed that it was taking forever. This was unusual. We killed it and started it again, and when it didn't improve we did some more investigation. What we found was that the LIST or SELECT started off very fast, but then got slower and slower over time. If we stopped the LIST/SELECT and restarted it right away it would start off very slow. If we stopped the LIST/ SELECT, then QUITted out of UV, and then went back in and restarted it, it would start up fast but then eventually slow down. We scratched our heads over this for quite a while. Eventually, we put a named COMMON statement in the program and listed all of the file variables as part of it. Then we put some code to check if the files were already open in front of the OPEN statements, to avoid re-opening. I'm not sure if this second step was really necessary. When we restested, we found that the LIST/SELECTs really flew, and set new speed records for completing. Something about file handling was the issue. This system has been in place for 10 years. We haven't upgraded Universe for several years (we're on version 10). This just started happening. Furthermore, when we checked our test system, we found that it also exhibited exactly the same behaviour. This would seem to rule out any system or hardware specific event. I consider the named common trick to be a work-around. Has anyone else noticed the same thing? If so, does anyone know any other way to stop this from happening? thanks, Dave Barrett, Lawyers' Professional Indemnity Company --- 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/
