Split output
Howard Brazee
but I sure wish I could point the output of a program to multiple
locations at once. Maybe have my DISPLAY go to SYSOUT and to a file
simultaneously.
Lucas, Todd
write an external File Handler routine to do it, but it can be done.
TL
Howard Brazee <howard...@cusys.edu> wrote in message
news:39073291...@cusys.edu...
William M. Klein
via JCL. (Certainly you CAN send the output to a file and spool that to a
printer via IEBGENER in a subsequent step.)
--
Bill Klein
wmklein <at> ix dot netcom dot com
Howard Brazee
"Lucas, Todd" wrote:
>
> Are you using Micro Focus Cobol? If so, then you can. You will have to
> write an external File Handler routine to do it, but it can be done.
>
> TL
>
Howard Brazee
"William M. Klein" wrote:
>
> If you are talking about OS/390, then I believe there are ways to handle this
> via JCL. (Certainly you CAN send the output to a file and spool that to a
> printer via IEBGENER in a subsequent step.)
I am. I noticed this need when I had to create a file to duplicate my
display. I did a write to a file and a display to sysout - so that I
could go into SYSD and monitor my progress. Once I got sufficient debug
lines, I could kill my long running job. A subsequent step won't do it.
William M. Klein
this give you what you are looking for (assuming JES2, not JES3). See
http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/IEA1B510/5%2e5%2e6%2e2
--
Bill Klein
wmklein <at> ix dot netcom dot com
"Howard Brazee" <howard...@cusys.edu> wrote in message
news:39074022...@cusys.edu...
Charles Hammond
often have reports that do multiple tasks. Sometimes we use an accept so
we can select what we want to do.
For instance if you want to build a file to sort, sort it and then print
it you can use a switch in your program to decide which task to do. By
doing this you eliminate wasted space for the 2 programs.
I have a little program that prints sections from my system dictionary, so
I needed to build an SD so I could sort it. I also needed to save the file
for a PC usage of the data so I built a downlod file that I can download
through the network.
A lot of this is operating system dependent. I actually just run the
program once for the build and once for the print, because we use a
utility program to do the sort in the middle. but you could do both
either at the same time with multiple writes or by just using a switch to
go back and start over after the build. You just need an extra file in the
file description, one for the print-file and one to write the file to.
The accepts on a mainframe we handle in the job control language. So for
one job you can run multiple programs.
Charles Hammond, BSIM Undergraduate Program
Howard Brazee
"William M. Klein" wrote:
>
> I have never used it, but have you looked at the OUTDISP parameter? Might
> this give you what you are looking for (assuming JES2, not JES3). See
>
> http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/IEA1B510/5%2e5%2e6%2e2
This looks useful, but not for what I want, unless I can convert from
SYSOUT=* to SYSOUT=FILE.NAME,DISP=(NEW,CATLG,DELETE),SPACE=...
Interesting, looking at your link I found the following:
//ddname DD SYSOUT=class
//name OUTPUT CLASS=class
//ddname DD SYSOUT=(,),OUTPUT=*.name
//name OUTPUT DEFAULT=YES,CLASS=class
//ddname DD SYSOUT=(,)
What in the world is *.name?
docd...@clark.net
Howard Brazee <Please, do, not, e-mail, replies, to, Howard, Brazee, post,
them!!> wrote:
>
>
>"William M. Klein" wrote:
>>
>> If you are talking about OS/390, then I believe there are ways to handle this
>> via JCL. (Certainly you CAN send the output to a file and spool that to a
>> printer via IEBGENER in a subsequent step.)
>
>I am. I noticed this need when I had to create a file to duplicate my
>display. I did a write to a file and a display to sysout - so that I
>could go into SYSD and monitor my progress. Once I got sufficient debug
>lines, I could kill my long running job. A subsequent step won't do it.
Golly... wasn't the ready availability of COBTEST supposed to make such
things unnecessary?
DD
docd...@clark.net
Howard Brazee <Please, do, not, e-mail, replies, to, Howard, Brazee, post,
them!!> wrote:
>
>
>"William M. Klein" wrote:
>>
>> this give you what you are looking for (assuming JES2, not JES3). See
>>
>> http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/IEA1B510/5%2e5%2e6%2e2
>
>This looks useful, but not for what I want, unless I can convert from
>SYSOUT=* to SYSOUT=FILE.NAME,DISP=(NEW,CATLG,DELETE),SPACE=...
>
>Interesting, looking at your link I found the following:
> //ddname DD SYSOUT=class
>
> //name OUTPUT CLASS=class
> //ddname DD SYSOUT=(,),OUTPUT=*.name
>
> //name OUTPUT DEFAULT=YES,CLASS=class
> //ddname DD SYSOUT=(,)
>
>What in the world is *.name?
Hmmmmmm... smells like referback, Kemo Sabe.
DD
ChrisOsborne
news:y7LN4.18478$0o4.1...@iad-read.news.verio.net...
> In article <39074022...@cusys.edu>,
> Howard Brazee <Please, do, not, e-mail, replies, to, Howard, Brazee,
post,
> them!!> wrote:
> >
> >
> >"William M. Klein" wrote:
> >>
handle this
> >> via JCL. (Certainly you CAN send the output to a file and spool that
to a
> >> printer via IEBGENER in a subsequent step.)
> >
> >I am. I noticed this need when I had to create a file to duplicate my
> >display. I did a write to a file and a display to sysout - so that I
> >could go into SYSD and monitor my progress. Once I got sufficient debug
> >lines, I could kill my long running job. A subsequent step won't do it.
>
> Golly... wasn't the ready availability of COBTEST supposed to make such
> things unnecessary?
Don't the local sysprogs have to install COBTEST? I know it wasn't
installed at all at a former site I worked at; though they had Xpediter to
make up for it.
>
> DD
>
William M. Klein
> >
> > Golly... wasn't the ready availability of COBTEST supposed to make such
> > things unnecessary?
>
> Don't the local sysprogs have to install COBTEST? I know it wasn't
> installed at all at a former site I worked at; though they had Xpediter to
> make up for it.
>
Bits and pieces of "information"
COBTEST was the VS COBOL II debugger - the current "debugger" is called "The
Debug Tool" - and it works for ALL the LE-enabled languages. (It DOES also
support debugging of VS COBOL II programs in a COBOL for this-and-that
applications.)
The Debug Tool is a "freebie" (unlike earlier IBM "add-ons") - so if your
site has LE, it has the Debug Tool.
Yes, your systems programmers need to "install" it, but it is actually easier
to install it than to avoid it. Often it is installed in shops - that don't
even know that it is there.
The original question about viewing output as a "debugging" option, is really
independent of COBTEST vs Debug Tool vs Xpediter vs SmarTest vs whatever.
Any one of those debugging programs SHOULD provide you an "option" that (I
would think) would be better than trying to monitor an output file.
Jonathan Nash
William M. Klein
before the 1st job finishes. I don't think that is what Howard was looking
for.
--
Bill Klein
wmklein <at> ix dot netcom dot com
"Jonathan Nash" <jn...@qis.net> wrote in message
news:Pine.GSO.3.96.1000426230122.1779A-100000@eclipse...
William M. Klein
http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/IEA1B510/5%2e7%2e1%2e2
(I sure wouldn't try this without asking my "friendly local SysProg" first)
--
Bill Klein
wmklein <at> ix dot netcom dot com
"Sff5ky" <sff...@aol.comxxx123> wrote in message
news:20000427000335...@nso-fc.aol.com...
> In article <Pine.SOL.3.96.100042...@ritz.cec.wustl.edu>,
> Charles Hammond <ce...@ritz.cec.wustl.edu> writes:
>
> >
> >I have a little program that prints sections from my system dictionary, so
> >I needed to build an SD so I could sort it. I also needed to save the file
> >for a PC usage of the data so I built a downlod file that I can download
> >through the network.
> >
>
> Does anyone know of a method for routing the output of a DDname
> to a network drive? I am speaking from an IBM OS/390 perspective
> with USS, TCP/IP and FTP capabilities. Currently we output a DASD
> file and then from the PC initiate an FTP session and download the files
> in BINARY mode. I would like to know if there is anyone with experience
> with generating the output directly to a PC/LAN Drive using Mainframe
> JCL syntax.
> Any assistance or pointers to specific locations in the Online reference
> manuals would be greatly appreciated.
> I have yet to search the manuals as I have never had a great deal of luck
> finding what I need without first locating the correct book. Most times
the
> book I choose is not the one the documentation wizards decided to use for
> explaining what I am looking for.
>
> Thanks for your time.
>
docd...@clark.net
ChrisOsborne <chris_n...@yahoo.com> wrote:
><docd...@clark.net> wrote in message
>news:y7LN4.18478$0o4.1...@iad-read.news.verio.net...
>> In article <39074022...@cusys.edu>,
>> Howard Brazee <Please, do, not, e-mail, replies, to, Howard, Brazee, post,
>> them!!> wrote:
>> >
>> >
>> >"William M. Klein" wrote:
>> >>
>> >> If you are talking about OS/390, then I believe there are ways to handle this
>> >> via JCL. (Certainly you CAN send the output to a file and spool that to a
>> >> printer via IEBGENER in a subsequent step.)
>> >
>> >I am. I noticed this need when I had to create a file to duplicate my
>> >display. I did a write to a file and a display to sysout - so that I
>> >could go into SYSD and monitor my progress. Once I got sufficient debug
>>
>> Golly... wasn't the ready availability of COBTEST supposed to make such
>> things unnecessary?
>
>Don't the local sysprogs have to install COBTEST? I know it wasn't
>installed at all at a former site I worked at; though they had Xpediter to
>make up for it.
I am not sure into whose lap such things falls... but I can readily
imagine that when the Big Blue Boys are in the taperoom, tossing carts
into the silo to load the OS and someone were to ask them 'Hey, will you
be installing COBTEST?'... that it would get done along with everything
else.
In my experience... not only does it have to be properly installed (and
rarely is) but there needs to be a bit of training in how to use it
(likewise never is).
DD
Sff5ky
>
> //name OUTPUT CLASS=class
> //ddname DD SYSOUT=(,),OUTPUT=*.name
>
> //name OUTPUT DEFAULT=YES,CLASS=class
> //ddname DD SYSOUT=(,)
>
>What in the world is *.name?
>
>
>
Wouldn't this be the JCL Referback to the OUTPUT profile 'name'?
Sff5ky
Binyamin Dissen
wrote:
:>MVS
:>"Lucas, Todd" wrote:
:>> Are you using Micro Focus Cobol? If so, then you can. You will have to
:>> write an external File Handler routine to do it, but it can be done.
:>> TL
:>> Howard Brazee <howard...@cusys.edu> wrote in message
:>> news:39073291...@cusys.edu...
:>> > This is an operating system issue, not a programming language issue -
:>> > but I sure wish I could point the output of a program to multiple
:>> > locations at once. Maybe have my DISPLAY go to SYSOUT and to a file
:>> > simultaneously.
If you don't want to (or can't) change the source program you can have your
friendly systems programmer write an SSI routine to do it.
PIPEs or SmartBatch may be able to do it as well.
--
Binyamin Dissen <bdi...@dissensoftware.com>
Binyamin Dissen <bdi...@netvision.net.il>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Ken Foskey
>
> I don't think so. Batch pipes lets you send output from one job to
> another - before the 1st job finishes. I don't think that is what
> Howard was looking for.
> "Jonathan Nash" <jn...@qis.net> wrote in message
> > Could BatchPipeWorks be used for something like this ?
You could write the equivalent of Unix 'tee' which copies the output
to console and passes it to the next program in the pipe.
program 1 | tee | program 2
tee would dump the output of program 1 and program 2 would also get
the output. Sledgehammer to crack a nut, but it would work.
Thanks
Ken Foskey
http://www.zipworld.com.au/~waratah/
Ken Foskey
> file and then from the PC initiate an FTP session and download the
You can execute the FTP client program from the TCPIP suite on the MVS
mainframe to a FTP server installed on your Network PC server (you do
have that set up don't you :-}).
If you need a sample JCL email me at 'waratah at zip dot com dot au'
and I will provide a JCL sample. (spamcop is broken must RTFM)
We do this to NT servers and Unix servers regularly and reliably. My
guess is you might not have the FTP server set up on your PC system
and this might be your biggest hurdle.
Howard Brazee
>
> Don't the local sysprogs have to install COBTEST? I know it wasn't
> installed at all at a former site I worked at; though they had Xpediter to
> make up for it.
To tell the truth, I don't know. I have never worked at a place where
anybody used debugger tools to follow what a batch program does - at
least past a bit of playing around. In this case, the volume of data is
such that I simply want to browse through the building output until I
found interesting data. This might be a hundred thousand records in,
before I killed the process. I guess we're too lazy to take the time
and effort to use those tools when we can do displays exactly where we
want and get our debugging out of the way quickly and easily. On the
other hand, it doesn't mean we have less work to do - by finishing up
quickly we just get handed new work.
William M. Klein
All of the debuggers have a method to put a "break point" in a debugging
session when a data-item (such as a record description) has a specific value.
You then "run" the program to that break point. Several of them (I believe)
even have a method of asking (in advance) for "backtrack" capability. This
would allow you to "run" to the record in question - and "backtrack" to look
at what happened with the previous record.
FYI-2,
From my days of working for both Micro Focus *and* ADS (the then vendor of
Xpediter), it is truly remarkable how many shops pay for
debugging/development tools but don't provide the time and resources for
their programmers to actually learn how and when to use them.
--
Bill Klein
wmklein <at> ix dot netcom dot com
"Howard Brazee" <howard...@cusys.edu> wrote in message
news:39084D30...@cusys.edu...
Howard Brazee
"William M. Klein" wrote:
>
> Just FYI,
> All of the debuggers have a method to put a "break point" in a debugging
> session when a data-item (such as a record description) has a specific value.
> You then "run" the program to that break point. Several of them (I believe)
> even have a method of asking (in advance) for "backtrack" capability. This
> would allow you to "run" to the record in question - and "backtrack" to look
> at what happened with the previous record.
If you know what you're looking for, this would be almost as easy as
putting in a display, and that backtracking ability could possibly be
useful. If you are simply putting out a lot of data looking for
something weird, that won't work.
I miss the EXHIBIT statement. I miss the ON statement.
But you may be right - that the reason batch debugging tools are not
widely used in mainframe shops is because of lack of training and
company support, rather than lack of perceived value to programmers in a
hurry.
docd...@clark.net
Sff5ky <sff...@aol.comxxx123> wrote:
>In article <Pine.SOL.3.96.100042...@ritz.cec.wustl.edu>,
>Charles Hammond <ce...@ritz.cec.wustl.edu> writes:
>
>>
>>I have a little program that prints sections from my system dictionary, so
>>I needed to build an SD so I could sort it. I also needed to save the file
>>for a PC usage of the data so I built a downlod file that I can download
>>through the network.
>>
>
>Does anyone know of a method for routing the output of a DDname
>to a network drive?
As in using a DDname to point directly to an open ftp session directed to
a network drive? No. As in creating a jobstream on the mainframe which
will invoke an ftp session and send the file down? Yes.
> I am speaking from an IBM OS/390 perspective
>with USS, TCP/IP and FTP capabilities. Currently we output a DASD
>file and then from the PC initiate an FTP session and download the files
>in BINARY mode. I would like to know if there is anyone with experience
>with generating the output directly to a PC/LAN Drive using Mainframe
>JCL syntax.
See above.
>Any assistance or pointers to specific locations in the Online reference
>manuals would be greatly appreciated.
See below.
>I have yet to search the manuals as I have never had a great deal of luck
>finding what I need without first locating the correct book. Most times the
>book I choose is not the one the documentation wizards decided to use for
>explaining what I am looking for.
Ow OW ow ow ow... *this* is what makes it less painful, but still
painful. Yes, I have designed jobstreams for OS390 systems which will
initiate an ftp session and squirt down a file; depending on how the ftp
logon id is configured the appropriate network drive/directory will be
said id's default.
In fact... I have designed... stuff, a combination of simple .BAT files
and JCL, which, when invoked by a PC user, will submit a batch job to the
mainframe's internal reader, run an extract program and then squirt the
file back down to the PC (via ftp) so that the user has fresh data to use.
Sounds right tasty, doesn't it? Well, here's the... sticky part: I was
paid for doing this... in fact, I was paid several severals of tens of
thousands of dollars for doing this; the result was a bunch of... stuff
which is now in daily use by a Very Large Company on a daily basis.
In short... I did this and still do this kind of stuff for money; this is
My Job. When I am asked to do My Job for free. I get kind of... wary.
When I am asked to do My Job for free by someone who admits that he has
'yet to search the manuals' I stifle obscenities.
You have my email address; feel free to pass it along to someone who has
sufficient authority to cut me a check.
DD
docd...@clark.net
Howard Brazee <Please, do, not, e-mail, replies, to, Howard, Brazee, post,
them!!> wrote:
[snippage]
>I guess we're too lazy to take the time
>and effort to use those tools when we can do displays exactly where we
>want and get our debugging out of the way quickly and easily.
BLEARGH! With all due respect, Mr Brazee, what you describe here is not
what I was taught to call 'laziness'. To be 'lazy' is to put out the
minimal amount of effort necessary to 'get away' with a task... the task
may or may not actually get done but the lazy one 'gets away' with
it. You seem to be stating here that you are putting in *more* effort
than the task might otherwise require were your efforts directed
differently... this, as I was taught, is not 'laziness' but more akin to
'stupidity'.
A Story:
A gang of carpenters are working on a house; the Foreman (this story is
old enough to have originated in the days when Foremen were Foremen, not
Forefolk), as is the Forman's wont, is wandering about, keeping an eye on
things. He notices one particular carpenter laboring *mightily* with his
saw and the following dialogue ensues:
F: 'Hey, Joe... what'cha doin'?'
J: 'Sawin' these planks, Boss, just like ya tol' me to.'
F: 'Yup, that ya are... y'know, I can't really tell from this angle but it
looks, to me, like your saw's kinda dull.'
J: 'You sure got a good eye, Boss... I guess that's why you're the
Boss. Saw sure is dull, duller'n a butterknife.'
F: 'Oh... ummmm, Joe, why don't you sharpen your saw?'
J: 'Sharpen my saw? I'm too busy cuttin' these planks to sharpen my saw!'
EOS
Now I have told that tale many times, in many places... and many folks
have laughed and nodded while intoning 'Yup, it's *just* that way here,
too'...
... while *my* response, when I first heard it, was to think 'All
right... and now the Foreman says 'Joe, lissen'a me. I am your
Boss... Direct Order, stop cuttin' the planks and sharpen your saw, *now*,
please?''
DD
docd...@clark.net
William M. Klein <wmk...@nospam.ix.netcom.com> wrote:
[snippimente]
>FYI-2,
> From my days of working for both Micro Focus *and* ADS (the then vendor of
>Xpediter), it is truly remarkable how many shops pay for
>debugging/development tools but don't provide the time and resources for
>their programmers to actually learn how and when to use them.
My experiences are similar to this.
DD
Howard Brazee
>
> In article <39084D30...@cusys.edu>,
> Howard Brazee <Please, do, not, e-mail, replies, to, Howard, Brazee, post,
> them!!> wrote:
>
> [snippage]
>
> >I guess we're too lazy to take the time
> >and effort to use those tools when we can do displays exactly where we
> >want and get our debugging out of the way quickly and easily.
>
> BLEARGH! With all due respect, Mr Brazee, what you describe here is not
> what I was taught to call 'laziness'. To be 'lazy' is to put out the
> minimal amount of effort necessary to 'get away' with a task... the task
> may or may not actually get done but the lazy one 'gets away' with
> it. You seem to be stating here that you are putting in *more* effort
> than the task might otherwise require were your efforts directed
> differently... this, as I was taught, is not 'laziness' but more akin to
> 'stupidity'.
That wasn't my intent. What I meant to say is that I use displays (in
batch programs) because I don't want to go to the extra work of tracing
through a debugger.
> A Story:
>
> A gang of carpenters are working on a house; the Foreman (this story is
> old enough to have originated in the days when Foremen were Foremen, not
> Forefolk), as is the Forman's wont, is wandering about, keeping an eye on
> things. He notices one particular carpenter laboring *mightily* with his
> saw and the following dialogue ensues:
>
> F: 'Hey, Joe... what'cha doin'?'
>
> J: 'Sawin' these planks, Boss, just like ya tol' me to.'
>
> F: 'Yup, that ya are... y'know, I can't really tell from this angle but it
> looks, to me, like your saw's kinda dull.'
>
> J: 'You sure got a good eye, Boss... I guess that's why you're the
> Boss. Saw sure is dull, duller'n a butterknife.'
>
> F: 'Oh... ummmm, Joe, why don't you sharpen your saw?'
>
> J: 'Sharpen my saw? I'm too busy cuttin' these planks to sharpen my saw!'
>
> EOS
>
> Now I have told that tale many times, in many places... and many folks
> have laughed and nodded while intoning 'Yup, it's *just* that way here,
> too'...
>
> ... while *my* response, when I first heard it, was to think 'All
> right... and now the Foreman says 'Joe, lissen'a me. I am your
> Boss... Direct Order, stop cuttin' the planks and sharpen your saw, *now*,
> please?''
>
> DD
Good story. I infer then that you believe that if we took the time to
really know the debugger well, we would find it to be less work than
using displays. You may be correct, but past experience has shown that
debugging batch is similar to debugging on-line. We have plenty of
experience using debugging tools with on-line - that's because we don't
have much choice. We do have a choice with batch, so we avoid them.
Joseph Kohler
Howard Brazee wrote:
>
> This is an operating system issue, not a programming language issue -
> but I sure wish I could point the output of a program to multiple
> locations at once. Maybe have my DISPLAY go to SYSOUT and to a file
> simultaneously.
Try this JCL method...
//JEPR240 JOB (EPR240,P),'W-2 PRINT JOB',MSGCLASS=5,
// USER=JEPR240,CLASS=A,PRTY=7
//*
//$AVRS OUTPUT CLASS=*
//SYSLIST OUTPUT CLASS=M
.
.
.
//STEP01 EXEC ...
.
.
.
//SYSOUD DD SYSOUT=(,),OUTPUT=(*.$AVRS,*.SYSLIST)
.
.
.
This enables us to print the same output file to 2 different classes at
once. I presume you can also write to a file as well.
Joe Kohler
docd...@clark.net
Howard Brazee <Please, do, not, e-mail, replies, to, Howard, Brazee, post,
them!!> wrote:
>docd...@clark.net wrote:
>>
>> In article <39084D30...@cusys.edu>,
>> Howard Brazee <Please, do, not, e-mail, replies, to, Howard, Brazee, post,
>> them!!> wrote:
>>
>> [snippage]
>>
>> >I guess we're too lazy to take the time
>> >and effort to use those tools when we can do displays exactly where we
>> >want and get our debugging out of the way quickly and easily.
>>
>> BLEARGH! With all due respect, Mr Brazee, what you describe here is not
>> what I was taught to call 'laziness'.
[mas snippimente]
>That wasn't my intent. What I meant to say is that I use displays (in
>batch programs) because I don't want to go to the extra work of tracing
>through a debugger.
... and what was intended in reply was what you concluded below... so, in
the words of Engineer Scott, 'Let's go see!'
>
>> A Story:
[a tale docked]
>> EOS
>>
>> Now I have told that tale many times, in many places... and many folks
>> have laughed and nodded while intoning 'Yup, it's *just* that way here,
>> too'...
>>
>> ... while *my* response, when I first heard it, was to think 'All
>> right... and now the Foreman says 'Joe, lissen'a me. I am your
>> Boss... Direct Order, stop cuttin' the planks and sharpen your saw, *now*,
>> please?''
>>
>
>Good story. I infer then that you believe that if we took the time to
>really know the debugger well, we would find it to be less work than
>using displays. You may be correct, but past experience has shown that
>debugging batch is similar to debugging on-line. We have plenty of
>experience using debugging tools with on-line - that's because we don't
>have much choice. We do have a choice with batch, so we avoid them.
I read your reply with sadness, Mr Brazee... see...
'... if we took the time to really know... we would find it to be less
work'.
The conclusion is that your work efforts are not directed by full
knowledge of alternatives... but the 'rut you know best', as it were.
Where, oh where is the Foreman who will tell you to sharpen your saws?
DD
Howard Brazee
>
> >Good story. I infer then that you believe that if we took the time to
> >really know the debugger well, we would find it to be less work than
> >using displays. You may be correct, but past experience has shown that
> >debugging batch is similar to debugging on-line. We have plenty of
> >experience using debugging tools with on-line - that's because we don't
> >have much choice. We do have a choice with batch, so we avoid them.
>
> I read your reply with sadness, Mr Brazee... see...
>
> '... if we took the time to really know... we would find it to be less
> work'.
>
> The conclusion is that your work efforts are not directed by full
> knowledge of alternatives... but the 'rut you know best', as it were.
I infer then that you believe that the batch debugger tools you are
familiar with are many orders of magnitude better than the online tools
we are familiar with.
Either that or your batch programs do a lot of calling of subprograms
(possibly OO). (That kind of complexity requires stronger tools). Boy
it would be nice if our online tools were half as useful as batch
displays. Maybe I have just worked in the wrong shops.
At any rate, I have worked with lots of programmers in lots of shops.
Maybe a third of us have tried online tools for batch. None of us have
kept doing so. The difference between us and that sawyer is that he
believes he has a tool to sharpen his saw. Maybe you have a better
"sharpener" than what I have seen at my shops, one that actually doesn't
dull the blades.
I do have to admit that in my current job I have no idea whether we have
any such tool at all. (Our online programs uses ADS/O and ADS-ALIVE for
debugging). I have asked around, but the systems person who might know
is on vacation. Since I have worked here for over two years, my
experience may be out of date.
William M. Klein
the PC is another story completely), there really should be LESS effort in
invoking an "online debugger" than using DISPLAYs.
Xpediter (and I assume several other online tools) provides a "tool" to
auto-magically convert JCL to TSO CLISTS (or possibly REXX now). In that
case, all you SHOULD need to do is (one time only) convert your JCL to
CLIST/REXX - and then invoke the debugger (usually under ISPF).
Once the full screen version of your program "comes up" - you can use a
single "line command" (that should look a LOT like and ISPF line command) to
put a break point where you would have put a DISPLAY and then run your
program. This should then give you a LOT more debugging capabilities than a
"simple display" to resolve your problem.
If this is "difficult," I just don't get it.
OTOH, there are lots and LOTS more capabilities that online debuggers have
that give you MORE capabilities than "display" statements. Getting to know
when and how to use those may take some time, but I just don't understand
how/why this is "difficult".
Now, the above DOES assume that your "installer" has installed the debugging
tool "successfully" so that it is easy to reach from your normal ISPF
session. If that is "missing" then there may be some reasons for never using
it.
--
Bill Klein
wmklein <at> ix dot netcom dot com
"Howard Brazee" <howard...@cusys.edu> wrote in message
news:3908A68F...@cusys.edu...
docd...@clark.net
Howard Brazee <Please, do, not, e-mail, replies, to, Howard, Brazee, post,
them!!> wrote:
>>
>
>> >Good story. I infer then that you believe that if we took the time to
>> >really know the debugger well, we would find it to be less work than
>> >using displays. You may be correct, but past experience has shown that
>> >debugging batch is similar to debugging on-line. We have plenty of
>> >experience using debugging tools with on-line - that's because we don't
>> >have much choice. We do have a choice with batch, so we avoid them.
>>
>> I read your reply with sadness, Mr Brazee... see...
>>
>> '... if we took the time to really know... we would find it to be less
>> work'.
>>
>> The conclusion is that your work efforts are not directed by full
>> knowledge of alternatives... but the 'rut you know best', as it were.
>
>
>I infer then that you believe that the batch debugger tools you are
>familiar with are many orders of magnitude better than the online tools
>we are familiar with.
My apologies for my obscurity, Mr Brazee; I took your statement of 'if we
took the time to really know' as the equivalent of '... but we have not
taken the time and do not really know'.
If my reading is correct then *either* of us might be right... but More
Learning is in order before a conclusion based on more on data and less on
assumption might be arrived at.
[snip]
>At any rate, I have worked with lots of programmers in lots of shops.
>Maybe a third of us have tried online tools for batch. None of us have
>kept doing so. The difference between us and that sawyer is that he
>believes he has a tool to sharpen his saw. Maybe you have a better
>"sharpener" than what I have seen at my shops, one that actually doesn't
>dull the blades.
A sharpening-stone, improperly handled, can dull a blade; first one needs
to learn how to use it.
DD
Art Perry
sharpening comment:
When my project has slow times (which it often does. Our work load
goes up and down.) I sharpen my saw. I am sharpening my saw right now
by reading this newsgroup.
Several weeks ago, I got yelled at for sharpening my saw. My leader
felt that it was not project related work and I should not be doing
it. I feel that saw sharpening is important, and although it might not
directly support the project, it always indirectly supports the
project, because it supports me.
Unfortunately, many narrow minded people who tell me what to do don't
see it that way, thus my dilemma. I've noticed several times, DD,
where you justify a given solution you have described by
saying "...Because he who signs my paychecks told me to..."
-Art
In article <MP4O4.18869$0o4.1...@iad-read.news.verio.net>,
docd...@clark.net () wrote:
[snip]
> My apologies for my obscurity, Mr Brazee; I took your statement
of 'if we
> took the time to really know' as the equivalent of '... but we have
not
> taken the time and do not really know'.
>
> If my reading is correct then *either* of us might be right... but
More
> Learning is in order before a conclusion based on more on data and
less on
> assumption might be arrived at.
>
> [snip]
>
> >At any rate, I have worked with lots of programmers in lots of
shops.
> >Maybe a third of us have tried online tools for batch. None of us
have
> >kept doing so. The difference between us and that sawyer is that he
> >believes he has a tool to sharpen his saw. Maybe you have a better
> >"sharpener" than what I have seen at my shops, one that actually
doesn't
> >dull the blades.
>
> A sharpening-stone, improperly handled, can dull a blade; first one
needs
> to learn how to use it.
>
> DD
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
docd...@clark.net
Art Perry <eowy...@my-deja.com> wrote:
>By now we are pretty much off topic, so I want to jump in with a saw
>sharpening comment:
>
>When my project has slow times (which it often does. Our work load
>goes up and down.) I sharpen my saw. I am sharpening my saw right now
>by reading this newsgroup.
>
>Several weeks ago, I got yelled at for sharpening my saw. My leader
>felt that it was not project related work and I should not be doing
>it. I feel that saw sharpening is important, and although it might not
>directly support the project, it always indirectly supports the
>project, because it supports me.
>
>Unfortunately, many narrow minded people who tell me what to do don't
>see it that way, thus my dilemma. I've noticed several times, DD,
>where you justify a given solution you have described by
>saying "...Because he who signs my paychecks told me to..."
For me it is more than 'several times', Mr Perry; I need to remind myself
of this on a daily basis:
'Why am I working on a proc in a public library where anyone, at any time,
can make mods that might screw up what I am doing? Because the person who
signs my timesheets tells me to.'
... and suchlike. You mention that a manager hollered on you for
'sharpening your saw'; this is behavior similar to the anecdote and
directly opposed to my msuing over why the Foreman didn't issue a
saw-sharpening order.
I am reminded of A Story! - perhaps apochryphal, granted, but if it isn't
true it should be.
It was told that Someone Important - Kernigan? Ritchie? - was working at
Bell Labs in the mid '70's, doing some rather... intricate work on data
dictionaries. He had A Problem in mind and had assumed the Programmer's
Position... cup of coffee in one hand, cigarette in the other, feet up on
the desk, staring at the ceiling and mapping out memory-locations in the
acoustic tiles.
His Boss walks past and bellows out 'What *ARE* you doing?!?'
He shakes himself, recovers from whatever intricacy is now lost... and, in
a calm, measured manner said 'I'm *thinking*, Boss.'
'Oh... well, can't you do that on your own time?'
This brings to mind a bit of a Benny Hill skit I saw, a few decades
back... I think it was a parody of Kojak... anyhow, Benny Hill, as one
character, engages Benny Hill, as another character, in the following
exchange:
'Where were you?
'Getting a haircut.'
'On company time?'
'It grew on company time.'
... and even more interesting, in the case of some companies - the old EDS
or Disney, say - not only does it grow on company time but it is the
company which demands hair of a certain length, too.
DD
Jonathan Nash
can be done with BatchPipeWorks:
>Yes, for the price of (a) JCL changes and (b) BatchPipes. The advantage
>to your management is that the code is maintained (by IBM, compared to
>Paul's suggestion from yesterday.)
>It would be a half-pipe fitting to do the split.
>Tom S.
I do not know enough about BatchPipeWorks to put together the
JCL that would be needed but here is a snippit from a manual
which shows how BatchPipeWorks can send output to more than
one location:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
IBM SmartBatch for OS/390: BatchPipeWorks User's Guide
Document Number GC28-1651-01
ź Copyright IBM Corp. 1995, 1998
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
5.3.2 The > Stage Function
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The > (rewrite data set) stage function reads records from its input
stream and writes those records to a physical sequential data set or
member of a partitioned data set. The physical sequential data set must
already exist. The member of the partitioned data set may or may not
exist. The physical sequential data set is replaced. If the member of
the partitioned data set exists, it is replaced. If the member does not
exist, it is created. Specify a data set identifier as the operand. The
data set identifier can be the name of an existing physical sequential
data set, the name of a partitioned data set and the member that you want
to replace or create, or the ddname of an allocated data set. A > stage
cannot be the first stage of a pipeline.
Like the TERMINAL stage function, the > stage function copies its input
stream to its output stream for use by any following stage. All output
device drivers work this way. In fact, both the following pipelines yield
the same results:
pipe tso listcat ł > space.data ł terminal
pipe tso listcat ł terminal ł > space.data
In the example, the order of the > and TERMINAL stage functions is
reversed. TERMINAL displays the LISTCAT response on your terminal, but
also writes the records to its output stream. The input stream of the >
stage function is connected to the output stream of TERMINAL. So, the >
stage reads the response records and writes them to the SPACE.DATA data
set, replacing the contents of the data set.
In Figure 154, the < stage function reads the data set DAY.LIST, writing
the records to its output stream. Then the > stage function reads those
records from its input stream and writes them to the existing data set
NEWDAY.LIST.
--------------------------------------------------------------------------
[snip]
William M. Klein
days), if your interactive debugging tool (that comes with your compiler) is
NOT built to make debugging of exactly that type of application "easy" - then
you should look at another vendor.
Certainly, Micro Focus' Animator has been enhanced (since multi-threading and
Windows APIs became common) to work exactly IN that type of environment.
--
Bill Klein
wmklein <at> ix dot netcom dot com
"Richard Plinston" <rip...@Azonic.co.nz> wrote in message
news:390BD...@Azonic.co.nz...
> >
> > I read your reply with sadness, Mr Brazee... see...
> >
> > '... if we took the time to really know... we would find it to be less
> > work'.
> >
> > The conclusion is that your work efforts are not directed by full
> > knowledge of alternatives... but the 'rut you know best', as it were.
> >
> > Where, oh where is the Foreman who will tell you to sharpen your saws?
>
> "To a hammer all problems look like nails".
>
> You seem to have no idea of the problem area but you are proposing that
> your solution is best regardless of any aspects that you are completely
> oblivious to.
>
> While interactive debugging is wonderful for certain sets of problems it
> is not always the best solution. I have a system which would be
> extremely difficult to interactively debug and would be almost
> unmanageable to maintain in a manner that would facilitate this. It is
> a large Windows API system maintaining a dozen or so main windows and a
> multitude of dialog boxes that allows completely unstructured user
> interaction.
>
> The system has its own built in 'debugging' trace that can be turned on
> or off. This is equivalent to 'Batch Displays' but uses a dialog list
> box and write a log file. Mostly it is only necessary to turn on the
> trace - on the users' site if required, and get the trace results to see
> where the problem is occuring.
>
> Different mechanisms may be more appropriate to other needs.
William M. Klein
that depends) - but all the debuggers that I know of, let you put a "break
point" in and to RUN to that point. Many (but not all) allow you to then
"backtrack" from that point to see how you got there. Even if you JUST have
the former capability, I am still not convinced of how/why a DISPLAY or
"logging" tool would be easier to use for debugging.
Oh well, the days of my getting a paycheck based on "selling" people on more
efficient debugging techniques is long gone, so I wish you luck with whatever
technique you find easiest/most useful. (How about always writing and
maintaining "perfect" code - Now debugging that is a "breeze" <G>)
--
Bill Klein
wmklein <at> ix dot netcom dot com
"Michael Mattias" <michael...@gte.net> wrote in message
news:qPLO4.1361$%Z2.1...@dfiatx1-snr1.gtei.net...
> Not withstanding my high regard for your views, I think I'll weigh in on
the
> side of Mr Plinston on this one.
>
> Perhaps it's because the first couple of times I tried to use a stepping
> debugger it was very difficult to use; or perhaps it's because I rarely
need
> to maintain old non-structured code, but I have developed the attitude that
> a stepping debugger is just not that valuable a tool.
>
> Seems to me other methods - log files or displays for instance - are better
> tools.
>
> Of course, there's no substitute for better planning when first developing
> the code - that is, planning in advance how you are going to *test* the
> code - and building in the appropriate "hook" points.
>
> --
> Michael Mattias
> Tal Systems
> Racine WI USA
> michael...@gte.net
>
>
> William M. Klein <wmk...@nospam.ix.netcom.com> wrote in message
> news:8efeiv$84n$1...@slb6.atl.mindspring.net...
Richard Plinston
Michael Mattias
docd...@clark.net
Richard Plinston <rip...@Azonic.co.nz> wrote:
>>
>> I read your reply with sadness, Mr Brazee... see...
>>
>> '... if we took the time to really know... we would find it to be less
>> work'.
>>
>> The conclusion is that your work efforts are not directed by full
>> knowledge of alternatives... but the 'rut you know best', as it were.
>>
>> Where, oh where is the Foreman who will tell you to sharpen your saws?
>
>"To a hammer all problems look like nails".
>
>You seem to have no idea of the problem area but you are proposing that
>your solution is best regardless of any aspects that you are completely
>oblivious to.
Mr Plinston, please re-read what you quoted above and, if you would,
ponder the phrase 'full knowledge of the alternatives'.
What do you interpret this to be? I intended it to be nothing more than
a reference to the gaining of knowledge, that one should decide on a tool
*after* one has knowledge of tools; limited fellow that I am I have found
that decisions made with knowledge are usually better than ones made in
ignorance.
>
>While interactive debugging is wonderful for certain sets of problems it
>is not always the best solution.
I do not recall suggesting that this might be the case.
>I have a system which would be
>extremely difficult to interactively debug and would be almost
>unmanageable to maintain in a manner that would facilitate this. It is
>a large Windows API system maintaining a dozen or so main windows and a
>multitude of dialog boxes that allows completely unstructured user
>interaction.
>
>The system has its own built in 'debugging' trace that can be turned on
>or off. This is equivalent to 'Batch Displays' but uses a dialog list
>box and write a log file. Mostly it is only necessary to turn on the
>trace - on the users' site if required, and get the trace results to see
>where the problem is occuring.
>
>Different mechanisms may be more appropriate to other needs.
I'm not usre what you intend to be learned from this example, Mr Plinston,
but a conclusion that I do *not* see coming out of it is that Mr Brazee
should remain in ignorance regarding the capabilities of the debugger
available to him... if my vision is correct then we are, I believe, in
agreement.
DD
Sff5ky
<wmk...@nospam.ix.netcom.com> writes:
>
>I agree that a "stepping" debugger is not that useful (well actually even
>that depends) - but all the debuggers that I know of, let you put a "break
>point" in and to RUN to that point. Many (but not all) allow you to then
>"backtrack" from that point to see how you got there. Even if you JUST have
>the former capability, I am still not convinced of how/why a DISPLAY or
>"logging" tool would be easier to use for debugging.
>
I have tried using the LE Debug Tool on a batch program and found that
it can be VERY difficult to work with. Even when using a control break
on a given line, it seemed to break/stop on EVERY record of the SYSIN
parms file which happens to be almost 1500 lines. It usually generates
about 5000 lines of output in the listings file.
William M. Klein
I know that Jimmy is using MERANT's NetExpress. Has it yet provided
support for an 'external repository' for interfaces? If not, and it still
requires you to actually keep the "prototype" in EVERY program that uses it,
I am not so positive that this really is a "good solution" (yet).
Once they do support an external repository for such things, then YES, I
would say that you should make certain that all CALLs and INVOKEs use "early"
binding where possible and late when that is all that is available.
--
Bill Klein
wmklein <at> ix dot netcom dot com
"Ken Foskey" <war...@zip.com.au> wrote in message
news:390D05EC...@zip.com.au...
> "James J. Gavan" wrote:
> >
> > My current debugger is a dream. I set breakpoints to stop at critical
> > areas then step through until I hit the specific line of code causing
> > the problem. Being OO, invariably it is a missing linkage parameter
> > or an incorrect object reference.
>
> For every object and method you should be using the interface
> definition. This will stop the compile dead and no debugging
> required.
>
> I saw a statistic that 30% of all coding errors were mismatches in
> parameters in writing solid code, this is the first instance when
> this has been supported.
James J. Gavan
"William M. Klein" wrote:
>
> I agree that a "stepping" debugger is not that useful (well actually even
> that depends) - but all the debuggers that I know of, let you put a "break
> point" in and to RUN to that point. Many (but not all) allow you to then
> "backtrack" from that point to see how you got there. Even if you JUST have
> the former capability, I am still not convinced of how/why a DISPLAY or
> "logging" tool would be easier to use for debugging.
>
> Oh well, the days of my getting a paycheck based on "selling" people on more
> efficient debugging techniques is long gone, so I wish you luck with whatever
> technique you find easiest/most useful. (How about always writing and
> maintaining "perfect" code - Now debugging that is a "breeze" <G>)
>
Are we differentiating between mainframe and PC debuggers. I see Sff5ky
referring to LE debugger as being difficult to use.
Believe me, just having had to recently do a quick and dirty Y2K on
RM/COBOL(1980) - how I wished for a debugger. To get it right
necessitated me putting in displays and "ACCEPT CHAR-X" to stop the
bloody thing so I could see what was being displayed. Remember - this
was meant to be a quick fix, not something for posterity.
My current debugger is a dream. I set breakpoints to stop at critical
areas then step through until I hit the specific line of code causing
the problem. Being OO, invariably it is a missing linkage parameter or
an incorrect object reference.
Jimmy
Ken Foskey
>
> My current debugger is a dream. I set breakpoints to stop at critical
> areas then step through until I hit the specific line of code causing
> the problem. Being OO, invariably it is a missing linkage parameter
> or an incorrect object reference.
For every object and method you should be using the interface
Thane Hubbell
wrote:
Ken,
He can't. Neither Fujitsu or Merant (that I am aware of) have
implementated the "INTERFACE". However, Fujitsu does let you restrict
object references to certain classes - either spcifically or to that
class and anything that inherits from it. Also using the Repository,
Fujitsu presently does conformance checking. Interface is defined in
the draft standard, but I know of no compiler vendor that has
implemented it.
James J. Gavan
"William M. Klein" wrote:
>
> Ken and Jimmy,
> I know that Jimmy is using MERANT's NetExpress. Has it yet provided
> support for an 'external repository' for interfaces? If not, and it still
> requires you to actually keep the "prototype" in EVERY program that uses it,
> I am not so positive that this really is a "good solution" (yet).
>
> Once they do support an external repository for such things, then YES, I
> would say that you should make certain that all CALLs and INVOKEs use "early"
> binding where possible and late when that is all that is available.
>
As Thane has already pointed out, it is the linkage/conformance checking
in COBOL 200X which will be a real boon. Given these two features, I
think debugging becomes a matter of merely checking your business
logic/sequencing in a three-tier system approach. Using three-tier and
having gotten "canned" User Interface (Screens) and DBI(File Handling)
right - you can be almost 100% certain that your errors reside in your
business logic.
Jimmy
Eddie White
"William M. Klein" <wmk...@nospam.ix.netcom.com> wrote:
> Again - going back to my Xpediter days (Micro Focus and "porting"
testing to
> the PC is another story completely), there really should be LESS
effort in
> invoking an "online debugger" than using DISPLAYs.
>
> Xpediter (and I assume several other online tools) provides a "tool"
to
> auto-magically convert JCL to TSO CLISTS (or possibly REXX now). In
that
> case, all you SHOULD need to do is (one time only) convert your JCL to
> CLIST/REXX - and then invoke the debugger (usually under ISPF).
>
In my previous life as a Cobol programmer, I worked in shops that used
both Xpediter and SmarTest. The gotcha in the JCL to CLIST conversion
method is if you have any files on tape. OTOH, both of these debugging
tools had the ability to attach from an ISPF session to a batch address
space. Again, there is a gotcha. The batch address space identifier
has to be recognizable as a VTAM application for the cross-region
communication to work. If you have a willing MVS sysprog, no problem.
Otherwise, you have to use Howard's method.
Eddie White, Volvo IT North America
William M. Klein
much of your "debugging" stage should be using tape files.
The VTAM session problem ONLY is a problem if you are using a "remote"
debugger, i.e. running your debugging session on the PC while the application
runs on the mainframe. If, instead, you do your debugging in "TSO
Foreground," this should not be a problem. (Although some shops still do NOT
like the resources that this takes either)
--
Bill Klein
wmklein <at> ix dot netcom dot com
"Eddie White" <eddie...@hotmail.com> wrote in message
news:8ekqus$4t$1...@nnrp1.deja.com...
Howard Brazee
>
> In my previous life as a Cobol programmer, I worked in shops that used
> both Xpediter and SmarTest. The gotcha in the JCL to CLIST conversion
> method is if you have any files on tape. OTOH, both of these debugging
> tools had the ability to attach from an ISPF session to a batch address
> space. Again, there is a gotcha. The batch address space identifier
> has to be recognizable as a VTAM application for the cross-region
> communication to work. If you have a willing MVS sysprog, no problem.
> Otherwise, you have to use Howard's method.
Has anybody used a batch COBOL debugger in an IDMS environment?
As I said earlier, I do use ADS-ALIVE to debug ADS programs. I am
limited to producing snaps of IDMS-DC programs called by on-line. Batch
IDMS programs, I use displays. Of the three the hierarchy of ease of
use is very clear:
Displays are much easier.
ADS-ALIVE is pretty much of a pain, but it allows me to change my mind
during the test run.
Snap dumps are at the bottom.
When I have been at shops which had Expediter, nobody used it for more
than getting nicely formatted dumps. Now that IBM gives us almost as
good dumps, I wouldn't spend money for that limited use. (It is quite
possible that if they were forced to use it interactively more, they
would eventually gotten used to it enough to choose to use it - but that
didn't happen).
I have used debugging tools with Java, Paradox for Windows, and C++ on
PCs. I found the switch from Paradox for DOS to Paradox for Windows had
a large effect in making me not want to use Paradox anymore - debugging
was all of a sudden much harder. But that isn't the fault of the
debugging tool, that was a result of its attempt to be more like OO.
With a lot of objects, debugging tools are necessary, as everything is
hidden and hard to find. And with interactive programs, some type of
debugging tool is necessary.
A powerful tool sometimes is necessary to do a tough job. But a
strength of Cobol is that it can often be designed so that debugging is
an easy job. Instead of getting out the back hoe and its highly paid
trained operator, I can get out a shovel, dig my small hole, find my
treasure and fill it back in while the back hoe is still being loaded
into the trailer.
I infer that OO shops have much tougher maintenance requirements which
make such tools more appropriate. I intend on using the right sized
tool for the job.
William M. Klein
"long ago and far away" - when I worked for ADS (Xpediter's then vendor),
we had LOTS of IDMS sites. I suspect that Compuware would be more than happy
to provide you with a number of "reference sites" for IDMS (batch) debugging.
--
Bill Klein
wmklein <at> ix dot netcom dot com
"Howard Brazee" <howard...@cusys.edu> wrote in message
news:390DFEF7...@cusys.edu...
James J. Gavan
Howard Brazee wrote:
>
> I infer that OO shops have much tougher maintenance requirements which
> make such tools more appropriate. I intend on using the right sized
> tool for the job.
Not PC-wise. The same N/E Animator is used for both structured and OO.
No real difference. For the latter you can open a 'window' to see a lot
of background specific to an OO object.
Regarding using the right tool. I haven't used it, although I was given
a copy. Eric Garrigue Vesely "COBOL Debugging Diagnostic Manual" 1990 -
ISBN 013 140187 4 - Prentice Hall. A quick glance indicates he uses
Declaratives to trap ALL errors for debugging purposes. Are you familiar
with it Howard ?
Jimmy
Howard Brazee
"William M. Klein" wrote:
>
> Howard,
> "long ago and far away" - when I worked for ADS (Xpediter's then vendor),
> we had LOTS of IDMS sites. I suspect that Compuware would be more than happy
> to provide you with a number of "reference sites" for IDMS (batch) debugging.
>
> --
> Bill Klein
The last IDMS site I worked at before my current site had Xpediter. But
nobody used its on-line debugger (we liked the formatted dumps though -
this was before IBM had formatted dumps). My current probably has
whatever comes with IBM Cobol. Since this thread started, I have done
some inquiry, but will need to do more research to determine whether we
have anything. It is not a priority.
Howard Brazee
I have used declaratives to do the equivalent of READY TRACE, and showed
it to others who weren't interested. After playing with a bit, I lost
interest as well. We set our compiler options so that programs give us
the line number of the abort so it is very easy to tell what the abort
was all about (along with a formatted dump). What does this procedure
give that would be more useful?
Eddie White
Joseph Kohler <joe_k...@yahoo.com> wrote:
>
>
> Howard Brazee wrote:
> >
> > This is an operating system issue, not a programming language issue
-
> > but I sure wish I could point the output of a program to multiple
> > locations at once. Maybe have my DISPLAY go to SYSOUT and to a file
> > simultaneously.
>
> Try this JCL method...
>
> //JEPR240 JOB (EPR240,P),'W-2 PRINT JOB',MSGCLASS=5,
> // USER=JEPR240,CLASS=A,PRTY=7
> //*
> //$AVRS OUTPUT CLASS=*
> //SYSLIST OUTPUT CLASS=M
> .
> .
> .
> //STEP01 EXEC ...
> .
> .
> .
> //SYSOUD DD SYSOUT=(,),OUTPUT=(*.$AVRS,*.SYSLIST)
> .
> .
> .
>
> This enables us to print the same output file to 2 different classes
at
> once. I presume you can also write to a file as well.
>
> Joe Kohler
>
The OUTPUT statement was my first thought, as well. But, a check of my
MVS/ESA JCL user's guide shows that OUTPUT only works for multiple
sysout classes/destinations, not to files. BTW, you can have send
sysout to an external writer by the OUTPUT statement.
Howard, if you want to have your displays saved in a dataset for
additional analysis after your test run is done, here's a suggestion.
First, I'm making the assumption that since you working on a
TSO/MVS/IDMS system, you have SDSF or something equivalent. Okay, when
you're ready to end you job, cancel it instead of purging it. This will
leave your sysout files on the TSO hold queue. Then, select the sysout
file your display were written to. Use the SDSF Print D command, which
will display a panel where you specify a dataset to copy the sysout file
to. Once you press enter, you're returned to the sysout display. Issue
the Print command, followed by the Print Close command. Your displays
are now save to the dataset you specified.
HTH,
Eddie White
Sff5ky
writes:
>file your display were written to. Use the SDSF Print D command, which
>will display a panel where you specify a dataset to copy the sysout file
>to. Once you press enter, you're returned to the sysout display. Issue
>the Print command, followed by the Print Close command. Your displays
>are now save to the dataset you specified.
>
This sounds similar to putting XDC in the NP column of an
output queue display. This presents the same data set destination
choice and handle the PRINT;PRINT CLOSE as well.
Something new I learned in the last couple of months
Eddie White
The only difference between the primary command Print Dataset and the
XDC line command is that the primary command gives you the opportunity
to copy only a portion of the sysout file to a dataset. You do this by
specifying a range of lines on the Print command--Print 150 300, for
examply would copy only lines 150 through 300. The line command
automatically copies the entire sysout file to a dataset.
Eddie
Eileen Preston
>>> docd...@clark.net 04/26 11:27 pm >>>
\In my experience... not only does it have to be properly installed (and rarely is) but there needs to be a bit of training in how to use it
(likewise never is).
DD
Amen
_____________________________________________________________
Deja.com: Before you buy.
http://www.deja.com/
* To modify or remove your subscription, go to
http://www.deja.com/edit_sub.xp?group=comp.lang.cobol
* Read this thread at
http://www.deja.com/thread/%3CAsON4.18610%240o4.139623%40iad-read.news.verio.net%3E
Jeff Baynard
did give us a course on it (1 or 2 hours I think) but it wasn't real
comprehensive or helpful. Displays are like GO-TOs. Maybe it's not the
best way to do something, but it works for me so I use it.
When writing new code, if you need a debugger to fix your own stuff then
stop right there! I have been tempted at times to do this but re-wrote some
of the sections. When writing new code, if it is structured then having to
use more than a few displays, especially a debugger, is not a good signal.
I assume the discussions on the debuggers is only related to old code.
Jeff
Terry Heinze
I use Xpediter at work and have found that there's a pretty fair number of
help screens behind it (F1 or HELP at the command line). F1 will list all
of your available commands and HELP <command> gives you the syntax and
example of any particular command. You can usually get by with about a half
dozen of the commands. You rarely would need all that are available to you.
I most often use INTercept, SHow INTercepts, breakpoint Before, breakpoint
After, Keep, and Peek. F6 (resume where you left off), F9 (single step),
F12 (run) and F4 (exit).
Jeff Baynard <uni...@macconnect.com> wrote in message
news:8f4ps...@enews4.newsguy.com...