Doug, I'm not sure, but I think there is now a command exit point where you can alter shows up. That'd be a program where you COULD have these popups, I think. Not exactly what you are suggesting (which I've wished for, too, in some form) but maybe another way.

What I would like is for the returned values to be used for validation, which they are not at this time.

BTW, I'm not a contact point at IBM - just an interested customer.


At 10:24 AM 3/19/2004 -0500, you wrote:
Vern, Guy, et al,

>Send your comments, wants, etc., to this list - he's listening - seriously.

Does the command prompter fall in the realm of CL enhancement requests? There
is one feature which I believe would have to be trivial to implement, but would
really extend the usability of choice programs.

What I'd dearly love to do is have the choice program be able to provide its own
interface -- say a windowed lookup to a database -- then when the user selects
an entry be able to pass back a parameter value for the keyword without ever
seeing the typical parameter prompt screen.

Currently, choice programs work well for short lists of dynamic data, but have a
major annoyance for larger dynamic data. Since I always have windowed lookup
subfile programs for other HLL programs to call to let a user find a say a
customer or product number, it was very easy to make a choice program which does
the following:

- For request type C, simply return a string including "..., F4=Prompt"
- For request type P, prior to returning the text to display on the next panel,
I first call my windowed subfile lookup and allow them to position / sort the
file select an entry.

The problem is, at that stage my choice program knows exactly what value the
keyword should get, but there is no way for me to pass it back to the command
prompter. Instead, I have to insert the selected key into a string to pass back
as the choice text, where it then gets displayed to the user but they have to
rekey it on the regular prompt panel.

What I'd like to propose is the ability to have the choice program signify it
has already handled the user interface or otherwise determined the desired
parameter value, and just pass that back to the command prompt directly.

My suggestion, in order to retain backward compatibility and not require a new
parameter to choice programs, would be to allow a choice program to change the
request code byte of "P" to something else -- say R for Return -- and then have
the command prompter treat the second choice pgm parameter as an actual keyword
value instead of a list of values to display to the user.

This would allow us to easily "extend" the command prompter to provide whatever
keyword prompt is appropriate, and it shouldn't break any existing code. Nor
should it take a long time to document in however many languages the manuals are
in these days.

The command prompter is one of the often under-utilized strengths of the system,
yet it hasn't seen much change since early CPF days, other than POPs added in
V1R2 (as I recall the timeframe).

Just my .02,
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.