Re: DDS Support

Hi Jon,

My assumption in this case would be that commands are not fast because of
all the parameter checking that's being done, and that this would be done by
SEU and the compiler. As far as speed of coding, a simple command for a
simple interface doesn't take much longer to code than the procedure
interface + prototype, the prompt text and keywords help make it self
documenting, and the ability to prompt in SEU means I don't have to look at
the service program or procedure or prototype source to determine what the
parameters are, what sequence they're supposed to be in, etc.

I don't know if you've noticed, but having to use someone else's service
programs requires either good documentation on the part of the service
program programmer, or a peek at the source code to see if it does what you
want done. Just because a service program has a procedure named "GetAcctRec"
doesn't mean it does what I want. Customer account? Patient account? General
ledger account? What else is it doing besides getting a record? Does it lock
it? Does it read records from related files? If there's no documentation, I
have to look at the source. I have to know where to find the /COPY source
(assuming the shop has a standard place for it), what it's named, etc. If
there are parameters that tell it to lock or not lock the record, what
values does it expect? L=lock/U=unlock, L=lock/N=no lock, 0=no lock/1=lock,
Y=lock/N=no lock?  I could go on, but I'm sure you get my drift. With a
command interface to the procedure, a lot of these questions are answered
simply by prompting. Of course I still have to figure out what the
"GetAcctRec" procedure actually does.

Which brings up the point that with the proliferation of procedures, it is
actually becoming more difficult to look at a program and determine what it
does until you have become familiar with the procedures in use.  I think
someone else on the list mentioned something along those lines in reference
to defining your own opcodes, that by being able to extend the language it
becomes less standard. I agree with that and note that it's already
happening with procedures. But don't make me give them up<G>!

Regards,

Peter Dow
Dow Software Services, Inc.
909 425-0194 voice
909 425-0196 fax


From: <Jon.Paris@hal.it>
>
>  >> Then we could make commands for each procedure instead of PR/PI D
> specs.
>
> Hmmm - that would be a little self defaulting methinks.  Subprocedures are
> supposed to provide an efficient _fast_ call mechanism.  Commands have
many
> virtues but "fast" is not one of them.  Besides - it would take longer to
> code the command than it does to code the PI (the PR is only a copy) and
> you use them via a /COPY anyway - what's the big deal?
>
> +---
> | 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
> +---


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
+---
| 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
+---