F4 to prompt for file member list
Jeff Crosby
he/she wants to use. I could have sworn that I once saw such an
article in News/400 where the user could press F4 when the cursor was
on that parm, and be presented with a member list from the file, in real
time. I searched the CD-ROM reference library (just got the new one
today) and could not find it.
Am I dreaming, or does anyone else remember such an article? Thanks.
--
-Jeff
Dave McKenzie
day. It involves the CHOICEPGM parm on the PARM stmt in the cmd.
Search in the CL Programming book (in the System Programming Support
bookshelf).
--Dave
On Tue, 08 Sep 1998 15:37:36 -0500, Jeff Crosby <jlcr...@fwi.com>
wrote:
Gary Guthrie
I don't think there's an article. I answered a couple of Tech Corner items about choice
programs in the January, 1997 issue of NEWS/400 that might help you some.
See "List of Currently Existing User Profiles" (January 1997, Tech Corner, page 109) and
"CL Command Exit Program" January 1997, Tech Corner, page 110). These two items answer
several questions about choice
programs and provide code for a sample choice program.
Hope this helps,
Gary Guthrie
Editor, The RPG Source
Technical Editor, NEWS/400 magazine
Ann Lewkowicz
wrote:
>I have a need in a command to allow the user to select the file member
>he/she wants to use. I could have sworn that I once saw such an
>article in News/400 where the user could press F4 when the cursor was
>on that parm, and be presented with a member list from the file, in real
>time.
I think I remember Don Schenck doing a presentation on that once,
which I attended. perhaps he could explain it again?
- Ann -
Charles R. Pence
>
> I have a need in a command to allow the user to select the
> file member he/she wants to use. I could have sworn that I
> once saw such an article in News/400 where the user could
> press F4 when the cursor was on that parm, and be presented
> with a member list from the file, in real
> new one today) and could not find it.
>
> Am I dreaming, or does anyone else remember such an article?
Unless there has been some improvements to the CL prompting interface,
the PARM's CHOICEPGM for a command definition is not going to help you
much. From what I remember, there was no way to pass to the choice
program, the current lib/file specified on a prompted command, so unless
the parameter for lib/file had a <constant> name known to the
program... Let me know if you find otherwise, because I think I'll have
to dig out some of my old requests/enhancements for new investigation.
Regards, Chuck
-- Comments provided "as is" with no warranties of any kind whatsoever.
Douglas Handy
>From what I remember, there was no way to pass to the choice
>program, the current lib/file specified on a prompted command,
You are correct. The choice program has no way of knowing the
contents of other parameters in the command, so it has no way knowing
for which file or library to create a member list.
>I think I'll have
>to dig out some of my old requests/enhancements for new investigation.
Since you mention it, can you tell me why there is not an option for a
choice program to directly return a value to use for the parameter?
I use choice programs extensively. A common problem is parameters
which can be selected from a database file, e.g. customer number or
product. I sure don't want to return the whole file back for the user
to scroll through, even if the size of the value list parameter wasn't
as issue. Here is how I currently handle this:
Most of my database files have a corresponding program which can be
called to put up a subfile selection window with position to, etc.
These are called from a HLL program when the user presses F4 in the
corresponding field. If a command parm ever needs to select from the
file, I put a choice program wrapper around it. The choice pgm just
tests for the C or P. For type C, it returns something like
"Character Value, F4=Prompt". For type P, it first calls my standard
selection window program for the file. This puts up the window and
waits for the user to select a value. If a record is selected, the
choice program sets the return parm to something like "Value selected
was xxxxxxx". This shows up fine on the "Specify Value for Paramater
XXX" display, but the user must key the value to get it into the parm.
I would much rather be able to signal that the return value is the
actual parameter value instead of a choice list. Maybe something like
change the "P" in byte 21 of the first paramter to R (for Return) then
put the actual value in the second choicepgm parm.
Doug
Tim
validity check program.
Douglas Handy wrote in message <35ff83e7...@www.newslink400.com>...
Worley Barry
>Chuck,
>
>>From what I remember, there was no way to pass to the choice
>>program, the current lib/file specified on a prompted command,
>
>You are correct. The choice program has no way of knowing the
>contents of other parameters in the command, so it has no way knowing
>for which file or library to create a member list.
>
>Doug
I've used a data area to pass the previously selected command
parameters to the choice program. I don't remember just exactly how but it
was one of the program types that was called when a parameter was entered.
If you're interested I'll go find the command and be more specific.
--
Regards, Worley
Douglas Handy
> I've used a data area to pass the previously selected command
>parameters to the choice program. I don't remember just exactly how but it
>was one of the program types that was called when a parameter was entered.
>If you're interested I'll go find the command and be more specific.
In the case of wanting a member list, I can see how this would work
by using a POP -- define the file() as a key parm but not mbr(), and
let the POP save the file() contents in QTEMP.
Thanks for the idea -- maybe Jeff can use this technique.
Doug
Douglas Handy
>Sounds like an application for either a prompt override program or a
>validity check program.
Can you elaborate? I don't see how either a POP or VCP effectively
gets the results I am looking for (which is to allow F4 to select a
parm value from a database file and return it to the command).
Using a POP can work around the problem of the choicepgm not knowing
the value of a key parm as mentioned by Worley.
I tried using a VCP, but that means you can't use F4 to prompt the
parm, you have to use something like *SELECT or maybe even the absence
of a value. But it doesn't work at security level 50, since at level
50 changes made by a VCP to parms are not seen by the CPP.
Doug
Jeff Crosby
> by using a POP -- define the file() as a key parm but not mbr(), and
> let the POP save the file() contents in QTEMP.
>
> Thanks for the idea -- maybe Jeff can use this technique.
>
Hmmm. I may be able to do that. After I put out a few fires anyway.
<g>
--
-Jeff
Charles R. Pence
not be able to select from the list; especially from a hard-coded list
of available values. Basically this is the same thing/reason as not
being able to just return the data from the CHOICEPGM to the parameter.
Some of the solutions for lists I have seen in system commands:
the WRKJOB OPTION(*SELECT) which brings up a menu
the CRTTBL SRCFILE(*PROMPT) which brings up a display file
the CHGJOB DUPJOBOPT(*SELECT) which brings up a list of
duplicate job names from which a selection can be made;
The distinguishing feature being that the user has to press Enter, thus
indicating their work at the command level is complete.
My preference for the last would be CHGJOB (*N/CRP/QDFTJOBD), then from
F4=Prompt on job number I would get the list of jobs matching the job
name and user. After the selection, the POP would pre-fill all the
*SAME values. Only then making additional mods to the other parameters,
and then press Enter.
After seeing the other responses <I sure missed an obvious solution
here!?>, I could change my perspective... and accomplish what I want
with a POP <and sharing data between the POP and CHOICEPGM>. It just
seemed to me more intuitive, to ask on the PARM statement, to have the
prompter pass into the CHOICEPGM existing data from a list of other
PARM(s). Don't know why I didn't think of <or had, but forgot since I
had to dismiss the idea> passing the needed PARM data from the POP to
the CHOICEPGM.
Are there any problems with being able to make the POP destroy the
shared "data area"? If this is a problem, then I would have dismissed
the idea. I've never done a VCP; could that program do the cleanup if a
POP can not?
Douglas Handy
>Yes I've always thought it was rather daft to press F4=Prompt and then
>not be able to select from the list; especially from a hard-coded list
>of available values. Basically this is the same thing/reason as not
>being able to just return the data from the CHOICEPGM to the parameter.
I've always thought it was pretty daft too. My reason for bringing it
up was your mentioning of revisiting enhancement requests. This seems
like such an obvious enhancement to choicepgms that I can't believe we
have made it through this many versions/releases without it. It
doesn't seem like it should be *that* hard to modify the command
prompter to recognize a return code/parm value from the choicepgm, and
shouldn't break any existing code.
>Are there any problems with being able to make the POP destroy the
>shared "data area"? If this is a problem, then I would have dismissed
>the idea. I've never done a VCP; could that program do the cleanup if a
>POP can not?
The POP cann't do the cleanup, because it has to end after creating
the data area. This would be before the choicepgm gets called. It
would be possible to delete the data area from a VCP, although I'm not
even sure that would be worth the bother unless a VCP were already
being used for the command. You'd want to create the data area in
QTEMP anyway to avoid collisions with concurrent users.
This technique does solve the problem of passing key parms to a choice
program, so enables a solution to Jeff's original question.
It still does not solve my desire to have a choicepgm directly return
a keyword's value. :(
I just wanted to make sure it got on your list of enhancement
requests. :)
Doug
Worley Barry
>Worley,
>
>> I've used a data area to pass the previously selected command
>>parameters to the choice program. I don't remember just exactly how but
>>it was one of the program types that was called when a parameter was
>>entered. If you're interested I'll go find the command and be more
>>specific.
>
> In the case of wanting a member list, I can see how this would work
>by using a POP -- define the file() as a key parm but not mbr(), and
>let the POP save the file() contents in QTEMP.
>
>Thanks for the idea -- maybe Jeff can use this technique.
>
>Doug
I used PMTCTLPGM on a library/file qualified parameter, it passes
command, keyword, and parameter value to the program. The program creates
the data area with the passed information.
In the CHOICEPGM for the member parameter, I check to be sure I got
the right command and keyword in the data area, do a DSPFD *MBRLIST to an
outfile, receive the outfile, and substring member and text into the
choice array.
This way I only create the file when the member choice is selected.
--
Regards, Worley
Tim
system. however, we have used a VCP and a POP to accomplish something
similar to what you want.
A special value in a key parm could trigger a POP. which would prompt your
database file.
A VCP can perform similarly except that it is not called until the user has
finished keying the other parameters.
A problem with the CHOICEPGM is that each entry can only be 30 some bytes
long and the entire return structure can only be 5K (or thereabout).
Furthermore, the return structure is ugly for RPG and CL programs(Although
for a PL/I program this structure in very convenient)
Perhaps a resolution should be put in at the next COMMON to allow a choice
program to return a value directly to the command.parm.
Douglas Handy wrote in message <3601bb84...@www.newslink400.com>...
Charles R. Pence
>
> <<SNIP>>
> I've always thought it was pretty daft too. My reason for bringing it
> up was your mentioning of revisiting enhancement requests. This seems
> like such an obvious enhancement to choicepgms that I can't believe we
> have made it through this many versions/releases without it.
> I just wanted to make sure it got on your list of enhancement
> requests. :)
>
Doh! Problem is we are waiting for the same enhancement... I was
waiting so I could use that <currently missing> function to improve
other function(s). Take for example a command like DSPPFM which, like
the original question, could take advantage of presenting a list of
members from which the user could choose a member. In an interface
standard (CUA, SAA, or??) I once read <it stated> the user should be
able to choose the directive against an item in a <presented> list <eg.
5=DSPPFM from WRKMBRPDM>, or from the directive, the user should be able
to get a list <presented> of items from which to choose <as the target
of the directive>. This exists for a list of special values <with the
exception being the "choose" is not a select-list; just a list of values
which the user can type>.
If it were implemented like other functions on the system I can see it
now: DSPPFM (QGPL/QCLSRC) MBR(*SELECT); the command only presenting the
list after Enter is pressed. Then when the user makes the selection,
the processing does not return to the <prompted> command to allow
further updates to parameter specifications like FROMRCD, but proceeds
on to the function of displaying the member <of course because rather
than F4=Prompt to go to a CHOICEPGM, it must instead call the CPP>.
So in order to reduce the list, a new parm like SUBSET() must be added
<presented DEPendent on the MBR parm's value of course>. And if the
user specified the wrong subset, they can not get back to the prompted
command, so the list program should probably both show the current, and
allow change to, the subset criteria. Not to suggest this is a terrible
implementation, just that it seems to me, to be less intuitive and too
restricting.
Douglas Handy
>Doh! Problem is we are waiting for the same enhancement...
True, but you have better contacts than I do ... <g>
Doug