subject:"Re\: Workable Mainframe Debuggers"

In
[EMAIL PROTECTED],
on 04/14/2008
   at 10:19 PM, Ted MacNEIL [EMAIL PROTECTED] said:

My point was: why do people do things in a non-standard (unsupported)
way. Which you snipped out.

ROTF,LMAO! You always believe that your every word is golden, and go
ballistic when people only quote the part that they are commenting on.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

In [EMAIL PROTECTED], on
04/11/2008
   at 03:08 PM, McKown, John [EMAIL PROTECTED] said:

It would be simple to do by customizing one of the IPCS clists. Or just
keep them ignorant of it. Why would a normal programmer ever want to
use IPCS?

Because it's easier to find thing than with a printed dump.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

In [EMAIL PROTECTED],
on 04/11/2008
   at 02:45 PM, Farley, Peter x23353 [EMAIL PROTECTED] said:

But then, no other post-mortem tool I'm aware of does that either,

ABDUMP and friends capture multiple tasks.


In [EMAIL PROTECTED],
on 04/11/2008
   at 03:46 PM, Farley, Peter x23353 [EMAIL PROTECTED] said:

I've rarely been in a shop that had IPCS and also permitted application
programmers to use it.

I've never been at a shop that prohibited applications programmers from
using IPCS. It's been decades since I've seen an MVS system that didn't
have IPCS.

By the time I moved to MVS shops, they were so large that they 
followed the rule: Everything permitted is mandatory; everything 
else is forbidden.

As opposed to the shops that are so large that the users do what they want
no matter what you tell them, and then you have to make it work? It must
be nice to have that kind of power.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

In [EMAIL PROTECTED],
on 04/11/2008
   at 06:48 PM, Farley, Peter x23353 [EMAIL PROTECTED] said:

Plus a little attitude --
Real programmers only use SYSUDUMP kind of attidude.

My attitude was Give me a SYSMDUMP if you want me to look at it; SYSUDUMP
is unusable. Especially when they printed it :-(
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-15 Thread Steve Comstock


Edward Jaffe wrote:

Bass, Walter W wrote:

ipcs

 IPCS for z/OS 01.08.00
 ICH408I USER(JOEUSER ) GROUP($JOESGRP) NAME(PGMR,JOE)
   SYS1.PARMLIB.B CL(DATASET ) VOL(SYSBR2)
   INSUFFICIENT ACCESS AUTHORITY
   FROM SYS1.PARMLIB.* (G)
   ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )
 IEC150I 
913-38,IFG0194E,JOEUSER,@ENDPROD,SYS00991,D1FB,SYSBR2,SYS1.PARMLIB.B


Not quite the result I was hoping for ...

If I am reading this correct, I am being stopped because I don't have
read access to SYS1.PARMLIB.B
  


Sheesh! I've never understood what some sysprog's think is so secret 
about the contents of parmlib. IMHO, UACC(NONE) for parmlib is more 
draconian paranoia than anything else. But, that's a discussion for 
another thread...


I recreated your issue by giving one of my userids ACCESS(NONE) to 
SYS1.PARMLIB (which is UACC(READ) BTW). I get the following:


IEC150I 
913-38,IFG0194E,JOEUSER,$IKJE440,SYS00116-0003,2000,Z9RES1,SYS1.PARMLIB


The SYS00116-0003 means a concatenation is being being opened and the 
failure in the 3rd data set in the concatenation. I looked at my LOADxx 
member in IPLPARM and I see:


PARMLIB  one.data.set
PARMLIB  another.data.set **
PARMLIB  SYS1.PARMLIB **

SYS1.PARMLIB is the 3rd data set specified via PARMLIB statements. 
Coincidence? I doubt it. (The IEFPRMLB service requires READ access to 
all parmlibs in the concatenation.)


Here's the best part. Ready for this? Are you sitting down?? You want to 
know what the big super secret contents of IPCSPR00 are??? 
.


 LINELENGTH(137) PAGESIZE(60) NODSD NOPDR;

(I feel like I'm revealing corporate secrets here... Do I need a license 
to operate this thing??)


In the absence of being able to READ parmlib in the People's Republic 
of UHC, I would say the best alternative is to follow the alternate 
parmlib procedure (see link below) -- what Mark (one of the good 
sysprogs) has already alluded to -- and see how far you get ...


http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2c760/2.3


But the point is, it's still an awful lot of work to
find the workaround to get to the function that the
applications person might not even know is available.

Most folks will give up way before that and just start
putting DISPLAYs / WTOs in their code.

IPCS might be the greatest thing for debugging ever,
but it is _effectively_ not available to the great
numbers of application programmers, for whatever
reasons.



--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

== call or email to receive a free sample student handout ==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-15 Thread Shane Ginnane

CC offers;

 If you're a lowly security administrator you're probably just
 going to elect UACC(NONE) for everything you don't understand. 

Had it happen once. I was in at a customer after business hours getting a 
test IPL done.
Wouldn't come up. Some bright spark had decided PARMLIB needed UACC(NONE) 
- with *no* access list.
After hours no-one on-site had authority to fix it. Head honcho had to be 
rung to provide the other half of the super-user password.
Took a while - good thing Prod hadn't fallen over.

I seem to remember muttering something about banks and auditors.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

In [EMAIL PROTECTED], on 04/12/2008
   at 09:42 PM, Paul Gilmartin [EMAIL PROTECTED] said:

I believe that ease of installation of squatty box products arises from
providing customers guidance in this area, and the customers' willingness
to follow that guidance.

Sounds good; when is it going to happen? It sounds like a welcome change
from the installs I've seen on the squatty boxen so far, with their
dependency Hell and their stepping on each other's registry data.

Is there somewhere a customer who has an esthetic dislike for SYS1 and
uses an alternative HLQ for production data sets?

Have you stopped beating your wife? Have you been paid off to steer
everybody to putting everything in the Master Catalog? Why not ask why
they named things the way they did instead of inventing ludicrous
explanations?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-15 Thread Barbara Nitz

IPCS for example; when the system captures an SVC dump all of the
available data (even fetch protected data) is going to be laying around
in the dump dataset. Give Joe black hat uncontrolled access to IPCS and
he can snoop around to his heart's content looking under rocks and
turning up vulnerabilities the installation might not even be aware of. 

grin In my experience most people tend to have no clue how to use IPCS, much 
less how to use it to advantage, again much less how to figure out things from 
an sdump. If someone is really capable of doing this and using the information 
to turn up vulnerabilities, my congrats to her/him, and possibly good luck in 
getting the powers that be to close that vulnerability! /sarcasm off

Best regards, Barbara

-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

SYSRES Data Set Names (was Re: Workable Mainframe Debuggers)

On Sun, 13 Apr 2008 02:51:34 +, Ted MacNEIL [EMAIL PROTECTED] wrote:

I often see SYS1.ISF.SISF* , SYS1.ISP.SISP*, SYS1.GIM.SGIM* etc. even
though the MLQ is redundant.

I agree with the redundancy argument; what's wrong with each product having
the same library name(s) at every site?


Hard to change that stuff in a production environment... well, maybe not
hard, just a PITA when there are batch processes and people with their own
clists etc.

In production, standards should be enforced, so it won't become a PITA.


(changed the subject since this has nothing to do with debuggers)

What do local production standards have to do with the sysres names chosen
for sysres dsns (perhaps years and years ago)?  How would standards make
it any easier to change?

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

On Sat, 12 Apr 2008 21:42:01 -0500, Paul Gilmartin [EMAIL PROTECTED] wrote:


Is there somewhere a customer who has an esthetic dislike for
SYS1 and uses an alternative HLQ for production data sets?


Even today the default names in ServerPac don't have SYS1 for the products
I mentioned.  The names are ISP.*, ISF.*, GIM.*, etc.   It isn't a matter if
dislike so much as it is a matter of history and not changing data set names
that may be used in production and by end users.  The first MVS system I
worked on was an Express system (MVS SP 1.3) and I'm pretty sure I
remember all those different HLQs.   When I upgraded to MVS/XA I changed
it all.Now try and do the same thing after another 20+ years of MVS
history at a shop.  Like I said... PITA.  :-)

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSRES Data Set Names (was Re: Workable Mainframe Debuggers)

2008-04-14 Thread Shane

I happen to like having SYS1.** for (all) IBM targets.
Always had a RACF rule for it - and a group SYS1 for that matter.
Nowadays have similar for the OMVS started tasks.

And yes, I go change all the ServerPac dsnames that need it - not
helped by the mish-mash of names shipped. I'm sure I've beaten up on
Marna about that.

I *hate* it when I go into an AD/CD (derived) shop that has
god-who-knows-how-many HLQs for system targets.
I can work with whatever the customer dictates, but I also know where I
can work most effectively.
I work with what they give me - they pay the bill after all.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSRES Data Set Names (was Re: Workable Mainframe Debuggers)

2008-04-14 Thread Eric Bielefeld

I also like making SYS1. qualifiers for all of the IBM target datasets.  When I 
was still at PH Mining, I would consolidate all of the ISPF libraries by type. 
 Instead of having a bunch of ISPPLIBs, SLIBs, TLIBs, etc., I changed the 
DDDefs to all point to SYS1.ISPPLIB, SYS1.ISPSLIB, SYS1.ISPTLIB, etc.  That 
way, in the logon proc and in the system libraries, there was one set of 
libraries.  I never had any problems with doing it that way.  It took a while 
longer setting it up on the Serverpac, but I think the results were worth it.  

Eric

 Shane [EMAIL PROTECTED] wrote: 
 I happen to like having SYS1.** for (all) IBM targets.
 Always had a RACF rule for it - and a group SYS1 for that matter.
 Nowadays have similar for the OMVS started tasks.
 
 And yes, I go change all the ServerPac dsnames that need it - not
 helped by the mish-mash of names shipped. I'm sure I've beaten up on
 Marna about that.
 
 I *hate* it when I go into an AD/CD (derived) shop that has
 god-who-knows-how-many HLQs for system targets.
 I can work with whatever the customer dictates, but I also know where I
 can work most effectively.
 I work with what they give me - they pay the bill after all.
 
 Shane ...
--
Eric Bielefeld
Systems Programmer
Aviva USA
Des Moines, Iowa
515-645-5153

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-14 Thread Ed Finnell

 
In a message dated 4/14/2008 1:42:12 A.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:

Agreed to the above and below. The only conflict I remember was  when
IBM came out with IOA as a hlq, and we'd already used it for  some
product from Israel that was acquired by some outfit in Texas  :)



I'd still like to brand DB/2 on the forehead  of whomever came out with 
DSNsumting as a naming convention...







**It's Tax Time! Get tips, forms and advice on AOL Money  
Finance.  (http://money.aol.com/tax?NCID=aolcmp0030002850)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSRES Data Set Names (was Re: Workable Mainframe Debuggers)

Hard to change that stuff in a production environment... well, maybe not
hard, just a PITA when there are batch processes and people with their own
clists etc.

In production, standards should be enforced, so it won't become a PITA.


(changed the subject since this has nothing to do with debuggers)

What do local production standards have to do with the sysres names chosen
for sysres dsns (perhaps years and years ago)?  How would standards make
it any easier to change?

The PITA comment was not made by me.
The standards don't make it easier to change.
If done right Production should not be steplib'ing (for example) to system 
libraries.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSRES Data Set Names (was Re: Workable Mainframe Debuggers)

On Mon, 14 Apr 2008 20:58:27 +, Ted MacNEIL [EMAIL PROTECTED] wrote:

Hard to change that stuff in a production environment... well, maybe not
hard, just a PITA when there are batch processes and people with their own
clists etc.

In production, standards should be enforced, so it won't become a PITA.


(changed the subject since this has nothing to do with debuggers)

What do local production standards have to do with the sysres names chosen
for sysres dsns (perhaps years and years ago)?  How would standards make
it any easier to change?

The PITA comment was not made by me.
The standards don't make it easier to change.
If done right Production should not be steplib'ing (for example) to system
libraries.


Not your comment, Eh?  Who's post is this??   Perhaps you were too busy
driving to remember.  :-)

http://bama.ua.edu/cgi-bin/wa?A2=ind0804L=ibm-mainD=1amp;O=DT=0P=125149

You can't STEPLIB to ISPPLIB, ISPMLIB, ISPTLIB etc.  Only ISPLLIB can be
eliminated by putting libraries in the LNKLST.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSRES Data Set Names (was Re: Workable Mainframe Debuggers)

On Mon, 14 Apr 2008 16:36:07 -0500, Mark Zelden [EMAIL PROTECTED]
wrote:

On Mon, 14 Apr 2008 20:58:27 +, Ted MacNEIL [EMAIL PROTECTED] wrote:

Hard to change that stuff in a production environment... well, maybe not
hard, just a PITA when there are batch processes and people with their own
clists etc.

In production, standards should be enforced, so it won't become a PITA.


(changed the subject since this has nothing to do with debuggers)

What do local production standards have to do with the sysres names chosen
for sysres dsns (perhaps years and years ago)?  How would standards make
it any easier to change?

The PITA comment was not made by me.
The standards don't make it easier to change.
If done right Production should not be steplib'ing (for example) to system
libraries.


Not your comment, Eh?  Who's post is this??   Perhaps you were too busy
driving to remember.  :-)

http://bama.ua.edu/cgi-bin/wa?A2=ind0804L=ibm-mainD=1amp;amp;O=DT=0P=125149

You can't STEPLIB to ISPPLIB, ISPMLIB, ISPTLIB etc.  Only ISPLLIB can be
eliminated by putting libraries in the LNKLST.


Ted,

To be clear... I used PITA in my post but you wrote In production, 
standards should be enforced, so it won't become a PITA.  

That was when I said  (basically) what do standards have to do with it?.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSRES Data Set Names (was Re: Workable Mainframe Debuggers)

Not your comment, Eh?  Who's post is this??   Perhaps you were too busy 
driving to remember.  :-)

I was responding to the original PITA comment.

The following comment was not mine -- I've lost track of whose it was:

Hard to change that stuff in a production environment... well, maybe not
hard, just a PITA when there are batch processes and people with their own
clists etc.

I responded. This comment was mine:
In production, standards should be enforced, so it won't become a PITA.

My point was: why do people do things in a non-standard (unsupported) way. 
Which you snipped out.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSRES Data Set Names (was Re: Workable Mainframe Debuggers)

That was when I said  (basically) what do standards have to do with it?.

I have lost track of your point.
In (almost) every shop I've worked in, we've set it up so production does not 
point (directly) to system libraries.
They're either in LINK/LPA, catalogued procedures or buried in production 
CLIST/REXX (preferrably the latter).
So, if we have to change some dataset names, we don't have to change production 
JCL.

We just change a single point of access.
Case in point:
Almost two years ago, we converted from PKZIP for z/OS to ZIP/390.
We had 1000's of jobs that used it, but we only had 7 that we had to change -- 
two were for steplibs and the rest because it was not a 100% work-alike.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSRES Data Set Names (was Re: Workable Mainframe Debuggers)

On Mon, 14 Apr 2008 22:19:01 +, Ted MacNEIL [EMAIL PROTECTED] 
wrote:
.

My point was: why do people do things in a non-standard (unsupported) way. 
Which you snipped out.


Then you missed the point.  The point is that there is nothing non-standard 
or unsupported in naming the data sets I was referring to: SYS1.ISP.SISP*, 
SYS1.ISF.SISF* or SYS1.SISP*, SYS1.SISF* or ISP.SISP*, ISF.SISF* (and
others).  IBM default names are the last  examples.  The other 2 examples
are both common (with SYS1.something being the most common from what
I have seen).Again, changing it once it has already been done one
way or the other is what I was referring to as being a PITA.   

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group
mailto: [EMAIL PROTECTED]
z/OS Systems Programming expert at 
http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSRES Data Set Names (was Re: Workable Mainframe Debuggers)

Then you missed the point.  The point is that there is nothing non-standard or 
unsupported in naming the data sets I was referring to:

My point had nothing to do with that, except for redundant qualifiers.

My point was why were production jobs/users pointing to SYS1 datasets directly?
I elabourated in a subsequent post.

I'm sorry I wasn't clear to begin with.

The true point to communication is not to ensure you're understood; rather to 
ensure you're not mis-understood!

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-13 Thread William H. Blair

Paul Gilmartin wrote:

 Is there somewhere a customer who has an esthetic dislike for
 SYS1 and uses an alternative HLQ for production data sets?

I promise you, they are all over the place. If we could somehow
gather all IBM z/OS customers together in one place (like SHARE)
and then arrange things up so that only those who did NOT like 
SYS1 for production data sets could attend SCIDS, you would 
find that the room would be as crowded as it ever has been. 

And then there are those that LOVE SYS1 for production anything.
I'll share but one (very old) example. Recent examples would not
be considered very tactful. But I promise you they exist.

In my (relative) youth, there was an IBM customer, a competitor
of my employer at the time, whose no modifications to the OS
policy dictated that everything went into SYS1.something (since
to have something else would require that it be created, which, 
by definition, would be a modification, hence not allowed). No,
they did not have a clue, but they did have two 360/65s running
just OS/360 -- no ASP, no HASP. They finished upgrading to two 
370/165s and installed ASP literally a few weeks before the 165 
boxes became boat anchors -- a blessing in disguise, since that
eventually resulted in the DP manager's head rolling, which, I
was told by an authoritative source, turned out to be the origin
of much, if not most, of the cluelessness there. 

These maroons (designated thusly, so that we don't give morons
a bad name -- to steal Chris Craddock's lovely phrase) put all 
of their production [COBOL] program load modules into -- hold on
to your hats, folks -- SYS1.LINKLIB.  Yes, I typed and you read 
that correctly. SYS1.LINKLIB. SysONEdotLINKLIB. Date cards were
copied into members of SYS1.PARMLIB (still unblocked F 80 at that
point). No TSO. (What!? Give a programmer direct access to the
system?! Heaven forbid!) Their programmers still did everything 
on cards, literally. No source manager (e.g., ADR LIBRARIAN).

Now, ordinarily, I would have interpreted putting anything at all
into SYS1.anything as a modification but they considered the
creation of something_else.LINKLIB to be a modification. The 
SYS1.LINKLIB data set was already there, and you didn't need to
modify the system to create another load module repository.
Besides, all the examples in the linkage editor manual showed
the use of SYS1.LINKLIB, and that was the default SYSLMOD data
set in many of the PROCs that came in (Gasp!) SYS1.PROCLIB. I
am not making this stuff up. If I were, I would have to make 
sure to make it a lot more believable.

They were forced to upgrade to the 370/165s not because a faster
CPU was needed (obviously, if they were happy running straight
OS/360 without ASP or HASP, then they had CPU and I/O resources
to burn), but simply because SYS1.LINKLIB had grown too large to
be entirely contained on a single 2314. They needed to install
3330s so that their SYS1.LINKLIBs could contain all the OS/360
stuff that IBM put there AND every last production load module
they had. Test programs were in SYS1.LINKLIB on one of the two
machines, and production programs were then re-link edited into 
SYS1.LINKLIB on the production machine.

I don't really know how they shared data among these two systems. 
I asked. They wouldn't say. They might have been embarrassed, but 
that would have required a level of comprehension that I do not
think they had. I understand very little was on DASD. That was OK 
given how they had written their applications: they had a boatload 
of tape drives: TWO full, completely unshared strings for EACH CPU. 
Maybe they did not share data (on DASD, I mean). But I don't know
how they shared tapes, either. They certainly did not have TMS or 
TLMS (in fact, they did not even know what they were, but even I 
thought that was just a joke at the time -- in fact, it was not a 
joke). I do have a _idea_ how they did it, but it would take more 
lines than this list permits me to post in one message to describe 
it. You would not believe ... 

I gave a presentation at the local large system user's group 
about some OS/360 MVT mods I had brought with me from my last
shop (which I was planning to install as soon as we were able
to migrate to MVT) in order to improve shared CVOL catalog 
performance. I remember the talk very well because at that 
point the systems in my shop were still running MFT-II, which
caused these guys to think they were so slick, since they were 
already running MVT! During that talk, which was not all that
technical, their system programmers' eyes glazed over: didn't 
understand the term 'CVOL'.  We both shared an IBM SE; she 
never said much about them other than that the branch manager 
had given her and everyone else explicit instructions never to 
say anything at all about how these guys did things or their 
capabilities, or what she herself did for them.  But her eye 
rolls and unfinished, just-started-but-only-one-word-uttered 
sentences revealed all I needed

Re: Workable Mainframe Debuggers

2008-04-13 Thread Gibney, Dave

We gave up when the first not SYS1 started and just use IBM's names. I
think that in the long run, we're ahead of the naming convention game.

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Ted MacNEIL
 Sent: Saturday, April 12, 2008 7:52 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Workable Mainframe Debuggers

 I often see SYS1.ISF.SISF* , SYS1.ISP.SISP*, SYS1.GIM.SGIM* etc. even
 though the MLQ is redundant.

 I agree with the redundancy argument; what's wrong with each product
 having the same library name(s) at every site?

 Hard to change that stuff in a production environment... well, maybe
not
 hard, just a PITA when there are batch processes and people with their
own
 clists etc.

 In production, standards should be enforced, so it won't become a
PITA.

 If unsupported software breaks, you get to keep both parts.

 -
 Too busy driving to stop for gas!

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-13 Thread Bruce Hewson

A lot of this is personal preference.and now I have to live with another 
group's preference...I can live with that. (i.e. I get to support SYS3.*, 
SYS5.*, SYS7.* and SYS9.* as well)

In the area of change all ServerPac (IBM Product) HLQs to SYS1.*, this meant 
that a single RACF rule protected ALL system datasets. I did understand the 
packaging rules required the shipped prodcut datasets use the 3char product 
identifier as the usual HLQ. It also meant that the special support for 
SYS1.* 
datasets built into DFDSS worked.

Personally, I liked coding a human-readable second level qualifier, like 
SYS1.ISPF.SISP*those people who didn't understand IBM 3/4 char product 
identifiers could at the least suss out which product a dataset belonged to, 
using a quailifier that matched the product acronym.



On Sun, 13 Apr 2008 02:51:34 +, Ted MacNEIL [EMAIL PROTECTED] 
wrote:

I often see SYS1.ISF.SISF* , SYS1.ISP.SISP*, SYS1.GIM.SGIM* etc. even 
though the MLQ is redundant.

I agree with the redundancy argument; what's wrong with each product 
having the same library name(s) at every site?


Hard to change that stuff in a production environment... well, maybe not 
hard, just a PITA when there are batch processes and people with their own 
clists etc.

In production, standards should be enforced, so it won't become a PITA.

If unsupported software breaks, you get to keep both parts.


Regards
Bruce Hewson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-13 Thread Knutson, Sam

XDC http://www.colesoft.com/ is IMHO the gold standard for debugging
assembler on z/OS especially authorized assembler code.  Dave has a
track record of innovation and XDC incorporates a large number of
functional enhancements based on Dave Cole interacting directly with
people who used the product.

A plus is that not only is the product a solid technical solution Cole
provides terms that make it easy to justify for even moderate sized
ISVs.

Best Regards, 

Sam Knutson 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of David Logan
Sent: Friday, April 11, 2008 12:35 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: FW: Workable Mainframe Debuggers

I was wondering if there are any function debuggers on z/OS these days.
Our shop is currently using z/OS 1.5, and the IBM provided LE debugger
(via the LE TEST options) is completely unusable for us. It always has
been.

What suggestions might other people have?

---
David Logan
Manager of Product Development, Pitney Bowes Software, Inc.
http://centrus.com

4750 Walnut St, Suite 200
Boulder, CO  80301

W: (720) 564-3056
C: (303) 818-8222

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-13 Thread Knutson, Sam

Hi,

You don't have to define anything to RACF to use IPCS but you can do
some really useful analysis of a live system if you do. 

If you define BLSACTV.ADDRSPAC and BLSACTV.SYSTEM to the FACILITY class
you can use IPCS as a fairly powerful storage browser.  In anything but
an ISV sandbox you would want to define these with UACC(NONE) and permit
use on limited basis.  Bob Rogers talked about the new capability
briefly during his session 2878 - z/OS 1.9: Sysprog Goody Bag at SHARE
in Orlando.  SYSTEM is new ADDRSPAC previously existed and functionality
has been enhanced. 

http://shareew.prod.web.sba.com/client_files/callpapers/attach/SHARE_in_
Orlando/S2878RR181322.pdf 

Live system analysis with IPCS
IPCS ACTIVE
 Users with no special authorization now can ask IPCS ACTIVE to
access data spaces that unauthorized code can see that are
owned by the ASID.
 Facility class BLSACTIVE ADDRSPAC read access now permits
all data spaces owned by the ASID to be viewed.
 Facility class BLSACTV SYSTEM read access now permits
access to the following:
 ABSOLUTE storage, All ASIDs, All data spaces
 IPCS does not serialize (Caveat emptor)
 Static areas of the system can yield good analysis
 Areas of the system that are altered frequently cannot


 

| Storage is accessed incrementally on demand, and IPCS generally 
| remains enabled. As a result, ACTIVE storage might be subject to 
| frequent changes, which can prevent the analysis programs from 
| producing useful results. 


| ABSOLUTE, ASID, DSPNAME, and HEADER keywords are supported. Access to 
| sensitive storage areas, such as ABSOLUTE, is limited using facility 
| classes. When the user does not have the authority, the access 
| attempts are handled as though the storage in question was not 
| included in a dump. 


| With no special authority, IPCS can access the following storage: 


| The common and private storage in its own ASID visible to a key 8 
| application 

| The data spaces owned by its own ASID and visible to a key 8 
| application 


| Before z/OS V1R9 no data space access was supported. 


| With read authority to facility class BLSACTV.ADDRSPAC, IPCS can look 
| at the following storage (in addition to those storage areas it can 
| access with no special authority) : 


| The common and private storage visible to a key 0 application 

| All data spaces owned by its own ASID 


| Before z/OS V1R9 no data space access was supported. 


| With read authority to facility class BLSACTV.SYSTEM, IPCS can look at

| the following storage (in addition to those storage areas it can 
| access with no special authority) : 


| The ABSOLUTE storage 

| Other ASIDs 

| The data spaces owned by other ASIDs 


| BLSACTV.SYSTEM support was added in z/OS V1R9. 


| Note: IPCS artificially attributes CADS ownerships to ASID(1) as it 
| also does for the page frame table space, ASID(1) 
| DSPNAME(IARPFT). Consistent with this perspective 
| BLSACTV.SYSTEM authority is required to access these data 
| spaces. 


Best Regards, 

Sam Knutson, GEICO 
System z Performance and Availability Management 
mailto:[EMAIL PROTECTED] 
(office)  301.986.3574 

Think big, act bold, start simple, grow fast... 



-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Edward Jaffe
Sent: Friday, April 11, 2008 4:00 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Workable Mainframe Debuggers

Farley, Peter x23353 wrote:
 I've rarely been in a shop that had IPCS

That *had* IPCS?? It comes with the system!

 and also permitted application
 programmers to use it.

I'm not aware of any SAF call or other method to prevent application 
programmers or anyone else from issuing the IPCS command under TSO/E. Is

there?? Perhaps some popular, home-grown way of preventing IPCS access 
for all but sysprogs?? If so, why? Is there also some sort of popular 
exit to prevent them from placing SYSMDUMP DD statements into their
jobs?

   I started in MVT and then early VM/VSE/SP
 environments with some VS1 on the side.  By the time I moved to MVS
 shops, they were so large that they followed the rule: Everything
 permitted is mandatory; everything else is forbidden.
   

-- 
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET

Re: Workable Mainframe Debuggers

2008-04-13 Thread Rick Fochtman

Bill, I was once in a shop like that. The VP that hired me gave me Carte
Blanche with the directive that I bring us up to state of the art.
Took me 18 months to educate some heads and roll others. A HUGE amount
of work, both in educating people and straightening out the mess, but
very rewarding and a great experience. Everyone learned a lot in the
process, including ME! :-)

--snip---

In my (relative) youth, there was an IBM customer, a competitor of my employer at the time, whose no modifications to the OS policy dictated that everything went into SYS1.something (since to have something else would require that it be created, which, by definition, would be a modification, hence not allowed). No, they did not have a clue, but they did have two 360/65s running just OS/360 -- no ASP, no HASP. They finished upgrading to two 370/165s and installed ASP literally a few weeks before the 165 boxes became boat anchors -- a blessing in disguise, since that eventually resulted in the DP manager's head rolling, which, I was told by an authoritative source, turned out to be the origin of much, if not most, of the cluelessness there.

These maroons (designated thusly, so that we don't give morons a bad name -- to steal
Chris Craddock's lovely phrase) put all of their production [COBOL] program load modules
into -- hold on to your hats, folks -- SYS1.LINKLIB. Yes, I typed and you read that
correctly. SYS1.LINKLIB. SysONEdotLINKLIB. Date cards were copied into members of
SYS1.PARMLIB (still unblocked F 80 at that point). No TSO. (What!? Give a programmer
direct access to the system?! Heaven forbid!) Their programmers still did everything on
cards, literally. No source manager (e.g., ADR LIBRARIAN).

Now, ordinarily, I would have interpreted putting anything at all into SYS1.anything as a
modification but they considered the creation of something_else.LINKLIB to be a
modification. The SYS1.LINKLIB data set was already there, and you didn't need to
modify the system to create another load module repository. Besides, all the examples
in the linkage editor manual showed the use of SYS1.LINKLIB, and that was the default SYSLMOD data
set in many of the PROCs that came in (Gasp!) SYS1.PROCLIB. I am not making this stuff up. If I
were, I would have to make sure to make it a lot more believable.

They were forced to upgrade to the 370/165s not because a faster CPU was needed
(obviously, if they were happy running straight OS/360 without ASP or HASP, then they had
CPU and I/O resources to burn), but simply because SYS1.LINKLIB had grown too large to be
entirely contained on a single 2314. They needed to install 3330s so that their
SYS1.LINKLIBs could contain all the OS/360 stuff that IBM put there AND every last
production load module they had. Test programs were in SYS1.LINKLIB on one of the two
machines, and production programs were then re-link edited into SYS1.LINKLIB on the
production machine.

I don't really know how they shared data among these two systems. I asked. They wouldn't say. They might have been embarrassed, but that would have required a level of comprehension that I do not think they had. I understand very little was on DASD. That was OK given how they had written their applications: they had a boatload of tape drives: TWO full, completely unshared strings for EACH CPU. Maybe they did not share data (on DASD, I mean). But I don't know how they shared tapes, either. They certainly did not have TMS or TLMS (in fact, they did not even know what they were, but even I thought that was just a joke at the time -- in fact, it was not a joke). I do have a _idea_ how they did it, but it would take more lines than this list permits me to post in one message to describe it. You would not believe ...

I gave a presentation at the local large system user's group about some OS/360 MVT mods I had brought with me from my last shop (which I was planning to install as soon as we were able to migrate to MVT) in order to improve shared CVOL catalog performance. I remember the talk very well because at that point the systems in my shop were still running MFT-II, which caused these guys to think they were so slick, since they were already running MVT! During that talk, which was not all that technical, their system programmers' eyes glazed over: didn't understand the term 'CVOL'. We both shared an IBM SE; she never said much about them other than that the branch manager had given her and everyone else explicit instructions never to say anything at all about how these guys did things or their capabilities, or what she herself did for them. But her eye rolls and unfinished, just-started-but-only-one-word-uttered sentences revealed all I needed to know.

---snip

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL

Re: Workable Mainframe Debuggers

2008-04-13 Thread Craddock, Chris

My best friend Bill writes... 
 These maroons (designated thusly, so that we don't give morons
 a bad name -- to steal Chris Craddock's lovely phrase)

Actually I stole it from Bugs Bunny because it always gets a laugh. 

The rest of this thread has (as usual) meandered off its original path
and into the area of installation and thence to installation naming
standards. Customers have always insisted on their right to name
everything to their own tastes and of course the system has always
catered to that. 

I will nail my colors to the wall and say that I have always thought
that a monumentally stupid idea, even back in my long ago previous life
as a sysprog. Frankly it just takes a lot of work and produces (as near
as I have ever been able to tell) no tangible benefit. 

The discussion here demonstrates that no two shops are alike and that in
itself is a barrier to the successful migration of people and skills
around the industry. New guy comes in the door with decades of
experience and he's literally clueless and helpless until some local
authority shows him the ropes and gives names to all the rocks the
necessary information is hiding under in this particular shop. 

There are lots of ways out of this dilemma. Other platforms have the
same flexibility in naming, but without the long history of militancy
about local choice they quickly wised up to the idea that its better to
just leave the names alone. There is probably no going back for us,
which is a pity. I like Ed's idea of using indirection. Catalog aliases
might also serve this purpose quite elegantly but they are a pain in the
butt to deal with too. The simplest practice is probably just not to
rename them in the first place. 

CC

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-13 Thread Rob Scott

The simplest practice is probably just not to rename them in the first place.

I agree in principle - however the sysprogs of yesteryear were not helped by 
software being supplied as foo.VnRnMn.bar as thus a complete maintenance 
headache when upgrades are required. Even only a few years ago when I was 
wearing my sysprog hat I had to juggle the ADCD dataset placement issues 
because IBM had moved sys1.foo from volume1 to volume2 between releases for 
some strange reason -  thus providing me with a few hours of catalog sync 
issues or dataset movement that was time consuming and error-prone.


Rob Scott
Rocket Software, Inc
275 Grove Street
Newton, MA 02466
617-614-2305
[EMAIL PROTECTED]


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of 
Craddock, Chris
Sent: 13 April 2008 20:07
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Workable Mainframe Debuggers

My best friend Bill writes...
 These maroons (designated thusly, so that we don't give morons a bad
 name -- to steal Chris Craddock's lovely phrase)

Actually I stole it from Bugs Bunny because it always gets a laugh.

The rest of this thread has (as usual) meandered off its original path and into 
the area of installation and thence to installation naming standards. Customers 
have always insisted on their right to name everything to their own tastes and 
of course the system has always catered to that.

I will nail my colors to the wall and say that I have always thought that a 
monumentally stupid idea, even back in my long ago previous life as a sysprog. 
Frankly it just takes a lot of work and produces (as near as I have ever been 
able to tell) no tangible benefit.

The discussion here demonstrates that no two shops are alike and that in itself 
is a barrier to the successful migration of people and skills around the 
industry. New guy comes in the door with decades of experience and he's 
literally clueless and helpless until some local authority shows him the ropes 
and gives names to all the rocks the necessary information is hiding under in 
this particular shop.

There are lots of ways out of this dilemma. Other platforms have the same 
flexibility in naming, but without the long history of militancy about local 
choice they quickly wised up to the idea that its better to just leave the 
names alone. There is probably no going back for us, which is a pity. I like 
Ed's idea of using indirection. Catalog aliases might also serve this purpose 
quite elegantly but they are a pain in the butt to deal with too. The simplest 
practice is probably just not to rename them in the first place.

CC

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
[EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-13 Thread Clark Morris

On 11 Apr 2008 17:49:18 -0700, in bit.listserv.ibm-main you wrote:

Farley, Peter x23353 wrote:
 I probably should have added the phrase available to the application
 programmer.  And yes, most of the MVS sites at which I worked used
 ignorance and information hiding to do it.  Plus a little attitude --
 Real programmers only use SYSUDUMP kind of attidude.
   

C'mon, Dude! I came up as an application programmer in a prominent 
Southern California bank back in the 1980s. Our sysprogs -- full 
disclosure: Skip Robinson from SCE was one of them -- did their jobs; we 
did ours. They didn't teach us about how to use TSO/E commands, how to 
use ISPF, or how to use/manage any of the other myriad MVS batch and 
online programs and facilities that we could run. We simply read the 
manuals to learn.

In those days, we ordered paper manuals. There was only so much space in 
your cubicle and the books were not ultra cheap. I suppose, if one 
ordered an IPCS manual, it's conceivable your manager *might* ask, What 
do you need that for? We also had a library with shelves full of 
manuals we could all share.

(FYI: I purchased G and S manuals directly from IBM for my own 
collection at home. It was purely my choice which ones to buy. I spent a 
fortune on them!  :-$ )

I doubt the sysprogs of today are any more interested in teaching 
application programmers how to use TSO/E than they were 25 years ago. 
Application programmers must still read manuals to learn how to use the 
system. And, these days, manuals are available for free, via the 
Internet, covering every imaginable aspect of z/OS!

I'd like to know just how evil, 21st-century, Darth-Vader-like sysprogs 
use ignorance and information hiding to prevent application 
programmers from knowing anything about IPCS. IPCS is just as easy a 
command to type as ISPF and the doc is as freely available as it is for 
any other built-in command or facility that runs under z/OS! (That is, 
unless the sysprogs are censoring the Internet!)

This may depend on how restrictive management is with ISPF.  Back in
the 1980's and early 1990's my shop restricted the use of TSO commands
severely and made ISPF the sole environment except for systems
programmers.  We finally were allowed to give them PDS.  At the time
IPCS was such a pain to set up that I found it easier to just read the
dumps normally for the few occasions where I needed them.  Abendaid
was more than adequate for the applications and understood COBOL.  The
LE dumps of the late 1990's also were good for debugging and for most
purposes IPCS would probably have been more trouble than it was worth.

Clark Morris

I suggest a more reasonable explanation is that the application 
programmers *themselves* are avoiding IPCS

 In any case, I've never been privileged to learn it or use it.
   

It's never too late! ;-)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-13 Thread Ted MacNEIL

I probably should have added the phrase available to the application
programmer.  And yes, most of the MVS sites at which I worked used
ignorance and information hiding to do it.  Plus a little attitude

With the INTERNET, and IBM storing almost every product document on it, there 
is no excuse for ignorance.

Look 'em up!

(Of course, you may have to explain to your boss why you are playing with this 
stuff, rather than writing application code)

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-13 Thread Don Leahy

  I suggest a more reasonable explanation is that the application
  programmers *themselves* are avoiding IPCS
  
   In any case, I've never been privileged to learn it or use it.
  
  
  It's never too late! ;-)


Where there are perfectly adequate tools available (Abend Aid, Debug
Tool, Dump Master etc) there is also very little incentive to learn
IPCS.

To solve application abends (except for the most exotic ones) all you
need is a tool that helps you figure out where the abend occurred and
formats the application's  Working Storage areas in a format that is
easy to relate to a compile listing.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-13 Thread CICS Guy

Just to throw my two cents into this, I've always prefered the printed dump, 
from VSE, I could (usually) find the problem
 
Once I got stuck into the MVS environment, I have been trying to understand and 
use IPCS, and not with too much success...grinSomething just hasn't 
'clicked' yet, but I keep searching.
 
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Don 
Leahy
Sent: Sunday, April 13, 2008 6:48 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Workable Mainframe Debuggers
Where there are perfectly adequate tools available (Abend Aid, Debug Tool, Dump 
Master etc) there is also very little incentive to learn IPCS.
To solve application abends (except for the most exotic ones) all you need is a 
tool that helps you figure out where the abend occurred and formats the 
application's Working Storage areas in a format that is easy to relate to a 
compile listing.
_
More immediate than e-mail? Get instant access with Windows Live Messenger.
http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_instantaccess_042008
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-13 Thread Linda Mooney

I can relate.  Try the IPCS sessions and labs at Share. Helped me out a lot

Linda

-- Original message -- 
From: CICS Guy [EMAIL PROTECTED] 

 Just to throw my two cents into this, I've always prefered the printed dump, 
 from VSE, I could (usually) find the problem 
 
 Once I got stuck into the MVS environment, I have been trying to understand 
 and 
 use IPCS, and not with too much success...grinSomething just hasn't 
 'clicked' yet, but I keep searching. 
 
 -Original Message- 
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of 
 Don Leahy 
 Sent: Sunday, April 13, 2008 6:48 PM 
 To: IBM-MAIN@BAMA.UA.EDU 
 Subject: Re: Workable Mainframe Debuggers 
 Where there are perfectly adequate tools available (Abend Aid, Debug Tool, 
 Dump 
 Master etc) there is also very little incentive to learn IPCS. 
 To solve application abends (except for the most exotic ones) all you need is 
 a 
 tool that helps you figure out where the abend occurred and formats the 
 application's Working Storage areas in a format that is easy to relate to a 
 compile listing. 
 _ 
 More immediate than e-mail? Get instant access with Windows Live Messenger. 
 http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_ins
  
 tantaccess_042008 
 -- 
 For IBM-MAIN subscribe / signoff / archive access instructions, 
 send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO 
 Search the archives at http://bama.ua.edu/archives/ibm-main.html 
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-12 Thread Mark Zelden

On Fri, 11 Apr 2008 17:49:02 -0700, Edward Jaffe
[EMAIL PROTECTED] wrote:


I'd like to know just how evil, 21st-century, Darth-Vader-like sysprogs
use ignorance and information hiding to prevent application
programmers from knowing anything about IPCS. 

I would say the majority of the shops I've been at  (over 30) use different
logon procs or starup clists based on userid and different ISPF menus for
different groups.  TECH, OPS (often together), application programmers and 
then the end user that only gets the old [EMAIL PROTECTED], SDSF and maybe an 
application to view output if lucky.   At least in my experience, the
application
programmer menus never had IPCS.  Just like they didn't have HCD, WLM and
some of the other system programmer ISPF applications now one the 
standard [EMAIL PROTECTED] menu (which most shops don't use since everyone has
their history of what their menus look like to end users and don't like to
change that).  But note that IPCS is on the [EMAIL PROTECTED] user menu now.
Other shops just had invocation CLISTs for some of these and unless you
knew the names or hunted for them, you wouldn't know how to get into
the ISPF dialogs.


So it probably isn't intentional hiding, but if the programmers don't see IPCS
on the menu, it doesn't exist for them and even if they have seen it at another
shop may assume they can't use it where they are at.   Heck, half the time I
couldn't find what I wanted or needed at the shops I consulted at which is 
why I developed all my own shortcuts (ISPCMDS) and LIBDEF clists similar
to Tom Conley's ISPF starter set.  Of course the best part about that is
I used the same commands at every shops I consulted at.  I didn't have
to worry about SDSF being option 8 at one stop, option 14 at another and
S or SD at still another and finding where the SMP/E option was. 

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-12 Thread Edward Jaffe


Mark Zelden wrote:

So it probably isn't intentional hiding, but if the programmers don't see IPCS
on the menu, it doesn't exist for them and even if they have seen it at another
shop may assume they can't use it where they are at.


Great points Mark!

You said, ... note that IPCS is on the [EMAIL PROTECTED] user menu now. I'd 
like to emphasize that IPCS has been on that sample user menu since it 
was first delivered way back in OS/390 1.x!


Out of curiosity, I ran an experiment to find out how hard it would be 
to poke around and make IPCS work in an unfamiliar environment. The 
quickest way is to use basic line mode IPCS. (Why not? As an application 
programmer, that's the way we used TSO TEST!)


First, a couple of commands to be sure I don't cheat:
| READY
|delete ddir
| IDC3901I ERROR QUALIFYING JOEUSER.DDIR
| IDC3902I ** DEFAULT SERVICE ROUTINE ERROR CODE 20, LOCATE ERROR CODE 8
| IDC0014I LASTCC=8
| READY
|free all
| READY

OK. Let's give it a try:

|ipcs
| BLS21001I IPCS for z/OS 01.09.00
| IKJ56584I BLSCDDIR NOT FOUND.  REQUIRED DDNAME SYSUPROC IS NOT ALLOCATED.
| BLS21020I FILE(IPCSDDIR) not allocated
| READY

Right out of the gate, something is wrong. At this point, I would be 
stuck without the manual. In the old days, that would be that. But, this 
is 2008! I navigate my browser to the IPCS User's Guide and search for 
BLSCDDIR, I find this:


http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2c640/4.3.1.1

It tells me exactly where to find the BLSCDDIR CLIST and what it's used 
for. Let's try it:


|ex 'sys1.sblscli0(blscddir)'
| Dump directory name 'JOEUSER.DDIR' will be used
| Dump directory space will be allocated in units of 15000 records
| Dump directory space will be allocated on volume VSAM01
| DEFINE CLUSTER(NAME('JOEUSER.DDIR') VOLUME(VSAM01) INDEXED REUSE 
SHAREOPTIONS(1,3)) INDEX(NAME('JOEUSER.DDIR.I') RECORDS(150,150) 
CONTROLINTERVALSIZE(4096)) DATA(NAME('JOEUSER.DDIR.D') 
RECORDS(15000,15000) KEYS(128,0) RECORDSIZE(2560 3072)  
BUFFERSPACE(1024000)) /*@L1C*/

| IDC0508I DATA ALLOCATION STATUS FOR VOLUME MVSPV1 IS 0
| IDC0509I INDEX ALLOCATION STATUS FOR VOLUME MVSPV1 IS 0
| IDC0181I STORAGECLASS USED IS BASE
| IDC0181I MANAGEMENTCLASS USED IS STANDARD
| IDC0181I DATACLASS USED IS KEYEDNC
| IPCSDDIR 'JOEUSER.DDIR' /*   @P1C*/
| ALLOCATE FILE(IPCSDDIR) REUSE DSNAME('JOEUSER.DDIR') SHR /* @P1C*/
| Dump directory 'JOEUSER.DDIR' allocated to FILE(IPCSDDIR)
| READY

Whoa! OK. Let me try that IPCS command again:

|ipcs
| BLS21001I IPCS for z/OS 01.09.00
| IPCS

I'm in!!

|summ active
| BLS18224I Dump of z/OS 01.09.00 - level same as IPCS level
|
|
| * * * *   K E Y F I E L D S   * * * *
| JOBNAME JOEUSER
| SELECTED BY: CURRENT
|
|  ASCB: 00FCDE80
| FWDP. 00F99B80  ASID. 0080  CSCB. 0AD74800
| TSB.. 00D1BBF0  AFFN.   ASXB. 00AFDDF8  
DSP1. 00

| FLG2. 00SRBS.   LOCK. 
| ASSB. 01F6E480
|
|  TCB: 00AFE030
| CMP..   PKF.. 00LMP.. FF
DSP.. FF

| TSFLG 00STAB. 00AFD588  NDSP. 
| JSCB. 00AFCE84  BITS.   DAR.. 00
| RTWA.   FBYT1 00
| Task non-dispatchability flags from TCBFLGS4:
|  Top RB is in a wait
|
|  PRB: 00AFDCB0
| WLIC. 00020001  OPSW. 070C1000  8117B0EA
| LINK. 01AFE030
| EP... IEAVAR00  ENTPT 86D37878
|
| (similar stuff snipped)
|
|  TCB: 00AF8928
| CMP..   PKF.. 80LMP.. FF
DSP.. FF

| TSFLG 00STAB. 00AFD288  NDSP. 
| JSCB. 00AFC194  BITS.   DAR.. 00
| RTWA.   FBYT1 00
| Task non-dispatchability flags from TCBFLGS4:
|  Top RB is in a wait
|
|  PRB: 00AF8E00
| WLIC. 00020001  OPSW. 078D1000  80030CB6
| LINK. 01AF8928
| EP... IPCS  MAJOR BLSU  ENTPT 80011340
|
|  TCB: 00AF85D8
| CMP..   PKF.. 80LMP.. FE
DSP.. FE

| TSFLG 00STAB. 00AFD1C8  NDSP. 
| JSCB. 00AFC194  BITS.   DAR.. 00
| RTWA.   FBYT1 00
|
|  PRB: 00AF88A0
| WLIC. 00020078  OPSW. 078D1000  80D59E1E
| LINK. 00AF85D8
| EP... BLSUINI2  MAJOR BLSU  ENTPT 8002A188
| IPCS

With only a bit more reading, I'll see that to get IPCS to use ISPF 
services, I must allocate the following data sets via ALTLIB/LIBDEF or 
any means available to me:

SYS1.SBLSCLI0
SYS1.SBLSKEL0
SYS1.SBLSMSG0
SYS1.SBLSPNL0
SYS1.SBLSTBL0

One of the easier hacks ...

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

Re: Workable Mainframe Debuggers

2008-04-12 Thread Mark Zelden

On Sat, 12 Apr 2008 08:45:21 -0700, Edward Jaffe
[EMAIL PROTECTED] wrote:


Out of curiosity, I ran an experiment to find out how hard it would be
to poke around and make IPCS work in an unfamiliar environment. 

snip


OK. Let's give it a try:

|ipcs
| BLS21001I IPCS for z/OS 01.09.00
| IKJ56584I BLSCDDIR NOT FOUND.  REQUIRED DDNAME SYSUPROC IS NOT ALLOCATED.
| BLS21020I FILE(IPCSDDIR) not allocated
| READY

Right out of the gate, something is wrong. 

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2c640/4.3.1.1

It tells me exactly where to find the BLSCDDIR CLIST and what it's used
for. Let's try it:

|ex 'sys1.sblscli0(blscddir)'

snip


I'm in!!


snip


With only a bit more reading, I'll see that to get IPCS to use ISPF
services, I must allocate the following data sets via ALTLIB/LIBDEF or
any means available to me:
SYS1.SBLSCLI0
SYS1.SBLSKEL0
SYS1.SBLSMSG0
SYS1.SBLSPNL0
SYS1.SBLSTBL0

One of the easier hacks ...


Even easier than that.  

If you start with  EX 'SYS1.SBLSCLI0(BLSCLIBD)' it does the libdefs and
executes BLSCDDIR for you.  

Of course this is dependent on using the default names of SYS1.SBLS*.  
One shop I was at used SYS1.BLS.SBLS* or BLS.SBLS*.  I think at one time it 
may have been delivered in CBIPO as BLS.SBLS* (like other products)
and some shops just stuck SYS1 in front of the name. I often see 
SYS1.ISF.SISF* , SYS1.ISP.SISP*, SYS1.GIM.SGIM* etc. even
though the MLQ is redundant.   Hard to change that stuff in a production
environment... well, maybe not hard, just a PITA when there are batch
processes and people with their own clists etc.  

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-12 Thread Edward Jaffe


Mark Zelden wrote:

On Sat, 12 Apr 2008 08:45:21 -0700, Edward Jaffe
[EMAIL PROTECTED] wrote:
  

One of the easier hacks ...




Even easier than that.  


If you start with  EX 'SYS1.SBLSCLI0(BLSCLIBD)' it does the libdefs and
executes BLSCDDIR for you.
  


Thanks for pointing that out! And, your approach is fully documented here:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2c640/2.1.3

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-12 Thread Paul Gilmartin

On Sat, 12 Apr 2008 11:26:26 -0500, Mark Zelden wrote:

 ...

Of course this is dependent on using the default names of SYS1.SBLS*.
One shop I was at used SYS1.BLS.SBLS* or BLS.SBLS*.  I think at one time it
may have been delivered in CBIPO as BLS.SBLS* (like other products)
and some shops just stuck SYS1 in front of the name. I often see
SYS1.ISF.SISF* , SYS1.ISP.SISP*, SYS1.GIM.SGIM* etc. even
though the MLQ is redundant.   Hard to change that stuff in a production
environment... well, maybe not hard, just a PITA when there are batch
processes and people with their own clists etc.

A couple years ago, there was a thread here which advanced the
opinion that it is harmful for vendors to attempt to influence
the customers' choice of data set names for installation of
their products.  Incredibly, one of the arguments was, Well,
you gotta have standards so programmers know where to find
stuff!  You seem to have provided a PITA argument for uniformity.

I believe that ease of installation of squatty box products
arises from providing customers guidance in this area, and the
customers' willingness to follow that guidance.  Further
benefits for the customer are easy interoperability of
products with less configuration labor, and for the vendors
greater market success.

I do not deny the argument that the customer must be able to
choose installation on an alternate path for testing, but only
a masochistic customer chooses an idiosyncratic path for
production use.

Is there somewhere a customer who has an esthetic dislike for
SYS1 and uses an alternative HLQ for production data sets?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-12 Thread Ted MacNEIL

I often see SYS1.ISF.SISF* , SYS1.ISP.SISP*, SYS1.GIM.SGIM* etc. even though 
the MLQ is redundant.

I agree with the redundancy argument; what's wrong with each product having the 
same library name(s) at every site?


Hard to change that stuff in a production environment... well, maybe not hard, 
just a PITA when there are batch processes and people with their own clists 
etc.

In production, standards should be enforced, so it won't become a PITA.

If unsupported software breaks, you get to keep both parts.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-11 Thread Craddock, Chris

 I was wondering if there are any function debuggers on z/OS these
days.
 Our shop is currently using z/OS 1.5, and the IBM provided LE debugger
 (via the LE TEST options) is completely unusable for us. It always has
 been.
 
 What suggestions might other people have?

You can't go past zXDC from Cole Software. 

CC

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-11 Thread Chase, John

 -Original Message-
 From: IBM Mainframe Discussion List On Behalf Of David Logan
 
 I was wondering if there are any function debuggers on z/OS 
 these days.
 Our shop is currently using z/OS 1.5, and the IBM provided LE 
 debugger (via the LE TEST options) is completely unusable for 
 us. It always has been.
 
 What suggestions might other people have?

I don't know of any other built-in facilities (beyond TSO TEST), or
any free ones, but IBM and other vendors offer debuggers at various
(but presumably competitive) fees.  Our shop currently licenses
Compuware's Xpediter for COBOL debugging (batch and CICS).  If you're
into serious bit-twiddling with Assembler, I've heard you can't beat
this one:

http://www.colesoft.com/overview.shtml

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-11 Thread Rob Scott

CLC  DEBUGGER,=C'XDC'
BNE  BADCHOICE
WTO 'YOU HAVE CHOSEN WELL, MY SON'



Rob Scott
Rocket Software, Inc
275 Grove Street
Newton, MA 02466
617-614-2305
[EMAIL PROTECTED]


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of 
Craddock, Chris
Sent: 11 April 2008 18:00
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Workable Mainframe Debuggers

 I was wondering if there are any function debuggers on z/OS these
days.
 Our shop is currently using z/OS 1.5, and the IBM provided LE debugger
 (via the LE TEST options) is completely unusable for us. It always has
 been.

 What suggestions might other people have?

You can't go past zXDC from Cole Software.

CC

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
[EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

I know of the following:

z/XDC from Cole software (www.colesoft.com) (assembler only?)
Xpeditor from Compuware (www.compuware.com) dump analysis with AbendAID
Intertest from CA (www.ca.com) dump analysis with Symdump
TraceMaster from Macro4 (www.macro4.com) dump analysis with DumpMaster
Track from MacKinney Systems (CICS only) www.mackinney.com

I've worked with Intertest and Xpeditor and tested TraceMaster. Our
programmers went with Xpeditor due mainly, they said, to their previous
experience. From my testing, I really loved TraceMaster from Macro4. I,
personally, wish that we had gone with it.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-11 Thread Jerry Fuchs

We use MacKinney Systems TRACK for batch and XRAY for CICS.

They are very inexpensive but work very well

Jerry 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-11 Thread Thompson, Steve

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of David Logan
Sent: Friday, April 11, 2008 11:35 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: FW: Workable Mainframe Debuggers

I was wondering if there are any function debuggers on z/OS these days.
Our shop is currently using z/OS 1.5, and the IBM provided LE debugger
(via the LE TEST options) is completely unusable for us. It always has
been.

What suggestions might other people have?
SNIP

For ALC based environments:

TSO TEST and TEST[AUTH] for very simple things.

zXDC for anything complicated or involved (and yes, we sometimes use it
to deal with LE and C code).

Regards,
Steve Thompson

-- All opinions expressed by me are my own and may not necessarily
reflect those of my employer. --

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-11 Thread Farley, Peter x23353

If the OP is also interested in post-mortem dump analysis tools (as
opposed to just interactive debugging), I'll add a recommendation for
Dumpmaster from Macro4 (handles both batch and CICS).  My only complaint
about that fine product is that it doesn't capture *all* the TCB's in an
AS, just the one that abended.  At one time I supported a massively
multitasking assembler-based application where I needed to see the state
of tasks other than the one that died and could not always see what I
needed to see when I needed to from inside Dumpmaster.

But then, no other post-mortem tool I'm aware of does that either,
though I'm sure I'll be quickly corrected if there is.

HTH

Peter


 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of McKown, John
 Sent: Friday, April 11, 2008 1:23 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Workable Mainframe Debuggers
 
 I know of the following:
 
 z/XDC from Cole software (www.colesoft.com) (assembler only?)
 Xpeditor from Compuware (www.compuware.com) dump analysis with
AbendAID
 Intertest from CA (www.ca.com) dump analysis with Symdump
 TraceMaster from Macro4 (www.macro4.com) dump analysis with DumpMaster
 Track from MacKinney Systems (CICS only) www.mackinney.com
 
 I've worked with Intertest and Xpeditor and tested TraceMaster. Our
 programmers went with Xpeditor due mainly, they said, to their
previous
 experience. From my testing, I really loved TraceMaster from Macro4.
I,
 personally, wish that we had gone with it.


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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers


Farley, Peter x23353 wrote:

But then, no other post-mortem tool I'm aware of does that either,
though I'm sure I'll be quickly corrected if there is.
  


I've never had an issue like that using IPCS.

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-11 Thread Thompson, Steve

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Farley, Peter x23353
Sent: Friday, April 11, 2008 1:46 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Workable Mainframe Debuggers

If the OP is also interested in post-mortem dump analysis tools (as
opposed to just interactive debugging), I'll add a recommendation for
Dumpmaster from Macro4 (handles both batch and CICS).  My only complaint
about that fine product is that it doesn't capture *all* the TCB's in an
AS, just the one that abended.  At one time I supported a massively
multitasking assembler-based application where I needed to see the state
of tasks other than the one that died and could not always see what I
needed to see when I needed to from inside Dumpmaster.

But then, no other post-mortem tool I'm aware of does that either,
though I'm sure I'll be quickly corrected if there is.
snip

Since you insist: IPCS. In dealing with multi-tasking (and even cross
memory situations) I'd much rather have a dump taken to SYSMDUMP or
system dump dataset than to paper.

Regards,
Steve Thompson

-- All opinions expressed by me are my own and may not necessarily
reflect those of my employer. --

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-11 Thread Farley, Peter x23353

I've rarely been in a shop that had IPCS and also permitted application
programmers to use it.  I started in MVT and then early VM/VSE/SP
environments with some VS1 on the side.  By the time I moved to MVS
shops, they were so large that they followed the rule: Everything
permitted is mandatory; everything else is forbidden.

Maybe one day...

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Edward Jaffe
 Sent: Friday, April 11, 2008 2:50 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Workable Mainframe Debuggers
 
 Farley, Peter x23353 wrote:
  But then, no other post-mortem tool I'm aware of does that either,
  though I'm sure I'll be quickly corrected if there is.
 
 
 I've never had an issue like that using IPCS.


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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-11 Thread Eric Bielefeld

Here we used to have Xpediter.  That was thrown out in favor of Intertest - I 
suspect mostly because of cost.  Just a few weeks ago, we went back to Xpediter 
because the programmers liked it better.  I suspect that because we were bought 
by Aviva, the 5th largest Life insurer in the world, that they got pricing 
deals from Compuware making it much more affordable.

Eric

 Farley wrote: 
 For COBOL my shop uses Intertest (CICS and Batch), other shops I have
 been at use Xpediter.  For CICS there is also ADS (Advanced Debugging
 System) from Gary Bergman Associates, which you can rent by the month if
 you need to (COBOL and Assembler).
 
 HTH
 
 Peter
--
Eric Bielefeld
Systems Programmer
Aviva USA
Des Moines, Iowa
515-645-5153

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers


Farley, Peter x23353 wrote:

I've rarely been in a shop that had IPCS


That *had* IPCS?? It comes with the system!


and also permitted application
programmers to use it.


I'm not aware of any SAF call or other method to prevent application 
programmers or anyone else from issuing the IPCS command under TSO/E. Is 
there?? Perhaps some popular, home-grown way of preventing IPCS access 
for all but sysprogs?? If so, why? Is there also some sort of popular 
exit to prevent them from placing SYSMDUMP DD statements into their jobs?



  I started in MVT and then early VM/VSE/SP
environments with some VS1 on the side.  By the time I moved to MVS
shops, they were so large that they followed the rule: Everything
permitted is mandatory; everything else is forbidden.
  


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

 -Original Message-
 From: IBM Mainframe Discussion List 
 [mailto:[EMAIL PROTECTED] On Behalf Of Eric Bielefeld
 Sent: Friday, April 11, 2008 2:56 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Workable Mainframe Debuggers

 Here we used to have Xpediter.  That was thrown out in favor 
 of Intertest - I suspect mostly because of cost.  Just a few 
 weeks ago, we went back to Xpediter because the programmers 
 liked it better.  I suspect that because we were bought by 
 Aviva, the 5th largest Life insurer in the world, that they 
 got pricing deals from Compuware making it much more affordable.

 Eric

Gee, we did the exact same thing. For exactly the same reasons! Except
that we were bought out by Blackstone and taken private. Queue the
Twilight Zone song!

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

 -Original Message-
 From: IBM Mainframe Discussion List 
 [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe
 Sent: Friday, April 11, 2008 3:00 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Workable Mainframe Debuggers

 I'm not aware of any SAF call or other method to prevent application 
 programmers or anyone else from issuing the IPCS command 
 under TSO/E. Is 
 there?? Perhaps some popular, home-grown way of preventing 
 IPCS access 
 for all but sysprogs?? If so, why? Is there also some sort of popular 
 exit to prevent them from placing SYSMDUMP DD statements into 
 their jobs?

It would be simple to do by customizing one of the IPCS clists. Or just
keep them ignorant of it. Why would a normal programmer ever want to
use IPCS? Ours have a bad enough time trying to use AbendAID! If for any
reason they cannot get a symbolic dump (i.e. the source is out of date
or some such), then they usually just throw up their hands and declare
the problem unresolvable until a listing is available and the program
recreated.

 -- 
 Edward E Jaffe

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers


McKown, John wrote:
It would be simple to do by customizing one of the IPCS clists. 


But, is this what *most* shops do?


Or just
keep them ignorant of it. Why would a normal programmer ever want to
use IPCS? 


It's the only way I know to analyze a SYSMDUMP or a data set created by 
the IEATDUMP macro -- a dump service intended for ordinary, 
problem-state application program use.


http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a671/9.3

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-11 Thread Steve Comstock


Edward Jaffe wrote:

McKown, John wrote:
It would be simple to do by customizing one of the IPCS clists. 


But, is this what *most* shops do?


Or just
keep them ignorant of it. Why would a normal programmer ever want to
use IPCS? 


It's the only way I know to analyze a SYSMDUMP or a data set created by 
the IEATDUMP macro -- a dump service intended for ordinary, 
problem-state application program use.


http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a671/9.3


1. I agree that few shops let applications programmers at IPCS

2. Mainly by keeping them in the dark

3. I think this started out a long time ago because SYSMDUMPs
   created large outputs (filling spool?) and were thought to
   be only for IBM support

4. Even if they had access to them, most programmers would not
   care to look; as John pointed out, they simply consider the
   dump unreadable.


Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

== call or email to receive a free sample student handout ==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

 -Original Message-
 From: IBM Mainframe Discussion List 
 [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe
 Sent: Friday, April 11, 2008 3:17 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Workable Mainframe Debuggers

 It's the only way I know to analyze a SYSMDUMP or a data set 
 created by 
 the IEATDUMP macro -- a dump service intended for ordinary, 
 problem-state application program use.

 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea
2a671/9.3

-- 
Edward E Jaffe

Is that a COBOL verb? If it ain't COBOL, our programmers ain't a gonna
bother with it. [grin?]

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-11 Thread Kirk Talman

You must work in heaven.  Obtaining a tool just because the pgmrs wanted 
it?  Oh my heart be still.

btw we went from XBUG to IDT (IBM debug tool).  plus the other tools in 
set.  there was a price issue (10's of kmips).

IDT has a serious learning curve w/ new releases yearly.

IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 04/11/2008 
03:56:19 PM:

 Here we used to have Xpediter.  That was thrown out in favor of 
 Intertest - I suspect mostly because of cost.  Just a few weeks ago,
 we went back to Xpediter because the programmers liked it better.  I

 Eric Bielefeld



-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. The information may also constitute a legally
privileged confidential communication. If the reader of this
message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified
that you have received this communication in error and that any
review, dissemination, copying, or unauthorized use of this
information, or the taking of any action in reliance on the
contents of this information is strictly prohibited. If you have
received this communication in error, please notify us immediately
by e-mail, and delete the original message. Thank you 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-11 Thread Ted MacNEIL

I've rarely been in a shop that had IPCS

Isn't IPCS a 'bundled' product?

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-11 Thread Farley, Peter x23353

I probably should have added the phrase available to the application
programmer.  And yes, most of the MVS sites at which I worked used
ignorance and information hiding to do it.  Plus a little attitude --
Real programmers only use SYSUDUMP kind of attidude.

In any case, I've never been privileged to learn it or use it.

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Ted MacNEIL
 Sent: Friday, April 11, 2008 6:05 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Workable Mainframe Debuggers
 
 I've rarely been in a shop that had IPCS
 
 Isn't IPCS a 'bundled' product?


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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-11 Thread Don Leahy

On Fri, Apr 11, 2008 at 4:38 PM, Steve Comstock
[EMAIL PROTECTED] wrote:


  1. I agree that few shops let applications programmers at IPCS

  2. Mainly by keeping them in the dark

  3. I think this started out a long time ago because SYSMDUMPs
created large outputs (filling spool?) and were thought to
be only for IBM support

  4. Even if they had access to them, most programmers would not
care to look; as John pointed out, they simply consider the
dump unreadable.

In my 25 years as an application programmer, I have never seen IPCS.
I knew it existed, but was under the impression it was only useful for
sysprogs.  So, count me in the keeping them in the dark category.

A couple of years ago we moved from Abendaid to IBM's Fault Analyzer.
Initially FA was resisted by the programmers but once they were shown
how to use its symbolic debugging features, the resistance crumbled.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers


Farley, Peter x23353 wrote:

I probably should have added the phrase available to the application
programmer.  And yes, most of the MVS sites at which I worked used
ignorance and information hiding to do it.  Plus a little attitude --
Real programmers only use SYSUDUMP kind of attidude.
  


C'mon, Dude! I came up as an application programmer in a prominent 
Southern California bank back in the 1980s. Our sysprogs -- full 
disclosure: Skip Robinson from SCE was one of them -- did their jobs; we 
did ours. They didn't teach us about how to use TSO/E commands, how to 
use ISPF, or how to use/manage any of the other myriad MVS batch and 
online programs and facilities that we could run. We simply read the 
manuals to learn.


In those days, we ordered paper manuals. There was only so much space in 
your cubicle and the books were not ultra cheap. I suppose, if one 
ordered an IPCS manual, it's conceivable your manager *might* ask, What 
do you need that for? We also had a library with shelves full of 
manuals we could all share.


(FYI: I purchased G and S manuals directly from IBM for my own 
collection at home. It was purely my choice which ones to buy. I spent a 
fortune on them!  :-$ )


I doubt the sysprogs of today are any more interested in teaching 
application programmers how to use TSO/E than they were 25 years ago. 
Application programmers must still read manuals to learn how to use the 
system. And, these days, manuals are available for free, via the 
Internet, covering every imaginable aspect of z/OS!


I'd like to know just how evil, 21st-century, Darth-Vader-like sysprogs 
use ignorance and information hiding to prevent application 
programmers from knowing anything about IPCS. IPCS is just as easy a 
command to type as ISPF and the doc is as freely available as it is for 
any other built-in command or facility that runs under z/OS! (That is, 
unless the sysprogs are censoring the Internet!)


I suggest a more reasonable explanation is that the application 
programmers *themselves* are avoiding IPCS



In any case, I've never been privileged to learn it or use it.
  


It's never too late! ;-)

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-11 Thread Ted MacNEIL

And yes, most of the MVS sites at which I worked used ignorance and 
information hiding to do it.  Plus a little attitude -- Real programmers only 
use SYSUDUMP kind of attidude.

I think there is a huge chip on your shoulder.
Most technical types realise we're all on the same side.
Our attitude comes from the fact that we, as SME's, are trying to help, but you 
don't like our solutions.
So, is that arrogance, or frustration on our part?

If I give you an answer, and you don't want to hear it, does that make me 
arrogant, because you won't listen to me?
Or, does that make you arrogant, because you won't listen to me?

We are SME's for a reason!

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers

2008-04-11 Thread Gibney, Dave

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Edward Jaffe
 Sent: Friday, April 11, 2008 5:49 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Workable Mainframe Debuggers

 Farley, Peter x23353 wrote:
  I probably should have added the phrase available to the
application
  programmer.  And yes, most of the MVS sites at which I worked used
  ignorance and information hiding to do it.  Plus a little attitude
--
  Real programmers only use SYSUDUMP kind of attidude.

 C'mon, Dude! I came up as an application programmer in a prominent
 Southern California bank back in the 1980s. Our sysprogs -- full
 disclosure: Skip Robinson from SCE was one of them -- did their jobs;
we
 did ours. They didn't teach us about how to use TSO/E commands, how to
 use ISPF, or how to use/manage any of the other myriad MVS batch and
 online programs and facilities that we could run. We simply read the
 manuals to learn.

 In those days, we ordered paper manuals. There was only so much space
in
 your cubicle and the books were not ultra cheap. I suppose, if one
 ordered an IPCS manual, it's conceivable your manager *might* ask,
What
 do you need that for? We also had a library with shelves full of
 manuals we could all share.

 (FYI: I purchased G and S manuals directly from IBM for my own
 collection at home. It was purely my choice which ones to buy. I spent
a
 fortune on them!  :-$ )

 I doubt the sysprogs of today are any more interested in teaching
 application programmers how to use TSO/E than they were 25 years ago.
 Application programmers must still read manuals to learn how to use
the
 system. And, these days, manuals are available for free, via the
 Internet, covering every imaginable aspect of z/OS!

 I'd like to know just how evil, 21st-century, Darth-Vader-like
sysprogs
 use ignorance and information hiding to prevent application
 programmers from knowing anything about IPCS. IPCS is just as easy a
 command to type as ISPF and the doc is as freely available as it is
for
 any other built-in command or facility that runs under z/OS! (That is,
 unless the sysprogs are censoring the Internet!)

 I suggest a more reasonable explanation is that the application
 programmers *themselves* are avoiding IPCS

  In any case, I've never been privileged to learn it or use it.

 It's never too late! ;-)

  A problem is that many applications programmers are to busy, or don't
care enough for such exploration and manual reading.
  At least some of those who do have such an inclination or the knack,
well, they used to become systems programmers :)

 --
 Edward E Jaffe
 Phoenix Software International, Inc
 5200 W Century Blvd, Suite 800
 Los Angeles, CA 90045
 310-338-0400 x318
 [EMAIL PROTECTED]
 http://www.phoenixsoftware.com/

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Workable Mainframe Debuggers