You could use an indirection in the I-Descriptor as well - use a SUBR which then constructs a subroutine name and uses CALL @ syntax.....For preference I would resolve all these at the start of a user session in "one fell swoop" and store the names in a dimensioned named COMMON block, using EQUATES. On the real plus side, I've used the technique in the past to dry-run code without having to use real-world interactions - a "test harness". The "harness" reads parameters in a file with a set sequential order and calls the named subroutine with set arguments and/or COMMON variables.
The result from each call (argument or COMMON or "this-record-in-this-file" is then retrieved using a rule-based schema and compared with an anticipated result. The answer is either "pass" or "fail (reason). It's a good way of bench-checking complex code and also regression testing. Rather than a parameter file to see if a program is running in "test mode" or not, I much prefer an Environment variable. This is also useful with UniData as you can include Environment variables in VOC file pointers - a different user running in the same account can be using totally different files to someone else. Both UniData and UniVerse allow you to query an Environment variable ..........E.g. F D_CUSTOMER @FILE_LOCATION/CUSTOMER (You may want to look at UDT.OPTIONS 87 as well if you use this technique). Regards JayJay -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Israel, John R. Sent: 22 May 2008 22:11 To: [email protected] Subject: RE: [U2] execute code/proc question HELP!!!!!!!! Not really a lot of work. Once your tester program is written (should not be very big), your code would change FROM something like: CALL XXXX(ARG1, ARG2...) To CALL VERSION.TESTER(XXXX) CALL @XXXX(ARG1, ARG2...) (or something like that) Off the top of my head, this should not be too bad. Just make sure you find ALL the programs that call XXXX and change them at the same time. The one place this does NOT work well is with I-Desc because they are hard-coded to use the name XXXX. However, I would not worry about these until they become an issue. As long as you keep the limitations of this in mind, it works amazingly well. John Israel Sr. Programmer/Analyst Dayton Superior Corporation 721 Richard St. Dayton, OH 45342 937-866-0711 x44380 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of doug chanco Sent: Thursday, May 22, 2008 4:42 PM To: [email protected] Subject: Re: [U2] execute code/proc question HELP!!!!!!!! hmmm this is a very interesting idea .......... thank you very much, its not as elegant as the path command but I think it will do what I need but if I understand it correctly there 2 things that have to be done 1. logic added to each program for this tester subroutine 2. the program would have to have a different name from the original program while step one would be a lot of work, I can see it working pretty well once the logic is in most of the programs thanks! dougc Israel, John R. wrote: > Write a simple tester subroutine that passes the name of the > original/standard program. > > This subroutine reads a control record that uses your > user_id:"*CODETESTING" as the key (thus unique to each user). If not > found (which would be the case for most users), return the original > program name. If found, do a LOCATE in F1 for the original program > name. If not found, return the original program name. If the original > program name IS found in F1, return the optional program name from the > associated position in F2 (if F2 is missing, return the original pgm > just in case). > > F1 = multi-valued list of original pgms > F2 = multi-valued list of test pgms > > Use the @ logic for doing a dynamic call to the returned pgm name. > > Granted, this is a bit of work up front, but once you have this tester > subroutine written and the coded added to your program(s), you could > leave this test in place anywhere you want. Add this logic as you need > it. You just disable it by removing the program names from F1/F2. If > this control record ever becomes empty, you could even delete it. > > Optionally, you could do this test at login time and save the info in > some common named variable(s). You just need to log out/in to reset > this stuff. > > I have used something like this in the past and it worked VERY well. By > using these control records, you can even give selected other users > access to this program for testing before rolling it out to the rest of > the world. Just remember to delete the stuff from the control record(s) > once you switch it over. > > > > > John Israel > Sr. Programmer/Analyst > Dayton Superior Corporation > 721 Richard St. > Dayton, OH 45342 > 937-866-0711 x44380 ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
