On Mon, 20 May 2019 13:28:58 +0000, Sankaranarayanan, Vignesh wrote:

>... in what ways are they similar, and what ways are they different?
>Is the world better off with SMP/E-like structure for code, or is z/OS etc. 
>better off with Git-like structure?
>
I never learned Git.  I've long seen similarities and differences between
"make" and SMP/E:

Both build targets from sources and update those targets when the sources
change (and both use the term "target").

SMP/E restricts names to 8 (or 7) characters, all uppercase.  Make suffers
no such archaic restriction.

The only language processer SMP/E supports is Assembler.  Make allows
the user to define rules for processing any language.  SMP/E should do
likewise.

Make infers element types from filename extensions.  SMP/E supplies
the element type in the element MCS.  I prefer to use filenames only
for identification, not to overload then with metadata as make does.

SMP/E determines service level from PRE and SUP operands of SYSMODs;
make relies on file timestamps.  SMP/E's more orderly practice avoids a
misbehavior when a target has been built later than the timestamp of a
higher-level source.

Make has a macro facility; SMP/E has none.  That could be valuable
for global specification of a DSN HLQ.  (Use of the SYSLMOD LLQ to
select a DDDEF is a small step in that direction.)

The make product description is entirely in the makefile; SMP/E uses
two sources, the UCLIN and the JCLIN.  JCLIN seems to me to be
transitional, allowing the user to import (mostly) existing JCL rather
than needing to re-specify a product to import it to SMP/E.

SMP/E's support of UNIX files is bizarre.  The user seems required
to use GIMDTS to transform UNIX files to FB80 PDS or instream
elements, unload the PDSes with IEBCOPY to RELFILES, and package
those.  Even as IEBCOPY is the natural tool for PDSes, "pax -xpax"
is the natural for UNIX files, and preserves all the peculiar z/OS
metadata.  SMP/E should adopt pax for transfer of UNIX files rather
than the current convoluted process.

(And everything that Joel said.)

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to