Page 1 of 1
SMG$ routines ?
Posted: Sun Jan 29, 2023 7:02 am
by fim
When developing programs in COBOL, should I bet on "OpenVMS RTL Screen Management (SMG$)" or
should I solve screen processing in another way?
/Fim W.
Re: SMG$ routines ?
Posted: Sun Jan 29, 2023 11:03 am
by sms
Code: Select all
> When developing programs in COBOL, should I bet on "OpenVMS RTL Screen
> Management (SMG$)" or should I solve screen processing in another way?
As usual, it depends. Will your programs need to run on some OS
other than VMS? Define "screen".
Some decades ago, I worked on a (FORTRAN) program which used DEC
line-drawing characters to create an oscilloscope-like display of the
results of a digital logic simulator on a VT100 (or compatible)
terminal/emulator. That program ran on VMS and a variety of UNIX
operating systems (where SMG was not available), so it did its own
screen management.
If your programs will be confined to VMS, then SMG might be more
attractive.
Re: SMG$ routines ?
Posted: Sun Jan 29, 2023 1:57 pm
by arne_v
fim wrote: ↑Sun Jan 29, 2023 7:02 am
When developing programs in COBOL, should I bet on "OpenVMS RTL Screen Management (SMG$)" or
should I solve screen processing in another way?
Most obvious for Cobol would be to just use ACCEPT and DISPLAY that can be used to create forms. See reference manual "Using ACCEPT and DISPLAY Statements for Input/Output and Video Forms".
Obviously SMG$ is also a possibility. I don't like SMG$ API, but maybe you will like it. I am just not sure about how natural its use will be in Cobol. VMS Cobol supports the VMS calling standard, but the code tend to be a bit verbose even for Cobol.
Re: SMG$ routines ?
Posted: Sun Jan 29, 2023 11:01 pm
by hein
Ask yourself where you are coming from, and where you need to go with this development.
Maybe there should be NO screen management on OpenVMS, just an API / RPC to handle request from an other (windows?) environment.
Starting from scratch?
If you are you adding to, or modifying, an existing environment then Stick to whatever is being used!
SMG$ is pretty verbose, requiring a good bit of code to build a 'form'.
Maybe a forms product is more appropriate?
Are you developing a 1-off program or a suite of programs to build up an entire solution?
For a somewhat big solution you might want to look at FMS and and for a really big one look at DECforms.
But those need license you may not have and cannot justify.
For a small standalone program, maybe just a few cursor positioning escape sequences is enough.
For sure, as pointed out, Cobol's build in extended Display/Accept should be considered.
What platform (Alpha, Integrety) today? Need to be on X86 tomorrow?
Tell us a bit more and we may be able to advise better.
Hein.
Re: SMG$ routines ?
Posted: Mon Jan 30, 2023 6:42 am
by fim
Thanks for the advice.
I have a software package for a small ERP system written in COBOL for DOS/Windows.
It includes about 300 screenshots and includes roughly 500,000 lines of code.
Development has been ongoing since 1984.
Now I thought to convert it to COBOL on OpenVms.
Considering what you have presented, I will bet on DISPLAY for output, same syntax in both COBOL versions. When it comes to input via ACCEPT, both syntax and functionality are different between the two COBOL versions. There I will build a subroutine with SMG Functions.
Found one in my stash, built in 1986, I'm going to build on it.
/Fim W.
Re: SMG$ routines ?
Posted: Mon Jan 30, 2023 6:57 am
by jonesd
SMG provides the abstractions to partion the screen and do basic/input output, building a screen oriented interface with it is a fair amount of work. I've only done 2 programs using screen orientation and one was just a Sudoku solver program.
SMG$READ_COMPOSED_LINE(), on the other hand, is very convenient for command-line driven programs as it provides a recall buffer.