Does VMS curses support colour ?

[Simon Clubley]

It looks like the VMS version of curses is so old that it doesn't
even support colour unless there's a non-standard header somewhere
that I have not found yet. Can anyone confirm the lack of colour
support ?

CC and VMS version:

HP C V7.3-009 on OpenVMS Alpha V8.4

Q&D test program (which works just fine on Linux):

/*
* Test curses colour map
*
* Compile with:
*
* gcc -Wall -o colour_map colour_map.c -lcurses
*/

#include <stdio.h>
#include <stdlib.h>
#include <curses.h>

int main(int argc, char *argv[])
{
int x = 5, i, j, pair = 1;

initscr();
if(has_colors() == FALSE)
{
endwin();
printf("Colours not supported for this terminal type\n");
exit(4);
}
start_color();
mvwprintw(stdscr, 1, 1, "COLORS = %u, COLOR_PAIRS = %u\n", COLORS, COLOR_PAIRS);

if((COLOR_PAIRS < 64) || (COLORS != 8))
{
endwin();
printf("Not enough colour pairs\n");
exit(4);
}

for(i=0; i<8; i++)
{
x = 5;
for(j=0; j<8; j++)
{
if(i != j)
{
init_pair(pair, j /*fg*/, i /*bg*/);

attron(COLOR_PAIR(pair));
mvwprintw(stdscr, i + 5, x, "%s", "text ");
refresh();
attroff(COLOR_PAIR(pair));
pair++;
}
x = x + 5;
}
}
getch();
endwin();
return 0;
}

Output:

$ cc colour_map.c

if(has_colors() == FALSE)
...........^
%CC-I-IMPLICITFUNC, In this statement, the identifier "has_colors" is implicitly declared as a function.
at line number 18 in file DKA100:[SIMON]COLOUR_MAP.C;1

start_color();
........^
%CC-I-IMPLICITFUNC, In this statement, the identifier "start_color" is implicitly declared as a function.
at line number 24 in file DKA100:[SIMON]COLOUR_MAP.C;1

mvwprintw(stdscr, 1, 1, "COLORS = %u, COLOR_PAIRS = %u\n", COLORS, COLOR
_PAIRS);
........^
%CC-I-IMPLICITFUNC, In this statement, the identifier "mvwprintw" is implicitly declared as a function.
at line number 25 in file DKA100:[SIMON]COLOUR_MAP.C;1

mvwprintw(stdscr, 1, 1, "COLORS = %u, COLOR_PAIRS = %u\n", COLORS, COLOR
_PAIRS);
...................................................................^
%CC-E-UNDECLARED, In this statement, "COLORS" is not declared.
at line number 25 in file DKA100:[SIMON]COLOUR_MAP.C;1

mvwprintw(stdscr, 1, 1, "COLORS = %u, COLOR_PAIRS = %u\n", COLORS, COLOR
_PAIRS);
...........................................................................^
%CC-E-UNDECLARED, In this statement, "COLOR_PAIRS" is not declared.
at line number 25 in file DKA100:[SIMON]COLOUR_MAP.C;1

init_pair(pair, j /*fg*/, i /*bg*/);
................................^
%CC-I-IMPLICITFUNC, In this statement, the identifier "init_pair" is implicitly declared as a function.
at line number 40 in file DKA100:[SIMON]COLOUR_MAP.C;1

attron(COLOR_PAIR(pair));
................................^
%CC-I-IMPLICITFUNC, In this statement, the identifier "attron" is implicitly declared as a function.
at line number 42 in file DKA100:[SIMON]COLOUR_MAP.C;1

[snip]

Thanks,

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Steven Schweda]

> [...] Can anyone confirm the lack of colour support ?

Seems pretty obvious.

ALP $ search decc_include:*.h has_colors, initscr

******************************
SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]CURSES.H;11

__WINDOW_ptr32 initscr (void);
#define initscr(_p1) decc$bsd_initscr(_p1)
__WINDOW_ptr32 initscr (void);

[Simon Clubley]

Thank you Steven.

I'd already found the lack of references in curses.h but I was hoping
against hope there was some non-standard header or something else
around which I had not yet found.

For goodness sake, is there _anything_ in VMS which is at least
half-way up to date ? :-(

[Jan-Erik Soderholm]

Den 2017-06-22 kl. 09:11, skrev Simon Clubley:
> On 2017-06-21, Steven Schweda <sms.an...@gmail.com> wrote:
>>> [...] Can anyone confirm the lack of colour support ?
>>
>> Seems pretty obvious.
>>
>> ALP $ search decc_include:*.h has_colors, initscr
>>
>> ******************************
>> SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]CURSES.H;11
>>
>> __WINDOW_ptr32 initscr (void);
>> #define initscr(_p1) decc$bsd_initscr(_p1)
>> __WINDOW_ptr32 initscr (void);
>
> Thank you Steven.
>
> I'd already found the lack of references in curses.h but I was hoping
> against hope there was some non-standard header or something else
> around which I had not yet found.
>
> For goodness sake, is there _anything_ in VMS which is at least
> half-way up to date ? :-(
>
> Thanks,
>
> Simon.
>

So, in what environment, and using what equipment, is that
color support of any practical use? Does the missed support
create the ANSI escape codes for color handling? So it is
used for hardware VT-terminals with color support or on
emulators having support for those ESC codes?

[Craig A. Berry]

On 6/22/17 2:11 AM, Simon Clubley wrote:

> For goodness sake, is there _anything_ in VMS which is at least
> half-way up to date ? :-(

Bill Pedersen was working on a new port of ncurses but I'm
not sure how far it got:

<https://sourceforge.net/p/vms-ports/ncurses/ci/default/tree/>

[Steven Schweda]

> For goodness sake, is there _anything_ in VMS which is at
> least half-way up to date ? :-(

Perhaps some things demanded by paying customers.

> [...] Does the missed support create the ANSI escape codes
> for color handling? [...]

Knowing nothing, I'd guess that the termcap/terminfo stuff
is supposed to handle such details (if you have termcap
and/or terminfo on your system).

[Jan-Erik Soderholm]

OK. My point was if there is anything currently having an issue
on VMS becuse of this lacking color support i C? Who needs it
and why is it needed?

[Simon Clubley]

On 2017-06-22, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>
> So, in what environment, and using what equipment, is that
> color support of any practical use?

In every decent terminal emulator created or modified in the
past 15-20 years.

Are you still using monochrome terminal environments only ?
Colour within a terminal environment greatly enhances the readability
of the information you are displaying. It's such an enhancement over
monochrome text displays that I consider it essential to any prototype
HELP replacement (if I get motivated enough to prototype some ideas
of mine).

In case you are not familiar with colour in a terminal environment
take a look at the following:

https://en.wikipedia.org/wiki/File:Slrn.png

Now imagine VMS help if it were similarly enhanced.

Unfortunately all my research so far has reminded me just how much
code you have to write if you want to try and do something like
this on VMS and then create executables which anyone can run.

I'm (potentially) interested in prototyping something in the future
which anyone can try out, but not interested enough to write and
debug 5 zillion lines of low level boilerplate code.

> Does the missed support
> create the ANSI escape codes for color handling?

Yes, but it's more than that because it fully integrates colour support
into the curses environment. I don't like curses as such but I've been
looking at alternatives to SMG$ and that was the only possibility shipped
with VMS or a layered product which I have found so far.

> So it is
> used for hardware VT-terminals with color support or on
> emulators having support for those ESC codes?
>

Anything which supports colours.

[Jan-Erik Soderholm]

Anything that still is "a terminal". Not much new development
with VT-type screens as the user interface, I guess. But thanks
for clearifying that anyway. Cannot be even close to the top
of the VSI priority list.




>
> Simon.
>

[Scott Dorsey]

A lot of Unix software uses the color support, most notably things like vim
and some of the data entry stuff. A lot of installers use it now too. I
do not think that it is essential for anything, but it certainly makes many
things easier and so I would call those issues. Not serious ones, but issues.

That said, implementing the seven short functions that are required to
manipulate colors should be an hour or so worth of work for someone familiar
with curses. It's not like porting java.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[John E. Malmberg]

The GNV Coreutils and Bash, and other projects provides code to do a
mostly read-only termios emulation on VMS. I have mostly only
implemented what the projects have needed so far.

https://sourceforge.net/p/gnv/bash_vms/ci/V4.2/tree/vms_source/bash/report_termcap.c

https://sourceforge.net/p/gnv/bash_vms/ci/V4.2/tree/vms_source/bash/vms_term.c

Note that some linux termcap entries for VT series terminals do not have
any documentation for what they are for that I could find.

Regards,
-John
wb8...@qsl.net_work

[hb]

On 06/22/2017 03:09 PM, Simon Clubley wrote:
> In case you are not familiar with colour in a terminal environment
> take a look at the following:
>
> https://en.wikipedia.org/wiki/File:Slrn.png

Which is only an example. The wiki entry says Slrn was developed for
VMS. S-lang is available for VMS, as well as jed. There are various jed
modes for especially VMS, (DCL, MMS/MMK, ...) using colours for syntax
highlighting.

[Stephen Hoffman]

On 2017-06-22 13:09:08 +0000, Simon Clubley said:

> On 2017-06-22, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>>
>> So, in what environment, and using what equipment, is that color
>> support of any practical use?
>
> In every decent terminal emulator created or modified in the past 15-20 years.

Ayup. Color support is available in the OpenVMS terminal emulator
DECterm, and that particularly terminal emulator been around for a very
long time.

> Are you still using monochrome terminal environments only ?

In a legacy-software manufacturing environment still running
AlphaServer DS20 servers and Rdb, monochrome terminal displays are not
particularly surprising. If this parallels what is common in many
manufacturing organizations, it'll continue to be used and largely
unmodified, until the manufacturing line itself is replaced. When the
manufacturing line is replaced, either the application code will be
ported and updated to the newer hardware, or it'll be replaced with a
different application. In short, a number of manufacturing and
process-control environments are still running monochrome UIs and
various OpenVMS environments — manufacturing, as well as other areas —
are still running real VT terminals and DECserver LAT widgets and
hardware from way back then. Stuff that nobody'd pick or choose or
use now, but it works for them.

> Colour within a terminal environment greatly enhances the readability
> of the information you are displaying. It's such an enhancement over
> monochrome text displays that I consider it essential to any prototype
> HELP replacement (if I get motivated enough to prototype some ideas of
> mine).

Ayup. Source code editing with syntax highlighting, or any number of
other UI-related tasks. Yes, this syntax highlighting is certainly
not for everybody, but many of us have become quite fond of it.

There are also implications here around accessibility, as even folks
that can see can't necessarily see colors.

> Now imagine VMS help if it were similarly enhanced.

Rather than imagining, just go use a system that does support . The
local production servers have red command-line prompts, for instance.

PS1="\[\e[1;31m\]\u@\H $\[\e[0m\] "

Cryptic as is common with the bash shell, and embedded ANSI sequences
are never fun in any context.

Somewhat slightly easier than embedding ANSI control sequences, tput
rummages the terminal tables for that data.

Bluebld="$(tput bold; tput setaf 63)"
Grn="$(tput setaf 34)"
export PS1='\[$Bluebld\]\h: \w$ \[$Grn\]'
alias clear='tput clear'

OpenVMS lacked tput in the GNV bash port when last I checked, and there
is nothing similar to tput in DCL.

> Unfortunately all my research so far has reminded me just how much code
> you have to write if you want to try and do something like this on VMS
> and then create executables which anyone can run.

This is what I've been griping about for some years.

Compared with higher-level tools and frameworks available elsewhere,
the amount of source code I have to write and debug and support and
charge my customers for is... excessive.

Then there are discussions of the differences in the tooling.

> I'm (potentially) interested in prototyping something in the future
> which anyone can try out, but not interested enough to write and debug
> 5 zillion lines of low level boilerplate code.

Boiler-plate code — glue code — is pretty much the definition of C
using OpenVMS features, or BASIC or Fortran using OpenVMS features for
that matter.

>> Does the missed support create the ANSI escape codes for color handling?
>
> Yes, but it's more than that because it fully integrates colour support
> into the curses environment. I don't like curses as such but I've been
> looking at alternatives to SMG$ and that was the only possibility
> shipped with VMS or a layered product which I have found so far.

One of the more recent implementation of curses is new curses or more
commonly known as ncurses, though the effort to port ncurses over to
OpenVMS has not been completed.

Further up the stack are Qt, GTK+ and suchlike. As for the available
GUI on OpenVMS, the X implementation is very old. On the plus side, X
on OpenVMS is so old, CVE-2006-0745 and some others likely don't apply.
I'd still want to look at CVE-1999-0526 and all of others, though.
(And if I were a national intelligence agency or a well-funded entity,
I already would have checked the whole list of CVEs against OpenVMS.)

Dealing with curses or ncurses is no fun, as you spend way too much
time with the displays which means the incentives run contrary to UI
testing and tweaks to improve the user interface design. This is were
tools to help design the UI shine, and where the separation of the UI
from the rest of the app code — so-called MVC or otherwise — also
assist with making the apps easier to understand and use, and to
require less documentation for end-users, and related.

>> So it is used for hardware VT-terminals with color support or on
>> emulators having support for those ESC codes?
>
> Anything which supports colours.

Ayup. This UI and this design — VT-style terminals and code written
for VT terminals that's been combined with terminal emulators, the late
adoption of UI changes and of ease-of-use, extremely late adoption of
open source — has been a substantial part of the OpenVMS market for
decades. Embedded systems seldom have modern UIs, and efforts toward
improving ease of use tend to be limited. Manufacturing organizations
particularly tend to update their servers and software once every
couple of decades, with incremental replacements and variously only for
failing hardware or software or critical patches in the interim. In
recent years, these approaches can encounter issues, such as SCADA
systems routinely getting owned due to shifts in the computing
environments.

Oh, and somewhere up-thread Steven was rummaging through
SYS$COMMON:[DECC$LIB.REFERENCE...] for evidence of support, and the
predecessors to VSI — OpenVMS antebellum? — stopped maintaining that
area a little over a decade ago. Search that with caution, unless
you're using the Freeware libext tool from Freeware V7. libext works
around a limitation of the librarian, an OpenVMS component closely
linked to another facet of the hypothetical replacement of the HELP
tool. Whether VSI reverses that decision to no longer maintain the
reference area, or provides tools to more directly rummage that data is
fodder for other discussions. Maybe extending SEARCH to search and
properly format text library contents? Better header file integration
with LSEDIT or another IDE? Lots of possibilities here. But that's
all fodder for another discussion. But then if the reference area is
no longer being maintained, then the directory should have been
removed. Leaving deprecated code or data or buggy examples around just
never works out.


--
Pure Personal Opinion | HoffmanLabs LLC

[Jan-Erik Soderholm]

A lot of quite contentless words, as usual.

Yes, *we* happens to use DS20's, but what on earth does that
have to do with anything? You, Stephen, is only using that as
a way to say thay I must be wrong. I do not like that. And
what has *Rdb* to do with color on the screens? Come on, I
do think that you can do better, Stephen.

Ayyway, I do not think we have built any new UI on VT-screens
for a decade. Most new additions are using web UIs.

I stand that color support in curses will be fairly far down
the list of enhancements...

Gosh...

[Stephen Hoffman]

On 2017-06-22 13:33:07 +0000, Scott Dorsey said:

> A lot of Unix software uses the color support, most notably things like
> vim and some of the data entry stuff.

Various Unix system startups use colors. These UI designs are akin to
system status dashboards. These designs are a whole lot easier to
review quickly than the usual wall of free-format text output by the
Integrity server consoles and the startups of many OpenVMS servers, too.

[Simon Clubley]

It wasn't so much the slrn application and S-lang library I was talking
about, but I was instead using it as an example of how the use of colour
enhances the display of information.

[Steven Schweda]

> [...] Search that with caution, unless you're using the Freeware
> libext tool from Freeware V7. [...]

With my limited access to compiler updates, it hasn't come up much
lately, but I have a CHEADER.COM script which says:

$! 4 January 2009. SMS.
$!
$! Extract C header files from the text libraries (as in the old
$! days).
$!
$! SYS$LIBRARY:DECC$RTLDEF.TLB ->
$! SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]
$!
$! SYS$LIBRARY:SYS$STARLET_C.TLB ->
$! SYS$COMMON:[DECC$LIB.REFERENCE.SYS$STARLET_C]

Nothing fancy, but it does keep the loose-file collection useful.
For the record:

alp $ show logi decc_include
"DECC_INCLUDE" = "SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]"
(LNM$SYSTEM_TABLE)
= "SYS$COMMON:[DECC$LIB.REFERENCE.SYS$STARLET_C]"

[hb]

On 06/22/2017 08:33 PM, Simon Clubley wrote:
> On 2017-06-22, hb <end...@inter.net> wrote:
>> On 06/22/2017 03:09 PM, Simon Clubley wrote:
>>> In case you are not familiar with colour in a terminal environment
>>> take a look at the following:
>>>
>>> https://en.wikipedia.org/wiki/File:Slrn.png
>>
>> Which is only an example. The wiki entry says Slrn was developed for
>> VMS. S-lang is available for VMS, as well as jed. There are various jed
>> modes for especially VMS, (DCL, MMS/MMK, ...) using colours for syntax
>> highlighting.
>>
>
> It wasn't so much the slrn application and S-lang library I was talking
> about, but I was instead using it as an example of how the use of colour
> enhances the display of information.
>
> Simon.
>

I think I understood, but maybe I didn't. S-lang obviously supports
colours on VMS. The S-lang sources include the file(s slcurses.c and)
slcurses.h. In slcurses.h I see

$ search [-.src]slcurses.h /match=and #define, has_colors
#define has_colors SLcurses_has_colors

So I try to use it with your demo source and

$ ty first.h
#include "../src/slcurses.h"
#define __CURSES_LOADED 1
$
$ cc colour_map/first=[]first.h/include=[-.src]/name=as_is
$ link colour_map,[-.src]slang/lib
$ run colour_map

And voilà I get the coloured "text".

[Simon Clubley]

On 2017-06-22, hb <end...@inter.net> wrote:
> On 06/22/2017 08:33 PM, Simon Clubley wrote:
>> On 2017-06-22, hb <end...@inter.net> wrote:
>>> On 06/22/2017 03:09 PM, Simon Clubley wrote:
>>>> In case you are not familiar with colour in a terminal environment
>>>> take a look at the following:
>>>>
>>>> https://en.wikipedia.org/wiki/File:Slrn.png
>>>
>>> Which is only an example. The wiki entry says Slrn was developed for
>>> VMS. S-lang is available for VMS, as well as jed. There are various jed
>>> modes for especially VMS, (DCL, MMS/MMK, ...) using colours for syntax
>>> highlighting.
>>>
>>
>> It wasn't so much the slrn application and S-lang library I was talking
>> about, but I was instead using it as an example of how the use of colour
>> enhances the display of information.
>>
>

> I think I understood, but maybe I didn't. S-lang obviously supports
> colours on VMS. The S-lang sources include the file(s slcurses.c and)
> slcurses.h. In slcurses.h I see
>

The confusion comes from the fact that I had totally missed that S-lang
has some curses enhancements which could be used.

Because I use slrn I used an image of it to demonstrate to Jan-Erik
the difference colour makes and nothing more. I hadn't even considered
that there might be something usable within S-lang.

I would prefer to only use libraries which ship with VMS but you
have still given me another option to consider.

Thank you,

[Jan-Erik Soderholm]

Den 2017-06-23 kl. 09:22, skrev Simon Clubley:
> On 2017-06-22, hb <end...@inter.net> wrote:
>> On 06/22/2017 08:33 PM, Simon Clubley wrote:
>>> On 2017-06-22, hb <end...@inter.net> wrote:
>>>> On 06/22/2017 03:09 PM, Simon Clubley wrote:
>>>>> In case you are not familiar with colour in a terminal environment
>>>>> take a look at the following:
>>>>>
>>>>> https://en.wikipedia.org/wiki/File:Slrn.png
>>>>
>>>> Which is only an example. The wiki entry says Slrn was developed for
>>>> VMS. S-lang is available for VMS, as well as jed. There are various jed
>>>> modes for especially VMS, (DCL, MMS/MMK, ...) using colours for syntax
>>>> highlighting.
>>>>
>>>
>>> It wasn't so much the slrn application and S-lang library I was talking
>>> about, but I was instead using it as an example of how the use of colour
>>> enhances the display of information.
>>>
>>
>> I think I understood, but maybe I didn't. S-lang obviously supports
>> colours on VMS. The S-lang sources include the file(s slcurses.c and)
>> slcurses.h. In slcurses.h I see
>>
>
> The confusion comes from the fact that I had totally missed that S-lang
> has some curses enhancements which could be used.
>
> Because I use slrn I used an image of it to demonstrate to Jan-Erik
> the difference colour makes and nothing more.

And you totaly missed my point... :-)

New development for VMS is not done on the VT-screen platform.
That is why I do not find *this* (color support for VT-screens)
to be a major issue for VMS today.

I fully understand what colors are and that different colors
looks different from each other. At least to most people... :-)

I see little reason to rewrite all current VT-based VMS utilities
to make use of colors. If you want something more graphical than
MONOTOR, you can run MonDeSi that displays in a web browser.

An example screen copy:
https://wasd.vsm.com.au/wasd_root/src/mondesi/mondesi.png

It is also installed on Decuserve, not responding at the moment:
https://www.decuserve.org/cgiplus-bin/mondesi

The reason that color support is missing from curses on VMS is
probably that there has been no business case that asked for it.
Just provide that business case and I'm sure it can be "fixed".

Regards, and a happy Midsummer to everyone!
https://sweden.se/culture-traditions/midsummer/

Jan-Erik.

[Mark Daniel]

On 23/6/17 7:01 pm, Jan-Erik Soderholm wrote:
8< snip 8<

> I see little reason to rewrite all current VT-based VMS utilities
> to make use of colors. If you want something more graphical than
> MONOTOR, you can run MonDeSi that displays in a web browser.
>
> An example screen copy:
> https://wasd.vsm.com.au/wasd_root/src/mondesi/mondesi.png
>
> It is also installed on Decuserve, not responding at the moment:
> https://www.decuserve.org/cgiplus-bin/mondesi

8< snip 8<

https://eisner.decuserve.org/cgiplus-bin/mondesi

www.decuserve.org not exactly AWOL but close enough ...

HTTP/1.0 200 OK
Cache-Control: max-age=900
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 23 Jun 2017 09:56:16 GMT
Content-Length: 225
Age: 7

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>

This website is temporarily unavailable, please try again later.

<!-- pageok -->
<!-- 10 -->
<!-- -->
</html>

[Craig A. Berry]

On 6/23/17 4:31 AM, Jan-Erik Soderholm wrote:

> New development for VMS is not done on the VT-screen platform.

What is your basis for saying that, and what do you use for VMS
development? I'm not saying you're wrong -- I really want to know. I
still use a terminal session for developing on VMS because I've never
found anything else that actually works with reasonable performance and
reliability.

For example, I've heard people here saying that they use jEdit, so a few
minutes ago I downloaded and installed it, and then fired it up. It's
beautiful and made me think for a minute that the desktop on VMS could
come back after all. Then I tried to open a file and edit it.

My 48-line login.com took 12 seconds to load after double-clicking on it
in the file dialog. It took 7 seconds to highlight a word after
double-clicking. Choosing a menu item, or doing page up or page down,
took about 10 seconds each. That's an order of magnitude or two above
tolerable. This is under XQuartz on macOS on a three-year-old Powerbook
Pro connecting to an rx2660 on my local network. Ping latency is 1.5 ms.

I tried NetBeans when it was supported, both the on-VMS version and the
client/server version. I don't recall its being quite this bad, but it
was pretty bad, performance-wise. I'm quite familiar with copying files
back and forth, but that's an awfully crude and error-prone way to edit
files that ultimately need to reside on VMS. There's no up-to-date SMB
server on VMS and most of what I hear about the NFS client is horror
stories. BBEdit as an sftp client shows more promise than most, so I may
have to revisit that.

With all of the above except NetBeans, you still have to have a terminal
session open to compile, link, and run your code, unless it's Java,
Perl, or Python and you develop it elsewhere and only deploy on VMS, but
that seems unlikely to be a very big portion of applications running on VMS.

So, I keep using my custom TPU section that I've been dragging around
for a quarter century. It works ok, but I do wish it could do color
syntax highlighting :-).

[Robert A. Brooks]

On 6/23/2017 10:30 PM, Craig A. Berry wrote:

> So, I keep using my custom TPU section that I've been dragging around
> for a quarter century.

Young'un!

My EDTINI.EDT file is largely unchanged since 1981, RSTS/E heritage.

--

-- Rob

[Henry Crun]

...and my TPU section file is (mainly) a carry-over from RSTS, started in '85.
with definitions for right-to-left typing, buffer includes etc.
When did TPU start replacing EDT?

--
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
and: http://alpha.mike-r.com/jargon/T/top-post.html

[Jan-Erik Soderholm]

Den 2017-06-24 kl. 04:30, skrev Craig A. Berry:
> On 6/23/17 4:31 AM, Jan-Erik Soderholm wrote:
>
>> New development for VMS is not done on the VT-screen platform.
>
> What is your basis for saying that, and what do you use for VMS
> development?

Sorry, I was unclear. *I* use VMS for VMS development. What I meant was
that the users are less and less using VT-screens as their application
user-interface run-time environment.

Maybe "on the VT-screen" should have been "for the VT-screen" above.

Yes, a lot can be done to modernize the VMS development tools, and I
guess that will happen on desktop type of environments. I do not see
a lot of time and money spent on pure VMS application tools, apart
from the server parts to support the desktop IDE's.

> I'm not saying you're wrong -- I really want to know.

There you are, I was unclear... :-)

> ...

> With all of the above except NetBeans, you still have to have a terminal

> session open to compile, link, and run your code,...

I have done som tests with UltraEdit-32 (would probably be similar with
their UEStudio that shares features). It has full FTP/SFTP/SSH support
builtin so you can directy edit remote files and run terminal sessions
within the IDE itself to run your builds. It has a powerfull scripting
environment so I'm sure you can automate that also.

See: https://www.ultraedit.com/products/ultraedit/features.html#prog

"Robust server support including AIX / AS400 / BS2000 / MVS / HP3000 /
OpenVMS / OS9000 / Stratus VOS / Tandem / UNIX / VShell (and auto-detection
of server type)"

The FTP support is fully integrated in the "Open" and "Save as" dialoges.

Remote debugging isn't there, that has to be done the traditional way.

It does have language files for many different programming languages,
but no VMS specific extensions or so. The language files are open
source and there are already third part files, so technically there
is no issue to make VMS specific language support. See:
https://www.ultraedit.com/downloads/extras/wordfiles.html
Search the page for "VMS"...


Anyway, if not using specifically UEStudio as the foundation, this is
how I see future VMS developments tools and IDEs being built.

Not by adding color support to HELP.

Jan-Erik.

[hb]

On 06/24/2017 04:30 AM, Craig A. Berry wrote:
> With all of the above except NetBeans, you still have to have a terminal
> session open to compile, link, and run your code, unless it's Java,
> Perl, or Python and you develop it elsewhere and only deploy on VMS, but
> that seems unlikely to be a very big portion of applications running on
> VMS.

For what it is worth, for/on VMS I use XTerm and jed - in EDT mode, with
my jed modes doing syntax colouring for DCL, MMS/MMK, Linker options,
Modparams, SDL, BLISS and Macro32.

For C, C++ I copy the sources back and forth and use Eclipse on a Linux
system, with some tweaks so that gcc only uses VMS supplied include
files and "builds" are compile only, no assembly nor link. Obviously I
still have to compile and link on VMS, but I can take advantage of all
the Eclipse features while editing the sources. Here for DCL, MMS/MMK
and Linker options I use my Editor plugin.

[Craig A. Berry]

On 6/23/17 10:56 PM, Robert A. Brooks wrote:
> On 6/23/2017 10:30 PM, Craig A. Berry wrote:
>
>> So, I keep using my custom TPU section that I've been dragging around
>> for a quarter century.
>
> Young'un!

Well I was using EDT before that, obviously :-).

[Robert A. Brooks]

On 6/24/2017 12:31 AM, Henry Crun wrote:
> On 24-Jun-2017 06:56, Robert A. Brooks wrote:
>> On 6/23/2017 10:30 PM, Craig A. Berry wrote:
>>
>>> So, I keep using my custom TPU section that I've been dragging around
>>> for a quarter century.
>>
>> Young'un!
>>
>> My EDTINI.EDT file is largely unchanged since 1981, RSTS/E heritage.
>>
> ...and my TPU section file is (mainly) a carry-over from RSTS, started in '85.
> with definitions for right-to-left typing, buffer includes etc.
> When did TPU start replacing EDT?

I think TPU came with VAX/VMS V4.2. Might have been V4.4, but I'm sure
it was one of those two versions.

--
-- Rob

[Jan-Erik Soderholm]

Den 2017-06-24 kl. 06:31, skrev Henry Crun:

> When did TPU start replacing EDT?

Others know that better than me. What I do know is that
TPU has not finished replacing EDT yet... :-)

[David Froble]

Henry Crun wrote:
> On 24-Jun-2017 06:56, Robert A. Brooks wrote:
>> On 6/23/2017 10:30 PM, Craig A. Berry wrote:
>>
>>> So, I keep using my custom TPU section that I've been dragging around
>>> for a quarter century.
>>
>> Young'un!
>>
>> My EDTINI.EDT file is largely unchanged since 1981, RSTS/E heritage.
>>
> ...and my TPU section file is (mainly) a carry-over from RSTS, started
> in '85.
> with definitions for right-to-left typing, buffer includes etc.
> When did TPU start replacing EDT?
>

Depends who you're asking. For me, it's never happened.

[Stephen Hoffman]

On 2017-06-24 02:30:29 +0000, Craig A. Berry said:

> ...With all of the above except NetBeans, you still have to have a

> terminal session open to compile, link, and run your code, unless it's
> Java, Perl, or Python and you develop it elsewhere and only deploy on
> VMS, but that seems unlikely to be a very big portion of applications
> running on VMS.
>
> So, I keep using my custom TPU section that I've been dragging around
> for a quarter century. It works ok, but I do wish it could do color
> syntax highlighting :-).

The OpenVMS IDEs I've tried aren't up to the same level of OpenVMS
integration and polish, nor to the same level of performance of various
IDEs running on other platforms. That'll come, of course. Of the
available IDEs, the LSEDIT IDE does perform well, but is severely
lacking in a number of areas. Syntax highlighting, source code
formatting, etc. The portable IDEs definitely have more capabilities
than what is available in LSEDIT. The portable IDEs I've tried do run
faster on on x86-64 systems and I've done some cross-platform
development on OpenVMS using them, though (unsurprisingly) the native
IDEs such as Xcode and Visual Studio do have better performance. I'm
not at all certain whether that performance difference is due to the
hardware underneath OpenVMS, or due to the Java performance, or quite
possibly both. Like you, I've stayed with an older means of source
code development while working on OpenVMS and with all that approach
lacks, because the available tools just haven't gotten sufficient
support and integration from OpenVMS. Better integration involves
access to the documentation, the debugger, the compiler diagnostics and
analysis files, and improvements to the performance of the Java and
other languages, as well as faster underlying hardware. The folks that
are working on the IDEs at VSI and third parties undoubtedly know all
of this too, and — for folks that have worked with Xcode, Visual Studio
or JetBrains — the gaps in the OpenVMS tools that would allow the VSI
and third-party IDEs better integration and better capabilities are
certainly apparent.

For now, vim and LSEDIT and command-line on OpenVMS. Though that's
unfortunately limiting. No, I'm not going back to EDT. But then I'm
sure that SSDs makes EDT work better than it once did.

Yes, there are problems with Xcode, Visual Studio, JetBrains, LSEDIT,
Eclipse, and many (all?) other development tools. None are perfect.
Far from it.

Yes, I know from and use artistic style source code formatter, and
other tools that can be useful on OpenVMS and other platforms, too.
(Add a source code formatter into a check-in hook in your source pool
management tool, too. That gets all the source code consistently
formatted, and reduces that particular aspect of herding cats. But I
digress.)

We're just not in an era when a whole lot of developers are interested
in routinely dealing with command-line application development. I'm
certainly not, and I know how to do it. Nor are we in an era when
that's a particularly efficient way to develop applications. This
having used native IDEs myself. While the need to do command-line
work will never completely go away, the business is entirely headed
toward IDEs. As compared with when I first started looking at and
much of my early experience with IDEs from years ago — back when the
IDEs often entirely stank on their target native platforms — the
available development tools and features and capabilities and
performance and related factors have all changed. The better IDEs are
definitely useful and increasingly so, and make for easier and better
development. And yes, IDEs and better tools and newer languages are a
change from how we've always done things. We're busy automating
ourselves, too. Welcome to computing.

[Simon Clubley]

When I moved from RSTS/E to VMS in the early 1990s, EVE and TPU
instantly replaced both EDT and TECO for me and I never looked back.

I still remember thinking after the first day or so of using EVE
and the underlying TPU language how much better it was than what
I had used up to that point; there was an instant positive liking
for EVE/TPU from me.

I've just had an idea, but I will ask that in another thread. :-)

[Arne Vajhøj]

On 6/23/2017 10:30 PM, Craig A. Berry wrote:

> On 6/23/17 4:31 AM, Jan-Erik Soderholm wrote:
>> New development for VMS is not done on the VT-screen platform.
>
> What is your basis for saying that, and what do you use for VMS
> development? I'm not saying you're wrong -- I really want to know. I
> still use a terminal session for developing on VMS because I've never
> found anything else that actually works with reasonable performance and
> reliability.

It probably varies.

I would expect two large categories:
* those that develop on VMS using VT, DCL and one of EDT/TPU/LSE
like they have for the last 30-40 years
* those that develop on a PC using modern tools and just move files
up and build on VMS

> For example, I've heard people here saying that they use jEdit, so a few
> minutes ago I downloaded and installed it, and then fired it up. It's
> beautiful and made me think for a minute that the desktop on VMS could
> come back after all. Then I tried to open a file and edit it.
>
> My 48-line login.com took 12 seconds to load after double-clicking on it
> in the file dialog. It took 7 seconds to highlight a word after
> double-clicking. Choosing a menu item, or doing page up or page down,
> took about 10 seconds each. That's an order of magnitude or two above
> tolerable. This is under XQuartz on macOS on a three-year-old Powerbook
> Pro connecting to an rx2660 on my local network. Ping latency is 1.5 ms.

Very difficult to troubleshoot based based on this information.

I have seen jEdit work acceptable on VMS.

As all Java applications it like (after VMS standard) huge amount
of memory.

> So, I keep using my custom TPU section that I've been dragging around
> for a quarter century. It works ok, but I do wish it could do color
> syntax highlighting :-).

I also have a highly customized EVE based on what I did in easter 1987.

:-)

Arne

[Arne Vajhøj]

On 6/24/2017 12:31 AM, Henry Crun wrote:

> When did TPU start replacing EDT?

I think 4.4, but I am not 100% sure as 4.4 was my first VMS version.

Arne

[Bill Gunshannon]

On 6/24/2017 1:34 PM, Stephen Hoffman wrote:
> On 2017-06-24 02:30:29 +0000, Craig A. Berry said:
>
>> ...With all of the above except NetBeans, you still have to have a
>> terminal session open to compile, link, and run your code, unless it's
>> Java, Perl, or Python and you develop it elsewhere and only deploy on
>> VMS, but that seems unlikely to be a very big portion of applications
>> running on VMS.
>>
>> So, I keep using my custom TPU section that I've been dragging around
>> for a quarter century. It works ok, but I do wish it could do color
>> syntax highlighting :-).
>
> The OpenVMS IDEs I've tried aren't up to the same level of OpenVMS
> integration and polish, nor to the same level of performance of various
> IDEs running on other platforms.

Has anyone ever tried to use jGrasp on VMS? It's Java code so it
should work. Of course, requires a GUI so I would assume DECWindows
and a remote terminal of some kind.

bill

[Kerry Main]

Have you tried using NXTware Remote from eCube?

< http://www.ecubesystems.com/products/nxtware-remote.html>
[click on video testimonial from leading credit card company]

" NXTware Remote makes remote agile development possible for OpenVMS, Unix/Linux, and other operating systems from Windows or Linux workstations. It simplifies remote development for C, C++, COBOL, BASIC, Pascal, FORTRAN and Java developers, making them more productive."

"NXTware Remote is a distributed integrated development environment comprised of two components: NXTware Remote Server and NXTware Remote Studio, an Eclipse plug-in. Together, they enable developers to use modern IDEs to analyze and edit code on local workstations then compile, debug and deploy them on any remote server with greater productivity, better code quality and the agility needed to meet future needs."

Bottom line - there are better IDE options for OpenVMS available today if you find EDT / LSE is not enough.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com