> From: [email protected] > Hmm, I never use option 2 so I didn't even know it would concatenate the various "group" level datasets together. > Been working on z/OS since the MVS XA days and never needed that capability. I wonder if very many people use it.
In my experience not many people use the concatenation capabilities of regular ISPF. This is a great shame because it can be REALLY useful. However, regular ISPF panels have a lot of restrictions that severely limit the usefulness of concatenating libraries. For example, the libraries being concatenated can only have 3 qualifiers, all of the qualifiers must be the same (except for the middle one), and no matter which library an edited member exists in it always get copied to and saved in the first library. This means someone could concatenate 'MY.COBOL.SOURCE' and 'TEST.COBOL.SOURCE' and 'PROD.COBOL.SOURCE'. But they couldn't concatenate 'MY.COBOL.COPYBOOK' because the last qualifier (COPYBOOK) doesn't match the other qualifiers (i.e. SOURCE). In addition, even if they could concatenate it they wouldn't want to because if they edited a member in COPYBOOK it would be copied to and saved in SOURCE. The restrictions just mentioned do not exist in SimpList. However, regular ISPF panels and SimpList do share the restriction that a maximum of 4 classic libraries can be concatenated. Even so, the elimination of the other restrictions makes working with concatenated libraries much more useful. For example, someone could concatenate 'MY.COBOL' and 'PROJECT6.TEST.COBOL' and 'PROD.GROUP1.COB.SOURCE' and 'PROD.ABC.ALL.COB.COPYBOOK'. The resulting member list displays all 4 libraries merged into one, which has numerous advantages. Right off the bat someone can see which library each member exists in, and therefore knows which members are being worked on (which helps with avoiding clobbering other people's changes). All of the required members can be worked on from a single member list, which avoids having to keep swapping between multiple split screens. Searches and changes can be conducted across all of the merged libraries at once. If a member is changed, it can automatically be copied to and saved in library 1 (just like regular ISPF), or saved in the original library (which you would definitely want to do if the libraries contain different types of members). If a member that's being browsed or edited references another member in any of the merged libraries (e.g. a COBOL program references a copybook), the referenced member can be opened for edit or browse by pointing the cursor at it. The referenced member can be opened on top of the existing member (in which case, exiting the referenced member returns to the original member) or opened as a separate split screen session (in which case, F9 can be pressed to swap back and forth between the calling and called members). These and other advantages of working with merged libraries apply to more than just COBOL. For example, ISPF dialog development can be simplified by merging REXX, panel, message, and skeleton libraries. Assembler and macro libraries can be merged, JCL proc and driver libraries can be merged, and so on. Having worked with concatenated libraries for many years I can hardly imagine what it would be like if I had to go back to not using them. Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
