PHP on VMS x86-64 9.2-2

[Arne Vajhøj]

It exists.

But I am having a few "challenges".

The VSI kit works out of the box, but without mysqli support then it is
not that useful.

And I am having problems with the Berryman kit.

Specifically php_x86_7_4_28.zip where I have tried with both
X86VMS-LDAP-V0205-15-1.ZIP and X86VMS-LDAP-V0206-6-1.ZIP but
always get:

$ php
%DCL-W-ACTIMAGE, error activating image LDAP$LIBLBER_SHR32
-CLI-E-IMGNAME, image file
ARNE4$DKA0:[SYS0.SYSCOMMON.][SYSLIB]LDAP$LIBLBER_SHR32.EXE;1
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

Any suggestions for what version of Berryman PHP that works
with what version of VSI LDAP?

Arne

[Mark Berryman]

Post by Arne Vajhøj
It exists.
But I am having a few "challenges".
The VSI kit works out of the box, but without mysqli support then it is
not that useful.
And I am having problems with the Berryman kit.
Specifically php_x86_7_4_28.zip where I have tried with both
X86VMS-LDAP-V0205-15-1.ZIP and X86VMS-LDAP-V0206-6-1.ZIP but
$ php
%DCL-W-ACTIMAGE, error activating image LDAP$LIBLBER_SHR32
-CLI-E-IMGNAME, image file
ARNE4$DKA0:[SYS0.SYSCOMMON.][SYSLIB]LDAP$LIBLBER_SHR32.EXE;1
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
Any suggestions for what version of Berryman PHP that works
with what version of VSI LDAP?

The 7.4.28 kit was built 2 years ago and was linked against LDAP V2.5-7
(VSI-X86VMS-LDAP-V0205-7-1.ZIP).

The more recent kits split out the extensions that depend on a
particular layered product version as loadable extensions rather than
building them into the phpshr.exe image. PHP 8.1.23, for example, is
linked against LDAP V2.6-6 (X86VMS-LDAP-V0206-6-1.ZIP).

Mark Berryman

[Arne Vajhøj]

Post by Mark Berryman

Post by Arne Vajhøj
It exists.
But I am having a few "challenges".
The VSI kit works out of the box, but without mysqli support then it
is not that useful.
And I am having problems with the Berryman kit.
Specifically php_x86_7_4_28.zip where I have tried with both
X86VMS-LDAP-V0205-15-1.ZIP and X86VMS-LDAP-V0206-6-1.ZIP but
$ php
%DCL-W-ACTIMAGE, error activating image LDAP$LIBLBER_SHR32
-CLI-E-IMGNAME, image file
ARNE4$DKA0:[SYS0.SYSCOMMON.][SYSLIB]LDAP$LIBLBER_SHR32.EXE;1
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
Any suggestions for what version of Berryman PHP that works
with what version of VSI LDAP?

The 7.4.28 kit was built 2 years ago and was linked against LDAP V2.5-7
(VSI-X86VMS-LDAP-V0205-7-1.ZIP).

I don't have that or know where to get.

Post by Mark Berryman
The more recent kits split out the extensions that depend on a
particular layered product version as loadable extensions rather than
building them into the phpshr.exe image.  PHP 8.1.23, for example, is
linked against LDAP V2.6-6 (X86VMS-LDAP-V0206-6-1.ZIP).

8.1.23 works perfect.

I was planning on doing 7.4, because some of the code is
pretty old style, but 8.1 will probably be fine.

Thanks.

Regarding all the link problems - would it be better
instead of xxxxxx.EXE to distribute xxxxxx.OLB and
LINK_xxxxxx.COM and let users link in their environment?

Arne

[Lawrence D'Oliveiro]

Post by Arne Vajhøj
Regarding all the link problems - would it be better
instead of xxxxxx.EXE to distribute xxxxxx.OLB and
LINK_xxxxxx.COM and let users link in their environment?

Interesting that, while VMS was a pioneer of shared libraries in the early
days, it never progressed to developing library versioning.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
Regarding all the link problems - would it be better
instead of xxxxxx.EXE to distribute xxxxxx.OLB and
LINK_xxxxxx.COM and let users link in their environment?

Interesting that, while VMS was a pioneer of shared libraries in the early
days, it never progressed to developing library versioning.

It did.

Which is actually what is causing the problem here.

Arne

[Lawrence D'Oliveiro]

Post by Arne Vajhøj

early days, it never progressed to developing library versioning.

It did.

It’s supposed to solve problems with linking with incompatible libraries.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj

early days, it never progressed to developing library versioning.

It did.

It’s supposed to solve problems with linking with incompatible libraries.

It refuses to load the executable when only an incompatible
library is present. It does not by magic download a compatible
library.

Arne

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj

early days, it never progressed to developing library versioning.

It did.

It’s supposed to solve problems with linking with incompatible libraries.

It refuses to load the executable when only an incompatible
library is present. It does not by magic download a compatible
library.

And for those that never got to read that section of the linker
manual:

$ type hello1.for
subroutine hello
write(*,*) 'hello 1'
end
$ type hello2.for
subroutine hello
write(*,*) 'hello 2'
end
$ type main.for
program main
call hello
end
$ for hello1
$ for hello2
$ for main
$ set noon
$ def/nolog hello sys$disk:[]hello.exe
$! I am not aware of the issue
$ link/share=hello hello1 + sys$input/opt
symbol_vector=(hello=procedure)
$
$ link main + sys$input/opt
hello/share
$
$ run main
hello 1
$ link/share=hello hello2 + sys$input/opt
symbol_vector=(hello=procedure)
$
$ run main
%DCL-W-ACTIMAGE, error activating image HELLO
-CLI-E-IMGNAME, image file DKA0:[arne]hello.EXE;3
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
$! I am not willing to commit to maintaining backwards compatibility
$ link/share=hello hello1 + sys$input/opt
gsmatch=equal,1,1
symbol_vector=(hello=procedure)
$
$ link main + sys$input/opt
hello/share
$
$ run main
hello 1
$ link/share=hello hello2 + sys$input/opt
gsmatch=equal,1,2
symbol_vector=(hello=procedure)
$
$ run main
%DCL-W-ACTIMAGE, error activating image HELLO
-CLI-E-IMGNAME, image file DKA0:[arne]hello.EXE;5
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
$! I promise to maintain backwards compatibility
$ link/share=hello hello1 + sys$input/opt
gsmatch=lequal,1,1
symbol_vector=(hello=procedure)
$
$ link main + sys$input/opt
hello/share
$
$ run main
hello 1
$ link/share=hello hello2 + sys$input/opt
gsmatch=lequal,1,2
symbol_vector=(hello=procedure)
$
$ run main
hello 2
$! fake it
$ link/share=hello hello1 + sys$input/opt
gsmatch=equal,1,1
symbol_vector=(hello=procedure)
$
$ link main + sys$input/opt
hello/share
$
$ run main
hello 1
$ link/share=hello hello2 + sys$input/opt
gsmatch=equal,1,1
symbol_vector=(hello=procedure)
$
$ run main
hello 2
$! hack it
$ link/share=hello hello1 + sys$input/opt
gsmatch=always,1,1
symbol_vector=(hello=procedure)
$
$ link main + sys$input/opt
hello/share
$
$ run main
hello 1
$ link/share=hello hello2 + sys$input/opt
gsmatch=always,1,2
symbol_vector=(hello=procedure)
$
$ run main
hello 2

Arne

[Lawrence D'Oliveiro]

It does not by magic download a compatible library.

Consider, on Linux, the transition from libc.so.5 to libc.so.6.

Now, to VMS denizens, those may look like version numbers on the end. But
they’re not--at least, not in the sense that VMS uses them, as some kind
of temporary backup facility that gets wiped out by the next PURGE
command.

Because there is no PURGE command on Linux. Those are actually different
file names, installed by different packages. So programs linked against
the old libc could coexist with those built against the new one.

Furthermore, that transition happened over a quarter century ago.
Notwithstanding the enhancements to libc since then, it is likely there
will never be, or need to be, a libc.so.7. This is because the symbols
themselves now have version numbers, so programs linked against older
versions can now share the same library file with those built more
recently.

[Stephen Hoffman]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj

early days, it never progressed to developing library versioning.

It did.

It’s supposed to solve problems with linking with incompatible libraries.

Which is exactly what has happened here. An incompatible shareable
image library was found in the default path, and its activation
violated the rules the developers provided to the linker, and the
activation was blocked.

As with myriad other implementation details, implementing
upward-compatibility is complex and nuanced and interconnected, with
the choices all having trade-offs.

Solutions range from static linking, to dynamic linking and shareable
images on OpenVMS and GSMATCH, to a storage-intensive solution such as
Nix as is used by NixOS and as available on some other platforms, to
storage-intensive self-contained app bundles.

Adding to the complexity and nuance, various development projects can
be fond of making incompatible changes whether for technical reasons or
for expediency or whatever (q.v. The CADT Model, etc), as anyone
familiar with Linux or OpenSSL or other platforms and packages will
become well aware. These incompatibilities can arise at API, or ABI, or
both. OpenVMS has had a few of these breaking changes too, not the
least of which was with the BACKUP callable API. Which AFAIK never
really has been fully cleaned up, either.

In the last couple of decades, OpenVMS has gone out of its way to
effectively disable GSMATCH usage in certain of its own libraries. This
being a workaround for a mess which arises from weak tooling, and from
update practices that range from exceedingly cautious to just bad.

And as for API and ABI design consistency goals more generally, not
breaking compatibility that needs to be broken "for reasons" is
empirically a poor long-term strategy for success, too.

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro
It’s supposed to solve problems with linking with incompatible libraries.

Which is exactly what has happened here. An incompatible shareable image
library was found in the default path, and its activation violated the
rules the developers provided to the linker, and the activation was
blocked.

What happened here is known as “DLL hell”. So you see, it’s something else
Windows inherited from VMS.

[Stephen Hoffman]

Post by Lawrence D'Oliveiro

Post by Stephen Hoffman

Post by Lawrence D'Oliveiro
It’s supposed to solve problems with linking with incompatible libraries.

Which is exactly what has happened here. An incompatible shareable
image library was found in the default path, and its activation
violated the rules the developers provided to the linker, and the
activation was blocked.

What happened here is known as “DLL hell”. So you see, it’s something
else Windows inherited from VMS.

Shareables can require different versions around, yes. All platforms
have to deal with this case, too.

In the linker, in the image activator, in the installer or package
manager, and in the system and the app updates/upgrades.

For OpenVMS, I'd suggest spending some time in the linker manual and
particularly with GSMATCH details.

Page 93: https://docs.vmssoftware.com/docs/VSI_Linker_Manual.pdf

The developers coded this shareable image for an exact match only,
meaning that they were not expecting or not keeping ABI stability. Or
they didn't specify GSMATCH.

Whether that was appropriate choice here, I don't know, as I don't know
the details of the ABI here.

OpenVMS does not do well around installations and upgrades and parallel
versions, with various apps chosing their own paths here, and OpenVMS
itself chosing different paths in different cases.

[Lawrence D'Oliveiro]

Post by Stephen Hoffman
OpenVMS does not do well around installations and upgrades and parallel
versions, with various apps chosing their own paths here, and OpenVMS
itself chosing different paths in different cases.

Like I said, while VMS was a pioneer of shared libraries in the early
days, it never progressed to developing library versioning. Which (I
didn’t make clear before, I assumed it was understood) nowadays means
being able to cope with transitioning between versions.

It’s not just Linux that has a solution to this problem: the BSDs do, too,
and I believe their solution predated Linux.

Back when VMS was new, the Unixes were still trying to come to terms with
shared libraries. But they have long since surpassed the pioneer in this
regard.

[Stephen Hoffman]

Post by Lawrence D'Oliveiro

Post by Stephen Hoffman
OpenVMS does not do well around installations and upgrades and parallel
versions, with various apps chosing their own paths here, and OpenVMS
itself chosing different paths in different cases.

Like I said, while VMS was a pioneer of shared libraries in the early
days, it never progressed to developing library versioning. Which (I
didn’t make clear before, I assumed it was understood) nowadays means
being able to cope with transitioning between versions.
It’s not just Linux that has a solution to this problem: the BSDs do,
too, and I believe their solution predated Linux.
Back when VMS was new, the Unixes were still trying to come to terms
with shared libraries. But they have long since surpassed the pioneer
in this regard.

Examples of alternatives and tooling mentioned in my earlier reply,
too. And Linux is a mess here, too. This is not an easy problem.

OpenVMS is limited here both by its compatibility goals, and as this
and related areas are seemingly "below the fold" when investing time
and effort on the platform.

But you're not interested in any of this.

[John Dallman]

Post by Stephen Hoffman
Examples of alternatives and tooling mentioned in my earlier reply,
too. And Linux is a mess here, too. This is not an easy problem.
OpenVMS is limited here both by its compatibility goals, and as
this and related areas are seemingly "below the fold" when
investing time and effort on the platform.

This is very educational: I'm learning about the origins of my employer's
very painstaking maintenance methods for shared library interfaces. Those
started on VAX VMS and have been applicable to every other platform we've
supported. They do require regarding the API compatibility as a
fundamental feature, never to be busted without a very good reason.

John

[Lawrence D'Oliveiro]

They do require regarding the API compatibility as a fundamental
feature, never to be busted without a very good reason.

That practically goes without saying. The problem here is a bit more
subtle than that.

[Stephen Hoffman]

Post by John Dallman

Post by Stephen Hoffman
Examples of alternatives and tooling mentioned in my earlier reply,
too. And Linux is a mess here, too. This is not an easy problem.
OpenVMS is limited here both by its compatibility goals, and as this
and related areas are seemingly "below the fold" when investing time
and effort on the platform.

This is very educational: I'm learning about the origins of my
employer's very painstaking maintenance methods for shared library
interfaces. Those started on VAX VMS and have been applicable to every
other platform we've supported. They do require regarding the API
compatibility as a fundamental feature, never to be busted without a
very good reason.

ABI and API stability avoids a whole lot of churn elsewhere in the
general configuration, yes.

Stuff touched by this area within OpenVMS includes PCSI and VMSINSTAL,
the image activator, kitting-related tooling including VMSKITBLD, the
linker and GSMATCH obviously, and sundry other giblets. And there are
bits missing that should exist here, including security and integrity
checks. There's a lot of tooling "behind the scenes" to ensure the ABIs
and APIs and constants are verified and don't incur any incompatible
changes, too. Which the BACKUP API ran afoul of, and that for various
reasons.

There are write-ups around this general topic, with various different
ways to cope with deploying breaking changes. This includes write-ups
for OpenVMS and other platforms, and around ABI and API stability more
generally.

The whole purpose for itemlists is easing ABI stability for instance,
with a newer syntactic abstraction for that same general ABI
requirement being a message-passing ABI; OOP. A decently-designed OO
scheme has the advantage of flexibility, and also of getting rid of
shedloads of glue code, too. As useful as they are, OpenVMS itemlists
are also a whole lot of glue, too. That OpenVMS still doesn't have
support for itemlists on either the calling or called end—past the
likes of BLISS and MACRO32 macros and ilk—is inexplicable too, but most
of fifty years on is also now largely irrelevent.

OpenVMS uses the same strategy as Linux in some areas, particularly
around open-source libraries that can or do make breaking changes. And
as mentioned, OpenVMS goes out of its way to disable use of GSMATCH in
some areas.

The downsides of ABI and API stability include cost and effort involved
in ensuring compatibility, and the limitations on what can change.
There are parts of OpenVMS that just can't be fixed without breaking
the ABI and API. One area I've referenced before: UAI$_PWD

As mentioned up-thread, the approach used by Nix is probably the
(cleanest? most flexible? least constraining?) of what is currently
available for managing apps and app versions, though one of the
trade-offs there is storage. Embedding the dependencies into the app is
another, though eventually the system ABI usually has to change, too.
Or inevitably.

[Lawrence D'Oliveiro]

Post by Stephen Hoffman
ABI and API stability avoids a whole lot of churn elsewhere in the
general configuration, yes.

What the *nix folks do is bite the bullet and make breaking ABI changes
every now and then: a public structure might gain extra fields, a type
like time_t might need to change from 32 bits to 64 bits (even on 32-bit
systems, to avoid the year-2038 problem), and so on.

So code compiled against the new version of the library picks up the new
definitions, while binaries built against the old version continue to work
unchanged.

[Dave Froble]

Post by John Dallman

Post by Stephen Hoffman
Examples of alternatives and tooling mentioned in my earlier reply,
too. And Linux is a mess here, too. This is not an easy problem.
OpenVMS is limited here both by its compatibility goals, and as
this and related areas are seemingly "below the fold" when
investing time and effort on the platform.

This is very educational: I'm learning about the origins of my employer's
very painstaking maintenance methods for shared library interfaces. Those
started on VAX VMS and have been applicable to every other platform we've
supported. They do require regarding the API compatibility as a
fundamental feature, never to be busted without a very good reason.
John

After having some experience with RTLs in VMS, WEENDOZE seemed to me to be a bit
lacking.

Ok, a confession. I have a database product which has a couple RTLs and a
couple files for linking. I attribute my placing them in SYS$SHARE to laziness.
Guilty as charged. However, with logical names on VMS it is rather trivial to
associate RTLs and such with particular applications. After all, the developers
should have to do some work.

The final concept I came up with in WEENDOZE was to place such files in the same
location as the application executables.

As a general concept, the RTLs, DLLs, and such that are developer and/or used
with a particular application are indeed part of that application. Storage
should no longer be an issue. My first DEC system was a PDP11-40 RSTS system
with 8 RKK05 disk drives. Each was 2000 blocks. Thought it was great, at the
time. Today we have multi-terabyte drives. While old habits die slowly, my
opinion is use whatever storage (and memory) is required to have a well ordered
application installation. Bundle the complete application as a single entity.

While some may feel that VMS (and others) should have tools to address such,
I've found that logical names can do the job. And some work by the developer.

[Arne Vajhøj]

Post by John Dallman

Post by Stephen Hoffman
Examples of alternatives and tooling mentioned in my earlier reply,
too. And Linux is a mess here, too. This is not an easy problem.
OpenVMS is limited here both by its compatibility goals, and as
this and related areas are seemingly "below the fold" when
investing time and effort on the platform.

This is very educational: I'm learning about the origins of my employer's
very painstaking maintenance methods for shared library interfaces. Those
started on VAX VMS and have been applicable to every other platform we've
supported. They do require regarding the API compatibility as a
fundamental feature, never to be busted without a very good reason.

Ok, a confession.  I have a database product which has a couple RTLs and
a couple files for linking.  I attribute my placing them in SYS$SHARE to
laziness.  Guilty as charged.  However, with logical names on VMS it is
rather trivial to associate RTLs and such with particular applications.
After all, the developers should have to do some work.
As a general concept, the RTLs, DLLs, and such that are developer and/or
used with a particular application are indeed part of that application.
Storage should no longer be an issue.  My first DEC system was a
PDP11-40 RSTS system with 8 RKK05 disk drives.  Each was 2000 blocks.
Thought it was great, at the time.  Today we have multi-terabyte
drives.  While old habits die slowly, my opinion is use whatever storage
(and memory) is required to have a well ordered application
installation.  Bundle the complete application as a single entity.
While some may feel that VMS (and others) should have tools to address
such, I've found that logical names can do the job.  And some work by
the developer.

VMS got the version check in the image activator.

VMS allows side by side installation using logicals.

Could VMS do more? Yes. But I don't think there is a good
case to do more. The message from VMS users seems to be
that they want less not more in this area. The "please
maintain backwards compatibility and disable the version
check and I will just upgrade to latest and greatest and
it should work" seems to be what the customers want.

Arne

[Simon Clubley]

Post by Arne Vajhøj
VMS got the version check in the image activator.
VMS allows side by side installation using logicals.
Could VMS do more? Yes. But I don't think there is a good
case to do more. The message from VMS users seems to be
that they want less not more in this area. The "please
maintain backwards compatibility and disable the version
check and I will just upgrade to latest and greatest and
it should work" seems to be what the customers want.

Linux isn't perfect in this regard either.

The earliest "fun" I remember in this area was the move from the .so.5
version of the C++ (not C) ABI to the .so.6 version.

This was especially "fun" when you tried to install/build a more modern
gcc (then use it to build programs) on a version of Linux that was using
.so.5 for its own C++ libraries.

Simon.

[John Dallman]

Post by Simon Clubley
Linux isn't perfect in this regard either.
The earliest "fun" I remember in this area was the move from the
.so.5 version of the C++ (not C) ABI to the .so.6 version.

Yup. The .so.X scheme is for version numbers of the library's ABI. Enough
people fooled themselves that was adequate for the .5 to .6 change to
cause serious difficulties.

It's notable that the GCC and glibc projects responded with the "version
every signature change of each symbol" they use now, meaning that the
.so.6 version of the C++ ABI is likely to continue forever. However, this
(a) requires scrupulous attention to detail and (b) requires an OS with
symbol versioning support built into the linker, loader, etc.

Linux has symbol versioning; Windows lacks it, although it has a bodged
solution for the C/C++ run-time.

John

[Arne Vajhøj]

Post by John Dallman

Post by Simon Clubley
Linux isn't perfect in this regard either.
The earliest "fun" I remember in this area was the move from the
.so.5 version of the C++ (not C) ABI to the .so.6 version.

Yup. The .so.X scheme is for version numbers of the library's ABI. Enough
people fooled themselves that was adequate for the .5 to .6 change to
cause serious difficulties.
It's notable that the GCC and glibc projects responded with the "version
every signature change of each symbol" they use now, meaning that the
.so.6 version of the C++ ABI is likely to continue forever. However, this
(a) requires scrupulous attention to detail and (b) requires an OS with
symbol versioning support built into the linker, loader, etc.

For those very interested in details:

https://www.cs.dartmouth.edu/~sergey/cs258/ABI/UlrichDrepper-How-To-Write-Shared-Libraries.pdf

Arne

[Single Stage to Orbit]

Post by Arne Vajhøj
 
https://www.cs.dartmouth.edu/~sergey/cs258/ABI/UlrichDrepper-How-To-Write-Shared-Libraries.pdf

Ooh, Ulrich Drepper. Blast from the past indeed. Famously rage quit
because other glibc2 developers wanted to take the glibc library in
another direction.

[Single Stage to Orbit]

Post by Simon Clubley
Linux isn't perfect in this regard either.
The earliest "fun" I remember in this area was the move from the
.so.5 version of the C++ (not C) ABI to the .so.6 version.
This was especially "fun" when you tried to install/build a more
modern gcc (then use it to build programs) on a version of Linux that
was using .so.5 for its own C++ libraries.

I had to manually patch and build my way from libc5 to glibc2. Nerve
wracking but worth it.

[Lawrence D'Oliveiro]

Post by Arne Vajhøj
VMS allows side by side installation using logicals.

Having to define different logical names before running each particular
executable just seems a clunky way of doing it.

[Dave Froble]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
VMS allows side by side installation using logicals.

Having to define different logical names before running each particular
executable just seems a clunky way of doing it.

In a decent implementation, the user environment sets up the logicals.
LOGIN.COM (or another command file) is part of the application.

[Lawrence D'Oliveiro]

Post by Stephen Hoffman
Linux is a mess here, too.

The *nixes manage to cope with greater complexity than VMS can manage.

[Dave Froble]

Post by Lawrence D'Oliveiro

Post by Stephen Hoffman
Linux is a mess here, too.

The *nixes manage to cope with greater complexity than VMS can manage.

That's kind of arbitrary, in my opinion. The corollary is that VMS just might
do some things a bit better than other OSs. Might depend upon your definition
of complex.

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Mark Berryman
The more recent kits split out the extensions that depend on a
particular layered product version as loadable extensions rather than
building them into the phpshr.exe image.  PHP 8.1.23, for example, is
linked against LDAP V2.6-6 (X86VMS-LDAP-V0206-6-1.ZIP).

8.1.23 works perfect.

Pretty well anyway.

My DIY stuff runs.

I can get a ZF 3 app to run.

But a Laravel 9 app gives me:

$ php artisan serve
zend_mm_heap corrupted

:-(

Arne

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Arne Vajhøj

Post by Mark Berryman
The more recent kits split out the extensions that depend on a
particular layered product version as loadable extensions rather than
building them into the phpshr.exe image.  PHP 8.1.23, for example, is
linked against LDAP V2.6-6 (X86VMS-LDAP-V0206-6-1.ZIP).

8.1.23 works perfect.

Pretty well anyway.
My DIY stuff runs.
I can get a ZF 3 app to run.
$ php artisan serve
zend_mm_heap corrupted
:-(

Slim 4 also runs.

Arne

[Mark Berryman]

Post by Arne Vajhøj

Post by Arne Vajhøj

Post by Mark Berryman
The more recent kits split out the extensions that depend on a
particular layered product version as loadable extensions rather than
building them into the phpshr.exe image.  PHP 8.1.23, for example, is
linked against LDAP V2.6-6 (X86VMS-LDAP-V0206-6-1.ZIP).

8.1.23 works perfect.

Pretty well anyway.
My DIY stuff runs.
I can get a ZF 3 app to run.
$ php artisan serve
zend_mm_heap corrupted

If you would, please define USE_ZEND_ALLOC to 0 and let me know if that
makes a difference.

Mark Berryman

[Arne Vajhøj]

Post by Mark Berryman

Post by Arne Vajhøj

Post by Arne Vajhøj

Post by Mark Berryman
The more recent kits split out the extensions that depend on a
particular layered product version as loadable extensions rather
than building them into the phpshr.exe image.  PHP 8.1.23, for
example, is linked against LDAP V2.6-6 (X86VMS-LDAP-V0206-6-1.ZIP).

8.1.23 works perfect.

Pretty well anyway.
My DIY stuff runs.
I can get a ZF 3 app to run.
$ php artisan serve
zend_mm_heap corrupted

If you would, please define USE_ZEND_ALLOC to 0 and let me know if that
makes a difference.

It makes a difference. Instead of that error it just exits
without any error message.

:-(

$ php artisan serve
zend_mm_heap corrupted
$ USE_ZEND_ALLOC=0
$ php artisan serve
$

where the expected is:

C:\Work\VMS\lar3>php artisan serve

INFO Server running on [http://127.0.0.1:8000].

Press Ctrl+C to stop the server

Arne

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Mark Berryman

Post by Arne Vajhøj

Post by Arne Vajhøj

Post by Mark Berryman
The more recent kits split out the extensions that depend on a
particular layered product version as loadable extensions rather
than building them into the phpshr.exe image.  PHP 8.1.23, for
example, is linked against LDAP V2.6-6 (X86VMS-LDAP-V0206-6-1.ZIP).

8.1.23 works perfect.

Pretty well anyway.
My DIY stuff runs.
I can get a ZF 3 app to run.
$ php artisan serve
zend_mm_heap corrupted

If you would, please define USE_ZEND_ALLOC to 0 and let me know if
that makes a difference.

It makes a difference. Instead of that error it just exits
without any error message.
:-(
$ php artisan serve
zend_mm_heap corrupted
$ USE_ZEND_ALLOC=0
$ php artisan serve
$
C:\Work\VMS\lar3>php artisan serve
   INFO  Server running on [http://127.0.0.1:8000].
  Press Ctrl+C to stop the server

But it is not necessarily bad.

The new error (it is an error despite no error message)
could be a VMS permission / record format problem unlike
the "zend_mm_heap corrupted" error that looks like a
problem in C code.

Arne

[Simon Clubley]

Post by Arne Vajhøj
But it is not necessarily bad.
The new error (it is an error despite no error message)
could be a VMS permission / record format problem unlike
the "zend_mm_heap corrupted" error that looks like a
problem in C code.

If that's the case, you could try using the undocumented file watch
command that traces XQP access. That might give you some clues.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Arne Vajhøj
But it is not necessarily bad.
The new error (it is an error despite no error message)
could be a VMS permission / record format problem unlike
the "zend_mm_heap corrupted" error that looks like a
problem in C code.

If that's the case, you could try using the undocumented file watch
command that traces XQP access. That might give you some clues.

It gives a lot of output.

:-)

But I did see a few 0x00000910 (NOSUCHFILE).

So now I am wondering if a Laravel install is
platform specific.

I installed on Windows, zipped, transferred to
VMS and unzipped.

Does anyone know if composer runs on VMS?

Arne

[Arne Vajhøj]

Post by Arne Vajhøj
Does anyone know if composer runs on VMS?

Apparently not.

PHP Fatal error: Uncaught PharException: manifest cannot be larger than
100 MB in phar "/disk0/www/lar4/composer.phar" in /disk0/w
ww/lar4/composer.phar:28
Stack trace:
#0 /disk0/www/lar4/composer.phar(28): Phar::mapPhar('composer.phar')
#1 {main}
thrown in /disk0/www/lar4/composer.phar on line 28

Arne

[Robert A. Brooks]

Post by Arne Vajhøj

Post by Simon Clubley

Post by Arne Vajhøj
But it is not necessarily bad.
The new error (it is an error despite no error message)
could be a VMS permission / record format problem unlike
the "zend_mm_heap corrupted" error that looks like a
problem in C code.

If that's the case, you could try using the undocumented file watch
command that traces XQP access. That might give you some clues.

It gives a lot of output.

Which command did you use

$ set watch file /class = major
or
$ set watch file /class = all

I always start with the first command, and only
use the heavy hammer when needed.

[Arne Vajhøj]

Post by Robert A. Brooks

Post by Arne Vajhøj

Post by Simon Clubley

Post by Arne Vajhøj
But it is not necessarily bad.
The new error (it is an error despite no error message)
could be a VMS permission / record format problem unlike
the "zend_mm_heap corrupted" error that looks like a
problem in C code.

If that's the case, you could try using the undocumented file watch
command that traces XQP access. That might give you some clues.

It gives a lot of output.

Which command did you use
$ set watch file /class = major
             or
$ set watch file /class = all
I always start with the first command, and only
use the heavy hammer when needed.

I also used MAJOR.

But Laravel is a big framework. One view, one controller
and two domain classes plus the framework is over 8700
files.

:-(

Arne

[Lawrence D'Oliveiro]

But Laravel is a big framework. One view, one controller and two domain
classes plus the framework is over 8700 files.

I don’t think it does WebSockets.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

But Laravel is a big framework. One view, one controller and two domain
classes plus the framework is over 8700 files.

I don’t think it does WebSockets.

Not with just laravel/laravel.

But add beyondcode/laravel-websockets and it is ready.

Arne

[Lawrence D'Oliveiro]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

But Laravel is a big framework. One view, one controller and two
domain classes plus the framework is over 8700 files.

I don’t think it does WebSockets.

Not with just laravel/laravel.
But add beyondcode/laravel-websockets and it is ready.

Interesting that the WebSocket server seems to need its own listening port
<https://beyondco.de/docs/laravel-websockets/basic-usage/starting>. So
it’s not integrated into the regular HTTP control flow, the way a Python-
based ASGI framework would do.

[Simon Clubley]

Post by Arne Vajhøj
It exists.
But I am having a few "challenges".
The VSI kit works out of the box, but without mysqli support then it is
not that useful.

That needs to be fixed. IMHO, without mysqli, it is a usable kit in name only.

Simon.