OK this is strange and maybe I've misundersood something but basically
I can't exmaine values of variables, as below.
examine usernameDebugger error in RSTTYPES\DBG$STA_SYMTYPE or session corruption
examine output_devDebugger error in RSTTYPES\DBG$STA_SYMTYPE or session corruption
Versions in use -
OpenVMS x86 V9.2-2
DEBUG V9.2-009
PASCAL: V6.3-143 (GEM 50XC4)
I have checked and I have definitely compiled the program with /DEBUG /NOOPTIMIZE, and linked using /DEBGU
Any ideas?
41: (* Declaration of lib$get_symbol *)
42: Procedure lib$get_symbol ( %DESCR symbol : Varying [$l1] of
char;
43: %DESCR value : Varying [$l2] of
char); external;
OK this is strange and maybe I've misundersood something but basically
I can't exmaine values of variables, as below.
─ SRC: module START_RECEIVER -scroll- source─────────────────────────────────────────────────────────────────
────────────────────────
39: End;
40:
41: (* Declaration of lib$get_symbol *)
42: Procedure lib$get_symbol ( %DESCR symbol : Varying [$l1] of
char;
43: %DESCR value : Varying [$l2] of
char); external;
44:
45:
46: Var
47: username : Varying [15] of char;
48: output_dev : Varying [16] of char;
49:
50: Begin
51: translate_logical('NWAY$PATH',pathname);52: translate_logical('SYS$OUTPUT',output_dev);
53: translate_logical('STARTREC$USERNAME',username);
54: username := username + '_NetV2';
55: status := $CREPRC( image := pathname + 'REC.EXE',
56: output := output_dev,
57: baspri := 3,
58: prcnam := username );
59: End.
─ OUT - output─────────────────────────────────────────────────────────────────
──────────────────────────────────────────────────────
stepped to START_RECEIVER\START_RECEIVER\%LINE 51
51: translate_logical('NWAY$PATH',pathname);
─ PROMPT -error-program- prompt─────────────────────────────────────────────────────────────────
─────────────────────────────────────
examine usernameDebugger error in RSTTYPES\DBG$STA_SYMTYPE or session corruption
examine output_devDebugger error in RSTTYPES\DBG$STA_SYMTYPE or session corruption
Versions in use -
OpenVMS x86 V9.2-2
DEBUG V9.2-009
PASCAL: V6.3-143 (GEM 50XC4)
I have checked and I have definitely compiled the program with /DEBUG /NOOPTIMIZE, and linked using /DEBGU
Any ideas?
Any ideas?
I believe debugging info has been an area where the x86-64
compilers has been let us say "a tiny bit behind".
So I would not be surprised if it is just due to
debugging info not being perfect yet.
But I guess we will need to hear John R state
whether this is supposed to work or not with that
specific version combo.
For some problems I have been debugging on Alpha,
found problem and then fixed it on x86-64 where I
saw the problem. That approach obviously require
that it is not a porting problem.
Curious. Any reason you don't do:
[inherit('sys$library:pascal$lib_routines')]
?
You will need to use all 3 arguments, but not a problem.
Example:
q : varying [255] of char;
...
lib$get_symbol('QUERY_STRING', q.body, q.length);
Did you try linking /DEBUG ?
;}
On Fri, 2024-04-05 at 00:07 +0100, Chris Townley wrote:
Did you try linking /DEBUG ?
;}
Argh. :-D. It's definitely /DEBUG.
On 4/4/2024 7:17 PM, Single Stage to Orbit wrote:
On Fri, 2024-04-05 at 00:07 +0100, Chris Townley wrote:
Did you try linking /DEBUG ?
;}
Argh. :-D. It's definitely /DEBUG.
A short time ago it was stated that some of the debugger stuff wasn't working.
Argh. :-D. It's definitely /DEBUG.
A short time ago it was stated that some of the debugger stuff
wasn't working.
It's a problem with FORTRAN as well - known issue.
On Fri, 2024-04-05 at 20:11 -0400, ken randell wrote:
A short time ago it was stated that some of the debugger stuffIt's a problem with FORTRAN as well - known issue.
wasn't working.
Which brings me to my point. Will they be sending out patches as soon
as they are ready? All these vmdk images will need sorting.
I don't think they've thought this through carefully enough.
I don't think they've thought this through carefully enough.
Based on the past then it seems likely that patches will be created
and made available via SP as soon as issues are fixed.
But CL users are different. VSI want those to get images not
kits. I don't think I have seen it stated how frequently the
image will be updated. Whether it will be an annual update
of the image so CL users will need to wait 1-12 months
forn patches or a monthly update so CL users can get patches
after 1 month (if they can live with the hassle of
image migration!) or something else.
On 4/6/2024 12:37 PM, Single Stage to Orbit wrote:
On Fri, 2024-04-05 at 20:11 -0400, ken randell wrote:
A short time ago it was stated that some of the debugger stuffIt's a problem with FORTRAN as well - known issue.
wasn't working.
Which brings me to my point. Will they be sending out patches as soon
as they are ready? All these vmdk images will need sorting.
I don't think they've thought this through carefully enough.
Based on the past then it seems likely that patches will be created
and made available via SP as soon as issues are fixed.
But CL users are different. VSI want those to get images not
kits. I don't think I have seen it stated how frequently the
image will be updated. Whether it will be an annual update
of the image so CL users will need to wait 1-12 months
forn patches or a monthly update so CL users can get patches
after 1 month (if they can live with the hassle of
image migration!) or something else.
Arne
My VM is more up to date than the VMDK
On Sat, 2024-04-06 at 19:37 +0100, Chris Townley wrote:
My VM is more up to date than the VMDK
As is mine, and it's worrying.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 416 |
Nodes: | 16 (2 / 14) |
Uptime: | 81:05:07 |
Calls: | 8,739 |
Calls today: | 2 |
Files: | 13,280 |
Messages: | 5,961,078 |