What are your favorite TSO/ISPF Performance No-Nos

dick scherrer · Posted: Mon Sep 23, 2013 9:54 pm

Howdy,

I am looking for different things that can be done but probably should not be done in the online environment.

One is sorting a file online (unless it is tiny).

Another is running file compares or searches online.

Another is compiling online.

Also, "Big" queries run in SPUFI.

What performance dehancers have you seen on your systems?

Is it true that the online file transfer uses more resources than ftp?

Thanks for the feedback.

d

don.leahy · Posted: Mon Sep 23, 2013 10:32 pm

Avoid Browse/Edit/View on a large data set with a poor BLKSIZE. I once did this deliberately to make a point; the difference in response time for a DOWN MAX command was dramatic.

daveporcelan · Posted: Mon Sep 23, 2013 10:41 pm

I have done the following without issue:

Run a SORT against a file with 400,000 records in less than 2 seconds.

Compared two files (Cobol programs) of 90,000 lines in less than 2 seconds.

It may be the speed of our processor, but many things like that work fine.

Even a longer wait beats submitting a batch job and having to go to the held queue for the results.

Just my opinion, nothing more.

don.leahy · Posted: Mon Sep 23, 2013 10:55 pm

Agree daveporcelan. Some things that I would not have dared do in the past I now do routinely. SRCHFOR on member lists; SRCHFOR on a data set lists, to name but two.

OTOH I am a very impatient guy. If I think that the response time will be > 8-10 seconds, and it is something that I will have to do more than once, I try to find a way to do it in batch.

dick scherrer · Posted: Mon Sep 23, 2013 11:55 pm

Thanks for the replies.

Many of the things that cost the most make life easier for the developer.

Things like those mentioned run very quickly many places these days. Our chargeback works on i/o and cpu utilization and these skyrocket.

Toggling to an output screen should be little to no inconvenience. When i'm on tso submitting jobs, i typically have an sdsf screen open or the equivelent in ROSCOE.

What i'm trying to do is generate a list of the more expensive things people do with no regard to the cost.

Some places have an entire test lpar that is not charged back. Then resource use is less of a concern.

Thanks again - keep'em coming

d

don.leahy · Posted: Tue Sep 24, 2013 12:54 am

Use of any interactive debugger can cost lots of $CPU. That used to be a huge concern in some shops, and in some cases kept those tools out of the environment completely.

I haven't used ROSCOE in over 20 years, and that was in a very tight-fisted shop where only the systems programmers were allowed to have access to TSO.

dick scherrer · Posted: Tue Sep 24, 2013 1:23 am

This client is primarily a roscoe shop.

Due to some rather sudden increase in contractor staff for a couple of projects, TSO is seeing more action and these folks are used to doing things the fastest way for them. They have not had to worry about the cost at previous clients (apparently).

Thanks for the mention about interactive debuggers. One of our folks ran Xpediter against a big batch probram and sucked up about 18 million cpou seconds . . . Bet that doesn't happen again

Question, is there any db2 impact when running an online debugger?

The 2 line items that have Jumped recently are TSO and DB2.

Bill O'Boyle · Posted: Tue Sep 24, 2013 3:15 am

ISPF selection 4 - Foreground Compiles (Your friendly SYSPROG may call you)

dbzTHEdinosauer · Posted: Tue Sep 24, 2013 4:56 pm

ispf panels
where the number of records/rows or whatever is done
is updated constantly (or every 100 or 1000).

don.leahy · Posted: Tue Sep 24, 2013 6:24 pm

Using an interactive debugger should not have much impact on DB2 cpu usage but can have an impact on the performance of the subsystem. Someone stitting at a breakpoint for 30 minutes analyzing code might be holding locks for that entire period of time.

I have often used debuggers on batch programs, but I always make an effort to keep the input file as small as possible. That's not just to save CPU; I am far too impatient to sit there watching the code churn through 10,000 records before reaching the one that is causing the problem.

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

-Don't do a report look up in Control-D without a USER specified. LOTS of data to sift through for that.

vasanthz · Posted: Tue Sep 24, 2013 10:30 pm

Processing large files using interactive SAS Program editor. Batch sas is well suited for large files or any type of file processing as it reduces utilization peaks.