It's all about the answers!

Ask a question

importing code to RTC EE, PDS arrangment

will mattar (1111) | asked Apr 04 '13, 12:39 p.m.

My question is what is the best practices for arranging my PDSs so that their corresponding zComponents make sense and function properly?

Is it best to put all COBOL into a single PDS, and if so are their size constraints?
Is it best to arrange PDS by system function? System Application?
Can we combine multiple types of objects (COBOL, BMS Maps, PL/1 etc..) in the same PDS and corresponding zComponent?

Thank you,


One answer

permanent link
Guy Slade (64158) | answered Apr 05 '13, 4:23 p.m.
Hi Will

Are we talking about before you import the COBOL source into the RTC SCM? Or are you talking about when you are building COBOL programs that are already in the RTC SCM?

If you are wondering about what to do before you import your source there really is no PDS organization required. The important thing at this stage is you understand the source code and how it relates so that when you use zImport you can place the source into zProjects and components in a way that makes some sense. An obvious example would be a separate component for copybooks.

If you are talking about what to do for building your COBOL source already in the RTC SCM .... this is an interesting question. Although where we place the source during build should be considered somewhat transient I think from a  common sense point of view considering something like putting everything in a single PDS would not be a smart thing to do. If for no other reason than the one you mentioned...size. There are no real restrictions on what you can do, as you are probably aware, the way to specify what PDS source is placed is by associating a folder to a Data Set Definition. And the way to specify what PDS's build output is place is by specifying Data Set Definitions (DSD) in the Translator definitions used to build the source. You can have the same DSD associated to all your folders, you can have a different one used for every folder. Most examples I have seen tend to be in the middle..... folders containing copybooks tend to be placed in one PDS and the COBOL source for a System Application tend to be placed into a different PDS. Being able to group source in a well thought out and logical way ... i.e splitting a System Application into a number of logical functional areas and then housing each one of these in their own component and mapped to their own source PDS library makes sense. Looking at how developers tend to work can help.. i.e teamA generally works in this area of the product and teamB works in a different area and both make use of a common set of copybooks. So having 3 components that map this out makes sense.

Also, yes you can combine multiple types of objects as long as the PDS physical characteristics will map to all of them. For example a PDS with an lrcl = 80 can be used for COBOL and PLI source but I think from memory, a BMS map needs a larger lrcl so you can't use the same PDS for BMS maps (could be wrong but you get the idea I hope).

I'd love to see other RTC user community members chime in here with examples of how they have been working.....


Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.