RE: API -> Commands

[jpcarr@xxxxxxxxxxxx]

In some cases the "End Consumers" Are not programmers.   Operations Staffs
I have found are,  by and large, not versed in programming.   Their
"Language" is CL.  Commands are their vehicle.   They don't,  need/want to
know how to interface with service programs in most cases.

That is the case for commands.  They have default values, special values
and conditional values that make that vehicle(commands vs API's)  very easy
to be used by less than erudite programmers.

Just an opinion/observation.  Not an opening for a series of counter
arguments.

John

>Okay, but you could do the same thing with service programs instead of
>commands.  That would run faster, and allow you to use some of these
>newfangled constructs that RPG has and CL doesn't.
>things like loops, arrays, and native file i/o...
>Scott K.

On Wed, 30 May 2001, Jim W wrote:

>> One reason is to allow the use of commands to construct custom
interfaces
>> without having to write entire programs.  We have a software product
that
>> has about 150 CL commands that can be used to create custom
communication
>> interfaces between the 400 and "some other box" (ASCII).  Our clients
can
>> arrange the commands fairly easily in a CL program without having to
know
>> anything about the programs that are working behind the scenes.  Some of
>> those programs are RPG, some CLP, ASM and C, but all they see are the
>> commands and CL.  For this type of application you have many different
>> functions and many programs to accomplish them.  You have to have
something
>> to control the whole process, and on the 400 that's CL.
>>
>> Jim Whalen
>> DCS Software and Services
>

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---