Re: FW: Workable Mainframe Debuggers

[Galambos, Robert]

SORRY to dis-agree with you.

Compuware does HAVE a debugger for C (Xped). And it has been out for awhile as 
well.

 
Robert Galambos CIPP/C  

Compuware Senior Technical Specialist 
IBM Certified Solutions Expert - 
DB2 UDB for OS/390 Database Administration
Certified Information Privacy Professional/Canada 
[EMAIL PROTECTED]
 
  
Tel: +1 905 886 7000 
Toll Free: +1 800 263 7189
Fax: +1 905 886 7023
Quebec: +1 877-281-1888 
  
Compuware  Canada

Service is our best product 
 Les renseignements contenus dans le présent message électronique sont 
confidentiels et concernent exclusivement le(s) destinataire(s) désigné(s). Il 
est strictement interdit de distribuer ou de copier ce message. Si vous avez 
reçu ce message par erreur, veuillez répondre par courriel à l'expéditeur et 
effacer ou détruire toutes les copies du présent message.


The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it.

From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom 
Ross
Sent: Monday, April 14, 2008 4:57 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: FW: Workable Mainframe Debuggers

>Hmmm, I find it interesting that I have two votes for IBMs Debug Tool, 
>which is completely unusable to me. We write C++ programs here. My main 
>app is something like 200 object modules.
>
>When I write a "Hello world" test app, fire it up under IBMs debug 
>tool, it works great. When I try to debug our actual application, 
>either the size or complexity is such that it just hacks up hairballs and dies.
>
>So I have filled my sources full of DEBUGX lines that I turn and off by 
>module, and debug in batch via what turn out to be CEEMSG's.
>
>So are there viable alternatives to IBMs debug tool, or is this the 
>one? If this is the one, I will have to give it another go so that I 
>can explain in detail how it behaves badly.

Sounds like a IBM needs to improve Debug Tool for debugging C++ code!
Have you tried reporting these problems to us (IBM) and getting us to fix them? 
 Debug Tool was not so good in the 1990s, but since we have improved it 
(hookless debugging, most of the features of other
debuggers) we have gotten a tremendous number of users (at least for COBOL, 
PL/I and C, not sure about C++) and have solved many problems.
Debug tool changed dramatically between 2000 and 2004 especially, and many 
customers tell us it is better than the rest now!
By the way, I think IBM has the only debugger for IBM C and C++ on z/OS.

Cheers,
TomR  >> COBOL is the Language of the Future! <<

--
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: Parmlib Paranoia (was Re: Workable Mainframe Debuggers)

[Edward Jaffe]

Mark Zelden wrote:

On Thu, 17 Apr 2008 12:04:00 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:
  


PARMLIB is similar to LNKLST in concept. It is a concatenation of
libraries, specified via PARMLIB statements in the LOADxx member of
IPLPARM, and accessed via the IEFPRMLB service.




Similar, but not the same in respect to this discussion.  LNKLST (and 
any other loadlib) can be set up with EXECUTE access only.  That still

allows one to use it but they can't read the contents or copy it.
  


That sounds like a good enhancement idea, Mark! It could be extremely 
useful to allow a program using IEFPRMLB to access members from PARMLIB 
without requiring READ access to every library in the concatenation. 
Case in point: I believe it would solve this IPCS access issue we have 
been discussing!


--
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: Parmlib Paranoia (was Re: Workable Mainframe Debuggers)

[Mark Zelden]

On Thu, 17 Apr 2008 12:04:00 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:

>Mark Zelden wrote:
>> On Tue, 15 Apr 2008 18:12:56 -0700, Edward Jaffe
>> <[EMAIL PROTECTED]> wrote:
>>
>>
>>> 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'm sure we've done this before.   Auditors are paranoid ("need to know
basis").
>> Some passwords (JES2 NJE for example) may be kept in parmlib.
>>
>
>PARMLIB is similar to LNKLST in concept. It is a concatenation of
>libraries, specified via PARMLIB statements in the LOADxx member of
>IPLPARM, and accessed via the IEFPRMLB service.
>

Similar, but not the same in respect to this discussion.  LNKLST (and 
any other loadlib) can be set up with EXECUTE access only.  That still
allows one to use it but they can't read the contents or copy it.  

>LNKLST has three libraries that are always present on the concatenation.
>The only always-present library for PARMLIB is SYS1.PARMLIB on the IPL
>volume. If this library is not explicitly specified via PARMLIB
>statements, it is added by the system at the end of the concatenation.
>
>JES does not use PARMLIB. It reads its configuration parameters via a
>hard-wired DD statement in its JCL procedure. The specification looks like:
>
>For JES2:
>//HASPPARM DD DISP=SHR,DSN=any.data.set.name(memname)
>
>For JES3:
>//JES3IN   DD DISP=SHR,DSN=any.data.set.name(memname)
>

Good point.  But many shops keep their JES2 parms in one of the same
parmlibs as the system parmlib concatenation".   In the past that was
much more common than today (from what I have seen).  

Besides, I used JES2 parms only as an example.   There could be 
others (although I can't think of any off hand).

>
>Some system programmers like to elevate JES to the level of a BCP
>component by putting its configuration parameters into a library on the
>PARMLIB concatenation. That's fine. But, totally unnecessary. And, if
>some sort of password might be specified therein, arguably 
>

Only inappropriate if parmlib has universal read access.  :-) 
  (are we going in circles?)

I don't think it is "elevating JES" it is just a convenient place that system
parms are kept.  It's also how IBM has distributed it's sample since 
and still does.  Look at SYS1.SHASSAMP(HASIPROC) and the JES2 init
and tuning.It can be changed as you said, but "it has always been
done that way" at many shops.   I personally split it out at shops I've
been at because of size of the members (I also split the parms into
multiple members at the same time).

Anyway... you are preaching to the choir as far as I am concerned and
probably many others on this list.   I am just playing devils advocate a 
little.It's the auditors (including ours) that you would have to convince.
Yes, I checked and our PARMLIBs have UACC(NONE).   
 
Regards,

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: Parmlib Paranoia (was Re: Workable Mainframe Debuggers)

[Wayne Driscoll]

Ed,
It's been a while since I have installed a base z/OS but as I recall, the
default JES2 proc that IBM shipped with CBIPO (like a said, been a while)
and the ADCD choose to "elevate JES to the level of a BCP Component" by
using:
//HASPPARM DD DISP=SHR,DSN=SYS1.PARMLIB(JES2PARM)
I will agree that passwords in parmlib is dangerous, but many feel that if
it's good enough for IBM, it should work for me!

Wayne Driscoll
Product Developer
NOTE:  All opinions are strictly my own.




-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Edward Jaffe
Sent: Thursday, April 17, 2008 2:04 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Parmlib Paranoia (was Re: Workable Mainframe Debuggers)

Mark Zelden wrote:
> On Tue, 15 Apr 2008 18:12:56 -0700, Edward Jaffe
> <[EMAIL PROTECTED]> wrote:
>
>   
>> 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'm sure we've done this before.   Auditors are paranoid ("need to know
basis").
> Some passwords (JES2 NJE for example) may be kept in parmlib.
>   

PARMLIB is similar to LNKLST in concept. It is a concatenation of 
libraries, specified via PARMLIB statements in the LOADxx member of 
IPLPARM, and accessed via the IEFPRMLB service.

LNKLST has three libraries that are always present on the concatenation. 
The only always-present library for PARMLIB is SYS1.PARMLIB on the IPL 
volume. If this library is not explicitly specified via PARMLIB 
statements, it is added by the system at the end of the concatenation.

JES does not use PARMLIB. It reads its configuration parameters via a 
hard-wired DD statement in its JCL procedure. The specification looks like:

For JES2:
//HASPPARM DD DISP=SHR,DSN=any.data.set.name(memname)

For JES3:
//JES3IN   DD DISP=SHR,DSN=any.data.set.name(memname)

A *sequential* (DSORG=PS) data set might even work here. (Don't know. 
Never tried it.)

Some system programmers like to elevate JES to the level of a BCP 
component by putting its configuration parameters into a library on the 
PARMLIB concatenation. That's fine. But, totally unnecessary. And, if 
some sort of password might be specified therein, arguably inappropriate.

-- 
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: Parmlib Paranoia (was Re: Workable Mainframe Debuggers)

[Edward Jaffe]

Mark Zelden wrote:

On Tue, 15 Apr 2008 18:12:56 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:

  

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'm sure we've done this before.   Auditors are paranoid ("need to know basis").
Some passwords (JES2 NJE for example) may be kept in parmlib.
  


PARMLIB is similar to LNKLST in concept. It is a concatenation of 
libraries, specified via PARMLIB statements in the LOADxx member of 
IPLPARM, and accessed via the IEFPRMLB service.


LNKLST has three libraries that are always present on the concatenation. 
The only always-present library for PARMLIB is SYS1.PARMLIB on the IPL 
volume. If this library is not explicitly specified via PARMLIB 
statements, it is added by the system at the end of the concatenation.


JES does not use PARMLIB. It reads its configuration parameters via a 
hard-wired DD statement in its JCL procedure. The specification looks like:


For JES2:
//HASPPARM DD DISP=SHR,DSN=any.data.set.name(memname)

For JES3:
//JES3IN   DD DISP=SHR,DSN=any.data.set.name(memname)

A *sequential* (DSORG=PS) data set might even work here. (Don't know. 
Never tried it.)


Some system programmers like to elevate JES to the level of a BCP 
component by putting its configuration parameters into a library on the 
PARMLIB concatenation. That's fine. But, totally unnecessary. And, if 
some sort of password might be specified therein, arguably inappropriate.


--
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: C++ Workable Mainframe Debuggers <[EMAIL PROTECTED]>

[Anthony Giorgio]

dbx has supported 64-bit code since z/OS V1R6.  It's also a 64-bit 
native application.


Timothy Sipples wrote:


Side note: Another dividing line for the debuggers seems to be whether they
support 64-bit code or not. z/XDC and IBM Debug Tool do, to pick two
examples. So I would advise the original poster to check that aspect also.
It's quite likely the C++ programmers will want 64-bit support -- if not
now, then soon.




--
Anthony Giorgio
On-Demand Infrastructure, Common Event Framework

--
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

[Kelman, Tom]

> On Tuesday, April 15, 2008, Edward Jaffe Wrote:
> 
> 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...
> 
Ed,

I agree and in a previous shop that I worked for the lead system
programmer had the authority to give the needed access to SYS1 datasets.
We had no problem with a UACC(READ) for the PARMLIBS.  Now I'm in a shop
that uses TopSecret instead of RACF and all security granting is done by
the Security group.  I don't even have the authority to grant someone
access to my personal TSO datasets.  I have to send an email to IT
Security and ask them to grant the access.  Now, IMHO, that's draconian.
Of course a lot of this might have come about because of our great
government and regulations like HIPAA and Sarbanes-Oxley.  Some places
are tightening down more than they might need to just to be on the safe
side.  I've always worked at banks, and I know from dealing with them
that you don't want the Federal Reserve or the Comptroller of the
Currency on your back.

Tom Kelman



*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at 
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer 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: SYSRES Data Set Names (was Re: Workable Mainframe Debuggers)

[Rick Fochtman]

-


You always believe that your every word is golden, and go ballistic when people 
only quote the part that they are commenting on.
   



1. I'm probably going to regret responding.
2. I do not think my words are golden; I'm simply trying to clarify, since I 
did not articulate my position well enough to be understood.
3. I was not ballistic; I didn't take any of the comments personally.
4. I don't know why you have it in for me, as I'm only trying to help. Also, I 
do not make cryptic and obscure comments that do not add to the knowledge being 
diseminated. Though, as anybody else, I've been known to be wrong, and, unlike 
some, I usually acknowledge and appologise.
5. It must be nice to be able to read minds and infer what people think, even 
when you're dead wrong.
6. This the last time I am responding to you on any post, because it appears to 
me that you deliberately goad people, rather than contribute positively.
7. I'm still investigating why you keep slipping through my e-mail filters.
8. If you cannot contribute constructively, I would suggest that you do not at 
all. I know I'm not the only one with that opinion.

Now back to real information.
 


-
ENOUGH WITH THE PERSONALITY CONFLICTS!

We're all professionals on this list; let's behave as such. Granted, 
sometimes we get a little "thin skinned" at times and that makes us a 
little "testy". And sometimes our personal traits MIGHT be offensive to 
others. But there's too much expertise represented here to let 
parsonalities get in the way, leading to waste and "hatred and discontent".


Make peace. PLEASE!!!

--
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

[Edward Jaffe]

McKown, John wrote:

But much more difficult, at least for the programmers around here, than
a nicely formatted AbendAID dump. Which they look at in the ISPF dialog,
not on SPOOL.

So I guess my thought is, why would a __normal programmer__ want to use
IPCS? Especially instead of something like AbendAID or Symdump or
DumpMaster or ... ? Of course, I've now labelled everybody who uses IPCS
as abnormal .
  


When I think of a so-called "formatted" dump, I think of something
similar to:

ip l 00FD9E20
00FD9E20. E4C1F3F7 F9F0F440 E2D7F74B F04BF940 |UA37904 SP7.0.9 |
00FD9E30. C8C2C2F7 F7F4F040 40404040 40404040 |HBB7740 |
00FD9E40. 40404040 40404040 2096 F0F3F840 |...o038 |
00FD9E50. 0218 00FEB4C4 00FDE604 00FD9DE8 |...D..WY|
00FD9E60.  00FF55E8 00FF1F96 00FE6B2E |...Y...o..,.|
00FD9E70. 00FE6934 0197BD48 81177680 00FECEA8 |.p..a..y|

How do I search for a string that "wraps" from one formatted line to the
next? In IPCS there are no "lines". How do I position to a particular
address? IIRC, if I want to position to 00FD9E3A in a formatted dump, I
need to figure out which address is printed on the left --the next lower
multiple of 16 or 32 (depending on how many words are formatted per
line) -- and FIND that value in the proper column. How well does that
work when the formatting of "n" lines are suppressed because they
contain the same data as the previous line? IPCS has none of these
limitations. Storage is storage. I can use indirect addressing to follow
complex storage chains. And, if I list a known structure, for which
someone has created formatting models etc., I can get even "nicer" displays.

ip l cvt
CVT - Communications Vector Table
LIST FD9E50. ASID(X'0001') POSITION(X'-28') LENGTH(X'0528') STRUCTURE(Cvt)
ASID(X'0001') ADDRESS(FD9E28.) KEY(00) ABSOLUTE(3F027E28.)
-0028 00FD9E28.   E2D7F74B F04BF940 |SP7.0.9 |
-0020 00FD9E30. C8C2C2F7 F7F4F040 40404040 40404040 |HBB7740 |
-0010 00FD9E40. 40404040 40404040 2096 F0F3F840 |...o038 |
+ 00FD9E50. 0218 00FEB4C4 00FDE604 00FD9DE8 |...D..WY|
+0010 00FD9E60.  00FF55E8 00FF1F96 00FE6B2E |...Y...o..,.|
+0020 00FD9E70. 00FE6934 0197BD48 81177680 00FECEA8 |.p..a..y|
+0030 00FD9E80. 021DB068 00FE5D40 0108106F 00FD9C88 |..) ...?...h|

ip cbf cvt str(cvt)
CVT: 00FD9E50
  -0028  PRODN SP7.0.9   PRODI HBB7740   VERID
  -0006  MDL.. 2096  RELNO 038
  +  TCBP. 0218  0EF00 00FEB4C4  LINK. 00FDE604
  +000C  AUSCB 00FD9DE8  BUF..   XAPG. 00FF55E8
  +0018  0VL00 00FF1F96  PCNVT 00FE6B2E  PRLTV 00FE6934
  +0024  LLCB. 0197BD48  LLTRM 81177680  XTLER 00FECEA8
  +0030  SYSAD 021DB068  BTERM 00FE5D40  DATE. 0108106F
  +003C  MSLT. 00FD9C88  ZDTAB 00F4B000  XITP. 00FF7EE8

--
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: SYSRES Data Set Names (was Re: Workable Mainframe Debuggers)

[Ted MacNEIL]

>You always believe that your every word is golden, and go ballistic when 
>people only quote the part that they are commenting on.

1. I'm probably going to regret responding.
2. I do not think my words are golden; I'm simply trying to clarify, since I 
did not articulate my position well enough to be understood.
3. I was not ballistic; I didn't take any of the comments personally.
4. I don't know why you have it in for me, as I'm only trying to help. Also, I 
do not make cryptic and obscure comments that do not add to the knowledge being 
diseminated. Though, as anybody else, I've been known to be wrong, and, unlike 
some, I usually acknowledge and appologise.
5. It must be nice to be able to read minds and infer what people think, even 
when you're dead wrong.
6. This the last time I am responding to you on any post, because it appears to 
me that you deliberately goad people, rather than contribute positively.
7. I'm still investigating why you keep slipping through my e-mail filters.
8. If you cannot contribute constructively, I would suggest that you do not at 
all. I know I'm not the only one with that opinion.

Now back to real information.
-
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: FW: Workable Mainframe Debuggers

[Howard Brazee]

On 16 Apr 2008 07:16:33 -0700, [EMAIL PROTECTED] (Don Leahy) wrote:

>>  Every once in a while, we have time to waste - pulling up debugger
>>  tools is as good of a way to fill that time as any.
>>
>
>If a debugging tool is seen as a "waste of time" it is usually because
>the installation hasn't put enough effort into tailoring it for local
>use.


Too often on mainframe environments, tool use needs to be mandated
before sufficient people will learn it, and adjust it and the
environment to each other.

This is a big reason why other programmers think of us as dinosaurs.
(But dinosaurs were very, very successful - it is unlikely that humans
(Java) will last nearly as long).

--
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: FW: Workable Mainframe Debuggers

[Don Leahy]

On Wed, Apr 16, 2008 at 9:26 AM, Howard Brazee <[EMAIL PROTECTED]> wrote:
> On Tue, 15 Apr 2008 18:03:09 -0700, Paul Knudsen
>  <[EMAIL PROTECTED]> wrote:
>
>  >>Every once in a while someone pulls up a debugger tool, intending on
>  >>having that skill in our resume.   But when we actually need to debug,
>  >>we go back to the old way - displays in the code.
>  >
>  >Wasting time good for job security.
>
>  Every once in a while, we have time to waste - pulling up debugger
>  tools is as good of a way to fill that time as any.
>

If a debugging tool is seen as a "waste of time" it is usually because
the installation hasn't put enough effort into tailoring it for local
use.

When we installed IBM Debug Tool in our shop, we altered all of our
standard compile procs to support the TEST option and to link in the
CEEUOPT module when needed.  All the programmer has to do is select
the TEST option on a panel and provide the VTAM LU of his debug
terminal  (We are on release 5.1 of DT, a bit back level.I
understand later releases of DT have done away with this requirement).

We never use the IBM supplied ISPF dialog to set up our debug
sessions.  I am not knocking IBM, but their dialog, of necessity, has
to be generic, and like all generic tools requires a fair amount of
effort to use.

We also provided each developer with a private DB2 data base for unit
testing/debugging, and developed some in house tools to help them
maintain them.  This addresses data base contention concerns cause by
people sitting at a breakpoint.

Finally, we renovated our rarely used BTS environment to accommodate
all of these changes.

It is the programmer who puts Display messages in the code that is
"wasting time"



--
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

[Shane]

On Wed, 2008-04-16 at 07:57 -0500, McKown, John wrote:

> So I guess my thought is, why would a __normal programmer__ want to use
> IPCS? Especially instead of something like AbendAID or Symdump or
> DumpMaster or ... ? Of course, I've now labelled everybody who uses IPCS
> as abnormal .

Recently I had to look at CEEDUMPs in anger. As I had to follow storage
pointers (some from registers), it was a serious PITA compared to what I
am used to. Hated it.
Each to their own.

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: FW: Workable Mainframe Debuggers

[Howard Brazee]

On Tue, 15 Apr 2008 18:03:09 -0700, Paul Knudsen
<[EMAIL PROTECTED]> wrote:

>>Every once in a while someone pulls up a debugger tool, intending on
>>having that skill in our resume.   But when we actually need to debug,
>>we go back to the old way - displays in the code.
>
>Wasting time good for job security.

Every once in a while, we have time to waste - pulling up debugger
tools is as good of a way to fill that time as any.

--
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]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Shmuel Metz (Seymour J.)
> Sent: Tuesday, April 15, 2008 8:10 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: 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

But much more difficult, at least for the programmers around here, than
a nicely formatted AbendAID dump. Which they look at in the ISPF dialog,
not on SPOOL.

So I guess my thought is, why would a __normal programmer__ want to use
IPCS? Especially instead of something like AbendAID or Symdump or
DumpMaster or ... ? Of course, I've now labelled everybody who uses IPCS
as abnormal .

--
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 (*** Private ***)

[Elardus Engelbrecht]

Shane wrote:

>The rest of you never saw it - o.k. ???.

Mate, I'll be really honest... (I'm not a car salesperson or a lawyer)

I did saw that post sitting nice and warm on my wide laptop screen at IBM-
MAIN's web pages.


>I'd better go find another line of work  :-(

No, you stay here on IBM-MAIN... :-D


Groete / Greetings

Elardus Engelbrecht

--
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

Parmlib Paranoia (was Re: Workable Mainframe Debuggers)

[Mark Zelden]

On Tue, 15 Apr 2008 18:12:56 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:

>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'm sure we've done this before.   Auditors are paranoid ("need to know basis").
Some passwords (JES2 NJE for example) may be kept in parmlib.   

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 (*** Private ***)

[Shane]

O.K., so the fact this (re-)appeared in my inbox probably indicates it
wasn't all that private.
The rest of you never saw it - o.k. ???.

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 (*** Private ***)

[Shane]

On Wed, 2008-04-16 at 06:58 +0200, Barbara Nitz wrote:

>  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.

Uh-oh - sounds like I'm being dragged into this (again).
Damn.

I'd better go find another line of work  :-(

Shane ...
(BTW, how did you figure out that exit was GRS ???)

--
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

[Edward Jaffe]

Craddock, Chris wrote:

We're so used to having access to the keys to the kingdom that we tend
to forget that everyone else doesn't get them. 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.
  


I have not forgotten. When I worked as an application programmer back in 
DC, we could browse SYS1.PARMLIB. It was no big deal. When I worked as 
an application programmer in Glendale, we could browse SYS1.PARMLIB. It 
was no big deal. When I rented time at a service bureau in the valley, 
we could browse SYS1.PARMLIB. It was no big deal. And, now that I have 
the proverbial keys to the "kingdom" where I work, everyone can browse 
SYS1.PARMLIB. It's no big deal.


IPCS is used for processing SYSMDUMP and "transaction" dumps produced by 
IEATDUMP. These dumps are produced by problem-state, application 
programs. They do not contain sensitive data. And, as far as I know, 
IPCS is still the only tool that can intelligently process them.


I agree with you that there is no reason for application programmers to 
be looking at SVC dumps. But, there have been "sensitive" data sets 
around since "dirt". IPCS is just another data set browsing tool. Heck, 
if any user can browse an SVC dump (which is a simple RECFM=FBS format) 
using ISPF BROWSE, they're liable to see lots of stuff (EBCDIC data) 
they shouldn't be seeing -- whether they have IPCS access or not!



Can it be controlled by controlling access to dump datasets? Sure. But
again, it depends on somebody knowing what to do and how to do it. If
you're a lowly security administrator you're probably just going to
elect UACC(NONE) for everything you don't understand.
  


To reiterate, I agree the system's SVC dump inventory should be 
UACC(NONE) to most people. I never suggested otherwise. Without that, 
you risk users copying the data via FTP onto a USB flash drive and 
walking it out of the building!


--
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: C++ Workable Mainframe Debuggers (and a Public z/OS HTTP Server)

[Timothy Sipples]

Miklos Szigetvari writes:
>We are struggling with the debugger for several years
>The main problems:
>- very very slow
>- unable to handle properly multithread application
>- abends in various places
>etc etc
>By the way we had a common project ( a PMR) a few years ago with the
>Toronto Lab, we sent and received the source code,
>and in the source code received from them, we seen a number of printf's
>, debug macro's etc etc
>We are in z/OS 1.8 and we had WD4Z (Web Sphere)

That doesn't suprise me at all for a few reasons. The first reason is the
"few years ago" part. I think it was only late 2006 (Version 7) when there
were some feature improvements for C++ added that a lot of developers
demanded. The second reason is that IBM cannot anticipate exactly which
debugger you have (if any), so if we're working collaboratively we may have
to fall back on printfs. I know when I was in support I'd often start with
the most basic troubleshooting inspection process, often thinking at the
same time that it would be so darn useful if my customer had tool X or
utility Y installed (and if I had remote access). Sometimes I would
remember to ask, but there's an overwhelming tendency for support-type
people to walk you through the "universal approach" by default, which in
this case is printf. The third reason is that you can still use printfs and
the like, so even programmers armed with debuggers they love still use both
techniques. The fourth reason is there are many production scenarios where
recording log files is essential, so you might be putting that stuff in
your code anyway. Especially in the mainframe world where more people worry
about deploying highly supportable code.

>We got now a new z9, we will try again, but till now , we were unable to
>find any real error with the help of the debugger
>The "hello word " program, and its variants are working with the
>debugger, but a  real complex application with DLL's , multithread not.

OK, please get whatever you find back to IBM. If the problems you describe
are still going on, it sounds like IBM has a lot of gap to close to meet
your needs. Make sure you challenge my colleages and give them a shot to do
better.

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [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

Re: Workable Mainframe Debuggers

[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. 

 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! 

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

Re: Workable Mainframe Debuggers

[Shmuel Metz (Seymour J.)]

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  
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

[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

[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

[Shmuel Metz (Seymour J.)]

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  
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

[Shmuel Metz (Seymour J.)]

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  
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

[Shmuel Metz (Seymour J.)]

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  
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: SYSRES Data Set Names (was Re: Workable Mainframe Debuggers)

[Shmuel Metz (Seymour J.)]

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  
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

[Craddock, Chris]

Ed responds
> > 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...

Dunno. Arguably it comes from those wonderful EDP auditor types (whoa,
there's a term from the way-back machine) who believe that exposing any
system information could lead to various attacks, e.g. learning the
names of the APF datasets, program property table entries, authorized
command names etc. The usual knee-jerk response (and fairly widespread
in my experience anyway) is to lock it up. Similar fears attach to most
of the major subsystem parmlib datasets. 

We're so used to having access to the keys to the kingdom that we tend
to forget that everyone else doesn't get them. 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. 

Can it be controlled by controlling access to dump datasets? Sure. But
again, it depends on somebody knowing what to do and how to do it. If
you're a lowly security administrator you're probably just going to
elect UACC(NONE) for everything you don't understand. 

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

[Wayne Driscoll]

I think that if you pre-allocate DD IPCSPARM it will not attempt to allocate
the system parmlib.  However, there are parmlib members that IPCS uses, so
you would need to get IPCSPR00, BLSCSECT and BLSCUSER, along with any other
members included by BLSCSECT copied into this separate library.  You can get
away without the IPCSPRM00 by starting IPCS with the NOPARM option, but the
BLSx members will still be required.

Wayne Driscoll
Product Developer
NOTE:  All opinions are strictly my own.




-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Bass, Walter W
Sent: Tuesday, April 15, 2008 6:35 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Workable Mainframe Debuggers

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe
> Sent: Saturday, April 12, 2008 11:45 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Workable Mainframe Debuggers
> 
> 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.
> 

Being an "applications" type guy for the past 25 years rather than a
"systems" type, I've been following this thread with a great deal of
interest.  There has been a lot of sentiment that applications
programmers are either reluctant to use IPCS because they are too lazy
to learn something new or too stupid to believe another tool could prove
useful.

In my case I have to plead total ignorance.  I had never heard of IPCS
prior to reading this thread.  How am I supposed to RTFM when I don't
even know the product exists?  As pointed out, it is not on the [EMAIL 
PROTECTED]
menu, which as an application developer is the only menu I have ever
seen on entry to ISPF.

> 
> 
> 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 


Yep, seeing all this talk about IPCS I had to go try it out for myself
and ran into this yesterday.


> 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/iea
> 2c640/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)'
> | READY

Ok, Thanks!  I'll try this too.  Yep, that worked.  And I allocated the
appropriate libs to SYSPROC, ISPSLIB, ISPMLIB, etc...   


> 
> Whoa! OK. Let me try that IPCS command again:
> 
> |ipcs
> | BLS21001I IPCS for z/OS 01.09.00
> | IPCS
> 
> I'm in!!
> 

Now I should be all set too since us "applications" type guys aren't
being blocked from using IPCS.

Here I go ...


 READY

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 
 

 System ABEND 913, reason code 0038

 PSW 075C1000 80EAAD8E, module IGC0001I, CSECT*UNKNOWN, offset 013D8E

 Instruction area 41003B7A 0A0D41F0 38BE56F0

 GPR   0R 00EAB054   1R A4913000   2R 0095619C   3R 00EAA4DA

 GPR   4R 009B5410   5R 009B57A4   6R 009B574C   7R 009B57A4

 GPR   8R 009B576C   9R 009A1CA8  10R 00FA9068  11R 00EADB04

 GPR  12R 80EADBE4  13R 009B56D0  14R 80EAA612  15R 0038

 *UNKNOWN ENDED DUE TO ERROR, SYSTEM ABEND CODE 913

 READY


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

Now I don't know about your shop, but if I go asking for access to a
SYS1 dataset that I currently do not have access to, I had better be
armed to the teeth with justifications for that request because it will
raise all kinds of serious red flags and I will attract lots of
attention from security folks.  "I wanted to play around with IPCS"
would not be considered a valid business justification and at best I
will be on someone's short list after that.

So unless someone knows some other magic or can tell me how to make IPCS
stop trying to read SYS1.PARMLIB.B, this looks like a dead end for me.

Bill Bass
United Health Care
Senior Applications

Re: Workable Mainframe Debuggers

[Edward Jaffe]

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

--
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

[Mark Zelden]

On Tue, 15 Apr 2008 18:35:13 -0500, Bass, Walter W <[EMAIL PROTECTED]> wrote:


>
>Now I should be all set too since us "applications" type guys aren't
>being blocked from using IPCS.
>
>Here I go ...
>
>
> READY
>
>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
>
>
> System ABEND 913, reason code 0038


>
>
>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
>
>Now I don't know about your shop, but if I go asking for access to a
>SYS1 dataset that I currently do not have access to, I had better be
>armed to the teeth with justifications for that request because it will
>raise all kinds of serious red flags and I will attract lots of
>attention from security folks.  "I wanted to play around with IPCS"
>would not be considered a valid business justification and at best I
>will be on someone's short list after that.
>
>So unless someone knows some other magic or can tell me how to make IPCS
>stop trying to read SYS1.PARMLIB.B, this looks like a dead end for me.
>

Unfortunately, that would be a problem in many shops and a valid concern
to not give you access to local parmlibs.

However, if you can convince someone to give you access to the 
IBM supplied parmlib "IBM.PARMLIB" or "SYS1.IBM.PARMLIB", then
you can allocate it to IPCSPARM and it will only look at that library.

ALLOC FI(IPCSPARM) DA('SYS1.IBM.PARMLIB') SHR REUSE

IPCS

Unfortunately you need the IBM parmlib for not onlt the IPCSPR00 member 
(which would be easy to create yourself in your own PDS) but also 
the BLSCECT member and a bunch of other members included from 
statements in BLSCECT.

So, I guess it isn't really as easy as we had indicated unless you have read
access to the parmlib concatenation.

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

[Ted MacNEIL]

>Believe it or not, that one doesn't always work either.  Especially if there 
>is an alternative available that has already been justified and paid for.

But, how about justifying the removal of a product.
Or, can we allocate something besides SYS1.PARMLIB -- that one I've never 
understood.
But, I cannot remember if it's possible.

-
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

[Don Leahy]

On Tue, Apr 15, 2008 at 7:40 PM, Ted MacNEIL <[EMAIL PROTECTED]> wrote:
> >Now I don't know about your shop, but if I go asking for access to a SYS1 
> >dataset that I currently do not have access to, I had better be armed to the 
> >teeth with justifications for that request because it will
>  raise all kinds of serious red flags and I will attract lots of attention 
> from security folks.  "I wanted to play around with IPCS" would not be 
> considered a valid business justification and at best I will be on someone's 
> short list after that.
>
>
>  How about: "I want to learn how to use a free debugging tool, potentially 
> reducing cost and improving productivity"?
>
>  -
Believe it or not, that one doesn't always work either.  Especially if
there is an alternative available that has already been justified and
paid for.

--
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

[Don Leahy]

On Tue, Apr 15, 2008 at 7:35 PM, Bass, Walter W <[EMAIL PROTECTED]> wrote:
> > -Original Message-
>  > From: IBM Mainframe Discussion List
>
> > [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe
>  > Sent: Saturday, April 12, 2008 11:45 AM
>  > To: IBM-MAIN@BAMA.UA.EDU
>
> > Subject: Re: Workable Mainframe Debuggers
>  >
>  > 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.
>  >
>
>  Being an "applications" type guy for the past 25 years rather than a
>  "systems" type, I've been following this thread with a great deal of
>  interest.  There has been a lot of sentiment that applications
>  programmers are either reluctant to use IPCS because they are too lazy
>  to learn something new or too stupid to believe another tool could prove
>  useful.
>
>  In my case I have to plead total ignorance.  I had never heard of IPCS
>  prior to reading this thread.  How am I supposed to RTFM when I don't
>  even know the product exists?  As pointed out, it is not on the [EMAIL 
> PROTECTED]
>  menu, which as an application developer is the only menu I have ever
>  seen on entry to ISPF.
>
>
>  >
>  >
>  > 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
>
>
>  Yep, seeing all this talk about IPCS I had to go try it out for myself
>  and ran into this yesterday.
>
>
>
>  > 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/iea
>  > 2c640/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)'
>  > | READY
>
>  Ok, Thanks!  I'll try this too.  Yep, that worked.  And I allocated the
>  appropriate libs to SYSPROC, ISPSLIB, ISPMLIB, etc...
>
>
>
>  >
>  > Whoa! OK. Let me try that IPCS command again:
>  >
>  > |ipcs
>  > | BLS21001I IPCS for z/OS 01.09.00
>  > | IPCS
>  >
>  > I'm in!!
>  >
>
>  Now I should be all set too since us "applications" type guys aren't
>  being blocked from using IPCS.
>
>  Here I go ...
>
>
>   READY
>
>  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
>
>
>   System ABEND 913, reason code 0038
>
>   PSW 075C1000 80EAAD8E, module IGC0001I, CSECT*UNKNOWN, offset 013D8E
>
>   Instruction area 41003B7A 0A0D41F0 38BE56F0
>
>   GPR   0R 00EAB054   1R A4913000   2R 0095619C   3R 00EAA4DA
>
>   GPR   4R 009B5410   5R 009B57A4   6R 009B574C   7R 009B57A4
>
>   GPR   8R 009B576C   9R 009A1CA8  10R 00FA9068  11R 00EADB04
>
>   GPR  12R 80EADBE4  13R 009B56D0  14R 80EAA612  15R 0038
>
>   *UNKNOWN ENDED DUE TO ERROR, SYSTEM ABEND CODE 913
>
>   READY
>
>
>  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
>
>  Now I don't know about your shop, but if I go asking for access to a
>  SYS1 dataset that I currently do not have access to, I had better be
>  armed to the teeth with justifications for that request because it will
>  raise all kinds of serious red flags and I will attract lots of
>  attention from security folks.  "I wanted to play around with IPCS"
>  would not be considered a valid business justification and at best I
>  will be on someone's short list after that.
>
>  So unless someone knows some other magic or can tell me how to make IPCS
>  stop trying to read SYS1.PAR

Re: Workable Mainframe Debuggers

[Ted MacNEIL]

>Now I don't know about your shop, but if I go asking for access to a SYS1 
>dataset that I currently do not have access to, I had better be armed to the 
>teeth with justifications for that request because it will
raise all kinds of serious red flags and I will attract lots of attention from 
security folks.  "I wanted to play around with IPCS" would not be considered a 
valid business justification and at best I will be on someone's short list 
after that.


How about: "I want to learn how to use a free debugging tool, potentially 
reducing cost and improving productivity"?

-
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

[Bass, Walter W]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe
> Sent: Saturday, April 12, 2008 11:45 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Workable Mainframe Debuggers
> 
> 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.
> 

Being an "applications" type guy for the past 25 years rather than a
"systems" type, I've been following this thread with a great deal of
interest.  There has been a lot of sentiment that applications
programmers are either reluctant to use IPCS because they are too lazy
to learn something new or too stupid to believe another tool could prove
useful.

In my case I have to plead total ignorance.  I had never heard of IPCS
prior to reading this thread.  How am I supposed to RTFM when I don't
even know the product exists?  As pointed out, it is not on the [EMAIL 
PROTECTED]
menu, which as an application developer is the only menu I have ever
seen on entry to ISPF.

> 
> 
> 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 


Yep, seeing all this talk about IPCS I had to go try it out for myself
and ran into this yesterday.


> 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/iea
> 2c640/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)'
> | READY

Ok, Thanks!  I'll try this too.  Yep, that worked.  And I allocated the
appropriate libs to SYSPROC, ISPSLIB, ISPMLIB, etc...   


> 
> Whoa! OK. Let me try that IPCS command again:
> 
> |ipcs
> | BLS21001I IPCS for z/OS 01.09.00
> | IPCS
> 
> I'm in!!
> 

Now I should be all set too since us "applications" type guys aren't
being blocked from using IPCS.

Here I go ...


 READY

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 
 

 System ABEND 913, reason code 0038

 PSW 075C1000 80EAAD8E, module IGC0001I, CSECT*UNKNOWN, offset 013D8E

 Instruction area 41003B7A 0A0D41F0 38BE56F0

 GPR   0R 00EAB054   1R A4913000   2R 0095619C   3R 00EAA4DA

 GPR   4R 009B5410   5R 009B57A4   6R 009B574C   7R 009B57A4

 GPR   8R 009B576C   9R 009A1CA8  10R 00FA9068  11R 00EADB04

 GPR  12R 80EADBE4  13R 009B56D0  14R 80EAA612  15R 0038

 *UNKNOWN ENDED DUE TO ERROR, SYSTEM ABEND CODE 913

 READY


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

Now I don't know about your shop, but if I go asking for access to a
SYS1 dataset that I currently do not have access to, I had better be
armed to the teeth with justifications for that request because it will
raise all kinds of serious red flags and I will attract lots of
attention from security folks.  "I wanted to play around with IPCS"
would not be considered a valid business justification and at best I
will be on someone's short list after that.

So unless someone knows some other magic or can tell me how to make IPCS
stop trying to read SYS1.PARMLIB.B, this looks like a dead end for me.

Bill Bass
United Health Care
Senior Applications Developer
NDB Provider Systems
Greenville, SC


This e-mail, including attachments, may include confidential and/or 
proprietary information, and may be used only by the person or entity to 
which it is addressed. If the reader of this e-mail is not the intended 
recipient or his or her authorized agent, the reader is hereby notified 
that any dissemination, distribution or copying of this e-mail is 
prohibited. If you have received this e-mail in error, please notify the 
sender by replying to this message and delete this e-mail immediately.

--
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: C++ Workable Mainframe Debuggers (and a Public z/OS HTTP Server)

[Miklos Szigetvari]

Hi

David Logan wrote:


I will give it a shot here whenever I'm not in eight hours worth of
meetings, and I will let you know what happens exactly.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Timothy Sipples
Sent: Tuesday, April 15, 2008 12:29 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: C++ Workable Mainframe Debuggers (and a Public z/OS HTTP
Server)

I agree with my IBM colleague. Please get those functional requirements
into IBM. "Unusable," how? [And which version(s)?] We'd like to know! If
you're unsure how to do that, please contact me offline.

 


We are struggling with the debugger for several years
The main problems:
- very very slow
- unable to handle properly multithread application
- abends in various places
etc etc
By the way we had a common project ( a PMR) a few years ago with the 
Toronto Lab, we sent and received the source code,
and in the source code received from them, we seen a number of printf's 
, debug macro's etc etc

We are in z/OS 1.8 and we had WD4Z (Web Sphere)

We got now a new z9, we will try again, but till now , we were unable to 
find any real error with the help of the debugger
The "hello word " program, and its variants are working with the 
debugger, but a  real complex application with DLL's , multithread not.






We eat our own cooking here, it's worth mentioning. We have a number of
middleware products for z/OS (and many z/OS elements) written in C++, so
IBM developers use Debug Tool in-house. IBM itself probably does more C++
development on z/OS than anyone. We need good C++ debugging functionality
at least as much as you do.

Re: C++ support, I'm having difficulty finding any other debuggers that
support C++ on z/OS, much less in both 31-bit and 64-bit modes, much less
both graphically and traditionally, aside from the two IBM has (Debug
Tool/DTU&AF and dbx). Someone please correct me if I'm mistaken -- I hope
I'm wrong -- but I've been unsuccessful in my searches thus far.

I forgot to mention that there is an IBM Debug Tool "test drive" available,
at least for the classic user interface. [I posted details previously on
the test drive for the graphical workbench. But if you happen to have
Rational Developer for System z or WebSphere Developer Debugger for System
z, I believe we have the necessary Debug Tool TCP/IP port accessible on the
test drive system for you to connect.] Start here to sign up:

http://zserveros.dfw.ibm.com

This test drive system is also available for trying many application
development tools, DB2 tools, and IMS tools.  We have Debug Tool Utilities
& Advanced Functions Version 8.1 (the latest release) installed on the test
drive system along with a bunch of other products.  We try to keep this
system up-to-date with all the latest releases.

By the way, zserveros.dfw.ibm.com is an Internet-connected z/OS system
running the IBM HTTP Server for z/OS. Somebody was asking if there were any
z/OS HTTP servers directly connected to the Internet. There are; this is
one. You can verify its status here:

http://toolbar.netcraft.com/site_report?url=http://zserveros.dfw.ibm.com

It says "Last reboot: unknown" in the report. :-) It also says "OS/390,"
and yes, I've already written them to see if they can fix that. Apparently
their scanner cannot distinguish between OS/390 and z/OS.

If you need 3270 emulation (to access the test drive system), you can take
the Host On-Demand test drive ("Try Your Own Host") here:

http://websphere.dfw.ibm.com/whidemo/atdemo_hod_basics_live.html

Please do not depend on the HOD test drive for real production use of
course.

Hope all that helps.

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [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

--
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


 



--
Miklos Szigetvari

Development Team
ISIS Information Systems Gmbh 
tel: (+43) 2236 27551 570
Fax: (+43) 2236 21081 

E-mail: [EMAIL PROTECTED] 

Info: [EMAIL PROTECTED] 
Hotline: +43-2236-27551-111 

Visit our Website: http://www.isis-papyrus.com 
-

Re: C++ Workable Mainframe Debuggers (and a Public z/OS HTTP Server)

[Timothy Sipples]

John Chase asks the following excellent question:
>Looks interesting, but one "essential ingredient" appears to be missing
>(or well-hidden):  How does one "register" to use it?  The "Obtaining
>your UserID and Password" link only says how to proceed _after_ you've
>obtained them.

IBM assigns you a chaperone. :-)

Actually, seriously, that chaperone is an IBM technical specialist (and not
really a chaperone). He or she will be an AD tools specialist, a DB2 tools
specialist, or an IMS tools specialist depending on which category you
wish. You can get a specialist assigned (and your ID) by asking your IBM
representative.  That might your Client Represetative, your Software
Representative... whichever person is most convenient.

If you're just hopelessly lost about who your representative might be, you
can surf here:

http://zserveros.dfw.ibm.com/adtoolsinternet/support.html

then click on the "Contact Us" link and ask that a Software Representative
contact you. The folks in Dallas should be able to figure that out.

Sorry I missed that bit. Great question.

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [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

Re: FW: Workable Mainframe Debuggers

[David Cole]

At 4/14/2008 04:57 PM, Tom Ross wrote:

By the way, I think IBM has the only debugger for IBM C and C++ on z/OS.


Not for much longer.





Cheers,
TomR  >> COBOL is the Language of the Future! <<


Dave Cole  REPLY TO: [EMAIL PROTECTED]
Cole Software  WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

Coming soon: c/XDC for C and C++

--
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: C++ Workable Mainframe Debuggers (and a Public z/OS HTTP Server)

[David Logan]

I will give it a shot here whenever I'm not in eight hours worth of
meetings, and I will let you know what happens exactly.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Timothy Sipples
Sent: Tuesday, April 15, 2008 12:29 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: C++ Workable Mainframe Debuggers (and a Public z/OS HTTP
Server)

I agree with my IBM colleague. Please get those functional requirements
into IBM. "Unusable," how? [And which version(s)?] We'd like to know! If
you're unsure how to do that, please contact me offline.

We eat our own cooking here, it's worth mentioning. We have a number of
middleware products for z/OS (and many z/OS elements) written in C++, so
IBM developers use Debug Tool in-house. IBM itself probably does more C++
development on z/OS than anyone. We need good C++ debugging functionality
at least as much as you do.

Re: C++ support, I'm having difficulty finding any other debuggers that
support C++ on z/OS, much less in both 31-bit and 64-bit modes, much less
both graphically and traditionally, aside from the two IBM has (Debug
Tool/DTU&AF and dbx). Someone please correct me if I'm mistaken -- I hope
I'm wrong -- but I've been unsuccessful in my searches thus far.

I forgot to mention that there is an IBM Debug Tool "test drive" available,
at least for the classic user interface. [I posted details previously on
the test drive for the graphical workbench. But if you happen to have
Rational Developer for System z or WebSphere Developer Debugger for System
z, I believe we have the necessary Debug Tool TCP/IP port accessible on the
test drive system for you to connect.] Start here to sign up:

http://zserveros.dfw.ibm.com

This test drive system is also available for trying many application
development tools, DB2 tools, and IMS tools.  We have Debug Tool Utilities
& Advanced Functions Version 8.1 (the latest release) installed on the test
drive system along with a bunch of other products.  We try to keep this
system up-to-date with all the latest releases.

By the way, zserveros.dfw.ibm.com is an Internet-connected z/OS system
running the IBM HTTP Server for z/OS. Somebody was asking if there were any
z/OS HTTP servers directly connected to the Internet. There are; this is
one. You can verify its status here:

http://toolbar.netcraft.com/site_report?url=http://zserveros.dfw.ibm.com

It says "Last reboot: unknown" in the report. :-) It also says "OS/390,"
and yes, I've already written them to see if they can fix that. Apparently
their scanner cannot distinguish between OS/390 and z/OS.

If you need 3270 emulation (to access the test drive system), you can take
the Host On-Demand test drive ("Try Your Own Host") here:

http://websphere.dfw.ibm.com/whidemo/atdemo_hod_basics_live.html

Please do not depend on the HOD test drive for real production use of
course.

Hope all that helps.

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [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

--
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: C++ Workable Mainframe Debuggers (and a Public z/OS HTTP Server)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Timothy Sipples
> 
> [ snip ]
> 
> I forgot to mention that there is an IBM Debug Tool "test 
> drive" available, at least for the classic user interface. [I 
> posted details previously on the test drive for the graphical 
> workbench. But if you happen to have Rational Developer for 
> System z or WebSphere Developer Debugger for System z, I 
> believe we have the necessary Debug Tool TCP/IP port 
> accessible on the test drive system for you to connect.] 
> Start here to sign up:
> 
> http://zserveros.dfw.ibm.com
> 
> This test drive system is also available for trying many 
> application development tools, DB2 tools, and IMS tools.  We 
> have Debug Tool Utilities & Advanced Functions Version 8.1 
> (the latest release) installed on the test drive system along 
> with a bunch of other products.  We try to keep this system 
> up-to-date with all the latest releases.

Looks interesting, but one "essential ingredient" appears to be missing
(or well-hidden):  How does one "register" to use it?  The "Obtaining
your UserID and Password" link only says how to proceed _after_ you've
obtained them.

-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: C++ Workable Mainframe Debuggers (and a Public z/OS HTTP Server)

[Timothy Sipples]

I agree with my IBM colleague. Please get those functional requirements
into IBM. "Unusable," how? [And which version(s)?] We'd like to know! If
you're unsure how to do that, please contact me offline.

We eat our own cooking here, it's worth mentioning. We have a number of
middleware products for z/OS (and many z/OS elements) written in C++, so
IBM developers use Debug Tool in-house. IBM itself probably does more C++
development on z/OS than anyone. We need good C++ debugging functionality
at least as much as you do.

Re: C++ support, I'm having difficulty finding any other debuggers that
support C++ on z/OS, much less in both 31-bit and 64-bit modes, much less
both graphically and traditionally, aside from the two IBM has (Debug
Tool/DTU&AF and dbx). Someone please correct me if I'm mistaken -- I hope
I'm wrong -- but I've been unsuccessful in my searches thus far.

I forgot to mention that there is an IBM Debug Tool "test drive" available,
at least for the classic user interface. [I posted details previously on
the test drive for the graphical workbench. But if you happen to have
Rational Developer for System z or WebSphere Developer Debugger for System
z, I believe we have the necessary Debug Tool TCP/IP port accessible on the
test drive system for you to connect.] Start here to sign up:

http://zserveros.dfw.ibm.com

This test drive system is also available for trying many application
development tools, DB2 tools, and IMS tools.  We have Debug Tool Utilities
& Advanced Functions Version 8.1 (the latest release) installed on the test
drive system along with a bunch of other products.  We try to keep this
system up-to-date with all the latest releases.

By the way, zserveros.dfw.ibm.com is an Internet-connected z/OS system
running the IBM HTTP Server for z/OS. Somebody was asking if there were any
z/OS HTTP servers directly connected to the Internet. There are; this is
one. You can verify its status here:

http://toolbar.netcraft.com/site_report?url=http://zserveros.dfw.ibm.com

It says "Last reboot: unknown" in the report. :-) It also says "OS/390,"
and yes, I've already written them to see if they can fix that. Apparently
their scanner cannot distinguish between OS/390 and z/OS.

If you need 3270 emulation (to access the test drive system), you can take
the Host On-Demand test drive ("Try Your Own Host") here:

http://websphere.dfw.ibm.com/whidemo/atdemo_hod_basics_live.html

Please do not depend on the HOD test drive for real production use of
course.

Hope all that helps.

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [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

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

[Ted MacNEIL]

>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: SYSRES Data Set Names (was Re: Workable Mainframe Debuggers)

[Mark Zelden]

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)

[Ted MacNEIL]

>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)

[Ted MacNEIL]

>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)

[Mark Zelden]

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=ind0804&L=ibm-main&D=1&O=D&T=0&P=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)

[Mark Zelden]

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=ind0804&L=ibm-main&D=1&O=D&T=0&P=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)

[Ted MacNEIL]

>>>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: FW: Workable Mainframe Debuggers

[Tom Ross]

>Hmmm, I find it interesting that I have two votes for IBMs Debug Tool, which
>is completely unusable to me. We write C++ programs here. My main app is
>something like 200 object modules.
>
>When I write a "Hello world" test app, fire it up under IBMs debug tool, it
>works great. When I try to debug our actual application, either the size or
>complexity is such that it just hacks up hairballs and dies.
>
>So I have filled my sources full of DEBUGX lines that I turn and off by
>module, and debug in batch via what turn out to be CEEMSG's.
>
>So are there viable alternatives to IBMs debug tool, or is this the one? If
>this is the one, I will have to give it another go so that I can explain in
>detail how it behaves badly.

Sounds like a IBM needs to improve Debug Tool for debugging C++ code!
Have you tried reporting these problems to us (IBM) and getting us to
fix them?  Debug Tool was not so good in the 1990s, but since we have
improved it (hookless debugging, most of the features of other
debuggers) we have gotten a tremendous number of users (at least for
COBOL, PL/I and C, not sure about C++) and have solved many problems.
Debug tool changed dramatically between 2000 and 2004 especially,
and many customers tell us it is better than the rest now!
By the way, I think IBM has the only debugger for IBM C and C++ on z/OS.

Cheers,
TomR  >> COBOL is the Language of the Future! <<

--
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: C++ Workable Mainframe Debuggers

[Webster, Chris]

I have been using z/XDC to debug C++ for years (before it was even
called z/XDC).  Of course, you have to be able to read assembler to do
so without any source code support.  The assembler listings from the
compiler are pretty much the same as any assembler listing and the
compiler code generation becomes quite familiar after awhile.

If you developers don't know assembler very well, this may not work for
them.

...chris.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of David Logan
Sent: Monday, April 14, 2008 8:36 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: C++ Workable Mainframe Debuggers

Does "C Source code support" also mean C++?

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf
Of David Cole
Sent: Sunday, April 13, 2008 5:10 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: C++ Workable Mainframe Debuggers

>Cole Software's z/XDC - no

We are on the verge of publishing C Source code support ("c/XDC") to 
beta testers.

More soon.
Dave Cole


At 4/13/2008 05:53 AM, you wrote:
>If you're debugging C/C++ on z/OS:
>
>1. There's dbx for UNIX System Services (only):
>
>http://www.ibm.com/servers/eserver/zseries/zos/unix/bpxa1dbx.html
>
>No charge.
>
>2. IBM Debug Tool for z/OS is available. IBM has introduced a new
version
>annually for years now, so you want to stay current and take a fresh
look
>if you remember an old version. Version 7, in particular, introduced
some
>substantial C++ related improvements. Version 8 is current. I see a lot
of
>old Debug Tool installed out there, unfortunately.
>
>You can license Debug Tool as MLC or, in the form of the Debug Tool
>Utilities & Advanced Functions superset product, as OTC with
subscription.
>As you prefer.
>
>Unfortunately for z/OS 1.5 you'll be limited to Debug Tool (or DTU&AF)
>Version 7, so please try to get your z/OS release updated as soon as
you
>can, at least for the development LPAR(s) where you're most likely to
be
>debugging. You may be able to work with IBM to order DT or DTU&AF
Version 8
>and arrange temporary use of Version 7; can't hurt to ask. Actually, as
I
>write this Debug Tool V7 MLC is still orderable so no harm there, but
for
>reasons of subscription you'll want to order DTU&AF V8 if you go the
OTC
>route.
>
>For graphical debugging use Rational Developer for System z (or
WebSphere
>Developer Debugger for System z) in conjunction with Debug Tool (or
>DTU&AF). I think those tools also provide graphical debugging with dbx
now.
>Very slick.
>
>A certain popular IBM-MAIN training firm has a course on C/C++
debugging.
>Details here:
>
>http://www.trainersfriend.com/C_courses/N735descr.htm
>
>3. There are a number of commercial debugger products for z/OS, most
>already mentioned. However, many (all?) of them don't support C++.
Here's
>the latest information I have, and someone please correct me if my
>information is out of date:
>
>Cole Software's z/XDC - no
>CA-InterTest - no
>Compuware's Xpediter - C yes, C++ ?
>Gary Bergman Associates' Advanced Debugging System (ADS) for CICS - C
yes,
>C++ ?
>Macro4's Tracemaster - no
>MacKinney Systems' Track and Xray - no
>ASG's (formerly Viasoft's) SmartTest - no
>Serena's StarTool ATD - product withdrawn?
>
>- - - - -
>Timothy Sipples
>IBM Consulting Enterprise Software Architect
>Specializing in Software Architectures Related to System z
>Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
>E-Mail: [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

--
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

[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: FW: Workable Mainframe Debuggers

[Howard Brazee]

On 14 Apr 2008 06:29:28 -0700, [EMAIL PROTECTED] (McKown,
John) wrote:

>> Every once in a while someone pulls up a debugger tool, intending on
>> having that skill in our resume.   But when we actually need to debug,
>> we go back to the old way - displays in the code.
>
>Hum, I know for a fact that our people use Xpeditor, especially in CICS.
>How? Because they complain any time something doesn't work the way they
>think that it should.

We don't have Xpeditor nor CICS.   That might be significant.

--
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)

[Eric Bielefeld]

I also like making SYS1. qualifiers for all of the IBM target datasets.  When I 
was still at P&H 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: C++ Workable Mainframe Debuggers

[David Logan]

Thanks for the (C++) subject update, Bill. It's one of those cases where I
work in it every day, so I forget the rest of the world doesn't know what I
do :)

Next, based on various other responses, it's good to know that IBMs debug
tool is unusable for others when it comes to C++. At least it's not just me,
although I am rather surprised that IBM is unable to get a functional
debugger for the language.

And, last but not least, a direct response to your email below: I would
lobby for a "functional C++ debugger"...forget the "features", unless that's
considered a feature.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Bill Klein
Sent: Monday, April 14, 2008 8:31 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: C++ Workable Mainframe Debuggers

Just a "plug" for SHARE.  If you work for a SHARE member organization, the
LNGC project does accept requirements for the various "debugging" tools. If
there are specific features that you think should be added to IBM debuggers,
please consider opening up SHARE requirements for them.

Obviously, requirements can also be submitted concerning debugging COBOL,
PL/I, or C as well.  My guess is that most HLASM debugging requirements
would go to the ASM project, but if submitted to LNGC, we would make certain
that they, too, received user and IBM attention.

"Miklos Szigetvari" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Hi
> 
> Unforunatly after several years of tests and  a number of PMR's etc. 
> etc  we think the IBM C++ debugger is unusable for a
> complex applications
>We still use a number of "printf"s to debug C++
> 
> Bill Klein wrote:
> 
> >David,
> >  This note makes it appear that what you are looking for is a C++
> >application debugger.  I haven't read all of the notes in the thread, but
> >making this clear in the subject may help getting more responsive
replies.
> >Therefore, I have added "C++" to the subject.
> >
> >"David Logan" <[EMAIL PROTECTED]> wrote in message
> >news:<[EMAIL PROTECTED]>...
> >  
> >
> >>Hmmm, I find it interesting that I have two votes for IBMs Debug Tool,
> >>
> >>
> >which
> >  
> >
> >>is completely unusable to me. We write C++ programs here. My main app is
> >>something like 200 object modules.
> >>
> >>When I write a "Hello world" test app, fire it up under IBMs debug tool,
> >>
> >>
> >it
> >  
> >
> >>works great. When I try to debug our actual application, either the size
> >>
> >>
> >or
> >  
> >
> >>complexity is such that it just hacks up hairballs and dies.
> >>
> >>So I have filled my sources full of DEBUGX lines that I turn and off by
> >>module, and debug in batch via what turn out to be CEEMSG's.
> >>
> >>So are there viable alternatives to IBMs debug tool, or is this the one?
> >>
> >>
> >If
> >  
> >
> >>this is the one, I will have to give it another go so that I can explain
> >>
> >>
> >in
> >  
> >
> >>detail how it behaves badly.
> >>
> >>David Logan
> >>Manager of Product Development, Pitney Bowes Software, Inc.
> >>http://centrus.com
> >>
> >>-Original Message-
> >>From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> >>
> >>
> >Behalf
> >  
> >
> >>Of Don Leahy
> >>Sent: Friday, April 11, 2008 11:24 AM
> >>To: IBM-MAIN@BAMA.UA.EDU
> >>Subject: Re: FW: Workable Mainframe Debuggers
> >>
> >>On Fri, Apr 11, 2008 at 12:35 PM, David Logan <[EMAIL PROTECTED]>
> >>
> >>
> >wrote:
> >  
> >
> >>>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?
> >>>
> >>>  
> >>>
> >
> >--
> >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

--
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: FW: Workable Mainframe Debuggers

[Jan MOEYERSONS]

On Fri, 11 Apr 2008 10:35:07 -0600, David Logan <[EMAIL PROTECTED]> wrote:

>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?
>

Xpediter does not too bad a job. They do have a module to debug C code.

Is Simon and Oliver still around. I remember having evaluated this 15 odd
years ago. Don't remember why we didn't retain it.

There is also Intertest. Not bad at all. 

I am sure there must be some others as well. Have you tried Google?

Cheers,

Jantje.

--
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

C++ Workable Mainframe Debuggers

[Bill Klein]

Just a "plug" for SHARE.  If you work for a SHARE member organization, the
LNGC project does accept requirements for the various "debugging" tools. If
there are specific features that you think should be added to IBM debuggers,
please consider opening up SHARE requirements for them.

Obviously, requirements can also be submitted concerning debugging COBOL,
PL/I, or C as well.  My guess is that most HLASM debugging requirements
would go to the ASM project, but if submitted to LNGC, we would make certain
that they, too, received user and IBM attention.

"Miklos Szigetvari" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Hi
> 
> Unforunatly after several years of tests and  a number of PMR's etc. 
> etc  we think the IBM C++ debugger is unusable for a
> complex applications
>We still use a number of "printf"s to debug C++
> 
> Bill Klein wrote:
> 
> >David,
> >  This note makes it appear that what you are looking for is a C++
> >application debugger.  I haven't read all of the notes in the thread, but
> >making this clear in the subject may help getting more responsive
replies.
> >Therefore, I have added "C++" to the subject.
> >
> >"David Logan" <[EMAIL PROTECTED]> wrote in message
> >news:<[EMAIL PROTECTED]>...
> >  
> >
> >>Hmmm, I find it interesting that I have two votes for IBMs Debug Tool,
> >>
> >>
> >which
> >  
> >
> >>is completely unusable to me. We write C++ programs here. My main app is
> >>something like 200 object modules.
> >>
> >>When I write a "Hello world" test app, fire it up under IBMs debug tool,
> >>
> >>
> >it
> >  
> >
> >>works great. When I try to debug our actual application, either the size
> >>
> >>
> >or
> >  
> >
> >>complexity is such that it just hacks up hairballs and dies.
> >>
> >>So I have filled my sources full of DEBUGX lines that I turn and off by
> >>module, and debug in batch via what turn out to be CEEMSG's.
> >>
> >>So are there viable alternatives to IBMs debug tool, or is this the one?
> >>
> >>
> >If
> >  
> >
> >>this is the one, I will have to give it another go so that I can explain
> >>
> >>
> >in
> >  
> >
> >>detail how it behaves badly.
> >>
> >>David Logan
> >>Manager of Product Development, Pitney Bowes Software, Inc.
> >>http://centrus.com
> >>
> >>-Original Message-
> >>From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> >>
> >>
> >Behalf
> >  
> >
> >>Of Don Leahy
> >>Sent: Friday, April 11, 2008 11:24 AM
> >>To: IBM-MAIN@BAMA.UA.EDU
> >>Subject: Re: FW: Workable Mainframe Debuggers
> >>
> >>On Fri, Apr 11, 2008 at 12:35 PM, David Logan <[EMAIL PROTECTED]>
> >>
> >>
> >wrote:
> >  
> >
> >>>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?
> >>>
> >>>  
> >>>
> >
> >--
> >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: SYSRES Data Set Names (was Re: Workable Mainframe Debuggers)

[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: Workable Mainframe Debuggers

[Mark Zelden]

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: C++ Workable Mainframe Debuggers

[David Logan]

Does "C Source code support" also mean C++?

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of David Cole
Sent: Sunday, April 13, 2008 5:10 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: C++ Workable Mainframe Debuggers

>Cole Software's z/XDC - no

We are on the verge of publishing C Source code support ("c/XDC") to 
beta testers.

More soon.
Dave Cole


At 4/13/2008 05:53 AM, you wrote:
>If you're debugging C/C++ on z/OS:
>
>1. There's dbx for UNIX System Services (only):
>
>http://www.ibm.com/servers/eserver/zseries/zos/unix/bpxa1dbx.html
>
>No charge.
>
>2. IBM Debug Tool for z/OS is available. IBM has introduced a new version
>annually for years now, so you want to stay current and take a fresh look
>if you remember an old version. Version 7, in particular, introduced some
>substantial C++ related improvements. Version 8 is current. I see a lot of
>old Debug Tool installed out there, unfortunately.
>
>You can license Debug Tool as MLC or, in the form of the Debug Tool
>Utilities & Advanced Functions superset product, as OTC with subscription.
>As you prefer.
>
>Unfortunately for z/OS 1.5 you'll be limited to Debug Tool (or DTU&AF)
>Version 7, so please try to get your z/OS release updated as soon as you
>can, at least for the development LPAR(s) where you're most likely to be
>debugging. You may be able to work with IBM to order DT or DTU&AF Version 8
>and arrange temporary use of Version 7; can't hurt to ask. Actually, as I
>write this Debug Tool V7 MLC is still orderable so no harm there, but for
>reasons of subscription you'll want to order DTU&AF V8 if you go the OTC
>route.
>
>For graphical debugging use Rational Developer for System z (or WebSphere
>Developer Debugger for System z) in conjunction with Debug Tool (or
>DTU&AF). I think those tools also provide graphical debugging with dbx now.
>Very slick.
>
>A certain popular IBM-MAIN training firm has a course on C/C++ debugging.
>Details here:
>
>http://www.trainersfriend.com/C_courses/N735descr.htm
>
>3. There are a number of commercial debugger products for z/OS, most
>already mentioned. However, many (all?) of them don't support C++. Here's
>the latest information I have, and someone please correct me if my
>information is out of date:
>
>Cole Software's z/XDC - no
>CA-InterTest - no
>Compuware's Xpediter - C yes, C++ ?
>Gary Bergman Associates' Advanced Debugging System (ADS) for CICS - C yes,
>C++ ?
>Macro4's Tracemaster - no
>MacKinney Systems' Track and Xray - no
>ASG's (formerly Viasoft's) SmartTest - no
>Serena's StarTool ATD - product withdrawn?
>
>- - - - -
>Timothy Sipples
>IBM Consulting Enterprise Software Architect
>Specializing in Software Architectures Related to System z
>Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
>E-Mail: [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

--
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)

[Mark Zelden]

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: FW: Workable Mainframe Debuggers

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Howard Brazee
> Sent: Monday, April 14, 2008 8:26 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: FW: Workable Mainframe Debuggers
> 
> 
> Every once in a while someone pulls up a debugger tool, intending on
> having that skill in our resume.   But when we actually need to debug,
> we go back to the old way - displays in the code.

Hum, I know for a fact that our people use Xpeditor, especially in CICS.
How? Because they complain any time something doesn't work the way they
think that it should.

--
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: FW: Workable Mainframe Debuggers

[Howard Brazee]

Every once in a while someone pulls up a debugger tool, intending on
having that skill in our resume.   But when we actually need to debug,
we go back to the old way - displays in the code.

--
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: C++ Workable Mainframe Debuggers

[Miklos Szigetvari]

Hi

   Unforunatly after several years of tests and  a number of PMR's etc. 
etc  we think the IBM C++ debugger is unusable for a

complex applications
  We still use a number of "printf"s to debug C++

Bill Klein wrote:


David,
 This note makes it appear that what you are looking for is a C++
application debugger.  I haven't read all of the notes in the thread, but
making this clear in the subject may help getting more responsive replies.
Therefore, I have added "C++" to the subject.

"David Logan" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
 


Hmmm, I find it interesting that I have two votes for IBMs Debug Tool,
   


which
 


is completely unusable to me. We write C++ programs here. My main app is
something like 200 object modules.

When I write a "Hello world" test app, fire it up under IBMs debug tool,
   


it
 


works great. When I try to debug our actual application, either the size
   


or
 


complexity is such that it just hacks up hairballs and dies.

So I have filled my sources full of DEBUGX lines that I turn and off by
module, and debug in batch via what turn out to be CEEMSG's.

So are there viable alternatives to IBMs debug tool, or is this the one?
   


If
 


this is the one, I will have to give it another go so that I can explain
   


in
 


detail how it behaves badly.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
   


Behalf
 


Of Don Leahy
Sent: Friday, April 11, 2008 11:24 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: FW: Workable Mainframe Debuggers

On Fri, Apr 11, 2008 at 12:35 PM, David Logan <[EMAIL PROTECTED]>
   


wrote:
 


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?

 



--
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


 



--
Miklos Szigetvari

Development Team
ISIS Information Systems Gmbh 
tel: (+43) 2236 27551 570
Fax: (+43) 2236 21081 

E-mail: [EMAIL PROTECTED] 

Info: [EMAIL PROTECTED] 
Hotline: +43-2236-27551-111 

Visit our Website: http://www.isis-papyrus.com 
---

This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS accepts
no responsibility for malicious or inappropriate content.
--- 


--
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: C++ Workable Mainframe Debuggers

[Timothy Sipples]

Dave Cole writes:
>We are on the verge of publishing C Source code support ("c/XDC") to
>beta testers.

That's excellent. Thanks, Dave, for getting me more up-to-date.

Side note: Another dividing line for the debuggers seems to be whether they
support 64-bit code or not. z/XDC and IBM Debug Tool do, to pick two
examples. So I would advise the original poster to check that aspect also.
It's quite likely the C++ programmers will want 64-bit support -- if not
now, then soon.

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [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

Re: FW: Workable Mainframe Debuggers

[Elardus Engelbrecht]

David Logan wrote:

>Apologies of a sort about this email. My outlook ...

Accepted of course, outlook should be renamed 
'Look Out! Buggy Software' ... :)

>I use Windows Vista with Office 2007 ... I *strongly* recommend *against* it
if anyone is thinking about it ...

Cool! That is one of the best recommendations I saw on IBM-MAIN! :)
I'm living on xp with office 2003. Yep, 5 year old software, I know. 

Groete / Greetings

Elardus Engelbrecht

--
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

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Craddock, Chris
> Sent: Sunday, April 13, 2008 12:07 PM
> 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.
> 

   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 :)

   Seriously, it's far easier to go with the flow on vendor naming,
especially for distribution datasets.
   I do like to copy vendor "target" datasets to local named copies.
I've been burnt a couple times by inadvertently putting maintenance on
an operational dataset. By using my own local DS, this shooting in the
foot requires better aim :}

> 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

[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

[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

[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

[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

[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

[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

[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

[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! :-)


-

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. 
 


---

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

Re: Workable Mainframe Debuggers

[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 ac

Re: Workable Mainframe Debuggers

[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: C++ Workable Mainframe Debuggers

[David Cole]

Cole Software's z/XDC - no


We are on the verge of publishing C Source code support ("c/XDC") to 
beta testers.


More soon.
Dave Cole


At 4/13/2008 05:53 AM, you wrote:

If you're debugging C/C++ on z/OS:

1. There's dbx for UNIX System Services (only):

http://www.ibm.com/servers/eserver/zseries/zos/unix/bpxa1dbx.html

No charge.

2. IBM Debug Tool for z/OS is available. IBM has introduced a new version
annually for years now, so you want to stay current and take a fresh look
if you remember an old version. Version 7, in particular, introduced some
substantial C++ related improvements. Version 8 is current. I see a lot of
old Debug Tool installed out there, unfortunately.

You can license Debug Tool as MLC or, in the form of the Debug Tool
Utilities & Advanced Functions superset product, as OTC with subscription.
As you prefer.

Unfortunately for z/OS 1.5 you'll be limited to Debug Tool (or DTU&AF)
Version 7, so please try to get your z/OS release updated as soon as you
can, at least for the development LPAR(s) where you're most likely to be
debugging. You may be able to work with IBM to order DT or DTU&AF Version 8
and arrange temporary use of Version 7; can't hurt to ask. Actually, as I
write this Debug Tool V7 MLC is still orderable so no harm there, but for
reasons of subscription you'll want to order DTU&AF V8 if you go the OTC
route.

For graphical debugging use Rational Developer for System z (or WebSphere
Developer Debugger for System z) in conjunction with Debug Tool (or
DTU&AF). I think those tools also provide graphical debugging with dbx now.
Very slick.

A certain popular IBM-MAIN training firm has a course on C/C++ debugging.
Details here:

http://www.trainersfriend.com/C_courses/N735descr.htm

3. There are a number of commercial debugger products for z/OS, most
already mentioned. However, many (all?) of them don't support C++. Here's
the latest information I have, and someone please correct me if my
information is out of date:

Cole Software's z/XDC - no
CA-InterTest - no
Compuware's Xpediter - C yes, C++ ?
Gary Bergman Associates' Advanced Debugging System (ADS) for CICS - C yes,
C++ ?
Macro4's Tracemaster - no
MacKinney Systems' Track and Xray - no
ASG's (formerly Viasoft's) SmartTest - no
Serena's StarTool ATD - product withdrawn?

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [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

Re: Workable Mainframe Debuggers

[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: C++ Workable Mainframe Debuggers

[Timothy Sipples]

If you're debugging C/C++ on z/OS:

1. There's dbx for UNIX System Services (only):

http://www.ibm.com/servers/eserver/zseries/zos/unix/bpxa1dbx.html

No charge.

2. IBM Debug Tool for z/OS is available. IBM has introduced a new version
annually for years now, so you want to stay current and take a fresh look
if you remember an old version. Version 7, in particular, introduced some
substantial C++ related improvements. Version 8 is current. I see a lot of
old Debug Tool installed out there, unfortunately.

You can license Debug Tool as MLC or, in the form of the Debug Tool
Utilities & Advanced Functions superset product, as OTC with subscription.
As you prefer.

Unfortunately for z/OS 1.5 you'll be limited to Debug Tool (or DTU&AF)
Version 7, so please try to get your z/OS release updated as soon as you
can, at least for the development LPAR(s) where you're most likely to be
debugging. You may be able to work with IBM to order DT or DTU&AF Version 8
and arrange temporary use of Version 7; can't hurt to ask. Actually, as I
write this Debug Tool V7 MLC is still orderable so no harm there, but for
reasons of subscription you'll want to order DTU&AF V8 if you go the OTC
route.

For graphical debugging use Rational Developer for System z (or WebSphere
Developer Debugger for System z) in conjunction with Debug Tool (or
DTU&AF). I think those tools also provide graphical debugging with dbx now.
Very slick.

A certain popular IBM-MAIN training firm has a course on C/C++ debugging.
Details here:

http://www.trainersfriend.com/C_courses/N735descr.htm

3. There are a number of commercial debugger products for z/OS, most
already mentioned. However, many (all?) of them don't support C++. Here's
the latest information I have, and someone please correct me if my
information is out of date:

Cole Software's z/XDC - no
CA-InterTest - no
Compuware's Xpediter - C yes, C++ ?
Gary Bergman Associates' Advanced Debugging System (ADS) for CICS - C yes,
C++ ?
Macro4's Tracemaster - no
MacKinney Systems' Track and Xray - no
ASG's (formerly Viasoft's) SmartTest - no
Serena's StarTool ATD - product withdrawn?

- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [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

Re: Workable Mainframe Debuggers

[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

[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 reveale

Re: Workable Mainframe Debuggers

[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

[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

[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

[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. 



>
>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)'



>
>I'm in!!
>



>
>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

[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

[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

C++ Workable Mainframe Debuggers

[Bill Klein]

David,
  This note makes it appear that what you are looking for is a C++
application debugger.  I haven't read all of the notes in the thread, but
making this clear in the subject may help getting more responsive replies.
Therefore, I have added "C++" to the subject.

"David Logan" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Hmmm, I find it interesting that I have two votes for IBMs Debug Tool,
which
> is completely unusable to me. We write C++ programs here. My main app is
> something like 200 object modules.
> 
> When I write a "Hello world" test app, fire it up under IBMs debug tool,
it
> works great. When I try to debug our actual application, either the size
or
> complexity is such that it just hacks up hairballs and dies.
> 
> So I have filled my sources full of DEBUGX lines that I turn and off by
> module, and debug in batch via what turn out to be CEEMSG's.
> 
> So are there viable alternatives to IBMs debug tool, or is this the one?
If
> this is the one, I will have to give it another go so that I can explain
in
> detail how it behaves badly.
> 
> David Logan
> Manager of Product Development, Pitney Bowes Software, Inc.
> http://centrus.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf
> Of Don Leahy
> Sent: Friday, April 11, 2008 11:24 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: FW: Workable Mainframe Debuggers
> 
> On Fri, Apr 11, 2008 at 12:35 PM, David Logan <[EMAIL PROTECTED]>
wrote:
> > 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?
> >

--
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

[Wayne Driscoll]

Or in your case Ed, a product developer who plays a sysprog on TV...

Wayne Driscoll
Product Developer
NOTE:  All opinions are strictly my own.




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

Gibney, Dave wrote:
>   A problem is that many applications programmers are to busy, or don't
> care enough for such exploration and manual reading.
>   

Agreed. Just don't blame the sysprogs ...

>   At least some of those who do have such an inclination or "the knack",
> well, they used to become systems programmers :)
>   

Or software developers. ;-)

-- 
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

[Edward Jaffe]

Gibney, Dave wrote:

  A problem is that many applications programmers are to busy, or don't
care enough for such exploration and manual reading.
  


Agreed. Just don't blame the sysprogs ...


  At least some of those who do have such an inclination or "the knack",
well, they used to become systems programmers :)
  


Or software developers. ;-)

--
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

[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

[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

[Edward Jaffe]

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: FW: Workable Mainframe Debuggers

[David Logan]

Apologies of a sort about this email. My outlook ...

I use Windows Vista with Office 2007 ... I *strongly* recommend *against* it
if anyone is thinking about it ...

Anyway, my Outlook likes to split groups of messages up, and I missed the
large discussion before I sent this. So let me now go read the rest of the
responses.

David Logan
Manager of Product Development, Pitney Bowes Software, Inc.

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

Hmmm, I find it interesting that I have two votes for IBMs Debug Tool, which
is completely unusable to me. We write C++ programs here. My main app is
something like 200 object modules.

When I write a "Hello world" test app, fire it up under IBMs debug tool, it
works great. When I try to debug our actual application, either the size or
complexity is such that it just hacks up hairballs and dies.

So I have filled my sources full of DEBUGX lines that I turn and off by
module, and debug in batch via what turn out to be CEEMSG's.

So are there viable alternatives to IBMs debug tool, or is this the one? If
this is the one, I will have to give it another go so that I can explain in
detail how it behaves badly.

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

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

On Fri, Apr 11, 2008 at 12:35 PM, David Logan <[EMAIL PROTECTED]> wrote:
> 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?
>

We use IBM's Debug Tool for all of our COBOL debugging.

Some of its competitors (Xpeditor for example) are more slick and have
more features, but Debug Tool was priced right and has enough features
to keep the programmers happy.

We were formerly a MicroFocus Cobol shop, but we had allowed that tool
kit to degrade over the years until it became less and less useful.
At the end, we found it was cheaper to move to Debug Tool than to
upgrade our MicroFocus.

--
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

--
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: FW: Workable Mainframe Debuggers

[David Logan]

Hmmm, I find it interesting that I have two votes for IBMs Debug Tool, which
is completely unusable to me. We write C++ programs here. My main app is
something like 200 object modules.

When I write a "Hello world" test app, fire it up under IBMs debug tool, it
works great. When I try to debug our actual application, either the size or
complexity is such that it just hacks up hairballs and dies.

So I have filled my sources full of DEBUGX lines that I turn and off by
module, and debug in batch via what turn out to be CEEMSG's.

So are there viable alternatives to IBMs debug tool, or is this the one? If
this is the one, I will have to give it another go so that I can explain in
detail how it behaves badly.

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

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

On Fri, Apr 11, 2008 at 12:35 PM, David Logan <[EMAIL PROTECTED]> wrote:
> 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?
>

We use IBM's Debug Tool for all of our COBOL debugging.

Some of its competitors (Xpeditor for example) are more slick and have
more features, but Debug Tool was priced right and has enough features
to keep the programmers happy.

We were formerly a MicroFocus Cobol shop, but we had allowed that tool
kit to degrade over the years until it became less and less useful.
At the end, we found it was cheaper to move to Debug Tool than to
upgrade our MicroFocus.

--
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

[John McKown]

On Sat, 12 Apr 2008, Shane wrote:

> On Fri, 2008-04-11 at 15:46 -0400, Farley, Peter x23353 wrote:
> 
> > I've rarely been in a shop that had IPCS and also permitted application
> > programmers to use it.
> 
> Peter has mentioned this before. Man, what I've give to have devs that
> were in the least bit interested ...
> FWIW I've never seen a shop restrict IPCS.
> 
> Shane ...

I agree. Even the ones who might be that technically inclined just don't 
have the time. They are too busy working on other things. If an abend 
occurs, they need to fix it ASAP. AbendAID is far better for that than 
IPCS. Of course, for applications, I usually just look at the CEEDUMP and 
can tell where the problem is (assuming AbendAID doesn't have what is 
needed).

-- 
Q: What do theoretical physicists drink beer from?
A: An EIN stein.

Maranatha!
John McKown

--
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

[Shane]

On Fri, 2008-04-11 at 15:46 -0400, Farley, Peter x23353 wrote:

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

Peter has mentioned this before. Man, what I've give to have devs that
were in the least bit interested ...
FWIW I've never seen a shop restrict IPCS.

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