BR Forum

Hey George,

I know that you use "PROC tt" to set lots of "global" variables at the beginning of every program. I'm thinking of doing the same. I have a great need to cut down on the redundancy in each of my programs. Long ago, I used a program generator to create most of my programs. This was before libraries, so all of the "common code" was duplicated in every program. Then as time went on and my program generator didn't work the way I wanted it to, I started simply cannanalizing existing programs to create new ones. (I'm sure no one here has every done that ). Anyway, now most of my programs have a LOT of common code that I'd like to pull out into libraries or TT procs or whatever is most appropriate.

Questions:

1. Do you just keep the tt file as a static file or is it generated dynamically by a BR program?

I had an idea. I thought that if I "generated" the TT text file from a program, I could create more dynamic values in it that would be updated constantly, such as formatted date strings for "today", or assigning folder names for different applications and things like that. I'm sure there are loads of other things that this would enable me to do too. In other words, I'd create a program that I run on a regular basis (haven't decided if it would be daily, or when I launch a menu or what...) .

But that program could open a new text file "TT_GLOBAL", write the "static" tt lines in the original TT file and then add dynamic values based on other criteria. So if most of my programs depend upon a value "DATEYMD" that is calculated at the beginning of every program, I'd do this in my global setup program and write it to the TT_GLOBAL file like any other value. (Yes I know I can use the DATE/DAYS functions to get that particular value, but I have loads of old programs that use other variables, so it would maintain compatibility wit those.)

2. Do you PROC in TT in mostly every program as a routine?

3. Is there a way to handle variables in TT that are larger than the default size of 18 bytes for undim'd strings? I have a longer string that is my application name - used in multiple places in almost every program. I thought that I could load this as well, though I can't figure out how I can dim it from a PROC. Is there a way?

-- Susan

George L. Tisdale, CPA
Tisdale CPA
75 Junction Square Drive
Concord, MA 01742
(978) 369-5585
IRS Circular 230 Notice: "To ensure compliance with requirements imposed by the IRS, we inform you that any U.S. tax advice contained in this communication (including any attachments) is not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein."
This electronic message transmission contains information which is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination or distribution of this communication to other than the intended recipient is strictly prohibited. If you have received this communication in error, please notify us immediately by calling (978) 369-5585 or by electronic mail (gtisdale@tisdalecpa.com) Thank you.


From: br_forum-bounces@ads.net [mailto:br_forum-bounces@ads.net] On Behalf Of Susan Smith
Sent: Sunday, May 10, 2009 10:29 PM
To: BR Forum
Subject: [BR_forum] George - PROC TT



Hey George,

I know that you use "PROC tt" to set lots of "global" variables at the beginning of every program. I'm thinking of doing the same. I have a great need to cut down on the redundancy in each of my programs. Long ago, I used a program generator to create most of my programs. This was before libraries, so all of the "common code" was duplicated in every program. Then as time went on and my program generator didn't work the way I wanted it to, I started simply cannanalizing existing programs to create new ones. (I'm sure no one here has every done that ). Anyway, now most of my programs have a LOT of common code that I'd like to pull out into libraries or TT procs or whatever is most appropriate.

Questions:

1. Do you just keep the tt file as a static file or is it generated dynamically by a BR program?
[George Tisdale] Kept as a static file. Your example below can be handled by BR any simply including as a line in the static text file:
let today=date(“cymd”)
or
let today$=date$(days(date),”Month d, cy”)


I had an idea. I thought that if I "generated" the TT text file from a program, I could create more dynamic values in it that would be updated constantly, such as formatted date strings for "today", or assigning folder names for different applications and things like that. I'm sure there are loads of other things that this would enable me to do too. In other words, I'd create a program that I run on a regular basis (haven't decided if it would be daily, or when I launch a menu or what...) .
[George Tisdale] DON’T! You would undo all the benefits of setting automatic values if you required the values to be reset by a program daily.


But that program could open a new text file "TT_GLOBAL", write the "static" tt lines in the original TT file and then add dynamic values based on other criteria. So if most of my programs depend upon a value "DATEYMD" that is calculated at the beginning of every program, I'd do this in my global setup program and write it to the TT_GLOBAL file like any other value. (Yes I know I can use the DATE/DAYS functions to get that particular value, but I have loads of old programs that use other variables, so it would maintain compatibility wit those.)

2. Do you PROC in TT in mostly every program as a routine?
[George Tisdale] Yes, every program contains

00202 execute “PROC =:vol002tt”


3. Is there a way to handle variables in TT that are larger than the default size of 18 bytes for undim'd strings? I have a longer string that is my application name - used in multiple places in almost every program. I thought that I could load this as well, though I can't figure out how I can dim it from a PROC. Is there a way?
[George Tisdale] Variables larger than the base size must be dimensioned in the program before executing the PROC. Array length must be dimensioned, but the PROC can use a MAT statement to set the number of elements before populating. RTFLIB.dll uses this method.


-- Susan

Small note – if you proc any of your programs, than instead of procing these things in subproc them in… like so:

00202 execute “*SubPROC =:vol002tt”

Because a proc will destroy/override a preious proc that may be running, but a subproc will work irregardless.

I might even suggest the leading * (shown above) that will remove these entries from your F2 command history… remove for testing, but in practice, those sorts of things get annoying.

I proc in a lot of dynamic variable names. Or perhaps I should say I *subproc in a lot of variables generated by BR! library functions… I simply make the function$ return the whole command then I execute fn_my_constants$ or something like that.

-john

From: br_forum-bounces@ads.net [mailto:br_forum-bounces@ads.net] On Behalf Of George Tisdale
Sent: Monday, May 11, 2009 7:01 AM
To: Business Rules Forum
Subject: Re: [BR_forum] George - PROC TT





George L. Tisdale, CPA
Tisdale CPA
75 Junction Square Drive
Concord, MA 01742
(978) 369-5585
IRS Circular 230 Notice: "To ensure compliance with requirements imposed by the IRS, we inform you that any U.S. tax advice contained in this communication (including any attachments) is not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein."
This electronic message transmission contains information which is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination or distribution of this communication to other than the intended recipient is strictly prohibited. If you have received this communication in error, please notify us immediately by calling (978) 369-5585 or by electronic mail (gtisdale@tisdalecpa.com) Thank you.


From: br_forum-bounces@ads.net [mailto:br_forum-bounces@ads.net] On Behalf Of Susan Smith
Sent: Sunday, May 10, 2009 10:29 PM
To: BR Forum
Subject: [BR_forum] George - PROC TT



Hey George,

I know that you use "PROC tt" to set lots of "global" variables at the beginning of every program. I'm thinking of doing the same. I have a great need to cut down on the redundancy in each of my programs. Long ago, I used a program generator to create most of my programs. This was before libraries, so all of the "common code" was duplicated in every program. Then as time went on and my program generator didn't work the way I wanted it to, I started simply cannanalizing existing programs to create new ones. (I'm sure no one here has every done that ). Anyway, now most of my programs have a LOT of common code that I'd like to pull out into libraries or TT procs or whatever is most appropriate.

Questions:

1. Do you just keep the tt file as a static file or is it generated dynamically by a BR program?
[George Tisdale] Kept as a static file. Your example below can be handled by BR any simply including as a line in the static text file:
let today=date(“cymd”)
or
let today$=date$(days(date),”Month d, cy”)


I had an idea. I thought that if I "generated" the TT text file from a program, I could create more dynamic values in it that would be updated constantly, such as formatted date strings for "today", or assigning folder names for different applications and things like that. I'm sure there are loads of other things that this would enable me to do too. In other words, I'd create a program that I run on a regular basis (haven't decided if it would be daily, or when I launch a menu or what...) .
[George Tisdale] DON’T! You would undo all the benefits of setting automatic values if you required the values to be reset by a program daily.


But that program could open a new text file "TT_GLOBAL", write the "static" tt lines in the original TT file and then add dynamic values based on other criteria. So if most of my programs depend upon a value "DATEYMD" that is calculated at the beginning of every program, I'd do this in my global setup program and write it to the TT_GLOBAL file like any other value. (Yes I know I can use the DATE/DAYS functions to get that particular value, but I have loads of old programs that use other variables, so it would maintain compatibility wit those.)

2. Do you PROC in TT in mostly every program as a routine?
[George Tisdale] Yes, every program contains

00202 execute “PROC =:vol002tt”


3. Is there a way to handle variables in TT that are larger than the default size of 18 bytes for undim'd strings? I have a longer string that is my application name - used in multiple places in almost every program. I thought that I could load this as well, though I can't figure out how I can dim it from a PROC. Is there a way?
[George Tisdale] Variables larger than the base size must be dimensioned in the program before executing the PROC. Array length must be dimensioned, but the PROC can use a MAT statement to set the number of elements before populating. RTFLIB.dll uses this method.


-- Susan

John,

Could you expand on this a bit? What do you mean by variables generated by libraries and also having the "function return the whole command"? Can you give an example?

-- Susan

John Bowman wrote:

<![endif]--> <![endif]--> I proc in a lot of dynamic variable names. Or perhaps I should say I *subproc in a lot of variables generated by BR! library functions… I simply make the function$ return the whole command then I execute fn_my_constants$ or something like that.

-john