Re: Testing an assembler using TSOEXEC TEST and breakpoint

On 22 Sep 2004 00:39:16 -0700 lamdalamda21@yahoo.com (Johnny) wrote:

:>I'm trying to test and debug an assembler(370) program and i've been
:>told that i should use TSOEXEC TEST command and by setting a break
:>point.

Do you have the slightest clue on how to use TEST? There are manuals.

Describe how you would like to use it.

--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

"Binyamin Dissen" <postingid@dissensoftware.com> wrote in message
 news:3ib2l0lnf9pj58gce4qhuqcur67ga8ojqu@
4ax.com...
> On 22 Sep 2004 00:39:16 -0700 lamdalamda21@yahoo.com (Johnny) wrote:
>
> :>I'm trying to test and debug an assembler(370) program and i've been
> :>told that i should use TSOEXEC TEST command and by setting a break
> :>point.
>
> Do you have the slightest clue on how to use TEST? There are manuals.
>
If you're going to tell him to RTFM, at least you might tell him which FM to
R.

z/OS TSO/E Programming Guide SA22-7788 has a tutorial on using TEST
z/OS TSO/E Command Reference SA22-7782 has the TEST comands in detail

Tom

Johnny,
If your company has shelled out for the (is it $99 a month?) for the
HLASM Toolkit, I'd suggest you use ASMIDF rather than TSO TEST to do
your debugging. This is a source-level debugger in an windowed (well,
at least as much windowing as you can do on a 3270) environment that
is much easier to use. Here's a link:

http://publibz.boulder.ibm.com/cgi-...KS/asmtiu04/1.1

--
Don Poitras - Sas Institute

Tom Grieve <tgrieve@uk.ibm.com> wrote:
> "Binyamin Dissen" <postingid@dissensoftware.com> wrote in message
>  news:3ib2l0lnf9pj58gce4qhuqcur67ga8ojqu@
4ax.com... 
> If you're going to tell him to RTFM, at least you might tell him which FM 
to
> R.

> z/OS TSO/E Programming Guide SA22-7788 has a tutorial on using TEST
> z/OS TSO/E Command Reference SA22-7782 has the TEST comands in detail

> Tom

Binyamin Dissen wrote:
> On Wed, 22 Sep 2004 10:03:24 +0100 "Tom Grieve" <tgrieve@uk.ibm.com> wrote
:
>
> :>"Binyamin Dissen" <postingid@dissensoftware.com> wrote in message
> :> news:3ib2l0lnf9pj58gce4qhuqcur67ga8ojqu@
4ax.com...
> :>> On 22 Sep 2004 00:39:16 -0700 lamdalamda21@yahoo.com (Johnny) wrote:
>
> :>> :>I'm trying to test and debug an assembler(370) program and i've been
> :>> :>told that i should use TSOEXEC TEST command and by setting a break
> :>> :>point.
>
> :>> Do you have the slightest clue on how to use TEST? There are manuals.
>
> :>If you're going to tell him to RTFM, at least you might tell him which F
M to
> :>R.
>
> :>z/OS TSO/E Programming Guide SA22-7788 has a tutorial on using TEST
> :>z/OS TSO/E Command Reference SA22-7782 has the TEST comands in detail
>
> Well...........
>
> If he can't find the manuals, he probably shouldn't be using TEST.
>
> --
> Binyamin Dissen <bdissen@dissensoftware.com>
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
>
>
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
>
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.

Nice thoughts... NOT! As one who has struggled through finding RELEVANT
manuals from that (actually, wonderful source - once you learn your way
around) site, I think YOU should remember just how overwhelmed YOU were
in the beginning of your "mainframe career" and not be be so high & mighty.

-michael

On Thu, 23 Sep 2004 05:48:17 GMT "tlgl@earthlink.net" <tlgl@earthlink.net>
wrote:

:>Nice thoughts... NOT! As one who has struggled through finding RELEVANT
:>manuals from that (actually, wonderful source - once you learn your way
:>around) site, I think YOU should remember just how overwhelmed YOU were
:>in the beginning of your "mainframe career" and not be be so high & mighty
.

Actually, when I started, the mainframes were not overwhelming.

I believe that the entire supervisor easily fit with 100K.

And I am not being "high & mighty" - TEST is not for the faint of heart.

--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

"Binyamin Dissen" <postingid@dissensoftware.com> wrote in message
 news:4405l01mm4dr4a8slrqo0kic8qhjl6m1lu@
4ax.com...
> On Thu, 23 Sep 2004 05:48:17 GMT "tlgl@earthlink.net" <tlgl@earthlink.net>
> wrote:
>
> :>Nice thoughts... NOT! As one who has struggled through finding RELEVANT
> :>manuals from that (actually, wonderful source - once you learn your way
> :>around) site, I think YOU should remember just how overwhelmed YOU were
> :>in the beginning of your "mainframe career" and not be be so high &
mighty.
>
> Actually, when I started, the mainframes were not overwhelming.
>
> I believe that the entire supervisor easily fit with 100K.
>
Hah! That's huge! DOS 26 used to fit in 16K (plus a lot of transients...).
And our office was a hole in the ground and we had to eat gravel for lunch.

Tom

 
I believe that the entire supervisor easily fit with 100K 

The resident portion, yes.

The transient portion, which included all of Job Management (except the Mast
er
Scheduler); and all of Open/Close/End-of-Volume, and numerous other service
routines; plus all system state (IEH-type utilities, e.g.) and problem state
(IEC-type utilities, e.g.) applications; was perhaps 10 megs. More after
Release 15/16.

(PCP could run on a 64K machine, so, obviously, a lot more of PCP was transi
ent
than in MFT's or MVT's case).

Peter H. <peterh5322@aol.comminch> wrote:

> I believe that the entire supervisor easily fit with 100K

> The resident portion, yes.

> The transient portion, which included all of Job Management (except the Ma
ster
> Scheduler); and all of Open/Close/End-of-Volume, and numerous other servic
e
> routines; plus all system state (IEH-type utilities, e.g.) and problem sta
te
> (IEC-type utilities, e.g.) applications; was perhaps 10 megs. More after
> Release 15/16.

Thanks too much for reminding me of R15/16. I think of it on my own
about once or twice a year, and then use it as a cautionary example
while teaching my trainee sysprogs, who have never had to deal with
Doing A System By Hand.

> (PCP could run on a 64K machine, so, obviously, a lot more of PCP
> was transient than in MFT's or MVT's case).

You may recall from Brooks' book _The Mythical Man-Month_ that the
original design of OS/360 called for just about _everything_ to be
transient and loaded-on-need, except for the nucleus. I'm sure that
lab testing showed them the error of that way, from what I've read.

Running MFT-II on a teeny-tiny /50 was ... interesting, and I thought
we had it tough, until I saw the teaching hospital's /40 running PCP
in less storage than I have in my digital watch.

The folks up in the state's Land Grant college actually had enough
machine to run MVT, and to run TSO as well. The best we could do
was ITF on 2741 terminals. I wound up doing more BTAM code for other
apps than I care to think about, and did a lot of instrumentation to
ry to see just WTF was happening. More than once I'd have been very
happy indeed to be able to use a decent debugger.

Circle-C, Circle-D, anyone?

--
Mike Andrews
mikea@mikea.ath.cx
Tired old symin

> > Well........... 

Believe me, sometimes it isn't easy to find the information you need
when it comes to IBM's mainframes.  And things do get worse when you
don't have any support coming from your company.  It's pretty , but
I've been "developing" in the mainframe environment for about 3 years
now, and I can tell you that I feel overwhelmed when I read most of
the messages posted in here and realize that I cannot quite understand
'em at all.  I'm in Mexico and you just can't find a decent book
written in Spanish about Mainframe assembler, and most of the books I
got (in English, of course) are old and are not really useful.  I've
started reading "Principles of Operation" because it was recommended
to me by people in this group, and it has helped me, but ironically my
workload haven't left me enough time to finish reading it.

So please don't be so tough.  Besides, people working in IT are mostly
looking for someone to tell 'em where they can find the information,
and not for other people to solve their problems explicitly.

V.

Peter H. <peterh5322@aol.comminch> wrote:

> I believe that the entire supervisor easily fit with 100K

> The resident portion, yes.

> The transient portion, which included all of Job Management (except the Ma
ster
> Scheduler); and all of Open/Close/End-of-Volume, and numerous other servic
e
> routines; plus all system state (IEH-type utilities, e.g.) and problem sta
te
> (IEC-type utilities, e.g.) applications; was perhaps 10 megs. More after
> Release 15/16.

Thanks too much for reminding me of R15/16. I think of it on my own
about once or twice a year, and then use it as a cautionary example
while teaching my trainee sysprogs, who have never had to deal with
Doing A System By Hand.

> (PCP could run on a 64K machine, so, obviously, a lot more of PCP
> was transient than in MFT's or MVT's case).

You may recall from Brooks' book _The Mythical Man-Month_ that the
original design of OS/360 called for just about _everything_ to be
transient and loaded-on-need, except for the nucleus. I'm sure that
lab testing showed them the error of that way, from what I've read.

Running MFT-II on a teeny-tiny /50 was ... interesting, and I thought
we had it tough, until I saw the teaching hospital's /40 running PCP
in less storage than I have in my digital watch.

The folks up in the state's Land Grant college actually had enough
machine to run MVT, and to run TSO as well. The best we could do
was ITF on 2741 terminals. I wound up doing more BTAM code for other
apps than I care to think about, and did a lot of instrumentation to
ry to see just WTF was happening. More than once I'd have been very
happy indeed to be able to use a decent debugger.

Circle-C, Circle-D, anyone?

--
Mike Andrews
mikea@mikea.ath.cx
Tired old symin