RE: [U2] [UD] CALL @progname
But if the program is not globally catalog then you will find it there. It make sure that you can exit the program catalog it before calling it. If you want to make sure that you can catalog it the basic the program before the catalog. EXECUTE BASIC :filename: :program CAPTURING OUTPUT (stops display to screen) EXECUTE CATALOG :filename: :program CAPTURING OUTPUT Note that if all your code is in one file that you can hard code the filename. -Original Message- From: Cordes, Tom (contractor) [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 27, 2008 6:32 AM To: 'u2-users@listserver.u2ug.org' Subject: RE: [U2] [UD] CALL @progname Dave, If the _MAP_ file is current, all globally catalogued programs have an entry. 'MAKE.MAP.FILE' updates the file. Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Wolverton Sent: Thursday, March 15, 2007 11:20 AM To: u2-users@listserver.u2ug.org Subject: [U2] [UD] CALL @progname I am writing some code that will execute a variable passed in progname using CALL @progname. Question - what is the 'best' way to know that progname exists before I attempt the CALL. I thought about reading the VOC, but if it's globally cataloged, that won't work. I could read the VOC and then the CTLGTB -- but that was two reads just to 'know' the routine wasn't going to blow up. Is there a more efficient or systemic way to do this? **Typically** progname will reference a real program, so this testing is 'overhead' for 99.9% of the time - but if someone were to pass in a bad 'progname', I want to be more graceful (and secure!) just falling over. Since some of the calls will come from 'web connected' clients, and some of the clients may not know for sure that the host cannot handle the request - if the client has a different function list than the host at that point and time... I'm just trying to plan for 'worst case'. How do others handle CALL @ --- 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] [UD] CALL @progname
Dave, If the _MAP_ file is current, all globally catalogued programs have an entry. 'MAKE.MAP.FILE' updates the file. Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Wolverton Sent: Thursday, March 15, 2007 11:20 AM To: u2-users@listserver.u2ug.org Subject: [U2] [UD] CALL @progname I am writing some code that will execute a variable passed in progname using CALL @progname. Question - what is the 'best' way to know that progname exists before I attempt the CALL. I thought about reading the VOC, but if it's globally cataloged, that won't work. I could read the VOC and then the CTLGTB -- but that was two reads just to 'know' the routine wasn't going to blow up. Is there a more efficient or systemic way to do this? **Typically** progname will reference a real program, so this testing is 'overhead' for 99.9% of the time - but if someone were to pass in a bad 'progname', I want to be more graceful (and secure!) just falling over. Since some of the calls will come from 'web connected' clients, and some of the clients may not know for sure that the host cannot handle the request - if the client has a different function list than the host at that point and time... I'm just trying to plan for 'worst case'. How do others handle CALL @ --- 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] [UD] CALL @progname
In message [EMAIL PROTECTED], Allen Egerton [EMAIL PROTECTED] writes David Wolverton wrote: snip Anyone have a clue why the indirects are a hair faster? Or am I just getting lucky over and over? I always thought they were slower as well! In Prime's implementation, which I *believe* was carried over to Universe, the *first* reference to @PROGNAME has to resolve the reference. Which means that it looks up the address that the routine's loaded into. Every subsequent reference uses the already resolved reference. Which is *fast*. So, the programming practice is to define it, snap the link the first time you call it, then keep calling it. Minimal overhead, and gives you a great deal of flexibility in coding. Indeed, I believe that the compiler converted CALL *s into CALL @s. It would create and initialise a temporary variable, then put CALL @ code into the executable. Cheers, Wol -- Anthony W. Youngman [EMAIL PROTECTED] 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998 Visit the MaVerick web-site - http://www.maverick-dbms.org Open Source Pick --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UD] CALL @progname
The 'extra' time when calling as a function is likely due to the assignment of the result to a variable. Doing that a million times has to trigger a significant number of garbage collects. Perhaps You could modify the test to call the routine and 'copy' the result argument to a variable - it should IMHO result in a time about the same as the function call... -- mats David Wolverton skrev: Actually - I just ran a test, and was surprised somewhat: 1,000,000 Iterations of ways to do a call... CALL PROGNAME (direct)7047 CALL *PROGNAME (global)7766 CALL @PROGNAME (indirect) 6984 GOSUB (logic contained in-line)1531 Call as Function 10203 I've rearranged the order the routines are called in, and run the test suite over and over... The Indirect calls are CLEARLY faster, with all numbers moving +/- 50, EXCEPT the indirect, which only moved +/- 25 or so. Note that I set the @PROGNAME outside of the call loop - this was not testing how fast the system could set variables - just the difference on the 'calls'. If I include the setting of the name WITHIN the loop, the indirect call went to 7290 or so -- the difference in the 'direct' call vs the 'indirect' call efficiency appears to be in the Variable handling! But both are still faster than use of Global catalogs. Anyone have a clue why the indirects are a hair faster? Or am I just getting lucky over and over? I always thought they were slower as well! DW --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] [UD] CALL @progname
I am writing some code that will execute a variable passed in progname using CALL @progname. Question - what is the 'best' way to know that progname exists before I attempt the CALL. I thought about reading the VOC, but if it's globally cataloged, that won't work. I could read the VOC and then the CTLGTB -- but that was two reads just to 'know' the routine wasn't going to blow up. Is there a more efficient or systemic way to do this? **Typically** progname will reference a real program, so this testing is 'overhead' for 99.9% of the time - but if someone were to pass in a bad 'progname', I want to be more graceful (and secure!) just falling over. Since some of the calls will come from 'web connected' clients, and some of the clients may not know for sure that the host cannot handle the request - if the client has a different function list than the host at that point and time... I'm just trying to plan for 'worst case'. How do others handle CALL @ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] CALL @progname
We do this all of the time for our EDI mapping. Since our code is all in 1 file, it is easy. PROG.NAME = JLSH.EDI.OUT856 READV X FROM PROGFILE,_:PROG.NAME:.:EDI.TPNAME, 1 THEN PROG.NAME = PROG.NAME:.:EDI.TPNAME END Obviously if your source code exists in multiple files, you would need logic to determine (and open if necessary) which file to look in. Notice all CAPS, 23 years (although I am open both conventions). UD 6 HP/UX Vance Alspach J L Industrial Supply An MSC Company -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Wolverton Sent: Thursday, March 15, 2007 11:20 AM To: u2-users@listserver.u2ug.org Subject: [U2] [UD] CALL @progname I am writing some code that will execute a variable passed in progname using CALL @progname. Question - what is the 'best' way to know that progname exists before I attempt the CALL. I thought about reading the VOC, but if it's globally cataloged, that won't work. I could read the VOC and then the CTLGTB -- but that was two reads just to 'know' the routine wasn't going to blow up. Is there a more efficient or systemic way to do this? **Typically** progname will reference a real program, so this testing is 'overhead' for 99.9% of the time - but if someone were to pass in a bad 'progname', I want to be more graceful (and secure!) just falling over. Since some of the calls will come from 'web connected' clients, and some of the clients may not know for sure that the host cannot handle the request - if the client has a different function list than the host at that point and time... I'm just trying to plan for 'worst case'. How do others handle CALL @ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ This e-mail is intended for the use of the addressee(s) only and may contain privileged, confidential, or proprietary information that is exempt from disclosure under law. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by replying to the e-mail. Please then delete the e-mail and destroy any copies of it. Thank you. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] CALL @progname
From David Wolverton How do others handle CALL @ As you've pointed out, there's no really good way to do this, at least not one that's easy AND portable. So what about this idea? Create a configuration record or file that has information for all of the methods you know about, then verify against that file? That way you have the control to ensure that all the methods are installed, you have a quick and simple way of checking for a valid method, and could even translate a method name into a valid subroutine with a different name if you so chose. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com ** Check out scheduled Connect! training courses at http://www.PrecisOnline.com/train.html. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] CALL @progname
This test shows the compiled source code exists - not that it's cataloged. If the VOC or CTLGTB were missing, the code shown would still allow the CALL @subroutine to fail. And I had not thought about checking that the compiled code existed! I guess it could happen that the VOC pointer is there, but the compiled code is not? You just added something else for me to check! I wanted simpler! ;-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vance E Alspach (JL - SFD) Sent: Thursday, March 15, 2007 10:50 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UD] CALL @progname We do this all of the time for our EDI mapping. Since our code is all in 1 file, it is easy. PROG.NAME = JLSH.EDI.OUT856 READV X FROM PROGFILE,_:PROG.NAME:.:EDI.TPNAME, 1 THEN PROG.NAME = PROG.NAME:.:EDI.TPNAME END Obviously if your source code exists in multiple files, you would need logic to determine (and open if necessary) which file to look in. Notice all CAPS, 23 years (although I am open both conventions). UD 6 HP/UX Vance Alspach J L Industrial Supply An MSC Company --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] CALL @progname
David, @CALL's are very inefficient and slow. It would be worth doing a speed test. Also, it might be prudent to have significant control over an external process calling an internal one. This is the source of many a virus on MS-Windows. I have used a CASE statement to check a variable and call the appropriate routine. This way, only processes which have been tested and approved can be called by the external process. Cheers, David Murray -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Wolverton Sent: Thursday, March 15, 2007 11:20 AM To: u2-users@listserver.u2ug.org Subject: [U2] [UD] CALL @progname I am writing some code that will execute a variable passed in progname using CALL @progname. Question - what is the 'best' way to know that progname exists before I attempt the CALL. I thought about reading the VOC, but if it's globally cataloged, that won't work. I could read the VOC and then the CTLGTB -- but that was two reads just to 'know' the routine wasn't going to blow up. Is there a more efficient or systemic way to do this? **Typically** progname will reference a real program, so this testing is 'overhead' for 99.9% of the time - but if someone were to pass in a bad 'progname', I want to be more graceful (and secure!) just falling over. Since some of the calls will come from 'web connected' clients, and some of the clients may not know for sure that the host cannot handle the request - if the client has a different function list than the host at that point and time... I'm just trying to plan for 'worst case'. How do others handle CALL @ --- 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] [UD] CALL @progname
If you were going to cover all the possible bases, you would need to do the: 1. VOC 2. OPEN 'CTLG' and read that. This covers 'LOCAL' catalogs 3. CREATE a temporary VOC entry where att1 is 'DIR' att2 is @UDTHOME/sys/CTLG/(first letter of program name) OPEN this file and read using program name as the Key Hoepfully somebody will come up with something simpiliar. But these are the three places I know of where object code can live. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Wolverton Sent: Thursday, March 15, 2007 9:20 AM To: u2-users@listserver.u2ug.org Subject: [U2] [UD] CALL @progname I am writing some code that will execute a variable passed in progname using CALL @progname. Question - what is the 'best' way to know that progname exists before I attempt the CALL. I thought about reading the VOC, but if it's globally cataloged, that won't work. I could read the VOC and then the CTLGTB -- but that was two reads just to 'know' the routine wasn't going to blow up. Is there a more efficient or systemic way to do this? **Typically** progname will reference a real program, so this testing is 'overhead' for 99.9% of the time - but if someone were to pass in a bad 'progname', I want to be more graceful (and secure!) just falling over. Since some of the calls will come from 'web connected' clients, and some of the clients may not know for sure that the host cannot handle the request - if the client has a different function list than the host at that point and time... I'm just trying to plan for 'worst case'. How do others handle CALL @ --- 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] [UD] CALL @progname
Actually - I just ran a test, and was surprised somewhat: 1,000,000 Iterations of ways to do a call... CALL PROGNAME (direct)7047 CALL *PROGNAME (global)7766 CALL @PROGNAME (indirect) 6984 GOSUB (logic contained in-line)1531 Call as Function 10203 I've rearranged the order the routines are called in, and run the test suite over and over... The Indirect calls are CLEARLY faster, with all numbers moving +/- 50, EXCEPT the indirect, which only moved +/- 25 or so. Note that I set the @PROGNAME outside of the call loop - this was not testing how fast the system could set variables - just the difference on the 'calls'. If I include the setting of the name WITHIN the loop, the indirect call went to 7290 or so -- the difference in the 'direct' call vs the 'indirect' call efficiency appears to be in the Variable handling! But both are still faster than use of Global catalogs. Anyone have a clue why the indirects are a hair faster? Or am I just getting lucky over and over? I always thought they were slower as well! DW -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Murray Sent: Thursday, March 15, 2007 11:32 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UD] CALL @progname David, @CALL's are very inefficient and slow. It would be worth doing a speed test. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UD] CALL @progname
Inefficient, but I check for Direct, Local and/or Global. Here is the subroutine that I use, which you can see has three opens. On the positive side, this has not failed me since I started using it. (Hopefully, there are no typos in this.) SUBROUTINE VERIFY.PROGRAM(PROGRAM.NAME,CATALOG.TYPE,CATALOG.PATH) * * Open files, initialize variables * OPEN 'CTLG' TO F.CTLG ELSE STOP 201,'CTLG' OPEN 'CTLGTB' TO F.CTLGTB ELSE STOP 201,'CTLGTB' OPEN 'VOC' TO F.VOC ELSE STOP 201,'VOC' CATALOG.TYPE = '' CATALOG.PATH = '' * * Check for a voc entry * READ VOC.REC FROM F.VOC,PROGRAM.NAME THEN IF VOC.REC1 = 'C' THEN OBJECT.PATH = VOC.REC2 NUM.FIELDS = COUNT(OBJECT.PATH,'/') + 1 * * Check to see if this is a direct catalog * OBJECT.NAME = FIELD(OBJECT.PATH,'/',NUM.FIELDS) OBJECT.FILE = FIELD(OBJECT.PATH,'/',NUM.FIELDS - 1) IF OBJECT.NAME = '_':PROGRAM.NAME AND OBJECT.FILE # CTLG THEN CATALOG.TYPE-1 = 'Direct' CATALOG.PATH-1 = OBJECT.PATH END * * Look in the CTLG file, indicates local catalog * (This could be deceiving if the direct catalog exists.) * READV EXISTS FROM F.CTLG,PROGRAM.NAME,0 THEN CATALOG.TYPE-1 = 'Local' IF VOC.REC3 # '' THEN OBJECT.PATH := ' - ':VOC.REC3 END CATALOG.PATH-1 = OBJECT.PATH END END END ELSE * * Look in the CTLG file, indicates a local catalog, but no * corresponding voc record. This is probably an error, since * without a voc record, I don't think you can call the program. * READV EXISTS FROM F.CTLG,PROGRAM.NAME,0 THEN CATALOG.TYPE-1 = 'Local?' CATALOG.PATH-1 = PROGRAM.NAME END END * * Look in the global catalog directory for the program name * READ CTLGTB.REC FROM F.CTLGTB,PROGRAM.NAME THEN CATALOG.TYPE-1 = 'Global' CATALOG.PATH-1 = CTLGTB.REC3 END RETURN -- Charlie Rubeor Senior Database Administrator Wiremold/Legrand 60 Woodlawn Street West Hartford, CT 06110 Tel: 860-233-6251 x3498 Fax: 860-523-3690 Email: [EMAIL PROTECTED] -- --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] CALL @progname
David, The HELP BASIC CALL help info explains how the CALL and CALL@ work. The variable setting should be included in the loop as it is a valid part of the CALL@ setup. Setting the variable will 'trigger' the CALL@ to find the program again. It is more of a real-life situation than setting the variable out of the loop. Nevertheless, it is interesting results, as CALL@ used to be rather slow. But debugging will be very stressful with [EMAIL PROTECTED] As a side note, I am finding similar zero-speed differences between dynamic and static array usages in large array's. The internals of U2 must be getting more interesting... Cheers, David Murray -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Wolverton Sent: Thursday, March 15, 2007 1:50 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UD] CALL @progname Actually - I just ran a test, and was surprised somewhat: 1,000,000 Iterations of ways to do a call... CALL PROGNAME (direct)7047 CALL *PROGNAME (global)7766 CALL @PROGNAME (indirect) 6984 GOSUB (logic contained in-line)1531 Call as Function 10203 I've rearranged the order the routines are called in, and run the test suite over and over... The Indirect calls are CLEARLY faster, with all numbers moving +/- 50, EXCEPT the indirect, which only moved +/- 25 or so. Note that I set the @PROGNAME outside of the call loop - this was not testing how fast the system could set variables - just the difference on the 'calls'. If I include the setting of the name WITHIN the loop, the indirect call went to 7290 or so -- the difference in the 'direct' call vs the 'indirect' call efficiency appears to be in the Variable handling! But both are still faster than use of Global catalogs. Anyone have a clue why the indirects are a hair faster? Or am I just getting lucky over and over? I always thought they were slower as well! DW -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Murray Sent: Thursday, March 15, 2007 11:32 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UD] CALL @progname David, @CALL's are very inefficient and slow. It would be worth doing a speed test. --- 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] [UD] CALL @progname
David Wolverton wrote: snip Anyone have a clue why the indirects are a hair faster? Or am I just getting lucky over and over? I always thought they were slower as well! In Prime's implementation, which I *believe* was carried over to Universe, the *first* reference to @PROGNAME has to resolve the reference. Which means that it looks up the address that the routine's loaded into. Every subsequent reference uses the already resolved reference. Which is *fast*. So, the programming practice is to define it, snap the link the first time you call it, then keep calling it. Minimal overhead, and gives you a great deal of flexibility in coding. An example of the flexibility would be: BEGIN CASE CASE COMPANY EQ COMPANY.1 INVOICE.RTN = INVOICE.RTN.COMPANY.1 CASE COMPANY EQ COMPANY.2 INVOICE.RTN = INVOICE.RTN.COMPANY.2 CASE 1 INVOICE.RTN = INVOICE.RTN.GENERIC END CASE CALL @INVOICE.RTN (argument list) -- Allen Egerton aegerton at pobox dot com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] CALL @progname
Duh duh duh (slaps forehead). I missed the UD bit in the subject line. Apologies. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Leach Sent: 15 March 2007 20:38 To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UD] CALL @progname David If you look at the MAP command, globally cataloged programs keep track of the number of times they have been run since being cataloged. That suggests that their headers are updated when they are called, which would explain why they are slower. Normally UniVerse cached subroutine object in memory for efficiency until you return to TCL. But I really don't understand why a function is slower. Are you actually using a FUNCTION or a DEFFUN ...CALLING construct? Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Wolverton Sent: 15 March 2007 17:50 To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UD] CALL @progname Actually - I just ran a test, and was surprised somewhat: 1,000,000 Iterations of ways to do a call... CALL PROGNAME (direct)7047 CALL *PROGNAME (global)7766 CALL @PROGNAME (indirect) 6984 GOSUB (logic contained in-line)1531 Call as Function 10203 I've rearranged the order the routines are called in, and run the test suite over and over... The Indirect calls are CLEARLY faster, with all numbers moving +/- 50, EXCEPT the indirect, which only moved +/- 25 or so. Note that I set the @PROGNAME outside of the call loop - this was not testing how fast the system could set variables - just the difference on the 'calls'. If I include the setting of the name WITHIN the loop, the indirect call went to 7290 or so -- the difference in the 'direct' call vs the 'indirect' call efficiency appears to be in the Variable handling! But both are still faster than use of Global catalogs. Anyone have a clue why the indirects are a hair faster? Or am I just getting lucky over and over? I always thought they were slower as well! DW -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Murray Sent: Thursday, March 15, 2007 11:32 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UD] CALL @progname David, @CALL's are very inefficient and slow. It would be worth doing a speed test. --- 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] [UD] CALL @progname
David If you look at the MAP command, globally cataloged programs keep track of the number of times they have been run since being cataloged. That suggests that their headers are updated when they are called, which would explain why they are slower. Normally UniVerse cached subroutine object in memory for efficiency until you return to TCL. But I really don't understand why a function is slower. Are you actually using a FUNCTION or a DEFFUN ...CALLING construct? Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Wolverton Sent: 15 March 2007 17:50 To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UD] CALL @progname Actually - I just ran a test, and was surprised somewhat: 1,000,000 Iterations of ways to do a call... CALL PROGNAME (direct)7047 CALL *PROGNAME (global)7766 CALL @PROGNAME (indirect) 6984 GOSUB (logic contained in-line)1531 Call as Function 10203 I've rearranged the order the routines are called in, and run the test suite over and over... The Indirect calls are CLEARLY faster, with all numbers moving +/- 50, EXCEPT the indirect, which only moved +/- 25 or so. Note that I set the @PROGNAME outside of the call loop - this was not testing how fast the system could set variables - just the difference on the 'calls'. If I include the setting of the name WITHIN the loop, the indirect call went to 7290 or so -- the difference in the 'direct' call vs the 'indirect' call efficiency appears to be in the Variable handling! But both are still faster than use of Global catalogs. Anyone have a clue why the indirects are a hair faster? Or am I just getting lucky over and over? I always thought they were slower as well! DW -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Murray Sent: Thursday, March 15, 2007 11:32 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UD] CALL @progname David, @CALL's are very inefficient and slow. It would be worth doing a speed test. --- 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] [UD] CALL @progname
DEFFUN UTL.MULT.PERCENT.BY.NUMBER.FUNC(PERCENT,NUMBER) FOR ZZZ = 1 TO CYCLE.CNT RESULT = UTL.MULT.PERCENT.BY.NUMBER.FUNC(PERCENT,NUMBER) NEXT ZZZ Routine Function call I think -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Leach Sent: Thursday, March 15, 2007 3:38 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UD] CALL @progname But I really don't understand why a function is slower. Are you actually using a FUNCTION or a DEFFUN ...CALLING construct? Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
