I've been checking the VSI Service Platform to see if the x86
Community PAK got renewed over the weekend just in case they decided
to put out something to keep my x86 systems from expiring Monday (or
will things stop working at midnight? I've ever been around when a
PAK expired). All weekend there was no change - until tonight. It's
10:20 CDT and not even midnight Eastern time but my package listing
is blank. It looks like all access to x86 packages there has been revoked. At least to me.
Both letters I got from VSI mentioned continuing x86 Community
Licensing and I thought I saw someplace that said if you already had
an x86 CLP then they would automatically send an email with the new credentials/setup but re-reading both I don't see that so I'm not
sure if I imagined it or it was someplace else or that my reading comprehension failed.
It will be interesting to see what April Fool's Day brings.
On Sun, 2024-03-31 at 22:33 -0500, John H. Reinhardt wrote:
I've been checking the VSI Service Platform to see if the x86
Community PAK got renewed over the weekend just in case they decided
to put out something to keep my x86 systems from expiring Monday (or
will things stop working at midnight? I've ever been around when a
PAK expired). All weekend there was no change - until tonight. It's
10:20 CDT and not even midnight Eastern time but my package listing
is blank. It looks like all access to x86 packages there has been
revoked. At least to me.
Both letters I got from VSI mentioned continuing x86 Community
Licensing and I thought I saw someplace that said if you already had
an x86 CLP then they would automatically send an email with the new
credentials/setup but re-reading both I don't see that so I'm not
sure if I imagined it or it was someplace else or that my reading
comprehension failed.
It will be interesting to see what April Fool's Day brings.
Same here. Waiting to see what happens next.
Both letters I got from VSI mentioned continuing x86 Community Licensing
and I thought I saw someplace that said if you already had an x86 CLP
then they would automatically send an email with the new
credentials/setup but re-reading both I don't see that so I'm not sure
if I imagined it or it was someplace else or that my reading
comprehension failed.
Existing holders of community licenses for these architectures will
get updates for those licenses and retain their access to the Service
Portal until March 2025 for Alpha and December 2025 for
Integrity."[1]Â Which is odd since my community membership never got
me access to anything related to Alpha and Integrity on the portal.
On 4/1/2024 4:29 AM, Single Stage to Orbit wrote:
On Sun, 2024-03-31 at 22:33 -0500, John H. Reinhardt wrote:
I've been checking the VSI Service Platform to see if the x86
Community PAK got renewed over the weekend just in case they decided
to put out something to keep my x86 systems from expiring Monday (or
will things stop working at midnight? I've ever been around when a
PAK expired). All weekend there was no change - until tonight. It's
10:20 CDT and not even midnight Eastern time but my package listing
is blank. It looks like all access to x86 packages there has been
revoked. At least to me.
Both letters I got from VSI mentioned continuing x86 Community
Licensing and I thought I saw someplace that said if you already had
an x86 CLP then they would automatically send an email with the new
credentials/setup but re-reading both I don't see that so I'm not
sure if I imagined it or it was someplace else or that my reading
comprehension failed.
It will be interesting to see what April Fool's Day brings.
Same here. Waiting to see what happens next.
PAK wise I guess we still have today (1-APR-2024) and things will stop when the
date rolls over to 2-APR-2024. I couldn't remember if the termination date took
effect ON the date or if that was the last day.
On 3/31/24 10:33 PM, John H. Reinhardt wrote:that so I'm not sure if I imagined it or it was someplace else or that my reading comprehension failed.
Both letters I got from VSI mentioned continuing x86 Community Licensing and I thought I saw someplace that said if you already had an x86 CLP then they would automatically send an email with the new credentials/setup but re-reading both I don't see
What they said was they will send anyone who has previously applied for
an x86 license is a link to the new vmdk that already has software and licenses on it. My understanding is that the service portal is going
away for CL users and what you get on the vmdk is what you'll have until
the next one comes out the following year.
Regarding Alpha and Integrity, the announcement on the web page says, "Effective immediately, we will discontinue offering new community
licenses for non-commercial use for Alpha and Integrity. Existing
holders of community licenses for these architectures will get updates
for those licenses and retain their access to the Service Portal until
March 2025 for Alpha and December 2025 for Integrity."[1]Â Which is odd since my community membership never got me access to anything related to Alpha and Integrity on the portal.
[1] https://vmssoftware.com/about/news/2024-03-25-community-license-update/
What they said was they will send anyone who has previously applied for
an x86 license is a link to the new vmdk that already has software and >licenses on it. My understanding is that the service portal is going
away for CL users and what you get on the vmdk is what you'll have until
the next one comes out the following year.
------------------------------------------------------------------------------<
------------------------------------------------------------------------------<
Craig A. Berry wrote on 1-APR-2024 13:05:15.61
What they said was they will send anyone who has previously applied for
an x86 license is a link to the new vmdk that already has software and
licenses on it. My understanding is that the service portal is going
away for CL users and what you get on the vmdk is what you'll have until
the next one comes out the following year.
I did not get that E-mail (should have got it because I got CLP licenses). Seems no vmdk for me.
I did not get that E-mail (should have got it because I got CLP licenses). Seems no vmdk for me.
On 2024-04-02 8:57 a.m., Craig A. Berry wrote:
I did not get that E-mail (should have got it because I got CLP
licenses).
Seems no vmdk for me.
I have not gotten such an e-mail either.
It sounds like there may be many of us that have not received that email
as of yet, so we're kind of stuck.
Whether our emails are queued up, or we've been overlooked, we have no
way of knowing at this point.
I didn't receive an email for seven months; when I mentioned this on the forum I was chided for impatience and then was told I had been sent an
email. Checked entire email server logs, nothing there. I asked if it
could be resent and have had no reply.
On 3/04/2024 9:10 am, motk wrote:
I didn't receive an email for seven months; when I mentioned this on
the forum I was chided for impatience and then was told I had been
sent an email. Checked entire email server logs, nothing there. I
asked if it could be resent and have had no reply.
And ... it just appeared! Well, there's a thing.
On 2/04/2024 5:10 pm, Jouk Jansen wrote:
I did not get that E-mail (should have got it because I got CLP licenses). >> Seems no vmdk for me.
Go to https://vmssoftware.com/products/licenses/ where you'll need to reapply for the Community license for VSI OpenVMS x86_64.
I did this last Sunday and received an e-mail with download details for
the vdmk disk image on Tuesday.
Tony
On 3/04/2024 10:10 am, motk wrote:
On 3/04/2024 9:10 am, motk wrote:
I didn't receive an email for seven months; when I mentioned this on
the forum I was chided for impatience and then was told I had been
sent an email. Checked entire email server logs, nothing there. I
asked if it could be resent and have had no reply.
And ... it just appeared! Well, there's a thing.
Doing a qm import into proxmox now. I've been a bit intemperant, and I'm
not convinced in any way that this is the right thing to do with the CL,
but I'll give it a go.
On 4/3/24 10:20, motk wrote:
...
I did apparently accidentally fuzz things:
$ product list *
 Improperly handled condition, bad stack or no handler specified.
   Signal arguments:  Number = 0000000000000005
                       Name  = 000000000000000C
                                0000000000000007
                                0000000000006000
                                FFFF830007C0236B
                                0000000000000012
   Register dump:
   RAX = 0000000000000000 RDI = 000000007FF9DC80 RSI = 0000000000006000
   RDX = 5344524F5759454B RCX = 0000000000006000 R8 = 00000000FFFF8F86
   R9 = 000000000808080D RBX = 000000007FFABE00 RBP = 000000007FF9FF60
   R10 = 000000007FFABDB0 R11 = 000000007FFA4D18 R12 = 000000007FF9C0F8
   R13 = 0000000000000018 R14 = 000000007FF9C2B0 R15 = 0000000000008301
   RIP = FFFF830007C0236B RSP = 000000007FF9FF00 SS = 000000000000001B
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000000C, PC=0000000000000002, PS=7AD5D8EE
can you reproduce this ? Over and over again ?
If so, please consider to report this in the VSI Forum together with a detailled description of your underlying software/hardware and the steps
to reproduce this access violation.
https://forum.vmssoftware.com/search.php?search_id=active_topics
Am 04.04.2024 um 09:52 schrieb motk:
On 4/3/24 10:20, motk wrote:
...
I did apparently accidentally fuzz things:
$ product list *
Improperly handled condition, bad stack or no handler specified.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000007
0000000000006000
FFFF830007C0236B
0000000000000012
Register dump:
RAX = 0000000000000000 RDI = 000000007FF9DC80 RSI = 0000000000006000 >> RDX = 5344524F5759454B RCX = 0000000000006000 R8 = 00000000FFFF8F86 >> R9 = 000000000808080D RBX = 000000007FFABE00 RBP = 000000007FF9FF60 >> R10 = 000000007FFABDB0 R11 = 000000007FFA4D18 R12 = 000000007FF9C0F8 >> R13 = 0000000000000018 R14 = 000000007FF9C2B0 R15 = 0000000000008301 >> RIP = FFFF830007C0236B RSP = 000000007FF9FF00 SS = 000000000000001B >> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=000000000000000C, PC=0000000000000002, PS=7AD5D8EE
motk,
can you reproduce this ? Over and over again ?
If so, please consider to report this in the VSI Forum together with a detailled description of your underlying software/hardware and the steps
to reproduce this access violation.
https://forum.vmssoftware.com/search.php?search_id=active_topics
On 2024-04-04, Volker Halle <volker_halle@hotmail.com> wrote:
Am 04.04.2024 um 09:52 schrieb motk:
On 4/3/24 10:20, motk wrote:
...
I did apparently accidentally fuzz things:
$ product list *
 Improperly handled condition, bad stack or no handler specified.
   Signal arguments:  Number = 0000000000000005
                       Name  = 000000000000000C
                                0000000000000007
                                0000000000006000
                                FFFF830007C0236B
                                0000000000000012
   Register dump:
   RAX = 0000000000000000 RDI = 000000007FF9DC80 RSI = 0000000000006000
   RDX = 5344524F5759454B RCX = 0000000000006000 R8 = 00000000FFFF8F86
   R9 = 000000000808080D RBX = 000000007FFABE00 RBP = 000000007FF9FF60
   R10 = 000000007FFABDB0 R11 = 000000007FFA4D18 R12 = 000000007FF9C0F8
   R13 = 0000000000000018 R14 = 000000007FF9C2B0 R15 = 0000000000008301
   RIP = FFFF830007C0236B RSP = 000000007FF9FF00 SS = 000000000000001B
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=000000000000000C, PC=0000000000000002, PS=7AD5D8EE
motk,
can you reproduce this ? Over and over again ?
If so, please consider to report this in the VSI Forum together with a
detailled description of your underlying software/hardware and the steps
to reproduce this access violation.
https://forum.vmssoftware.com/search.php?search_id=active_topics
Well that's a seriously "interesting" thing to suggest Volker. :-(
Assuming the posted output has not been edited, running a user-mode program resulted in the process being killed. That means it failed in either supervisor mode or executive mode. That means VSI need to be told _privately_ about the sequence to reproduce (if it can be discovered) so that they can see if the sequence can be modified to actually exploit the system.
If that sequence is published in a public forum before VSI have analyzed
and fixed the problem, it means anyone else will be able to perform the
same analysis to see if the problem can be exploited. :-(
Simon.
On 4/04/2024 10:43 pm, Simon Clubley wrote:
Am 04.04.2024 um 09:52 schrieb motk:
On 4/3/24 10:20, motk wrote:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=000000000000000C, PC=0000000000000002, PS=7AD5D8EE
Assuming the posted output has not been edited, running a user-mode program >> resulted in the process being killed. That means it failed in either
supervisor mode or executive mode. That means VSI need to be told _privately_
about the sequence to reproduce (if it can be discovered) so that they can >> see if the sequence can be modified to actually exploit the system.
I can guarantee that output wasn't mangled in any way. I've been trying
to reproduce it with no success so far. It was an extremely surprising
result though; would it have hit a log somewhere?
On 2024-04-05, motk <meh@meh.meh> wrote:
On 4/04/2024 10:43 pm, Simon Clubley wrote:
Am 04.04.2024 um 09:52 schrieb motk:
On 4/3/24 10:20, motk wrote:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=000000000000000C, PC=0000000000000002, PS=7AD5D8EE
Assuming the posted output has not been edited, running a user-mode program >>> resulted in the process being killed. That means it failed in either
supervisor mode or executive mode. That means VSI need to be told _privately_
about the sequence to reproduce (if it can be discovered) so that they can >>> see if the sequence can be modified to actually exploit the system.
I can guarantee that output wasn't mangled in any way. I've been trying
to reproduce it with no success so far. It was an extremely surprising
result though; would it have hit a log somewhere?
The exit status on the accounting log may be interesting.
Try a "$ acc/since=<whatever>/full" and once you have found the correct session, have a look at the exit status.
Assuming the current mode bits on x86-64 in the PS register match those
on Alpha, then, assuming I am decoding the bitfield correctly, it looks
like an executive mode failure (ie: a failure in RMS itself). :-(
Can someone confirm I am decoding the current mode bits in the above
PS register correctly ?
Alex: What this would do is to turn the failure into a failure that
crashes the system (and writes a dumpfile, assuming the VSI virtual
image is setup correctly) instead of just deleting the current process.
Alex: What this would do is to turn the failure into a failure that
crashes the system (and writes a dumpfile, assuming the VSI virtual
image is setup correctly) instead of just deleting the current
process.
On Fri, 2024-04-05 at 13:20 +0000, Simon Clubley wrote:
Alex: What this would do is to turn the failure into a failure that
crashes the system (and writes a dumpfile, assuming the VSI virtual
image is setup correctly) instead of just deleting the current
process.
Who, me? I think it's actually motk with the issue, is it not?
The exit status on the accounting log may be interesting.
Try a "$ acc/since=<whatever>/full" and once you have found the correct session, have a look at the exit status.
Simon.
On 5/04/2024 10:27 pm, Simon Clubley wrote:
The exit status on the accounting log may be interesting.
Try a "$ acc/since=<whatever>/full" and once you have found the correct
session, have a look at the exit status.
This seems relevant:
Queue entry: Final status code: 1000000C
Queue name:
Job name:
Final status text: %SYSTEM-F-ACCVIO, access violation, reason mask=!XB, virtual address=!XH, PC=!XH
I remembered vaguely how to drive sysgen, and have enabled SYSTEM_CHECK
now.
On 2024-04-05, motk <meh@meh.meh> wrote:
I remembered vaguely how to drive sysgen, and have enabled SYSTEM_CHECK
now.
Is there anything in the error log ?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 403 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 04:21:59 |
| Calls: | 8,478 |
| Calls today: | 15 |
| Files: | 13,184 |
| Messages: | 5,911,899 |