Does VSI have a preferred or official language for system programming
for OpenVMS?

I know system programming for VAX/VMS was done in MACRO-32 and BLISS-32,
and at least some system programs were written in C when Alpha was
introduced.

VSI has the BLISS reference manual on the Legacy shelf.

Have all the MACRO and BLISS programs been ported to C or C++, or will
they be in the future?

--
David Meyer
Takarazuka, Japan
papa@sdf.org

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/19/2024 01:56, David Meyer wrote:

Does VSI have a preferred or official language for system programming
for OpenVMS?

I know system programming for VAX/VMS was done in MACRO-32 and BLISS-32,
and at least some system programs were written in C when Alpha was introduced.

VSI has the BLISS reference manual on the Legacy shelf.

Have all the MACRO and BLISS programs been ported to C or C++, or will
they be in the future?

About 40% of the operating system is now written in C, 30% in both MACRO-21 and BLISS.

Work was done in the mid-90's to make it easier to write kernel mode code in C; most of the MACRO-only JSB interfaces were jacketed with the ability to call them from C.

As a result, the "Writing OpenVMS Alpha Device Drivers in C" book (Szubowicz, Sherlock)
describes some of those changes.

--
-- Rob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/19/2024 11:38, Robert A. Brooks wrote:

About 40% of the operating system is now written in C, 30% in both MACRO-21 and BLISS. ^^^^^^^^

MACRO-32 . . .

--
-- Rob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 19 Dec 2024 15:56:43 +0900, David Meyer wrote:

Have all the MACRO and BLISS programs been ported to C or C++, or will
they be in the future?

I hear there is this new language called “Java”, that is supposed to take over from C++ ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/19/2024 1:56 AM, David Meyer wrote:

Does VSI have a preferred or official language for system programming
for OpenVMS?

I know system programming for VAX/VMS was done in MACRO-32 and BLISS-32,
and at least some system programs were written in C when Alpha was introduced.

VSI has the BLISS reference manual on the Legacy shelf.

Have all the MACRO and BLISS programs been ported to C or C++, or will
they be in the future?

Brooks already explained what VSI actually has in the VMS code base.

Since I am not with VSI then I can better speculate and my
guess is that:
- VSI would like to rewrite all the remaining Bliss and Macro
to make maintenance easier
- VSI does not have the money to start a systematic migration
of all the remaining Bliss and Macro because migrating that
many millions of lines would be too expensive (I stuffed some
random numbers into a COCOMO style model and it said 1500
man years!)

If you are really asking what language you should use for
writing VMS code interfacing closely with the OS (more close
than just using documented LIB$ and SYS$ calls), then I will
suggest C. C is officially supported for writing device drivers
nowadays and I believe they have a subset of the C RTL that is
safe to call in inner modes.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks, all.

I'm working on a retrocomputing project on a VAX teaching myself
BLISS-32 and was curious about the current state of the OS.

--
David Meyer
Takarazuka, Japan
papa@sdf.org

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-12-19 06:56:43 +0000, David Meyer said:

Does VSI have a preferred or official language for system programming
for OpenVMS?

Starting in the early 1990s, the language choice for DEC OpenVMS was C.

I know system programming for VAX/VMS was done in MACRO-32 and
BLISS-32, and at least some system programs were written in C when
Alpha was introduced.

VSI has the BLISS reference manual on the Legacy shelf.

BLISS was retired as a salable layered product long ago.

The BLISS compilers became available on the Freeware.

BLISS remains necessary for OpenVMS itself. As is MACRO-32, and some
layered products including Notes.

Have all the MACRO and BLISS programs been ported to C or C++, or will
they be in the future?

No, and no.

Back around Y2K, MACRO-32, BLISS, and C were roughly divided in thirds
of the ~64K source modules in OpenVMS Alpha and OpenVMS I64 source
pool, with the percentage of C rapidly increasing starting with the C
system programming work introduced at V6.1.

VSI is likely still following those longstanding DEC OpenVMS practices
here, and will be writing new code in C, rewriting existing code being overhauled into C, and maintaining and modifying the rest of the
existing code in the original language as needed.

Some code gets rewritten due to other constraints, such as the PL/1
code, and the Ada code.

Rewriting existing code is best approached with great caution, as it
can very easily become exceedingly expensive, and tedious. It also
requires immense resources. And even the best results can be perilous.

In a manner of consideration, rewrites are a whole lot like platform
ports, though rewrites are far bigger and far riskier and far more
costly projects. And keep other development work constrained for even
longer than the port tends to cause.

There are, of course, other and even better ways to spend vast sums for negligible benefits for the OpenVMS vendor, such as a Linux "kernel
transplant" that was suggested by a few folks around here. Though if
you do want that something akin to that approach, have a look at Sector
7 product.

I'd suggest reading some of Martin Fowler's writings in the area of
incremental rewrites and refactoring, as that might help avoid some
common missteps.


--
Pure Personal Opinion | HoffmanLabs LLC

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 27 Dec 2024 22:47:58 -0500, Stephen Hoffman wrote:

Starting in the early 1990s, the language choice for DEC OpenVMS was C.

It could do with Pascal-style extensions added to it to cope with
descriptors, counted strings, named arguments etc. Otherwise it is quite
an awkward language to use for VMS programming.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Thu, 19 Dec 2024 15:56:43 +0900, David Meyer wrote:

Have all the MACRO and BLISS programs been ported to C or C++, or will
they be in the future?

I hear there is this new language called “Java”, that is supposed to take >over from C++ ...

When Java first came out, I had this image in my head of a bunch of
managers sitting around a table asking "What can we do to make computers
more slow? How can we sell people on more expensive hardware?" "I know,
we can get the UCSD P-System for the new millennium!"
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/23/2025 1:21 PM, Scott Dorsey wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Thu, 19 Dec 2024 15:56:43 +0900, David Meyer wrote:

Have all the MACRO and BLISS programs been ported to C or C++, or will
they be in the future?

I hear there is this new language called “Java”, that is supposed to take
over from C++ ...

When Java first came out, I had this image in my head of a bunch of
managers sitting around a table asking "What can we do to make computers
more slow? How can we sell people on more expensive hardware?" "I know,
we can get the UCSD P-System for the new millennium!"

Java 1.0.2 was probably rather similar to P-System regarding
hardware usage.

But if enough money is spent then problems get solved.

If we look at the traditional JVM problems:

byte code interpretation is slow - got fixed with JIT compilation
25 years ago, on VMS x86-64 the JVM JIT compiler is one of the
best optimizers

the JVM has many MB of memory as overhead - became irrelevant
when price of RAM dropped to a few dollars per GB

generational GC is very efficient at average but it has
horrible real time characteristics due to the dreaded
ms GC pauses - got fixed via special JVM's like Azul
Zing (with pauseless C4 GC) and in mainstream with the introduction
of ZGC that changed pauses from ms to us, we are still waiting
for ZGC on VMS though (we should get the non-generational
ZGC with Java 17 relative soon and the generational ZGC
with the next release 21 or 25)

huge upstart time due to JVM initialization and JIT
compilation - got fixed when AOT compilation was
introduced with Graal (Spring Boot Native, Quarkus
etc. all use Graal AOT), note that Graal is not available
on VMS and I have heard no indication that VSI is considering
porting it

None of this solved itself by magic. But Sun, IBM, Oracle etc.
put hundreds of thousands of man years into making it happen. So
it happened.

P-System had 2 problems: hardware was rather limited in its time
and nobody wanted to spend money on it like money was spent on JVM.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 23 Feb 2025 21:09:53 -0500, Arne Vajhøj wrote:

generational GC is very efficient at average but it has horrible real
time characteristics due to the dreaded ms GC pauses - got fixed via
special JVM's ...

None of which get around the basic problem that current CPUs depend
crucially for their speed on good program caching behaviour, and garbage collection is ultimately a cache-hostile process.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-02-23, Scott Dorsey <kludge@panix.com> wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Thu, 19 Dec 2024 15:56:43 +0900, David Meyer wrote:

Have all the MACRO and BLISS programs been ported to C or C++, or will
they be in the future?

I hear there is this new language called “Java”, that is supposed to take >>over from C++ ...

When Java first came out, I had this image in my head of a bunch of
managers sitting around a table asking "What can we do to make computers
more slow? How can we sell people on more expensive hardware?" "I know,
we can get the UCSD P-System for the new millennium!"

As Arne is well aware, my number one issue with Java is how the bloody
^&^%*& JNI interface was designed. It's utter crap, especially when you
are trying to get it working on Android. There is a replacement in the
works, but you still have legacy device issues to deal with so that
will not really make a difference for a few years

My number two issue is the lack of actual unsigned integers in Java.
Some hacks have been added to later Java versions to support unsigned integer operations, but it's still signed integers at the core as I understand it.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/24/2025 2:10 PM, Simon Clubley wrote:

On 2025-02-23, Scott Dorsey <kludge@panix.com> wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Thu, 19 Dec 2024 15:56:43 +0900, David Meyer wrote:

Have all the MACRO and BLISS programs been ported to C or C++, or will >>>> they be in the future?

I hear there is this new language called “Java”, that is supposed to take
over from C++ ...

When Java first came out, I had this image in my head of a bunch of
managers sitting around a table asking "What can we do to make computers
more slow? How can we sell people on more expensive hardware?" "I know,
we can get the UCSD P-System for the new millennium!"

As Arne is well aware, my number one issue with Java is how the bloody
^&^%*& JNI interface was designed. It's utter crap, especially when you
are trying to get it working on Android. There is a replacement in the
works, but you still have legacy device issues to deal with so that
will not really make a difference for a few years

JNI is very cumbersome to work with.

But I think that the design made sense back in the late 90's. Back then
it needed to be very efficient and there were lots of C developers
and no Java developers. So it was decided that the glue code should
be written in C/C++.

IT has changed since then. And JNI is an obsolete design.

On Windows or Linux you can use JNA to be able to write the
glue code in Java. I believe it is also available for Android.

On VMS you can use my VMSCALL library that does VMS calling
convention in Java.

And Java 16 (preview) / 22 (final) added Java Foreign Function,
which added a standardized way to do it.

I wonder whether we will get the preview in Java 17 on VMS or
we will have to wait for final in Java 25 or whatever.

My number two issue is the lack of actual unsigned integers in Java.
Some hacks have been added to later Java versions to support unsigned integer operations, but it's still signed integers at the core as I understand it.

The lack of unsigned integers is a PITA.

And they could have done it. Kotlin added unsigned integers (first as experimental and then fully in version 1.5).

But if you are writing Android code, then you should use Kotlin!

I can think about a few other problems though.

The decision to implement generics in a backwards compatible
way in Java 5 had some immediate benefits, but we are also
paying the price today.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 24 Feb 2025 14:37:54 -0500, Arne Vajhøj wrote:

The lack of unsigned integers is a PITA.

Also the lack of typedefs. A basic convenience, but such an important one.

The decision to implement generics in a backwards compatible way in Java
5 had some immediate benefits, but we are also paying the price today.

It seemed to be done to maintain backward binary compatibility with older bytecode that could not be recompiled. Was there a lot of such bytecode? I never realized ...

I think somewhere in the beginning, the goal of Java was to take all the
good bits out of C++, leave out the rest and add garbage collection and
some dynamic capability -- basically to be a simpler, smaller language
than C++. Somehow along the way, that goal got lost.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/24/2025 3:23 PM, Lawrence D'Oliveiro wrote:

On Mon, 24 Feb 2025 14:37:54 -0500, Arne Vajhøj wrote:

The lack of unsigned integers is a PITA.

Also the lack of typedefs. A basic convenience, but such an important one.

typedef is very much used in C.

Type declarations are part of the Pascal way.

But I don't think it is the same in OO languages.

I have never heard a Java developer ask for it.

C# has the functionality (in using directive). But I
have never used it myself and I don't think I have
ever seen code using it (note: I am talking about
using for type alias only - using for namespace alias is
used occasionally).

Kotlin also has it and even though it is used then
I would call it rare.

I cannot demo C# on VMS< but Kotlin runs on VMS, so:

$ type ta.kt
typealias OneToMany<T> = Map<T,List<T>>

fun dump(m: OneToMany<String>, rt: String) {
println("$rt:")
for(lang in m[rt].orEmpty()) {
println(" $lang")
}
}

fun main() {
val m: OneToMany<String> = mapOf(Pair("JVM", listOf("Java",
"Kotlin", "Scala", "Groovy")),
Pair("CLR", listOf("C#", "VB.NET", "F#")))
dump(m, "JVM")
dump(m, "CLR")
}
$ kotlinc """ta.kt"""
$ java -cp .:/disk0/net/kotlin/kotlinc/lib/* "TaKt"
JVM:
Java
Kotlin
Scala
Groovy
CLR:
C#
VB.NET
F#

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/24/2025 3:23 PM, Lawrence D'Oliveiro wrote:

The decision to implement generics in a backwards compatible way in Java
5 had some immediate benefits, but we are also paying the price today.

It seemed to be done to maintain backward binary compatibility with older bytecode that could not be recompiled. Was there a lot of such bytecode? I never realized ...

It was not just a binary compatibility for already compiled
byte code. It would have impacted the ability to recompile
existing source code as well.

Yes - lots of code.

Java got generics in its 6th version (1.0, 1.1, 1.2, 1.3, 1.4, 1.5) and implemented generics in a way compatible with existing collections.

C#/.NET got generics in its 3rd version (1.0, 1.1, 2.0) and implemented generics in a way that required new collections to be added.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 24 Feb 2025 16:55:31 -0500, Arne Vajhøj wrote:

Type declarations are part of the Pascal way.

But I don't think it is the same in OO languages.

I have never heard a Java developer ask for it.

Never written things like this?

private final HashMap<Integer, ArrowLabel>
SatLabels = new HashMap<Integer, ArrowLabel>();

Or this?

return
new Iterable<Map<String, String>>()
{
public Iterator<Map<String, String>> iterator()
{
return
new ResultMapIterator
(
Resolver.query
(
/*uri =*/ ProviderUri,
/*projection =*/ FieldNames,
/*selection =*/ Selection,
/*selectionArgs =*/ SelectionArgs,
/*sortOrder =*/ SortOrder
),
FieldNames
);
} /*iterator*/
} /*Iterable*/;

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/24/2025 8:05 PM, Lawrence D'Oliveiro wrote:

On Mon, 24 Feb 2025 16:55:31 -0500, Arne Vajhøj wrote:

Type declarations are part of the Pascal way.

But I don't think it is the same in OO languages.

I have never heard a Java developer ask for it.

Never written things like this?

private final HashMap<Integer, ArrowLabel>
SatLabels = new HashMap<Integer, ArrowLabel>();

I would write:

private final Map<Integer, ArrowLabel> satLabels = new HashMap<Integer, ArrowLabel>();

to follow OO best practice and Java coding convention.

But I think it is good code.

It is very clear what it is. All Java developers know what Map
and HashMap are.

Introducing application specific aliases for Map<Integer, ArrowLabel>
and HashMap<Integer, ArrowLabel> would make the code less readable.

Or this?

return
new Iterable<Map<String, String>>()
{
public Iterator<Map<String, String>> iterator()
{
return
new ResultMapIterator
(
Resolver.query
(
/*uri =*/ ProviderUri,
/*projection =*/ FieldNames,
/*selection =*/ Selection,
/*selectionArgs =*/ SelectionArgs,
/*sortOrder =*/ SortOrder
),
FieldNames
);
} /*iterator*/
} /*Iterable*/;

I see lots of problems in that code.

I don't consider lack of type aliases as one of them.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 24 Feb 2025 20:33:07 -0500, Arne Vajhøj wrote:

But I think it is good code.

I think it is bloody long-winded code.

In C++ I could write things like

typedef std::map<std::string /*section*/, SectionParams>
SectionTable;
typedef std::pair<std::string, SectionParams>
SectionTablePair;
typedef SectionTable::const_iterator
SectionTableLister;

but Java doesn’t give you the option.

And then there’s the long-windedness of code like

static final java.util.Map<Integer, String> TypeNames;
/* mapping from sensor type codes to symbolic names */
static
{
TypeNames = new java.util.HashMap<Integer, String>();
TypeNames.put(Sensor.TYPE_ACCELEROMETER, "accelerometer");
TypeNames.put(Sensor.TYPE_AMBIENT_TEMPERATURE, "ambient temperature");
TypeNames.put(Sensor.TYPE_GRAVITY, "gravity");
TypeNames.put(Sensor.TYPE_GYROSCOPE, "gyroscope");
TypeNames.put(Sensor.TYPE_LIGHT, "light");
TypeNames.put(Sensor.TYPE_LINEAR_ACCELERATION, "linear accel");
TypeNames.put(Sensor.TYPE_MAGNETIC_FIELD, "magnetic");
TypeNames.put(Sensor.TYPE_ORIENTATION, "orientation");
TypeNames.put(Sensor.TYPE_PRESSURE, "pressure");
TypeNames.put(Sensor.TYPE_PROXIMITY, "proximity");
TypeNames.put(Sensor.TYPE_RELATIVE_HUMIDITY, "relative humidity");
TypeNames.put(Sensor.TYPE_ROTATION_VECTOR, "rotation");
TypeNames.put(Sensor.TYPE_TEMPERATURE, "temperature");
} /*static*/

because the language doesn’t provide expressions that evaluate to
common structure types like dictionaries/maps.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/24/2025 9:22 PM, Lawrence D'Oliveiro wrote:

And then there’s the long-windedness of code like

static final java.util.Map<Integer, String> TypeNames;
/* mapping from sensor type codes to symbolic names */
static
{
TypeNames = new java.util.HashMap<Integer, String>();
TypeNames.put(Sensor.TYPE_ACCELEROMETER, "accelerometer");
TypeNames.put(Sensor.TYPE_AMBIENT_TEMPERATURE, "ambient temperature");
TypeNames.put(Sensor.TYPE_GRAVITY, "gravity");
TypeNames.put(Sensor.TYPE_GYROSCOPE, "gyroscope");
TypeNames.put(Sensor.TYPE_LIGHT, "light");
TypeNames.put(Sensor.TYPE_LINEAR_ACCELERATION, "linear accel");
TypeNames.put(Sensor.TYPE_MAGNETIC_FIELD, "magnetic");
TypeNames.put(Sensor.TYPE_ORIENTATION, "orientation");
TypeNames.put(Sensor.TYPE_PRESSURE, "pressure");
TypeNames.put(Sensor.TYPE_PROXIMITY, "proximity");
TypeNames.put(Sensor.TYPE_RELATIVE_HUMIDITY, "relative humidity");
TypeNames.put(Sensor.TYPE_ROTATION_VECTOR, "rotation");
TypeNames.put(Sensor.TYPE_TEMPERATURE, "temperature");
} /*static*/

because the language doesn’t provide expressions that evaluate to
common structure types like dictionaries/maps.

If you are on Java 10+ then you could:

Map<Integer, String> typeNames = Map.of(Sensor.TYPE_ACCELEROMETER, "accelerometer",

Sensor.TYPE_AMBIENT_TEMPERATURE, "ambient temperature",
...);

But the Sensor.TYPE_* int approach has been obsolete since Java 5 where
Java got enums.

With enum the need for that Map disappears.

You can either hack it:

public class EnumHack {
public static enum SensorType {
TYPE_ACCELEROMETER, TYPE_AMBIENT_TEMPERATURE, TYPE_GRAVITY;
public String prettyName() {
return name().substring(5).toLowerCase().replace('_', ' ');
}
}
public static void main(String[] args) {

System.out.println(SensorType.TYPE_AMBIENT_TEMPERATURE.prettyName());
}
}

or do it the right way:

public class EnumRight {
public static enum SensorType {
TYPE_ACCELEROMETER("accelerometer"),
TYPE_AMBIENT_TEMPERATURE("ambient temperature"), TYPE_GRAVITY("gravity");
private String prettyName;
private SensorType(String prettyName) {
this.prettyName = prettyName;
}
public String getPrettyName() {
return prettyName;
}
}
public static void main(String[] args) {

System.out.println(SensorType.TYPE_AMBIENT_TEMPERATURE.getPrettyName());
}
}

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/24/2025 9:22 PM, Lawrence D'Oliveiro wrote:

On Mon, 24 Feb 2025 20:33:07 -0500, Arne Vajhøj wrote:

# private final Map<Integer, ArrowLabel> satLabels = new
HashMap<Integer, ArrowLabel>();

But I think it is good code.

I think it is bloody long-winded code.

It is fine with me.

I do not even like the Java 7+ version:

private final Map<Integer, ArrowLabel> satLabels = new HashMap<>();

In C++ I could write things like

typedef std::map<std::string /*section*/, SectionParams>
SectionTable;
typedef std::pair<std::string, SectionParams>
SectionTablePair;
typedef SectionTable::const_iterator
SectionTableLister;

Yes.

But that just give the reader of the code a few more names
to remember what is.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 24 Feb 2025 22:23:30 -0500, Arne Vajhøj wrote:

But that just give the reader of the code a few more names to remember
what is.

That’s what your editor’s search facility is for.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)