Here's my current set of DECC$ logicals for maximum UNIX compatibility.

$! Set VMS logicals for UNIX-like compatibility.
$ $ define/job DECC$UNIX_LEVEL "30"
$! This feature must be disabled for Clang.
$ define/job DECC$FILE_SHARING "DISABLE"
$! This feature must be disabled for Vim.
$ define/job DECC$FILENAME_UNIX_REPORT "DISABLE"
$ $ define/job DECC$ENABLE_GETENV_CACHE "ENABLE"
$ define/job DECC$ENABLE_TO_VMS_LOGNAME_CACHE "2"
$ define/job DECC$EXIT_AFTER_FAILED_EXEC "ENABLE"
$ define/job DECC$MAILBOX_CTX_STM "ENABLE"
$ define/job DECC$POPEN_NO_CRLF_REC_ATTR "ENABLE"
$ define/job DECC$STREAM_PIPE "ENABLE"
$ define/job DECC$EXEC_FILEATTR_INHERITANCE "2"
$ $ define/job DECC$ALLOW_REMOVE_OPEN_FILES "ENABLE"
$ define/job DECC$ACL_ACCESS_CHECK "ENABLE"

This is in addition to the defines in the OpenJDK setup script:

$ define DECC$ARGV_PARSE_STYLE "enable"
$ define DECC$EFS_CASE_PRESERVE "enable"
$ define DECC$EFS_CHARSET "enable"
$ define DECC$FD_LOCKING "true"
$ define DECC$READDIR_DROPDOTNOTYPE "enable"

I tried increasing DECC$PIPE_BUFFER_SIZE and DECC$PIPE_BUFFER_QUOTA, but that only made performance slightly worse. At DECC$UNIX_LEVEL = 10, DECC$PIPE_BUFFER_SIZE is increased from 512 to 4096 bytes, which may be close to optimal.

I also know from benchmarks that enabling DECC$STREAM_PIPE has a 2-3x speed increase for pipe(), but DECC$POPEN_NO_CRLF_REC_ATTR doesn't seem to matter (I added it for compatibility).

DECC$EXIT_AFTER_FAILED_EXEC is needed if the program expects a failed exec() in a vfork() child to return an error instead of exiting the child. Most of these C RTL settings should be defined at startup by ported programs themselves, as many of the GNV ports do.

I discovered that DECC$FILE_SHARING must be disabled for Clang to be able to write its output files, and DECC$FILENAME_UNIX_REPORT must be disabled for Vim to be able to read the files to edit (otherwise it reports file not found and opens an empty editor window). Those are enabled at DECC$UNIX_LEVEL 30 and 20, respectively.

I also know that DECC$READDIR_DROPDOTNOTYPE must be disabled for Perl's generated Descrip.MMS scripts to work, or else an extra "." is added at the end of the directory name when building a CPAN perl module and the build fails. That setting is also enabled at DECC$UNIX_LEVEL 20 (besides being enabled specifically by the OpenJDK script). I wonder if there are any other VMS programs or build scripts that need this to be disabled.

BTW, as I mentioned in an earlier post with PostMark results, setting DECC$POSIX_COMPLIANT_PATHNAMES to 2 leads to noticeably slower file open speeds than the standard VMS/UNIX hybrid pathname parsing, so I would suggest avoiding that feature.

Regards,
Jake Hamby

On Monday, October 16, 2023 at 2:03:17 PM UTC-4, Jake Hamby (Solid State Jake) wrote:
> Here's my current set of DECC$ logicals for maximum UNIX compatibility.
>
> $! Set VMS logicals for UNIX-like compatibility.
> $
> $ define/job DECC$UNIX_LEVEL "30"
> $! This feature must be disabled for Clang.
> $ define/job DECC$FILE_SHARING "DISABLE"
> $! This feature must be disabled for Vim.
> $ define/job DECC$FILENAME_UNIX_REPORT "DISABLE"
> $
> $ define/job DECC$ENABLE_GETENV_CACHE "ENABLE"
> $ define/job DECC$ENABLE_TO_VMS_LOGNAME_CACHE "2"
> $ define/job DECC$EXIT_AFTER_FAILED_EXEC "ENABLE"
> $ define/job DECC$MAILBOX_CTX_STM "ENABLE"
> $ define/job DECC$POPEN_NO_CRLF_REC_ATTR "ENABLE"
> $ define/job DECC$STREAM_PIPE "ENABLE"
> $ define/job DECC$EXEC_FILEATTR_INHERITANCE "2"
> $
> $ define/job DECC$ALLOW_REMOVE_OPEN_FILES "ENABLE"
> $ define/job DECC$ACL_ACCESS_CHECK "ENABLE"
>
> This is in addition to the defines in the OpenJDK setup script:
>
> $ define DECC$ARGV_PARSE_STYLE "enable"
> $ define DECC$EFS_CASE_PRESERVE "enable"
> $ define DECC$EFS_CHARSET "enable"
> $ define DECC$FD_LOCKING "true"
> $ define DECC$READDIR_DROPDOTNOTYPE "enable"
>
> I tried increasing DECC$PIPE_BUFFER_SIZE and DECC$PIPE_BUFFER_QUOTA, but that only made performance slightly worse. At DECC$UNIX_LEVEL = 10, DECC$PIPE_BUFFER_SIZE is increased from 512 to 4096 bytes, which may be close to optimal.
>
> I also know from benchmarks that enabling DECC$STREAM_PIPE has a 2-3x speed increase for pipe(), but DECC$POPEN_NO_CRLF_REC_ATTR doesn't seem to matter (I added it for compatibility).
>
> DECC$EXIT_AFTER_FAILED_EXEC is needed if the program expects a failed exec() in a vfork() child to return an error instead of exiting the child. Most of these C RTL settings should be defined at startup by ported programs themselves, as many of the GNV ports do.
>
> I discovered that DECC$FILE_SHARING must be disabled for Clang to be able to write its output files, and DECC$FILENAME_UNIX_REPORT must be disabled for Vim to be able to read the files to edit (otherwise it reports file not found and opens an empty editor window). Those are enabled at DECC$UNIX_LEVEL 30 and 20, respectively.
>
> I also know that DECC$READDIR_DROPDOTNOTYPE must be disabled for Perl's generated Descrip.MMS scripts to work, or else an extra "." is added at the end of the directory name when building a CPAN perl module and the build fails. That setting is also enabled at DECC$UNIX_LEVEL 20 (besides being enabled specifically by the OpenJDK script). I wonder if there are any other VMS programs or build scripts that need this to be disabled.
>
> BTW, as I mentioned in an earlier post with PostMark results, setting DECC$POSIX_COMPLIANT_PATHNAMES to 2 leads to noticeably slower file open speeds than the standard VMS/UNIX hybrid pathname parsing, so I would suggest avoiding that feature.
>
> Regards,
> Jake Hamby
I never recommend setting any DECC$ feature logicals at the DCL command line. As you've seen, setting some of those logicals can break things like compilers. IIRC, setting PCP would break the Itanium C compiler. I always suggest to use a LIB$INITIALIZE routine and set the desired logicals in the program directly. I wasn't directly involved with the invention of the feature logicals, but I would walk by the C and CRTL teams and roll my eyes as often as I can. We don't test anything with non-default logicals.

That said, I do have somebody looking at why clang didn't like DECC$FILE_SHARING but it isn't high on our lists. This is one of those "Dr, it hurts when I do this" situations.

On Monday, October 16, 2023 at 5:54:55 PM UTC-7, John Reagan wrote:
>
> I never recommend setting any DECC$ feature logicals at the DCL command line. As you've seen, setting some of those logicals can break things like compilers. IIRC, setting PCP would break the Itanium C compiler. I always suggest to use a LIB$INITIALIZE routine and set the desired logicals in the program directly. I wasn't directly involved with the invention of the feature logicals, but I would walk by the C and CRTL teams and roll my eyes as often as I can. We don't test anything with non-default logicals.
>
> That said, I do have somebody looking at why clang didn't like DECC$FILE_SHARING but it isn't high on our lists. This is one of those "Dr, it hurts when I do this" situations.

That makes perfect sense. I've already discovered that enabling DECC$ENABLE_TO_VMS_LOGNAME_CACHE is highly unsafe, at least Java and probably others. I suspect the JVM is using a VMS filename conversion to test for the presence/absence of a file, and then when it gets deleted on disk, the cache is out of sync, and the program (Apache Spark benchmark) crashes with an object not found exception.

I have a very minimal set of DECC$ values that I've set before building/testing Perl, to see if they make any difference:

$! Set VMS logicals for UNIX-like compatibility.
$! Only sets features that are safe for Perl 5 build/run/test.
$ $! Start from UNIX level 10 (fewer features to remove).
$ $ define/job DECC$UNIX_LEVEL "10"
$ define/job DECC$FILENAME_UNIX_NO_VERSION "ENABLE"
$ define/job DECC$RENAME_NO_INHERIT "ENABLE"
$ $ define/job DECC$ENABLE_GETENV_CACHE "ENABLE"
$ define/job DECC$STREAM_PIPE "ENABLE"
$ define/job DECC$EXEC_FILEATTR_INHERITANCE "2"
$ $! Unset logical set by OpenJDK startup script
$ $ deassign/nolog DECC$READDIR_DROPDOTNOTYPE

On 10/17/23 9:51 PM, Jake Hamby (Solid State Jake) wrote:
> On Monday, October 16, 2023 at 5:54:55 PM UTC-7, John Reagan wrote:
>>
>> I never recommend setting any DECC$ feature logicals at the DCL command line. As you've seen, setting some of those logicals can break things like compilers. IIRC, setting PCP would break the Itanium C compiler. I always suggest to use a LIB$INITIALIZE routine and set the desired logicals in the program directly. I wasn't directly involved with the invention of the feature logicals, but I would walk by the C and CRTL teams and roll my eyes as often as I can. We don't test anything with non-default logicals.
>>
>> That said, I do have somebody looking at why clang didn't like DECC$FILE_SHARING but it isn't high on our lists. This is one of those "Dr, it hurts when I do this" situations.
>
> That makes perfect sense. I've already discovered that enabling DECC$ENABLE_TO_VMS_LOGNAME_CACHE is highly unsafe, at least Java and probably others. I suspect the JVM is using a VMS filename conversion to test for the presence/absence of a file, and then when it gets deleted on disk, the cache is out of sync, and the program (Apache Spark benchmark) crashes with an object not found exception.
>
> I have a very minimal set of DECC$ values that I've set before building/testing Perl, to see if they make any difference:

>
> $! Set VMS logicals for UNIX-like compatibility.
> $! Only sets features that are safe for Perl 5 build/run/test.
> $
> $! Start from UNIX level 10 (fewer features to remove).

I've only ever used one of these "bucket" logicals when running a
configure script under GNV, and even then it was iffy whether it caused
more problems than it solved.

> $
> $ define/job DECC$UNIX_LEVEL "10"
> $ define/job DECC$FILENAME_UNIX_NO_VERSION "ENABLE"
> $ define/job DECC$RENAME_NO_INHERIT "ENABLE"
> $
> $ define/job DECC$ENABLE_GETENV_CACHE "ENABLE"
> $ define/job DECC$STREAM_PIPE "ENABLE"
> $ define/job DECC$EXEC_FILEATTR_INHERITANCE "2"
> $

It's not clear to me what problem you're trying to solve by setting all
these. None of them is necessary for Perl. You probably do want
DECC$ARGV_PARSE_STYLE since setting that in LIB$INITIALIZE is too late
and there are some things in the Perl test suite that assume a
case-preserved command line without quoting arguments.

I guess it's possible one or more of these things might be necessary for
clang++, though you have the head of the compiler team from VSI telling
you they don't use them.

> $! Unset logical set by OpenJDK startup script
> $
> $ deassign/nolog DECC$READDIR_DROPDOTNOTYPE

On Wednesday, October 18, 2023 at 7:46:02 AM UTC-4, Craig A. Berry wrote:
> On 10/17/23 9:51 PM, Jake Hamby (Solid State Jake) wrote:
> > On Monday, October 16, 2023 at 5:54:55 PM UTC-7, John Reagan wrote:
> >>
> >> I never recommend setting any DECC$ feature logicals at the DCL command line. As you've seen, setting some of those logicals can break things like compilers. IIRC, setting PCP would break the Itanium C compiler. I always suggest to use a LIB$INITIALIZE routine and set the desired logicals in the program directly. I wasn't directly involved with the invention of the feature logicals, but I would walk by the C and CRTL teams and roll my eyes as often as I can. We don't test anything with non-default logicals.
> >>
> >> That said, I do have somebody looking at why clang didn't like DECC$FILE_SHARING but it isn't high on our lists. This is one of those "Dr, it hurts when I do this" situations.
> >
> > That makes perfect sense. I've already discovered that enabling DECC$ENABLE_TO_VMS_LOGNAME_CACHE is highly unsafe, at least Java and probably others. I suspect the JVM is using a VMS filename conversion to test for the presence/absence of a file, and then when it gets deleted on disk, the cache is out of sync, and the program (Apache Spark benchmark) crashes with an object not found exception.
> >
> > I have a very minimal set of DECC$ values that I've set before building/testing Perl, to see if they make any difference:
>
> >
> > $! Set VMS logicals for UNIX-like compatibility.
> > $! Only sets features that are safe for Perl 5 build/run/test.
> > $
> > $! Start from UNIX level 10 (fewer features to remove).
> I've only ever used one of these "bucket" logicals when running a
> configure script under GNV, and even then it was iffy whether it caused
> more problems than it solved.
> > $
> > $ define/job DECC$UNIX_LEVEL "10"
> > $ define/job DECC$FILENAME_UNIX_NO_VERSION "ENABLE"
> > $ define/job DECC$RENAME_NO_INHERIT "ENABLE"
> > $
> > $ define/job DECC$ENABLE_GETENV_CACHE "ENABLE"
> > $ define/job DECC$STREAM_PIPE "ENABLE"
> > $ define/job DECC$EXEC_FILEATTR_INHERITANCE "2"
> > $
> It's not clear to me what problem you're trying to solve by setting all
> these. None of them is necessary for Perl. You probably do want
> DECC$ARGV_PARSE_STYLE since setting that in LIB$INITIALIZE is too late
> and there are some things in the Perl test suite that assume a
> case-preserved command line without quoting arguments.
>
> I guess it's possible one or more of these things might be necessary for
> clang++, though you have the head of the compiler team from VSI telling
> you they don't use them.
> > $! Unset logical set by OpenJDK startup script
> > $
> > $ deassign/nolog DECC$READDIR_DROPDOTNOTYPE
Yeah, when I build LLVM 3.4.2 on Itanium, I do set a minimal # of logicals in a subprocess
just before I invoke bash/make

$ set process /parse=extended
$ define/nolog DECC$ARGV_PARSE_STYLE ENABLE
$ define/nolog DECC$EFS_CASE_PRESERVE ENABLE
$ define/nolog DECC$EFS_CHARSET ENABLE
$ define/nolog DECC$ACL_ACCESS_CHECK ENABLE

On Wednesday, October 18, 2023 at 9:32:31 AM UTC-4, John Reagan wrote:
> On Wednesday, October 18, 2023 at 7:46:02 AM UTC-4, Craig A. Berry wrote:
> > On 10/17/23 9:51 PM, Jake Hamby (Solid State Jake) wrote:
> > > On Monday, October 16, 2023 at 5:54:55 PM UTC-7, John Reagan wrote:
> > >>
> > >> I never recommend setting any DECC$ feature logicals at the DCL command line. As you've seen, setting some of those logicals can break things like compilers. IIRC, setting PCP would break the Itanium C compiler. I always suggest to use a LIB$INITIALIZE routine and set the desired logicals in the program directly. I wasn't directly involved with the invention of the feature logicals, but I would walk by the C and CRTL teams and roll my eyes as often as I can. We don't test anything with non-default logicals.
> > >>
> > >> That said, I do have somebody looking at why clang didn't like DECC$FILE_SHARING but it isn't high on our lists. This is one of those "Dr, it hurts when I do this" situations.
> > >
> > > That makes perfect sense. I've already discovered that enabling DECC$ENABLE_TO_VMS_LOGNAME_CACHE is highly unsafe, at least Java and probably others. I suspect the JVM is using a VMS filename conversion to test for the presence/absence of a file, and then when it gets deleted on disk, the cache is out of sync, and the program (Apache Spark benchmark) crashes with an object not found exception.
> > >
> > > I have a very minimal set of DECC$ values that I've set before building/testing Perl, to see if they make any difference:
> >
> > >
> > > $! Set VMS logicals for UNIX-like compatibility.
> > > $! Only sets features that are safe for Perl 5 build/run/test.
> > > $
> > > $! Start from UNIX level 10 (fewer features to remove).
> > I've only ever used one of these "bucket" logicals when running a
> > configure script under GNV, and even then it was iffy whether it caused
> > more problems than it solved.
> > > $
> > > $ define/job DECC$UNIX_LEVEL "10"
> > > $ define/job DECC$FILENAME_UNIX_NO_VERSION "ENABLE"
> > > $ define/job DECC$RENAME_NO_INHERIT "ENABLE"
> > > $
> > > $ define/job DECC$ENABLE_GETENV_CACHE "ENABLE"
> > > $ define/job DECC$STREAM_PIPE "ENABLE"
> > > $ define/job DECC$EXEC_FILEATTR_INHERITANCE "2"
> > > $
> > It's not clear to me what problem you're trying to solve by setting all
> > these. None of them is necessary for Perl. You probably do want
> > DECC$ARGV_PARSE_STYLE since setting that in LIB$INITIALIZE is too late
> > and there are some things in the Perl test suite that assume a
> > case-preserved command line without quoting arguments.
> >
> > I guess it's possible one or more of these things might be necessary for
> > clang++, though you have the head of the compiler team from VSI telling
> > you they don't use them.
> > > $! Unset logical set by OpenJDK startup script
> > > $
> > > $ deassign/nolog DECC$READDIR_DROPDOTNOTYPE
> Yeah, when I build LLVM 3.4.2 on Itanium, I do set a minimal # of logicals in a subprocess
> just before I invoke bash/make
>
> $ set process /parse=extended
> $ define/nolog DECC$ARGV_PARSE_STYLE ENABLE
> $ define/nolog DECC$EFS_CASE_PRESERVE ENABLE
> $ define/nolog DECC$EFS_CHARSET ENABLE
> $ define/nolog DECC$ACL_ACCESS_CHECK ENABLE
And if we are desperate, I can call one of the Black Magic Specialists from the other spam
posts flooding the newsgroup. Perhaps they can help?

On 10/18/2023 7:45 AM, Craig A. Berry wrote:
> On 10/17/23 9:51 PM, Jake Hamby (Solid State Jake) wrote:
>> On Monday, October 16, 2023 at 5:54:55 PM UTC-7, John Reagan wrote:
>>> I never recommend setting any DECC$ feature logicals at the DCL
>>> command line. As you've seen, setting some of those logicals can
>>> break things like compilers. IIRC, setting PCP would break the
>>> Itanium C compiler. I always suggest to use a LIB$INITIALIZE routine
>>> and set the desired logicals in the program directly. I wasn't
>>> directly involved with the invention of the feature logicals, but I
>>> would walk by the C and CRTL teams and roll my eyes as often as I
>>> can. We don't test anything with non-default logicals.
>>>
>>> That said, I do have somebody looking at why clang didn't like
>>> DECC$FILE_SHARING but it isn't high on our lists. This is one of
>>> those "Dr, it hurts when I do this" situations.
>>
>> That makes perfect sense. I've already discovered that enabling
>> DECC$ENABLE_TO_VMS_LOGNAME_CACHE is highly unsafe, at least Java and
>> probably others. I suspect the JVM is using a VMS filename conversion
>> to test for the presence/absence of a file, and then when it gets
>> deleted on disk, the cache is out of sync, and the program (Apache
>> Spark benchmark) crashes with an object not found exception.
>>
>> I have a very minimal set of DECC$ values that I've set before
>> building/testing Perl, to see if they make any difference:
>
>>
>> $! Set VMS logicals for UNIX-like compatibility.
>> $! Only sets features that are safe for Perl 5 build/run/test.
>> $
>> $! Start from UNIX level 10 (fewer features to remove).
>
> I've only ever used one of these "bucket" logicals when running a
> configure script under GNV, and even then it was iffy whether it caused
> more problems than it solved.
>
>> $
>> $ define/job DECC$UNIX_LEVEL "10"
>> $ define/job DECC$FILENAME_UNIX_NO_VERSION "ENABLE"
>> $ define/job DECC$RENAME_NO_INHERIT "ENABLE"
>> $
>> $ define/job DECC$ENABLE_GETENV_CACHE "ENABLE"
>> $ define/job DECC$STREAM_PIPE "ENABLE"
>> $ define/job DECC$EXEC_FILEATTR_INHERITANCE "2"
>> $
>
> It's not clear to me what problem you're trying to solve by setting all
> these.  None of them is necessary for Perl.  You probably do want
> DECC$ARGV_PARSE_STYLE since setting that in LIB$INITIALIZE is too late
> and there are some things in the Perl test suite that assume a
> case-preserved command line without quoting arguments.

I am also very cautious about these logicals.

I only add any when absolutely needed.

java$setup.com set a few - I *hope* that the VSI Java gurus
only set those logicals that do not create problems for
other applications.

I know that for sqlite JDBC usage I need:

$ define/nolog java$filename_controls 8
$ define/nolog decc$efs_charset true

Otherwise it does not work (in case anyone wonder -
type 2 JDBC driver with shareable image embedded
in jar needing extraction before load).

And when running Java code coming from *nix I sometime
have to set java$filename_match_list to get it to work, like:

$ define/nolog java$filename_match_list "*.jdb=shr=get,put"

That is it. And I play with a lot of stuff.

Arne

On 2023-10-18, John Reagan <xyzzy1959@gmail.com> wrote:
> And if we are desperate, I can call one of the Black Magic Specialists from the other spam
> posts flooding the newsgroup. Perhaps they can help?

Those messages are not showing up on Eternal September, but neither are
all of the messages from the regulars here, so I wonder if they are
also been marked as spam and removed.

I have seen those messages for the last few days when looking through
Google Groups however. Surely posting so many messages in such a short
time would actually be very counterproductive ? If they want people to
call them, I would have thought that posting at a much slower rate would
be more productive.

Simon.

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

On 2023-10-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> I am also very cautious about these logicals.
>
> I only add any when absolutely needed.
>

Those logicals seem like a major case of technical debt, in that each
were added to solve an immediate problem, but at the same time, their
addition caused extra work for people in the future.

I wonder if it is possible to reorganise them into easier to understand
and easier to use groups, as there's no way that Jake should have had
to go to the level of detail and effort he did to understand and use
them.

People say Jake should not have used many of them. My question is how
could he possibly have known that in advance until he had done the
work to understand what each of them did ? That's why I call them a
case of technical debt.

Simon.

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

On 10/18/23 8:47 AM, hb@end.of.inter.net wrote:
> On Wednesday, October 18, 2023 at 1:46:02 PM UTC+2, Craig A. Berry wrote:
>> It's not clear to me what problem you're trying to solve by setting all
>> these. None of them is necessary for Perl. You probably do want
>> DECC$ARGV_PARSE_STYLE since setting that in LIB$INITIALIZE is too late
>> and there are some things in the Perl test suite that assume a
>> case-preserved command line without quoting arguments.
>
> A general statement that setting the DECC$ARGV_PARSE_STYLE feature in LIB$INITIALIZE is too late is wrong. For C applications, you can have a LIB$INITIALIZE in your main program and it works as expected. For C++ applications, you can have a LIB$INITIALIZE in an own shareable image, which is linked to your main program, and it works as expected.

Fair point. But the OP is using C++ and is building something that does
not have LIB$INITIALIZE in its own separate image (i.e, a different
image from the one main() is in, if I remember how this works).

On 10/18/2023 1:59 PM, Simon Clubley wrote:
> On 2023-10-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> I am also very cautious about these logicals.
>>
>> I only add any when absolutely needed.
>
> Those logicals seem like a major case of technical debt, in that each
> were added to solve an immediate problem, but at the same time, their
> addition caused extra work for people in the future.
>
> I wonder if it is possible to reorganise them into easier to understand
> and easier to use groups, as there's no way that Jake should have had
> to go to the level of detail and effort he did to understand and use
> them.
>
> People say Jake should not have used many of them. My question is how
> could he possibly have known that in advance until he had done the
> work to understand what each of them did ? That's why I call them a
> case of technical debt.

An application that original was developed on VMS does not need
any of that stuff. So if all VMS applications was original developed
on VMS then we would not have a problem.

But we live in the real world where a huge portion of "new stuff"
for VMS was original developed on *nix. And by *nix developers that
wrote code based on the wrong assumption that all future
usage of the code would be on an OS that behaved like
*nix regarding file name syntax, record format, case
sensitivity, charset etc..

So VMS has a problem - how to support both:
- applications developed on VMS
- application ported *nix that makes some nixy assumptions

This is a hard problem to solve.

Apparently logicals were the preferred way to handle that
in DEC/CPQ/HP a few decades ago.

I do not like the design due to logical having
typical process scope where the need really is for
application scope.

An obvious question is: are there a better solution.

I think it would be nice if such info could be stored
in P0 space, put in an EXE via link option and moved from
EXE to P0 space at image activation.

But I don't know enough to say whether that would really work.

Arne

On 10/18/2023 1:47 PM, Simon Clubley wrote:
>
>
> I have seen those messages for the last few days when looking through
> Google Groups however.

I suppose you would being as that is where they are coming from.

bill

On Wednesday, October 18, 2023 at 11:34:25 AM UTC-7, Arne Vajhøj wrote:
> On 10/18/2023 1:59 PM, Simon Clubley wrote:
> > On 2023-10-18, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >> I am also very cautious about these logicals.
> >>
> >> I only add any when absolutely needed.
> >
> > Those logicals seem like a major case of technical debt, in that each
> > were added to solve an immediate problem, but at the same time, their
> > addition caused extra work for people in the future.
> >
> > I wonder if it is possible to reorganise them into easier to understand
> > and easier to use groups, as there's no way that Jake should have had
> > to go to the level of detail and effort he did to understand and use
> > them.
> >
> > People say Jake should not have used many of them. My question is how
> > could he possibly have known that in advance until he had done the
> > work to understand what each of them did ? That's why I call them a
> > case of technical debt.
> An application that original was developed on VMS does not need
> any of that stuff. So if all VMS applications was original developed
> on VMS then we would not have a problem.
>
> But we live in the real world where a huge portion of "new stuff"
> for VMS was original developed on *nix. And by *nix developers that
> wrote code based on the wrong assumption that all future
> usage of the code would be on an OS that behaved like
> *nix regarding file name syntax, record format, case
> sensitivity, charset etc..
>
> So VMS has a problem - how to support both:
> - applications developed on VMS
> - application ported *nix that makes some nixy assumptions
>
> This is a hard problem to solve.
>
> Apparently logicals were the preferred way to handle that
> in DEC/CPQ/HP a few decades ago.
>
> I do not like the design due to logical having
> typical process scope where the need really is for
> application scope.
>
> An obvious question is: are there a better solution.
>
> I think it would be nice if such info could be stored
> in P0 space, put in an EXE via link option and moved from
> EXE to P0 space at image activation.
>
> But I don't know enough to say whether that would really work.
>
> Arne

That's the challenging problem that I've been fascinated with. The VMS port of Perl is a valuable reference because it's kept up-to-date and has the most thoroughly documented UNIX and VMS filename handling in the Perl doc for the port:

https://perldoc.perl.org/perlvms

Logicals mentioned in the Perl port docs include:

- DECC$FILENAME_UNIX_REPORT (modifies behavior so e.g. "./.../" in a Unix path is now translated to "[.^.^.^.]" instead of the traditional VMS "[...]".
- DECC$FILENAME_UNIX_ONLY (expects filenames to already be in UNIX format; incompatible with Perl
- DECC$POSIX_COMPLIANT_PATHNAMES (new with the RMS Symbolic Link SDK and included with OpenVMS v8.3, but is not yet supported in Perl)
- DECC$EFS_CASE_PRESERVE (enabled by default)
- DECC$ARGV_PARSE_STYLE (enabled by default, requires process to have extended parsing enabled)

The replies in this thread have convinced me that the DECC$ settings enabled by OpenJDK may not even be safe to have in SYLOGIN .COM, so I've commented out the OpenJDK setup line from my sylogin .com, and added OpenJDK setup to my user login .com file.

CivetWeb has sometimes been dumping core, as has Samba, and I'm wondering if possibly having the OpenJDK setup script in my sylogin was part of the problem. I'll report on those issues separately when I have more info. In general, CivetWeb seemed to crash at startup, or under heavy load, on Itanium and now x86. I can make Samba crash at will by running "dbench" in WSL on a Windows client with the Samba drive mounted in Windows as a drive letter and then in WSL with "sudo mount -t drvfs Z: /mnt/z".

While I'm at it, Perl has a few other noteworthy features regarding logicals.

- GNV$UNIX_SHELL enables more UNIX-like handling if defined, e.g. PERL5LIB and PERLLIB will use ":" as a separator if defined, or "|" by default on VMS, and environment variables are checked in the C environ array first and then the VMS logical name tables instead of the other way around.

I've seen this tested for in other GNV programs, and it looks like a good hint whenever there are two possible flavors for handling a filename or files.

- PERL_VMS_EXCEPTION_DEBUG if defined as enabled ("In typical VMS style, only the first letter of the value of this logical name is actually checked in a case insensitive mode, and it is considered enabled if it is the value "T","1" or "E") will enter the VMS debugger if a fatal exception that's not otherwise handled is raised.
- PERL_VMS_POSIX_EXIT maps the handling of return values to be similar to how _POSIX_EXIT works in C/C++ programs.

It seems like the DECC$POSIX_COMPLIANT_PATHNAMES feature is basically an evolutionary dead end, since it seems to be both slower (based on PostMark) and less flexible. VMS symbolic link targets have to be given in UNIX format, but I don't think the Perl docs are correct about them having to be within the POSIX root, if you aren't using POSIX compliant pathnames. I discovered on accident that many files in SYS$COMMON:[SYSEXE] are now links to the V9.2-1 memory disk used for booting and crashes:

$ dir/siz sys$common:[sysexe]loginout.exe

Directory SYS$COMMON:[SYSEXE]

LOGINOUT.EXE;1 -> /SYS$MD23276063438B/VMS$COMMON/SYSEXE/LOGINOUT.EXE
0.50KB

Regards,
Jake Hamby

On 10/18/23 5:34 PM, Jake Hamby (Solid State Jake) wrote:
> On Wednesday, October 18, 2023 at 11:34:25 AM UTC-7, Arne Vajhøj wrote:

>> This is a hard problem to solve.
>>
>> Apparently logicals were the preferred way to handle that
>> in DEC/CPQ/HP a few decades ago.
>>
>> I do not like the design due to logical having
>> typical process scope where the need really is for
>> application scope.

Would that really be different from user-mode logicals?

>> An obvious question is: are there a better solution.
>>
>> I think it would be nice if such info could be stored
>> in P0 space, put in an EXE via link option and moved from
>> EXE to P0 space at image activation.
>>
>> But I don't know enough to say whether that would really work.
>>
>> Arne
>

> That's the challenging problem that I've been fascinated with. The
> VMS port of Perl is a valuable reference because it's kept up-to-date and
> has the most thoroughly documented UNIX and VMS filename handling in the
> Perl doc for the port:
>
> https://perldoc.perl.org/perlvms

Up-to-date for some definition of up-to-date. It's been touched a
number of times in the last couple of decades, but I suspect there are
places that it still needs work.

> Logicals mentioned in the Perl port docs include:
>
> - DECC$FILENAME_UNIX_REPORT (modifies behavior so e.g. "./.../" in a Unix path is now translated to "[.^.^.^.]" instead of the traditional VMS "[...]".
> - DECC$FILENAME_UNIX_ONLY (expects filenames to already be in UNIX format; incompatible with Perl
> - DECC$POSIX_COMPLIANT_PATHNAMES (new with the RMS Symbolic Link SDK and included with OpenVMS v8.3, but is not yet supported in Perl)
> - DECC$EFS_CASE_PRESERVE (enabled by default)
> - DECC$ARGV_PARSE_STYLE (enabled by default, requires process to have extended parsing enabled)
>

> The replies in this thread have convinced me that the DECC$ settings
> enabled by OpenJDK may not even be safe to have in SYLOGIN .COM,

Ding! Ding! Ding!

Yeah, I used to run the JDK set-up in my personal login.com and then
delete one or two that I knew to be problematic. But now I'm unlikely
to assume that set-up is a good default, and the OpenJDK port doesn't
really need them anymore on x86 since I believe it now uses its own
LIB$INITIALIZE section.

<snip>

> It seems like the DECC$POSIX_COMPLIANT_PATHNAMES feature is basically an
> evolutionary dead end, since it seems to be both slower (based on
> PostMark) and less flexible. VMS symbolic link targets have to be given
> in UNIX format, but I don't think the Perl docs are correct about them
> having to be within the POSIX root, if you aren't using POSIX compliant
> pathnames. I discovered on accident that many files in
> SYS$COMMON:[SYSEXE] are now links to the V9.2-1 memory disk used for
> booting and crashes:

>
> $ dir/siz sys$common:[sysexe]loginout.exe
>
> Directory SYS$COMMON:[SYSEXE]
>
> LOGINOUT.EXE;1 -> /SYS$MD23276063438B/VMS$COMMON/SYSEXE/LOGINOUT.EXE
> 0.50KB

I think symlinks came in v8.3 and there were definitely changes and
fixes in v8.4. It would be unsurprising if the Perl docs did not
completely keep up with the changes.

On 10/18/2023 2:34 PM, Arne Vajhøj wrote:
> On 10/18/2023 1:59 PM, Simon Clubley wrote:
>> On 2023-10-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> I am also very cautious about these logicals.
>>>
>>> I only add any when absolutely needed.
>>
>> Those logicals seem like a major case of technical debt, in that each
>> were added to solve an immediate problem, but at the same time, their
>> addition caused extra work for people in the future.
>>
>> I wonder if it is possible to reorganise them into easier to understand
>> and easier to use groups, as there's no way that Jake should have had
>> to go to the level of detail and effort he did to understand and use
>> them.
>>
>> People say Jake should not have used many of them. My question is how
>> could he possibly have known that in advance until he had done the
>> work to understand what each of them did ? That's why I call them a
>> case of technical debt.
>
> An application that original was developed on VMS does not need
> any of that stuff. So if all VMS applications was original developed
> on VMS then we would not have a problem.
>
> But we live in the real world where a huge portion of "new stuff"
> for VMS was original developed on *nix. And by *nix developers that
> wrote code based on the wrong assumption that all future
> usage of the code would be on an OS that behaved like
> *nix regarding file name syntax, record format, case
> sensitivity, charset etc..
>
> So VMS has a problem - how to support both:
> - applications developed on VMS
> - application ported *nix that makes some nixy assumptions
>
> This is a hard problem to solve.
>
> Apparently logicals were the preferred way to handle that
> in DEC/CPQ/HP a few decades ago.
>
> I do not like the design due to logical having
> typical process scope where the need really is for
> application scope.
>
> An obvious question is: are there a better solution.
>
> I think it would be nice if such info could be stored
> in P0 space, put in an EXE via link option and moved from
> EXE to P0 space at image activation.
>
> But I don't know enough to say whether that would really work.
>
> Arne
>

Look at the Basic OPTION statement ...

It is two things, a compile time directive, and contained within the program.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Wednesday, October 18, 2023 at 8:34:25 PM UTC+2, Arne Vajhøj wrote:
....
> Apparently logicals were the preferred way to handle that
> in DEC/CPQ/HP a few decades ago.
>
> I do not like the design due to logical having
> typical process scope where the need really is for
> application scope.
>
> An obvious question is: are there a better solution.

The C RTL features can be enabled with logical names or with calling C RTL feature routines. Some of the features need to be set before the C/C++ main function runs. When using C RTL routines that's where the LIB$INITIALIZE mechanism is needed. Obviously, using the C RTL routines is more work than enabling the features with a logical name. So using logical names for setting the features is often preferred over setting the feature in the program - writing code.

C RTL feature logical names should be set in user-mode in the process table.. Then they are only in effect for the next image activation. But I know that there are a lot of command procedures out there, which just define them in super-mode in the process table. There are even command procedures, which define them in other tables.

> I think it would be nice if such info could be stored
> in P0 space, put in an EXE via link option and moved from
> EXE to P0 space at image activation.

This suggests that the application should set the C RTL features. That is probably the recommended and best way how these features can/should be enabled today - but see above.

I don't understand how your suggestion is supposed to work. Do you want the C RTL to look up the feature somewhere in the main image, which is mapped into P0? This requires (code or) data in the image, no matter how you put it - at compile or link time and a mechanism to find it.

Your suggestion is not really different from what you have or can do today: for each feature, create object modules, which enable/disable it with the LIB$INITIALIZE mechanism. When linking your application,
add the necessary modules to your image. Or, for each feature, create one object module, which sets its value with a "globalvalue". And that needs to be set at link time. This approach will also work for features which require a size. All in all it is more work to build the application than defining a logical name (in a command procedure) before running the application. And it does not help with existing applications.

For existing applications, I can think of another approach, but that requires rewriting its (ELF) image.

On 10/19/2023 1:03 AM, Dave Froble wrote:
> On 10/18/2023 2:34 PM, Arne Vajhøj wrote:
>> An application that original was developed on VMS does not need
>> any of that stuff. So if all VMS applications was original developed
>> on VMS then we would not have a problem.
>>
>> But we live in the real world where  a huge portion of "new stuff"
>> for VMS was original developed on *nix. And by *nix developers that
>> wrote code based on the wrong assumption that all future
>> usage of the code would be on an OS that behaved like
>> *nix regarding file name syntax, record format, case
>> sensitivity, charset etc..
>>
>> So VMS has a problem - how to support both:
>> - applications developed on VMS
>> - application ported *nix that makes some nixy assumptions
>>
>> This is a hard problem to solve.
>>
>> Apparently logicals were the preferred way to handle that
>> in DEC/CPQ/HP a few decades ago.
>>
>> I do not like the design due to logical having
>> typical process scope where the need really is for
>> application scope.
>>
>> An obvious question is: are there a better solution.
>>
>> I think it would be nice if such info could be stored
>> in P0 space, put in an EXE via link option and moved from
>> EXE to P0 space at image activation.
>>
>> But I don't know enough to say whether that would really work.
>
> Look at the Basic OPTION statement ...
>
> It is two things, a compile time directive, and contained within the
> program.

That would mean changes to all compilers.

And I also think it is cleaner to have it outside
the source code.

Arne

On 10/19/2023 3:13 AM, hb@end.of.inter.net wrote:
> On Wednesday, October 18, 2023 at 8:34:25 PM UTC+2, Arne Vajhøj
> wrote:
>> I think it would be nice if such info could be stored in P0 space,
>> put in an EXE via link option and moved from EXE to P0 space at
>> image activation.
>
> This suggests that the application should set the C RTL features.
> That is probably the recommended and best way how these features
> can/should be enabled today - but see above.
>
> I don't understand how your suggestion is supposed to work. Do you
> want the C RTL to look up the feature somewhere in the main image,
> which is mapped into P0?

Yes. Just like it today lookup logicals.

> This requires (code or) data in the image,
> no matter how you put it - at compile or link time and a mechanism to
> find it.

Of course - it will not work by magic.

> Your suggestion is not really different from what you have or can do
> today: for each feature, create object modules, which enable/disable
> it with the LIB$INITIALIZE mechanism. When linking your application,
> add the necessary modules to your image. Or, for each feature, create
> one object module, which sets its value with a "globalvalue". And
> that needs to be set at link time.

That is functional equivalent of what I am suggesting.

But the LIB$INITIALIZE mechanism is a rather
complex mechanism.

Compared to:

$ LINK ... + SYS$INPUT/OPT
NIX_OPTIONS=(xxx,yyy,zzz)
$

or even simpler:

$ LINK/NIX_OPTIONS=(xxx,yyy,zzz) ...

I want something that we can tell developers moving
from nix to VMS to use and they can easily understand.

Process logicals are easy to understand but has the wrong scope.

Arne

On 10/19/2023 6:59 PM, Arne Vajhøj wrote:
> On 10/19/2023 1:03 AM, Dave Froble wrote:
>> On 10/18/2023 2:34 PM, Arne Vajhøj wrote:
>>> An application that original was developed on VMS does not need
>>> any of that stuff. So if all VMS applications was original developed
>>> on VMS then we would not have a problem.
>>>
>>> But we live in the real world where a huge portion of "new stuff"
>>> for VMS was original developed on *nix. And by *nix developers that
>>> wrote code based on the wrong assumption that all future
>>> usage of the code would be on an OS that behaved like
>>> *nix regarding file name syntax, record format, case
>>> sensitivity, charset etc..
>>>
>>> So VMS has a problem - how to support both:
>>> - applications developed on VMS
>>> - application ported *nix that makes some nixy assumptions
>>>
>>> This is a hard problem to solve.
>>>
>>> Apparently logicals were the preferred way to handle that
>>> in DEC/CPQ/HP a few decades ago.
>>>
>>> I do not like the design due to logical having
>>> typical process scope where the need really is for
>>> application scope.
>>>
>>> An obvious question is: are there a better solution.
>>>
>>> I think it would be nice if such info could be stored
>>> in P0 space, put in an EXE via link option and moved from
>>> EXE to P0 space at image activation.
>>>
>>> But I don't know enough to say whether that would really work.
>>
>> Look at the Basic OPTION statement ...
>>
>> It is two things, a compile time directive, and contained within the program.
>
> That would mean changes to all compilers.
>
> And I also think it is cleaner to have it outside
> the source code.
>
> Arne
>
>

I think it's insane to have it outside the application. What can happen if any
of the logicals aren't set appropriately?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 10/19/2023 8:42 PM, Dave Froble wrote:
> On 10/19/2023 6:59 PM, Arne Vajhøj wrote:
>> On 10/19/2023 1:03 AM, Dave Froble wrote:
>>> On 10/18/2023 2:34 PM, Arne Vajhøj wrote:
>>>> I think it would be nice if such info could be stored
>>>> in P0 space, put in an EXE via link option and moved from
>>>> EXE to P0 space at image activation.
>>>>
>>>> But I don't know enough to say whether that would really work.
>>>
>>> Look at the Basic OPTION statement ...
>>>
>>> It is two things, a compile time directive, and contained within the
>>> program.
>>
>> That would mean changes to all compilers.
>>
>> And I also think it is cleaner to have it outside
>> the source code.
>
> I think it's insane to have it outside the application.  What can happen
> if any of the logicals aren't set appropriately?

I do want it in the application. Just in the build script
not in the source code.

It does not matter much for VMS Basic as it will only
run on VMS.

But for a language that runs on VMS and other OS, then
having same source code and putting stuff like this in
the build script makes sense to me (the build scripts
tend to be platform specific no matter what.

Arne

On 10/19/2023 9:10 PM, Arne Vajhøj wrote:
> On 10/19/2023 8:42 PM, Dave Froble wrote:
>> On 10/19/2023 6:59 PM, Arne Vajhøj wrote:
>>> On 10/19/2023 1:03 AM, Dave Froble wrote:
>>>> On 10/18/2023 2:34 PM, Arne Vajhøj wrote:
>>>>> I think it would be nice if such info could be stored
>>>>> in P0 space, put in an EXE via link option and moved from
>>>>> EXE to P0 space at image activation.
>>>>>
>>>>> But I don't know enough to say whether that would really work.
>>>>
>>>> Look at the Basic OPTION statement ...
>>>>
>>>> It is two things, a compile time directive, and contained within the program.
>>>
>>> That would mean changes to all compilers.
>>>
>>> And I also think it is cleaner to have it outside
>>> the source code.
>>
>> I think it's insane to have it outside the application. What can happen if
>> any of the logicals aren't set appropriately?
>
> I do want it in the application. Just in the build script
> not in the source code.

Does a build script always exist for every computer the application is running on?

> It does not matter much for VMS Basic as it will only
> run on VMS.

Perhaps a good thing?

> But for a language that runs on VMS and other OS, then
> having same source code and putting stuff like this in
> the build script makes sense to me (the build scripts
> tend to be platform specific no matter what.
>
> Arne
>
>

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Den 2023-10-20 kl. 05:15, skrev Dave Froble:
> On 10/19/2023 9:10 PM, Arne Vajhøj wrote:
>> On 10/19/2023 8:42 PM, Dave Froble wrote:
>>> On 10/19/2023 6:59 PM, Arne Vajhøj wrote:
>>>> On 10/19/2023 1:03 AM, Dave Froble wrote:
>>>>> On 10/18/2023 2:34 PM, Arne Vajhøj wrote:
>>>>>> I think it would be nice if such info could be stored
>>>>>> in P0 space, put in an EXE via link option and moved from
>>>>>> EXE to P0 space at image activation.
>>>>>>
>>>>>> But I don't know enough to say whether that would really work.
>>>>>
>>>>> Look at the Basic OPTION statement ...
>>>>>
>>>>> It is two things, a compile time directive, and contained within the
>>>>> program.
>>>>
>>>> That would mean changes to all compilers.
>>>>
>>>> And I also think it is cleaner to have it outside
>>>> the source code.
>>>
>>> I think it's insane to have it outside the application.  What can happen if
>>> any of the logicals aren't set appropriately?
>>
>> I do want it in the application. Just in the build script
>> not in the source code.
>
> Does a build script always exist for every computer the application is
> running on?

Dave, I think you are missunderstanding Arne.

You both do want the UNIX option to be in the finished EXE.
That is, having no special setup to get them when you run the EXE.

But Arne does not want them into the actual source code (since
that makes it "different" from other platforms). But rather into
the VMS-specific build script.

Still, the EXE would have them included and it run on any VMS box
without any special setup or having access to the build script.

>
>> It does not matter much for VMS Basic as it will only
>> run on VMS.
>
> Perhaps a good thing?
>
>> But for a language that runs on VMS and other OS, then
>> having same source code and putting stuff like this in
>> the build script makes sense to me (the build scripts
>> tend to be platform specific no matter what.
>>
>> Arne
>>
>>
>
>

On Friday, October 20, 2023 at 1:10:46 AM UTC+2, Arne Vajhøj wrote:
....
> That is functional equivalent of what I am suggesting.

and easy to implement. Just write a script to produce all the necessary source modules, compile them and tell the developer that at link time for feature A the object module NIX_A needs to be included and for feature B additionally the symbol NIX_B_VALUE needs to be defined. At least for the A type of features there can be an OPTIONS file.

> But the LIB$INITIALIZE mechanism is a rather
> complex mechanism.
>
> Compared to:
>
> $ LINK ... + SYS$INPUT/OPT
> NIX_OPTIONS=(xxx,yyy,zzz)
> $
>
> or even simpler:
>
> $ LINK/NIX_OPTIONS=(xxx,yyy,zzz) ...

You need to make that NIX_OPTIONS=(xxx,yyy=nnn,zzz) for a yyy features, which requires a value.

What do you want the linker to generate? Symbols the CRTL can look up at run time? Other than that would require CRTL changes, there are no symbols in main executable images. LIB$INITIALIZE code? That's probably possible but requires linker changes. The above approach seems simpler and works today.
> I want something that we can tell developers moving
> from nix to VMS to use and they can easily understand.

I understand, and I used NIX from your examples, something Germans will like :-)

On 10/20/2023 4:37 AM, Jan-Erik Söderholm wrote:
> Den 2023-10-20 kl. 05:15, skrev Dave Froble:
>> On 10/19/2023 9:10 PM, Arne Vajhøj wrote:
>>> On 10/19/2023 8:42 PM, Dave Froble wrote:
>>>> On 10/19/2023 6:59 PM, Arne Vajhøj wrote:
>>>>> On 10/19/2023 1:03 AM, Dave Froble wrote:
>>>>>> On 10/18/2023 2:34 PM, Arne Vajhøj wrote:
>>>>>>> I think it would be nice if such info could be stored
>>>>>>> in P0 space, put in an EXE via link option and moved from
>>>>>>> EXE to P0 space at image activation.
>>>>>>>
>>>>>>> But I don't know enough to say whether that would really work.
>>>>>>
>>>>>> Look at the Basic OPTION statement ...
>>>>>>
>>>>>> It is two things, a compile time directive, and contained within the program.
>>>>>
>>>>> That would mean changes to all compilers.
>>>>>
>>>>> And I also think it is cleaner to have it outside
>>>>> the source code.
>>>>
>>>> I think it's insane to have it outside the application. What can happen if
>>>> any of the logicals aren't set appropriately?
>>>
>>> I do want it in the application. Just in the build script
>>> not in the source code.
>>
>> Does a build script always exist for every computer the application is running
>> on?
>
> Dave, I think you are missunderstanding Arne.

That happens a lot with me anymore ...

:-)

You are correct, I've never used such, and therefore don't really understand the
details. If the necessary info is in the EXE, that is the important thing.

> You both do want the UNIX option to be in the finished EXE.
> That is, having no special setup to get them when you run the EXE.
>
> But Arne does not want them into the actual source code (since
> that makes it "different" from other platforms). But rather into
> the VMS-specific build script.
>
> Still, the EXE would have them included and it run on any VMS box
> without any special setup or having access to the build script.
>
>
>>
>>> It does not matter much for VMS Basic as it will only
>>> run on VMS.
>>
>> Perhaps a good thing?
>>
>>> But for a language that runs on VMS and other OS, then
>>> having same source code and putting stuff like this in
>>> the build script makes sense to me (the build scripts
>>> tend to be platform specific no matter what.
>>>
>>> Arne
>>>
>>>
>>
>>
>

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 10/19/2023 11:15 PM, Dave Froble wrote:
> On 10/19/2023 9:10 PM, Arne Vajhøj wrote:
>> On 10/19/2023 8:42 PM, Dave Froble wrote:
>>> On 10/19/2023 6:59 PM, Arne Vajhøj wrote:
>>>> On 10/19/2023 1:03 AM, Dave Froble wrote:
>>>>> On 10/18/2023 2:34 PM, Arne Vajhøj wrote:
>>>>>> I think it would be nice if such info could be stored
>>>>>> in P0 space, put in an EXE via link option and moved from
>>>>>> EXE to P0 space at image activation.
>>>>>>
>>>>>> But I don't know enough to say whether that would really work.
>>>>>
>>>>> Look at the Basic OPTION statement ...
>>>>>
>>>>> It is two things, a compile time directive, and contained within
>>>>> the program.
>>>>
>>>> That would mean changes to all compilers.
>>>>
>>>> And I also think it is cleaner to have it outside
>>>> the source code.
>>>
>>> I think it's insane to have it outside the application.  What can
>>> happen if
>>> any of the logicals aren't set appropriately?
>>
>> I do want it in the application. Just in the build script
>> not in the source code.
>
> Does a build script always exist for every computer the application is
> running on?

If it is none-trivial I think so.

>> It does not matter much for VMS Basic as it will only
>> run on VMS.
>
> Perhaps a good thing?

Maybe. Maybe not. :-)

But good or bad does not change that some other languages may
have a portability requirement.

Arne