From Newsgroup: comp.os.vms

ZeroMQ in Pascal.

Take and install/build:
* libzmq kit from VSI (has to be V4.1-8A, programs crash with
V4.1-2A on x86-64)
* https://www.vajhoej.dk/arne/opensource/vms/vmspzmq-src-v1_0-upd2.zip

Tested on 9.2-3.

Demo:

[inherit('pzmqdir:common', 'pzmqdir:pzmq')]
program s3(input,output);

var
ctx : zmq_ctx;
s : zmq_sock;
reqmsg, respmsg : pstr;

begin
ctx := zmq_ctx_new;
s := zmq_socket(ctx, ZMQ_REP);
zmq_bind(s, 'tcp://*:10000');
respmsg := '';
while true do begin
zmq_recv(s, reqmsg, 0);
respmsg := respmsg + reqmsg + chr(13) + chr(10);
zmq_send(s, respmsg, 0);
end;
end.

$ pas s3
$ link/thread s3 + pzmqdir:pzmq + pzmqdir:common +
zmq$root:[lib]libzmq64/lib

[inherit('pzmqdir:common', 'pzmqdir:pzmq')]
program c3(input,output);

var
ctx : zmq_ctx;
s : zmq_sock;
reqmsg, respmsg : pstr;

begin
ctx := zmq_ctx_new;
s := zmq_socket(ctx, ZMQ_REQ);
zmq_connect(s, 'tcp://localhost:10000');
reqmsg := 'Hi from Pascal!';
zmq_send(s, reqmsg, 0);
zmq_recv(s, respmsg, 0);
writeln(respmsg);
zmq_close(s);
zmq_ctx_destroy(ctx);
end.

$ pas c3
$ link c3 + pzmqdir:pzmq + pzmqdir:common + zmq$root:[lib]libzmq64/lib

Note: have to link against libzmq64 - programs crash if linked against
libzmq32 (apparently Pascal 32 bit pointers -> C 64 bit pointers
is more safe than C 32 bit pointers -> C++ 64 bit pointers!!).

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/13/2025 10:07 AM, Arne Vajh|+j wrote:

$ pas s3
$ link/thread s3 + pzmqdir:pzmq + pzmqdir:common + zmq$root:[lib]libzmq64/lib

/thread is not strictly needed, but without it breaking the
infinite loop with CTRL/Y exits a bit hard.

$ r s3
Interrupt

$ dir
%DECthreads bugcheck (version V3.23-001), terminating execution.

% Reason: lckMcsLock: deadlock detected, cell = 0x7b5e2e00

% Running on OpenVMS V9.2-3() on VMware, Inc. VMware20,1, 7932Mb; 4
CPUs, pid 1056

% The bugcheck occurred at 13-SEP-2025 09:51:43.91, running image

% DKA0:[arne.art.ipc.zmq]s3.EXE;3 in process 420 (named "ARNE"), under

% username "ARNE". AST delivery is enabled for kernel, exec, super;
ASTs are

% active in user. Upcalls are disabled. Multiple kernel threads are
disabled.

% The current thread sequence number is 1, at 0x7b5e2e00

% Current thread traceback:

% 0: PC 0x8cdbf10, SP 0x7ac860a0, ICTX 0x7ac866f8

...

% 36: PC 0x7adc432c, SP 0x7ac9ba30, ICTX 0x7ac9bab8

% Bugcheck output saved to pthread_dump.log.

%SYSTEM-F-IMGDMP, dynamic image dump signal at PC=FFFF830008CDC1F6, PS=0000001B

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Sat, 13 Sep 2025 10:07:28 -0400, Arne Vajh|+j wrote:

ctx := zmq_ctx_new;
s := zmq_socket(ctx, ZMQ_REQ);
zmq_connect(s, 'tcp://localhost:10000');

Are errors automatically signalled?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/13/2025 5:58 PM, Lawrence DrCOOliveiro wrote:

On Sat, 13 Sep 2025 10:07:28 -0400, Arne Vajh|+j wrote:

ctx := zmq_ctx_new;
s := zmq_socket(ctx, ZMQ_REQ);
zmq_connect(s, 'tcp://localhost:10000');

Are errors automatically signalled?

No.

It returns an integer with status.

I just didn't test on it.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Sat, 13 Sep 2025 18:43:22 -0400, Arne Vajh|+j wrote:

On 9/13/2025 5:58 PM, Lawrence DrCOOliveiro wrote:

On Sat, 13 Sep 2025 10:07:28 -0400, Arne Vajh|+j wrote:

ctx := zmq_ctx_new;
s := zmq_socket(ctx, ZMQ_REQ);
zmq_connect(s, 'tcp://localhost:10000');

Are errors automatically signalled?

No.

It returns an integer with status.

I just didn't test on it.

Ironic, isnrCOt it? Here we have a platform, one of whose core
distinguishing features is its elaborate, cross-language exception-
handling system, and this library doesnrCOt make any use of it.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/14/2025 2:18 AM, Lawrence DrCOOliveiro wrote:

On Sat, 13 Sep 2025 18:43:22 -0400, Arne Vajh|+j wrote:

On 9/13/2025 5:58 PM, Lawrence DrCOOliveiro wrote:

On Sat, 13 Sep 2025 10:07:28 -0400, Arne Vajh|+j wrote:

ctx := zmq_ctx_new;
s := zmq_socket(ctx, ZMQ_REQ);
zmq_connect(s, 'tcp://localhost:10000');

Are errors automatically signalled?

No.

It returns an integer with status.

I just didn't test on it.

Ironic, isnrCOt it? Here we have a platform, one of whose core
distinguishing features is its elaborate, cross-language exception-
handling system, and this library doesnrCOt make any use of it.

VMS has an elaborate status code system.

But libzmq is a *nix thingy, so no VMS status code.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/13/25 16:11, Arne Vajh|+j wrote:

$ pas s3
$ link/thread s3 + pzmqdir:pzmq + pzmqdir:common + zmq$root:
[lib]libzmq64/lib

/thread is not strictly needed, but without it breaking the
infinite loop with CTRL/Y exits a bit hard.

/THREAD enables upcalls and multiple kernel threads.

The linker was changed to enable Upcalls whenever it sees that threads
are used and no /THREAD was given. In this case the linker prints an informational message.

If you link without /THREAD, do you see the linker message? The shown
"Upcalls are disabled. Multiple kernel threads are disabled" indicates
you did not.

If you do not see the message, then I assume the threaded code is in a shareable image. The linker does not check whether threads are used in shareables. From the shown link command I don't see that a threaded
shareable image is involved.

It would be interesting to know whether /THREAD=UPCALLS is enough to
make this work. I suspect it is.

Do you have any idea where threaded code is used? What is ICTX?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/15/2025 7:14 AM, hb0815 wrote:

On 9/13/25 16:11, Arne Vajh|+j wrote:

$ pas s3
$ link/thread s3 + pzmqdir:pzmq + pzmqdir:common + zmq$root:
[lib]libzmq64/lib

/thread is not strictly needed, but without it breaking the
infinite loop with CTRL/Y exits a bit hard.

/THREAD enables upcalls and multiple kernel threads.

The linker was changed to enable Upcalls whenever it sees that threads
are used and no /THREAD was given. In this case the linker prints an informational message.

If you link without /THREAD, do you see the linker message?

No.

The shown "Upcalls are disabled. Multiple kernel threads are disabled" indicates
you did not.

If you do not see the message, then I assume the threaded code is in a shareable image. The linker does not check whether threads are used in shareables.-a From the shown link command I don't see that a threaded shareable image is involved.

Correct. libzmq64.olb claims to be an "ELF OBJECT library".

It would be interesting to know whether /THREAD=UPCALLS is enough to
make this work. I suspect it is.

It is.

Do you have any idea where threaded code is used?

The only library being used is libzmq, so it must be it.

And the upstream repo confirms that:
https://github.com/zeromq/libzmq/blob/master/src/thread.hpp

What is ICTX?

No idea.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Mon, 15 Sep 2025 20:34:59 -0400, Arne Vajh|+j wrote:

On 9/15/2025 7:14 AM, hb0815 wrote:

Do you have any idea where threaded code is used?

The only library being used is libzmq, so it must be it.

And the upstream repo confirms that:
https://github.com/zeromq/libzmq/blob/master/src/thread.hpp

Threads are unnecessary just to do asynchronous message passing. They
should be used mainly for CPU-intensive tasks.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/16/25 02:34, Arne Vajh|+j wrote:

The only library being used is libzmq, so it must be it.

And the upstream repo confirms that:
-a https://github.com/zeromq/libzmq/blob/master/src/thread.hpp

If there is only an object library then the linker seems to have a
problem to see that threads are used.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/13/2025 6:43 PM, Arne Vajh|+j wrote:

On 9/13/2025 5:58 PM, Lawrence DrCOOliveiro wrote:

On Sat, 13 Sep 2025 10:07:28 -0400, Arne Vajh|+j wrote:

-a-a-a-a ctx := zmq_ctx_new;
-a-a-a-a s := zmq_socket(ctx, ZMQ_REQ);
-a-a-a-a zmq_connect(s, 'tcp://localhost:10000');

Are errors automatically signalled?

No.

It returns an integer with status.

I just didn't test on it.

Note that the detailed error is not in the return value
but in errno.

So I had to add support for that (and had a few issues
along the way, because I messed up a free call).

Instead of:

retval := zmq_connect(s, addr);
if retval <> 0 then begin
writeln('error');
end;

it is now possible to do:

retval := zmq_connect(s, addr);
if retval <> 0 then begin
e := errno;
writeln(strerror(e));
end;

or even:

retval := zmq_connect(s, addr);
if retval <> 0 then begin
e := errno;
if e <> EVMSERR then begin
writeln(strerror(e));
end else begin
e := vmserrno;
writeln(strvmserror(e));
end;
end;

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Thu, 18 Sep 2025 20:21:51 -0400, Arne Vajh|+j wrote:

Instead of:

retval := zmq_connect(s, addr);
if retval <> 0 then begin
writeln('error');
end;

it is now possible to do:

retval := zmq_connect(s, addr);
if retval <> 0 then begin
e := errno; writeln(strerror(e));
end;

or even:

retval := zmq_connect(s, addr);
if retval <> 0 then begin
e := errno;
if e <> EVMSERR then begin
writeln(strerror(e));
end else begin
e := vmserrno; writeln(strvmserror(e));
end;
end;

Does perror(3) take care of this for you?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/18/2025 10:17 PM, Lawrence DrCOOliveiro wrote:

On Thu, 18 Sep 2025 20:21:51 -0400, Arne Vajh|+j wrote:

Instead of:

retval := zmq_connect(s, addr);
if retval <> 0 then begin
writeln('error');
end;

it is now possible to do:

retval := zmq_connect(s, addr);
if retval <> 0 then begin
e := errno; writeln(strerror(e));
end;

or even:

retval := zmq_connect(s, addr);
if retval <> 0 then begin
e := errno;
if e <> EVMSERR then begin
writeln(strerror(e));
end else begin
e := vmserrno; writeln(strvmserror(e));
end;
end;

Does perror(3) take care of this for you?

I do not have any intention of wrap perror - it
is a very specific composite function.

strvmserror calls lib$sys_getmsg.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Fri, 19 Sep 2025 08:26:43 -0400, Arne Vajh|+j wrote:

On 9/18/2025 10:17 PM, Lawrence DrCOOliveiro wrote:

Does perror(3) take care of this for you?

I do not have any intention of wrap perror - it is a very specific
composite function.

Then the problem is that you have to repeat that long sequence of code in every project.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/19/2025 8:35 PM, Lawrence DrCOOliveiro wrote:

On Fri, 19 Sep 2025 08:26:43 -0400, Arne Vajh|+j wrote:

On 9/18/2025 10:17 PM, Lawrence DrCOOliveiro wrote:

Does perror(3) take care of this for you?

I do not have any intention of wrap perror - it is a very specific
composite function.

Then the problem is that you have to repeat that long sequence of code in every project.

If a big application were to use this, then they will have to add
a library function for it or more likely they already have one.

But the implementation will likely be different for different
places.

Target: SYS$OUTPUT, SYS$ERROR, syslog or something else.
Format: single text lines, JSON, XML or something else.
Information: any combination of string argument, errno text,
time, code location, system and maybe a few more.

The chance that a VMS Pascal application will standardize
on perror style (SYS$ERROR, single text line, string argument +
errno text) seems pretty slim to me.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Fri, 19 Sep 2025 21:15:06 -0400, Arne Vajh|+j wrote:

On 9/19/2025 8:35 PM, Lawrence DrCOOliveiro wrote:

Then the problem is that you have to repeat that long sequence of
code in every project.

If a big application were to use this, then they will have to add a
library function for it or more likely they already have one.

But the implementation will likely be different for different
places.

Target: SYS$OUTPUT, SYS$ERROR, syslog or something else.

Errors/diagnostics always go to stderr. Sure, you can explicitly
target syslog, but itrCOs easier nowadays to leave it to the service
manager infrastructure (e.g. systemd) to collect stderr from daemon
processes and save that to the system log. The less special-casing you
have to do to run as a daemon versus non-daemon, the better.

Format: single text lines, JSON, XML or something else.

Simple text lines. TheyrCOre meant to be human-readable, after all.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/19/2025 10:03 PM, Lawrence DrCOOliveiro wrote:

On Fri, 19 Sep 2025 21:15:06 -0400, Arne Vajh|+j wrote:

On 9/19/2025 8:35 PM, Lawrence DrCOOliveiro wrote:

Then the problem is that you have to repeat that long sequence of
code in every project.

If a big application were to use this, then they will have to add a
library function for it or more likely they already have one.

But the implementation will likely be different for different
places.

Target: SYS$OUTPUT, SYS$ERROR, syslog or something else.

Errors/diagnostics always go to stderr. Sure, you can explicitly
target syslog, but itrCOs easier nowadays to leave it to the service
manager infrastructure (e.g. systemd) to collect stderr from daemon
processes and save that to the system log. The less special-casing you
have to do to run as a daemon versus non-daemon, the better.

Format: single text lines, JSON, XML or something else.

Simple text lines. TheyrCOre meant to be human-readable, after all.

You know what you want. Fine.

But realize that other may have other preferences.

To me strerror seems like the right API since it
does not impose any assumptions about log handling.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Sat, 20 Sep 2025 08:46:39 -0400, Arne Vajh|+j wrote:

On 9/19/2025 10:03 PM, Lawrence DrCOOliveiro wrote:

Errors/diagnostics always go to stderr. Sure, you can explicitly
target syslog, but itrCOs easier nowadays to leave it to the service
manager infrastructure (e.g. systemd) to collect stderr from daemon
processes and save that to the system log. The less special-casing
you have to do to run as a daemon versus non-daemon, the better.

Format: single text lines, JSON, XML or something else.

Simple text lines. TheyrCOre meant to be human-readable, after all.

You know what you want. Fine.

But realize that other may have other preferences.

This is not a question of rCLpreferencesrCY. ItrCOs a question of writing
tools that fit nicely into an existing highly productive ecosystem,
and leverage its capabilities. Learn from those who went before you;
their code remains in use for a reason.

To me strerror seems like the right API since it does not impose any assumptions about log handling.

That has its uses, too, for formatting more elaborate messages.
perror(3) is handy for, say, quick-and-dirty code that you plan to
tidy up later. Only you never do, so it stays in use like that for
ever after. And itrCOs still useful enough to not be a complete
embarrassment. ;)
--- Synchronet 3.21a-Linux NewsLink 1.2