IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

JOINKEY capacity EXCEEDED error


IBM Mainframe Forums -> JCL & VSAM
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
jaggi

New User


Joined: 05 Jul 2007
Posts: 3
Location: India

PostPosted: Fri Jan 18, 2008 8:51 pm
Reply with quote

Hi,

I am using SYNCSORT with JOINKEYS to compare 2 files.
I am Getting error - > WER488A JOIN CAPACITY EXCEEDED
There are 2 files to be compared with about 2 million records each. LRECL is 3665.
Can somebody give a pointer as to how to resolve this problem?

I do not have SYNCSORT manual with me although searching for it for a long time.
Number of records in both the files are exactly 2 million each. JOINKEY is on 1st 10 bytes. Please find the complete sort card and
spool messages below.

I would appreciate any help in solving this problem. Thanks in advance.

-- Jaggi.

Code:

    SYNCSORT FOR Z/OS  1.2.3.0R    U.S. PATENTS: 4210961, 5117495   (C) 2005 SYNCSO

                                                 XXXXX INC.   z/OS   1.8.0       

    PRODUCT LICENSED FOR CPU SERIAL NUMBER 36FAB, MODEL 2094 715              LICEN

    PARMTBLE : BMSG,CORE=MAX                                                     

    $ORTPARM : DYNALLOC=(SYSDA,200),VSCORE=6M,VSCORET=38M                         

    SYSIN :                                                                       

    **********************************************************************  0007511

    *****      HERE FIRST 3 FILES FOR THE DESIGN ARE CREATED     *********  0007526

    **********************************************************************  0007531

      JOINKEYS FILES=F1,FIELDS=(1,10,A)                                     0007600

      JOINKEYS FILES=F2,FIELDS=(1,10,A)                                     0008000

      REFORMAT FIELDS=(F1:1,3664,F2:1,3634),FILL=X'FF'                      0009006

      JOIN UNPAIRED                                                         0010000

      SORT FIELDS=COPY                                                      0011000

      OUTFIL FILES=01,INCLUDE=(1,1,BI,NE,X'FF',                             0014335

                   AND,3655,10,CH,EQ,C'0001-01-01',AND,3665,1,BI,EQ,X'FF'), 0014348

                     OUTREC=(1,3634,C'U')                                   0014376

      OUTFIL FILES=02,INCLUDE=(3665,1,BI,NE,X'FF',                          0014396

                    AND,1,1,BI,EQ,X'FF'),                                   0014406

                      OUTREC=(1:3665,3634,C'A')                             0014416

      OUTFIL FILES=03,INCLUDE=(1,1,BI,NE,X'FF',                             0014426

                      AND,3665,1,BI,NE,X'FF',                               0014436

                      AND,3655,10,CH,NE,C'0001-01-01'),                     0014446

                      OUTREC=(1:3665,3634,C'A')                             0014506     0015391

      OUTFIL FILES=04,INCLUDE=(1,1,BI,NE,X'FF',AND,3665,1,BI,NE,X'FF',      0015916

                      AND,3655,10,CH,EQ,C'0001-01-01'),                     0015926

                      OUTREC=(1,3634,C'B')                                  0015966

      OUTFIL FILES=05,INCLUDE=(1,1,BI,NE,X'FF',AND,3665,1,BI,NE,X'FF',      0015986

                      AND,3655,10,CH,EQ,C'0001-01-01'),                     0015996

                      OUTREC=(1:3665,3634,C'A')                             0016006a

    WER161B  ALTERNATE PARM USED                                                 

    WER276B  SYSDIAG= 309700, 3624568, 3624568, 5667039                           

    WER164B  92,832K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,           

    WER164B     0 BYTES RESERVE REQUESTED, 1,373,384 BYTES USED                   

    WER146B  20K BYTES OF EMERGENCY SPACE ALLOCATED                               

    WER481I  JOINKEYS REFORMAT RECORD LENGTH= 7298, TYPE = F                     

    WER110I  SORTOF01 : RECFM=FB   ; LRECL=  3635; BLKSIZE=  7270                 

    WER110I  SORTOF02 : RECFM=FB   ; LRECL=  3635; BLKSIZE=  7270                 

    WER110I  SORTOF03 : RECFM=FB   ; LRECL=  3635; BLKSIZE=  7270                 

    WER110I  SORTOF04 : RECFM=FB   ; LRECL=  3635; BLKSIZE=  7270                 

    WER110I  SORTOF05 : RECFM=FB   ; LRECL=  3635; BLKSIZE=  7270                 

    WER488A  JOIN CAPACITY EXCEEDED                                               

    WER211B  SYNCSMF  CALLED BY SYNCSORT; RC=0000                                 

    WER449I  SYNCSORT GLOBAL DSM SUBSYSTEM ACTIVE                                 

    WER482I  JNF1 STATISTICS                                                     

    WER483B  2,604K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,           

    WER483B     0 BYTES RESERVE REQUESTED, 1,580K BYTES USED                     

    WER108I  SORTJNF1 : RECFM=FB   ; LRECL=  3664; BLKSIZE=  7328                 

    WER483B  1,264K BYTES OF VIRTUAL STORAGE AVAILABLE ABOVE THE 16MEG LINE,     

    WER483B     0 BYTES RESERVE REQUESTED, 1,264K BYTES USED                     

    WER483B  G=15                                                                 

    WER416B  SORTJNF1 : EXCP'S=1,UNIT=3390,DEV=8174,CHP=(87A7ADB7C1D7F4FF,3),VOL=BI

    WER416B  TOTAL OF 1 EXCP'S ISSUED FOR SORTING                                 

    WER487I  FILESIZE 0 BYTES                                                     

    WER482I  JNF2 STATISTICS                                                     

    WER483B  89,232K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,           

    WER483B     0 BYTES RESERVE REQUESTED, 88,148K BYTES USED                     

    WER108I  SORTJNF2 : RECFM=FB   ; LRECL=  3634; BLKSIZE= 18170                 

    WER483B  87,892K BYTES OF VIRTUAL STORAGE AVAILABLE ABOVE THE 16MEG LINE,     

    WER483B     0 BYTES RESERVE REQUESTED, 87,832K BYTES USED                     

    WER483B  G=5047,B=15,BIAS=00                                                 

    WER483B  72,000 PREALLOCATED SORTWORK TRACKS, 0 DYNAMICALLY ALLOCATED,       

    WER483B     0 ACQUIRED IN SECONDARY EXTENTS, 0 RELEASED, TOTAL OF 66,766 TRACKS
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10873
Location: italy

PostPosted: Fri Jan 18, 2008 9:11 pm
Reply with quote

Quote:

I do not have SYNCSORT manual with me although searching for it for a long time


that' s odd and very unpleasant for everybody ...
how have You done your work until now ???
( writing sort control statements )

if the company You work for is a licensed user
it should have all the the relevant documentation
and should make it available in order to let people do their work

very mild hint
the forums are not a manual reading service
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Fri Jan 18, 2008 10:38 pm
Reply with quote

Hello,

Quote:
I do not have SYNCSORT manual with me although searching for it for a long time.
If your system is licensed to use Syncsort, all of the documentation is available for free from Syncsort support.
Back to top
View user's profile Send private message
Alissa Margulies

SYNCSORT Support


Joined: 25 Jul 2007
Posts: 496
Location: USA

PostPosted: Sat Jan 19, 2008 12:57 am
Reply with quote

Jaggi,

As per the SyncSort for z/OS 1.2 Programmer's Guide:

WER488A JOIN CAPACITY EXCEEDED

EXPLANATION: SyncSort is unable to complete the join application because of insufficient memory. This may be due to a user error in specifying the JOINKEYS fields, or the application may be very large relative to the amount of available memory.

In order to join all records with equal JOINKEYS in SORTJNF1 with all records with matching JOINKEYS in SORTJNF2, SyncSort retains all the equally keyed SORTJNF2 records in memory to join with the next equally keyed record from SORTJNF1. The available amount of memory is determined by the available system resources and the region size and may not be sufficient if there are very many equally keyed records in SORTJNF2.

ACTION: First examine the fields specified for the JOINKEYS FILE=F2 statement and correct any errors. If the fields were incorrectly specified, then many records may have been incorrectly determined to be equally keyed.

If the JOINKEYS statement for F2 is correct, and if you believe that SORTJNF1 does not contain many equally keyed records that match the large number of equally keyed records in SORTJNF2, then this problem may be easily corrected by reversing the F1 and F2 definitions such that SORTJNF1 has many equally keyed records, but SORTJNF2 does not. To do this, reverse the DDNAMEs of the two files and change the JOINKEYS, REFORMAT, and JOIN UNPAIRED statements accordingly.

If this does not solve the problem, then the total region size must be raised high enough to contain all of the SORTJNF2 equally keyed records.

Contact SyncSort for z/OS Product Services for assistance, if necessary.
Back to top
View user's profile Send private message
jaggi

New User


Joined: 05 Jul 2007
Posts: 3
Location: India

PostPosted: Mon Jan 21, 2008 9:22 pm
Reply with quote

Thanks everyone for replying to my post. As of now the problem has been solved.

I tried reversing the F1 and F2 definitions and it worked.

Once a again. Thanks.

Jaggi.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> JCL & VSAM

 


Similar Topics
Topic Forum Replies
No new posts Error to read log with rexx CLIST & REXX 11
No new posts Error when install DB2 DB2 2
No new posts CLIST - Virtual storage allocation error CLIST & REXX 5
No new posts Error while running web tool kit REXX... CLIST & REXX 5
No new posts ISPP330 BDISPMAX exceeded CLIST & REXX 12
Search our Forums:

Back to Top