Re: Commands from systsin

[Joseph Reichman]

Think we went thru this 

There are a number of Zpdt users out there like me who have the personal
edition and most them do authorized code 

Being a businessman you can determine 

What the price would be and if it would be worth your while I'm sure I
wouldn't be the only one who would be willing to buy it 

Thank you 



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
David Cole
Sent: Thursday, September 14, 2023 6:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Commands from systsin

At 9/13/2023 12:52 PM, Joseph Reichman wrote:
>But I want to debug the function routine under TEST/TESTAUTH

Joe, If we offered an inexpensive "personal License" for z/XDC, Would you be
interested?

--
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: Commands from systsin

[Joseph Reichman]

I want to set a breakpoint via TEST/TESTAUTH to debug it test is particular as 
to what type of storage you can set a breakpoint

Get Outlook for iOS<https://aka.ms/o0ukef>

From: IBM Mainframe Discussion List  on behalf of Tom 
Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, September 14, 2023 12:57:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Commands from systsin

Why does it have to be in your private storage?
What is wrong with CSVDYLPA?

--
Tom Marchant

On Thu, 14 Sep 2023 08:03:25 -0400, Joseph Reichman  
wrote:

>I would like to debug my subsystem function under TESTAUTH towards that end
>I need it in private storage for the duration of my time logged on to TSO
>in between sessions of TESTAUTH I’m schedirb to load the routine and have
>the TCB ptr point to IKJEFT01 aka TCBJSTCB
>
>On Thu, Sep 14, 2023 at 7:27 AM Peter Relson  wrote:
>
>> Please stay away from LOAD GLOBAL=YES. In almost all circumstances where
>> the loading address space can terminate, this can lead to a system
>> integrity exposure. Specifically, you would have to be able to ensure with
>> 100% certainty that no program in any other address space is executing
>> within "your module" at the point that "your address space" terminates
>> since at that point the storage would be freed.
>>
>> That is why CSVDYLPA is a better choice usually. And that has additional
>> diagnostic advantages.
>> Or, less good but better than LOAD GLOBAL=YES, LOAD with ADDR= where the
>> storage you obtained is in common storage.
>>
>> In neither of the latter choices would the system ever free the storage
>> automatically.
>>
>> 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

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

Re: Commands from systsin

[Tom Marchant]

Why does it have to be in your private storage?
What is wrong with CSVDYLPA?

-- 
Tom Marchant

On Thu, 14 Sep 2023 08:03:25 -0400, Joseph Reichman  
wrote:

>I would like to debug my subsystem function under TESTAUTH towards that end
>I need it in private storage for the duration of my time logged on to TSO
>in between sessions of TESTAUTH I’m schedirb to load the routine and have
>the TCB ptr point to IKJEFT01 aka TCBJSTCB
>
>On Thu, Sep 14, 2023 at 7:27 AM Peter Relson  wrote:
>
>> Please stay away from LOAD GLOBAL=YES. In almost all circumstances where
>> the loading address space can terminate, this can lead to a system
>> integrity exposure. Specifically, you would have to be able to ensure with
>> 100% certainty that no program in any other address space is executing
>> within "your module" at the point that "your address space" terminates
>> since at that point the storage would be freed.
>>
>> That is why CSVDYLPA is a better choice usually. And that has additional
>> diagnostic advantages.
>> Or, less good but better than LOAD GLOBAL=YES, LOAD with ADDR= where the
>> storage you obtained is in common storage.
>>
>> In neither of the latter choices would the system ever free the storage
>> automatically.
>>
>> 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: Commands from systsin

[Joseph Reichman]

I would like to debug my subsystem function under TESTAUTH towards that end
I need it in private storage for the duration of my time logged on to TSO
in between sessions of TESTAUTH I’m schedirb to load the routine and have
the TCB ptr point to IKJEFT01 aka TCBJSTCB

Thanks



On Thu, Sep 14, 2023 at 7:27 AM Peter Relson  wrote:

> Please stay away from LOAD GLOBAL=YES. In almost all circumstances where
> the loading address space can terminate, this can lead to a system
> integrity exposure. Specifically, you would have to be able to ensure with
> 100% certainty that no program in any other address space is executing
> within "your module" at the point that "your address space" terminates
> since at that point the storage would be freed.
>
> That is why CSVDYLPA is a better choice usually. And that has additional
> diagnostic advantages.
> Or, less good but better than LOAD GLOBAL=YES, LOAD with ADDR= where the
> storage you obtained is in common storage.
>
> In neither of the latter choices would the system ever free the storage
> automatically.
>
> 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
>

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

Re: Commands from systsin

[Peter Relson]

Please stay away from LOAD GLOBAL=YES. In almost all circumstances where the 
loading address space can terminate, this can lead to a system integrity 
exposure. Specifically, you would have to be able to ensure with 100% certainty 
that no program in any other address space is executing within "your module" at 
the point that "your address space" terminates since at that point the storage 
would be freed.

That is why CSVDYLPA is a better choice usually. And that has additional 
diagnostic advantages.
Or, less good but better than LOAD GLOBAL=YES, LOAD with ADDR= where the 
storage you obtained is in common storage.

In neither of the latter choices would the system ever free the storage 
automatically.

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: Commands from systsin

[Colin Paice]

Would a *home-address-space-level name/token pair*

name token work?

On Thu, 14 Sept 2023 at 11:24, David Cole  wrote:

> At 9/13/2023 11:12 AM, Joe wrote:
> >Seems then the only to do what I want is schedule an IRB with the
> >TCB being IKJEFT01
>
> Thank might work.
>
> --
> 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: Commands from systsin

[David Cole]

At 9/13/2023 12:52 PM, Joseph Reichman wrote:

But I want to debug the function routine under TEST/TESTAUTH


Joe, If we offered an inexpensive "personal License" for z/XDC, Would 
you be interested?


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

Re: Commands from systsin

[David Cole]

At 9/13/2023 11:12 AM, Joe wrote:
Seems then the only to do what I want is schedule an IRB with the 
TCB being IKJEFT01


Thank might work.

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

Re: Commands from systsin

[David Cole]

WRT "Dave.C, may you live forever"... I'll drink to that!






At 9/13/2023 04:01 PM, Steve Thompson wrote:

Noobies who don't want to know history and the like, just delete this
As to z/XDC and priv code and/or key zero 
storage -- oh the ease and joy of not being 
forced to use TEST Auth. Or having to set some SLIP, get a dump, or do SNAPs...
I wish I could be cursed with having to use 
z/XDC again. Stepping through code But don't 
do that on a production machine -- sand box only 
(for setting traps in LPA and the like. Yes, you 
can set traps in SVCs and PCs and the like) -- 
just be very careful or you can kill the system 
right out from under you (read the very good 
manual, it lists things you do at your own risk).
I can't tell you how much I enjoyed XDC, and 
then z/XDC. Dave.C, may you live forever.

Steve Thompson
On 9/13/2023 3:40 PM, Tom Marchant wrote:

only TESTAUTH let’s you debug code with PSW bit 15 being 0

Obviously you haven't tried z/XDC.


All I want is to debug a program that was preloaded under a different TCB
Have you considered using CSVDYLPA to load in 
into dynamic LPA? Probably overkill for your 
purposes, but you can do it so that it will stay after task termination.

--
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: Commands from systsin

[Farley, Peter]

Apologies Joseph, you are correct.  I just re-checked the ASMIDF manuals and 
they do not directly say that it supports debugging authorized code.  The Fine 
Manuals actually don’t say one way or another whether authorized debugging is 
supported, but since it is not specifically documented as possible I would 
presume that it is not.

I suppose you could try making ASMIDF itself authorized in an APF library so 
you could try debugging authorized code, but I suspect that exercise would end 
up causing more problems than it may be worth.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Joseph Reichman
Sent: Wednesday, September 13, 2023 4:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Commands from systsin


Last time I visited IDF didn’t debug code in supervisor state



> On Sep 13, 2023, at 4:02 PM, Steve Thompson  wrote:

>

> Noobies who don't want to know history and the like, just delete this

>

> As to z/XDC and priv code and/or key zero storage -- oh the ease and joy of 
> not being forced to use TEST Auth. Or having to set some SLIP, get a dump, or 
> do SNAPs...

>

> I wish I could be cursed with having to use z/XDC again. Stepping through 
> code But don't do that on a production machine -- sand box only (for 
> setting traps in LPA and the like. Yes, you can set traps in SVCs and PCs and 
> the like) -- just be very careful or you can kill the system right out from 
> under you (read the very good manual, it lists things you do at your own 
> risk).

>

> I can't tell you how much I enjoyed XDC, and then z/XDC. Dave.C, may you live 
> forever.

>

> Steve Thompson

>

> On 9/13/2023 3:40 PM, Tom Marchant wrote:

>>> only TESTAUTH let’s you debug code with PSW bit 15 being 0

>> Obviously you haven't tried z/XDC.

>>

>>> All I want is to debug a program that was preloaded under a different TCB

>> Have you considered using CSVDYLPA to load in into dynamic LPA? Probably 
>> overkill for your purposes, but you can do it so that it will stay after 
>> task termination.

--



This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: Commands from systsin

[Joseph Reichman]

Last time I visited IDF didn’t debug code in supervisor state 

> On Sep 13, 2023, at 4:02 PM, Steve Thompson  wrote:
> 
> Noobies who don't want to know history and the like, just delete this
> 
> As to z/XDC and priv code and/or key zero storage -- oh the ease and joy of 
> not being forced to use TEST Auth. Or having to set some SLIP, get a dump, or 
> do SNAPs...
> 
> I wish I could be cursed with having to use z/XDC again. Stepping through 
> code But don't do that on a production machine -- sand box only (for 
> setting traps in LPA and the like. Yes, you can set traps in SVCs and PCs and 
> the like) -- just be very careful or you can kill the system right out from 
> under you (read the very good manual, it lists things you do at your own 
> risk).
> 
> I can't tell you how much I enjoyed XDC, and then z/XDC. Dave.C, may you live 
> forever.
> 
> Steve Thompson
> 
> On 9/13/2023 3:40 PM, Tom Marchant wrote:
>>> only TESTAUTH let’s you debug code with PSW bit 15 being 0
>> Obviously you haven't tried z/XDC.
>> 
>>> All I want is to debug a program that was preloaded under a different TCB
>> Have you considered using CSVDYLPA to load in into dynamic LPA? Probably 
>> overkill for your purposes, but you can do it so that it will stay after 
>> task termination.
>> 
> 
> --
> 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: Commands from systsin

[Steve Thompson]

Noobies who don't want to know history and the like, just delete 
this


As to z/XDC and priv code and/or key zero storage -- oh the ease 
and joy of not being forced to use TEST Auth. Or having to set 
some SLIP, get a dump, or do SNAPs...


I wish I could be cursed with having to use z/XDC again. Stepping 
through code But don't do that on a production machine -- 
sand box only (for setting traps in LPA and the like. Yes, you 
can set traps in SVCs and PCs and the like) -- just be very 
careful or you can kill the system right out from under you (read 
the very good manual, it lists things you do at your own risk).


I can't tell you how much I enjoyed XDC, and then z/XDC. Dave.C, 
may you live forever.


Steve Thompson

On 9/13/2023 3:40 PM, Tom Marchant wrote:

only TESTAUTH let’s you debug code with PSW bit 15 being 0

Obviously you haven't tried z/XDC.


All I want is to debug a program that was preloaded under a different TCB

Have you considered using CSVDYLPA to load in into dynamic LPA? Probably 
overkill for your purposes, but you can do it so that it will stay after task 
termination.



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

Re: Commands from systsin

[Farley, Peter]

AFAIK, Zpdt systems include the HLASM Toolkit by default.  Check it out, it may 
save you some grief.  Since you are on Zpdt you have control over the necessary 
VTAM APPL’s and LU’s, so you could do remote batch debugging and forget about 
TEST/TESTAUTH.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Joseph Reichman
Sent: Wednesday, September 13, 2023 3:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Commands from systsin



I don’t have the $10,000 or so to purchase it

If it was a reasonable  price for Zpdt user I would consider it



I need the program in storage area that TESTAUTH will let me set a breakpoint



I think my method should work



Will try it later



> On Sep 13, 2023, at 3:40 PM, Tom Marchant 
> <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

>

> 

>>

>> only TESTAUTH let’s you debug code with PSW bit 15 being 0

>

> Obviously you haven't tried z/XDC.

>

>> All I want is to debug a program that was preloaded under a different TCB

>

> Have you considered using CSVDYLPA to load in into dynamic LPA? Probably 
> overkill for your purposes, but you can do it so that it will stay after task 
> termination.

>

> --

> Tom Marchant

>

>> On Wed, 13 Sep 2023 15:10:19 -0400, Joseph Reichman  
>> wrote:

>>

>> First off tried it only TESTAUTH let’s you debug code with PSW bit 15 being 0

>>

>> Not really sure what not being a good idea that is usually reserved for 
>> moving using non standard code into production as other problems will pop up

>>

>> All I want is to debug a program that was preloaded under a different TCB 
>> after I get the kinks out I’ll have LOADTOGLOBAL=YES

>>

>>>> On Sep 13, 2023, at 3:04 PM, Farley, Peter 
>>>> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

>>>

>>> I agree with other posters that your suggested solution is not a good idea.

>>>

>>> If you have the HLASM Toolkit product licensed on your system you can use 
>>> the ASMIDF debugger to remotely debug batch jobs from a VTAM session, but 
>>> using ASMIDF requires that pre-established VTAM APPL’s and LU’s are defined 
>>> by your VTAM/network team.

>>>

>>> I have used it to debug assembler code and it is a pretty reasonable 
>>> debugging tool (not as good as z/XDC, but reasonable nonetheless, and IMHO 
>>> better than TSO TEST) IFF you can get your network team to set up the VTAM 
>>> APPL’s and LU’s for you.  It’s all documented in the install/reference 
>>> manual for the HLASM Toolkit.

>>>

>>> IIRC, ASMIDF even has the ability to debug authorized code, but check the 
>>> manual to be sure.

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: Commands from systsin

[Joseph Reichman]

I don’t have the $10,000 or so to purchase it 
If it was a reasonable  price for Zpdt user I would consider it 

I need the program in storage area that TESTAUTH will let me set a breakpoint 

I think my method should work 

Will try it later 

> On Sep 13, 2023, at 3:40 PM, Tom Marchant 
> <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> 
> 
>> 
>> only TESTAUTH let’s you debug code with PSW bit 15 being 0
> 
> Obviously you haven't tried z/XDC.
> 
>> All I want is to debug a program that was preloaded under a different TCB
> 
> Have you considered using CSVDYLPA to load in into dynamic LPA? Probably 
> overkill for your purposes, but you can do it so that it will stay after task 
> termination.
> 
> -- 
> Tom Marchant
> 
>> On Wed, 13 Sep 2023 15:10:19 -0400, Joseph Reichman  
>> wrote:
>> 
>> First off tried it only TESTAUTH let’s you debug code with PSW bit 15 being 0
>> 
>> Not really sure what not being a good idea that is usually reserved for 
>> moving using non standard code into production as other problems will pop up 
>> 
>> All I want is to debug a program that was preloaded under a different TCB 
>> after I get the kinks out I’ll have LOADTOGLOBAL=YES
>> 
 On Sep 13, 2023, at 3:04 PM, Farley, Peter 
 <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>>> 
>>> I agree with other posters that your suggested solution is not a good idea.
>>> 
>>> If you have the HLASM Toolkit product licensed on your system you can use 
>>> the ASMIDF debugger to remotely debug batch jobs from a VTAM session, but 
>>> using ASMIDF requires that pre-established VTAM APPL’s and LU’s are defined 
>>> by your VTAM/network team.
>>> 
>>> I have used it to debug assembler code and it is a pretty reasonable 
>>> debugging tool (not as good as z/XDC, but reasonable nonetheless, and IMHO 
>>> better than TSO TEST) IFF you can get your network team to set up the VTAM 
>>> APPL’s and LU’s for you.  It’s all documented in the install/reference 
>>> manual for the HLASM Toolkit.
>>> 
>>> IIRC, ASMIDF even has the ability to debug authorized code, but check the 
>>> manual to be sure.
> 
> --
> 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: Commands from systsin

[Tom Marchant]

>only TESTAUTH let’s you debug code with PSW bit 15 being 0

Obviously you haven't tried z/XDC.

>All I want is to debug a program that was preloaded under a different TCB

Have you considered using CSVDYLPA to load in into dynamic LPA? Probably 
overkill for your purposes, but you can do it so that it will stay after task 
termination.

-- 
Tom Marchant

On Wed, 13 Sep 2023 15:10:19 -0400, Joseph Reichman  
wrote:

>First off tried it only TESTAUTH let’s you debug code with PSW bit 15 being 0
>
>Not really sure what not being a good idea that is usually reserved for moving 
>using non standard code into production as other problems will pop up 
>
>All I want is to debug a program that was preloaded under a different TCB 
>after I get the kinks out I’ll have LOADTOGLOBAL=YES
>
>> On Sep 13, 2023, at 3:04 PM, Farley, Peter 
>> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> I agree with other posters that your suggested solution is not a good idea.
>> 
>> If you have the HLASM Toolkit product licensed on your system you can use 
>> the ASMIDF debugger to remotely debug batch jobs from a VTAM session, but 
>> using ASMIDF requires that pre-established VTAM APPL’s and LU’s are defined 
>> by your VTAM/network team.
>> 
>> I have used it to debug assembler code and it is a pretty reasonable 
>> debugging tool (not as good as z/XDC, but reasonable nonetheless, and IMHO 
>> better than TSO TEST) IFF you can get your network team to set up the VTAM 
>> APPL’s and LU’s for you.  It’s all documented in the install/reference 
>> manual for the HLASM Toolkit.
>> 
>> IIRC, ASMIDF even has the ability to debug authorized code, but check the 
>> manual to be sure.

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

Re: Commands from systsin

[Joseph Reichman]

First off tried it only TESTAUTH let’s you debug code with PSW bit 15 being 0

Not really sure what not being a good idea that is usually reserved for moving 
using non standard code into production as other problems will pop up 

All I want is to debug a program that was preloaded under a different TCB after 
I get the kinks out I’ll have LOADTOGLOBAL=YES

> On Sep 13, 2023, at 3:04 PM, Farley, Peter 
> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
> 
> I agree with other posters that your suggested solution is not a good idea.
> 
> If you have the HLASM Toolkit product licensed on your system you can use the 
> ASMIDF debugger to remotely debug batch jobs from a VTAM session, but using 
> ASMIDF requires that pre-established VTAM APPL’s and LU’s are defined by your 
> VTAM/network team.
> 
> I have used it to debug assembler code and it is a pretty reasonable 
> debugging tool (not as good as z/XDC, but reasonable nonetheless, and IMHO 
> better than TSO TEST) IFF you can get your network team to set up the VTAM 
> APPL’s and LU’s for you.  It’s all documented in the install/reference manual 
> for the HLASM Toolkit.
> 
> IIRC, ASMIDF even has the ability to debug authorized code, but check the 
> manual to be sure.
> 
> Peter
> 
> From: IBM Mainframe Discussion List  On Behalf Of 
> Joseph Reichman
> Sent: Wednesday, September 13, 2023 12:52 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Commands from systsin
> 
> 
> 
> Let me explain I’m only doing this for testing purposes
> 
> 
> 
> I am writing a subsystem so normally the function routines would be in global
> 
> 
> 
> But I want to debug the function routine under TEST/TESTAUTH
> 
> 
> 
> So the subsystem initialization routine is going to create the SSVT routine 
> by address
> 
> 
> 
> But I need that address to be valid when I later on in the same TSO Session 
> but under  a new invocation of TESTAUTH invoke the function
> 
> Under second invocation of TEST/TESTAUTH
> 
> 
> 
> I have this address which I saved wrote down from the first
> 
> And in second invocation before I issue IEFSSREQ I’ll do a AT 1EF37980. ( the 
> address is just an example )
> 
> 
> 
> Makes sense ?
> 
> 
> 
>>> On Sep 13, 2023, at 12:19 PM, Seymour J Metz  wrote:
>> 
>> 
> 
>> I advise against it.
> 
>> 
> 
>> 
> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> Joseph Reichman 
> 
>> Sent: Wednesday, September 13, 2023 11:12 AM
> 
>> To: IBM-MAIN@LISTSERV.UA.EDU
> 
>> Subject: Re: Commands from systsin
> 
>> 
> 
>> Seems then the only to do what I want is schedule an IRB with the TCB being 
>> IKJEFT01
> 
>> 
> 
>> ?
> 
>> 
> 
>>> On Sep 13, 2023, at 11:09 AM, Seymour J Metz  wrote:
> 
>>> 
> 
>>> The modules are deleted from storage when the command complete, as part of 
>>> task cleanup.
> 
>>> 
> 
>>> 
> 
>>> From: IBM Mainframe Discussion List  on behalf of 
>>> Joseph Reichman 
> 
>>> Sent: Wednesday, September 13, 2023 10:10 AM
> 
>>> To: IBM-MAIN@LISTSERV.UA.EDU
> 
>>> Subject: Commands from systsin
> 
>>> 
> 
>>> Hi
> 
>>> 
> 
>>> I have a number of program that I would like to stay resident in the job 
>>> pack are of my tso session
> 
>>> 
> 
>>> So I run a command from systsin in my tso session  that command all it does 
>>> is loads
> 
>>> A few load modules and wto s the address
> 
>>> Will they remain in core until I log off
> 
>>> 
> 
>>> I mean I’m assuming the would run under job step TCB IKJEFT01
> 
>>> 
> 
>>> And therefore stay in the job pack are till I log off
> 
>>> Am I correct ?
> 
> --
> 
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communication in error, please notify us immediately by e-mail 
> and delete the message and any attachments from your system.
> 
> 
> --
> 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: Commands from systsin

[Farley, Peter]

I agree with other posters that your suggested solution is not a good idea.

If you have the HLASM Toolkit product licensed on your system you can use the 
ASMIDF debugger to remotely debug batch jobs from a VTAM session, but using 
ASMIDF requires that pre-established VTAM APPL’s and LU’s are defined by your 
VTAM/network team.

I have used it to debug assembler code and it is a pretty reasonable debugging 
tool (not as good as z/XDC, but reasonable nonetheless, and IMHO better than 
TSO TEST) IFF you can get your network team to set up the VTAM APPL’s and LU’s 
for you.  It’s all documented in the install/reference manual for the HLASM 
Toolkit.

IIRC, ASMIDF even has the ability to debug authorized code, but check the 
manual to be sure.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Joseph Reichman
Sent: Wednesday, September 13, 2023 12:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Commands from systsin



Let me explain I’m only doing this for testing purposes



I am writing a subsystem so normally the function routines would be in global



But I want to debug the function routine under TEST/TESTAUTH



So the subsystem initialization routine is going to create the SSVT routine by 
address



But I need that address to be valid when I later on in the same TSO Session but 
under  a new invocation of TESTAUTH invoke the function

Under second invocation of TEST/TESTAUTH



I have this address which I saved wrote down from the first

And in second invocation before I issue IEFSSREQ I’ll do a AT 1EF37980. ( the 
address is just an example )



Makes sense ?



> On Sep 13, 2023, at 12:19 PM, Seymour J Metz  wrote:

>

> I advise against it.

>

> 

> From: IBM Mainframe Discussion List  on behalf of 
> Joseph Reichman 

> Sent: Wednesday, September 13, 2023 11:12 AM

> To: IBM-MAIN@LISTSERV.UA.EDU

> Subject: Re: Commands from systsin

>

> Seems then the only to do what I want is schedule an IRB with the TCB being 
> IKJEFT01

>

> ?

>

>> On Sep 13, 2023, at 11:09 AM, Seymour J Metz  wrote:

>>

>> The modules are deleted from storage when the command complete, as part of 
>> task cleanup.

>>

>> 

>> From: IBM Mainframe Discussion List  on behalf of 
>> Joseph Reichman 

>> Sent: Wednesday, September 13, 2023 10:10 AM

>> To: IBM-MAIN@LISTSERV.UA.EDU

>> Subject: Commands from systsin

>>

>> Hi

>>

>> I have a number of program that I would like to stay resident in the job 
>> pack are of my tso session

>>

>> So I run a command from systsin in my tso session  that command all it does 
>> is loads

>> A few load modules and wto s the address

>> Will they remain in core until I log off

>>

>> I mean I’m assuming the would run under job step TCB IKJEFT01

>>

>> And therefore stay in the job pack are till I log off

>> Am I correct ?

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: Commands from systsin

[Michael Stein]

On Wed, Sep 13, 2023 at 10:10:42AM -0400, Joseph Reichman wrote:
> I have a number of program that I would like to stay resident in the
> job pack are of my tso session
> 
> So I run a command from systsin in my tso session  that command all it
> does is loads A few load modules and wto s the address Will they remain
> in core until I log off

No.  see the load macro:

https://www.ibm.com/docs/en/zos/2.5.0?topic=storage-load-description

  The responsibility count for the load module is increased by one.

  The load module remains in virtual storage until the responsibility
  count is reduced to 0 through task terminations. The module also remains
  until the effects of all outstanding LOAD requests for the module are
  canceled by using the DELETE macro. There are no other requirements
  for the module.

So the module goes away when it's not being used and the task doing the
LOAD terminated implies DELETEs for all the modules it loaded.

If the use count for a module goes to zero the module goes away.

> I mean I'm assuming the would run under job step TCB IKJEFT01 

No, the TSO TMP uses attach to start commands so when the command ends
the task attached to run the command terminates (and all it's loaded
modules get implicitly deleted).
 
> And therefore stay in the job pack are till I log off 
> Am I correct ?

No.

I'd suggest learning how to read dumps and use SYSUDUMP or SYSMDUMP
and debug it in batch.  This avoids all the TSO APF mess...

You might want your own "driver" program which preloads modules
as you need before attaching your program your testing...

Possibly how well this works depends on how fast your submit/output
cycle time is. 

I've written subsystem code and did not use the TSO TEST APF functions
during development but this was something like MVS SP1.  Then again at
that point I'd already been reading (others) dumps for over 10 years.

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

Re: Commands from systsin

[Joseph Reichman]

Let me explain I’m only doing this for testing purposes 

I am writing a subsystem so normally the function routines would be in global 

But I want to debug the function routine under TEST/TESTAUTH 

So the subsystem initialization routine is going to create the SSVT routine by 
address 

But I need that address to be valid when I later on in the same TSO Session but 
under  a new invocation of TESTAUTH invoke the function 
Under second invocation of TEST/TESTAUTH 

I have this address which I saved wrote down from the first 
And in second invocation before I issue IEFSSREQ I’ll do a AT 1EF37980. ( the 
address is just an example ) 

Makes sense ?

> On Sep 13, 2023, at 12:19 PM, Seymour J Metz  wrote:
> 
> I advise against it.
> 
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Joseph Reichman 
> Sent: Wednesday, September 13, 2023 11:12 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Commands from systsin
> 
> Seems then the only to do what I want is schedule an IRB with the TCB being 
> IKJEFT01
> 
> ?
> 
>> On Sep 13, 2023, at 11:09 AM, Seymour J Metz  wrote:
>> 
>> The modules are deleted from storage when the command complete, as part of 
>> task cleanup.
>> 
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> Joseph Reichman 
>> Sent: Wednesday, September 13, 2023 10:10 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Commands from systsin
>> 
>> Hi
>> 
>> I have a number of program that I would like to stay resident in the job 
>> pack are of my tso session
>> 
>> So I run a command from systsin in my tso session  that command all it does 
>> is loads
>> A few load modules and wto s the address
>> Will they remain in core until I log off
>> 
>> I mean I’m assuming the would run under job step TCB IKJEFT01
>> 
>> And therefore stay in the job pack are till I log off
>> Am I correct ?
>> --
>> 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

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

Re: Commands from systsin

[Seymour J Metz]

I advise against it.


From: IBM Mainframe Discussion List  on behalf of 
Joseph Reichman 
Sent: Wednesday, September 13, 2023 11:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Commands from systsin

Seems then the only to do what I want is schedule an IRB with the TCB being 
IKJEFT01

?

> On Sep 13, 2023, at 11:09 AM, Seymour J Metz  wrote:
>
> The modules are deleted from storage when the command complete, as part of 
> task cleanup.
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Joseph Reichman 
> Sent: Wednesday, September 13, 2023 10:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Commands from systsin
>
> Hi
>
> I have a number of program that I would like to stay resident in the job pack 
> are of my tso session
>
> So I run a command from systsin in my tso session  that command all it does 
> is loads
> A few load modules and wto s the address
> Will they remain in core until I log off
>
> I mean I’m assuming the would run under job step TCB IKJEFT01
>
> And therefore stay in the job pack are till I log off
> Am I correct ?
> --
> 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: Commands from systsin

[Paul Gilmartin]

On Wed, 13 Sep 2023 11:12:30 -0400, Joseph Reichman wrote:

>Seems then the only to do what I want is schedule an IRB with the TCB being 
>IKJEFT01
>?
>
Can you ATTACH your other programs from the task that performs the LOAD?


>> 
>> From: Joseph Reichman 
>> Sent: Wednesday, September 13, 2023 10:10 AM
>> 
>> I have a number of program that I would like to stay resident in the job 
>> pack are of my tso session
>> 
>> So I run a command from systsin in my tso session  that command all it does 
>> is loads
>> A few load modules and wto s the address
>> Will they remain in core until I log off

-- 
gil

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

Re: Commands from systsin

[Joseph Reichman]

Seems then the only to do what I want is schedule an IRB with the TCB being 
IKJEFT01

?

> On Sep 13, 2023, at 11:09 AM, Seymour J Metz  wrote:
> 
> The modules are deleted from storage when the command complete, as part of 
> task cleanup.
> 
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Joseph Reichman 
> Sent: Wednesday, September 13, 2023 10:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Commands from systsin
> 
> Hi
> 
> I have a number of program that I would like to stay resident in the job pack 
> are of my tso session
> 
> So I run a command from systsin in my tso session  that command all it does 
> is loads
> A few load modules and wto s the address
> Will they remain in core until I log off
> 
> I mean I’m assuming the would run under job step TCB IKJEFT01
> 
> And therefore stay in the job pack are till I log off
> Am I correct ?
> --
> 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: Commands from systsin

[Seymour J Metz]

The modules are deleted from storage when the command complete, as part of task 
cleanup.


From: IBM Mainframe Discussion List  on behalf of 
Joseph Reichman 
Sent: Wednesday, September 13, 2023 10:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Commands from systsin

Hi

I have a number of program that I would like to stay resident in the job pack 
are of my tso session

So I run a command from systsin in my tso session  that command all it does is 
loads
A few load modules and wto s the address
Will they remain in core until I log off

I mean I’m assuming the would run under job step TCB IKJEFT01

And therefore stay in the job pack are till I log off
Am I correct ?
--
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: Commands from systsin

[Rupert Reynolds]

You might have to be sneaky. If your setup has a command run from TSO
before ISPF (something like A.CLIST(#LOGON)) you should be able to run code
that loads your stuff before it starts ISPF (PDF, ISPSTART or whatever).

On my MVS 3.8 system at IPL I run something that loads 3 routines into LPA,
and a list of pointers to them I called USERVT, pointed to by the spare
CVTUSER field.

Since CoViD-19 I can't remenber /why/ I did this, so there's a bit of
investigation to do :-)

Roops

On Wed, 13 Sep 2023, 15:10 Joseph Reichman,  wrote:

> Hi
>
> I have a number of program that I would like to stay resident in the job
> pack are of my tso session
>
> So I run a command from systsin in my tso session  that command all it
> does is loads
> A few load modules and wto s the address
> Will they remain in core until I log off
>
> I mean I’m assuming the would run under job step TCB IKJEFT01
>
> And therefore stay in the job pack are till I log off
> Am I correct ?
> --
> 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