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 /DEBGU

Any ideas?
--
Tactical Nuclear Kittens

On 4/4/2024 6:26 PM, Single Stage to Orbit wrote:
> 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

On 4/4/2024 6:26 PM, Single Stage to Orbit wrote:
> 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

On 04/04/2024 23:26, Single Stage to Orbit wrote:
> 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 /DEBGU
>
> Any ideas?

Did you try linking /DEBUG ?

;}

--
Chris

On Thu, 2024-04-04 at 18:55 -0400, Arne Vajhøj wrote:
> 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);

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.
--
Tactical Nuclear Kittens

On Thu, 2024-04-04 at 18:52 -0400, Arne Vajhøj wrote:
>
> > 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
--
Tactical Nuclear Kittens

On Fri, 2024-04-05 at 00:07 +0100, Chris Townley wrote:
> Did you try linking /DEBUG ?
>
> ;}

Argh. :-D. It's definitely /DEBUG.
--
Tactical Nuclear Kittens

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.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 4/5/2024 1:05 AM, Dave Froble wrote:
> 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.
>
It's a problem with FORTRAN as well - known issue.

On Fri, 2024-04-05 at 20:11 -0400, ken randell wrote:
> > > 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.
--
Tactical Nuclear Kittens

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

On 06/04/2024 19:13, Arne Vajhøj wrote:
> 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 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

--
Chris

On Sat, 2024-04-06 at 14:13 -0400, Arne Vajhøj wrote:
> > 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
--
Tactical Nuclear Kittens

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.
--
Tactical Nuclear Kittens

On 06/04/2024 20:09, Single Stage to Orbit wrote:
> 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.

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

--
Chris