• Debugging a Pascal program under VMS V9.2-2

    From Single Stage to Orbit@21:1/5 to All on Thu Apr 4 23:26:17 2024
    T0sgdGhpcyBpcyBzdHJhbmdlIGFuZCBtYXliZSBJJ3ZlIG1pc3VuZGVyc29vZCBzb21ldGhpbmcg YnV0IGJhc2ljYWxseQpJIGNhbid0IGV4bWFpbmUgdmFsdWVzIG9mIHZhcmlhYmxlcywgYXMgYmVs b3cuIAoK4pSAIFNSQzogbW9kdWxlIFNUQVJUX1JFQ0VJVkVSIC1zY3JvbGwtCnNvdXJjZeKUgOKU gOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKU gOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKU gOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKU gOKUgOKUgOKUgOKUgOKUgOKUgArilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDi lIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIAKICAgIDM5OiBFbmQ7CiAgICA0MDoK ICAgIDQxOiAoKiBEZWNsYXJhdGlvbiBvZiBsaWIkZ2V0X3N5bWJvbCAqKQogICAgNDI6IFByb2Nl ZHVyZSBsaWIkZ2V0X3N5bWJvbCAoICVERVNDUiBzeW1ib2wgOiBWYXJ5aW5nIFskbDFdIG9mCmNo YXI7CiAgICA0MzogICAgICAgICAgICAgICAgICAgICAgICAgICAgJURFU0NSIHZhbHVlICA6IFZh cnlpbmcgWyRsMl0gb2YKY2hhcik7IGV4dGVybmFsOwogICAgNDQ6CiAgICA0NToKICAgIDQ2OiBW YXIKICAgIDQ3OiAgIHVzZXJuYW1lIDogVmFyeWluZyBbMTVdIG9mIGNoYXI7CiAgICA0ODogICBv dXRwdXRfZGV2IDogVmFyeWluZyBbMTZdIG9mIGNoYXI7CiAgICA0OToKICAgIDUwOiBCZWdpbgot PiAgNTE6ICAgdHJhbnNsYXRlX2xvZ2ljYWwoJ05XQVkkUEFUSCcscGF0aG5hbWUpOwogICAgNTI6 ICAgdHJhbnNsYXRlX2xvZ2ljYWwoJ1NZUyRPVVRQVVQnLG91dHB1dF9kZXYpOwogICAgNTM6ICAg dHJhbnNsYXRlX2xvZ2ljYWwoJ1NUQVJUUkVDJFVTRVJOQU1FJyx1c2VybmFtZSk7CiAgICA1NDog ICB1c2VybmFtZSA6PSB1c2VybmFtZSArICdfTmV0VjInOwogICAgNTU6ICAgc3RhdHVzIDo9ICRD UkVQUkMoIGltYWdlIDo9IHBhdGhuYW1lICsgJ1JFQy5FWEUnLAogICAgNTY6ICAgICAgICAgICAg b3V0cHV0IDo9IG91dHB1dF9kZXYsCiAgICA1NzogICAgICAgICAgICBiYXNwcmkgOj0gMywKICAg IDU4OiAgICAgICAgICAgIHByY25hbSA6PSB1c2VybmFtZSApOwogICAgNTk6IEVuZC4K4pSAIE9V VCAtCm91dHB1dOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKU gOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKU gOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKU gOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgArilIDilIDilIDilIDilIDilIDilIDi lIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDi lIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDi lIDilIDilIDilIDilIDilIDilIDilIDilIAKc3RlcHBlZCB0byBTVEFSVF9SRUNFSVZFUlxTVEFS VF9SRUNFSVZFUlwlTElORSA1MQogICAgNTE6ICAgdHJhbnNsYXRlX2xvZ2ljYWwoJ05XQVkkUEFU SCcscGF0aG5hbWUpOwoKCgoKCgoKCgoKCuKUgCBQUk9NUFQgLWVycm9yLXByb2dyYW0tCnByb21w dOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKU gOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKU gOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKU gOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgArilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDi lIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDi lIDilIDilIDilIDilIDilIDilIDilIAKREJHPiBleGFtaW5lIHVzZXJuYW1lCkRlYnVnZ2VyIGVy cm9yIGluIFJTVFRZUEVTXERCRyRTVEFfU1lNVFlQRSBvciBzZXNzaW9uIGNvcnJ1cHRpb24KREJH PiBleGFtaW5lIG91dHB1dF9kZXYgCkRlYnVnZ2VyIGVycm9yIGluIFJTVFRZUEVTXERCRyRTVEFf U1lNVFlQRSBvciBzZXNzaW9uIGNvcnJ1cHRpb24KREJHPiAKREJHPiAKCgpWZXJzaW9ucyBpbiB1 c2UgLQoKT3BlblZNUyB4ODYgVjkuMi0yCkRFQlVHIFY5LjItMDA5ClBBU0NBTDogVjYuMy0xNDMg KEdFTSA1MFhDNCkKCkkgaGF2ZSBjaGVja2VkIGFuZCBJIGhhdmUgZGVmaW5pdGVseSBjb21waWxl ZCB0aGUgcHJvZ3JhbSB3aXRoIC9ERUJVRwovTk9PUFRJTUlaRSwgYW5kIGxpbmtlZCB1c2luZyAv REVCR1UKCkFueSBpZGVhcz8KLS0gClRhY3RpY2FsIE51Y2xlYXIgS2l0dGVucwo=

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Single Stage to Orbit on Thu Apr 4 18:52:15 2024
    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Single Stage to Orbit on Thu Apr 4 18:55:29 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Townley@21:1/5 to Single Stage to Orbit on Fri Apr 5 00:07:41 2024
    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─────────────────────────────────────────────────────────────────
    ─────────────────────────────────────
    examine username
    Debugger error in RSTTYPES\DBG$STA_SYMTYPE or session corruption
    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?


    Did you try linking /DEBUG ?

    ;}

    --
    Chris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to All on Fri Apr 5 00:15:02 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to All on Fri Apr 5 00:16:24 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to Chris Townley on Fri Apr 5 00:17:25 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave Froble@21:1/5 to Single Stage to Orbit on Fri Apr 5 01:05:57 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ken randell@21:1/5 to Dave Froble on Fri Apr 5 20:11:13 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to ken randell on Sat Apr 6 17:37:27 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Single Stage to Orbit on Sat Apr 6 14:13:49 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to All on Sat Apr 6 20:07:58 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Townley@21:1/5 to All on Sat Apr 6 19:37:01 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to Chris Townley on Sat Apr 6 20:09:15 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Townley@21:1/5 to Single Stage to Orbit on Sat Apr 6 20:45:18 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)