On 28 Aug 2012 13:37, fbocch2595@xxxxxxx wrote:
as part of a command we allow programmers to use that copies files
from one i to another, I'd like to change it up so that the library
on the TOFILE can not be changed but the file can be changed. I'm not
sure how that's done since TOFILE includes the file along with the
library. So, if midrange nation can tell me how it's done and/or
gimme some code, I'd appreciate it.
<<SNIP prompted CPYF command showing kwd view>>
So there is already a command that has a CPP, which apparently
eventually [calls something that] presents an interactive prompted
request such as?:
?CPYF ??TOFILE(SomeLib/SomeFile) ...
And the issue is that there is no capability via the "selective
prompt characters" feature of the command prompter to hide or protect
just one element of a QUAL specification of a Command definition; i.e.
there is no way to allow the value SomeFile to be modified, while also
preventing the value SomeLib from being modified, because the selective
prompt feature acts only on an entire parameter rather than on portions
of qualified names and elements.? If so...
In a similar scenario long ago, I had used QCMDCHK to get the
resolved command string from the prompted request, then verified the
value remained unchanged from its prompted value, then either requested
[by an inquiry message and re-prompting] or effected correction of the
parameter specification directly within the command string, and finally
invoked the verified [or the corrected and re-verified] command string
using QCMDEXC [or QCAPCMD]. My scenario required, similarly, an OUTFILE
library name to remain unchanged. And prior to changing the code to
force the library name, I had retrieved the file and library name from
the completion message sent by the feature that created or directed to
the named output file; since the change, both names were derived from
the command string. I would have created my own command and then
invoked the other utility, but the command and the amount of flexibility
the user required for their specifications of the command made that
option unpalatable. That said...
If the capabilities of the CPYF allowable for use by the programmers
in their prompted requests ["as part of a command" already in use] is
somewhat limited in scope, then creating a private command and a CPP
that does little more than invoke the equivalent *SYSTEM/CPYF [or if
prompted again, then probably *NLVLIBL/CPYF] request is easily a better
choice over /parsing/ and possibly modifying the command string and thus
having to use interpreted versus compiled [though optionally prompted]
command requests. For example, the following prompted command
invocation coded in a CLP protects but displays a ToFileLibr() parameter
value of 'SomeLib', while enabling the user to modify the ToFileName()
parameter value from 'SomeFile' to any other allowed name-value that the
programmer\user chooses:
?SIMPLECPYF ?*TOFILELIBR(SomeLib) ??TOFILENAME(SomeFile) ...
The TOFILELIB and TOFILE parameters of the SIMPLECPYF would be
defined as simple names instead of as QUALified names, and the specified
values could be passed to the CPYF command [shown below as prompted, but
that is optional; the intent is to show the protected qualified name,
which if TOFILENAME had been changed to 'ThatFile' in the SIMPLECPYF
invocation then the resolved parameter would become
TOFILE(SomeLib/ThatFile) in the following invocation]:
? *SYSTEM/CPYF ?*TOFILE(&ToFileLibr/&ToFileName) ...
Note: the CPP for the SIMPLECPYF command would best specify
effectively all parameters on that CPYF invocation to prevent changed
defaults [to the CPYF command] from impacting the behavior [of the
SIMPLECPYF command].
midrange.com
