| View previous topic :: View next topic |
| Author |
Message |
xcal
Beginner
Joined: 08 Aug 2007
Posts: 4
Topics: 1
|
 Posted: Thu Aug 09, 2007 3:43 pm Post subject: REPRO selects too many records when using FROMKEY and TOKEY |
 |
|
Hi I use IDCAMS to copy one record from one main VSAM file to another using a FROMKEY and TOKEY that are the same. Somtimes though, several nearby records are copied too:
Here is the repro stmt:
| Code: | REPRO INFILE(IN1) FROMKEY(X'62116CF0F0F3C4000007505C') -
TOKEY(X'62116CF0F0F3C4000007505C') -
OUTFILE(OU1) REPLACE |
Here is the output VSAM (OU1) with the required record (the last one) and 4 previous (key wise) ones:
| Code: | ********************************* TOP OF DATA ****
%003D & % % <M00EN % * N
616FFFC00050 616000001624DFFCD260500000000444D0000
21C00340070C 21C0000C8C6C400550C6C0C0C0C0C00050C0C
--------------------------------------------------
%003D & % M00EN % % N
616FFFC00051 616000001210DFFCD262600000000444D0000
21C00340070C 21C0000C8C8C400550C8C0C0C0C0C00050C0C
--------------------------------------------------
%003D & % @ M00EN % N
616FFFC00052 616000001708DFFCD263300000000444D0000
21C00340070C 21C0000C8C3C400550C0C0C0C0C0C00050C0C
--------------------------------------------------
%003D & % % M00EN % N
616FFFC00053 616000001603DFFCD263200000000444D0000
21C00340070C 21C0000C7C8C400550C6C0C0C0C0C00050C0C
--------------------------------------------------
%003D &* % % M00EN @ YN
616FFFC00055 616000001609DFFCD27090000000044ED0000
21C00340070C 21C0000C8C2C400550C3C0C0C0C0C00850C0C
******************************** BOTTOM OF DATA ** |
It only happens once in a while and always pulls in records consecutive to the required one. I havent been able to figure out what causes this. Is there a way to ensure only the record desired is copied? |
|
| Back to top |
|
 |
Terry_Heinze
Supermod
Joined: 31 May 2004
Posts: 391
Topics: 4
Location: Richfield, MN, USA
|
| Posted: Thu Aug 09, 2007 4:10 pm Post subject: |
|
|
Are you certain that those 1st 4 records weren't already on the output file before your REPRO?
_________________
....Terry |
|
| Back to top |
|
|
dbzTHEdinosauer
Supermod
Joined: 20 Oct 2006
Posts: 1411
Topics: 26
Location: germany
|
| Posted: Thu Aug 09, 2007 4:14 pm Post subject: |
|
|
I assume the key is only 12 bytes, and records ...500 thru 503 were not already in ou1.
what does the sysout and msgs say? It always tells you how many records were repro'd.
_________________
Dick Brenholtz
American living in Varel, Germany |
|
| Back to top |
|
|
xcal
Beginner
Joined: 08 Aug 2007
Posts: 4
Topics: 1
|
| Posted: Thu Aug 09, 2007 6:49 pm Post subject: |
|
|
Of course the output file was empty.. sheesh. the out put is deleted and redefined each time before the copy, and I checked it before this last test  .
It appears to almost use only the 1st 11 bytes of the key... but here is delete define :
| Code: | **************************** Top of Data ************************
DELETE (PPP.PPSY.PROD.GGCRTZ.VSAM)
SET MAXCC=0
DEFINE CLUSTER -
( NAME(PPP.PPSY.PROD.GGCRTZ.VSAM) -
BUFFERSPACE(38400) -
CYLINDER(9 5) -
INDEXED -
KEYS(12 0) -
RECORDSIZE(642 8764) -
SPEED -
SHAREOPTIONS(2 3) ) -
DATA -
( CISZ (12288) -
NAME(PPP.PPSY.PROD.GGCRTZ.VSAM.DATA) ) -
INDEX -
( CISZ (512) -
NAME(PPP.PPSY.PROD.GGCRTZ.VSAM.INDX) )
IF LASTCC EQ 0 THEN -
DEFINE ALTERNATEINDEX -
( NAME(PPP.PPSY.PROD.GGCRTZIN.VSAM) -
RELATE(PPP.PPSY.PROD.GGCRTZ.VSAM) -
BUFFERSPACE(38400) -
CYLINDERS(3 2) -
KEYS(8 7) -
SPEED -
REUSE -
SHAREOPTIONS(2 3) ) -
DATA -
( NAME(PPP.PPSY.PROD.GGCRTZIN.DATA) ) -
INDEX -
( NAME(PPP.PPSY.PROD.GGCRTZIN.INDX) )
DEFINE PATH -
( NAME(PPP.PPSY.PROD.GGCRTZIN.PATH) -
PATHENTRY(PPP.PPSY.PROD.GGCRTZIN.VSAM) ) |
The set up of the input VSAM is also key of 12 bytes.
| Code: | File-AID ------ VSAM Information - (Page 1 of 2 ) ---------------------------
COMMAND ===>
Catalog: SYS1.TESTCAT2
Cluster: 'GRA.PPSY.PROD.DETAIL.VSAM'
Data: 'GRA.PPSY.PROD.DETAIL.VSAM.DATA' Data Volume: TEP095
Index: 'GRA.PPSY.PROD.DETAIL.VSAM.INDEX' Index Volume: TEP095
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Data Component Information: Current Allocation Options:
Device type: 3390 Load option: SPEED
Organization: KSDS Write check: NO
KSDS key length: 12 Buffer space: 38400
KSDS key location: 0 Erase on delete: NO
Average record size: 642 Imbedded index: NO
Maximum record size: 8764 Replicated index: NO
Allocated Space: Unit Primary Secondary Reuse option: NO
Data: CYLINDERS 50 25 Share option: 2-3
Index: TRACKS 2 1 Spanned records: NO
Dataset Date Information: Key ranges present: NO
Creation date: 2007/06/27 AIX-unique keys:
Expiration date: AIX-upgrade:
Modification date: 2007/07/18
Modification time: 03:45 PM GMT
|
The sysout is as follows:
| Code: | ********************************* TOP OF DATA *******************
IDCAMS SYSTEM SERVICES
REPRO INFILE(IN1) FROMKEY(X'62116CF0F0F3C4000007505C') -
TOKEY(X'62116CF0F0F3C4000007505C') -
OUTFILE(OU1) REPLACE
IDC3300I ERROR OPENING PPP.PPSY.DEV.GGCRTZ.VSAM
IDC3351I ** VSAM OPEN RETURN CODE IS 100
IDC0005I NUMBER OF RECORDS PROCESSED WAS 5
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 4
IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 4
******************************** BOTTOM OF DATA ***************** |
The return code 100 always happens due to an alternate index issue with the output file being empty (thus no index built). Since the multiple record problem occurs only occasionally and this index issue always occurs, I dont believe it is related. |
|
| Back to top |
|
|
kolusu
Site Admin
Joined: 26 Nov 2002
Posts: 12378
Topics: 75
Location: San Jose
|
| Posted: Thu Aug 09, 2007 8:53 pm Post subject: |
|
|
xcal,
The reason for extra keys is the item in bold
| Quote: |
FROMKEY(key)
specifies the key of the first record you want copied. If you specify generic keys (a portion of the key followed by *), copying begins at the first record with a key matching the portion of the key you specified. You cannot specify a key longer than that defined for the data set. If you do, the data set is not copied. If the specified key is not found, the next higher key is used as the starting point for copying.
FROMKEY may be specified only when an alternate index, a key-sequenced VSAM data set, or an indexed-sequential (ISAM) non-VSAM data set is being copied.
key
can contain 1 to 255 EBCDIC characters.
Note: A hexadecimal key ending in X'5C' processes as a generic key.
TOKEY(key)
specifies the key of the last record you want copied. You can specify generic keys (that is, a portion of the key followed by *). If you specify generic keys, copying stops after the first record encountered that matches your key specifications. You cannot specify a key longer than that defined for the data set. If you do, the data set is not copied. If the specified key is not found, the next lower key is used as the end point for copying. TOKEY can be specified only when an alternate index, a key-sequenced data set, or an indexed-sequential (ISAM) non-VSAM data set is being copied.
key
can contain 1 to 255 EBCDIC characters.
Note: A hexadecimal key ending in X'5C' processes as a generic key.
|
You also have another problem using a packed decimal field for a KEY is not good. vsam key comparision is pure binary and this cause problems. for ex: +1 is in hex is X'001C' and a -1 in hex is X'001D'. In hex comparison X'001C'is < X'001D' which means that +1 < -1 which is not true.
Hope this helps...
Cheers
Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu |
|
| Back to top |
|
|
xcal
Beginner
Joined: 08 Aug 2007
Posts: 4
Topics: 1
|
| Posted: Fri Aug 10, 2007 8:25 am Post subject: |
|
|
THANKS SO MUCH KOLUSU!! 
I checked other occurences of this issue and it does seem to happen when the key ends in x'5C' which is '*'.
So it seems REPRO takes it as generic key - 11 bytes followed by '*'. Man... never saw that.
I tried adding another x'5C' at the end after the original x'5C' (key was then 13 bytes) and it worked - it only pulled in the desired record.
A few questions though:
| Quote: | | You cannot specify a key longer than that defined for the data set. If you do, the data set is not copied. |
It DID copy one record...I guess it doesnt see the Generic portion '*' as part of the key specified?
| Quote: | | If you specify generic keys, copying stops after the first record encountered that matches your key specifications. |
Why didnt it stop after selecting the first one before when it pulled in 5 records?
Does anyone know of another way to handle a HEX key ending with X'5C'?
Anyhow, thanks again. At least I found one solution.
Xcal... |
|
| Back to top |
|
|
kolusu
Site Admin
Joined: 26 Nov 2002
Posts: 12378
Topics: 75
Location: San Jose
|
| Posted: Fri Aug 10, 2007 9:01 am Post subject: |
|
|
xcal,
| Quote: |
I tried adding another x'5C' at the end after the original x'5C' (key was then 13 bytes) and it worked - it only pulled in the desired record.
|
The reason it worked it simple. Your key is 12 bytes
| Code: |
----+----1--
ABCDEFGHIJKL
|
In your previous extract the ending X'5c' is treated as a generic key which would make search key a 11 byte key followed by an asterick.
ex:
| Code: |
----+----1--
ABCDEFGHIJK*
|
so that is the reason you got the keys 50 thru 55.
Now when you added the extra x'5c' the extra x'5c' is treated as a generic key and made the search key a 12 byte key followed by an asterick.
| Code: |
----+----1--
ABCDEFGHIJKL*
|
| Quote: |
Does anyone know of another way to handle a HEX key ending with X'5C'?
|
You can try to use SORT to extract the desired records with the following condition.
| Code: |
//SYSIN DD *
SORT FIELDS=COPY
INCLUDE COND=(01,24,CH,GE,C'62116CF0F0F3C4000007505C',AND,
01,24,CH,LE,C'62116CF0F0F3C4000007505C')
/*
|
Hope this helps...
Cheers
Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu |
|
| Back to top |
|
|
xcal
Beginner
Joined: 08 Aug 2007
Posts: 4
Topics: 1
|
| Posted: Fri Aug 10, 2007 12:34 pm Post subject: |
|
|
| Thanks Kolusu. |
|
| Back to top |
|
|
|
|
|
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
