Right of the bat, that process works at the granularity of an entire member. With XEDIT it's easy to have multiple people testing changes to the same member with a merge process that's normally very quick.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Jon Perryman <[email protected]> Sent: Tuesday, September 9, 2025 3:13 PM To: [email protected] <[email protected]> Subject: Product build using CMS vs TSO Was: Pipelines = you don't understand z/OS External Message: Use Caution On Mon, 8 Sep 2025 18:39:32 -0400, Phil Smith III <[email protected]> wrote: >You saying "TSO PIPEs aren't useful" suggests to me that you haven't really >seen the power of Pipes. I was equally perplexed when you said "but for a complex process like building a product I found it far easier to handle in CMS." implies you might not understand the power of ISPF REXX. I found creating the build product simple in TSO. Here are the phases using ISPF REXX. Which phases can you simplify in CMS REXX using PIPEs? >Yes, COBOL might (sometimes!) be faster to run -- >but is (generally) slower to develop, debug, maintain. People's time is >expensive... I never suggested nor hinted at COBOL. The build process is very simple and efficient in ISPF REXX. How can CMS REXX and PIPEs make it simpler or make it less code? Here is how I handled each phase of the build process in ISPF REXX: 1. Each developer chooses how they want to work using STANDARD ISPF. no code required. E.g. One of multiple ways to edit is ISPF 2 but certainly not the only method: PROJECT ===> AAO21 GROUP ===> user_prefix ===> CURRENT ===> ORIG_REL TYPE ===> ASM INITIAL MACRO ===> EDITMAC No code here because PROJECT, GROUP and TYPE are an ISPF standard. AAO21 is AAO product and 21 is the release. Group is the key where ORIG_REL is the FMID version of the members, CURRENT contains members from their last PTF released to customers and user_prefix is your personal libraries that will only contain members you have checked out. Type is ASM, JCL, JCLIN or any library used by the product. EDITMAC's only job is to checkout (lock) a member that you want to edit. Most edit methods can support IMACRO EDITMAC in some way. 2. Member checkout (EDITMAC): A member can only be modified by 1 person. When you edit the member and the member was not in the user_prefix library, then a checkout occurs. EDITMAC reads the member record from the product control dataset (library), verifies the member is not checked out by another user and then updates the member record. Only a few lines of code. 3. Product control dataset (library): No code. Each member represents the same member name in various TYPE datasets (e.g. ASM, JCL, JCLIN, ...). Each record contains: TYPE, current PTF ID, checkout user, JCLIN association and .... This is solely for performance so that the entire dataset is not read. There are alternatives (e.g. VSAM, DB2, implement your own indexing USING LMPUT & LMGET). I used ISPF edit to maintain these records but any method works as long as it includes serialization (enqueue). 4. Alloc user_prefix libraries: User_prefix libraries are empty except when members are checked out. Using listcat to get the list of CURRENT libraries, allocate each user library (using LISTDSI & ALLOC) with 10% of CURRENT's used space because this is far more than needed. Very little code 5. Compile & link: Write a REXX that compiles TYPE (e.g. ASM) that support compile. Link modules using JCLIN. Add an option to submit a batch job in case someone wants to compile several members. Not much code here. 6. Create new PTF ID and assign APAR: Ask developer for APAR or NEW. If new APAR, display new APAR screen and create APAR using file tailoring. Reads last PTF id, increments and updates. Display PTF screen and create ++PTF using file tailoring. Not much code here. 7. Promote modules to PTF: If TYPE library does not exist for the PTF, then alloc it. LMMCOPY member to PTF library. Change the checkout user_prefix in the member record to the PTF ID because it no longer belongs to the user. Delete anything related to the member from the user_prefix libraries. Realize that a PTF is functionally a user. Not much code here. 8. Build PTF: Use listcat to get list of PTF libraries. Compile members that support compile. Append each member in all libraries (except load libraries and compile libraries e.g. ASM) as ++TYPE to the ++PTF. More code than other processes but still not much code. 9. Commit PTF to CURRENT: LMMCOPY members of libraries to the CURRENT libraries. Using JCLIN, link affected load modules. Clear the checked out user from each member record. 10. If multiple platforms (zVSE, zVM, zLinux, ...) need to be supported, then add a few lines to compile and package for those platforms. --------------------------------------------------------------------------- Because of ISPF standard flexibility, most phases of the build processes could function both as an ISPF command and ISPF EDIT. They seamlessly functioned from ISPF edit, command line, list of files, REFLIST, member list and more. Each developer can easily tailor their environment according to their needs because of ISPF design. For me, it was commands such as E TYPE(member) to edit the member. Not much code and very effective for me. For others, it was REFLIST, ISPF 3.4, ISPF 2, custom REXX or ???. The build process is efficient for the developer and the CPU because of ISPF REXX. Some people say ISPF is menu driven but they ignore menus are for easing new staff into the product or finding seldom used functionality such as creating the new release. It's very common for the command line to be used for commands instead of menu selection. Let's not ignore all the other z/OS bells and whistles not mentioned here such as automatic backup and migration. When a product release goes into maintenance only mode, I don't worry about my libraries because they automatically move to cheaper media such as tape that automatically restores to disk if I need it again. What am I missing about CMS REXX and PIPEs improving the build process for a product? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
