Re: Assembler - Authorized program debug

[David Crayford]

I devoted a weekend to learn Vim and by the end of it was proficient. In 
the years since I've bonded with it to stage where I really struggle 
when I go back to ISPF. Luckily my emulator (Vista) supports keyboard 
shortcuts like CNTL+D to delete words, CNTL+left/CNTL+right to jump 
words and CNTL+E to jump to the end-of-line.


Vim is only useful if you can touch type. If you have to look at the 
keyboard it's not worth the effort.


On 1/03/2021 3:46 am, Tom Brennan wrote:
Thanks! I really need just take a couple of hours and learn about it, 
instead of always just jumping in without a bit it self-training.


On 2/27/2021 11:45 PM, David Crayford wrote:

On 27/02/2021 8:22 am, Tom Brennan wrote:

You take that back!! :)

Sorry... I just used vi a minute ago and although I finally 
remembered shift-g to move to the bottom, I had to goggle how to 
move back to the top.  gg  Of course! It's so obvious. 



:1 will also jump to the top. 'g' isn't a command, it's used to 
escape although people assume it's goto as it's used to jump around 
the buffer.


I can remember when I first started learning vim I didn't find it 
particularly intuitive. Once I got over the initial learning curve it 
all made perfect sense. People like vim because its design philosophy 
echos that of Unix. In both Unix and in vim, you have a collection of 
atomic commands that perform one task well. More complicated tasks 
are done by combining the smaller predefined tasks. For example, the 
vim command dl deletes the next character,  dw deletes the next word, 
and db deletes the previous word. Here, d represents the delete 
operator and must be followed by a movement task. lt means move to 
the next character. w for the next word and b for the previous word. 
d2b will delete the previous 2 words. dtx will delete every character 
up to the next x in the current line.  Once you grok this you won't 
want to use another editor as you will find them unproductive. I also 
use Slickedit and Intellij IDEA and I have Vim emulation running in 
both. The key design is maximum economy of keystrokes. Your hand 
should be glued to the home row. I've remapped the Windows caps lock 
key to ESC (single key) and CNTL (multiple keys) to make this easier.


BTW, no need to google. Vim has excellent help. Just type :h motion 
and use CNTL-] to follow links.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Tom Brennan]

Thanks!  I really need just take a couple of hours and learn about it, 
instead of always just jumping in without a bit it self-training.


On 2/27/2021 11:45 PM, David Crayford wrote:

On 27/02/2021 8:22 am, Tom Brennan wrote:

You take that back!! :)

Sorry... I just used vi a minute ago and although I finally remembered 
shift-g to move to the bottom, I had to goggle how to move back to the 
top.  gg  Of course! It's so obvious. 



:1 will also jump to the top. 'g' isn't a command, it's used to escape 
although people assume it's goto as it's used to jump around the buffer.


I can remember when I first started learning vim I didn't find it 
particularly intuitive. Once I got over the initial learning curve it 
all made perfect sense. People like vim because its design philosophy 
echos that of Unix. In both Unix and in vim, you have a collection of 
atomic commands that perform one task well. More complicated tasks are 
done by combining the smaller predefined tasks. For example, the vim 
command dl deletes the next character,  dw deletes the next word, and db 
deletes the previous word. Here, d represents the delete operator and 
must be followed by a movement task. lt means move to the next 
character. w for the next word and b for the previous word. d2b will 
delete the previous 2 words. dtx will delete every character up to the 
next x in the current line.  Once you grok this you won't want to use 
another editor as you will find them unproductive. I also use Slickedit 
and Intellij IDEA and I have Vim emulation running in both. The key 
design is maximum economy of keystrokes. Your hand should be glued to 
the home row. I've remapped the Windows caps lock key to ESC (single 
key) and CNTL (multiple keys) to make this easier.


BTW, no need to google. Vim has excellent help. Just type :h motion and 
use CNTL-] to follow links.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Seymour J Metz]

There are many ISPF, Wylbur and XEDIT clones; I don't know of one that can't 
deal with column ranges. There are even some free clones.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Spiegel [dspiegel...@hotmail.com]
Sent: Sunday, February 28, 2021 6:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler - Authorized program debug

Hi David,
I like VI(m) too.
I'd like to point out, however, that ISPF and XEDIT allow the user to
restrict edits to a column range.
This capability AFAIK is ONLY available on Mainframe.

Regards,
David

On 2021-02-28 02:45, David Crayford wrote:
> On 27/02/2021 8:22 am, Tom Brennan wrote:
>> You take that back!! :)
>>
>> Sorry... I just used vi a minute ago and although I finally
>> remembered shift-g to move to the bottom, I had to goggle how to move
>> back to the top.  gg  Of course! It's so obvious.
>
>
> :1 will also jump to the top. 'g' isn't a command, it's used to escape
> although people assume it's goto as it's used to jump around the buffer.
>
> I can remember when I first started learning vim I didn't find it
> particularly intuitive. Once I got over the initial learning curve it
> all made perfect sense. People like vim because its design philosophy
> echos that of Unix. In both Unix and in vim, you have a collection of
> atomic commands that perform one task well. More complicated tasks are
> done by combining the smaller predefined tasks. For example, the vim
> command dl deletes the next character,  dw deletes the next word, and
> db deletes the previous word. Here, d represents the delete operator
> and must be followed by a movement task. lt means move to the next
> character. w for the next word and b for the previous word. d2b will
> delete the previous 2 words. dtx will delete every character up to the
> next x in the current line.  Once you grok this you won't want to use
> another editor as you will find them unproductive. I also use
> Slickedit and Intellij IDEA and I have Vim emulation running in both.
> The key design is maximum economy of keystrokes. Your hand should be
> glued to the home row. I've remapped the Windows caps lock key to ESC
> (single key) and CNTL (multiple keys) to make this easier.
>
> BTW, no need to google. Vim has excellent help. Just type :h motion
> and use CNTL-] to follow links.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[René Jansen]

If you like ISPF (like me!) have a look at LSPF at 
https://github.com/daniel64/lspf . 

If it seems tricky to build, I have a Docker container at 
https://hub.docker.com/r/rvjansen/lspf/tags?page=1=last_updated

René 

> On 28 Feb 2021, at 12:04, David Spiegel  wrote:
> 
> Hi David,
> I like VI(m) too.
> I'd like to point out, however, that ISPF and XEDIT allow the user to 
> restrict edits to a column range.
> This capability AFAIK is ONLY available on Mainframe.
> 
> Regards,
> David
> 
>> On 2021-02-28 02:45, David Crayford wrote:
>>> On 27/02/2021 8:22 am, Tom Brennan wrote:
>>> You take that back!! :)
>>> 
>>> Sorry... I just used vi a minute ago and although I finally remembered 
>>> shift-g to move to the bottom, I had to goggle how to move back to the top. 
>>>  gg  Of course! It's so obvious. 
>> 
>> 
>> :1 will also jump to the top. 'g' isn't a command, it's used to escape 
>> although people assume it's goto as it's used to jump around the buffer.
>> 
>> I can remember when I first started learning vim I didn't find it 
>> particularly intuitive. Once I got over the initial learning curve it all 
>> made perfect sense. People like vim because its design philosophy echos that 
>> of Unix. In both Unix and in vim, you have a collection of atomic commands 
>> that perform one task well. More complicated tasks are done by combining the 
>> smaller predefined tasks. For example, the vim command dl deletes the next 
>> character,  dw deletes the next word, and db deletes the previous word. 
>> Here, d represents the delete operator and must be followed by a movement 
>> task. lt means move to the next character. w for the next word and b for the 
>> previous word. d2b will delete the previous 2 words. dtx will delete every 
>> character up to the next x in the current line.  Once you grok this you 
>> won't want to use another editor as you will find them unproductive. I also 
>> use Slickedit and Intellij IDEA and I have Vim emulation running in both. 
>> The key design is maximum economy of keystrokes. Your hand should be glued 
>> to the home row. I've remapped the Windows caps lock key to ESC (single key) 
>> and CNTL (multiple keys) to make this easier.
>> 
>> BTW, no need to google. Vim has excellent help. Just type :h motion and use 
>> CNTL-] to follow links.
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> .
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[David Spiegel]

Hi David,
I like VI(m) too.
I'd like to point out, however, that ISPF and XEDIT allow the user to 
restrict edits to a column range.

This capability AFAIK is ONLY available on Mainframe.

Regards,
David

On 2021-02-28 02:45, David Crayford wrote:

On 27/02/2021 8:22 am, Tom Brennan wrote:

You take that back!! :)

Sorry... I just used vi a minute ago and although I finally 
remembered shift-g to move to the bottom, I had to goggle how to move 
back to the top.  gg  Of course! It's so obvious. 



:1 will also jump to the top. 'g' isn't a command, it's used to escape 
although people assume it's goto as it's used to jump around the buffer.


I can remember when I first started learning vim I didn't find it 
particularly intuitive. Once I got over the initial learning curve it 
all made perfect sense. People like vim because its design philosophy 
echos that of Unix. In both Unix and in vim, you have a collection of 
atomic commands that perform one task well. More complicated tasks are 
done by combining the smaller predefined tasks. For example, the vim 
command dl deletes the next character,  dw deletes the next word, and 
db deletes the previous word. Here, d represents the delete operator 
and must be followed by a movement task. lt means move to the next 
character. w for the next word and b for the previous word. d2b will 
delete the previous 2 words. dtx will delete every character up to the 
next x in the current line.  Once you grok this you won't want to use 
another editor as you will find them unproductive. I also use 
Slickedit and Intellij IDEA and I have Vim emulation running in both. 
The key design is maximum economy of keystrokes. Your hand should be 
glued to the home row. I've remapped the Windows caps lock key to ESC 
(single key) and CNTL (multiple keys) to make this easier.


BTW, no need to google. Vim has excellent help. Just type :h motion 
and use CNTL-] to follow links.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[David Crayford]

On 27/02/2021 8:22 am, Tom Brennan wrote:

You take that back!! :)

Sorry... I just used vi a minute ago and although I finally remembered 
shift-g to move to the bottom, I had to goggle how to move back to the 
top.  gg  Of course! It's so obvious. 



:1 will also jump to the top. 'g' isn't a command, it's used to escape 
although people assume it's goto as it's used to jump around the buffer.


I can remember when I first started learning vim I didn't find it 
particularly intuitive. Once I got over the initial learning curve it 
all made perfect sense. People like vim because its design philosophy 
echos that of Unix. In both Unix and in vim, you have a collection of 
atomic commands that perform one task well. More complicated tasks are 
done by combining the smaller predefined tasks. For example, the vim 
command dl deletes the next character,  dw deletes the next word, and db 
deletes the previous word. Here, d represents the delete operator and 
must be followed by a movement task. lt means move to the next 
character. w for the next word and b for the previous word. d2b will 
delete the previous 2 words. dtx will delete every character up to the 
next x in the current line.  Once you grok this you won't want to use 
another editor as you will find them unproductive. I also use Slickedit 
and Intellij IDEA and I have Vim emulation running in both. The key 
design is maximum economy of keystrokes. Your hand should be glued to 
the home row. I've remapped the Windows caps lock key to ESC (single 
key) and CNTL (multiple keys) to make this easier.


BTW, no need to google. Vim has excellent help. Just type :h motion and 
use CNTL-] to follow links.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Robert Shimizu]

Hi Don:

Bob Shimizu here, of Cole Software.  Thanks for the "plug", sir! Much 
appreciated.


Sincerely,

Bob

On 2/25/21 11:39 PM, Don Poitras wrote:

In article <9007603817792033.wa.nitzibmgmx@listserv.ua.edu> you wrote:

On Thu, 25 Feb 2021 23:57:08 -0600, Ravi Gaur  wrote:


Writing and debugging an assembler code which has MODESET instruction to change 
key and while debugging it via IDF or Debug tool both abend with S047(APF) 
issue. Anyone know a way to debug facility for code without using IDF/Debug 
tool?

Set a  slip trap on s=047 and use IPCS to read the resulting sdump.

Regards, Barbara

S047 is a side-effect of running authorized while trying to use debuggers that
aren't themselves APF-authorized. z/XDC will allow this kind of debugging. See:

https://colesoft.com/products/zxdc/components#authxdc


--

Robert W. Shimizu
Partner, Concierge
ColeSoft Marketing, Inc.
(800) 932-5150
(928) 771-2003

bshim...@colesoft.com 
www.colesoft.com 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Peter Relson]

Writing and debugging an assembler code which has MODESET instruction to 
change key and while debugging it via IDF or Debug tool both abend with 
S047(APF) issue. 


Depending on what means by debugging (for example, debugging is often 
after the fact - figuring out what went wrong from a dump and any other 
diagnostic data - versus some sort of stepping through code), this still 
seems like a curious way to word a problem.

If assembler code issues the MODESET macro, either it is done in an 
authorized environment or you are not. Either it will succeed or it will 
not. What does it mean for a tool to "abend with S047(APF) issue"? If your 
program can successfuly issue modeset, so can anything else. Now, if you 
told me that you were getting a LOAD failure because some library used by 
the debugger was not APF-authorized yet your jobstep was, that I would 
understand. Or if you told me that it was your module's MODESET that 
failed because the jobstep is not APF-authorized, I would understand.

I wouldn't think that the debuggers tamper with the authorization 
environment. 

What's the story?

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Tom Brennan]

On 2/26/2021 2:36 PM, Tony Harminc wrote:

sort of the vi of TSO ...


You take that back!! :)

Sorry... I just used vi a minute ago and although I finally remembered 
shift-g to move to the bottom, I had to goggle how to move back to the 
top.  gg  Of course! It's so obvious.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Seymour J Metz]

March 1971 is almost 50 years ago.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Harminc [t...@harminc.net]
Sent: Friday, February 26, 2021 6:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler - Authorized program debug

On Fri, 26 Feb 2021 at 18:37, Seymour J Metz  wrote:
>
> > 40 years ago
> ?

I said "(well, TEST, but the syntax is identical)". And yes, I realize
that each has an only overlapping set of subcommands and functions.

> TEST is older older and TESTAUTH is more recent.

Indeed. But not all *that* much more recent.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Tony Harminc]

On Fri, 26 Feb 2021 at 18:37, Seymour J Metz  wrote:
>
> > 40 years ago
> ?

I said "(well, TEST, but the syntax is identical)". And yes, I realize
that each has an only overlapping set of subcommands and functions.

> TEST is older older and TESTAUTH is more recent.

Indeed. But not all *that* much more recent.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Seymour J Metz]

> 40 years ago

?

TEST is older older and TESTAUTH is more recent.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Harminc [t...@harminc.net]
Sent: Friday, February 26, 2021 5:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler - Authorized program debug

On Fri, 26 Feb 2021 at 02:46, Tom Brennan  wrote:
>
> Is the TSO TESTAUTH command still around?  I have to admit I can't
> remember ever trying it.

It's still there, and works much the way it did 40 years ago.

I find I use it way more often than I would've expected. In 2021! Part
of it is that I used it (well, TEST, but the syntax is identical)
extensively way way back when, and my fingers still know what to do.
Yeah, it's clunky and has all kinds of weird restrictions, but it's
sort of the vi of TSO - always there.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Tony Harminc]

On Fri, 26 Feb 2021 at 02:46, Tom Brennan  wrote:
>
> Is the TSO TESTAUTH command still around?  I have to admit I can't
> remember ever trying it.

It's still there, and works much the way it did 40 years ago.

I find I use it way more often than I would've expected. In 2021! Part
of it is that I used it (well, TEST, but the syntax is identical)
extensively way way back when, and my fingers still know what to do.
Yeah, it's clunky and has all kinds of weird restrictions, but it's
sort of the vi of TSO - always there.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Colin Paice]

One of the best troubleshooters I know was a big photograph of a dog. This
dog had an 80% success rate!
The photo belonged to the expert, and you could only ask the expert once
you had asked the dog.
Of course everyone would roll their eyes, tut and explain their problem to
the dog.
In doing so people solved their own problems.  As I said - it had a high
success rate!

On Fri, 26 Feb 2021 at 18:03, Ramsey Hallman 
wrote:

> I agree with Syrmour's method.  When I am stumped, I'll start an email to
> my boss (the best assembler coder I know) asking what I've done wrong.
> While putting as much information into the email as possible, so he doesn't
> think I'm taking the easy way out, 99 times out of 100 I'll find my issue.
> Usually, it's something fairly minor that I've simply overlooked as
> "obviously correct" or "obviously not the area of the problem."  When I
> point this out to my boss, he usually says "desk check" your code.  But I
> live by the motto that was posted here some time in the past - Months of
> coding and debugging beats hours of desk checking any day. (or something
> very close to that LOL).
> Ramsey
>
>
>
> On Fri, Feb 26, 2021 at 11:09 AM Seymour J Metz  wrote:
>
> > With regard to Tom's second method, often *I* spot the error when I'm
> > asking for help and explaining the code. Somehow it seems to sometimes
> cure
> > a mental blind spot.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> > of Charles Mills [charl...@mcn.org]
> > Sent: Friday, February 26, 2021 11:20 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Assembler - Authorized program debug
> >
> > I really second Tom's latter method. Try walking through the code with
> > someone else -- explain to them how it works instruction by instruction.
> I
> > have good luck with that method using my wife as a sounding board -- even
> > though she doesn't know L from ST.
> >
> > I think many respondents are answering the wrong question. The OP's
> > question is not "how do I debug or prevent an S047?" He understands the
> > S047. His question is "how do I debug this code without triggering an
> > unrelated but well-deserved S047?"
> >
> > Charles
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Tom Brennan
> > Sent: Thursday, February 25, 2021 11:46 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Assembler - Authorized program debug
> >
> > Is the TSO TESTAUTH command still around?  I have to admit I can't
> > remember ever trying it.  My debugging method of such code typically
> > consisted of multiple temporary WTO's to let me know where the program
> > was at before it failed, and also display fields or registers I was
> > interested in.  Usually within a few iterations of that method, I'd
> > figure out my problem.
> >
> > Another method:  After looking at your code for hours and hours, have
> > someone else peek over your shoulder and invariably they will see the
> > problem in seconds.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Ramsey Hallman]

Sorry for the "fat fingers", Seymour.

On Fri, Feb 26, 2021 at 12:02 PM Ramsey Hallman 
wrote:

> I agree with Syrmour's method.  When I am stumped, I'll start an email to
> my boss (the best assembler coder I know) asking what I've done wrong.
> While putting as much information into the email as possible, so he doesn't
> think I'm taking the easy way out, 99 times out of 100 I'll find my issue.
> Usually, it's something fairly minor that I've simply overlooked as
> "obviously correct" or "obviously not the area of the problem."  When I
> point this out to my boss, he usually says "desk check" your code.  But I
> live by the motto that was posted here some time in the past - Months of
> coding and debugging beats hours of desk checking any day. (or something
> very close to that LOL).
> Ramsey
>
>
>
> On Fri, Feb 26, 2021 at 11:09 AM Seymour J Metz  wrote:
>
>> With regard to Tom's second method, often *I* spot the error when I'm
>> asking for help and explaining the code. Somehow it seems to sometimes cure
>> a mental blind spot.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>> 
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
>> of Charles Mills [charl...@mcn.org]
>> Sent: Friday, February 26, 2021 11:20 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Assembler - Authorized program debug
>>
>> I really second Tom's latter method. Try walking through the code with
>> someone else -- explain to them how it works instruction by instruction. I
>> have good luck with that method using my wife as a sounding board -- even
>> though she doesn't know L from ST.
>>
>> I think many respondents are answering the wrong question. The OP's
>> question is not "how do I debug or prevent an S047?" He understands the
>> S047. His question is "how do I debug this code without triggering an
>> unrelated but well-deserved S047?"
>>
>> Charles
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Tom Brennan
>> Sent: Thursday, February 25, 2021 11:46 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Assembler - Authorized program debug
>>
>> Is the TSO TESTAUTH command still around?  I have to admit I can't
>> remember ever trying it.  My debugging method of such code typically
>> consisted of multiple temporary WTO's to let me know where the program
>> was at before it failed, and also display fields or registers I was
>> interested in.  Usually within a few iterations of that method, I'd
>> figure out my problem.
>>
>> Another method:  After looking at your code for hours and hours, have
>> someone else peek over your shoulder and invariably they will see the
>> problem in seconds.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Ramsey Hallman]

I agree with Syrmour's method.  When I am stumped, I'll start an email to
my boss (the best assembler coder I know) asking what I've done wrong.
While putting as much information into the email as possible, so he doesn't
think I'm taking the easy way out, 99 times out of 100 I'll find my issue.
Usually, it's something fairly minor that I've simply overlooked as
"obviously correct" or "obviously not the area of the problem."  When I
point this out to my boss, he usually says "desk check" your code.  But I
live by the motto that was posted here some time in the past - Months of
coding and debugging beats hours of desk checking any day. (or something
very close to that LOL).
Ramsey



On Fri, Feb 26, 2021 at 11:09 AM Seymour J Metz  wrote:

> With regard to Tom's second method, often *I* spot the error when I'm
> asking for help and explaining the code. Somehow it seems to sometimes cure
> a mental blind spot.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Charles Mills [charl...@mcn.org]
> Sent: Friday, February 26, 2021 11:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Assembler - Authorized program debug
>
> I really second Tom's latter method. Try walking through the code with
> someone else -- explain to them how it works instruction by instruction. I
> have good luck with that method using my wife as a sounding board -- even
> though she doesn't know L from ST.
>
> I think many respondents are answering the wrong question. The OP's
> question is not "how do I debug or prevent an S047?" He understands the
> S047. His question is "how do I debug this code without triggering an
> unrelated but well-deserved S047?"
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tom Brennan
> Sent: Thursday, February 25, 2021 11:46 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Assembler - Authorized program debug
>
> Is the TSO TESTAUTH command still around?  I have to admit I can't
> remember ever trying it.  My debugging method of such code typically
> consisted of multiple temporary WTO's to let me know where the program
> was at before it failed, and also display fields or registers I was
> interested in.  Usually within a few iterations of that method, I'd
> figure out my problem.
>
> Another method:  After looking at your code for hours and hours, have
> someone else peek over your shoulder and invariably they will see the
> problem in seconds.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Seymour J Metz]

With regard to Tom's second method, often *I* spot the error when I'm asking 
for help and explaining the code. Somehow it seems to sometimes cure a mental 
blind spot.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Friday, February 26, 2021 11:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler - Authorized program debug

I really second Tom's latter method. Try walking through the code with someone 
else -- explain to them how it works instruction by instruction. I have good 
luck with that method using my wife as a sounding board -- even though she 
doesn't know L from ST.

I think many respondents are answering the wrong question. The OP's question is 
not "how do I debug or prevent an S047?" He understands the S047. His question 
is "how do I debug this code without triggering an unrelated but well-deserved 
S047?"

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Thursday, February 25, 2021 11:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler - Authorized program debug

Is the TSO TESTAUTH command still around?  I have to admit I can't
remember ever trying it.  My debugging method of such code typically
consisted of multiple temporary WTO's to let me know where the program
was at before it failed, and also display fields or registers I was
interested in.  Usually within a few iterations of that method, I'd
figure out my problem.

Another method:  After looking at your code for hours and hours, have
someone else peek over your shoulder and invariably they will see the
problem in seconds.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Seymour J Metz]

I doubt that TESTAUTH will ever go away, but I suggest that you look at the HLA 
Toolkit or a 3rd party product, since TESTAUTH is pretty barebones.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom 
Brennan [t...@tombrennansoftware.com]
Sent: Friday, February 26, 2021 2:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler - Authorized program debug

Is the TSO TESTAUTH command still around?  I have to admit I can't
remember ever trying it.  My debugging method of such code typically
consisted of multiple temporary WTO's to let me know where the program
was at before it failed, and also display fields or registers I was
interested in.  Usually within a few iterations of that method, I'd
figure out my problem.

Another method:  After looking at your code for hours and hours, have
someone else peek over your shoulder and invariably they will see the
problem in seconds.

On 2/25/2021 9:57 PM, Ravi Gaur wrote:
> **Positing in Assembler group as well** - However given the activity thought 
> to put it in IBM-Main as well.
>
> Writing and debugging an assembler code which has MODESET instruction to 
> change key and while debugging it via IDF or Debug tool both abend with 
> S047(APF) issue. Anyone know a way to debug facility for code without using 
> IDF/Debug tool?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Charles Mills]

I really second Tom's latter method. Try walking through the code with someone 
else -- explain to them how it works instruction by instruction. I have good 
luck with that method using my wife as a sounding board -- even though she 
doesn't know L from ST.

I think many respondents are answering the wrong question. The OP's question is 
not "how do I debug or prevent an S047?" He understands the S047. His question 
is "how do I debug this code without triggering an unrelated but well-deserved 
S047?"

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Thursday, February 25, 2021 11:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler - Authorized program debug

Is the TSO TESTAUTH command still around?  I have to admit I can't 
remember ever trying it.  My debugging method of such code typically 
consisted of multiple temporary WTO's to let me know where the program 
was at before it failed, and also display fields or registers I was 
interested in.  Usually within a few iterations of that method, I'd 
figure out my problem.

Another method:  After looking at your code for hours and hours, have 
someone else peek over your shoulder and invariably they will see the 
problem in seconds.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Ravi Gaur]

Hi David, Yes believe that would help and uploading that on CBT will definitely 
be useful to many others like me.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[David Spiegel]

Hi Ravi, Barbara,
If you want to trace the execution of the program (instead of just one 
snapshot (as Barbara is suggesting)), you might want to consider setting 
up a SLIP Trap with TRACE, capturing your data with GTF and using IPCS 
(via ISPF or Batch) to print the Trace.


I am currently working on a situation like this. (I am also developing a 
Rexx Exec to make the output of the printed Trace more easily readable.)


If you'd like more information on this, please respond.

Sam: Please let me know if you'd like my finished product for the CBT Tape.

Regards,
David

On 2021-02-26 01:02, Barbara Nitz wrote:

On Thu, 25 Feb 2021 23:57:08 -0600, Ravi Gaur  wrote:


Writing and debugging an assembler code which has MODESET instruction to change 
key and while debugging it via IDF or Debug tool both abend with S047(APF) 
issue. Anyone know a way to debug facility for code without using IDF/Debug 
tool?

Set a  slip trap on s=047 and use IPCS to read the resulting sdump.

Regards, Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Colin Paice]

First check your steplib - and all the libraries in steplib are APF
authorised!
Secondly check binder setting AC
Colin

On Fri, 26 Feb 2021 at 05:57, Ravi Gaur  wrote:

> **Positing in Assembler group as well** - However given the activity
> thought to put it in IBM-Main as well.
>
> Writing and debugging an assembler code which has MODESET instruction to
> change key and while debugging it via IDF or Debug tool both abend with
> S047(APF) issue. Anyone know a way to debug facility for code without using
> IDF/Debug tool?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Tom Brennan]

Is the TSO TESTAUTH command still around?  I have to admit I can't 
remember ever trying it.  My debugging method of such code typically 
consisted of multiple temporary WTO's to let me know where the program 
was at before it failed, and also display fields or registers I was 
interested in.  Usually within a few iterations of that method, I'd 
figure out my problem.


Another method:  After looking at your code for hours and hours, have 
someone else peek over your shoulder and invariably they will see the 
problem in seconds.


On 2/25/2021 9:57 PM, Ravi Gaur wrote:

**Positing in Assembler group as well** - However given the activity thought to 
put it in IBM-Main as well.

Writing and debugging an assembler code which has MODESET instruction to change 
key and while debugging it via IDF or Debug tool both abend with S047(APF) 
issue. Anyone know a way to debug facility for code without using IDF/Debug 
tool?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Don Poitras]

In article <9007603817792033.wa.nitzibmgmx@listserv.ua.edu> you wrote:
> On Thu, 25 Feb 2021 23:57:08 -0600, Ravi Gaur  wrote:
>
> >Writing and debugging an assembler code which has MODESET instruction to 
> >change key and while debugging it via IDF or Debug tool both abend with 
> >S047(APF) issue. Anyone know a way to debug facility for code without using 
> >IDF/Debug tool?
>
> Set a  slip trap on s=047 and use IPCS to read the resulting sdump. 
>
> Regards, Barbara

S047 is a side-effect of running authorized while trying to use debuggers that
aren't themselves APF-authorized. z/XDC will allow this kind of debugging. See:

https://colesoft.com/products/zxdc/components#authxdc

-- 
Don Poitras

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler - Authorized program debug

[Barbara Nitz]

On Thu, 25 Feb 2021 23:57:08 -0600, Ravi Gaur  wrote:

>Writing and debugging an assembler code which has MODESET instruction to 
>change key and while debugging it via IDF or Debug tool both abend with 
>S047(APF) issue. Anyone know a way to debug facility for code without using 
>IDF/Debug tool?

Set a  slip trap on s=047 and use IPCS to read the resulting sdump. 

Regards, Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Assembler - Authorized program debug

[Ravi Gaur]

**Positing in Assembler group as well** - However given the activity thought to 
put it in IBM-Main as well.

Writing and debugging an assembler code which has MODESET instruction to change 
key and while debugging it via IDF or Debug tool both abend with S047(APF) 
issue. Anyone know a way to debug facility for code without using IDF/Debug 
tool?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN