Screen descriptions in HP Cobol on VMS

Hi,

I was used to describe screen layouts using the SCREEN SECTION or doing
a DISPLAY ... AT ... in a cobol program. In another newsgroup, someone
mentioned that there were much better ways to design and handle a
screen for dialogues.

On AS/400 et al., I'm used to define screens as (DDS) files and handle
them as TRANSACTIONAL files from within cobol. But this is a AS/400 or
Mainframe way, isn't it?

So I'm curious how you define and handle full screen i/o in Cobol on
VMS?

Volker

I am NOT a VMS programmer, but DEC was the "father" of the FIMS (Forms Inter
face
Management System) definition - that was adopted by CODASYL and *almost* bec
ame
a COBOL Standard.  There is a LONG PDF document about it at:


[url]http://h71000.www7.hp.com/doc/73final/documentation/PDF/decforms_prog_ref_gd.PDF[/
url]

If you are developing for VMS, I would check your reference material for "FI
MS".

--
Bill Klein
wmklein <at> ix.netcom.com
"Volker Englisch" <eh97@despammed.com> wrote in message
news:d6a0l3$2oq$1@rrz.allgaeu.org...
> Hi,
>
> I was used to describe screen layouts using the SCREEN SECTION or doing
> a DISPLAY ... AT ... in a cobol program. In another newsgroup, someone
> mentioned that there were much better ways to design and handle a
> screen for dialogues.
>
> On AS/400 et al., I'm used to define screens as (DDS) files and handle
> them as TRANSACTIONAL files from within cobol. But this is a AS/400 or
> Mainframe way, isn't it?
>
> So I'm curious how you define and handle full screen i/o in Cobol on
> VMS?
>
> Volker

Hi,

I am of the opinion that DECforms was one of the key strategic f*ck-ups
that, while not actually instigating, certainly hastened the recession of
VMS
as a development platform (and DEC as a company). Furthermore, I suspect
that IBM, and others on the FIMS consortium, merely continued to fund the
project so they could enjoy the spectacle of Digital disappearing up its own
DECforms rathole! That said, if you'd like to learn a complete new language
(IFDL) and run it without a debugger (anyone who's worked with DECforms
will appreciate the useful trace output "You are on the right side of the
equation") or a useful Panel Editor then, by all means, go DECforms.

Getting back to your original queries both here and in COV, what is the
actual problem?

1) Your Screen-Section strategy is a perfectly acceptable way to go. What do
you think is wrong with it?

2) Was it you that was questioning the refresh time? If so, seeing as how
Don Braffit has confirmed that DEC COBOL uses the SMG$ utility, you may want
to ask him why he doesn't batch the screen output (if in fact he doesn't).
Was it also you with the VT220 CRT? Have you tried with any reasonable VT
terminal emulator and telnet? Is it still slow?

3) If you really pine for some sort of IBM 3270 emulation block i/o thingy,
then WHY? (Having said that I recall that FMS had some such emulation
functionality.) If you are using ACMS (a transaction monitor analogous to
CICS) then I can see the requirement. DEC decided to create TDMS for this
purpose. It's much like a limited FMS but does have the asynchronous record
i/o capability where you have one process (the CP) controlling many CRTs.
TDMS has just been ported to Alpha so I assume it will also be making it to
Itanium, but I guess you should really go DECforms if you need this
functionality.

4) Are you limited to a dumb terminal/character-cell interface? If not, then
why don't you front end your application with VB  (or whatever) and have VMS
and COBOL serve the back-end? Then we can have another lengthy discussion
about middleware :-)

So Volker, please restate your requirements/problems/restrictions and
someone
may be able to offer some specific advice. For the following discussion I'll
assume you're restricted to dumb terminals and you've landed this VMS and
COBOL box and you want to know what tool(s) should you use for the
user-interface: -

"Options that I know of for VMS character-cell user-interface development
with COBOL"

a) COBOL's own DISPLAY and ACCEPT verbs. (With or without the
SCREEN-SECTION)

Nothing wrong with it! Can provide a perfectly adequate
"missionary-position" user-interface. Easy to code.

b) The SMG$ (Screen Manager) Run-Time Library.

At the dollar ($) prompt, type HELP RTL SMG$ and you will see all of the
routines that you can call to paint your screens. There is also complete
documentation somewhere on the web. Your interest may lie with the buffering
routines (have a look at SMG$*_DISPLAY_UPDATE routines.)

SMG $ is VERY powerful and the best thing is it comes free with the
operating system and supports quite a few CRT types. It is however quite
complex and it will take a while for you to get your head around if you
haven't done it before.

c) The $QIO System Service to the Terminal Driver and io$_readverify

I don't recommend that you go this way and only include it for completeness.
This is a very low-level interface. (You have to code your own escape
sequences to change video-attributes etc). But if you are interested, look
at the Terminal Driver section of the I/O Users Reference manual. (I think?)

d) FMS Forms Management System

This is the BEST character-cell forms product EVER invented! (There is also
an FMS to Motif converter available) There is a fantastic full-function
Panel-Editor and your forms are stored in separate files (or a library) and
can be compiled and linked in with your COBOL object code for performance.
See docs on the web.

The downside is it costs money and HP make you pay through the nose even
though they flatly refuse to enhance this product :-(

e) TDMS (Some acronym :-)

Like FMS but record-oriented and has asynchronous capabilities. I'd only use
it if I was using ACMS.  Costs money. HP have only just ported to ALPHA.
(Probably about the same time they announce the death of the Alpha chip?)

f) DECforms. Piece o' shit. The drug-inspired act of a mad man.

If you're using ACMS then you probably need this. (But then there's the SI
interface but I digress) Costs money.

The last I heard (probably about 5 years ago) FMS had sold 750,000 licenses,
TDMS had sold 150,000 and DECforms 100,000. The Forms Development Team at
DEC took all of the lovely revenue from FMS and P*ssed it up against the
DECforms folly of a wall.

Regards Richard Maher

PS. The above may not be a completely objective analysis and may be tinted
with my own bias and prejudices :-)

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:Sn6ie.181063$QY2.46272@fe01.news.easynews.com...
> I am NOT a VMS programmer, but DEC was the "father" of the FIMS (Forms
Interface
> Management System) definition - that was adopted by CODASYL and *almost*
became
> a COBOL Standard.  There is a LONG PDF document about it at:
>
>
>
http://h71000.www7.hp.com/doc/73fin...prog_ref_gd.PDF
>
> If you are developing for VMS, I would check your reference material for
"FIMS".
>
> --
> Bill Klein
>  wmklein <at> ix.netcom.com
> "Volker Englisch" <eh97@despammed.com> wrote in message
> news:d6a0l3$2oq$1@rrz.allgaeu.org... 
>
>

"Richard Maher" <maher_rj@hotspamnotmail.com> wrote in message
news:d6hq2t$51$1@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com...
> Hi,
>
> I am of the opinion that DECforms was one of the key strategic f*ck-ups
> that, while not actually instigating, certainly hastened the recession of
> VMS
:
<snip long rant>
:

So Richard... please tell us how you really feel about all this :-) :-).

Actually IMHO Richard hits all the nails, including the 'nails on the
coffin' right smack on the head.
I largerly concur: SCREEN SECTION has its place (as do simple DISPLAYS). FMS
is the best, SMG when needed,...
Thanks for taking the time to pen it all down, and (re-)asking the right
questions.

fwiw,
Hein.

Richard Maher wrote:
> Hi,
>
> I am of the opinion that DECforms was one of the key strategic
> f*ck-ups that, while not actually instigating, certainly hastened the
> recession of VMS
> as a development platform (and DEC as a company). Furthermore, I
> suspect that IBM, and others on the FIMS consortium, merely continued
> to fund the project so they could enjoy the spectacle of Digital
> disappearing up its own DECforms rathole! That said, if you'd like to
> learn a complete new language (IFDL) and run it without a debugger
> (anyone who's worked with DECforms will appreciate the useful trace
> output "You are on the right side of the equation") or a useful Panel
> Editor then, by all means, go DECforms.
>
> Getting back to your original queries both here and in COV, what is
> the actual problem?
>
> 1) Your Screen-Section strategy is a perfectly acceptable way to go.
> What do you think is wrong with it?
>
> 2) Was it you that was questioning the refresh time? If so, seeing as
> how Don Braffit has confirmed that DEC COBOL uses the SMG$ utility,
> you may want to ask him why he doesn't batch the screen output (if in
> fact he doesn't). Was it also you with the VT220 CRT? Have you tried
> with any reasonable VT terminal emulator and telnet? Is it still slow?
>
> 3) If you really pine for some sort of IBM 3270 emulation block i/o
> thingy, then WHY? (Having said that I recall that FMS had some such
> emulation functionality.) If you are using ACMS (a transaction
> monitor analogous to CICS) then I can see the requirement. DEC
> decided to create TDMS for this purpose. It's much like a limited FMS
> but does have the asynchronous record i/o capability where you have
> one process (the CP) controlling many CRTs. TDMS has just been ported
> to Alpha so I assume it will also be making it to Itanium, but I
> guess you should really go DECforms if you need this functionality.
>
> 4) Are you limited to a dumb terminal/character-cell interface? If
> not, then why don't you front end your application with VB  (or
> whatever) and have VMS and COBOL serve the back-end? Then we can have
> another lengthy discussion about middleware :-)
>
> So Volker, please restate your requirements/problems/restrictions and
> someone
> may be able to offer some specific advice. For the following
> discussion I'll assume you're restricted to dumb terminals and you've
> landed this VMS and COBOL box and you want to know what tool(s)
> should you use for the user-interface: -
>
> "Options that I know of for VMS character-cell user-interface
> development with COBOL"
>
> a) COBOL's own DISPLAY and ACCEPT verbs. (With or without the
> SCREEN-SECTION)
>
> Nothing wrong with it! Can provide a perfectly adequate
> "missionary-position" user-interface. Easy to code.
>
> b) The SMG$ (Screen Manager) Run-Time Library.
>
> At the dollar ($) prompt, type HELP RTL SMG$ and you will see all of
> the routines that you can call to paint your screens. There is also
> complete documentation somewhere on the web. Your interest may lie
> with the buffering routines (have a look at SMG$*_DISPLAY_UPDATE
> routines.)
>
> SMG $ is VERY powerful and the best thing is it comes free with the
> operating system and supports quite a few CRT types. It is however
> quite complex and it will take a while for you to get your head
> around if you haven't done it before.
>
> c) The $QIO System Service to the Terminal Driver and io$_readverify
>
> I don't recommend that you go this way and only include it for
> completeness. This is a very low-level interface. (You have to code
> your own escape sequences to change video-attributes etc). But if you
> are interested, look at the Terminal Driver section of the I/O Users
> Reference manual. (I think?)
>
> d) FMS Forms Management System
>
> This is the BEST character-cell forms product EVER invented! (There
> is also an FMS to Motif converter available) There is a fantastic
> full-function Panel-Editor and your forms are stored in separate
> files (or a library) and can be compiled and linked in with your
> COBOL object code for performance. See docs on the web.
>
> The downside is it costs money and HP make you pay through the nose
> even though they flatly refuse to enhance this product :-(
>
> e) TDMS (Some acronym :-)
>
> Like FMS but record-oriented and has asynchronous capabilities. I'd
> only use it if I was using ACMS.  Costs money. HP have only just
> ported to ALPHA. (Probably about the same time they announce the
> death of the Alpha chip?)
>
> f) DECforms. Piece o' shit. The drug-inspired act of a mad man.
>
> If you're using ACMS then you probably need this. (But then there's
> the SI interface but I digress) Costs money.
>
> The last I heard (probably about 5 years ago) FMS had sold 750,000
> licenses, TDMS had sold 150,000 and DECforms 100,000. The Forms
> Development Team at DEC took all of the lovely revenue from FMS and
> P*ssed it up against the DECforms folly of a wall.
>
> Regards Richard Maher
>
> PS. The above may not be a completely objective analysis and may be
> tinted with my own bias and prejudices :-)
>
Richard,

As soon as I started reading about DECForms panel editor and IFDL my brain
short circuited and I was transported through space and time into another
zone.  Soon after fear and loathing took over and my dog had to give me
mouth to mouth to bring me out of it.  Man, that DECForms sh*t can really
screw with your mind.

Dr. Dweeb - still trembling at the memories

ps: What is "fims" mean in danish ?

Hi,

> Getting back to your original queries both here and in COV, what is the
> actual problem?
>
> 1) Your Screen-Section strategy is a perfectly acceptable way to go.
> What do you think is wrong with it?

Well, some guy told here that the screen is built up very slow when a
COBOL program is run on a VT220 terminal. For I have the same problem
here, I just asked if there was a better way to code screen layouts.

> 2) Was it you that was questioning the refresh time?

No, it wasn't me.

> Was it also you with the VT220 CRT? Have you tried with any
> reasonable VT terminal emulator and telnet? Is it still slow?

I tried with PUTTY over Ethernet, there is no visible delay. I also
connected the VT220 directly to a unix machine and did a telnet to the
VMS box. Still slow like connected directly to the VMS.

Maybe I had to mention here that tools like FLIST on VMS display their
screen with no delay, even at the serial VT220 CRT.

> 4) Are you limited to a dumb terminal/character-cell interface?

Yes, I am.

> If not, then why don't you front end your application with VB (or
> whatever) and have VMS and COBOL serve the back-end?

Scream :-) I don't love graphical interfaces really :-)

> Then we can have another lengthy discussion about middleware :-)

:-)

> d) FMS Forms Management System
>
> This is the BEST character-cell forms product EVER invented! (There
> is also an FMS to Motif converter available) There is a fantastic
> full-function Panel-Editor and your forms are stored in separate
> files (or a library) and can be compiled and linked in with your
> COBOL object code for performance. See docs on the web.

Is there any tutorial on the web? I didn't find one yet.

However, thanks a lot for your patience and your detailled explanation.

V.

Volker Englisch wrote:
> Hi,
>
> 
>
>
> Well, some guy told here that the screen is built up very slow when a
> COBOL program is run on a VT220 terminal. For I have the same problem
> here, I just asked if there was a better way to code screen layouts.

First you have to know what the problem is.

I've mentioned it before, maybe it was too simple to try.

Set the terminal's serial line speed to 'real slow', 110 or 300 baud,
and then watch the screen display.  You'll be able to see everything
that happens.  Perhaps some unnecessary and bandwidth clogging stuff is
there.

When using a PC or whatever with a terminal emulator, you're using
ethernet, much higher speed, and that can mask plenty of things.

Dave

--
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      Fax: 724-529-0596
DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com
170 Grimplin Road
Vanderbilt, PA  15486

Hein,

No worries. Glad I'm not the only one who feels that way.

Cheers Richard Maher

"Hein" <hein.nomail@hp.nomail> wrote in message
news:428be2e2$1@usenet01.boi.hp.com...
>
> "Richard Maher" <maher_rj@hotspamnotmail.com> wrote in message
> news:d6hq2t$51$1@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com... 
of 
> :
> <snip long rant>
> :
>
> So Richard... please tell us how you really feel about all this :-) :-).
>
> Actually IMHO Richard hits all the nails, including the 'nails on the
> coffin' right smack on the head.
> I largerly concur: SCREEN SECTION has its place (as do simple DISPLAYS).
FMS
> is the best, SMG when needed,...
> Thanks for taking the time to pen it all down, and (re-)asking the right
> questions.
>
> fwiw,
> Hein.
>
>

Hi,

>
> ps: What is "fims" mean in danish ?
>

No idea. Could it be "My Lego is broken" :-)

Cheers Richard

"Dr. Dweeb" <NOSPAM_5msg0h202@sneakemail.com> wrote in message
news:428cb594$0$78285$157c6196@dreader1.cybercity.dk...
> Richard Maher wrote: 
> Richard,
>
> As soon as I started reading about DECForms panel editor and IFDL my brain
> short circuited and I was transported through space and time into another
> zone.  Soon after fear and loathing took over and my dog had to give me
> mouth to mouth to bring me out of it.  Man, that DECForms sh*t can really
> screw with your mind.
>
> Dr. Dweeb - still trembling at the memories
>
> ps: What is "fims" mean in danish ?
>
>

Hi,

You're on your own with the VT220, (Didn't that have a graphics capability?
Could draw squiggly lines and circles?)

For an FMS tutorial you should install it and look at
fms$examples:sampcob.cob. If you run the example it will show you most of
the main features. Be aware that YES FMS also paints the screen one line at
a time and this will be visible at low baud rates. These days it's usually
so quick that the naked eye can't pick it up, but it is there. If you want
control over this then use SMG$.

Cheers Richard Maher

"Volker Englisch" <eh97@despammed.com> wrote in message
news:d6ifq9$c26$1@rrz.allgaeu.org...
> Hi,
> 
>
> Well, some guy told here that the screen is built up very slow when a
> COBOL program is run on a VT220 terminal. For I have the same problem
> here, I just asked if there was a better way to code screen layouts.
> 
>
> No, it wasn't me.
> 
>
> I tried with PUTTY over Ethernet, there is no visible delay. I also
> connected the VT220 directly to a unix machine and did a telnet to the
> VMS box. Still slow like connected directly to the VMS.
>
> Maybe I had to mention here that tools like FLIST on VMS display their
> screen with no delay, even at the serial VT220 CRT.
> 
>
> Yes, I am.
> 
>
> Scream :-) I don't love graphical interfaces really :-)
> 
>
> :-)
> 
>
> Is there any tutorial on the web? I didn't find one yet.
>
> However, thanks a lot for your patience and your detailled explanation.
>
> V.