Debugging a Pascal program under VMS V9.2-2

[Single Stage to Orbit]

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─────────────────────────────────────────────────────────────────
─────────────────────────────────────
DBG> examine username
Debugger error in RSTTYPES\DBG$STA_SYMTYPE or session corruption
DBG> examine output_dev
Debugger error in RSTTYPES\DBG$STA_SYMTYPE or session corruption
DBG>
DBG>


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 /

[Arne Vajhøj]

Post by Single Stage to Orbit
OK this is strange and maybe I've misundersood something but basically
I can't exmaine values of variables, as below.
DBG> examine username
Debugger error in RSTTYPES\DBG$STA_SYMTYPE or session corruption
DBG> examine output_dev
Debugger 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?

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.

Arne

[Single Stage to Orbit]

Post by Arne Vajhøj

Post by Single Stage to Orbit
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.

Yes, it works fine on OpenVMS 7.3 under simh so not the issue.

I tested it on the VMDK VSI sent to me last week, and the issue is
definitely there. Looks like we should be looking forward to some
patches soon. :-D

[Arne Vajhøj]

Post by Single Stage to Orbit
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;

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);


Arne

[Single Stage to Orbit]

Post by Arne Vajhøj
[inherit('sys$library:pascal$lib_routines')]
?
You will need to use all 3 arguments, but not a problem.
    q : varying [255] of char;
    ...
    lib$get_symbol('QUERY_STRING', q.body, q.length);

This is old Pascal code that worked under OpenVMS 7.3 on VAX.
Maybe it does need updating. But the debugging issue is whole another
issue.

[Chris Townley]

Post by Single Stage to Orbit
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;
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;
46: Var
47: username : Varying [15] of char;
48: output_dev : Varying [16] of char;
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─────────────────────────────────────────────────────────────────
─────────────────────────────────────
DBG> examine username
Debugger error in RSTTYPES\DBG$STA_SYMTYPE or session corruption
DBG> examine output_dev
Debugger error in RSTTYPES\DBG$STA_SYMTYPE or session corruption
DBG>
DBG>
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?

Did you try linking /DEBUG ?

;}

[Single Stage to Orbit]

Post by Chris Townley
Did you try linking /DEBUG ?
;}

Argh. :-D. It's definitely /DEBUG.

[Dave Froble]

Post by Single Stage to Orbit

Post by Chris Townley
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.

[ken randell]

Post by Dave Froble

Post by Single Stage to Orbit

Post by Chris Townley
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.

It's a problem with FORTRAN as well - known issue.

[Single Stage to Orbit]

Post by ken randell

Post by Dave Froble

Post by Single Stage to Orbit
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.

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.

[Arne Vajhøj]

Post by Single Stage to Orbit

Post by ken randell

Post by Dave Froble
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.

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

[Chris Townley]

Post by Arne Vajhøj

Post by Single Stage to Orbit

Post by ken randell

Post by Dave Froble
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.

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

They stated that CL users will get a new image every year - when the
license expired.

As most of us still have access to the portal, but no longer with
anything in it, they ~may~ put up the odd fix for us if our testing is
helping them.

My VM is more up to date than the VMDK

[Single Stage to Orbit]

Post by Chris Townley
My VM is more up to date than the VMDK

As is mine, and it's worrying.

[Chris Townley]

Post by Single Stage to Orbit

Post by Chris Townley
My VM is more up to date than the VMDK

As is mine, and it's worrying.

But if you still have the packs that aren't on the VMDK, there is
nothing to stop you installing them

[Single Stage to Orbit]

Post by Arne Vajhøj

Post by Single Stage to Orbit
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.

The instructions that came with the vmdk image hinted you could add the
existing VM disk as another disk and mount it directly to work with it.

Again, I'm not sure how they intend to keep these vmdk images updated
though.

I haven't yet searched the vmdk to see if I can find anything of
interest though. I was hoping someone would forget removing the
installation kits :-D