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
 

 

Performance issue with PROCESS DYN OPT

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
anandinmainframe

Active User


Joined: 31 May 2007
Posts: 171
Location: India

PostPosted: Thu Feb 20, 2014 12:50 pm    Post subject: Performance issue with PROCESS DYN OPT
Reply with quote

Hi Everyone,
Replacing 'PROCESS DYN OPT' with 'PROCESS OPT(FULL)'. what is the significance it can bring to the code. I have been asked to do this to improve the performance.
Back to top
View user's profile Send private message

Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Thu Feb 20, 2014 12:57 pm    Post subject: Reply to: Performance issue
Reply with quote

Depends on the default value of DYN, for one thing, so can't answer that.

Depends on the defualt value of OPT.

All that OPT(FULL) vs OPT(ON) does is get the compiler to look and mark unused storage, This can affect program size but is unlikely to produce a noticeable CPU reduction unless masses of unused storage are included regularly in programs at your site (and then you might not notice it much).

Post your compiler options in use from the front of a compile listing and we can see.
Back to top
View user's profile Send private message
anandinmainframe

Active User


Joined: 31 May 2007
Posts: 171
Location: India

PostPosted: Thu Feb 20, 2014 1:40 pm    Post subject: Reply to: Performance issue
Reply with quote

I hope this helps.
Code:

LANGUAGE          ===> COBOL390  (Blank for list; applies to source code)   
COMPILE PROCEDURE ===> CMNCOB3   (Blank for list; ? for designated procedure)
COMPILE PARMS     ===>                                                       
PGM BINDER PARMS  ===>                                                       
DB2 PRECOMPILE    ===> YES       (Y/N)   PRECOMPILE VARIABLES ===> YES  (Y/N)
OTHER OPTIONS     ===> YES       (Y/N to display other options)             
SUPPRESS MESSAGES ===> NO        (Y/N)                                       

Code:

NAME: XXXXXXXX                                                     
TYPE: SRC        LANGUAGE: COBOL390                                 
                                                                   
      COMPILE ONLY     ===> N       DLITxxx INCLUDE FOR IMS  ===> N
      CICS PRECOMPILE  ===> N       DROP INCLUDE STMTS(LCT)  ===> N
      TRACK(CICS)      ===> N       IMS ONLINE               ===> Y
                                    DCD LISTING (COBOL ONLY) ===> N
      GATEWAY          ===> N      SUBROUTINE (STATIC CALL) ===> N 
      EXPAND COPY      ===> Y      DROP LE (WGS 1.3/PLI)    ===> N 
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Thu Feb 20, 2014 2:19 pm    Post subject: Reply to: Performance issue
Reply with quote

No, not at all.

On the compile listing, you should find something that looks at least a bit like this:

Code:
Options in effect:
 NOADATA         
   ADV           
   QUOTE         
   ARITH(COMPAT) 
 NOAWO           
   BUFSIZE(4096) 


We need to see all of that sort of stuff.
Back to top
View user's profile Send private message
anandinmainframe

Active User


Joined: 31 May 2007
Posts: 171
Location: India

PostPosted: Thu Feb 20, 2014 2:48 pm    Post subject: Reply to: Performance issue
Reply with quote

Please find that info below.
Code:
                 
Options in effect:
 NOADATA           
   ADV             
   APOST           
   ARITH(COMPAT)   
   AWO             
 NOBLOCK0         
   BUFSIZE(31744) 
 NOCICS           
   CODEPAGE(1140) 
 NOCOMPILE(S)     
 NOCURRENCY       
   DATA(31)       
 NODATEPROC       
 NODBCS           
NODECK                         
NODIAGTRUNC                   
NODLL                         
NODUMP                         
  DYNAM                       
NOEXIT                         
NOEXPORTALL                   
NOFASTSRT                     
  FLAG(I,I)                   
NOFLAGSTD                     
  INTDATE(ANSI)               
  LANGUAGE(EN)                 
  LIB                         
  LINECOUNT(60)               
NOLIST                         
  MAP                         
NOMDECK                       
NONAME                         
  NSYMBOL(DBCS)   
NONUMBER           
  NUMPROC(NOPFD)   
  OBJECT           
  OFFSET           
  OPTIMIZE(FULL)   
  OUTDD(SYSOUT)   
  PGMNAME(COMPAT) 
  RENT             
  RMODE(AUTO)     
NOSEQUENCE         
  SIZE(MAX)       
  SOURCE           
  SPACE(1)                         
NOSQL                             
  SQLCCSID                         
NOSSRANGE                         
NOTERM                             
  TEST(NOHOOK,SEPARATE,NOEJPD)     
NOTHREAD                           
  TRUNC(BIN)                       
NOVBREF                           
NOWORD                             
  XMLPARSE(XMLSS)                 
  XREF(FULL)                       
  YEARWINDOW(1950)                 
NOZWB                                 
Back to top
View user's profile Send private message
Nic Clouston

Global Moderator


Joined: 10 May 2007
Posts: 1712
Location: UK

PostPosted: Thu Feb 20, 2014 3:52 pm    Post subject: Reply to: Performance issue
Reply with quote

If you look at those options you will see that OPTIMIZE is already FULL.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Thu Feb 20, 2014 4:06 pm    Post subject: Reply to: Performance issue
Reply with quote

You have 4.2 I see.

Assuming that this list is whilst specifying OPT(FULL) and dropping DYN, the dropping DYN is OK, as DYN is your default option.

OPT(FULL) over OPT is unlikely to genuinely make any difference to performance.

So, no damage, but no positive impact.

Code:
   AWO             
 NOBLOCK0         
  NUMPROC(NOPFD)   
  TRUNC(BIN)


These are possible to consider for performance improvements.

The BLOCK0, unless your system does unblocked files, won't really affect performance, but will improve flexibility.

I would not use AWO if it can be avoided, but specify APPLY WRITE ONLY for all VB output files. AWO affects VB input files, and slows that part down. So benefit from APPLY WRITE ONLY without the detriment of AWO. However, you can't just change this. That would be bad. You may have programs which are "benefitting" (not abending) from AWO without anyone realising.

For NUMPROC and TRUNC you have the worst performance options - but you must not just change them. They change the way programs operate, so you have a big analysis job if you want to change both or either.

Do you have general performance problems with your systems? If so, best to find out why, before considering changing compiler options.
Back to top
View user's profile Send private message
anandinmainframe

Active User


Joined: 31 May 2007
Posts: 171
Location: India

PostPosted: Thu Feb 20, 2014 4:23 pm    Post subject: Reply to: Performance issue
Reply with quote

Thank you Bill.
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: Thu Feb 20, 2014 9:16 pm    Post subject:
Reply with quote

Hello,

Who has determined there are performance problems and how did they determine this?

Many folks want their system to "run better" but there needs to be an understanding of just what can be improved.

Usually sledgehammer tuning does not get the desired results.
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Thu Feb 20, 2014 9:47 pm    Post subject:
Reply with quote

"Usually sledgehammer tuning does not get the desired results."

I smart-assedly disagree. Performance projects ALWAYS get desired results. This is because no one EVER does before/after analysis when starting out.

The results are always what you needed them to be, because after you have ten people work for a year on 'making it better,' the only possible outcome is success. That's what the manager's report will say for certain.
Back to top
View user's profile Send private message
Rohit Umarjikar

Senior Member


Joined: 21 Sep 2010
Posts: 1609
Location: NY,USA

PostPosted: Sat Feb 22, 2014 1:40 am    Post subject:
Reply with quote

It is very good that you asked and understood before you go and make the change.

So baiscally as Nic said OPT(FULL) already is in place and Bill also mentioned this can hardly change your performace stats may be fractional sometimes ( I did this before but nothing considerable change found)

And I totally agree with Dick on,
Quote:

Many folks want their system to "run better" but there needs to be an understanding of just what can be improved
[/quote]
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 -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts DFHRESPONSE returns issue divated CICS 3 Wed Nov 02, 2016 6:32 pm
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 Can sending 5 MB data between cobol p... Kevin Vaz CICS 12 Tue Oct 18, 2016 4:50 pm
No new posts REXX Screen not working due to LINKED... sundarkudos CLIST & REXX 1 Mon May 09, 2016 1:44 pm
No new posts Issue in sending zip file as mail att... ajithajt JCL & VSAM 8 Thu Apr 07, 2016 9:11 am


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