0

I want to get the maximum key value in between the given range.(Maximum value between 1000 to 2000). Below My VSAM data.

Key

1001

1002

1003

2001

2006

Now I have moved 1999 to key and start search

START VSAM-KSDS-FILE    KEY IS > 1999

Then I have read next record but I am getting 2001 But I want the maximum key value of 1003.(Maximum value between 1000 to 2000)

How can I get this value?

Community
  • 1
  • 1
karthi
  • 1,059
  • 3
  • 10
  • 21
  • The maximum value you show is 2006. Is 1003 a typo, or can you clarify how that qualifies as the maximum? The traditional way to do this is to "know" the highest value (control-record or control-file). Enterprise COBOL (fortunately) does not have "read previous". It would be absurd to read all the data or to attempt to find the last key, or attempt multiple convoluted STARTs. – Bill Woodger Jul 07 '15 at 08:35
  • I Want the maximum key value between 1000 to 2000. – karthi Jul 07 '15 at 08:45
  • Is there any possibility to read backwards in VSAM? – karthi Jul 07 '15 at 10:05
  • "Enterprise COBOL (fortunately) does not have "read previous"" so that's a No. People do enough strange things without read backwards being allowed, so imagine the chaos if/when that arrives. For your task, someone didn't do the design correctly. Just cast magic words and hope that a bag of fakery then gets you out of the fix. Oh. You can do it in Assembler, of course. – Bill Woodger Jul 07 '15 at 10:22

2 Answers2

2

Before we got READ PREVIOUS in RM/Cobol (which was a god-send), we used a 'reverse key' for this sort of thing.

For example, let's assume that your key is only 4 digits. You would have a REV-KEY field in the record which was equal to 10000 minus the real key. Define that as an alternate key and you can start on that key with REV-KEY set to 10000 - 1999.

Of course, if you don't have the ability to change the structure of the file, then there's no way to do it without READ PREVIOUS.

DuncanKinnear
  • 4,563
  • 2
  • 34
  • 65
  • I suppose if we'd had it when I was a trainee, I'd not be concerned with it. Perhaps I would. Problem is, people would use it. The same people who do file-matching by reading one file as the driver, then read the entire second file in case they get a match. For the second record on the driver, they close and reopen the second file. Continue *ad nauseum*. An alternate index that gets any more than minimal use in a Mainframe batch job is a resource hog. On the Mainframe, people pay for resources. – Bill Woodger Jul 07 '15 at 22:16
-1

It saves a lot of time if you already know something rather than having to go searching for it.

So, don't lose the value, keep it, and you never have to search for it.

Have a "Control Record" within the file, which contains the value you want, or have a separate "Control File" contain the Control Record.

You do check that all your data is for the same date, don't you? The "Business Date" or "Data Date"? So if using the Control File, that file will of course contain the Business/Data Date which you will match to your existing Business/Data Date on your KSDS.

No-one on a Mainframe just assumes that everything is correct. Do they?

Bill Woodger
  • 12,968
  • 4
  • 38
  • 47