Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

What are your favorite TSO/ISPF Performance No-Nos

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> TSO/ISPF
View previous topic :: :: View next topic  
Author Message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Mon Sep 23, 2013 9:54 pm    Post subject: What are your favorite TSO/ISPF Performance No-Nos
Reply with quote

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
Back to top
View user's profile Send private message

don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 641
Location: Whitby, ON, Canada

PostPosted: Mon Sep 23, 2013 10:32 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
daveporcelan

Active Member


Joined: 01 Dec 2006
Posts: 645
Location: Pennsylvania

PostPosted: Mon Sep 23, 2013 10:41 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 641
Location: Whitby, ON, Canada

PostPosted: Mon Sep 23, 2013 10:55 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Mon Sep 23, 2013 11:55 pm    Post subject:
Reply with quote

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

d
Back to top
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 641
Location: Whitby, ON, Canada

PostPosted: Tue Sep 24, 2013 12:54 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Tue Sep 24, 2013 1:23 am    Post subject:
Reply with quote

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

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

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

Quote:
only the systems programmers were allowed to have access to TSO.
Yup, rather common. The good news was that as a DBA i was given the same access most places icon_cool.gif

Later,

d
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Tue Sep 24, 2013 3:15 am    Post subject: Reply to: What are your favorite TSO/ISPF Performance No-Nos
Reply with quote

ISPF selection 4 - Foreground Compiles (Your friendly SYSPROG may call you) icon_surprised.gif
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Tue Sep 24, 2013 4:56 pm    Post subject:
Reply with quote

ispf panels
where the number of records/rows or whatever is done
is updated constantly (or every 100 or 1000).
Back to top
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 641
Location: Whitby, ON, Canada

PostPosted: Tue Sep 24, 2013 6:24 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Tue Sep 24, 2013 8:17 pm    Post subject:
Reply with quote

-Don't do a report look up in Control-D without a USER specified. LOTS of data to sift through for that.
Back to top
View user's profile Send private message
vasanthz

Global Moderator


Joined: 28 Aug 2007
Posts: 1445
Location: Azeroth

PostPosted: Tue Sep 24, 2013 10:30 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> TSO/ISPF All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts What are the way we can improve CPU p... Gunapala CN DB2 10 Mon Oct 24, 2016 2:16 pm
No new posts ISPF program to set SCRNAME prino TSO/ISPF 5 Fri Sep 30, 2016 2:18 pm
No new posts I am unable to use SWAPBAR ON command... mrsidhu12 TSO/ISPF 3 Thu Sep 01, 2016 1:10 pm
No new posts ISPF Tables Creation newsysprg TSO/ISPF 6 Wed Jul 13, 2016 2:21 pm
No new posts More ISPF RFE's to vote for prino TSO/ISPF 1 Tue Apr 19, 2016 12:06 am


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us