开云体育

It's been ages since I debugged a user program in CMS, and I'm stumbling over things I used to remember, so I have a few questions for anyone who's got something to offer.

I have a program that has multiple SD entries, and the addresses start at X'020000' and go up. The programs were separately compiled so the displacements shown in the listings are for that particular routine->text deck->module. That is ... a module that loads at 275F0, and the instruction I want to look at is X'0A' (10 decimal) bytes in, I want to X 275FA 8, to see the code in memory, -OR- if I have defined the ORIGIN 02000, then I have to remember to really use X 075FA 8.

I can DEFINE addresses to stop at, and use BREAK to stop execution to look at the GPR and X or DUMP memory, and GO from there. These I usually remember what I have set ORIGIN to, so the BREAKs stop at the right instruction.

What I seem to keep tripping over is the use of ORIGIN. I know if it gets set to say, 020000, that value is added to the addresses I use in DEFINEs, or in X or DUMP commands. This is all well and good, until I forget, while looking at a listing to which I have written down the absolute address (the sum of the SD entry and the listing's displacement) to a command or data area. Then it becomes a game of addition and subtraction in hexadecimal, which isn't fun, yet.

SO ... when you are debugging, do you actually make use of ORIGIN, or not?
At X'000000' or X'020000' or ...?
Do you change it as you work through your program, or leave it alone?
If you change it, do you have it set to the SD value of the routine you are examining?
Or should I bias my paper calculations, as I refer to my listings?

Thanks for your help.

?... Mark S.

On Fri, 10 Feb 2023 at 21:36, Mark A. Stevens via groups.io wrote:

It's been ages since I debugged a user program in CMS, and I'm stumbling over things I used to
remember, so I have a few questions for anyone who's got something to offer.

I have a program that has multiple SD entries, and the addresses start at X'020000' and go up.
The programs were separately compiled so the displacements shown in the listings are for that
particular routine->text deck->module. That is ... a module that loads at 275F0, and the
instruction I want to look at is X'0A' (10 decimal) bytes in, I want to X 275FA 8, to see the code
in memory, -OR- if I have defined the ORIGIN 02000, then I have to remember to really use X
075FA 8.

[...]
I haven't debugged on VM of any flavour for a long time, but it seems
to me you should be able to use the START assembler directive (instead
of CSECT) to get your listings to match loaded reality. Of course
you'd have to change the address on START each time you change any
preceding module, so it's not ideal. But if you think you'll be
finding multiple bugs or generally spending a lot of time debugging
your program before rebuilding, then it might work well.

Tony H.

Hello Mark,
I did a lot of program debugging back in the day and recently with the VM/370 system. I used the ADSTOP to set a stop point and the use the CP PER and DISPLAY commands to look at storage and register content. The PER command I used was PER I RANGE nnnnnnn:xx where n is the start trace address and xx is the length of code to be traced. There are a options to step code or let it run to display to the terminal or output to a printer. With DISPLAY you can show storage and register content. You can also get the PER command to do this for every time it traps. There is a whole host of options and commands with PER its worth looking at. Also there is the TRACE command that will trap interrupts and the TRACE PROGRAM is useful to trap program abends and then use the DISPLAY command to look around.

Don’t forget to use the LOAD MAP created by the GENMOD to find the areas where you want to investigate.

Hope this is not telling you stuff you already know !

Regards,?
Martin.

On Sat, Feb 11, 2023 at 07:58 PM, Tony Harminc wrote:

I haven't debugged on VM of any flavour for a long time, but it seems
to me you should be able to use the START assembler directive (instead
of CSECT) to get your listings to match loaded reality.

I've been using LOADMOD, then set up the CMS DEBUG commands, and then issue START with the parameters I would normally pass when I just entered the module name.

I don't know if I have multiple bugs, or not, yet.

Thank you!

?... Mark S.

On Sun, Feb 12, 2023 at 02:48 PM, Martin Taylor wrote:

Hope this is not telling you stuff you already know !

Since the program is a user program, rather than CMS, I had not thought to try the CP debugging commands. That will be new ground for me.

Thank you.

?... Mark S.

Hello Mark,
I tried to use the DEBUG function but never got the hang of it. Using CP to do the debugging was the way to go. I can put together a guide outlining my method if this would be of use to you.

Regards,
Martin.

What Dave says is true but its worth looking st CP PER function as it can assist the debugging process no end.

On Mon, Feb 13, 2023 at 08:10 AM, Dave Wade wrote:

One issuette is that PER which is definitely the way?to go is a user add-on so isn't in the R6 manuals. It's way more sophisticated than the CMS debug facilites.

I remember hearing about PER, but when last debugging years ago, I got my problem solved with DEBUG, so I didn't look into it.

So the VM/370 CE V1R1.2 contains help for CP PER, and I can use that, and won't waste time scanning the manuals.

Thanks!

?... Mark S.

On Mon, Feb 13, 2023 at 07:42 AM, Martin Taylor wrote:

I can put together a guide outlining my method if this would be of use to you.

I think having someone write about PER, who has used it would be of benefit to ALL of us. Please do so at your pace.

?... Mark S.

Hello Mark,
I have sent you a PDF with some words on PER usage in program debugging. Please let me know that you have received it.

Regards,
Martin.

On Thu, Feb 23, 2023 at 10:27 AM, Martin Taylor wrote:

Please let me know that you have received it.

Found it! Just printed a copy to read.

Thanks!

?... Mark S.

In comparing notes I received from Martin, and the VM/370 CE HELP PER, I have noticed an omission in the HELP when it comes to displaying storage.

Where is the source for the PER command kept on VM/370 CE?? Failing that, where else could I find the code. I want to try to fix the omission.

?... Mark S.

On Mon, May 8, 2023 at 07:29 PM, Mark A. Stevens wrote:

Where is the source for the PER command kept on VM/370 CE?? Failing that, where else could I find the code. I want to try to fix the omission.

It is amazing what you find when you are lost. I was trying to understand instructions I received earlier, and constructed, the following without REALLY understanding what I was doing.

CP PER STORE 20348-20457 TERM RUN CMD DUMP G0:15 DUMP T20348-20457

From MAINT 5E5, to VMSETUP EXEC, to vmsetup cp, to xlist *PER* * *, to PER SCRIPT, to ... and this is the left turn CP DUMP G0:15. (I know I don't need the CP. It's there for people who know less about DUMP than I do, and I don't know a lot.)

The CP DUMP command documents the use of L and T, but not G. Still, it works.
+----------+------------------------------------------------------------------+
| DUmp???? | [0|[L|T]hexloc1 [[-|:][END hexloc2]] [*dumpid]?????????????????? |
|????????? | [[0|[L|T]hexloc1 [[.][END bytecount]] [*dumpid]????????????????? |
+----------+------------------------------------------------------------------+

So ... I've learned a lot, but do need to look into expanding the help for DUMP HELP$CP to include something about dumping general registers ... Gee, I wonder if there are other undocumented prefixes, for say, other registers?

What's another rabbit hole?

?... Mark S.