I don't think you'll get anywhere with SDA because CL can't write to
files. The DSM APIs are possibly overkill, but they seem like they
might get the job done for you (if you are happy with ILE CL). I have
no personal experience with them however.

Alternatively, writing your own Commands might be the way to go,
depending on exactly what you are trying to achieve. (This would only
be suitable for very simple interactions.)

Finally, there is UIM, but I don't know enough about that to offer any
comment as to how suitable it might be.

walker.l2 wrote:
> I don't think you'll get anywhere with SDA because CL can't write to
> files. The DSM APIs are possibly overkill, but they seem like they
> might get the job done for you (if you are happy with ILE CL). I have
> no personal experience with them however.
>
> Alternatively, writing your own Commands might be the way to go,
> depending on exactly what you are trying to achieve. (This would only
> be suitable for very simple interactions.)
>
> Finally, there is UIM, but I don't know enough about that to offer any
> comment as to how suitable it might be.
>

In the past you could use DCLF for a display file and SNDRCVF (w/RCDFMT
parm) to put/get data from a green screen. I haven't done it years, but
it would be worth a try.

--
Karl Hanson

Karl Hanson wrote:
> walker.l2 wrote:
>> I don't think you'll get anywhere with SDA because CL can't write to
>> files. The DSM APIs are possibly overkill, but they seem like they
>> might get the job done for you (if you are happy with ILE CL). I have
>> no personal experience with them however.
>>

>
> In the past you could use DCLF for a display file and SNDRCVF (w/RCDFMT
> parm) to put/get data from a green screen. I haven't done it years, but
> it would be worth a try.
>

After sending the last post I searched InfoCenter using 'SNDRCVF' - this
link shows a simple menu example, including DDS:
http://publib.boulder.ibm.com/infoce...bam6/srfil.htm

--
Karl Hanson

walker.l2 wrote:
> I don't think you'll get anywhere with SDA because CL can't write to
> files.

?????????????

I have a number of CL programs that shouldn't be working, then.

Chris
--

More spefically what I am trying to do, is create a screen with
something like.

Enter value below
____________________

have the user type in the value and hit enter. that input becomes a
variable.

On Dec 6, 3:12 pm, "jerryeveretts" wrote:
> More spefically what I am trying to do, is create a screen with
> something like.
>
> Enter value below
> ____________________
>
> have the user type in the value and hit enter. that input becomes a
> variable.

No problem I done this in many CL's. You can trap for F key usage,
indicators send and receive values. It's CL so it's kinda clunky
compared to wrting in RPG but it works well.

that 1 guy

You might want to look at creating your own command. They can be from
extremely simple to extremely complex, but they do guarantee a good bit of
validation.

Here's a simple example:
*
* To compile:
*
* CRTCMD CMD(YOURLIB/DSPDTAQ) SRCFILE(YOURLIB/QCMDSRC)
* PGM(DSPDTAQDRG) VLDCKR(DSPDTAQDVC)
*
*================================================= ======================
CMD PROMPT('Display Data Queue Description')
PARM KWD(QUEUE) TYPE(QUAL) PROMPT('Data Queue')
QUAL: QUAL TYPE(*NAME) MIN(1)
QUAL TYPE(*NAME) DFT(*LIBL) SPCVAL((*LIBL) +
(*CURLIB)) PROMPT('Library')This comes from
an article here:
http://www.itjungle.com/mpo/mpo112102-story04.html

A more complex command/article can be found here:
http://www.itjungle.com/fhg/fhg112906.html

Sam

"jerryeveretts" wrote in message
news:1165421669.434388.241880@73g2000cwn.googlegro ups.com...
>I have written a few CL programs, and I have used 'sndusrmsg' to
> retreive information from the user which is passed to a variable. I
> would like to clean these programs up and create a screen to send to
> the user where they can input the information which will get passed to
> the program. I have used SDA to create menu's but have never created
> display screens or used them in CLP's. Is there a place to look or can
> anybody provide me with a basic overview?
>
> Jerry
>

"jerryeveretts" wrote in message
news:1165421669.434388.241880@73g2000cwn.googlegro ups.com...
>I have written a few CL programs, and I have used 'sndusrmsg' to
> retreive information from the user which is passed to a variable. I
> would like to clean these programs up and create a screen to send to
> the user where they can input the information which will get passed to
> the program. I have used SDA to create menu's but have never created
> display screens or used them in CLP's. Is there a place to look or can
> anybody provide me with a basic overview?
>
> Jerry
>
So why do you want to re-invent the wheel?

SNDUSRMSG seems like a perfectly good way prompt the user.

Alternatively, you should consider creating a command defintion

Tim M wrote:
> "jerryeveretts" wrote in message
> news:1165421669.434388.241880@73g2000cwn.googlegro ups.com...
> >I have written a few CL programs, and I have used 'sndusrmsg' to
> > retreive information from the user which is passed to a variable. I
> > would like to clean these programs up and create a screen to send to
> > the user where they can input the information which will get passed to
> > the program. I have used SDA to create menu's but have never created
> > display screens or used them in CLP's. Is there a place to look or can
> > anybody provide me with a basic overview?
> >
> > Jerry
> >
> So why do you want to re-invent the wheel?
>
> SNDUSRMSG seems like a perfectly good way prompt the user.
>
> Alternatively, you should consider creating a command defintion

My users frequently run multiple sessions, and get confused if there
message queue is allocated to another job. They run the program, but
the message is breaking on another session.

Perhaps what I should have said is that CL can't write a record (though
it can read them via RCVF).
>From my experience with CL, I thought you could only write records by
generating a whole file (QRYF type stuff), or by using RUNSQSTM to
insert records. The SNDRCVF command mentioned by others here was a new
one to me, but looks like it should meet the OP's requirements. Is
there another technique I've missed?

"jerryeveretts" wrote in message
news:1165462624.124679.148310@j44g2000cwa.googlegr oups.com...
>
> Tim M wrote:
>> "jerryeveretts" wrote in message
>> news:1165421669.434388.241880@73g2000cwn.googlegro ups.com...
>> >I have written a few CL programs, and I have used 'sndusrmsg' to
>> > retreive information from the user which is passed to a variable. I
>> > would like to clean these programs up and create a screen to send
>> > to
>> > the user where they can input the information which will get passed
>> > to
>> > the program. I have used SDA to create menu's but have never
>> > created
>> > display screens or used them in CLP's. Is there a place to look or
>> > can
>> > anybody provide me with a basic overview?
>> >
>> > Jerry
>> >
>> So why do you want to re-invent the wheel?
>>
>> SNDUSRMSG seems like a perfectly good way prompt the user.
>>
>> Alternatively, you should consider creating a command defintion
>
> My users frequently run multiple sessions, and get confused if there
> message queue is allocated to another job. They run the program, but
> the message is breaking on another session.
>

Don't use SNDUSRMSG to send inquiry messages to a message queue. Rather,
for interactive jobs send the inquiry message to the special value '*';
this indicates that the message will be presented to the interactive
user.

Worked perfect!
Thanks so much

jerryeveretts wrote:

> I have written a few CL programs, and I have used 'sndusrmsg' to
> retreive information from the user which is passed to a variable. I
> would like to clean these programs up and create a screen to send to
> the user where they can input the information which will get passed to
> the program. I have used SDA to create menu's but have never created
> display screens or used them in CLP's. Is there a place to look or can
> anybody provide me with a basic overview?

You've gotten enough answers to resolve your need, but I thought I'd
summarize to bring most things into a single post. You can never tell
when you might want to try something different in a more complex
situation. There was also some confusion in some posts.

1. The advice to use SNDUSRMSG TOMSGQ(*) or TOMSGQ(*EXT) seems to work
for you. This avoids sending messages to the user's individual message
queue and sends it to the job's external message queue instead. That
keeps the message inside the job that sends it. The message can request
the user to enter a reply. The reply can be validated by the CL program;
if necessary, the program can loop back to SNDUSRMSG again.

2. DSM APIs _can_ be used in ILE CL. However, unless you program at V5R4
or later, the pointer handling makes receiving replies difficult if not
impossible. Before V5R4, a HLL would have to be used to receive input.

3. UIM can be used even in OPM CL going back perhaps to version 2 of
OS/400. Someone mentioned 'overkill' and that's probably a good word.
Perhaps not as much overkill as DSM, but still more than needed.

One advantage of DSM and UIM is that it isn't necessary to declare the
display file. DSM can be used to create completely dynamic displays. UIM
uses its own display facility.

4. I saw 'command interface' mentioned a couple times. Defining commands
is an extremely useful feature of CL, but it might not be a particularly
user-friendly way to get user-input into your CL program. It's an
excellent way to control parameters into program calls, but this sounds
more like you want the user to interact while your program runs.

5. A simple display file can be designed in SDA. The file doesn't have
to be "simple", but you'd seldom need a complex one in CL and some
features such as subfiles can't be used. CL declares the compiled file
with the DCLF statement. Record formats are displayed with the SNDF
statement and read with the RCVF statement. A display format that is
intended for both output and input can be referenced with the SNDRCVF
statement. SNDRCVF is how CL would do what RPG does with EXFMT.

Until recently (V5R3) a CL program was limited to a single DCLF. That
made it difficult to receive records from a database file if you wanted
a display file in the same CL program. Now, up to five DCLFs can be in
one program (but there is still no direct method of output to a database
file, i.e., SNDF can only be used to output to a display file.)

There are a few other ways to achieve terminal input/output, but these
cover the generally useful and flexible ones.

Tom Liotta

http://zap.to/tl400