Talk about commercial or opensource products that already exist for OpenVMS or may be available in the future.
-
Topic author
issinoho
- Master
- Posts: 115
- Joined: Wed Apr 05, 2023 9:22 am
- Reputation: 0
- Location: Glasgow, Scotland
-
Status:
Offline
-
Contact:
Post
by issinoho » Wed Jan 29, 2025 1:39 pm
VSI I64VMS OPENVMS V8.4-2L3
VSIFMS V2.6
I'm rebuilding a system with an FMS based front-end and on executing the application, it immediately exits with the following.
Code: Select all
FMS STATUS: -18
RMS STATUS: 150113832
I'm pretty sure this is something fundamental that has been forgotten in the build notes but the above is not giving me many clues. Does anyone have any experience with FMS that may be able to give me a clue on investigating this?
TIA
-
lastovica@sciinc.com
- Active Contributor
- Posts: 32
- Joined: Wed May 22, 2024 5:32 pm
- Reputation: 0
- Location: colorado, usa
-
Status:
Offline
-
Contact:
Post
by lastovica@sciinc.com » Wed Jan 29, 2025 2:19 pm
issinoho wrote: ↑Wed Jan 29, 2025 1:39 pm
VSI I64VMS OPENVMS V8.4-2L3
VSIFMS V2.6
I'm rebuilding a system with an FMS based front-end and on executing the application, it immediately exits with the following.
Code: Select all
FMS STATUS: -18
RMS STATUS: 150113832
I'm pretty sure this is something fundamental that has been forgotten in the build notes but the above is not giving me many clues. Does anyone have any experience with FMS that may be able to give me a clue on investigating this?
TIA
150113832 likely refers to
%FMS-W-INVFORM, Binary form in file is invalid
Norm Lastovica / SCI
-
Topic author
issinoho
- Master
- Posts: 115
- Joined: Wed Apr 05, 2023 9:22 am
- Reputation: 0
- Location: Glasgow, Scotland
-
Status:
Offline
-
Contact:
Post
by issinoho » Wed Jan 29, 2025 3:46 pm
I've now realised that the FMS binaries were compiled with HPFMS V2.5, whilst this machine is running, VSIFMS V2.6 - would that account for this issue? i.e. is FMS not version compatible?
-
lastovica@sciinc.com
- Active Contributor
- Posts: 32
- Joined: Wed May 22, 2024 5:32 pm
- Reputation: 0
- Location: colorado, usa
-
Status:
Offline
-
Contact:
Post
by lastovica@sciinc.com » Wed Jan 29, 2025 3:51 pm
issinoho wrote: ↑Wed Jan 29, 2025 3:46 pm
I've now realised that the FMS binaries were compiled with HPFMS V2.5, whilst this machine is running, VSIFMS V2.6 - would that account for this issue? i.e. is FMS not version compatible?
I suspect that the FMS documentation has descriptions and explanations for the FMS messages. If not, you'll likely want to get in touch with VSI OpenVMS FMS support directly.
Norm Lastovica / SCI
-
hein
- Valued Contributor
- Posts: 56
- Joined: Fri Dec 25, 2020 5:20 pm
- Reputation: 0
-
Status:
Offline
Post
by hein » Thu Jan 30, 2025 9:50 am
As Norm also indicated:
Code: Select all
FMS STATUS: -18
RMS STATUS: 150113832
BULOVA> sea/win=3 sys$library:fdvdef.bas "-18"
, FDV$_IOR ! Error reading form library &
! FMS CODE = -18 &
, FDV$_IVM ! Insufficient virtual memory &
BULOVA> set mess sys$message:FDVMSG.EXE
BULOVA> exit 150113832
%FMS-W-INVFORM, Binary form in file is invalid
I'm pretty sure this is something fundamental that has been forgotten in the build notes.
I don't think this will be a version incompatibly.
More likely the binary forms or forms library file was mis-managed, or maybe pointing to the wrong file (type)?
I recommend using the FMS tools such as Forms Editor or FMS/TEST or FMS/LIBRARY to access the forms (.FRM) or library (.FLB ) that the application tries to access. Was FTP used without binary more? Logical name mixup? Are there description text file (.FLG) then rebuild library with FMS/TRANSLATE ?
Good luck.
Hein
-
Topic author
issinoho
- Master
- Posts: 115
- Joined: Wed Apr 05, 2023 9:22 am
- Reputation: 0
- Location: Glasgow, Scotland
-
Status:
Offline
-
Contact:
Post
by issinoho » Thu Jan 30, 2025 12:19 pm
Hein, thanks a million
I'd zipped up the executable files using -V and transferred in binary mode, which was good enough for the EXE files, but apparently not for the FRM and FLB files. FMS/TEST errors out on those.
So I transferred again firstly by backing up the forms files into a saveset and zipping that, transferring it in binary mode and reversing on the target machine.
This time all is good, FMS/TEST confirms format of the files, and the application now runs.
My heartiest gratitude.
-
cct
- Master
- Posts: 278
- Joined: Sat Aug 15, 2020 9:00 am
- Reputation: 0
- Location: Cambridge, UK
-
Status:
Offline
Post
by cct » Thu Jan 30, 2025 12:27 pm
That is a useful trick - I have used it many times - zipping a saveset
Chris Townley
VMS Ambassador
-
sms
- Senior Member
- Posts: 518
- Joined: Fri Aug 21, 2020 5:18 pm
- Reputation: 0
-
Status:
Offline
Post
by sms » Thu Jan 30, 2025 1:51 pm
Code: Select all
> I'd zipped up the executable files using -V and transferred in binary
> mode, which was good enough for the EXE files, but apparently not for
> the FRM and FLB files. [...]
The attributes of executable files are not tightly restricted.
I know nothing about FMS, but I'd be very interested in seeing any
files which Zip (-V) and UnZip can't handle correctly. That was (Zip)
"-V", not "-v", right?
Does BACKUP /COMPARE see a difference between the good and bad files?
Does "-VV" do any better? It shouldn't be needed with a
well-structured file, that is, with an accurate EOF marker, but if there
are significant data past EOF, then the extra "V" might be helpful.
There might also be some bugs in some old UnZip version which can
result in truncated files with unlucky data. Patches exist, but may not
be universally distributed.
-
roberbrooks
- VSI Expert
-
Valued Contributor
- Posts: 83
- Joined: Thu Jun 20, 2019 11:48 am
- Reputation: 0
- Location: Leverett, MA
-
Status:
Offline
Post
by roberbrooks » Thu Jan 30, 2025 11:18 pm
Given how much backward compatibility is baked into virtually every aspect of VMS, there is no way that we would have changed the FMS/TDMS/DECforms internals to conflict with literal decades of forms binaries.
In case anyone is looking for a *working* version of FMS on X86, as opposed to the version that's out there that does not work particularly well, we have discovered two compiler issues (one BLISS, one C) that can make FMS go sideways pretty quickly.
The first issue is related to FMS timed reads. If it times out, bad things happen. That's on the BLISS compiler. We think we understand that problem and have a working prototype that seems to work. There may be other artifacts of this problem, but that's how we were alerted to it by a customer.
The other issue is with 16-bit integers in C. That's under investigation, and is less understood right now.
Stuff compiled /NOOPT works correctly, but /OPT=LEVEL=1 does not. In FMS, this was discovered by us using the
$ FORMS/VECTOR command.
--
-- Rob