Command Prompt Override for CL Commands
Hi, I am managing a very large project that has morphed time and time again. Presently a new release of a third-party application that requires tight coupling with various aspects of the primary application was introduced. Instead of the Jr. Programmers going back time and time again to substitute parameters in the CL Commands for changes I would like them to build a program that interfaces with the CL command and the CPP that allows for substitution of parameters from a file or another means. This will reduce the changes required when third-party apps are updated. I also think this will help them with changes to the proprietary code as well.
Not being a programmer myself, I need some assistance in getting them an example so that they can either replicate it or use it as a guide. We are using RPG and Cobol for the most part. The more experienced programmers are being a bit, shall we say difficult, with getting the less senior people up to speed. Any help would be greatly appreciated!
Software/Hardware used:
Software/Hardware used:
ASKED:
February 7, 2006 10:20 PM
UPDATED:
November 26, 2009 9:05 AM
Answer Wiki:
I know that there is likely a straight CL way to do it, but I'm a JCL guy, and not excellent at CL. However, there is a way to do what you're asking for in C. Since you asked for an example, here you go:
Let's assume that I want to issue two commands,
CALL PGM(some library/some program)
CALL PGM(some library/some other program)
and I want to have a single call that takes the library from a parameter in a CL line, but if the parameter is blank, uses MYLIB. I want to take the two program names from record #100 in some file. That should cover all the bases. Here's the sample code:
EXEC SQL INCLUDE SQLCA; /* Needed for inline SQL */
int main(int argc, char *argv[]) { /* All C programs start this way. argc is the number of
arguments, and argv is the vector of arguments */
char library[11]; /* Space for library name and trailing null */
char programA[11]; /* Again, space for name and trailing null */
char programB[11];
char command[80]; /* Here's where I'll build CL commands */
if (argv[1][0]==0) /* Is the 1st argument empty? */
strcpy(library, "MYLIB"); /* Yes - Use the default value */
else /* No */
strcpy(library, argv[1]); /* Use the first argument */
EXEC SQL SELECT pgmA, pgmB -- Get the two program names
INTO :programA, :programB -- And put them in variables
FROM programNames -- From whatever file
WHERE id=100; /* With whatever conditions */
sprintf(command, "CALL PGM(%s/%s)", library, programA); /* Form command */
system(command); /* Execute it */
sprintf(command, "CALL PGM(%s/%s)", library, programB); /* Form command */
system(command); /* Execute it */
return 0; /* Show successful completion */
}
Error checking is omitted for clarity.
--
Sheldon Linker (sol@linker.com)
Linker Systems, Inc. (www.linkersystems.com)
800-315-1174 (+1-949-552-1904)
========================================================
Since previous answers haven't addressed your question, I'll add some comments. You gave a general outline of an idea, but could you give something of an example?
Are you wanting a command that presents different selections of parameter values based on records in a file? If so, it seems like it'd be faster just to recompile the command with new allowed values. I mean, seriously, that only takes 10-15 minutes. It quite likely would take longer to update a "prompts" file since you'd need to update the records for the right parms in the right commands, and a simple mistake at that point could really screw things up. In order to minimize mistakes, you'll need a 'command prompt maintenance' app even if it'll be fairly simple. New parms, new commands, parm value adds, changes and deletions...
Bear in mind that prompt-overrides require selecting "key" parameters. These are always required in order to instruct the prompt-override program what to do.
In addition to maintenance of the prompts database, you also need to code the prompt-override programs themselves. Would you expect to code a different one for every command? Or will there be one program intelligent enough to handle all parms for every different command? How many commands? What happens if a new parm must be added? (Or existing parms removed?)
Will there be allowances for 'special values'? 'Single values'? Default values? Lists of values?
A prompt-override program is useful when you have something like 'update item #A10234' and you want to present all the current values for item #A10234. You can see how these programs work with a lot of 'Change' commands such as CHGUSRPRF. If that's what you want yours to work like, supply a basic example and we'll work it through.
Tom
To see all answers submitted to the Answer Wiki: View Answer History.
One way to do this is to anticipate the future parameters, include them in the program(s) and passing nulls until needed to become active and tweak the logic accordingly:
“if ParmX not null
then
do something
else ignore”.
Hope this helps.
good luck!