[comp.os.vms] FMS/TDMS vs SMG

sommar@enea.se (Erland Sommarskog) (02/29/88)

There was some discussion some days ago about whether one should
use FMS for a menu system or SMG. News flow here is a little slow,
so it haven't reached me until now, but I thought I should add my 
twopenny anyway.

I know very little of FMS, but I attended a course about its
cousin TDMS just the other week. I doubt that there is any im-
portant difference between them in this issue. (The major difference
is that FMS works with fields, where as TDMS works with entire
records at a time.)

Basically: If you want maximum freedoom, use SMG. (Or even more
freedoom, do all terminal I/O by direct QIO. Also SMG enfroces 
resreictions, I'd guess.) On the other hand: If you want to save 
time and work, use FMS or TDMS. Both of them are sure intended for 
menus, so if you if don't want something very special, they should 
do. And as far as I know they use SMG in the bottom, so the foriegn-
terminal problem doesn't count. This presumes of course that you want
to pay extra from them. SMG comes for free with VMS.

Now, it is not easy as that. Using a ready-made menu system, imposes
restrictions on your application, which you may find unacceptable.
They contain assumptions which you may strongly dislike. In TDMS
you use the TAB key to move to the next field, whereas the return key
completes the form. This was about to drive me crazy when I should
use the form editor during the course. Filled in a field, pressed
CR, and back much too early to next form.
  With the latest version of TDMS V1.7 you can at least save your
own users from this. It is possible to define CR as goto next field,
but you can't define it as: Goto to the next field, if no more fields,
complete the form. So you must define another key as complete the
form. My natural choice was Gold-CR. However, on the arrow keys
are allowed with Gold prefix in this context! (There are three
types of key definitions in TDMS, but only one applies here.)

Another situation where TDMS may get dropped is the following:
You may in TDMS define that a field must not be empty, only
numbers are allowed etc. So if the user tries to deviate, he will
get "input required", "numeric required" etc. Fine. Unless all
your menus are in Swedish...

As a whole, my impression from the course was that they have
some more development to do with TDMS.

-- 
Erland Sommarskog       
ENEA Data, Stockholm        
sommar@enea.UUCP           "Souvent pour s'amuser les hommes d'equipages
                            and it's like talking to a stranger" -- H&C.

cfchiesa@bsu-cs.UUCP (Christopher Chiesa) (03/11/88)

In article <2778@enea.se>, sommar@enea.se (Erland Sommarskog) writes:
> 
> I know very little of FMS, but I attended a course about its
> cousin TDMS just the other week. I doubt that there is any im-
> portant difference between them in this issue. (The major difference
> is that FMS works with fields, where as TDMS works with entire
> records at a time.)

I haven't had any direct experience with TDMS, per se, but FMS is the *ONLY*
screen- or form- or field-oriented user interface that allows the terminal 
operator to move back and forth between the various fields of a screen, letting
him modify and adjust til everything is "just right."  In my job I am required
to use a database application involving mostly data-entry; if I make a typo 
in a one-character, auto-tab field at the top of the screen, the ONLY alterna-
tives are to a) hit control-Y, aborting to DCL, and start over; b) enter the
record, complete with typos, into the database, then pull it up for UPDATE and
change whatever was wrong.  Even then, I can't go BACK to a previous entry and
correct it.  I wish like mad the programmer had used FMS!

> 
> Basically: If you want maximum freedoom, use SMG. (Or even more
> freedoom, do all terminal I/O by direct QIO. 

I tend to agree, although we use a lot of different terminals around here and
the "hard-coded escape sequence" is quite a problem...  SMG at least handles
that much for you.

> Now, it is not easy as that. Using a ready-made menu system, imposes
> restrictions on your application, which you may find unacceptable.
> They contain assumptions which you may strongly dislike. In TDMS
> you use the TAB key to move to the next field, whereas the return key
> completes the form. This was about to drive me crazy when I should
> use the form editor during the course. Filled in a field, pressed
> CR, and back much too early to next form.
>   With the latest version of TDMS V1.7 you can at least save your
> own users from this. It is possible to define CR as goto next field,
> but you can't define it as: Goto to the next field, if no more fields,
> complete the form. So you must define another key as complete the
> form. My natural choice was Gold-CR. However, on the arrow keys
> are allowed with Gold prefix in this context! (There are three
> types of key definitions in TDMS, but only one applies here.)

Aha!   In FMS you can assign *ANY* function, FMS-provided or user-written, to
ANY key or combination of keys, including just about every conceivable combi-
nation of GOLD keys, control keys, GOLD-control keys, you name it.  It's VERY
good.

> Another situation where TDMS may get dropped is the following:
> You may in TDMS define that a field must not be empty, only
> numbers are allowed etc. So if the user tries to deviate, he will
> get "input required", "numeric required" etc. Fine. Unless all
> your menus are in Swedish...

I don't kow what you mean by "...TDMS may get dropped," but for what it's 
worth, "you can do the same thing in FMS, too!"  And you can change the entire
layout of the FORMS without having to recompile the software that USES them.

> 
> As a whole, my impression from the course was that they have
> some more development to do with TDMS.

Alas, I feel the same way about FMS.  I'm thinking of doing some "hacking" on
its internals one of these months, if I get the time and motivation...

> 
> -- 
> Erland Sommarskog       
> ENEA Data, Stockholm        
> sommar@enea.UUCP           "Souvent pour s'amuser les hommes d'equipages
>                             and it's like talking to a stranger" -- H&C.

Chris Chiesa
Senior, CS Dept
Ball State University


-- 
<><><><><><><><><><><><><><><><><><><><><><><><><><><><> Chris Chiesa <><><><><>
<> {ihpn4|seismo}!{iuvax|pur-ee}!bsu-cs!cfchiesa                              <>
<> cfchiesa@bsu-cs.UUCP                                                       <>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

cfchiesa@bsu-cs.UUCP (Christopher Chiesa) (03/11/88)

In article <2325@bsu-cs.UUCP>, I wrote:  
> In article <2778@enea.se>, sommar@enea.se (Erland Sommarskog) writes:
> > 
         [ Much assorted bull-bleep deleted ]
> 
> I haven't had any direct experience with TDMS, per se, but FMS is the *ONLY*
> screen- or form- or field-oriented user interface that allows ... etc..

I meant to qualify that: it's the only (etc.)-oriented inferface I HAVE USED
that allows... etc....   I hope you read BOTH of these postings before flaming
the first!

Chris
-- 
<><><><><><><><><><><><><><><><><><><><><><><><><><><><> Chris Chiesa <><><><><>
<> {ihpn4|seismo}!{iuvax|pur-ee}!bsu-cs!cfchiesa                              <>
<> cfchiesa@bsu-cs.UUCP                                                       <>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

sommar@enea.se (Erland Sommarskog) (03/14/88)

Christopher Chiesa (cfchiesa@bsu-cs.UUCP) writes:
>I haven't had any direct experience with TDMS, per se, but FMS is the *ONLY*
>screen- or form- or field-oriented user interface that allows the terminal 
>operator to move back and forth between the various fields of a screen, letting
>him modify and adjust til everything is "just right."  In my job I am required

Christopher corrected this in another posting, to say that FMS is the only
he has used, that's a big difference. Anyway, TDMS does the same. And I
should be very surprised if this is not standard with products of this
kind that comes with database like Oracle et al, although I have no
experience of them. 

The program you talk of Christopher, is home-brewed I suppose?

( >> is me.)
>> Another situation where TDMS may get dropped is the following:
>> You may in TDMS define that a field must not be empty, only
>> numbers are allowed etc. So if the user tries to deviate, he will
>> get "input required", "numeric required" etc. Fine. Unless all
>> your menus are in Swedish...
>
>I don't kow what you mean by "...TDMS may get dropped," but for what it's 
>worth, "you can do the same thing in FMS, too!"  And you can change the entire
>layout of the FORMS without having to recompile the software that USES them.

What I meant by "get dropped" is that this is a "feature" which may make you
decide to not use TDMS. The reason is that the error message are hard-
coded in English, there is no way to change them. (Well, patching, but
that's absurd.) So if you want these tests *and* entirely an Swedish-
speaking system, you have to forget TDMS. (And I assume FMS?).

Changing the layout of the forms with affecting the program is also
possible with TDMS. However, you have to re-build the request library,
and that is about as heavy as a recompilation.
-- 
Erland Sommarskog       
ENEA Data, Stockholm        
sommar@enea.UUCP           "Si tu crois l'amour tabou...
                            Regarde bien, les yeux d'un fou!!!" -- Ange

SHAVA@ISIS.MIT.EDU (03/15/88)

From:	ISIS::SHAVA        14-MAR-1988 20:55
To:	IN%"bsu-cs!cfchiesa@iuvax.cs.indiana.edu",SHAVA       
Subj:	RE: Re: FMS/TDMS vs SMG

It is sad but true that DEC had a user-interface design language that could
run on VMS and could support REGIS and a couple other graphics standards, in
1983, which was developed by DEC Ed. Svcs., and was forbidden to:
	(A)  add hooks for the VMS call standard
	(B)  add hooks to read anything but non-index sequential files.

This was 100% politics--mostly because they didn't want a product out of
Educational Services taking market away from Engineering's FMS group.

They even sell it, in its current stunted and barely supported form as part
of the Interactive Video Information System development system.  The language
is called (imaginatively) DESIGN, and a graphics editor that goes with it
is called DRAW.  I would not recommend this product at this time for people
interested in user interface design, but simply offer this up as a history
lesson.

					Shava Nerad
					MIT VAX Resource Center

{disclaimer--this bitter missive has little to do with MIT, but is rooted in
the past when I used to be an outside consultant of Ed Svcs.  I like academia
better...}