Help required regarding Path File
Select messages from
# through # FAQ
[/[Print]\]

MVSFORUMS.com -> CICS and Middleware

#1: Help required regarding Path File Author: edkir98Location: Chennai PostPosted: Thu Aug 12, 2010 8:12 am
    —
Hello,
We have a huge VSAM file with 500 million records and 4 fields (say Continent, Country, Currency and Account number). A combination of continent, country, currency and account number would make the record in the VSAM file unique.

The CICS program which i write gets Continent, Country, Currency and Account as input. After recieving the input, the program checks this VSAM file with these 4 fields to see if a record is found in the VSAM file. If it is found then it does process-1. Otherwise it does process-2.

Now since the number of records in the VSAM file is huge, we would like to make this process efficient.

I created a non-unique alternate index on Continent and Country and a corresponding path file. But i am not sure how to use this path file to make the search more efficient.

Can someone help. Thanks in advance.

#2:  Author: dbzTHEdinosauerLocation: germany PostPosted: Thu Aug 12, 2010 8:34 am
    —
if the 4 fields are unique in the vsam file (should be the key, huh?)
and the 4 fields are input,
why not do a random read?

why do you need a non-unique alternate index?

#3:  Author: edkir98Location: Chennai PostPosted: Thu Aug 12, 2010 8:54 am
    —
Hi Dick, Thanks for the quick reply.

Yes i could always use a random search.
If i would declare an alternate index and a related path on Continent and country and use the path file in the program wouldnt it make the search more refined and easier?

i.e Lets say i have input as Asia, China, Yuan and 12345, cant the search be more refined to some 50 million out of the 500 million in the base cluster which have Continent as Asia and Country as China, if i would use the path file?

#4:  Author: dbzTHEdinosauerLocation: germany PostPosted: Thu Aug 12, 2010 9:02 am
    —
suggest that you read VSAM Demystified an easy to read IBM Redbook.

#5:  Author: RonBLocation: Orlando, FL PostPosted: Thu Aug 12, 2010 5:29 pm
    —
Do an internet search for the algorithms related to doing sequential searches ( n = 50 million in your case ) and the algorithms related to doing B+tree searches ( n = 500 million in your case ) and let us know which you think would be "more refined", "easier", and more "efficient", based on BEST CASE, AVERAGE, and WORST CASE scenarios.
Some Hints:
Sequential Search
B+Tree Search

#6:  Author: dbzTHEdinosauerLocation: germany PostPosted: Thu Aug 12, 2010 9:15 pm
    —
Sorry,

actually the construction of your vsam file sucks.
(apologize for the rudeness of the above statement,
though it is true - dbz 13 Aug)

after further thought, I don't think you are being honest with us about
the vsam file record.

If you are, then you could reduce the vsam file by substituting codes
which in the case of country, would allow you to refer to germany as
  • germany
  • deutschland
  • allemagne
  • etc...
instead of having multiple records for the same country in you composite vsam file.

Thru use of the codes, this would also remove 'spelling errors'.

you should have
a continent - ksds- where each continent is related to a number, howmany continents are there?
a country ksds - again, each spelling would relate to a number, again - how many countries are there?
a currency ksds - again related to a number, again how many currencies are there.

the continent number would be 2 char max (99 allows for sub-continent description)
the country number would be 3 char max
the currency number would be 3 char max.

that means your fourth vsam file would be 2+3+3+size of account number - 20 char??.

a 28 char record, with a 28 char unique key

Quote:
Yes i could always use a random search.

which would mean the i/o services reads the index and returns either the record or a 'not found' condition

Quote:
If i would declare an alternate index and a related path on Continent and country and use the path file in the program wouldnt it make the search more refined and easier?


means not only i/o service reading thru the index,
but upon return the program does a bunch (?million) read-next until the
record = key is found or the program determines that it is 'not found'.


so, as RonB suggested, it is more efficient for the the i/o service to read thru the index, than for your program to read-next.

(modified 13 aug 11:15 by dbz)



MVSFORUMS.com -> CICS and Middleware


output generated using printer-friendly topic mod. All times are GMT - 5 Hours

Page 1 of 1

Powered by phpBB © 2001, 2005 phpBB Group