Thanks for the response. I've deleted the PRINT throwaway connective on my U2 client's systems over these last 14 years with no adverse effects.
I chose the word PRINT based on earlier forms of dartmouth basic whereby their command line was permanently in a BASIC command interpeter. If you typed 10 PRINT X, you stored a line of code at line number 10. If you typed PRINT X, you displayed the value of X left over from the most recent run of the program. Sort of like our debugger. If you typed X=10, then so be it, the value of X became 10. But you didn't see anything. TCL and Basic were very intertwined then. I just got used to testing and/or seeing what 5+5 was that way. You can name it anything you want. As far as the multi-users concept. Most of my environments have just me as the Pick person with access to TCL. If you have a multiple programmer environment, then modify userid or portno as required. My multiple programmer environments's other programmers are somewhat stubborn for new ideas from me. Too bad, I have a bunch of utilities that I've published in Spectrum and/or Datastream that serve me constantly to this day that fall on deaf ears. One is a modified LISTDICTS limiting the display to just the field number desired instead of wading through all of the previous attributes. Another is a utility to display any data file using the existing dict items sort of like an Access Form View. These 2 tools allow me to quickly learn a new client's system, data-wise. Thanks for your response. ----- Original Message ----- From: "Timothy Snyder" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 20, 2004 10:09 AM Subject: Re: [U2] [UD] running a subroutine > "Mark Johnson" <[EMAIL PROTECTED]> wrote on 10/20/2004 08:53:46 > AM: > > > In fact, I welcome any criticisms or limitations anyone would have > against > > establishing this PRINT command to handle everything. > > This is an intriguing concept, and does seem to have its uses. A couple of > issues that occurred to me are: > > 1) This could cause problems in a multi-user environment. The %PRINT% item > should probably include a port number, PID, or something else unique so you > don't end up creating and compiling something, only to have it overwritten > by somebody else before you execute it. Granted, that's not likely, but on > a very busy system with many users, it's certainly a possibility. Of > course, you'd have to clean up the generated source and the object after > the EXECUTE instead of before, to avoid littering up your BP file. > > 2) This relies on the fact that the name of the program is also a basic > command. The logic as it is precludes changing the name to anything other > than PRINT. If PRINT also exists as a command or other VOC entry, you're > out of luck. (You do allude to this when you say that on UniData, where > PRINT is a keyword, this should be globally cataloged instead of creating a > VOC entry.) On general principal, I'd prefer to name it something that's > more descriptive of its purpose. I think I'd be tempted to change the name > to DO.BASIC, or something like that. Then of course you'd have to change > the logic so you strip out the first word of the command line that you > place in TEST. This would also mean that you don't have to put a dummy > argument at the beginning of the command line if you don't actually want to > print anything. So, instead of > PRINT ; CALL SUBROUTINENAME(VAL1, VAL2, VAL3) > you could just say > DO.BASIC CALL SUBROUTINENAME(VAL1, VAL2, VAL3) > > > Thanks for sharing this interesting idea. > > > Tim Snyder > IBM Information Management > Consulting I/T Specialist , U2 Professional Services > ------- > 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/
