"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/
