Changing a parameter value of a command dynamically

[Guest.Visitor]

To whom may help... I think this one need a tricky shot. I am using Prompt override program, Choice control program and Validity checking program in my commands. I am getting used to this stuff. But, there is one thing I need to do now and these could not help : I would like to complete a date input on a parameter. Ex : Parameter date --> __________ (YYYYMMDD) If the user enters 17, I would like to complete with current month and current year to make 20000617. My problem is that if I use the Validity checking program to do this, my date will be completed but than passed to the CPP without displaying it to the user. I would like to validate it, than complete it, and if different from the original input after completion, redisplay the command one last time with the completed date. I tried to use a backup value of my date before completing it, than compare it after the completion and send an error (fake) message that says "Date completed". It could not work because when the control returns to the command, it appears that the old value entered by the user is diaplyed back, even if the return value from the VCP had been changed ! And because the command is not getting back the value completed by the VCP, the next time the VCP will be called, it will display the message again and again because the value will be completed at each call... Thanks for a tricky shot, Luc.

[B.Myrick]

Luc, I am pretty sure that you have an IF COND statement to capture the date if it is not complete and use this DO to complete it. How about using a GOTO in the statement after you edit the date field. The TAG would be on or before the SNDRCVF statement. $TAG001: SNDRCVF display_format * begin psuedo code * if the condition of the date is not complete then: complete the date goto tag statement * end psuedo code * Hope this helps, Bret

[Guest.Visitor]

I am not sure of your answer... I am using a command parameter to get this partial date and completing it in a Validity checking program... Because I am asking for other parameters in this command, I would not want to prompt a screen after the command parameters had been entered using my CL Program to ask for a date. I would like to use my command to enter the date with the other parameters I need. I know if I use a CL, it would be easy to use a screen, but using a command has its benefits and I would like to push further this technique.

[B.Myrick]

Luc, Sorry for the answer. My mind must be wandering. I read CPP and did not even register it as a command. Will look into this some more. Does anybody know if you can prompt a command from inside the CL that it calls? Is that considered redundant? Bret

[D.Handy]

Luc, <font color=blue>My problem is that if I use the Validity checking program to do this, my date will be completed but than passed to the CPP without displaying it to the user. I would like to validate it, than complete it, and if different from the original input after completion, redisplay the command one last time with the completed date.</font> You can't there from here. The command prompter, for all its other virtues, has some limitations. This is one of them. Another pet peeve of mine is that a choice program can't return a keyword value directly. Also, be aware that the technique you are using to modify a parm value in the VCP and have it seen by the CPP is unsupported. It is not documented as a feature, and has no guarantee of continuing to work, even though it has worked that way since CPF days until security level 50. At security level 50 it will not work -- the VCP gets the parms by value instead of by reference. Any changes you make will last only till the VCP is done. The CPP gets the same values as the VCP first received. There is no guarantee IBM won't implement this on lower security levels also, so use it at your own risk. Doug

[Guest.Visitor]

Luc, how are you currently handling that parm with respect to your prompt override program? Maybe you could fill in the current date before they even see the parameter. Then they could just correct the day part if necessary with hardly any more keystrokes than typing 17 on a blank field. Barbara Morris

[Guest.Visitor]

Luc, I have written quite a few commands that support *PRV and I think the technique would be similar. To support *PRV, the CPP for the program reprompts itself (it has to be written in a language that supports recursion). To do this the parameters are scanned for *PRV values. In many cases *PRV has to be mapped to a special value. If *PRV is found, the previous value(s) are retrieved and a string containing the command is built. That string is reprompted using QCMDEXC with the prompting characters ?, ?-, ?*, etc. David Morris

[Guest.Visitor]

Good point Barbara ! And it would do it nice. But I would still like a solution where the parameter would becompleted and displayed back (like if the command had an error in the VCP) because there could be other cases where something else than a date be the subject. But regarding my date here, you are right. Thanks for the clue on this, if someone knows a tricky one for the first goal, still looking further... Luc.

[Guest.Visitor]

Hello Luc, I will give this problem a shot: In your command, add an extra parameter (lets call it noChange). It has a default value of YES. In your VCP, if you detect that the date has change (or any other parameter for that matter) also change the noChange parameter valu to NO. In the CPP, test the valu of noChange, if it is yes, branch to the part of the CL that does the actual processing. If noChange equal no, call the command again like this: ?COMMAND PARM1(&parm1) PARM2(&parm2)noChange(YES) RETURN This way, the command get redisplayed with all the correct values. Hope this help

[Guest.Visitor]

Denis, thanks for the that one. Yes it could make it ;o) I am just wandering if my CPP than redisplay the command in this manner, it will also call another instance of the CPP after the redisplay, and when the control get back to the first instance of the CPP, I will have to do a branch to ENDPGM making sure I will not do the processing twice... And if I go further, if the user change the date for another partial at the second prompt, the second instance of the CPP will than redisplay and creat a third instance, and so on... I know if all of them branch to ENDPGM except the one that has no change, it will do it. I am just wandering if there is a way of doing it using the command only and so far, it seems not. In these conditions, this is the best way of doing it, my second choice being to call IBM and ask them if they have spare time at Rochester to do a simple modification to make the command receive back the parameters from the VCP... I think I will just go on with the recursive call, chances may be better... ;o) Luc.

[D.Handy]

Luc, <font color=blue>I think I will just go on with the recursive call, chances may be better... ;o)</font> Chances will be a lot better. The command prompter hasn't seen any improvements for a long time, even though some seemingly simple changes would make a big difference in usability. If you decide to use Dennis' technique, I'd suggest you use the PMTCTL keyword to keep the parameter from being normally displayed. You may also need to add ?- before the keyword in your recursive call in the CPP. Remember also the caveat I mentioned about changing a parm value in the VCP -- it currently works below security level 50 (or is it 40? I forget which), but there is no guarantee of it continuing to work since it is considered an unsupported method. Doug