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
