How to read through a PDS from Cobol 1

[MrStar]

Does anybody know how I can read through all the members a PDS, and retreive then membername and some information from each member ?
An example with JCL would be nice.

I have coded Cobol for about 20 years, but newer managed to figure out how to do the above. I have always found an other solution such as converting PDS to a sequential dataset via IBM utilities.

 

[CraigJConrad]

MrStar,

Is your entire source available somewhere? It looks as if the posting of the code is incomplete. I think it would be a useful example for some things I'd like to try sometime.

Thanks, Craig

 

[MrStar]

Give me your e-mail and I will send it to you.
I have tried several times to upload it to Tek-tips, but every time it fails.

 

[CraigJConrad]

MrStar,

Thanks so much. My email is cjcTek-Tips@ConradHome.net.
I appreciate your assistance!

Craig

 

[TonyJollans]

MrStar,

For the record, I believe there is a limit to the size of a post here. I don't know what it is, but you may be able to do better if you copy your code to an editor that strips trailing spaces from records - just a thought, it does depend how much of it is missing.

Enjoy,
Tony

------------------------------------------------------------------------------------------------------
We want to help you; help us to do it by reading FAQ222-2244 before you ask a question.

 

[slade]

Just a side note. If anyone plans to use this approach, i.e. open/process/close a number of members in a PDS, the repeated open/close of the members can add substantial overhead to the process.

I encountered a pgm that processed 3-4 million records for 20,000 accounts. The logic was such that the file was opened/closed twice for each account, totaling 80,000 open/closes for each run.

The pgm was rewritten to eliminate 90%+ of the o/cs. Before the change the pgm ran for 3 hrs; after the change it ran in 10mins! Granted, you won’t normally encounter 20,000 members in a PDS, but it’s something to keep in mind.

Regards, Jack.

 

[solanki123]

Helo MrStar,
I am very hungry of this solution.
Could you please send that cobol program as well as Jcl to me.My id is visa_solanki@yahoo.com


Thanks and Regards,
Visaram Solanki

 

[CraigJConrad]

My thanks to MrStar for this code. I have a task in mind (been on my to-do list for awhile), and I think the framework of this code will be a big boost.

I appreciate the time in putting it together and sharing it!

Craig

 

[HUJ]

Helo MrStar,
Could you please send that cobol program as well as Jcl to me.My email address is hu_jun_1@yahoo.com.cn
thank you

HU JUN

 

[gazolba]

This is possible and I have done it many times. It depends on what Cobol you are using. I used IBM mainframe Cobol. As best as I can remember (It was many years since I have used Covbol - am amazed anyone is still using it). You code the FD as 'undefined' and specify no member name in the JCL. Then when you open the dataset you get the directory. You have to skip thru some pointers to get to the member names and other data. I'm sure I have an old listing of this stashed away somewhere. You can read the entire directory. You cannot, however, open each member and read it. You can only open one member at a time when you specify the member name in your JCL. You can do that in PL/1 which is a MUCH superior language to Cobol in every respect. Shame it never caught on.

 

[MrStar]

Hi Gazolba
It is not corrrect what you wrote. It is possible to read each member without specifying each member. This is what my program does.
And yes, Cobol is still used around the world. I heard somewhere that about 80% of the code in the world is in Cobol. I dont know if it's true.

 

[webrabbit]

I like Pl/I, but it has a lot more overhead than COBOL. Plus, COBOL is designed for business, and implements business rules much more elegantly than PL/I. Just one example: try to express currency as a binary field in PL/I.

 

[gazolba]

Hi Mr Star,
It was certainly not possible to read all the members of a PDS when I last wrote Cobol which I think was VS Cobol II.
If you have to call a routine to do it, you are not really doing it in Cobol. We used Assembler to do those kind of things. Its a lot easier and more efficient. I don't know what new PDS accessing facilities Cobol has now but it seems to me that reading PDS members is not a suitable job for Cobol.

As for PL/1, I coded in Cobol for about 10 years and PL/1 for about 10 years doing exclusively business applications and PL/1 was far superior. Cobol does not 'implement any business rule' as far as I know, nor does any programming language.

 

[TonyJollans]

Hi webrabbit,

I hesitate to get involved in discussions of the merits of one language over another. Although it didn't end up that way (and probably never could) Cobol was originally designed with the business person in mind and the idea that non-programmers could use it, whilst PL/1 was more of a programmer's language (and, as a programmer, I generally prefer PL/1).

I wouldn't seriously disagree with you about Cobol's capacity for the expression of business rules, BUT business has no concerns over binary (or any other type) of data; business cares about the currency and not the programmatic representation of it.

Enjoy,
Tony

--------------------------------------------------------------------------------------------
We want to help you; help us to do it by reading this: Before you ask a question.

 

[gazolba]

Both Cobol and PL/1 were meant for general business type applications programming. IBM wanted PL/1 to become the successor to Cobol but it could never make inroads into the vast Cobol universe. PL/1 can do anything Cobol can do, and much more, with the possible exception of SEARCH, SEARCH ALL and SORT - which are probably the most useful verbs in Cobol.
The great things about PL/1, which Cobol programmers can only dream about, are local variables and dynamic allocation of memory. Also 'x := 1' is so much more sensible than 'Move 1 to X'.
All my origionbal post meant to say was that PL/1 could easily handle the PDS processing problem whereas Cobol has to jump through hoops to do it.

 

[webrabbit]

COBOL was not designed for non-programmers to use, but for non-programmers to read. In my first job, I had one program which was modified frequently and submitted to the users to vet. It would have been even easier for the users if COBOL had had the EVALUATE verb at that time.

Not many people appreciate the full usefulness of the EVALUATE verb. It is not just an implementation of the CASE structure, but a multidimensional truth-table compiler. Truth tables are the most common description of business rules.

I always implemnt currency in data bases as binary in COBOL. It takes up much less space, which is still important. For instance, a sales history by SKU, store, and date may have many millions of entries. Saving a few bytes per record results in reducing the file size by a few gigabytes.

 

[TonyJollans]

Hi webrabbit,

Storing a value (be it currency or anything else) in binary has nothing directly to do with Cobol (never mind Business). Even if you implement a system in Cobol, you cannot be sure that other languages won't be used to process the data in the future. I think all languages can handle binary data and your enormous saving is in space on whatever medium in whatever (language-independent) environment you happen to be.





Enjoy,
Tony

--------------------------------------------------------------------------------------------
We want to help you; help us to do it by reading this: Before you ask a question.