Quantcast
Channel: IBM Mainframe Computers Forums
Viewing all 8500 articles
Browse latest View live

SYNCSORT :: RE: Reduce CPU Times for Join Sort

$
0
0
Author: santoshn
Posted: Wed Jun 14, 2017 7:18 pm (GMT 5.5)

Sorry I could not reply earlier. I had access issues on mainframes.
This job is one of more expensive jobs so we are checking if any alternative can be implemented to reduce CPU times.
Both the files are unloads for tables so they are sorted with a default order.
Below is the SORT which compares and send delta:
Code:
SORT FIELDS=COPY                                                   
JOINKEYS FILES=F1,FIELDS=(01,99,A,102,105,A,207,139,A,346,240,A,   
                          586,47,A,633,254,A,887,254,A,1141,83,A, 
                          1224,240,A,1464,21,A,1511,93,A,1604,3,A,
                          1607,17,A)                               
                                                                   
JOINKEYS FILES=F2,FIELDS=(01,99,A,102,105,A,207,139,A,346,240,A,   
                          586,47,A,633,254,A,887,254,A,1141,83,A, 
                          1224,240,A,1464,21,A,1511,93,A,1604,3,A,
                          1607,17,A)                               
                                                                   
JOIN UNPAIRED,F2,ONLY                                             
REFORMAT FIELDS=(F2:01,1623)                                       
OUTFIL FNAMES=SORTOUT,                                             
BUILD=(1:1,1623)


Coded for you
Do it yourself next time


DFSORT/ICETOOL :: RE: Include/omit with "ALL" parameter

$
0
0
Author: Nic Clouston
Posted: Wed Jun 14, 2017 7:45 pm (GMT 5.5)

Rohit, that does not explain what the 'ALL' does within the conditional expression. It seems that 'ALL' should be the entire expression i.e.
Code:
OMIT COND=ALL
but the example shows
Code:
OMIT COND=((142,1,BI,ALL,B'00000001')

_________________
Regards
Nic

SYNCSORT :: RE: Reduce CPU Times for Join Sort

$
0
0
Author: Nic Clouston
Posted: Wed Jun 14, 2017 7:49 pm (GMT 5.5)

By default JOINKEYS sorts both data sets (they are not "files") unless told not to by the SORTED keyword - which I do not see in your control statements.
_________________
Regards
Nic

SYNCSORT :: RE: Reduce CPU Times for Join Sort

$
0
0
Author: Rohit Umarjikar
Posted: Wed Jun 14, 2017 8:00 pm (GMT 5.5)

1.Can't it be possible to try unload delta by some sql query using batch spufi or BMC unload?
2. Try COMPAREX
3.as suggested add SORTED keyword during the JOINKEYS.
_________________
Regards,
Rohit Umarjikar
"Knowledge is knowing that a tomato is a fruit, but Wisdom is knowing not to put it in a fruit salad."icon_razz.gif

DFSORT/ICETOOL :: RE: Include/omit with "ALL" parameter

$
0
0
Author: dneufarth
Posted: Wed Jun 14, 2017 8:42 pm (GMT 5.5)

This may help. Look for it on the page Rohit suggested.


For complete details on the parameters of the OMIT control statement, see INCLUDE control statement.

_________________
Dave

I came here to give you these facts. It is no concern of ours how you run your own planet. But if you threaten to extend your violence, this Earth of yours will be reduced to a burned-out cinder.
The Day The Earth Stood Still

DFSORT/ICETOOL :: RE: Include/omit with "ALL" parameter

$
0
0
Author: sergeyken
Posted: Wed Jun 14, 2017 9:00 pm (GMT 5.5)

Read carefully the suggested manual.

Quote:
BO (or ALL) All mask bits are 1s (ON) in the input field
BM (SOME) Some but not all mask bits are 1s (ON) in the input field
BZ (NONE) None of the mask bits is 1 (ON) in the input field
BNO (NOTALL) Some or no mask bits are 1s (ON) in the input field
BNM (NOTSOME) All or no mask bits are 1s (ON) in the input field
BNZ (NOTNONE) All or some mask bits are 1s (ON) in the input field


You need to understand Bit Operations (or Bitwise Operations) first of all - no relation to SORT itself.
If not, then RTFM (including Wikipedia)
_________________
Tyrannosaurus-REXX

DFSORT/ICETOOL :: RE: Include/omit with "ALL" parameter

SYNCSORT :: RE: Reduce CPU Times for Join Sort

$
0
0
Author: sergeyken
Posted: Wed Jun 14, 2017 9:48 pm (GMT 5.5)

1. There are only two gaps in the whole record which are not used as join keys: bytes 100 to 101 (=2 bytes), and bytes 1485 to 1510 (=26 bytes)
It might give a minor performance improvement if all adjacent join keys were combined into three groups each considered as long join key:
Code:
FIELDS=(1,99,A,
        102,1362,A,
        1511,113,A)


2. A more significant improvement in performance might be expected only by providing at least one (better two) of input datasets to appear as pre-sorted before this join. Then extra keyword needs to be specified for the sorted field(s):
Code:
FIELDS=(...........),SORTED

_________________
Tyrannosaurus-REXX


SYNCSORT :: RE: Reduce CPU Times for Join Sort

$
0
0
Author: vasanthz
Posted: Wed Jun 14, 2017 10:58 pm (GMT 5.5)

Quote:
1.Can't it be possible to try unload delta by some sql query using batch spufi or BMC unload?
2. Try COMPAREX

On what basis are you suggesting that option 1 or 2 is efficient than JOINKEYS?
Also BMC unload and comparex are licensed products and are not available on all shops.
_________________
Strike.. Scream.. Run - Creed Bratton

TSO/ISPF :: )SEL and )ENDSEL usage

$
0
0
Author: cvnlynn
Subject: )SEL and )ENDSEL usage
Posted: Thu Jun 15, 2017 12:52 am (GMT 5.5)

What )SEL and )ENDSEL do ?

TSO/ISPF :: RE: )SEL and )ENDSEL usage

$
0
0
Author: enrico-sorichetti
Posted: Thu Jun 15, 2017 1:04 am (GMT 5.5)

asking somebody to provide an answer after nine years is at least optimistic
anyway the look like some job scheduler control statements
_________________
cheers
enrico
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort icon_cool.gif

TSO/ISPF :: RE: )SEL and )ENDSEL usage

$
0
0
Author: Akatsukami
Posted: Thu Jun 15, 2017 1:06 am (GMT 5.5)

I recommend that you start a new thread for your question, rather than append it to a thread that is eight and a half years old. I have done so for you.

)SEL and )ENDSEL are ISPF file-tailoring directives. Neither is actually Rexx, although many confuse the two. I recommend that you read their descriptions in the ISPF Dialog Developer's Guide and Reference.
_________________
Data is not information.
Information is not knowledge.
Knowledge is not wisdom.

TSO/ISPF :: RE: )SEL and )ENDSEL usage

JCL & VSAM :: RE: CONTIG for performance?

$
0
0
Author: steve-myers
Subject: Re: Reply to: CONTIG for performance?
Posted: Thu Jun 15, 2017 7:32 am (GMT 5.5)

Robert Sample wrote:
I don't think performance is the issue any more -- but RACF, for example, has CONTIG coded in the sample JCL member RACJCL because the RACF database must be allocated in one extent.

There are a few other places where this is true. For example, the JES2 checkpoint and SPOOL data sets must be CONTIG.

JCL & VSAM :: RE: CONTIG for performance?

$
0
0
Author: steve-myers
Subject: Re: Reply to: CONTIG for performance?
Posted: Thu Jun 15, 2017 8:21 am (GMT 5.5)

enrico-sorichetti wrote:
IIRC contig was/is used when trying to squeeze the last drop of I/O dasd performance
using highly optimized ccw chains
I'm not so sure about performance here. You might get a tiny reduction in CPU usage by cheating on some device dependent calculations, but I can't imagine any real I/O improvement unless you are also allocating in cylinders and you are using "multi-track" CCW read commands

SYNCSORT :: RE: Reduce CPU Times for Join Sort

$
0
0
Author: Robert Sample
Subject: Reply to: Reduce CPU Times for Join Sort
Posted: Thu Jun 15, 2017 6:21 pm (GMT 5.5)

Quote:
This job is one of more expensive jobs so we are checking if any alternative can be implemented to reduce CPU times.
If you're looking at a job using 3 minutes of CPU because it is "one of more expensive jobs" (sic) at your site, then you're pretty much wasting your time. If it was using 60 or 90 minutes of CPU time, then you'd be justified in looking at the job; for 3 minutes of CPU time, why bother? Even if you cut CPU time in half (which is most likely impossible based on what you've posted so far), and the job runs daily, you have saved 90 seconds of CPU time or 0.1% of the CPU available for the day (if your site has more than one CP processor in your CEC, the percentage goes down) -- hardly worth spending much time on! And if your site bought the machine, then you're not saving any money until a new machine is purchased (and not a lot then).
_________________
TANSTAAFL

The first rule of code reuse is that the code needs to be worth re-using.

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth

SYNCSORT :: RE: Reduce CPU Times for Join Sort

$
0
0
Author: Rohit Umarjikar
Posted: Thu Jun 15, 2017 9:30 pm (GMT 5.5)

Quote:
On what basis are you suggesting that option 1 or 2 is efficient than JOINKEYS?
Also BMC unload and comparex are licensed products and are not available on all shops.
I would leave that to try and acknowledge you by TS. We have them using at my shop and if TS don't have it then he is out of choice(s).
_________________
Regards,
Rohit Umarjikar
"Knowledge is knowing that a tomato is a fruit, but Wisdom is knowing not to put it in a fruit salad."icon_razz.gif

SYNCSORT :: RE: compare 2 rows within the same file

$
0
0
Author: sergeyken
Posted: Thu Jun 15, 2017 10:21 pm (GMT 5.5)

Nic Clouston wrote:
Your terminology could be better: not 'file' but a 'data set' and both files and data sets have records, not rows. SQL tables have rows.

Frankly, any "table" has "rows", not only a SQL table:
- ISPF tables
- Excel tables
- tables printed on paper
- etc.
icon_biggrin.gif
_________________
Tyrannosaurus-REXX

TSO/ISPF :: RE: )SEL and )ENDSEL usage

$
0
0
Author: sergeyken
Subject: Re: )SEL and )ENDSEL usage
Posted: Thu Jun 15, 2017 10:30 pm (GMT 5.5)

cvnlynn wrote:
What )SEL and )ENDSEL do ?

Out of context )SEL and )ENDSEL by themselves do nothing.
Those are simple sequences of characters with either wrong or strange syntax.
It depends on: where, and how they are used?

As already has been told above, it might make sense when used with ISPF File Tailoring Services. Unless there is a minor idea about this stuff - nothing to talk about these two words.
_________________
Tyrannosaurus-REXX

COBOL Programming :: Dynamic output file creation in cobol using BPXWDYN

$
0
0
Author: smileheal
Subject: Dynamic output file creation in cobol using BPXWDYN
Posted: Thu Jun 15, 2017 10:53 pm (GMT 5.5)

Hi, i am trying to create multiple output files dynamically from a Cobol pgm using BPXWDYN routine.

But when i ran the compiled load in JCL, the files are not created after the successful job run.

Below the Cobol logic.
Code:

SELECT OP-FILE ASSIGN TO DD1

FD OP-FILE
       RECORDING MODE IS F
       LABEL RECORDS ARE STANDARD.
01 OP-REC PIC X(10).

PROCEDURE DIVISION.
MOVE 'ABC.BAR.DD01' TO FN.
STRING 'ALLOC DD(DD1) DSN('FN') NEW '
'CATALOG' 'LRECL(10) RECFM(F,B)'
DELIMITED BY SIZE INTO WS-ALLOC-STRING

CALL 'BPXDWYN' USING WS-ALLOC-STRING
OPEN OUTPUT OP-FILE
MOVE '123' TO OP-REC.
WRITE OP-REC.
CLOSE OP-FILE


JCL:
Code:

STEP01 EXEC PGM=ABC
SYSOUT  DD SYSOUT=*
DD1          DD DSN=ABC.DD1

Viewing all 8500 articles
Browse latest View live


Latest Images