Discussion:
%SYSTEM-W-ENDOFFILE, end of file
(too old to reply)
Phillip Helbig (undress to reply)
2017-03-26 08:42:56 UTC
Permalink
Raw Message
I have a procedure which I've been using for years, almost always called
from another procedure which is running in a SPAWNed subprocess. A few
months ago, it started producing

%SYSTEM-W-ENDOFFILE, end of file

messages when an executable processed the corresponding file, and also
the executable doesn't do what it is supposed to do.

Needless to say, I didn't change anything.

If I execute the same procedure interactively, rather than from within
the other procedure, it works as it always has.

Any ideas?

It would be easy to stop the automatic execution from within the other
procedure and fire it up by hand, but I'd like to understand what is
going on.

Unfortunately, it is rather complicated and it would be difficult to
produce a small reproducer. Also, most people probably wouldn't be able
to actually test it because it relies on some external connections etc.

So, the basic question is whether anything could cause the message to
appear in the case of the procedure called from within another (which is
also spawned) but not interactively?
Stephen Hoffman
2017-03-26 17:05:55 UTC
Permalink
Raw Message
Post by Phillip Helbig (undress to reply)
I have a procedure which I've been using for years, almost always
called from another procedure which is running in a SPAWNed subprocess.
A few months ago, it started producing
%SYSTEM-W-ENDOFFILE, end of file
messages when an executable processed the corresponding file, and also
the executable doesn't do what it is supposed to do.
Needless to say, I didn't change anything.
If I execute the same procedure interactively, rather than from within
the other procedure, it works as it always has.
Any ideas?
It would be easy to stop the automatic execution from within the other
procedure and fire it up by hand, but I'd like to understand what is
going on.
Unfortunately, it is rather complicated and it would be difficult to
produce a small reproducer. Also, most people probably wouldn't be
able to actually test it because it relies on some external
connections etc.
So, the basic question is whether anything could cause the message to
appear in the case of the procedure called from within another (which
is also spawned) but not interactively?
Turn on automated application debugging and configure and enable the
blockchain-protected and encrypted distributed application error and
crash logging mechanisms, and re-run the sequence. That'll point
right to the error, and you can then select either "Refactor", "Recode"
or "Resolve" from the IDE GUI, then select "Build" and "Run", and off
you go.

Oh, wait, sorry; that capability doesn't exist on OpenVMS. My bad. πŸ˜‰ ;-)

All admonitions to the contrary, something here has clearly changed.
Something. Either in the application code or in some dependency or in
the local system environment, in the scale or encoding or in the
quantity or contents of the data present, or in the I/O timing or
related details, maybe in process quotas or file sizes or device
timings or whatever. There's more data, or less data, or the data
isn't arriving as expected, or.... something has changed. Instrument
and debug your code.

Caution: Code that's been running for decades does not imply that the
code is bug-free, nor that the code will always be reliable nor
necessarily even stable, for that matter. Older code tends to be
pretty buggy, too β€” I've found more than a few latent errors in old
code through the use of more recent compilers and compiler diagnostics,
too. Code that produces an isolated EOF error β€” without some
additional information or some way to trace the call and the cause β€”
could certainly use some better diagnostics, too.

The DCL command SET WATCH might help isolate the particular executable
or command or call that's failing, but that's far from the best tool to
use in any large and complex environment. Unfortunately, OpenVMS
itself is not very good at allowing a developer to capture these
errors, nor at packaging and producing and reporting diagnostics when
errors do arise. It's certainly possible to add that, but β€” as
apparently happened here β€” that error-detection and error-reporting
code doesn't always get embedded in the applications.

We're either going to need a look at the code or some form or
reproducer or access to the code... Or you're going to have to wade
into this code and debug and/or instrument this, and resolve this....
--
Pure Personal Opinion | HoffmanLabs LLC
Phillip Helbig (undress to reply)
2017-03-26 19:33:20 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Turn on automated application debugging and configure and enable the
blockchain-protected and encrypted distributed application error and
crash logging mechanisms, and re-run the sequence. That'll point
right to the error, and you can then select either "Refactor", "Recode"
or "Resolve" from the IDE GUI, then select "Build" and "Run", and off
you go.
I tried SET VERIFY. :-| The error is coming from the .EXE, though.
Post by Stephen Hoffman
All admonitions to the contrary, something here has clearly changed.
Yes, but not in the code.
Post by Stephen Hoffman
The DCL command SET WATCH might help isolate the particular executable
or command or call that's failing,
I know what the executable is. I even have the source.
Post by Stephen Hoffman
We're either going to need a look at the code or some form or
reproducer or access to the code... Or you're going to have to wade
into this code and debug and/or instrument this, and resolve this....
The source (not written by me) is below. The executable (resulting from
my compile and link of the code) is from 16-DEC-1997 19:04:52.80. It
posts a text file "as is" to an NNTP server.

With VERIFY turned on, the warning (which apparently is actually an
error in the sense that the file is not sent) appears right after the
executable is run. Doing the same interactively (i.e. @ the procedure
with the executable in it) works, but not when that procedure is called
from another one (which is SPAWNed).

#include "netlib_dir:netlibdef.h"
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <stsdef.h>
#include <ssdef.h>
#include <descrip.h>
#include <rms.h>
#include <starlet.h>
#include <lib$routines.h>

#define OK(_rc) $VMS_STATUS_SUCCESS(_rc)
#define INIT_SDESC(_d, _l, _a) {\
(_d).dsc$b_dtype = DSC$K_DTYPE_T; (_d).dsc$b_class = DSC$K_CLASS_S;\
(_d).dsc$w_length = (_l); (_d).dsc$a_pointer = (_a);}
#define RECBUF_SIZE 32771 /* 32K max record length + 3 extra bytes */

static int timeout[2];
static unsigned int read_response(void **, struct dsc$descriptor *,
unsigned short *, int *);

int main (int argc, char *argv[]) {

struct FAB fab;
struct RAB rab;
struct dsc$descriptor dsc;
unsigned short port, buflen;
void *sock;
char *rbuf, buf[1024];
unsigned int status;
int code;
static $DESCRIPTOR(post_cmd, "POST\r\n");
static $DESCRIPTOR(dot, ".\r\n");
static $DESCRIPTOR(quit_cmd, "QUIT\r\n");
static $DESCRIPTOR(tmostr, "0 00:05:00.00");

if (argc < 3) {
printf("usage: POST file-spec host-name [port-number]\n");
return SS$_NORMAL;
}

sys$bintim(&tmostr, timeout);

if (argc > 3) { /* port number specified */
port = atoi(argv[3]);
} else {
port = 119; /* default NNTP port */
}

rbuf = malloc(RECBUF_SIZE);
if (rbuf == 0) {
perror("malloc");
return SS$_NORMAL;
}

fab = cc$rms_fab;
fab.fab$l_fna = argv[1];
fab.fab$b_fns = strlen(argv[1]);
fab.fab$b_fac = FAB$M_GET;

status = sys$open(&fab);
if (!OK(status)) {
free(rbuf);
return status;
}
rab = cc$rms_rab;
rab.rab$l_fab = (void *) &fab;
rab.rab$l_ubf = rbuf + 1;
rab.rab$w_usz = RECBUF_SIZE - 3;
rab.rab$l_rop |= RAB$M_RAH;
status = sys$connect(&rab);
if (!OK(status)) {
sys$close(&fab);
free(rbuf);
return status;
}
INIT_SDESC(dsc, strlen(argv[2]), argv[2]);
status = netlib_socket(&sock);
if (OK(status)) status = netlib_connect_by_name(&sock, &dsc, &port);
if (!OK(status)) {
sys$disconnect(&rab);
sys$close(&fab);
free(rbuf);
return status;
}
INIT_SDESC(dsc, sizeof(buf), buf);

status = read_response(&sock, &dsc, &buflen, &code);
if (!OK(status)) {
netlib_close(&sock);
sys$disconnect(&rab);
sys$close(&fab);
free(rbuf);
return status;
}
if (code != 200) {
printf("Server not accepting posts:\n%.*s\n", buflen, buf);
netlib_close(&sock);
sys$disconnect(&rab);
sys$close(&fab);
free(rbuf);
return 0;
}

status = netlib_write(&sock, &post_cmd);
if (OK(status)) status = read_response(&sock, &dsc, &buflen, &code);

if (OK(status))
if ((code / 100) != 3) status = 0; /* must have a 3xx reply code */

if (!OK(status)) {
if (status == 0)
printf ("POST command error reply:\n%.*s\n", buflen, buf);
netlib_close(&sock);
sys$disconnect(&rab);
sys$close(&fab);
free(rbuf);
return status;
}

while (1) {
unsigned short rlen;
char *bufp;

status = sys$get(&rab);
if (!OK(status)) break;

rlen = rab.rab$w_rsz;
bufp = rbuf + 1;
if (rlen > 0 && *bufp == '.') {
*rbuf = '.';
rlen += 1;
bufp = rbuf;
}
bufp[rlen++] = '\r';
bufp[rlen++] = '\n';
INIT_SDESC(dsc, rlen, bufp);
status = netlib_write(&sock, &dsc);
if (!OK(status)) break;

}

/*
* EOF is normal condition
*/
if (status == RMS$_EOF) {
status = netlib_write(&sock, &dot); /* which should return success */
}

if (OK(status)) {
INIT_SDESC(dsc, sizeof(buf), buf);
status = read_response(&sock, &dsc, &buflen, &code);
if (OK(status)) status = (code / 100) == 2 ? 1 : 0;
if (OK(status)) {
netlib_write(&sock, &quit_cmd);
read_response(&sock, &dsc, &buflen, &code);
}
}

netlib_close(&sock);
sys$disconnect(&rab);
sys$close(&fab);
free(rbuf);

if (status == 0) printf("POST returned error:\n%.*s\n", buflen, buf);
return status;

}

static unsigned int read_response (void **sock, struct dsc$descriptor *dsc,
unsigned short *retlen, int *code) {

unsigned int status;
char *bufp;

bufp = dsc->dsc$a_pointer;
while (1) {

status = netlib_readline(sock, dsc, retlen, 0, timeout);
if (!OK(status)) return status;

if (*retlen < 3) return SS$_PROTOCOL;

if (*retlen > 3 && bufp[3] == '-') continue;

break;

}

lib$cvt_dtb(3, bufp, code);

return SS$_NORMAL;

}
Stephen Hoffman
2017-03-26 22:08:21 UTC
Permalink
Raw Message
Post by Phillip Helbig (undress to reply)
The source (not written by me) is below. The executable (resulting
from my compile and link of the code) is from 16-DEC-1997 19:04:52.80.
It posts a text file "as is" to an NNTP server.
That code is missing some error checks that might point to the trigger.
Post by Phillip Helbig (undress to reply)
With VERIFY turned on, the warning (which apparently is actually an
error in the sense that the file is not sent) appears right after the
with the executable in it) works, but not when that procedure is called
from another one (which is SPAWNed).
All of which interesting, but the debugger will provide the requisite
details here. Or if we're in an earlier era of programming, add
diagnostics to the exit paths as per below.

C on OpenVMS has very poor integration with the platform. Getting
something like netlib reconstituted and updated and integrated with SSL
and certificates would be really handy to have as a standard library,
too. But I digress.

I've added some error handing and diagnostics (entirely untested!) into
the provided code, though a pass or three through the code recompiled
and linked with the debugger will be far more expedient.

There's certainly more room to refactor this code, too.

Whether this is this code, something in netlib, or something else
that's changed here remains unclear.
Post by Phillip Helbig (undress to reply)
#include "netlib_dir:netlibdef.h"
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <stsdef.h>
#include <ssdef.h>
#include <descrip.h>
#include <rms.h>
#include <starlet.h>
#include <lib$routines.h>
#define OK(_rc) $VMS_STATUS_SUCCESS(_rc)
#define INIT_SDESC(_d, _l, _a) {\
(_d).dsc$b_dtype = DSC$K_DTYPE_T; (_d).dsc$b_class = DSC$K_CLASS_S;\
(_d).dsc$w_length = (_l); (_d).dsc$a_pointer = (_a);}
#define RECBUF_SIZE 32771 /* 32K max record length + 3 extra bytes */
static int timeout[2];
static unsigned int read_response(void **, struct dsc$descriptor *,
unsigned short *, int *);
int main (int argc, char *argv[]) {
struct FAB fab;
struct RAB rab;
struct dsc$descriptor dsc;
unsigned short port, buflen;
void *sock;
char *rbuf, buf[1024];
unsigned int status;
int code;
static $DESCRIPTOR(post_cmd, "POST\r\n");
static $DESCRIPTOR(dot, ".\r\n");
static $DESCRIPTOR(quit_cmd, "QUIT\r\n");
static $DESCRIPTOR(tmostr, "0 00:05:00.00");
if (argc < 3) {
printf("usage: POST file-spec host-name [port-number]\n");
return SS$_NORMAL;
}
status = sys$bintim(&tmostr, timeout);
if (!OK(status)) {
perror("sys$bintim");
return status;
}
Post by Phillip Helbig (undress to reply)
if (argc > 3) { /* port number specified */
port = atoi(argv[3]);
} else {
port = 119; /* default NNTP port */
}
// catch bad input to atoi (which returns 0), and a
too-long-input-string for the port is bad, too.

if ( !port ) {
perror("bad port specified");
return status;
}
Post by Phillip Helbig (undress to reply)
rbuf = malloc(RECBUF_SIZE);
if (rbuf == 0) {
perror("malloc");
return SS$_NORMAL;
// Probably best not to exit the app with a successful status on a
buffer allocation error, though there is a diagnostic generated.
Post by Phillip Helbig (undress to reply)
}
fab = cc$rms_fab;
fab.fab$l_fna = argv[1];
fab.fab$b_fns = strlen(argv[1]);
fab.fab$b_fac = FAB$M_GET;
status = sys$open(&fab);
if (!OK(status)) {
perror("sys$open");
Post by Phillip Helbig (undress to reply)
free(rbuf);
return status;
}
rab = cc$rms_rab;
rab.rab$l_fab = (void *) &fab;
rab.rab$l_ubf = rbuf + 1;
rab.rab$w_usz = RECBUF_SIZE - 3;
rab.rab$l_rop |= RAB$M_RAH;
status = sys$connect(&rab);
if (!OK(status)) {
perror("sys$connect");
Post by Phillip Helbig (undress to reply)
sys$close(&fab);
free(rbuf);
return status;
}
INIT_SDESC(dsc, strlen(argv[2]), argv[2]);
status = netlib_socket(&sock);
if (!OK(status)) {
perror("netlib_socket");
sys$disconnect(&rab);
sys$close(&fab);
free(rbuf);
return status;
}
Post by Phillip Helbig (undress to reply)
status = netlib_connect_by_name(&sock, &dsc, &port);
if (!OK(status)) {
perror("netlib_connect_by_name");
Post by Phillip Helbig (undress to reply)
sys$disconnect(&rab);
sys$close(&fab);
free(rbuf);
return status;
}
INIT_SDESC(dsc, sizeof(buf), buf);
status = read_response(&sock, &dsc, &buflen, &code);
if (!OK(status)) {
perror("read_response");
Post by Phillip Helbig (undress to reply)
netlib_close(&sock);
sys$disconnect(&rab);
sys$close(&fab);
free(rbuf);
return status;
}
if (code != 200) {
printf("Server not accepting posts:\n%.*s\n", buflen, buf);
netlib_close(&sock);
sys$disconnect(&rab);
sys$close(&fab);
free(rbuf);
return 0;
}
status = netlib_write(&sock, &post_cmd);
if (!OK(status)) {
perror("netlib_write");
netlib_close(&sock);
sys$disconnect(&rab);
sys$close(&fab);
free(rbuf);
return status;
}
Post by Phillip Helbig (undress to reply)
status = read_response(&sock, &dsc, &buflen, &code);
if (!OK(status)) {
perror("read_response");
netlib_close(&sock);
sys$disconnect(&rab);
sys$close(&fab);
free(rbuf);
return status;
}

if (code / 100) != 3) {
printf ("POST command error reply:\n%.*s\n", buflen, buf);
netlib_close(&sock);
sys$disconnect(&rab);
sys$close(&fab);
free(rbuf);
return status;
}
Post by Phillip Helbig (undress to reply)
while (1) {
unsigned short rlen;
char *bufp;
status = sys$get(&rab);
/*
* EOF is normal condition
*/
if (status == RMS$_EOF) {
status = netlib_write(&sock, &dot); /* which should return success */
break;
}
Post by Phillip Helbig (undress to reply)
if (!OK(status)) break;
rlen = rab.rab$w_rsz;
bufp = rbuf + 1;
if (rlen > 0 && *bufp == '.') {
*rbuf = '.';
rlen += 1;
bufp = rbuf;
}
bufp[rlen++] = '\r';
bufp[rlen++] = '\n';
INIT_SDESC(dsc, rlen, bufp);
status = netlib_write(&sock, &dsc);
if (!OK(status)) break;
}
if (OK(status)) {
INIT_SDESC(dsc, sizeof(buf), buf);
status = read_response(&sock, &dsc, &buflen, &code);
if (!OK(status)) {
netlib_close(&sock);
sys$disconnect(&rab);
sys$close(&fab);
free(rbuf);
}
if ((code / 100) == 2 ) {
printf("POST returned error:\n%.*s\n", buflen, buf);
netlib_write(&sock, &quit_cmd);
read_response(&sock, &dsc, &buflen, &code);
}

netlib_close(&sock);
sys$disconnect(&rab);
sys$close(&fab);
free(rbuf);
return status;
Post by Phillip Helbig (undress to reply)
}
static unsigned int read_response (void **sock, struct dsc$descriptor *dsc,
unsigned short *retlen, int *code) {
unsigned int status;
char *bufp;
bufp = dsc->dsc$a_pointer;
while (1) {
status = netlib_readline(sock, dsc, retlen, 0, timeout);
// I'm assuming that netlib calls return LBS on success!

if (!OK(status)) {
perror("netlib_readline");
return status;
}
Post by Phillip Helbig (undress to reply)
if (*retlen < 3) return SS$_PROTOCOL;
if (*retlen > 3 && bufp[3] == '-') continue;
break;
}
status = lib$cvt_dtb(3, bufp, code);
if (!OK(status )) {
perror("lib$cvt_dtb");
return status;
}
Post by Phillip Helbig (undress to reply)
return SS$_NORMAL;
}
Never assume that "nothing has changed", at least until it's been
verified. Patches, configuration tweaks elsewhere, system parameter
changes, all can contribute to exposing latent bugs...
--
Pure Personal Opinion | HoffmanLabs LLC
Craig A. Berry
2017-03-27 02:56:54 UTC
Permalink
Raw Message
Post by Stephen Hoffman
C on OpenVMS has very poor integration with the platform.
Such as an error tracking mechanism that doesn't actually do anything
when using native services?
Post by Stephen Hoffman
Post by Phillip Helbig (undress to reply)
status = sys$open(&fab);
if (!OK(status)) {
perror("sys$open");
Post by Phillip Helbig (undress to reply)
free(rbuf);
return status;
}
Using perror like this will tell you something failed in the
neighborhood of the call to sys$open (assuming there is only one of
those). But since sys$open won't set errno, popen in this context will
not function as intended, i.e., it won't retrieve a relevant error
message. It may retrieve an entirely irrelevant error message left over
from some prior CRTL call, or it may retrieve none at all. If you want
to report what sys$open didn't like, use sys$getmsg, or lib$signal, but
I know you know how to do that.
Steven Schweda
2017-03-27 04:38:30 UTC
Permalink
Raw Message
[...] since sys$open won't set errno, popen in this context
will not function as intended, i.e., it won't retrieve a
relevant error message. [...]
[I suppose that "popen" here should have been "perror".]

An easy/sleazy way out of this is:

errno = EVMSERR;
vaxc$errno = status;

Typical behavior ("status = sys$setprv( [...])":

ORVL: Set privilege (OPER) failed. sts = %x00000681 .
ORVL: errno = 65535, vaxc$errno = 00000681.
ORVL: not all requested privileges authorized

The "not all requested privileges authorized" message came
from "strerror( errno)". I trust that perror() works the
same. (If you want the whole "%SYSTEM-S-NOTALLPRIV" thing,
then you'll need to work a little harder.)

This technique is probably best reserved for code intended
to run on non-VMS systems. For VMS-only code, I'd probably
use sys$getmsg(). (In this case, the program has only one
such VMS-specific error case, so relying on EVMSERR and
vaxc$errno made more sense to me than dragging in a whole
real-VMS error message routine.)
Craig A. Berry
2017-03-27 12:03:57 UTC
Permalink
Raw Message
Post by Steven Schweda
[...] since sys$open won't set errno, popen in this context
will not function as intended, i.e., it won't retrieve a
relevant error message. [...]
[I suppose that "popen" here should have been "perror".]
Yes, thanks for spotting that.
Post by Steven Schweda
errno = EVMSERR;
vaxc$errno = status;
ORVL: Set privilege (OPER) failed. sts = %x00000681 .
ORVL: errno = 65535, vaxc$errno = 00000681.
ORVL: not all requested privileges authorized
The "not all requested privileges authorized" message came
from "strerror( errno)". I trust that perror() works the
same. (If you want the whole "%SYSTEM-S-NOTALLPRIV" thing,
then you'll need to work a little harder.)
That works, though in principle one should only set errno when
implementing a syscall, and, depending on context, people may or may not
care about such things. I doubt Phillip does.
Post by Steven Schweda
This technique is probably best reserved for code intended
to run on non-VMS systems. For VMS-only code, I'd probably
use sys$getmsg(). (In this case, the program has only one
such VMS-specific error case, so relying on EVMSERR and
vaxc$errno made more sense to me than dragging in a whole
real-VMS error message routine.)
Steven Schweda
2017-03-27 12:43:05 UTC
Permalink
Raw Message
Post by Craig A. Berry
That works, though in principle one should only set errno
when implementing a syscall, [...]
And some might argue that sys$setprv() _is_ a "syscall".
(Based on spelling alone, I'd say that it qualifies.)

According to:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/errno.html

The lvalue errno is used by many functions to return
error values.

I know nothing, but I see no obvious "syscall" restriction
there.
John Reagan
2017-03-27 14:12:34 UTC
Permalink
Raw Message
Post by Steven Schweda
Post by Craig A. Berry
That works, though in principle one should only set errno
when implementing a syscall, [...]
And some might argue that sys$setprv() _is_ a "syscall".
(Based on spelling alone, I'd say that it qualifies.)
http://pubs.opengroup.org/onlinepubs/9699919799/functions/errno.html
The lvalue errno is used by many functions to return
error values.
I know nothing, but I see no obvious "syscall" restriction
there.
That is hardly a requirement on a platform. It is statement about existing practice (bordering on wishful thinking). Used by "many functions"? Which ones?

Since system services can be called from non-C languages (and from non-user mode), decided whether to update errno is a complicated decision (threads make it even more interesting - look at the interaction with errno and TIS in normal user-mode code today). Errno in general is not thread safe or re-entrant and is ugly.
Stephen Hoffman
2017-03-27 17:02:53 UTC
Permalink
Raw Message
Post by John Reagan
That is hardly a requirement on a platform. It is statement about
existing practice (bordering on wishful thinking). Used by "many
functions"? Which ones?
Since system services can be called from non-C languages (and from
non-user mode), decided whether to update errno is a complicated
decision (threads make it even more interesting - look at the
interaction with errno and TIS in normal user-mode code today). Errno
in general is not thread safe or re-entrant and is ugly.
Ayup. Worse.... mucking about with errno and integrating descriptor
support into C and the rest are all really just making the Y2K era even
better.

That including the wonderfully-problematic POSIX-style threading, for
that matter.

Other platforms and tools and approaches are far past these approaches,
and many now or soon offering far better approaches and tools.

Not easy decisions. Never are, of course.
--
Pure Personal Opinion | HoffmanLabs LLC
Steven Schweda
2017-03-27 18:34:10 UTC
Permalink
Raw Message
Post by John Reagan
Errno in general is not thread safe or re-entrant and is
ugly.
I'll give you ugly. It was one of the bad design
decisions in UNIX. Re-entrant is as re-entrant does, but
whose errno is not thread-safe these days? On VMS I see:

inline static int *__CXX_CMA_TIS_ERRNO_GET_ADDR(void) {
return CMA$TIS_ERRNO_GET_ADDR(); }

On the handy Mac, it seems to be:

extern int * __error(void);
#define errno (*__error())

(where I assume that __error() does something useful.)

In this context, setting it is simply a way to fool an
existing error message function, without redesigning all of
UNIX. Some folks around here seem to live on the very edge
of a rant at all times. I couldn't stand the stress.
John Reagan
2017-03-27 19:43:35 UTC
Permalink
Raw Message
Post by Steven Schweda
Post by John Reagan
Errno in general is not thread safe or re-entrant and is
ugly.
I'll give you ugly. It was one of the bad design
decisions in UNIX. Re-entrant is as re-entrant does, but
inline static int *__CXX_CMA_TIS_ERRNO_GET_ADDR(void) {
return CMA$TIS_ERRNO_GET_ADDR(); }
extern int * __error(void);
#define errno (*__error())
(where I assume that __error() does something useful.)
In this context, setting it is simply a way to fool an
existing error message function, without redesigning all of
UNIX. Some folks around here seem to live on the very edge
of a rant at all times. I couldn't stand the stress.
I was musing on the original history of 'errno' as some random static variable that code read/wrote as it felt like.

Yes, with threading, getting the address of 'errno' to write into is more complicated.

I was mostly aiming my reply at people who seemed to want SYS$mumble to update 'errno' since they are syscalls. Finding the right 'errno' to write back into requires knowledge of the caller's thread state, if any. Mix into that VMS's asychronous services and you quickly find that 'errno' wouldn't mean much even if the system service dispatcher decided to copy R0 into 'errno' on your behalf.
David Froble
2017-03-27 20:07:13 UTC
Permalink
Raw Message
Post by John Reagan
Post by Steven Schweda
Post by John Reagan
Errno in general is not thread safe or re-entrant and is
ugly.
I'll give you ugly. It was one of the bad design
decisions in UNIX. Re-entrant is as re-entrant does, but
inline static int *__CXX_CMA_TIS_ERRNO_GET_ADDR(void) {
return CMA$TIS_ERRNO_GET_ADDR(); }
extern int * __error(void);
#define errno (*__error())
(where I assume that __error() does something useful.)
In this context, setting it is simply a way to fool an
existing error message function, without redesigning all of
UNIX. Some folks around here seem to live on the very edge
of a rant at all times. I couldn't stand the stress.
I was musing on the original history of 'errno' as some random static variable that code read/wrote as it felt like.
Yes, with threading, getting the address of 'errno' to write into is more complicated.
I was mostly aiming my reply at people who seemed to want SYS$mumble to update 'errno' since they are syscalls. Finding the right 'errno' to write back into requires knowledge of the caller's thread state, if any. Mix into that VMS's asychronous services and you quickly find that 'errno' wouldn't mean much even if the system service dispatcher decided to copy R0 into 'errno' on your behalf.
Now, I don't go near C, and I don't get out much, and I most likely don't know
what I'm writing about, but, that's never stopped me before, why change now?

The system service routines I've used usually have a parameter for an IOSB, and
return the completion status in the IOSB. Has this gone out of style? Maybe
I'm just too old school?
John Reagan
2017-03-27 20:42:32 UTC
Permalink
Raw Message
Post by David Froble
Post by John Reagan
Post by Steven Schweda
Post by John Reagan
Errno in general is not thread safe or re-entrant and is
ugly.
I'll give you ugly. It was one of the bad design
decisions in UNIX. Re-entrant is as re-entrant does, but
inline static int *__CXX_CMA_TIS_ERRNO_GET_ADDR(void) {
return CMA$TIS_ERRNO_GET_ADDR(); }
extern int * __error(void);
#define errno (*__error())
(where I assume that __error() does something useful.)
In this context, setting it is simply a way to fool an
existing error message function, without redesigning all of
UNIX. Some folks around here seem to live on the very edge
of a rant at all times. I couldn't stand the stress.
I was musing on the original history of 'errno' as some random static variable that code read/wrote as it felt like.
Yes, with threading, getting the address of 'errno' to write into is more complicated.
I was mostly aiming my reply at people who seemed to want SYS$mumble to update 'errno' since they are syscalls. Finding the right 'errno' to write back into requires knowledge of the caller's thread state, if any. Mix into that VMS's asychronous services and you quickly find that 'errno' wouldn't mean much even if the system service dispatcher decided to copy R0 into 'errno' on your behalf.
Now, I don't go near C, and I don't get out much, and I most likely don't know
what I'm writing about, but, that's never stopped me before, why change now?
The system service routines I've used usually have a parameter for an IOSB, and
return the completion status in the IOSB. Has this gone out of style? Maybe
I'm just too old school?
Nobody is changing anything. Opensource code coming to OpenVMS doesn't use IOSB but then again also doesn't call SYS$anything. CRTL calls manipulate 'errno'. Direct OpenVMS calls (system services, LIB$, etc.) do not. I thought the conversation was moving to "why don't they? They are system calls".
David Froble
2017-03-28 01:25:57 UTC
Permalink
Raw Message
Post by John Reagan
Post by David Froble
Post by John Reagan
Post by Steven Schweda
Post by John Reagan
Errno in general is not thread safe or re-entrant and is
ugly.
I'll give you ugly. It was one of the bad design
decisions in UNIX. Re-entrant is as re-entrant does, but
inline static int *__CXX_CMA_TIS_ERRNO_GET_ADDR(void) {
return CMA$TIS_ERRNO_GET_ADDR(); }
extern int * __error(void);
#define errno (*__error())
(where I assume that __error() does something useful.)
In this context, setting it is simply a way to fool an
existing error message function, without redesigning all of
UNIX. Some folks around here seem to live on the very edge
of a rant at all times. I couldn't stand the stress.
I was musing on the original history of 'errno' as some random static variable that code read/wrote as it felt like.
Yes, with threading, getting the address of 'errno' to write into is more complicated.
I was mostly aiming my reply at people who seemed to want SYS$mumble to update 'errno' since they are syscalls. Finding the right 'errno' to write back into requires knowledge of the caller's thread state, if any. Mix into that VMS's asychronous services and you quickly find that 'errno' wouldn't mean much even if the system service dispatcher decided to copy R0 into 'errno' on your behalf.
Now, I don't go near C, and I don't get out much, and I most likely don't know
what I'm writing about, but, that's never stopped me before, why change now?
The system service routines I've used usually have a parameter for an IOSB, and
return the completion status in the IOSB. Has this gone out of style? Maybe
I'm just too old school?
Nobody is changing anything. Opensource code coming to OpenVMS doesn't use IOSB but then again also doesn't call SYS$anything. CRTL calls manipulate 'errno'. Direct OpenVMS calls (system services, LIB$, etc.) do not. I thought the conversation was moving to "why don't they? They are system calls".
Well, yeah, what he wrote ....
Bob Koehler
2017-03-28 15:11:22 UTC
Permalink
Raw Message
Direct OpenVMS calls (system services, LIB$, etc.) do not. I th=
ought the conversation was moving to "why don't they? They are system call=
s".
And if anybody wants to take the conversation that way, the answer
is simple: mostly they're not written in C. And they're not on
UNIX.
Stephen Hoffman
2017-03-27 21:19:32 UTC
Permalink
Raw Message
Post by David Froble
Now, I don't go near C, and I don't get out much, and I most likely
don't know what I'm writing about, but, that's never stopped me before,
why change now?
The system service routines I've used usually have a parameter for an
IOSB, and return the completion status in the IOSB. Has this gone out
of style? Maybe I'm just too old school?
Translating the discussion from C to BASIC or Fortran, the analog would
be a call that properly displays the error message text including the
IOSB information, and which can be embedded in the error-handling logic
following the particular call. That error-reporting code can
certainly be crafted on OpenVMS using sys$getmsg and various
conditionals to drag sys$getmsg into producing the text output of the
associated errors or condition values produced by the call.
(sys$getmsg is more complex than it needs to be, but it's what we
have.) To add code for this error display into C would entail updates
to the compiler around the system service calls, and that's certainly
feasible. This hypothetical implementation gets more difficult with
asynchronous calls, as asynch completions are not something that the
perror call has any clue about, and OpenVMS C was lacking the POSIX aio
calls and libdispatch and related. So the compiler can't (easily)
help there, and the errors β€” and as JR mentions around the current
errno implementation β€” have to be maintained AST-local and
thread-specific to be reliable. Any shared values would otherwise be
unreliable β€” corrupted β€” depending on the timing of other active
threads or ASTs. That, and there are arguably much better ways to do
all of this error reporting for C and for BASIC and the other
languages, and β€” if there are going to be changes requiring source code
changes β€” it's likely better to drag the whole environment much further
forward in few or one larger jump rather than enduring a series of
smaller tweaks each requiring source code changes. OO BASIC would be
pretty interesting, but that's fodder for another day, and a whole lot
more work in the BASIC compiler and system run-time than I expect VSI
to undertake anytime soon.
--
Pure Personal Opinion | HoffmanLabs LLC
David Froble
2017-03-28 01:33:00 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by David Froble
Now, I don't go near C, and I don't get out much, and I most likely
don't know what I'm writing about, but, that's never stopped me
before, why change now?
The system service routines I've used usually have a parameter for an
IOSB, and return the completion status in the IOSB. Has this gone out
of style? Maybe I'm just too old school?
Translating the discussion from C to BASIC or Fortran, the analog would
be a call that properly displays the error message text including the
IOSB information, and which can be embedded in the error-handling logic
following the particular call. That error-reporting code can certainly
be crafted on OpenVMS using sys$getmsg and various conditionals to drag
sys$getmsg into producing the text output of the associated errors or
condition values produced by the call. (sys$getmsg is more complex
than it needs to be, but it's what we have.) To add code for this
error display into C would entail updates to the compiler around the
system service calls, and that's certainly feasible. This
hypothetical implementation gets more difficult with asynchronous calls,
as asynch completions are not something that the perror call has any
clue about, and OpenVMS C was lacking the POSIX aio calls and
libdispatch and related. So the compiler can't (easily) help there,
and the errors β€” and as JR mentions around the current errno
implementation β€” have to be maintained AST-local and thread-specific to
be reliable. Any shared values would otherwise be unreliable β€”
corrupted β€” depending on the timing of other active threads or ASTs.
That, and there are arguably much better ways to do all of this error
reporting for C and for BASIC and the other languages, and β€” if there
are going to be changes requiring source code changes β€” it's likely
better to drag the whole environment much further forward in few or one
larger jump rather than enduring a series of smaller tweaks each
requiring source code changes.
What I think I'm getting from this discussion is that some people want to bring
*ix C code to VMS and just have it work the way it might on *ix. I just have a
rather hard time with that concept. Too much like "cut-n-paste" without knowing
what the code is actually doing.

While I'm not knowledgeable about the VMS CRTL, from reading various threads, I
keep feeling worse about it. Naw, it's probably just me ....
Post by Stephen Hoffman
OO BASIC would be pretty interesting,
but that's fodder for another day, and a whole lot more work in the
BASIC compiler and system run-time than I expect VSI to undertake
anytime soon.
If it ain't broke, then why fix it?

Yeah, I know, Basic at least is 32 bit, not thread or anything else safe, and
sometimes more is needed. But, it sure does the job for lots of people.
Steven Schweda
2017-03-28 02:37:32 UTC
Permalink
Raw Message
Post by David Froble
What I think I'm getting from this discussion is that some
people want to bring *ix C code to VMS and just have it work
the way it might on *ix. [...]
What I think is that too many people around here are too
eager to take any opportunity which might present itself to
reassert the same old lines.

The original code here was said to be mixing some VMS
system service with a CRTL error-message function. Looking
back now, I don't see it, but that was the claim. I supplied
a way to use a CRTL error-message function with a VMS system
service, in case it might be useful. It probably wouldn't be
helpful in the original code, which seems not to have been
doing the kind of mixing which might cause any problems until
it got "fixed" according to some suggestions made here.

Then the usual rants started/resumed. I's tiring.
Craig A. Berry
2017-03-28 02:56:03 UTC
Permalink
Raw Message
Post by Steven Schweda
The original code here was said to be mixing some VMS
system service with a CRTL error-message function. Looking
back now, I don't see it, but that was the claim.
No, it wasn't. It was that the addition of perror() to the original
code did that, where the quoted part is Phillip's original and the
Post by Steven Schweda
status = sys$open(&fab);
if (!OK(status)) {
perror("sys$open");
Stephen Hoffman
2017-03-28 14:17:01 UTC
Permalink
Raw Message
Post by David Froble
Post by Stephen Hoffman
Post by David Froble
Now, I don't go near C, and I don't get out much, and I most likely
don't know what I'm writing about, but, that's never stopped me before,
why change now?
The system service routines I've used usually have a parameter for an
IOSB, and return the completion status in the IOSB. Has this gone out
of style? Maybe I'm just too old school?
Translating the discussion from C to BASIC or Fortran, the analog would
be a call that properly displays the error message text including the
IOSB information, and which can be embedded in the error-handling logic
following the particular call. That error-reporting code can
certainly be crafted on OpenVMS using sys$getmsg and various
conditionals to drag sys$getmsg into producing the text output of the
associated errors or condition values produced by the call.
(sys$getmsg is more complex than it needs to be, but it's what we
have.) To add code for this error display into C would entail updates
to the compiler around the system service calls, and that's certainly
feasible. This hypothetical implementation gets more difficult with
asynchronous calls, as asynch completions are not something that the
perror call has any clue about, and OpenVMS C was lacking the POSIX aio
calls and libdispatch and related. So the compiler can't (easily)
help there, and the errors β€” and as JR mentions around the current
errno implementation β€” have to be maintained AST-local and
thread-specific to be reliable. Any shared values would otherwise be
unreliable β€” corrupted β€” depending on the timing of other active
threads or ASTs. That, and there are arguably much better ways to do
all of this error reporting for C and for BASIC and the other
languages, and β€” if there are going to be changes requiring source code
changes β€” it's likely better to drag the whole environment much further
forward in few or one larger jump rather than enduring a series of
smaller tweaks each requiring source code changes.
What I think I'm getting from this discussion is that some people want
to bring *ix C code to VMS and just have it work the way it might on
*ix. I just have a rather hard time with that concept. Too much like
"cut-n-paste" without knowing what the code is actually doing.
I can't easily show you the difference that these changes would make in
a C program without showing you the differences in the source code.
There'd be less of it. Better integration of the error handling here
would mean less source code. In practical terms, checking both the
IOSB and the return status means more glue code, and β€” if all the
developer wants to do is display a cogent error and exit β€” much more
source code.

Yes, we can get there with our own wrappers, and by writing a couple of
hundred or a couple of thousand lines of source code, or more,
depending on how much work we're willing to do to abstract away the
problems with the C implementation on OpenVMS or the complexity of the
system service APIs. But β€” as is the case with the source code
earlier in this thread β€” that code doesn't always get written or
cut-and-pasted over into the apps.

BASIC avoids some of that, because BASIC β€” unlike C β€” has had
descriptors abstracted into the language. But BASIC still has to deal
with the same mess around return status values and IOSBs and retrieving
error messages. There's a tedious pile of code needed for itemlists,
too. Itemlists were a great idea for upward compatibility and API
stability, but they're a slog that even DEC recognized via the LIB
variants, they're still a serious problem around incompatible changes
(e.g. the password hash), and there are far better and more powerful
and simpler abstractions available now.

Oh, and the "knowing what is going on" in this context is one of those
"turtles all the way down" constructs. We all depend on the
abstractions as a way to avoid dealing with some of the arcana and the
minutiae of application development. That's why most of us aren't
using assembler, or machine code. Each of us is comfortable with the
abstractions we each use. With OpenVMS in general, we're comfortable
with the comparative mountain of source code needed on OpenVMS, and
most of us become inured. We get used to repeating the same
incantations after every call. We get used to the blocks of
conditions. Platforms and languages with better integration reduce or
eliminate much of that code. This so that we can cut-and-paste β€”
either mentally, or from our own libraries of snippets β€” more quickly,
too. We get blind to the glue code, and we discount the frameworks we
depend on, and we often don't see where we could have or use less code.
These efforts are where the vendor β€” VSI in this case β€” can really
make a difference in our code, and in the effort required to program
OpenVMS. These also become cases where we will want to acquire product
upgrades or new servers because the newer release of OpenVMS or of the
particular tools are obviously and fundamentally better. These are
unfortunately cases we haven't seen in a very long time, too.
Post by David Froble
While I'm not knowledgeable about the VMS CRTL, from reading various
threads, I keep feeling worse about it. Naw, it's probably just me ....
The C RTL is a problem, variously because the RTL hasn't been kept up,
because there are bugs in the RTL, and because there are some
fundamental differences between Unix and OpenVMS.
Post by David Froble
Post by Stephen Hoffman
OO BASIC would be pretty interesting, but that's fodder for another
day, and a whole lot more work in the BASIC compiler and system
run-time than I expect VSI to undertake anytime soon.
If it ain't broke, then why fix it?
It's broke. You just don't know it. OpenVMS and its components
haven't moved substantially forward in so long that many of us have
forgotten what it's like to have "gotta have it" new features and
capabilities. If we're not working with and following other platforms
or evolving standards, we can end up in a very comfortable backwater,
too. One where we're just not as efficient and as effective as we can
be, unfortunately.
Post by David Froble
Yeah, I know, Basic at least is 32 bit, not thread or anything else
safe, and sometimes more is needed. But, it sure does the job for lots
of people.
So does assembler. So does machine code. You don't use those,
because you've found BASIC a better fit. Now ponder whether there
might be equivalent gains available either in some newer instantiation
of BASIC, or in some newer language. Some new stuff is trendy or
hyped. Some of the "newer" approaches β€” like DVCS, or .NET-like and
OO implementations with better frameworks β€” can really help write less
code, better code, write and debug and test that code faster, and can
allow better application compatibility.

As is the case here, the easier we make correct code to write in one of
the supported languages, the better the results for all of us. If we
can get simpler error messages out of C or BASIC or whatever, we're all
going to be using those capabilities. If the language has
error-reporting interfaces β€” C does, languages such as BASIC don't have
message catalogs or error reporting and thus use system services β€” the
better off we all are.
--
Pure Personal Opinion | HoffmanLabs LLC
Craig A. Berry
2017-03-28 02:37:29 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by David Froble
Now, I don't go near C, and I don't get out much, and I most likely
don't know what I'm writing about, but, that's never stopped me
before, why change now?
The system service routines I've used usually have a parameter for an
IOSB, and return the completion status in the IOSB. Has this gone out
of style? Maybe I'm just too old school?
Translating the discussion from C to BASIC or Fortran, the analog would
be a call that properly displays the error message text including the
IOSB information, and which can be embedded in the error-handling logic
following the particular call.
VMS BASIC does have the STATUS, RMSSTATUS, and VMSSTATUS keywords. I
guess you still have to look up the error text once you've got the value.
Stephen Hoffman
2017-03-28 14:36:01 UTC
Permalink
Raw Message
Post by Craig A. Berry
Post by Stephen Hoffman
Post by David Froble
Now, I don't go near C, and I don't get out much, and I most likely
don't know what I'm writing about, but, that's never stopped me before,
why change now?
The system service routines I've used usually have a parameter for an
IOSB, and return the completion status in the IOSB. Has this gone out
of style? Maybe I'm just too old school?
Translating the discussion from C to BASIC or Fortran, the analog would
be a call that properly displays the error message text including the
IOSB information, and which can be embedded in the error-handling logic
following the particular call.
VMS BASIC does have the STATUS, RMSSTATUS, and VMSSTATUS keywords. I
guess you still have to look up the error text once you've got the value.
Yeah; though that's still not the IOSB, and that's still just half of
an implementation; one of the most common reasons for futzing with
condition values is to get those vaunted text translations, after all.
Which means that we write the glue code to translate. Or we don't,
and we just β€” as many of us so often do β€” dump some
potentially-undifferentiated is-it-hex-or-is-it-decimal values at the
user or the log file, and "leave it for later". That because we don't
have a way to collect those errors remotely without writing that, and
there's no automated crash collection mechanisms without writing that,
and many of us still think it's reasonable or appropriate or necessary
to dump (decimal? hexadecimal?) codes and stackdumps at the users,
too. Thirty years ago I added some instrumentation and a crash
handler, and discovered the end-user folks were reporting a minuscule
fraction of those application errors, which meant the code was
massively less stable than we'd thought and that the tests were (not)
catching. In some cases the end-users were intentionally triggering
those same errors to work around problems in the navigation that we
didn't even know about. So... yeah... better error handling and
better crash handling and reporting, and better language integration
and less glue code is a win... For everybody.
--
Pure Personal Opinion | HoffmanLabs LLC
David Froble
2017-03-28 18:54:58 UTC
Permalink
Raw Message
Post by Craig A. Berry
Post by Stephen Hoffman
Post by David Froble
Now, I don't go near C, and I don't get out much, and I most likely
don't know what I'm writing about, but, that's never stopped me
before, why change now?
The system service routines I've used usually have a parameter for
an IOSB, and return the completion status in the IOSB. Has this
gone out of style? Maybe I'm just too old school?
Translating the discussion from C to BASIC or Fortran, the analog
would be a call that properly displays the error message text
including the IOSB information, and which can be embedded in the
error-handling logic following the particular call.
VMS BASIC does have the STATUS, RMSSTATUS, and VMSSTATUS keywords. I
guess you still have to look up the error text once you've got the value.
Yeah; though that's still not the IOSB, and that's still just half of an
implementation; one of the most common reasons for futzing with
condition values is to get those vaunted text translations, after all.
Which means that we write the glue code to translate. Or we don't, and
we just β€” as many of us so often do β€” dump some
potentially-undifferentiated is-it-hex-or-is-it-decimal values at the
user or the log file, and "leave it for later". That because we don't
have a way to collect those errors remotely without writing that, and
there's no automated crash collection mechanisms without writing that,
and many of us still think it's reasonable or appropriate or necessary
to dump (decimal? hexadecimal?) codes and stackdumps at the users,
too. Thirty years ago I added some instrumentation and a crash
handler, and discovered the end-user folks were reporting a minuscule
fraction of those application errors, which meant the code was massively
less stable than we'd thought and that the tests were (not) catching.
In some cases the end-users were intentionally triggering those same
errors to work around problems in the navigation that we didn't even
know about. So... yeah... better error handling and better crash
handling and reporting, and better language integration and less glue
code is a win... For everybody.
Ok, gonna be too long, don't read unless it interests you ...

:-)

Ya know, the following isn't all that hard, unless one chooses to re-type it for
every use ....

100 !************************************************************
! Return a VMS error message
!************************************************************
!
SUB VMSERR( LONG E , STRING MSG )
!
! E - Error code
! MSG - VMS error message
!
!************************************************************
!
OPTION SIZE = ( INTEGER WORD , REAL DOUBLE )


EXTERNAL LONG FUNCTION SYS$GETMSG ! External routines

Z$ = SPACE$(80%) ! Build a buffer
CALL SYS$GETMSG( E BY VALUE , , Z$ , 1% BY VALUE , )
MSG = EDIT$(Z$,128%) ! Get VMS message


SUBEND

So, Ok, a library routine, called as needed, sort of like what something like
Python might have ....

One key thing is, if I encounter an error, I can determine what the error is,
and I can then choose what to do about it. Perhaps display on a terminal
screen, perhaps take some pre-defined action, perhaps write to some error log,
etc ....

I'll admit, perhaps I don't understand what Steve's trying to promote. Lot of
that going around anymore. It seems that as age goes up, cognitive ability
decreases ....

For example, in Basic, there is ERR, (a trapped error code), and there is
ERT$(ERR), a language function to return the text of the language error. I'm
not sure how much more you'd want this "hidden" from the programmer?

As for using system services, in their current form I know of only one way to
use them reliably. Yes, item lists can be an issue, but they do work. When
queuing a system service for execution, it's important to me to know if it was
successfully queued, and if not, why not, and have an option of what to do if
not successfully queued. On completion, it's important to me to know the
completion status, if not successful, why not, and have an option of what to do
if unsuccessful. The following code is verbose, to say the least, but I don't
see what could be omitted and still be correct.

Stat% = SYS$QIOW( , ! Event flag &
ListenCh% By Value, ! VMS channel &
IO$_SETCHAR By Value, ! Operation &
IOSB::Stat%, ! I/O status block &
, ! AST routine &
, ! AST parameter &
LISTEN.OPTN::Protocol%, ! P1 &
, ! P2 &
SERVER.ITEMLST::Len%, ! P3 - local socket name &
BACKLOG% By Value, ! P4 - connection back&
SOCKOPT.ITEMLST::Len%, ! P5 - socket options &
) ! P6

If ( Stat% And SS$_NORMAL ) = 0%
Then E$ = FnVMSerr$( Stat% )
Print #KB%, "Unable to queue create and bind listener socket -
"; E$
GoTo 4900
End If

If ( IOSB::Stat% And SS$_NORMAL ) = 0%
Then Stat% = IOSB::Stat%
E$ = FnVMSerr$( Stat% )
Print #KB%, "Unable to create and bind listener socket - "; E$
GoTo 4900
End If

On more than one occasion I've thought about burying the conditional stuff
elsewhere, but have never seen any reasonable way to do so. Anything done to
hide the error handling is going to reduce available options.

It appears that Philip's problem was inadequate handling of errors. Such is
just poor (or worse) programming practices. Is there a lot of that going
around. Seems so. But "not right" is still and always "not right".

Can things be done to make it better? Don't know. Not in anything I can see,
but, perhaps that gets back to "don't get out much" ....
Stephen Hoffman
2017-03-29 13:13:14 UTC
Permalink
Raw Message
Post by David Froble
Post by Stephen Hoffman
Post by Craig A. Berry
Post by Stephen Hoffman
Post by David Froble
Now, I don't go near C, and I don't get out much, and I most likely
don't know what I'm writing about, but, that's never stopped me before,
why change now?
The system service routines I've used usually have a parameter for an
IOSB, and return the completion status in the IOSB. Has this gone out
of style? Maybe I'm just too old school?
Translating the discussion from C to BASIC or Fortran, the analog would
be a call that properly displays the error message text including the
IOSB information, and which can be embedded in the error-handling logic
following the particular call.
VMS BASIC does have the STATUS, RMSSTATUS, and VMSSTATUS keywords. I
guess you still have to look up the error text once you've got the value.
Yeah; though that's still not the IOSB, and that's still just half of
an implementation; one of the most common reasons for futzing with
condition values is to get those vaunted text translations, after all.
Which means that we write the glue code to translate. Or we don't,
and we just β€” as many of us so often do β€” dump some
potentially-undifferentiated is-it-hex-or-is-it-decimal values at the
user or the log file, and "leave it for later". That because we don't
have a way to collect those errors remotely without writing that, and
there's no automated crash collection mechanisms without writing that,
and many of us still think it's reasonable or appropriate or necessary
to dump (decimal? hexadecimal?) codes and stackdumps at the users,
too. Thirty years ago I added some instrumentation and a crash
handler, and discovered the end-user folks were reporting a minuscule
fraction of those application errors, which meant the code was
massively less stable than we'd thought and that the tests were (not)
catching. In some cases the end-users were intentionally triggering
those same errors to work around problems in the navigation that we
didn't even know about. So... yeah... better error handling and
better crash handling and reporting, and better language integration
and less glue code is a win... For everybody.
Ok, gonna be too long, don't read unless it interests you ...
:-)
Ya know, the following isn't all that hard, unless one chooses to
re-type it for every use ....
That works for the base message, but doesn't deal with the parameters
that are commonly associated with the errors. Message signaling is
rather more complex than that code assumes. The code I'm using is a
couple of hundred lines of source code, between dealing with the
differences in system errors, RMS errors, and user messages, and their
respective parameters, and around dealing with signals, and around some
of the related silliness where APIs β€” such as the CLI β€” are
inconsistent about what they do.

It's utterly insane that I need to write and use a couple of hundred
lines of glue code to catch and display system error messages created
with the system message utilities from this operating system, but then
I'm in a polite mood.
--
Pure Personal Opinion | HoffmanLabs LLC
Stephen Hoffman
2017-03-29 14:36:38 UTC
Permalink
Raw Message
Post by David Froble
One key thing is, if I encounter an error, I can determine what the
error is, and I can then choose what to do about it. Perhaps display
on a terminal screen, perhaps take some pre-defined action, perhaps
write to some error log, etc ....
I'll admit, perhaps I don't understand what Steve's trying to promote.
Lot of that going around anymore. It seems that as age goes up,
cognitive ability decreases ....
For example, in Basic, there is ERR, (a trapped error code), and there
is ERT$(ERR), a language function to return the text of the language
error. I'm not sure how much more you'd want this "hidden" from the
programmer?
ERR et al is the BASIC analog of perror and friends over in C.

Okay, error handling on OpenVMS is rather more complex than most folks
recognize. Here's a refresher...

http://h41379.www4.hpe.com/doc/731final/5841/5841pro_025.html#cond_handling_chap


It's a capable and flexible design, too. it's also one that's
somewhat fussy to implement, and most folks tend to get what they need
going β€” translate an error, sans parameters, and most ignore signals
entirely β€” and then ignore the rest. The existing design does feature
what are some incredibly stupid inconsistencies around the formatting
of system errors, RMS errors, and all the rest; of the rest of the
system-provided apps and RTL calls and of user errors using the
standard tools, too.

It's also not at all the implementation I'd choose with newer
environments. It's very much a creature and a design for procedural
programming, and there are OO approaches β€” here's an object with one or
more errors, call (message) some system routine to fetch the localized
text for display or storage or recovery processing or whatever β€” which
both hide the complexity from the programmer, and allow the platform
and the developers to make various changes. But it is what we have,
and it works. (Unwinding errors gets interesting, but that's fodder
for another discussion or three.)

My central gripe here β€” what started off that part of this thread β€” is
that perror doesn't work very well with system service and RTL calls β€”
and that can certainly be addressed in some distant future update to
the tools, but more centrally that there's no flipping API mechanism in
a flipping forty year old operating system that flipping retrieves or
flipping displays the flipping error messages in a flipping useful way
when we're using the flipping system-provided tools and APIs, meaning
we either write the flipping glue code that wraps $getmsg, or we just
ignore the errors and exit β€” as the code posted up-thread tends to do β€”
and all of which is which is a flipping absurd state of affairs.

I'm not even going to get into non-traditional character encodings and
internationalization, as trying to do that on OpenVMS β€” short of using
add-on tools, and basically ignoring what OpenVMS does try to provide
here β€” is a slog.

Then there's that everybody has tended to ignore the original designs
for error messages, so there are "odd" system services, and more than a
little code that makes up and returns its own errors β€” this having just
chased some code that was generating its own SS$_NOPRIV call and
utterly blew the check β€” and all of which all tends to degrade into an
almost inevitable morass of decades-old
legacy-compatibility-don't-worry-be-happy source code. And then I go
work with some error code over on another platform that is just vastly
easier to deal with. Though that too has some issues. Just fewer of
them.
--
Pure Personal Opinion | HoffmanLabs LLC
Craig A. Berry
2017-03-30 02:52:25 UTC
Permalink
Raw Message
Post by Stephen Hoffman
My central gripe here β€” what started off that part of this thread β€” is
that perror doesn't work very well with system service and RTL calls β€”
and that can certainly be addressed in some distant future update to the
tools
I would really not want to see native services start setting errno.
Something that's as easy to use as perror might be nice, though.
Craig A. Berry
2017-03-28 02:28:53 UTC
Permalink
Raw Message
Post by John Reagan
I was mostly aiming my reply at people who seemed to want SYS$mumble
to update 'errno' since they are syscalls.
I'm not sure any such people have appeared in this thread. Hoff provided
sample code using perror() after a sys$open as if such were already the
case, but he knows better. I was just pointing out, lest folks find that
code and copy and paste it thinking it was a good way to do things, that
this doesn't actually work since sys$open doesn't set errno. I'm glad to
hear you're going to keep it that way -- errno is enough of a mess even
when confined to the CRTL.
Stephen Hoffman
2017-03-27 15:29:46 UTC
Permalink
Raw Message
Post by Craig A. Berry
Post by Stephen Hoffman
C on OpenVMS has very poor integration with the platform.
Such as an error tracking mechanism that doesn't actually do anything
when using native services?
One of many issues that's lacking, yes. Another involves the lack of
integrated descriptor support, which leads to more glue code in OpenVMS
C programs. But then OO is the much more recent and much more capable
analog of descriptors. That whole source code module is ripe for
garbage-collected approach, too. On OpenVMS, some refactoring and
judicious exit handlers or gotos would make the error-path code simpler.
Post by Craig A. Berry
...use sys$getmsg...
Which is just hilariously inconsistently designed (among system service
errors and RMS errors and the rest of the morass of errors), and
requires a pile of code to make it function more reasonably. Code
that we all eventually end up writing.
Post by Craig A. Berry
...or lib$signal...
Another great idea with an unfortunately rough implementation, and an
approach that's been re-thought in subsequent iterations on other
platforms, and usually one that's seen a vastly simpler and better
implementation via OO. That call is not particularly nicely
integrated with C signaling, either. And then there's dealing with
the calls that signal errors β€” the CLI calls, for instance β€” and the
stuff that doesn't.

The Microsoft approach used with .NET β€” which in many ways looks to be
the OpenVMS APIs, modernized β€” or Apple used with Objective C works
quite well, and there's certainly still a requirement for current C and
C++ compilers.
--
Pure Personal Opinion | HoffmanLabs LLC
Phillip Helbig (undress to reply)
2017-03-27 20:07:45 UTC
Permalink
Raw Message
Post by Stephen Hoffman
That code is missing some error checks that might point to the trigger.
Post by Phillip Helbig (undress to reply)
With VERIFY turned on, the warning (which apparently is actually an
error in the sense that the file is not sent) appears right after the
with the executable in it) works, but not when that procedure is called
from another one (which is SPAWNed).
All of which interesting, but the debugger will provide the requisite
details here. Or if we're in an earlier era of programming, add
diagnostics to the exit paths as per below.
C on OpenVMS has very poor integration with the platform. Getting
something like netlib reconstituted and updated and integrated with SSL
and certificates would be really handy to have as a standard library,
too. But I digress.
I've added some error handing and diagnostics (entirely untested!) into
the provided code, though a pass or three through the code recompiled
and linked with the debugger will be far more expedient.
Thanks. I'll test it when I can. I'm going into hospital soon and
don't know when I will be ready to look into this.

Another problem has indicated a solution to this problem.

Short answer: it seems to work on

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 7
on a Digital Personal WorkStation running OpenVMS V7.3-2

but not on

HP TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 5
on a COMPAQ Professional Workstation XP1000 running OpenVMS V8.4

Long answer: Why did I notice this? As I mentioned here a while back, I
upgraded to 8.4 on one node but not on the others since after the
upgrade DECwindows stopped working. However, SSL has problems on 7.3-2
so I use that mostly on 8.4. It's a long story, but there are reasons
why I was running that code on the 8.4 node.

Another intermittent problem on a satellite I boot a few times a week is
that sometimes the colours come up strange, as if the graphics card had
a problem. This happpens on perhaps 2 per cent of the boots. Usually
not a problem, just colours a bit strange. However, when running
something like GS when the colours are messed up sometimes causes them
to become even worse. The satellite is 7.3-2 and usually I'm logged
into the 8.4 node in just one DECterm. After running GS, the colours
became worse, and I logged out of that DECterm, and hence ran the
program in another one, on 7.3-2, where it works as always.
Phillip Helbig (undress to reply)
2017-03-27 20:21:43 UTC
Permalink
Raw Message
Post by Phillip Helbig (undress to reply)
Thanks. I'll test it when I can. I'm going into hospital soon and
don't know when I will be ready to look into this.
Another problem has indicated a solution to this problem.
Short answer: it seems to work on
HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 7
on a Digital Personal WorkStation running OpenVMS V7.3-2
but not on
HP TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 5
on a COMPAQ Professional Workstation XP1000 running OpenVMS V8.4
As I mentioned, it posts a text file "as is" to an NNTP server. So, you
need an NNTP server which will let you post without authentication.
(The one I use allows me based on my IP address, which is know to the
server administrator.) The newsgroup alt.test is good for things like
this, but be sure to put "ignore" somewhere in the subject line, since
otherwise people might try to email you to let you know that they saw
the post.

It seems to be related to the VMS version, or something closely related
to that (perhaps the C RTL), or the TCPIP version. My guess is that the
code, though it perhaps could be better, is essentially OK and that
something is wrong on the newer system disk, though of course it might
be more strict, showing bugs in the code which were present but not
noticed before.

Perhaps someone who is familiar with C could find some problem in the
newer VMS/C/TCPIP which might be interesting to others.
Stephen Hoffman
2017-03-27 21:03:25 UTC
Permalink
Raw Message
Post by Phillip Helbig (undress to reply)
Another problem has indicated a solution to this problem.
Short answer: it seems to work on
HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 7
on a Digital Personal WorkStation running OpenVMS V7.3-2
but not on
HP TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 5
on a COMPAQ Professional Workstation XP1000 running OpenVMS V8.4
That's different networking software, different system software,
different SRM versions, and different system and storage hardware.
Which opens up the full gamut of latent errors in the source code,
timing differences, and problems in the underlying software and
hardware.
Post by Phillip Helbig (undress to reply)
Long answer: Why did I notice this? As I mentioned here a while back,
I upgraded to 8.4 on one node but not on the others since after the
upgrade DECwindows stopped working. However, SSL has problems on 7.3-2
so I use that mostly on 8.4. It's a long story, but there are reasons
why I was running that code on the 8.4 node.
Migrate your own data somewhere and back up what you want to preserve,
then wipe the system disks involved, perform a clean install of
OpenVMS, and get everything migrated to OpenVMS Alpha V8.4 with
whatever UPDATE is available and "current" layered products. Older
and established OpenVMS configurations tend to build up cruft, as well
as disk problems and who-knows-what-else. (This is where having system
and user and app profiles help, though those aren't commonly used with
one- or two-box configurations. Having software migration mechanisms
can also help; where a clean install can copy in apps or user-level
customizations, recreating the old environment. These sorts of
enhancements make for easier recoveries and reproducible
configurations, too.)
Post by Phillip Helbig (undress to reply)
Another intermittent problem on a satellite I boot a few times a week
is that sometimes the colours come up strange, as if the graphics card
had a problem. This happpens on perhaps 2 per cent of the boots.
Usually
not a problem, just colours a bit strange. However, when running
something like GS when the colours are messed up sometimes causes them
to become even worse. The satellite is 7.3-2 and usually I'm logged
into the 8.4 node in just one DECterm. After running GS, the colours
became worse, and I logged out of that DECterm, and hence ran the
program in another one, on 7.3-2, where it works as always.
Welcome to old hardware and irreproducible software configurations.
Various Alpha systems have an SRM bus reset knob and I'd enable that as
a test, if it's not already enabled. Swap the graphics controller, the
graphics cable, and see if the problem moves around, too.
--
Pure Personal Opinion | HoffmanLabs LLC
Phillip Helbig (undress to reply)
2017-03-28 04:32:32 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Migrate your own data somewhere and back up what you want to preserve,
then wipe the system disks involved, perform a clean install of
OpenVMS, and get everything migrated to OpenVMS Alpha V8.4 with
whatever UPDATE is available and "current" layered products.
I see the attraction of this. I have an iPad pro (which I use mainly as
a portable PDF reader---it is about the size of a piece of paper---and
mobile internet (often together with an external keyboard) as well as an
eBook reader which has Android under the hood. Updates are simple and
have always worked.

In a cluster, I have cluster-common stuff on a non-system disk.
Defining stuff in SYLOGICALS.COM is easy. Other stuff is more
complicated and involves editing command procedures in SYS$COMMON to
look if a procedure of the same name exists on the non-system disk and
if so execute it and exit rather than executing itself normally. So, a
clean install would mean a lot of extra work. Worth doing, but might
time is limited.

Another approach would be to redefine SYS$SYSROOT to add the non-system
disk between SYS$SPECIFIC and SYS$COMMON. Is this supported? I have
heard of people who have done it, but obviously I would want to test
this first.

The older I get, the faster time passes. It shouldn't be long before I
have VMS on x86, where I'll have to do a clean install anyway, so there
is some attraction in waiting for that.

Whether VSI makes it easier to do a fresh install without wiping
customizations remains to be seen.
Stephen Hoffman
2017-03-28 15:24:34 UTC
Permalink
Raw Message
Post by Phillip Helbig (undress to reply)
Post by Stephen Hoffman
Migrate your own data somewhere and back up what you want to preserve,
then wipe the system disks involved, perform a clean install of
OpenVMS, and get everything migrated to OpenVMS Alpha V8.4 with
whatever UPDATE is available and "current" layered products.
I see the attraction of this. I have an iPad pro (which I use mainly
as a portable PDF reader---it is about the size of a piece of
paper---and mobile internet (often together with an external keyboard)
as well as an eBook reader which has Android under the hood. Updates
are simple and have always worked.
Both with iOS and macOS, a reinstall can restore customizations and
restore files, too. The installations and the upgrades and the
migrations can restore end-user files and application bundles from the
user's backups, as part of the whole operation. It's vastly easier
than what's involved with similar sequences in OpenVMS. Installing
Server.app on macOS is a real surprise too, around what's possible, and
around what sorts of management interfaces and tools are available now
and that will become more common on other platforms. If you want to
know what's possible and where other folks and vendors and products are
headed, the more you look around, the better...

In the specific case of OpenVMS, old cruft tends to build up in the
system directories. Customizations. Old work-arounds, too. Even
the occasional upgrade-related bug, though those tend to be rare.
Post by Phillip Helbig (undress to reply)
In a cluster, I have cluster-common stuff on a non-system disk.
Common. More than a little of that should be out in LDAP, but what we
have with OpenVMS and clustering and text files and logical names is
what we have.
Post by Phillip Helbig (undress to reply)
Defining stuff in SYLOGICALS.COM is easy.
It's certainly obvious, once you're accustomed to command line work, of
finding the appropriate file, and coordinating that file across hosts
and system disks in a cluster.

The addition of that "new" and somewhat oddly-named shutdown file was
helpful for some of the related processing, too.

This file-based approach is also rather tedious, clunky, awkward,
somewhat of a pain and variously fussy, and adding and adding and
removing changes in any sort of a modular fashion is messy at best.
(That was tried with SYSMAN and VMSINSTAL, but dealing with the
sequencing and dependencies largely killed that effort. Containers
have similar issues in these and other areas of the configuration and
startup processing, and particularly need modularity and easier
automation.)

It doesn't productize at all well, and there's no in-built mechanism
for sequencing it.
Post by Phillip Helbig (undress to reply)
Other stuff is more complicated and involves editing command procedures
in SYS$COMMON to look if a procedure of the same name exists on the
non-system disk and if so execute it and exit rather than executing
itself normally. So, a clean install would mean a lot of extra work.
Worth doing, but might time is limited.
Chasing these sorts of bugs usually takes longer. OpenVMS is more
effort to reconstitute, which tends to make folks reticent around
re-installations.
Post by Phillip Helbig (undress to reply)
Another approach would be to redefine SYS$SYSROOT to add the non-system
disk between SYS$SPECIFIC and SYS$COMMON. Is this supported?
Nope.
Post by Phillip Helbig (undress to reply)
I have heard of people who have done it, but obviously I would want to
test this first.
I've seen it work, and I've also seen some software installs and
upgrades get confused in those environments.
Post by Phillip Helbig (undress to reply)
The older I get, the faster time passes. It shouldn't be long before I
have VMS on x86, where I'll have to do a clean install anyway, so there
is some attraction in waiting for that.
You're also probably depending on that so that you can avoid the effort
involved in learning a different and newer (and variously easier)
platform, too. We all have those sorts of areas where we do that, too.
Post by Phillip Helbig (undress to reply)
Whether VSI makes it easier to do a fresh install without wiping
customizations remains to be seen.
I doubt they will. It's not a headline feature, and they're too busy
with more important projects. Unfortunately their competitors are
spending time in this and other areas.
--
Pure Personal Opinion | HoffmanLabs LLC
Phillip Helbig (undress to reply)
2017-03-28 18:36:13 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by Phillip Helbig (undress to reply)
The older I get, the faster time passes. It shouldn't be long before I
have VMS on x86, where I'll have to do a clean install anyway, so there
is some attraction in waiting for that.
You're also probably depending on that so that you can avoid the effort
involved in learning a different and newer (and variously easier)
platform, too. We all have those sorts of areas where we do that, too.
Life is short. One has to choose priorities. Still, I wouldn't mind
moving off of VMS to something which is better. An absolute minimum
would be: built-in multi-version file system, clustering at least as
good as that of VMS in all respects, decent compilers, multiple users,
CLI. That's not asking much. Sure, some or maybe all of the same
functionality could be achieved in other ways. Any Turing machine can
emulate another one, but that doesn't mean that all are equally
convenient or useful.
David Froble
2017-03-28 21:34:49 UTC
Permalink
Raw Message
Post by Phillip Helbig (undress to reply)
Post by Stephen Hoffman
Post by Phillip Helbig (undress to reply)
The older I get, the faster time passes.
Yeah, and at some point it passes too quickly for life to exist ....

:-)
Post by Phillip Helbig (undress to reply)
Post by Stephen Hoffman
Post by Phillip Helbig (undress to reply)
It shouldn't be long before I
have VMS on x86, where I'll have to do a clean install anyway, so there
is some attraction in waiting for that.
You're also probably depending on that so that you can avoid the effort
involved in learning a different and newer (and variously easier)
platform, too. We all have those sorts of areas where we do that, too.
Life is short. One has to choose priorities. Still, I wouldn't mind
moving off of VMS to something which is better.
From past posts, I'm not sure what you'd be looking for. While the terms may
be arbitrary, do you want a "server" or a "user interface / client / etc"?

I think we all have to admit, VMS is not so good for the latter option. One can
flog DECwindows and whatever it may run, but, it's not near to what's now available.
Post by Phillip Helbig (undress to reply)
An absolute minimum
would be: built-in multi-version file system, clustering at least as
good as that of VMS in all respects, decent compilers, multiple users,
CLI. That's not asking much. Sure, some or maybe all of the same
functionality could be achieved in other ways. Any Turing machine can
emulate another one, but that doesn't mean that all are equally
convenient or useful.
Phillip Helbig (undress to reply)
2017-03-28 21:56:48 UTC
Permalink
Raw Message
Post by David Froble
From past posts, I'm not sure what you'd be looking for. While the
terms may be arbitrary, do you want a "server" or a "user interface /
client / etc"?
Desktop to datacenter! :-)
Post by David Froble
I think we all have to admit, VMS is not so good for the latter option.
One can flog DECwindows and whatever it may run, but, it's not near to
what's now available.
I just spent a couple of hours writing something in LaTeX (developed
mainly on VMS, by the way), generating some PostScript and PDF files
from the .tex file, viewing them on-screen, transferring them to a
remote system, emailing them, etc. I'm logged in at a graphics terminal
with CDE (and typing this in a DECterm).

I haven't yet encountered another system where I can do these things as
comfortably.
Post by David Froble
Post by Phillip Helbig (undress to reply)
An absolute minimum
would be: built-in multi-version file system, clustering at least as
good as that of VMS in all respects, decent compilers, multiple users,
CLI. That's not asking much. Sure, some or maybe all of the same
functionality could be achieved in other ways. Any Turing machine can
emulate another one, but that doesn't mean that all are equally
convenient or useful.
Simon Clubley
2017-03-28 22:59:02 UTC
Permalink
Raw Message
Post by Phillip Helbig (undress to reply)
Post by David Froble
I think we all have to admit, VMS is not so good for the latter option.
One can flog DECwindows and whatever it may run, but, it's not near to
what's now available.
I just spent a couple of hours writing something in LaTeX (developed
mainly on VMS, by the way), generating some PostScript and PDF files
from the .tex file, viewing them on-screen, transferring them to a
remote system, emailing them, etc. I'm logged in at a graphics terminal
with CDE (and typing this in a DECterm).
I haven't yet encountered another system where I can do these things as
comfortably.
The above requirements can be met by a GUI Linux system with a CLI
toolchain under bash inside a decent terminal emulator so you can
use one of the editors in EDT keypad mode and run multiple terminal
sessions in the GUI environment.

Make sure you don't use one of the overbearing desktop environments
that thinks it knows better than you do; pick a window manager and
desktop environment that stays out of the way. I have no recommendations
unfortunately as this kind of thing is a personal thing so you will
have to find out what works for you.

There's a _wide_ variety of email clients for you to choose from
under Linux as well, ranging from various character cell clients
to various GUI clients.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Phillip Helbig (undress to reply)
2017-03-29 04:59:00 UTC
Permalink
Raw Message
Post by Simon Clubley
The above requirements can be met by a GUI Linux system with a CLI
toolchain under bash inside a decent terminal emulator so you can
use one of the editors in EDT keypad mode and run multiple terminal
sessions in the GUI environment.
Built-in file versions? (This is even more important when developing
code.)
Post by Simon Clubley
There's a _wide_ variety of email clients for you to choose from
under Linux as well, ranging from various character cell clients
to various GUI clients.
Most allow SORTING on one (or more) keys. OK, I haven't looked that
much, but I haven't found one which allows one to show only those emails
corresponding to certain criteria (/SINCE/FROM/SUBJECT).

Of course, if I move everything off of VMS, it has to be better; just as
good means all the effort but no real advantage.
Simon Clubley
2017-03-29 23:38:50 UTC
Permalink
Raw Message
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
The above requirements can be met by a GUI Linux system with a CLI
toolchain under bash inside a decent terminal emulator so you can
use one of the editors in EDT keypad mode and run multiple terminal
sessions in the GUI environment.
Built-in file versions? (This is even more important when developing
code.)
It sounds to me like what you really need is a version control system,
either something like subversion or one of the later alternatives.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Bob Koehler
2017-03-30 14:13:02 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
The above requirements can be met by a GUI Linux system with a CLI
toolchain under bash inside a decent terminal emulator so you can
use one of the editors in EDT keypad mode and run multiple terminal
sessions in the GUI environment.
Built-in file versions? (This is even more important when developing
code.)
It sounds to me like what you really need is a version control system,
either something like subversion or one of the later alternatives.
Version control systems require ation on the part of the user to
save versions that the user thinks are worth saving. File version
numbers don't.
Simon Clubley
2017-03-30 17:34:58 UTC
Permalink
Raw Message
Post by Bob Koehler
Post by Simon Clubley
It sounds to me like what you really need is a version control system,
either something like subversion or one of the later alternatives.
Version control systems require ation on the part of the user to
save versions that the user thinks are worth saving. File version
numbers don't.
File versioning works when all your source code and other data is in
one physical file only. It doesn't work when you have multiple physical
files in your project and you need to easily see how your project
looked as a whole at a specific point in time.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Paul Sture
2017-03-31 18:30:22 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by Bob Koehler
Post by Simon Clubley
It sounds to me like what you really need is a version control system,
either something like subversion or one of the later alternatives.
Version control systems require ation on the part of the user to
save versions that the user thinks are worth saving. File version
numbers don't.
File versioning works when all your source code and other data is in
one physical file only. It doesn't work when you have multiple physical
files in your project and you need to easily see how your project
looked as a whole at a specific point in time.
With a tool like BBEdit, which supports git, you can have the best of
both worlds.

Note for existing TextWrangler users:

TextWrangler (free) is being retired, but BBEdit can now run
unlicensed, with restricted ability after 30 days.

<http://www.barebones.com/products/textwrangler/>

Differences between unlicensed BBEdit and TextWrangler:

<http://www.barebones.com/products/bbedit/comparison.html#free-comparison>

Full BBEdit / Unlicensed BBEdit / TextWrangle comparison chart:

<http://www.barebones.com/products/bbedit/comparison.html>
--
A supercomputer is a device for turning compute-bound problems into
I/O-bound problems. ---Ken Batcher
Paul Sture
2017-03-31 18:24:39 UTC
Permalink
Raw Message
Post by Bob Koehler
Post by Simon Clubley
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
The above requirements can be met by a GUI Linux system with a CLI
toolchain under bash inside a decent terminal emulator so you can
use one of the editors in EDT keypad mode and run multiple terminal
sessions in the GUI environment.
Built-in file versions? (This is even more important when developing
code.)
It sounds to me like what you really need is a version control system,
either something like subversion or one of the later alternatives.
Version control systems require ation on the part of the user to
save versions that the user thinks are worth saving. File version
numbers don't.
True. BBEdit and TextWrangler on macOS offer a limited form of
individual file versioning, though this isn't enabled out of the box.

Preferences -> Text files, with the following options:

x Make backup before saving
x Keep historical backups
x Preserve file name extension


The backups reside in '~/Documents/BBEdit backups' and
'/Documents/TextWrangler Backups' respectively, with one subdirectory
per day. E.g. the following snippet contains the edits for
readlog.py

β”œβ”€β”€ 2017-03-23
β”‚Β Β  β”œβ”€β”€ readlog\ (2017-03-23\ 12-42-53-850).py
β”‚Β Β  β”œβ”€β”€ readlog\ (2017-03-23\ 12-43-14-775).py
β”‚Β Β  β”œβ”€β”€ readlog\ (2017-03-23\ 12-43-30-757).py
β”‚Β Β  β”œβ”€β”€ readlog\ (2017-03-23\ 12-46-59-031).py
β”‚Β Β  └── readlog\ (2017-03-23\ 12-47-20-903).py
└── 2017-03-27
└── #init#.sls

Note that this doesn't track the original directories; when editing
files of the same name in different locations, care is needed. Searching
these directory trees by content usually gets you where you want to be.
--
A supercomputer is a device for turning compute-bound problems into
I/O-bound problems. ---Ken Batcher
Stephen Hoffman
2017-03-29 15:12:26 UTC
Permalink
Raw Message
Post by Phillip Helbig (undress to reply)
I just spent a couple of hours writing something in LaTeX (developed
mainly on VMS, by the way), generating some PostScript and PDF files
from the .tex file, viewing them on-screen, transferring them to a
remote system, emailing them, etc. I'm logged in at a graphics
terminal with CDE (and typing this in a DECterm).
macOS and Linux have those tool chains available. dvipdf, texi2dvi
and some other tools, an available TeX (MacTeX) installation kit, and
TeXShop or maybe BBEdit if you want or need GUI tools, syntax
highlighting or such.

Scrivener is a very powerful writing tool, and has support for TeX and
LaTeX formats and processing, directly or via MultiMarkdown.
Scrivener is available on both Windows and macOS.

https://www.tug.org/mactex/
http://www.texshop.org
http://literatureandlatte.com/scrivener.php
https://itunes.apple.com/us/app/texpad-latex-editor/id458866234?mt=12
etc....

iWork Pages just recently sprouted a somewhat-limited ability to accept
TeX formatting for displays, though I've not tried that. That's
intended for embedded typesetting formula and suchlike, with the rest
of the document using Pages native format.
Post by Phillip Helbig (undress to reply)
I haven't yet encountered another system where I can do these things as
comfortably.
I'm not so sure yours is the easier approach, but it's certainly one
that's more comfortable and familiar for you. Which has value.

The hobbyist OpenVMS licensing does wildly distort any discussions of
pricing, too.
--
Pure Personal Opinion | HoffmanLabs LLC
Paul Sture
2017-03-31 18:10:41 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by Phillip Helbig (undress to reply)
I just spent a couple of hours writing something in LaTeX (developed
mainly on VMS, by the way), generating some PostScript and PDF files
from the .tex file, viewing them on-screen, transferring them to a
remote system, emailing them, etc. I'm logged in at a graphics
terminal with CDE (and typing this in a DECterm).
macOS and Linux have those tool chains available. dvipdf, texi2dvi
and some other tools, an available TeX (MacTeX) installation kit, and
TeXShop or maybe BBEdit if you want or need GUI tools, syntax
highlighting or such.
Scrivener is a very powerful writing tool, and has support for TeX and
LaTeX formats and processing, directly or via MultiMarkdown.
Scrivener is available on both Windows and macOS.
https://www.tug.org/mactex/
http://www.texshop.org
http://literatureandlatte.com/scrivener.php
https://itunes.apple.com/us/app/texpad-latex-editor/id458866234?mt=12
etc....
There are also iPad and iPhone versions of Scrivener, with the ability
to sync work with the desktop versions. Note from the Scrivener manual

Important Note: This feature is not intended for keeping two
versions of the same project in sync and should not be used in such
a mannerβ€”you should never try to sync two different projects with
the same folder. Rather, this feature is intended to allow you to
edit or share project files with other applications or on other
plat-forms, and then to have any changes made to the shared files
reflected in your Scrivener project. It also cannot be used to
perform structural or outline order modifications, just simple text
content modifications.
--
A supercomputer is a device for turning compute-bound problems into
I/O-bound problems. ---Ken Batcher
Simon Clubley
2017-03-28 12:14:18 UTC
Permalink
Raw Message
Post by Phillip Helbig (undress to reply)
Thanks. I'll test it when I can. I'm going into hospital soon and
don't know when I will be ready to look into this.
I don't know why you are going into hospital but I wish you well
and hope everything turns out ok for you.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Richard Maher
2017-03-28 12:37:56 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by Phillip Helbig (undress to reply)
Thanks. I'll test it when I can. I'm going into hospital soon and
don't know when I will be ready to look into this.
I don't know why you are going into hospital but I wish you well
and hope everything turns out ok for you.
Simon.
Gender realignment is a relatively straight forward operation in
Switzerland these days and covered under Obamacare.
David Froble
2017-03-28 13:08:58 UTC
Permalink
Raw Message
Post by Richard Maher
On 2017-03-27, Phillip Helbig (undress to reply)
Post by Phillip Helbig (undress to reply)
Thanks. I'll test it when I can. I'm going into hospital soon and
don't know when I will be ready to look into this.
I don't know why you are going into hospital but I wish you well
and hope everything turns out ok for you.
Simon.
Gender realignment is a relatively straight forward operation in
Switzerland these days and covered under Obamacare.
As I sit here, looking out at overcast, rain, and generally gloomy, I can still
laugh. Thank you Richard ....

:-)
Phillip Helbig (undress to reply)
2017-03-28 18:25:31 UTC
Permalink
Raw Message
Post by Richard Maher
Post by Simon Clubley
Post by Phillip Helbig (undress to reply)
Thanks. I'll test it when I can. I'm going into hospital soon and
don't know when I will be ready to look into this.
I don't know why you are going into hospital but I wish you well
and hope everything turns out ok for you.
Simon.
Gender realignment is a relatively straight forward operation in
Switzerland these days and covered under Obamacare.
???

Who pissed in your cornflakes?
m***@googlemail.com
2017-03-29 02:27:40 UTC
Permalink
Raw Message
In article <obdlfb$19st$1>, Richard Maher
Post by Richard Maher
Gender realignment is a relatively straight forward operation in
Switzerland these days and covered under Obamacare.
???
Who pissed in your cornflakes?
C'mon Phillippa, your sense of humour has become Swiss over the years :-( You know the more I abuse you the more I like you?

Good luck with the prostate and remember that having it out means you'll have to stop asking to be tested!
Hein RMS van den Heuvel
2017-03-29 03:26:30 UTC
Permalink
Raw Message
On Wednesday, March 29, 2017 at 2:25:32 AM UTC+8, Phillip Helbig (undress t> > Who pissed in your cornflakes?
Good one Phillip!

Haven't been here in a while.
Nothing much has changed it seems.
Same players, same prayers.
Any topic is still good for a language war no matter how irrelevant.

Anyway...

Firstly, Phillip best of luck with the medical stuff.

Next, all the way back to the top:
%SYSTEM-W-ENDOFFILE, end of file
That's odd! Well, just a little bit even: It is a WARNING (98936 = %x018278)
Normal is more even: an ERROR = RMS$_EOF = 98938 Hex = 0001827A

John R was the first to pick up on that, but I did not see it pursued?

Hoff made a valid, value-able suggestion to use SET WATCH FILE/CLA=ALL
Seems this was dismissed without trying ?!
If John is right, SET WATCH would likely prove it.

Is the error triggered by particular input file attributes?

I don't expect it is anything to do with the file being read, but on the off-chance it might I would encourage to hook up an XABFHC and print out XAB$L_EBK * 512 + XAB$W_FFB right after the open.
It wouldn't surprise me if this is NOT printed in the failure case.
For deluxe debugging save (RAB$L_RAF0*512 + RAB$W_RFA4) in the loop before the get and print on exit to see what the position of the last record read was.

Good luck!
Hein
hb
2017-03-29 09:35:06 UTC
Permalink
Raw Message
Post by Phillip Helbig (undress to reply)
%SYSTEM-W-ENDOFFILE, end of file
That's odd! Well, just a little bit even: It is a WARNING (98936 = %x018278)
Normal is more even: an ERROR = RMS$_EOF = 98938 Hex = 0001827A
Yes, it is a warning
$ exit 2160
%SYSTEM-W-ENDOFFILE, end of file
$
Post by Phillip Helbig (undress to reply)
John R was the first to pick up on that, but I did not see it pursued?
As John pointed out, the image activator prints this warning as a
secondary message: "-" no "%". If the original quote is correct, it is
not related to image activation.
Phillip Helbig (undress to reply)
2017-03-29 05:00:16 UTC
Permalink
Raw Message
Post by m***@googlemail.com
In article <obdlfb$19st$1>, Richard Maher
Post by Richard Maher
Gender realignment is a relatively straight forward operation in
Switzerland these days and covered under Obamacare.
???
Who pissed in your cornflakes?
C'mon Phillippa, your sense of humour has become Swiss over the years
:-( You know the more I abuse you the more I like you?
I think you're confusing me with someone else.
Post by m***@googlemail.com
Good luck with the prostate and remember that having it out means
you'll have to stop asking to be tested!
Actually, the goal is to keep it in---and keep it up :-) This treatment
should kill just the cancerous cells, leaving the rest intact.
Richard Maher
2017-03-29 10:58:24 UTC
Permalink
Raw Message
Post by Phillip Helbig (undress to reply)
Post by m***@googlemail.com
In article <obdlfb$19st$1>, Richard Maher
Post by Richard Maher
Gender realignment is a relatively straight forward operation in
Switzerland these days and covered under Obamacare.
???
Who pissed in your cornflakes?
C'mon Phillippa, your sense of humour has become Swiss over the years
:-( You know the more I abuse you the more I like you?
I think you're confusing me with someone else.
Post by m***@googlemail.com
Good luck with the prostate and remember that having it out means
you'll have to stop asking to be tested!
Actually, the goal is to keep it in---and keep it up :-) This treatment
should kill just the cancerous cells, leaving the rest intact.
No I'm thinking of you but alzheimer's has me remembering Credit
Suisse and Zurich instead of DB and Prussia. (First time I saw your
photo today though. Never knew you were a ranga. Maybe they can fix that
while you're in for the plumbing :-)

Hope all goes well and you get to remain intact!
Phillip Helbig (undress to reply)
2017-03-29 19:39:00 UTC
Permalink
Raw Message
Post by Richard Maher
No I'm thinking of you but alzheimer's has me remembering Credit
Suisse and Zurich instead of DB and Prussia. (First time I saw your
photo today though. Never knew you were a ranga. Maybe they can fix that
while you're in for the plumbing :-)
Not sure what a ranga is but due to previous chemotherapy my appearance
has changed somewhat. Both old and new pictures are available. :-|
Post by Richard Maher
Hope all goes well and you get to remain intact!
Thanks!
Phillip Helbig (undress to reply)
2017-03-28 18:00:35 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by Phillip Helbig (undress to reply)
Thanks. I'll test it when I can. I'm going into hospital soon and
don't know when I will be ready to look into this.
I don't know why you are going into hospital but I wish you well
and hope everything turns out ok for you.
Thanks.

It's actually something which will affect a majority of the readership
here: prostate cancer. Mine is "low-risk" and was detected early
(solely because I voluntarily had various tests done; I still have no
symptoms even though I've had it for several years now). I've decided
for a focal treatment with HIFU---look it up. Ultrasound has been used
for a long time to destroy the prostate, usually on patients where for
various reasons an operation is not an option. However, a couple of
years ago a new apparatus called Focal One was developed, which allows
focussing on an area only a few square millimetres or so in size. The
idea is to destroy only the diseased tissue. Side effects should be
much less of a problem than with any other treatment. In contrast to
many other treatments, having this treatment doesn't reduce other
options: I can have it again, or any other treatment. Often, one tries
something (usually with massive side effects) and if it works, OK, but
if not, then it is difficult to do anything else.

Most men die with prostate cancer, but not of prostate cancer. Most who
have it do not know that they have it. In many cases, treatment is not
necessary. But if it does flare up, by the time one has symptoms it is
often too late for any curative treatment, and certainly too late for
almost side-effect--free treatment. Thus, the idea is to wait as long
as possible---but not longer. My PSA value had been increasing steadily
for a few years, then several months ago the slope greatly increased,
leading to the decision to have some treatment.

Three things distinguish it from other cancers. First, it often needs
no treatment at all. Second, most treatment has long-term side effects.
Third, recommendations vary quite a bit---even if the physician knows
the details of the cancer and knows what the patient wants. Thus,
catching it early is even more important than with other cancers,
because the decision-making process can be long.

If it were only the long-term side effects, then, sure, treat it---if
the alternative is death. But in most cases it never needs to be
treated. If it were only the fact that it often never needs treatment,
treat it---and have no worries. But then there are the side effects.
One doesn't want to treat it, have serious long-term side effects, and
know that the treatment probably wasn't even necessary. Thus the reason
why I've waited for years. In retrospect it was good to wait, and I was
lucky that I could, because this new apparatus has only been on the
market for a couple of years. But waiting too long could be fatal. In
my case, I know that there has been some change and it is becoming
dangerous, so now is the time. (Some recommended that I have something
done years ago; some claim that still nothing is necessary. I hope that
I've picked the right moment.)

I've had much worse cancer twice before, which is now gone thanks to
chemotherapy, so I'm optimistic.

There is much debate about whether monitoring the PSA is worth the
trouble. If you would rather die sooner than try to treat the disease
then, sure, don't measure the PSA value. Assuming this is not the case,
the debate centers on whether it is "worth the trouble". The question
is, worth the trouble to whom? To the patient? To the hospitals? To
medical research? To health insurance? To society? My view is that
more knowledge is better than less knowledge; I can still decide what to
do with that knowledge.

One often reads that screening produces many false positives---it
does---and that as a result too many unnecessary biopsies are performed.
Several problems with this statement. First, even if the biopsy turns
out negative, the patient knows that he doesn't have cancer, which is an
advantage. Second, a biopsy sounds worse than it is. I've had two, one
with 14 samples and one with 58. Didn't notice much difference and both
cases were just a night in hospital. Third, even if just one life is
saved, this is a small price to pay---especially if it is your life.
Fourth, anyone who says "your PSA is high, you need a biopsy" is a
quack. Measure it again in three months, under the same conditions and
in the same lab. A biopsy makes sense only if the value is high---and
stays high---and/or is increasing rapidly. In either case, there might
be another cause, but a biopsy is needed to see if it is cancer or not.
MRI can be very useful (for seeing how things change and also for taking
more samples where the tumor is) but by itself can't be used for
diagnosis. If you have no symptoms, you can measure three times over
half a year and see how it changes.
Simon Clubley
2017-03-28 18:20:21 UTC
Permalink
Raw Message
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
Post by Phillip Helbig (undress to reply)
Thanks. I'll test it when I can. I'm going into hospital soon and
don't know when I will be ready to look into this.
I don't know why you are going into hospital but I wish you well
and hope everything turns out ok for you.
Thanks.
It's actually something which will affect a majority of the readership
here: prostate cancer. Mine is "low-risk" and was detected early
(solely because I voluntarily had various tests done; I still have no
symptoms even though I've had it for several years now).
I sincerely wish you the best of luck Phillip and also wish you
a quick recovery.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
John Reagan
2017-03-27 01:29:56 UTC
Permalink
Raw Message
Post by Phillip Helbig (undress to reply)
Post by Stephen Hoffman
Turn on automated application debugging and configure and enable the
blockchain-protected and encrypted distributed application error and
crash logging mechanisms, and re-run the sequence. That'll point
right to the error, and you can then select either "Refactor", "Recode"
or "Resolve" from the IDE GUI, then select "Build" and "Run", and off
you go.
I tried SET VERIFY. :-| The error is coming from the .EXE, though.
You'll see that error if the image activator tries to read beyond the end of the file. Something like:

$ RUN NL:

Do ANAL/IMAGE to see if it gets upset about something.

Any rogue logical names that point to non-existant files or undefined logicals?

$ define librtl nl:
$ dir
%DCL-W-ACTIMAGE, error activating image LIBRTL
-CLI-E-IMGNAME, image file NL:[].EXE;
-SYSTEM-W-ENDOFFILE, end of file
IanD
2017-03-27 08:58:54 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by Phillip Helbig (undress to reply)
I have a procedure which I've been using for years, almost always
called from another procedure which is running in a SPAWNed subprocess.
A few months ago, it started producing
%SYSTEM-W-ENDOFFILE, end of file
messages when an executable processed the corresponding file, and also
the executable doesn't do what it is supposed to do.
Needless to say, I didn't change anything.
If I execute the same procedure interactively, rather than from within
the other procedure, it works as it always has.
Any ideas?
<snip>
Post by Stephen Hoffman
Turn on automated application debugging and configure and enable the
blockchain-protected and encrypted distributed application error and
crash logging mechanisms, and re-run the sequence. That'll point
right to the error, and you can then select either "Refactor", "Recode"
or "Resolve" from the IDE GUI, then select "Build" and "Run", and off
you go.
Oh, wait, sorry; that capability doesn't exist on OpenVMS. My bad. πŸ˜‰ ;-)
Ha ha ha, too dam funny

You forgot the quantum state analyser - that will give a productivity boost that defies all sensibilities
Post by Stephen Hoffman
All admonitions to the contrary, something here has clearly changed.
Something. Either in the application code or in some dependency or in
the local system environment, in the scale or encoding or in the
quantity or contents of the data present, or in the I/O timing or
related details, maybe in process quotas or file sizes or device
timings or whatever. There's more data, or less data, or the data
isn't arriving as expected, or.... something has changed. Instrument
and debug your code.
or some type of corruption that remains undetectable by current VMS. Something akin to say bit-rot that XFS can detect
Post by Stephen Hoffman
Caution: Code that's been running for decades does not imply that the
code is bug-free, nor that the code will always be reliable nor
necessarily even stable, for that matter. Older code tends to be
pretty buggy, too β€” I've found more than a few latent errors in old
code through the use of more recent compilers and compiler diagnostics,
too. Code that produces an isolated EOF error β€” without some
additional information or some way to trace the call and the cause β€”
could certainly use some better diagnostics, too.
Despite talk to the contrary, I think coding standards have improved greatly compared to the days of old when coders rode on their white horses conquering all (at least this is how people seem to remember them). Languages are evolving, errors spotted earlier in the assembly process, frameworks herding people into models that improve quality.

Education standards overall are better at imparting best practices

The difference is the barrier to entry is much lower than it used to be. There are languages like php that allow atrocious code to be stitched together and because it was a language that easily allowed web pages and backend systems to work together it became widespread and the low quality genie was let out of the bottle again

Now there is the push for functional languages again. People are tired of side effects

I'm working in a place with old code. The language in use is an old tried and tested one, yet code constantly needs tweaking and changing because data changes, wants and needs and the grouping together of different data sets in different ways is being asked for, the old code struggles to keep up.

It was never designed to be cross-functional and go across differing data sets, so it breaks and needs tweaking. Side effects also show up in logic changes and/or timing issues arise. No one over the years get funding to regroup and refactor the business logic and eventually the old code base is seen as not fit for purpose and is thrown out along with the OS (VMS in this case!)

Old code is not better than new code IMO, unless your talking about highly constrained specific code, say things like low level assembler routines that only have to deal with a confined situation - yeah, then the old code is good and by implication, those old programmers get a pat on the back for being wizards while the higher order programmers somehow get tarred - different worlds and different coding constructs yet people wish to try and group them all together at times and whip one group while praising the other
Post by Stephen Hoffman
The DCL command SET WATCH might help isolate the particular executable
or command or call that's failing, but that's far from the best tool to
use in any large and complex environment. Unfortunately, OpenVMS
itself is not very good at allowing a developer to capture these
errors, nor at packaging and producing and reporting diagnostics when
errors do arise. It's certainly possible to add that, but β€” as
apparently happened here β€” that error-detection and error-reporting
code doesn't always get embedded in the applications.
Can't say I've ever needed to use that tool.

Is it supported yet?
Post by Stephen Hoffman
We're either going to need a look at the code or some form or
reproducer or access to the code... Or you're going to have to wade
into this code and debug and/or instrument this, and resolve this....
--
Pure Personal Opinion | HoffmanLabs LLC
Something like strace would be nice on VMS. or set watch on VMS symbols and logicals (triggered events instead of having to poll them through horrible things like Show Symbol bla bla bla)

Is there any reason why a set watch on a dcl symbol / logical could not be implemented? perhaps it's not worth it since it seems DCL could be on its death march (or is it?)
Stephen Hoffman
2017-03-27 16:28:03 UTC
Permalink
Raw Message
Post by IanD
Post by Stephen Hoffman
Turn on automated application debugging and configure and enable the
blockchain-protected and encrypted distributed application error and
crash logging mechanisms, and re-run the sequence. That'll point
right to the error, and you can then select either "Refactor", "Recode"
or "Resolve" from the IDE GUI, then select "Build" and "Run", and off
you go.
Oh, wait, sorry; that capability doesn't exist on OpenVMS. My bad. πŸ˜‰ ;-)
Ha ha ha, too dam funny
You forgot the quantum state analyser - that will give a productivity
boost that defies all sensibilities
That whole sequence is closer to availability than many folks familiar
with OpenVMS might recognize. I'm working with system-integrated
tools that automatically upload app and system crashes and that detect
and notify and process app and system software updates, and where tools
to integrate and to run your own crash server and your own software
update server are available, and where the code-refactoring and
compiler-detected error-detection and correction tools are available in
the development environment. That's a whole lot less like fantasy.

OpenVMS development had a crash server and there are still hooks and
pieces of that around, but AFAIK the back-end automated crash-scanning
service was discontinued long ago. Other platforms now have something
similar, and with more capabilities, as well as possessing far more
advanced software update mechanisms.
Post by IanD
Post by Stephen Hoffman
All admonitions to the contrary, something here has clearly changed.
Something. Either in the application code or in some dependency or in
the local system environment, in the scale or encoding or in the
quantity or contents of the data present, or in the I/O timing or
related details, maybe in process quotas or file sizes or device
timings or whatever. There's more data, or less data, or the data
isn't arriving as expected, or.... something has changed. Instrument
and debug your code.
or some type of corruption that remains undetectable by current VMS.
Something akin to say bit-rot that XFS can detect
It'd be interesting to see how common disk errors are in OpenVMS
environments. There are published empirical studies with estimates of
three to six hard errors per terabyte.
Post by IanD
Post by Stephen Hoffman
Caution: Code that's been running for decades does not imply that the
code is bug-free, nor that the code will always be reliable nor
necessarily even stable, for that matter. Older code tends to be
pretty buggy, too β€” I've found more than a few latent errors in old
code through the use of more recent compilers and compiler diagnostics,
too. Code that produces an isolated EOF error β€” without some
additional information or some way to trace the call and the cause β€”
could certainly use some better diagnostics, too.
Despite talk to the contrary, I think coding standards have improved
greatly compared to the days of old when coders rode on their white
horses conquering all (at least this is how people seem to remember
them). Languages are evolving, errors spotted earlier in the assembly
process, frameworks herding people into models that improve quality.
Error detection has gotten substantially better in even the OpenVMS
compilers, too. Though prying folks off source code dependencies on
/STANDARD=VAXC can sometimes be a surreal exercise, and part of why I'd
prefer to see that sort of compatibility-with-broken-code killed with
fire.
Post by IanD
Education standards overall are better at imparting best practices
The difference is the barrier to entry is much lower than it used to
be. There are languages like php that allow atrocious code to be
stitched together and because it was a language that easily allowed web
pages and backend systems to work together it became widespread and the
low quality genie was let out of the bottle again
Now there is the push for functional languages again. People are tired of side effects
And a monad is a merely mechanism for creating a bag for side-effects...
Post by IanD
I'm working in a place with old code. The language in use is an old
tried and tested one, yet code constantly needs tweaking and changing
because data changes, wants and needs and the grouping together of
different data sets in different ways is being asked for, the old code
struggles to keep up.
It was never designed to be cross-functional and go across differing
data sets, so it breaks and needs tweaking. Side effects also show up
in logic changes and/or timing issues arise. No one over the years get
funding to regroup and refactor the business logic and eventually the
old code base is seen as not fit for purpose and is thrown out along
with the OS (VMS in this case!)
Old code is not better than new code IMO, unless your talking about
highly constrained specific code, say things like low level assembler
routines that only have to deal with a confined situation - yeah, then
the old code is good and by implication, those old programmers get a
pat on the back for being wizards while the higher order programmers
somehow get tarred - different worlds and different coding constructs
yet people wish to try and group them all together at times and whip
one group while praising the other
Old code that works is far more valuable than new code that doesn't yet exist.
Post by IanD
Post by Stephen Hoffman
The DCL command SET WATCH might help isolate the particular executable
or command or call that's failing, but that's far from the best tool to
use in any large and complex environment. Unfortunately, OpenVMS
itself is not very good at allowing a developer to capture these
errors, nor at packaging and producing and reporting diagnostics when
errors do arise. It's certainly possible to add that, but β€” as
apparently happened here β€” that error-detection and error-reporting
code doesn't always get embedded in the applications.
Can't say I've ever needed to use that tool.
Is it supported yet?
SET WATCH? AFAIK, no, not supported. Closest supported analog is
enabling security audits or alarms for accesses, and that can generate
a tsunami of data to sort through, and it's far less granular than what
SET WATCH reports.
Post by IanD
Post by Stephen Hoffman
We're either going to need a look at the code or some form or
reproducer or access to the code... Or you're going to have to wade
into this code and debug and/or instrument this, and resolve this....
Something like strace would be nice on VMS. or set watch on VMS symbols
and logicals (triggered events instead of having to poll them through
horrible things like Show Symbol bla bla bla)
Ayup. dtrace and Instruments are the local analogs on macOS, and are
very powerful. Combined with the Xcode IDE, lldb and the rest, macOS
and iOS have a better tool chain than is available with OpenVMS. This
as much as I appreciate the capabilities of the OpenVMS debugger,
Instruments just utterly blows it away, and lldb and dtrace are
exceptionally useful. Over the next five and ten years, these are
the sorts of development tools that OpenVMS will increasingly be
competing with, too.
Post by IanD
Is there any reason why a set watch on a dcl symbol / logical could not
be implemented? perhaps it's not worth it since it seems DCL could be
on its death march (or is it?)
If the goal is to watch logical name tables, then audits and alarms are
available for that. The SET WATCH command displays file system
activity, and will report a file system call returning an EOF status.
The SET WATCH command won't report program-generated EOF condition
values, nor will it report condition values returned from networking
calls.
--
Pure Personal Opinion | HoffmanLabs LLC
Loading...