|
View previous topic :: View next topic
|
| Author |
Message |
anandinmainframe
Active User
Joined: 31 May 2007
Posts: 171
Location: India
|
|
|
|
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 |
|
 |
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
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 |
|
|
anandinmainframe
Active User
Joined: 31 May 2007
Posts: 171
Location: India
|
|
|
|
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 |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
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 |
|
|
anandinmainframe
Active User
Joined: 31 May 2007
Posts: 171
Location: India
|
|
|
|
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 |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2455
Location: Hampshire, UK
|
|
|
|
| If you look at those options you will see that OPTIMIZE is already FULL. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
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 |
|
|
anandinmainframe
Active User
Joined: 31 May 2007
Posts: 171
Location: India
|
|
|
|
| Thank you Bill. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
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 |
|
|
Ed Goodman
Active Member
Joined: 08 Jun 2011
Posts: 556
Location: USA
|
|
|
|
"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 |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3053
Location: NYC,USA
|
|
|
|
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 |
|
|
|
|
