Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Phil Smith III]

Peter Relson wrote:

>I on the other hand do have sympathy. A highly significant reason that

>z/OS still exists (and the same could have been said for its

>predecessors OS/390 and MVS) is because of the enormous amount of time

>and effort we have put into maintaining as much compatibility as we

>can. We do not treat incompatibility lightly. We do try to keep down

>the number of upgrade actions needed to move to a new release.

 

+1000. Nobody does compatibility like IBM, and that's A Good Thing that s 
many other vendors should learn from. Microsoft changes UI elements and 
keyboard shortcuts silently with service! And breaks myriad other things, also 
without notice.

 

IBM has been my guiding light in this regard for my 37 (gulp) years at vendors. 
When we break something, we try to do it visibly-e.g., a configuration option 
that fails at startup, rather than doing something unexpected. And it's 
documented, of course, AND in release notes.

 

Of course this is enterprise software, where folks can be expected to read 
release notes; if they don't, my sympathy is low. Consumer stuff, expectations 
are somewhat different.

 

Anyone who's dealt with the Python 2 to Python 3 mess should understand.

 

...phsiii


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Peter Relson]

That should just be made a syntax error.  I have no sympathy for the
"compatibility" argument.


I on the other hand do have sympathy. A highly significant reason that z/OS 
still exists (and the same could have been said for its predecessors OS/390 and 
MVS) is because of the enormous amount of time and effort we have put into 
maintaining as much compatibility as we can. We do not treat incompatibility 
lightly. We do try to keep down the number of upgrade actions needed to move to 
a new release.

For your concrete suggestions about improving the documentation (such as your 
examples), please make them via the appropriate feedback mechanisms, not via a 
post on IBM-MAIN.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Paul Gilmartin]

On Wed, 11 Oct 2023 15:44:39 +, Peter Relson wrote:
>
>As it happens, the offending sentence had already been removed from the 3.1 
>book. Since the thread started before those books were generally available to 
>be looked at, it's not surprising that that was not realized.
> 
I see that.  Thanks.

I searched the 3.1 JCL Ref. for "unpredictable".  I consider some remaining
instances inexcusable, such as:
Do not code TIME=0 on a JOB statement. The results are unpredictable.

That should just be made a syntax error.  I have no sympathy for the
"compatibility" argument.

If there is some uncertainty due to discretization, that should be mentioned
concisely.

As for nested symbols, there should be an edg case example, such as:
//  SET X=FOO,Y-BAR
//  SET  A=B
The equivalent JCL would be elaborated as:
//  SET  AFOO=BBAR

If I guessed wrong, that's a fortiori reason for clarification.

And, abridged from the Ref."
//EXAMPLE   PROC SYM1='Whats up, 
Doc?',SYM2=(DEF),SYM3=&&TEMP1,
//   SYM4='&TEMP2',SYM5=&TEMP3,TEMP3=TEMPNAME,
//   SYM6=
...
//DD3   DD   DSN=,UNIT=SYSDA,SPACE=(TRK,(1,1))
//DD4   DD   DSN=,UNIT=SYSDA,SPACE=(TRK,(1,1))
//DD5   DD   DSN=,UNIT=SYSALLDA,SPACE=(TRK,(1,1))
...
The equivalent JCL produced by the substitution, when the procedure is 
expanded, is:
...
//DD4   DD   DSN=,UNIT=SYSDA,SPACE=(TRK,(1,1))
(It fails to show the equivalent JCL for DD5.)

It would be a valuable clarification to state that DD4 names a
temporary data set.  I think.

• Symbols on JCL records are treated as if they resolved simultaneously. 

I'll assume the contrapositive:  Symbols on different JCL records
(It says "record", not "statement") are resolved sequentially.
So SYM6 should receive the value "TEMPNAME".

-- 
Thanks,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Peter Relson]

Paul G wrote

I fear "unpredictable" is too often the writers' excuse when they don't know
the answer to a request for clarification and can't find out.


I don't think you will find that that is true in z/OS books. Writers do not 
make up usage of that word. They are asked to do so because the developers have 
told them that it is the situation. It might be that "style guidelines" suggest 
using "unpredictable" rather than something like "not defined". If anything, 
blame us the design/development folks, not the writers.

It is not worth the cost to try to create an exhaustive list of what happens 
(or could happen) if you were to do something that you're told not to do. It is 
rarely worth the cost even to create examples of what could happen. It can well 
be worth the cost to try to create a list of the things that you are allowed to 
do.

As it happens, the offending sentence had already been removed from the 3.1 
book. Since the thread started before those books were generally available to 
be looked at, it's not surprising that that was not realized.

If that had not happened, we would have investigated whether there were cases 
that we could document for which it would be OK to have JCL symbols used to 
define other JCL symbols.

I expect that somewhere the books describe what you get if you use a symbol and 
that symbol is not yet defined (I do not know exactly where that is). There are 
probably subtleties about "not yet defined" for cases where you (in effect) 
"undefine" a symbol (which I think you can do). It might be that the 
no-substitution-done case is "not defined now", covering both "not yet defined" 
and also "no longer defined".

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Michael Oujesky]

Processing date from control card input is endemic to the financial 
industry, not just banks.


I believe it stems from the fact that "daily" processing occurs after midnight,

Michael


At 11:08 AM 10/8/2023, Paul Gilmartin wrote:


On Sat, 7 Oct 2023 22:30:52 +0200, Radoslaw Skorupka wrote:

>To be honest I consider date-related variables as pooor when
>compared to batch scheduler features, especially ControlM (it is not
>advertisement, just opinion).
>
You worked for a bank.

I had a co-worker who had worked for a bank.  He told me that
certain reports were legally required on certain dates.  Failure
to meet a production window would not avoid a penalty.

To avoid the risk, he read the report date from a control record rather
than using the system date facility.  The readers never knew.

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Paul Gilmartin]

On Sat, 7 Oct 2023 22:30:52 +0200, Radoslaw Skorupka wrote:

>To be honest I consider date-related variables as pooor when
>compared to batch scheduler features, especially ControlM (it is not
>advertisement, just opinion).
>
You worked for a bank.

I had a co-worker who had worked for a bank.  He told me that
certain reports were legally required on certain dates.  Failure
to meet a production window would not avoid a penalty.

To avoid the risk, he read the report date from a control record rather
than using the system date facility.  The readers never knew.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Paul Gilmartin]

On Sat, 7 Oct 2023 18:42:42 +, Farley, Peter wrote:

>I’ll admit I have NOT used symbol substitution in the “name” part (left of the 
>“=”) at all, only on the right (value) side, so the true answer is “I don’t 
>know”.  Never had a reason to use substitution in the “name” part.
>
However infrequently it's done, it should be documented and behave as 
documented.
If the effect is to "Determine Equivalent JCL" then perform the operation, no 
more
explanation is needed.

I find 16 uses of "unpredictable" in the JCL Ref., with the caveat:
Chapter 4. Syntax of parameters 
Note: You must follow the syntax rules in coding job control statements to 
achieve
specific results. If you do not follow the rules, you may get error 
messages or
unpredictable results. IBM does not support the use of statements or parame

I fear "unpredictable" is too often the writers' excuseo when they don't know
the answer to a request for clarification and can't find out.

>I also have never had reason/need to use JCL continuation for the “value” part 
>of a symbol definition, all my symbols have fairly short values.
>
My  concern about continuation relates not only to SET/PROC/EXEC, but to
any JCL statement where symbol substitution might change the content of
column 73.  Since symbols can't be continued (bad design), I couldn't simply
generate a long command string and break it into 71-column chunks.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Paul Gilmartin]

On Sat, 7 Oct 2023 13:10:36 -0500, Michael Oujesky wrote:

>Dynamic symbols (date/time) can be evaluated at different points in
>time during conversion, so if used multiple time in the JCL, they can
>resolve to different values.   My ROT was to never use a dynamic
>symbol more that once in coding and where it was needed multiple
>time, set it to my own date/time variable and then use that in the
>multiple instances it was needed.
> 
But the hazard exists for any two or more symbols whose values must
be coordinated such as DATE and TIME.  This could be done with a
single symbol containing both date and time with guaranteed block-
concurrent access.  I know of none such.

POSIX rename() and PDS STOW Replace provide the effect of
block-concurrent access to the content of a file.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Radoslaw Skorupka]

To be honest I consider date-related variables as pooor when 
compared to batch scheduler features, especially ControlM (it is not 
advertisement, just opinion).

Justification:
More possibilities of when the date should be resolved. For example it 
can be "accounting date" - job should prepare report for 21-sept, but 
due to some events it was submitted day after. Etc. etc.
Date calculations. It can be "day before". Not just 21-1 (what happens 
on 1st?), but real date for "yesterday".
Summary of days (i.e. daily datasets concatenation) for each month. 
Despite it is 30 or 31 day. Or 28. Or 29.

...and more.


--
Radoslaw Skorupka
Lodz, Poland



W dniu 07.10.2023 o 20:42, Farley, Peter pisze:

I’ll admit I have NOT used symbol substitution in the “name” part (left of the 
“=”) at all, only on the right (value) side, so the true answer is “I don’t 
know”.  Never had a reason to use substitution in the “name” part.

I personally haven’t had reason to use dynamic system symbols that could change 
at midnight in production JCL, only in test JCL I was running during normal 
daytime business hours, and usually only the “date” symbols like LYYMMDD, not 
the “time” ones.  If I had to use them in production JCL I would probably use 
Michael Oujesky’s solution of assigning that system dynamic symbol once to a 
private symbol name and then use the private symbol name everywhere else it is 
needed.

I also have never had reason/need to use JCL continuation for the “value” part 
of a symbol definition, all my symbols have fairly short values.  I use a LOT 
of symbols in my test JCL for easy flexibility of running tests varying 
critical application parameter values and dataset names, with multiple symbols 
for each different part of the standardly-named files.  I can see that a symbol 
definition using multiple other symbols for the value could exceed column 71, 
but I haven’t had that need.

When I get a chance I will try the new feedback process.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Saturday, October 7, 2023 1:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E 
needed for installs?]


On Sat, 7 Oct 2023 09:41:56 -0700, Ed Jaffe wrote:




On 9/20/2023 8:23 AM, Farley, Peter wrote:

... JCL symbols as part of the definition of other JCL symbols works flawlessly 
every time.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Farley, Peter]

I’ll admit I have NOT used symbol substitution in the “name” part (left of the 
“=”) at all, only on the right (value) side, so the true answer is “I don’t 
know”.  Never had a reason to use substitution in the “name” part.

I personally haven’t had reason to use dynamic system symbols that could change 
at midnight in production JCL, only in test JCL I was running during normal 
daytime business hours, and usually only the “date” symbols like LYYMMDD, not 
the “time” ones.  If I had to use them in production JCL I would probably use 
Michael Oujesky’s solution of assigning that system dynamic symbol once to a 
private symbol name and then use the private symbol name everywhere else it is 
needed.

I also have never had reason/need to use JCL continuation for the “value” part 
of a symbol definition, all my symbols have fairly short values.  I use a LOT 
of symbols in my test JCL for easy flexibility of running tests varying 
critical application parameter values and dataset names, with multiple symbols 
for each different part of the standardly-named files.  I can see that a symbol 
definition using multiple other symbols for the value could exceed column 71, 
but I haven’t had that need.

When I get a chance I will try the new feedback process.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Saturday, October 7, 2023 1:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E 
needed for installs?]


On Sat, 7 Oct 2023 09:41:56 -0700, Ed Jaffe wrote:



>On 9/20/2023 8:23 AM, Farley, Peter wrote:

>> ... JCL symbols as part of the definition of other JCL symbols works 
>> flawlessly every time.

>

Is this true alike for substitution both in the name (left of the "=")

and in the value (right of the "=")?



In 
<https://www.ibm.com/docs/en/zos/3.1.0?topic=symbols-determining-equivalent-jcl>

Substitute all symbols.

...

Symbols on JCL records are treated as if they resolved simultaneously.



Peter Relson (IIRC) answered my question hers that near midnight 

and  might be resolved at a time when their values are inconsistent.

This requires some explanation of "simultaneously".  There ought to be

a lock to prevent this.  (REXX does it right.)



And some explanation of the effect of resolving a symbol changing the

content of column 72 from blank to non-blank or vice-versa.





>Agreed 100%. We use that feature all the time for in-house JCL and also

>for distributed product JCL.

>

>This seems like a golden opportunity to test the IBM Documentation

>Feedback process.

>

>Give it a try and let us know if you actually get a response...

>

Yes.



--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Michael Oujesky]

Dynamic symbols (date/time) can be evaluated at different points in 
time during conversion, so if used multiple time in the JCL, they can 
resolve to different values.   My ROT was to never use a dynamic 
symbol more that once in coding and where it was needed multiple 
time, set it to my own date/time variable and then use that in the 
multiple instances it was needed.


Michael

At 12:45 PM 10/7/2023, Paul Gilmartin wrote:


On Sat, 7 Oct 2023 09:41:56 -0700, Ed Jaffe wrote:

>On 9/20/2023 8:23 AM, Farley, Peter wrote:
>> ... JCL symbols as part of the definition of other JCL symbols 
works flawlessly every time.

>
Is this true alike for substitution both in the name (left of the "=")
and in the value (right of the "=")?

In 


Substitute all symbols.
...
Symbols on JCL records are treated as if they resolved simultaneously.

Peter Relson (IIRC) answered my question hers that near midnight 
and  might be resolved at a time when their values are inconsistent.
This requires some explanation of "simultaneously".  There ought to be
a lock to prevent this.  (REXX does it right.)

And some explanation of the effect of resolving a symbol changing the
content of column 72 from blank to non-blank or vice-versa.


>Agreed 100%. We use that feature all the time for in-house JCL and also
>for distributed product JCL.
>
>This seems like a golden opportunity to test the IBM Documentation
>Feedback process.
>
>Give it a try and let us know if you actually get a response...
>
Yes.

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Paul Gilmartin]

On Sat, 7 Oct 2023 09:41:56 -0700, Ed Jaffe wrote:

>On 9/20/2023 8:23 AM, Farley, Peter wrote:
>> ... JCL symbols as part of the definition of other JCL symbols works 
>> flawlessly every time. 
>
Is this true alike for substitution both in the name (left of the "=")
and in the value (right of the "=")?

In 

Substitute all symbols.
...
Symbols on JCL records are treated as if they resolved simultaneously.

Peter Relson (IIRC) answered my question hers that near midnight 
and  might be resolved at a time when their values are inconsistent.
This requires some explanation of "simultaneously".  There ought to be
a lock to prevent this.  (REXX does it right.)

And some explanation of the effect of resolving a symbol changing the
content of column 72 from blank to non-blank or vice-versa.


>Agreed 100%. We use that feature all the time for in-house JCL and also
>for distributed product JCL.
>
>This seems like a golden opportunity to test the IBM Documentation
>Feedback process.
>
>Give it a try and let us know if you actually get a response...
>
Yes.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Ed Jaffe]

On 9/20/2023 8:23 AM, Farley, Peter wrote:

I believe that statement in the JCL Reference is in error and needs to be deleted 
or at the very least completely rewritten.  My quite substantial experience using 
this technique over the last 10-15 years is that using JCL symbols as part of the 
definition of other JCL symbols works flawlessly every time.  There is no 
unpredictability.  If the symbol used to define one symbol isn’t already defined, 
you get the literal “” value that you coded as part of the definition.  
This works for both SET and PROC and EXEC statements, without any failures or 
unpredictability that I have ever seen.  The resulting VALUE of that symbol may 
cause errors, but there is no unpredictability to the symbol definition process.


Agreed 100%. We use that feature all the time for in-house JCL and also 
for distributed product JCL.


This seems like a golden opportunity to test the IBM Documentation 
Feedback process.


Give it a try and let us know if you actually get a response...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Phil Smith III]

Farley, Peter wrote:
>I believe that statement in the JCL Reference is in error and needs to
>be deleted or at the very least completely rewritten. My quite
>substantial experience using this technique over the last 10-15 years
>is that using JCL symbols as part of the definition of other JCL
>symbols works flawlessly every time. There is no unpredictability. If
>the symbol used to define one symbol isn't already defined, you get
>the literal "" value that you coded as part of the definition.
>This works for both SET and PROC and EXEC statements, without any
>failures or unpredictability that I have ever seen. The resulting
>VALUE of that symbol may cause errors, but there is no
>unpredictability to the symbol definition process.

>I cannot imagine any circumstance in which the result of defining one
>JCL symbol using another JCL symbol would ever be unpredictable.

>If there is any possible case where the result is unpredictable, IBM
>should be required to specify the circumstances and explain why.

I'd bet large coin that what this really means is "If you do this, you're 
likely to confuse yourself". As indeed you COULD-anyone who's gotten sloppy 
with Rexx stemmed variables (where this kind of usage is more common) has been 
burned that way! Of course in the examples Peter Hannigan provided, you're 
*trying* to play those games, so I think it's as safe as anything.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Paul Gilmartin]

Thanks for changing the Subject: as the topic drifted.

On Wed, 20 Sep 2023 15:23:31 +, Farley, Peter wrote:

>I believe that statement in the JCL Reference is in error and needs to be 
>deleted or at the very least completely rewritten.  My quite substantial 
>experience using this technique over the last 10-15 years is that using JCL 
>symbols as part of the definition of other JCL symbols works flawlessly every 
>time.  ...
>
The Ref. is inconsistent in its terminology:

The SET statement contains one or more parameters:
symbolic-parameter=value[,symbolic parameter=value]...

clearly in:
>On Wed, 20 Sep 2023 04:12:20 +, Peter Hannigan wrote:
>>...
>>// SET A=' '
>>
Peter H. was specifying a symbol within a "symbolic-parameter",
not within the "value"
>
>
>  - Do not specify JCL symbols within other JCL symbols. The results
>can be unpredictable, especially if the imbedded JCL symbol is
>not previously defined.
>
For clarity, that should have said "symbolic-parameter", which
I assume was within its intended meaning, not simply "JCL
symbols within"

Regardless, I agree with both Peter F. and Peter H. that either
construct works provided that all  symbols are resolved according
to "Determining equivalent JCL" which should be cited here
unless it can be assumed to apply consistently throughout the Ref.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Farley, Peter]

I believe that statement in the JCL Reference is in error and needs to be 
deleted or at the very least completely rewritten.  My quite substantial 
experience using this technique over the last 10-15 years is that using JCL 
symbols as part of the definition of other JCL symbols works flawlessly every 
time.  There is no unpredictability.  If the symbol used to define one symbol 
isn’t already defined, you get the literal “” value that you coded as part 
of the definition.  This works for both SET and PROC and EXEC statements, 
without any failures or unpredictability that I have ever seen.  The resulting 
VALUE of that symbol may cause errors, but there is no unpredictability to the 
symbol definition process.

I cannot imagine any circumstance in which the result of defining one JCL 
symbol using another JCL symbol would ever be unpredictable.

If there is any possible case where the result is unpredictable, IBM should be 
required to specify the circumstances and explain why.

Peter

P.S. – I will add that all of my experience using symbols to define other 
symbols also uses EXPORT SYMLIST=* as a standard part of JCL and 
SYMLIST=JCLONLY for in-stream DD’s with symbols to be substituted.

From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Wednesday, September 20, 2023 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is SMP/E needed for installs?


On Wed, 20 Sep 2023 04:12:20 +, Peter Hannigan wrote:

>...

>// SET A=' '

>

<https://www.ibm.com/docs/en/zos/2.5.0?topic=symbols-defining-nullifying-jcl>

  - Do not specify JCL symbols within other JCL symbols. The results

can be unpredictable, especially if the imbedded JCL symbol is

not previously defined.



Damn feckless IBM!  Don't call a construct "unpredictable".  Either

report it as a JCL error or specify the effect in the Ref.



But ISVs should avoid "unpredictable" constructs in customer-facing code.



--



This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Phil Smith III]

Peter Hannigan wrote:
>If the length of the prefix can be limited to seven characters then
>this can be used:


Wow. It took me 10+ minutes of staring at this to puzzle it out. Too clever by 
half for me (and that's not meant as an insult). 

After much discussion, we've concluded that nobody is going to load our stuff 
to the "root" on a real system, and if they do, then they're going to be an 
SMP/E jock already. So while I love this suggestion and will look at other ways 
to use it, I think I'm just going to put a comment in the common member that 
does the SETs saying "You can't have a null HLQ/RPREFIX". The other places 
where the HLQ gets substituted in would have the same problem (though, yes, I 
could be clever and set them with a trailing do, but that way lies madness).

I really appreciate all the help folks have provided with this. Our 
installation is now MUCH cleaner/simpler because the edits to the actual jobs 
comprise just:

1.  JOB card (doh)
2.  JCLLIB (right below the JOB card, so easy to find)
3.  Possibly SMS changes from UNIT= and VOL=SER=



I vaguely considered changing the last one to use a variation on your approach, 
Peter, but that would have to assume (as the default does) that all the data 
sets use the same values. Again, at that point, hopefully the customer is 
sophisticated enough to deal with it; can only hold their hands so far before 
it becomes ridiculous.

If folks think I'm being silly in any of these conclusions, I'd love to hear it!

...phsiii


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Paul Gilmartin]

On Wed, 20 Sep 2023 04:12:20 +, Peter Hannigan wrote:
>...
>// SET A=' '
>

  - Do not specify JCL symbols within other JCL symbols. The results
can be unpredictable, especially if the imbedded JCL symbol is
not previously defined.

Damn feckless IBM!  Don't call a construct "unpredictable".  Either
report it as a JCL error or specify the effect in the Ref.

But ISVs should avoid "unpredictable" constructs in customer-facing code.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Peter Hannigan]

> -Original Message-
> 
> Date:Tue, 5 Sep 2023 17:34:17 -0400
> From:Phil Smith III 
> Subject: Re: Is SMP/E needed for installs?
> 
.
.
> 2.On the SMP/E RECEIVE command, I believe that in 99.44% (or higher)
> cases, an RPREFIX will be needed. And I can specify this using a variable
> (now!). In the unlikely event that no RPREFIX is needed, it appears from
> my testing that you cannot just say
>RECEIVE SYSMODS RFPREFIX() .
> or, more precisely:
>   RECEIVE SYSMODS RFPREFIX() .
> where  is null. Is that correct? I can handle this via doc and
> comments, but of course would rather not if there's a way around it.
> 

If the length of the prefix can be limited to seven characters then this can be 
used:

// SET Q=
// SET RPREFIX=
// SET RFPFXPRM=
.
.
// SET RPREFIX=prefix  When needed
.
.
// SET A=
// SET A=' '
// SET O=,RFPFXPRM=()
.
.
RECEIVE SYSMODS  .


If an eight character prefix must be allowed then use a blank as its default 
value:

// SET Q=
// SET RPREFIX=' '
// SET RFPFXPRM=
.
.
// SET RPREFIX=prefix  When needed
.
.
// SET O=,RFPFXPRM=()
.
.
RECEIVE SYSMODS  .


I've used both techniques, the second often, the first not so much.


Peter Hannigan
Kyndryl


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Andrew Rowley]

On 6/09/2023 9:39 am, Steve Thompson wrote:
But, doesn't that take a long time and burn many cycles to get it 
done? I'm only asking to verify what I have been told about z/OSMF in 
the past few weeks.


Good question. SMP/E itself doesn't have a reputation for being 
lightweight, and the z/OSMF install would avoid most of the SMP/E steps. 
Hopefully, a simple restore of a basic SMP/E environment in z/OSMF 
wouldn't be too intensive. Particularly compared to someone muddling 
through trying to understand SMP/E, re-running steps etc.


For a product install, the CPU time etc. is probably not significant 
compared to everyday workload.


--

Andrew Rowley
Black Hill Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Phil Smith III]

Andrew Rowley wrote, in part:
>IBM's answer to this would be to recommend installing using a portable
>software instance through z/OSMF.

Yep, on my future todo list, but I'm not there at this point. Nor am I 
convinced that I can require z/OSMF yet (that's probably another topic for 
another thread, which I may start).


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Steve Thompson]

But, doesn't that take a long time and burn many cycles to get it 
done? I'm only asking to verify what I have been told about 
z/OSMF in the past few weeks.


Steve Thompson

On 9/5/2023 7:23 PM, Andrew Rowley wrote:

On 6/09/2023 7:34 am, Phil Smith III wrote:
To recap, the goal here is just to make our SMP/E installation 
as easy as possible for the increasing number of customers for 
whom it seems to be a mystery. Yes, that's worrisome; no, I 
can't fix it. What I can do is try to keep them from blowing 
their fingers off as much as possible by making it as easy as 
possible.


IBM's answer to this would be to recommend installing using a 
portable software instance through z/OSMF. That will deliver 
the whole SMP/E environment pre-built, and the customer doesn't 
need to do any SMP/E for installation. They can still install 
maintenance using SMP/E, and you can be reasonably confident 
that the SMP/E environment is configured correctly so they can 
install maintenance.


There are some downsides (new stuff to learn etc.) but given 
your goal and the fact that IBM is pushing people to z/OSMF 
installation anyway, it's worth considering.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Andrew Rowley]

On 6/09/2023 7:34 am, Phil Smith III wrote:

To recap, the goal here is just to make our SMP/E installation as easy as 
possible for the increasing number of customers for whom it seems to be a 
mystery. Yes, that's worrisome; no, I can't fix it. What I can do is try to 
keep them from blowing their fingers off as much as possible by making it as 
easy as possible.


IBM's answer to this would be to recommend installing using a portable 
software instance through z/OSMF. That will deliver the whole SMP/E 
environment pre-built, and the customer doesn't need to do any SMP/E for 
installation. They can still install maintenance using SMP/E, and you 
can be reasonably confident that the SMP/E environment is configured 
correctly so they can install maintenance.


There are some downsides (new stuff to learn etc.) but given your goal 
and the fact that IBM is pushing people to z/OSMF installation anyway, 
it's worth considering.


--
Andrew Rowley
Black Hill Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Phil Smith III]

Paul Gilmartin wrote:
>Put the mainstream JCL in that same JCLLIB and invoke it with a stub/wrapper 
>INCLUDE.
>(Can INCLUDEs be nested?)
>(I've done similar with Assembler using a script to generate a SYSIN 
>consisting of only
>a single COPY statement.)

Sorry, I'm not grokking this. I have a library that includes the "real" JCL and 
the member with the SET statements. Then I put a third stub in that library 
that does an INCLUDE of both. Doesn't that stub need the same tailoring, to 
name the library? If so, what am I gaining?

>It's dismaying that JCL and many other IBM products provide no way of 
>explicitly
>asserting a default value.

I think you're agreeing with me that there's no workaround?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Paul Gilmartin]

On Tue, 5 Sep 2023 17:34:17 -0400, Phil Smith III wrote:
>...
>1. Is there a way to say "Do the INCLUDE from the same library where you 
>found this JCL?" (I expect not, because I don't think the JCL has any 
>association with that library by the time it's submitted)
>
Put the mainstream JCL in that same JCLLIB and invoke it with a stub/wrapper 
INCLUDE.
(Can INCLUDEs be nested?)
(I've done similar with Assembler using a script to generate a SYSIN consisting 
of only
a single COPY statement.)

>2. On the SMP/E RECEIVE command, I believe that in 99.44% (or higher) 
>cases, an RPREFIX will be needed. And I can specify this using a variable 
>(now!). In the unlikely event that no RPREFIX is needed, it appears from my 
>testing that you cannot just say
>   RECEIVE SYSMODS RFPREFIX() .
>or, more precisely:
>  RECEIVE SYSMODS RFPREFIX() .
>where  is null. Is that correct? I can handle this via doc and 
>comments, but of course would rather not if there's a way around it.
>
It's dismaying that JCL and many other IBM products provide no way of explicitly
asserting a default value.  Examples:

o There's mo operand of TYPRUN that asserts the default value.

o I encountered a problem with a script-generated DDDEF with
  SECONDARY(0).  It had to be 1 or greater, or the option had
  to be omitted.

o (But COBOL, OTOH, won't use SDB when the programmer omits the
  BLOCK CONTAINS clause.)

o Etc.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Phil Smith III]

Thanks to y'all helping me fumble through this, I have my SMP/E installation 
jobs working with a single INCLUDEd member that sets all the variables.

 

I think I know the answer here, having spent a while reading the docs, but I'll 
still ask about the two remaining nits:

 

1.  Is there a way to say "Do the INCLUDE from the same library where you 
found this JCL?" (I expect not, because I don't think the JCL has any 
association with that library by the time it's submitted)
2.  On the SMP/E RECEIVE command, I believe that in 99.44% (or higher) 
cases, an RPREFIX will be needed. And I can specify this using a variable 
(now!). In the unlikely event that no RPREFIX is needed, it appears from my 
testing that you cannot just say
   RECEIVE SYSMODS RFPREFIX() .
or, more precisely:
  RECEIVE SYSMODS RFPREFIX() .
where  is null. Is that correct? I can handle this via doc and 
comments, but of course would rather not if there's a way around it.

 

To recap, the goal here is just to make our SMP/E installation as easy as 
possible for the increasing number of customers for whom it seems to be a 
mystery. Yes, that's worrisome; no, I can't fix it. What I can do is try to 
keep them from blowing their fingers off as much as possible by making it as 
easy as possible.

 

Thanks,

...phsiii


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: Is SMP/E needed for installs?

[Wayne Bickerdike]

The wheel has turned full circle. When I worked at IBM UK in 1978 we had a
JOBPROC statement.

It was internal code developed by one of our systems programmers. It worked
but sometimes broke.

On Fri, Sep 1, 2023 at 4:58 AM Tom Brennan 
wrote:

> Thanks, I forgot about that.  But we may have known it at one time,
> because I "think" we coded our exit 4 conversion from PROCLIB to JCLLIB
> with that in mind.
>
> On 8/31/2023 10:50 AM, Gibney, Dave wrote:
> > EasyProclib did DD concatenations.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: Is SMP/E needed for installs?

[Paul Gilmartin]

On Thu, 31 Aug 2023 19:16:25 +, Schmitt, Michael wrote:

>It they had used DD, imagine all the customer code that would break that 
>parses JCL looking for DDs, and never expects to see a DD outside of a step. 
>...
> 
I'm unsympathetic.  Even as all the customer code that broke when PROC
parameters, IF-THEN-ELSE, SET, EXPORT, SYMBOLS=, ... were introduced.
Managers could simply instruct programmers never to do anything for
the first time.

>-Original Message-
>From:  Radoslaw Skorupka
>Sent: Thursday, August 31, 2023 1:44 PM
>
>DD is also better, because it can describe non-catalogued PDS(E)s.
>
And zFS directories.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: Is SMP/E needed for installs?

[Schmitt, Michael]

I've never coded it!

So forgot about it.


We were just happy to get JCLLIB at all, JES proclibs were a pain.  What was 
that, /*JOBPARM P=, where the concatenation could only be changed by the 
systems people, because it is was in the PROC00 member in the JES parms library?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Thursday, August 31, 2023 2:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Is SMP/E needed for installs?

Hi Michael,
What about //JOBLIB? ... That is not in any Step.

Regards,
David

On 2023-08-31 15:16, Schmitt, Michael wrote:
> It they had used DD, imagine all the customer code that would break that 
> parses JCL looking for DDs, and never expects to see a DD outside of a step. 
> And all the code that *edits* DDs would have to say "except if PROCLIB". And 
> you wouldn't be able to *have* a DD named PROCLIB. And certain code would 
> break that currently *creates* a DD named PROCLIB from the proc concatenation.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Radoslaw Skorupka
> Sent: Thursday, August 31, 2023 1:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: Is SMP/E needed for installs?
>
> W dniu 31.08.2023 o 19:48, Paul Gilmartin pisze:
>> On Thu, 31 Aug 2023 10:39:34 -0700, Tom Brennan wrote:
>>> I thought ORDER= was done because you can code more than one dataset.
>>>
>> DD concatenation should have sufficed for that.
> DD concatenation is better, because it may contain more entries. Yes,
> ORDER parameter can be continued in next line, but it is much more error
> prone than regular DD set.
> DD is also better, because it can describe non-catalogued PDS(E)s.
>
> I suspect the JCLLIB in that form was a way to force catalog as a must.
> AFAIK it was introduced in MVS 4.1 along with IF/THEN/ELSE statements.
> And TIME=NOLIMIT (not 1440).
> Or maybe it was INCLUDE?
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: Is SMP/E needed for installs?

[David Spiegel]

Hi Michael,
What about //JOBLIB? ... That is not in any Step.

Regards,
David

On 2023-08-31 15:16, Schmitt, Michael wrote:

It they had used DD, imagine all the customer code that would break that parses JCL 
looking for DDs, and never expects to see a DD outside of a step. And all the code that 
*edits* DDs would have to say "except if PROCLIB". And you wouldn't be able to 
*have* a DD named PROCLIB. And certain code would break that currently *creates* a DD 
named PROCLIB from the proc concatenation.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Thursday, August 31, 2023 1:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Is SMP/E needed for installs?

W dniu 31.08.2023 o 19:48, Paul Gilmartin pisze:

On Thu, 31 Aug 2023 10:39:34 -0700, Tom Brennan wrote:

I thought ORDER= was done because you can code more than one dataset.


DD concatenation should have sufficed for that.

DD concatenation is better, because it may contain more entries. Yes,
ORDER parameter can be continued in next line, but it is much more error
prone than regular DD set.
DD is also better, because it can describe non-catalogued PDS(E)s.

I suspect the JCLLIB in that form was a way to force catalog as a must.
AFAIK it was introduced in MVS 4.1 along with IF/THEN/ELSE statements.
And TIME=NOLIMIT (not 1440).
Or maybe it was INCLUDE?

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Paul Gilmartin]

On Thu, 31 Aug 2023 11:58:23 -0400, Phil Smith III wrote:
>...
>//SYSUT1   DD DSN=
>...

>STMT NO. MESSAGE
>   
>   6 IEFC624I INCORRECT USE OF PERIOD IN THE DSN FIELD
>I understand the latter error (because the SET didn't happen), 
>...
I could find that behavior useful.  I have at times expressed a wish
that undefined symbols be reported as JCL errors.  So I need only
follow the symbol with a period and an error will (probably) result
if undefined.  For example:
//SYSUT2  DD  DSN=,RECFM=VB

will result in a JCL error if NAME is unset, rather than naming a
temporary data set.

Are the statements numbered in the job log, or do you just need to guess?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: Is SMP/E needed for installs?

[Schmitt, Michael]

It they had used DD, imagine all the customer code that would break that parses 
JCL looking for DDs, and never expects to see a DD outside of a step. And all 
the code that *edits* DDs would have to say "except if PROCLIB". And you 
wouldn't be able to *have* a DD named PROCLIB. And certain code would break 
that currently *creates* a DD named PROCLIB from the proc concatenation.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Thursday, August 31, 2023 1:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Is SMP/E needed for installs?

W dniu 31.08.2023 o 19:48, Paul Gilmartin pisze:
> On Thu, 31 Aug 2023 10:39:34 -0700, Tom Brennan wrote:
>> I thought ORDER= was done because you can code more than one dataset.
>>
> DD concatenation should have sufficed for that.

DD concatenation is better, because it may contain more entries. Yes,
ORDER parameter can be continued in next line, but it is much more error
prone than regular DD set.
DD is also better, because it can describe non-catalogued PDS(E)s.

I suspect the JCLLIB in that form was a way to force catalog as a must.
AFAIK it was introduced in MVS 4.1 along with IF/THEN/ELSE statements.
And TIME=NOLIMIT (not 1440).
Or maybe it was INCLUDE?

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: Is SMP/E needed for installs?

[Tom Brennan]

Thanks, I forgot about that.  But we may have known it at one time, 
because I "think" we coded our exit 4 conversion from PROCLIB to JCLLIB 
with that in mind.


On 8/31/2023 10:50 AM, Gibney, Dave wrote:
EasyProclib did DD concatenations. 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: Is SMP/E needed for installs?

[Radoslaw Skorupka]

W dniu 31.08.2023 o 19:48, Paul Gilmartin pisze:

On Thu, 31 Aug 2023 10:39:34 -0700, Tom Brennan wrote:

I thought ORDER= was done because you can code more than one dataset.


DD concatenation should have sufficed for that.


DD concatenation is better, because it may contain more entries. Yes, 
ORDER parameter can be continued in next line, but it is much more error 
prone than regular DD set.

DD is also better, because it can describe non-catalogued PDS(E)s.

I suspect the JCLLIB in that form was a way to force catalog as a must.
AFAIK it was introduced in MVS 4.1 along with IF/THEN/ELSE statements. 
And TIME=NOLIMIT (not 1440).

Or maybe it was INCLUDE?

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Radoslaw Skorupka]

Wrong JCLLIB use.
JCLLIB is *not* DD name it is separate JCL statement. Like PROC, PEND, 
EXEC, JOB, etc.


What is misleading, it is *NOT* similar to JOBLIB/STEPLIB or older 
special DD names.



--
Radoslaw Skorupka
Lodz, Poland



W dniu 31.08.2023 o 17:58, Phil Smith III pisze:

Thanks to many people politely telling me, "Hey dummy, use SYMBOLS=", I have 
gotten around the must-change-many-places problem with the SMP/E jobs. Thanks!

Next, Gil suggested using an INCLUDE member, so the SETs get done exactly once, 
which I quite like. But now I'm stumped again.

Here's my trivial test job:
//TEST JOB  MSGLEVEL=(1,1),MSGCLASS=A,NOTIFY=
//*
//* THE FOLLOWING DATA SETS EXIST:
//*  PHS.PDS.JCL840(TEST) **THIS JOB
//*  PHS.PDS.JCL840(SETS) **THE INCLUDE MEMBER
//*  HUD840.VVSH84C.SMPMCS**THE INPUT DATA SET
//*  PHS840.SAMPLE.MCS**THE OUTPUT DATA SET
//*
//* PHS.PDS.JCL840(SETS) INCLUDES THE FOLLOWING LONE STATEMENT:
//*  SET  HLQ=HUD840
//*
//COPYIT   EXEC PGM=IEBCOPY
//JCLLIB   DD   DSN=PHS.PDS.JCL840,DISP=SHR
// INCLUDE MEMBER=SETS
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=
//SYSUT2   DD DSN=PHS840.SAMPLE.MCS,DISP=OLD
//SYSINDD *
 COPYGRP INDD=((SYSUT1,R)),OUTDD=SYSUT2
/*

This fails with:
STMT NO. MESSAGE
4 IEFC017I INCLUDE SETS WAS NOT FOUND
6 IEFC624I INCORRECT USE OF PERIOD IN THE DSN FIELD
I understand the latter error (because the SET didn't happen), but the first is 
baffling. Based on
https://www.ibm.com/docs/en/zos/2.1.0?topic=description-examples-include-statement
I first thought that the JCLLIB needed to *precede* the EXEC statement. That's 
sure what they show. But if I move it up one, I get:
STMT NO. MESSAGE
2 IEFC019I MISPLACED DD STATEMENT
.followed by the same two other errors.

I'm sure this is something obvious, but I've been tinkering and not getting anywhere. At 
one point I did have it complaining not about the JCLLIB (which was before the EXEC at 
that point), but rather that the "JOB HAS NO STEPS", which I don't understand 
either, but that went away with more tinkering-though nothing I did really ADDED a 
jobstep.

Any ideas?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: Is SMP/E needed for installs?

[Tom Brennan]

True, they could have done that.  They could have also used //PROCLIB 
and saved us some kludge coding :)  Unless there was some concern about 
getting sued by CA.  Oh well, it's all history now.


On 8/31/2023 10:48 AM, Paul Gilmartin wrote:

On Thu, 31 Aug 2023 10:39:34 -0700, Tom Brennan wrote:


I thought ORDER= was done because you can code more than one dataset.


DD concatenation should have sufficed for that.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: Is SMP/E needed for installs?

[Gibney, Dave]

EasyProclib did DD concatenations. IBM did a new //name JCLLIB 
ORDER=(dsn,dsn,,) JCL statement. I am only guessing that this was so that it 
was sufficiently different from the existing ISV product

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Tom Brennan
> Sent: Thursday, August 31, 2023 10:40 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: Is SMP/E needed for installs?
> 
> [EXTERNAL EMAIL]
> 
> I remember that product!  But I thought it worked with a DD, something
> like:  //PROCLIB DD DSN=TED013.PROCLIB,DISP=SHR
> 
> When JCLLIB came out, we dropped the product and wrote some code in JES2
> exit 4 to convert PROCLIB to JCLLIB so users didn't have to change their
> JCL.
> 
> I thought ORDER= was done because you can code more than one dataset.
> 
> On 8/31/2023 10:27 AM, Gibney, Dave wrote:
> > In part because that was how the EasyProclib (owned by CA at the
> time)product worked.
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> >> Behalf Of Pommier, Rex
> >> Sent: Thursday, August 31, 2023 10:20 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: [EXTERNAL] Re: Is SMP/E needed for installs?
> >>
> >> [EXTERNAL EMAIL]
> >>
> >> Yeah, I don't understand why IBM didn't just use DD card syntax instead of
> >> coming up with this.
> >>
> >> Rex
> >>
> >> -----Original Message-----
> >> From: IBM Mainframe Discussion List  On
> >> Behalf Of Phil Smith III
> >> Sent: Thursday, August 31, 2023 12:01 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: [EXTERNAL] Re: Is SMP/E needed for installs?
> >>
> >> Billy Ashton wrote:
> >>
> >>> If you want to INCLUDE a member, this is like a PROC, so you need to
> >>
> >>> have SETS in a system-defined proclib or you have to add something like
> >>
> >>> //JCLLIB ORDER=PHS.PDS.JCL840
> >>
> >>
> >>
> >> You've got me to spot what I'd just stupidly missed: I had taken the JCLLIB
> to
> >> be a DD, and it's not: it's a whole new statement. If I change it to:
> >>
> >> // JCLLIB   ORDER=PHS.PDS.JCL840
> >>
> >>
> >>
> >> It works. Well, it fails later, but the JCL works! Thanks. I knew it was
> something
> >> dumb.
> >>
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to
> >> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >> --
> >> The information contained in this message is confidential, protected from
> >> disclosure and may be legally privileged. If the reader of this message is 
> >> not
> the
> >> intended recipient or an employee or agent responsible for delivering this
> >> message to the intended recipient, you are hereby notified that any
> disclosure,
> >> distribution, copying, or any action taken or action omitted in reliance 
> >> on it,
> is
> >> strictly prohibited and may be unlawful. If you have received this
> >> communication in error, please notify us immediately by replying to this
> >> message and destroy the material in its entirety, whether in electronic or
> hard
> >> copy format. Thank you.
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: Is SMP/E needed for installs?

[Tom Brennan]

I just found some old JCL for EasyProc and sure enough, it's coded like:
//PROCLIB DD DSN=TED013.PROCLIB,DISP=SHR

... with a DD.  But that doesn't mean it went through standard DD 
allocation.  All this happened early in the JCL scanning and conversion. 
 The "DD" and maybe even the DISP=SHR was probably just for consistency.


On 8/31/2023 10:38 AM, Paul Gilmartin wrote:

On Thu, 31 Aug 2023 17:19:38 +, Pommier, Rex wrote:


Yeah, I don't understand why IBM didn't just use DD card syntax instead of 
coming up with this.


I conjecture sequence of operations.  DD statements aren't elaborated until
job initiation.  JCLLIB is needed earlier.  Isn't there a similar requirement 
for
PROCLIB?

gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: Is SMP/E needed for installs?

[Paul Gilmartin]

On Thu, 31 Aug 2023 10:39:34 -0700, Tom Brennan wrote:
>
>I thought ORDER= was done because you can code more than one dataset.
>
DD concatenation should have sufficed for that.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: Is SMP/E needed for installs?

[Steve Thompson]

I think it was because it was "stolen|borrowed" from DOS/VSE
Steve Thompson

On 8/31/2023 1:19 PM, Pommier, Rex wrote:

Yeah, I don't understand why IBM didn't just use DD card syntax instead of 
coming up with this.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Thursday, August 31, 2023 12:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Is SMP/E needed for installs?

Billy Ashton wrote:


If you want to INCLUDE a member, this is like a PROC, so you need to
have SETS in a system-defined proclib or you have to add something like
//JCLLIB ORDER=PHS.PDS.JCL840
  


You've got me to spot what I'd just stupidly missed: I had taken the JCLLIB to 
be a DD, and it's not: it's a whole new statement. If I change it to:

// JCLLIB   ORDER=PHS.PDS.JCL840

  


It works. Well, it fails later, but the JCL works! Thanks. I knew it was 
something dumb.


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
Regards,
Steve Thompson
VS Strategies LLC
Westfield IN
972-983-9430 cell

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: Is SMP/E needed for installs?

[Tom Brennan]

I remember that product!  But I thought it worked with a DD, something 
like:  //PROCLIB DD DSN=TED013.PROCLIB,DISP=SHR


When JCLLIB came out, we dropped the product and wrote some code in JES2 
exit 4 to convert PROCLIB to JCLLIB so users didn't have to change their 
JCL.


I thought ORDER= was done because you can code more than one dataset.

On 8/31/2023 10:27 AM, Gibney, Dave wrote:

In part because that was how the EasyProclib (owned by CA at the time)product 
worked.


-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of Pommier, Rex
Sent: Thursday, August 31, 2023 10:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Is SMP/E needed for installs?

[EXTERNAL EMAIL]

Yeah, I don't understand why IBM didn't just use DD card syntax instead of
coming up with this.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of Phil Smith III
Sent: Thursday, August 31, 2023 12:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Is SMP/E needed for installs?

Billy Ashton wrote:


If you want to INCLUDE a member, this is like a PROC, so you need to



have SETS in a system-defined proclib or you have to add something like



//JCLLIB ORDER=PHS.PDS.JCL840




You've got me to spot what I'd just stupidly missed: I had taken the JCLLIB to
be a DD, and it's not: it's a whole new statement. If I change it to:

// JCLLIB   ORDER=PHS.PDS.JCL840



It works. Well, it fails later, but the JCL works! Thanks. I knew it was 
something
dumb.


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
The information contained in this message is confidential, protected from
disclosure and may be legally privileged. If the reader of this message is not 
the
intended recipient or an employee or agent responsible for delivering this
message to the intended recipient, you are hereby notified that any disclosure,
distribution, copying, or any action taken or action omitted in reliance on it, 
is
strictly prohibited and may be unlawful. If you have received this
communication in error, please notify us immediately by replying to this
message and destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: Is SMP/E needed for installs?

[Paul Gilmartin]

On Thu, 31 Aug 2023 17:19:38 +, Pommier, Rex wrote:

>Yeah, I don't understand why IBM didn't just use DD card syntax instead of 
>coming up with this.
>
I conjecture sequence of operations.  DD statements aren't elaborated until
job initiation.  JCLLIB is needed earlier.  Isn't there a similar requirement 
for
PROCLIB?

gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: Is SMP/E needed for installs?

[Gibney, Dave]

In part because that was how the EasyProclib (owned by CA at the time)product 
worked.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Pommier, Rex
> Sent: Thursday, August 31, 2023 10:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: Is SMP/E needed for installs?
> 
> [EXTERNAL EMAIL]
> 
> Yeah, I don't understand why IBM didn't just use DD card syntax instead of
> coming up with this.
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Phil Smith III
> Sent: Thursday, August 31, 2023 12:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: Is SMP/E needed for installs?
> 
> Billy Ashton wrote:
> 
> >If you want to INCLUDE a member, this is like a PROC, so you need to
> 
> >have SETS in a system-defined proclib or you have to add something like
> 
> >//JCLLIB ORDER=PHS.PDS.JCL840
> 
> 
> 
> You've got me to spot what I'd just stupidly missed: I had taken the JCLLIB to
> be a DD, and it's not: it's a whole new statement. If I change it to:
> 
> // JCLLIB   ORDER=PHS.PDS.JCL840
> 
> 
> 
> It works. Well, it fails later, but the JCL works! Thanks. I knew it was 
> something
> dumb.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> The information contained in this message is confidential, protected from
> disclosure and may be legally privileged. If the reader of this message is 
> not the
> intended recipient or an employee or agent responsible for delivering this
> message to the intended recipient, you are hereby notified that any 
> disclosure,
> distribution, copying, or any action taken or action omitted in reliance on 
> it, is
> strictly prohibited and may be unlawful. If you have received this
> communication in error, please notify us immediately by replying to this
> message and destroy the material in its entirety, whether in electronic or 
> hard
> copy format. Thank you.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] Re: Is SMP/E needed for installs?

[Pommier, Rex]

Yeah, I don't understand why IBM didn't just use DD card syntax instead of 
coming up with this.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Thursday, August 31, 2023 12:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Is SMP/E needed for installs?

Billy Ashton wrote:

>If you want to INCLUDE a member, this is like a PROC, so you need to

>have SETS in a system-defined proclib or you have to add something like

>//JCLLIB ORDER=PHS.PDS.JCL840

 

You've got me to spot what I'd just stupidly missed: I had taken the JCLLIB to 
be a DD, and it's not: it's a whole new statement. If I change it to:

// JCLLIB   ORDER=PHS.PDS.JCL840

 

It works. Well, it fails later, but the JCL works! Thanks. I knew it was 
something dumb.


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Phil Smith III]

Billy Ashton wrote:

>If you want to INCLUDE a member, this is like a PROC, so you need to

>have SETS in a system-defined proclib or you have to add something like

>//JCLLIB ORDER=PHS.PDS.JCL840

 

You've got me to spot what I'd just stupidly missed: I had taken the JCLLIB to 
be a DD, and it's not: it's a whole new statement. If I change it to:

// JCLLIB   ORDER=PHS.PDS.JCL840

 

It works. Well, it fails later, but the JCL works! Thanks. I knew it was 
something dumb.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Billy Ashton]

If you want to INCLUDE a member, this is like a PROC, so you need to 
have SETS in a system-defined proclib or you have to add something like

//JCLLIB ORDER=PHS.PDS.JCL840

and I would probably move the INCLUDE up to where you explain what is in 
the SETS member, to make it clearer.


Billy

Thank you and best regards,
Billy Ashton


-- Original Message --

From "Phil Smith III" 

To IBM-MAIN@listserv.ua.edu
Date 8/31/2023 11:58:23 AM
Subject Re: Is SMP/E needed for installs?


Thanks to many people politely telling me, "Hey dummy, use SYMBOLS=", I have 
gotten around the must-change-many-places problem with the SMP/E jobs. Thanks!

Next, Gil suggested using an INCLUDE member, so the SETs get done exactly once, 
which I quite like. But now I'm stumped again.

Here's my trivial test job:
//TEST JOB  MSGLEVEL=(1,1),MSGCLASS=A,NOTIFY=
//*
//* THE FOLLOWING DATA SETS EXIST:
//*  PHS.PDS.JCL840(TEST) **THIS JOB
//*  PHS.PDS.JCL840(SETS) **THE INCLUDE MEMBER
//*  HUD840.VVSH84C.SMPMCS**THE INPUT DATA SET
//*  PHS840.SAMPLE.MCS**THE OUTPUT DATA SET
//*
//* PHS.PDS.JCL840(SETS) INCLUDES THE FOLLOWING LONE STATEMENT:
//*  SET  HLQ=HUD840
//*
//COPYIT   EXEC PGM=IEBCOPY
//JCLLIB   DD   DSN=PHS.PDS.JCL840,DISP=SHR
// INCLUDE MEMBER=SETS
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=
//SYSUT2   DD DSN=PHS840.SAMPLE.MCS,DISP=OLD
//SYSINDD *
COPYGRP INDD=((SYSUT1,R)),OUTDD=SYSUT2
/*

This fails with:
STMT NO. MESSAGE
   4 IEFC017I INCLUDE SETS WAS NOT FOUND
   6 IEFC624I INCORRECT USE OF PERIOD IN THE DSN FIELD
I understand the latter error (because the SET didn't happen), but the first is 
baffling. Based on
https://www.ibm.com/docs/en/zos/2.1.0?topic=description-examples-include-statement
I first thought that the JCLLIB needed to *precede* the EXEC statement. That's 
sure what they show. But if I move it up one, I get:
STMT NO. MESSAGE
   2 IEFC019I MISPLACED DD STATEMENT
.followed by the same two other errors.

I'm sure this is something obvious, but I've been tinkering and not getting anywhere. At 
one point I did have it complaining not about the JCLLIB (which was before the EXEC at 
that point), but rather that the "JOB HAS NO STEPS", which I don't understand 
either, but that went away with more tinkering-though nothing I did really ADDED a 
jobstep.

Any ideas?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Phil Smith III]

Thanks to many people politely telling me, "Hey dummy, use SYMBOLS=", I have 
gotten around the must-change-many-places problem with the SMP/E jobs. Thanks!

Next, Gil suggested using an INCLUDE member, so the SETs get done exactly once, 
which I quite like. But now I'm stumped again.

Here's my trivial test job:
//TEST JOB  MSGLEVEL=(1,1),MSGCLASS=A,NOTIFY=
//*
//* THE FOLLOWING DATA SETS EXIST:
//*  PHS.PDS.JCL840(TEST) **THIS JOB
//*  PHS.PDS.JCL840(SETS) **THE INCLUDE MEMBER
//*  HUD840.VVSH84C.SMPMCS**THE INPUT DATA SET
//*  PHS840.SAMPLE.MCS**THE OUTPUT DATA SET
//*
//* PHS.PDS.JCL840(SETS) INCLUDES THE FOLLOWING LONE STATEMENT:
//*  SET  HLQ=HUD840
//*
//COPYIT   EXEC PGM=IEBCOPY
//JCLLIB   DD   DSN=PHS.PDS.JCL840,DISP=SHR
// INCLUDE MEMBER=SETS
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=
//SYSUT2   DD DSN=PHS840.SAMPLE.MCS,DISP=OLD
//SYSINDD *
COPYGRP INDD=((SYSUT1,R)),OUTDD=SYSUT2
/*

This fails with:
STMT NO. MESSAGE
   4 IEFC017I INCLUDE SETS WAS NOT FOUND
   6 IEFC624I INCORRECT USE OF PERIOD IN THE DSN FIELD
I understand the latter error (because the SET didn't happen), but the first is 
baffling. Based on 
https://www.ibm.com/docs/en/zos/2.1.0?topic=description-examples-include-statement
I first thought that the JCLLIB needed to *precede* the EXEC statement. That's 
sure what they show. But if I move it up one, I get:
STMT NO. MESSAGE
   2 IEFC019I MISPLACED DD STATEMENT
.followed by the same two other errors.

I'm sure this is something obvious, but I've been tinkering and not getting 
anywhere. At one point I did have it complaining not about the JCLLIB (which 
was before the EXEC at that point), but rather that the "JOB HAS NO STEPS", 
which I don't understand either, but that went away with more tinkering-though 
nothing I did really ADDED a jobstep.

Any ideas?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Jon Perryman]

On Saturday, August 26, 2023 at 11:17:39 AM PDT, Phil Smith III 
 wrote:

> I'm not really going to tell a customer, "I'm sorry, you're clearly not up to 
> the job
> of installing this product. Who else there knows more than you do?" so I'm 
> not 
> sure what your real-world point is-IOW, what different action you're 
> suggesting.

The customer isn't being rude and they deserve to be educated in a polite way. 
You get them to come to the realization on their own by asking them questions 
about planning, recovery and other system critical information. More often than 
not, these people are trying to learn, be independent and prove themselves but 
they don't know what they don't know. Your questions will open the door for 
them to ask intelligent questions from their lead. A good lead will recognize 
they did not educate this person on their policies and strategies.

> PSWI? Pharmacy Society of Wisconsin?

PSWI (Portable Software Instance) that has been mentioned a few times in this 
thread. It's the first time I heard about it too and I don't know anything 
about it. If I understand it correctly, it's IBM's new alternative product 
installer that guides a user thru the complete install, setup and configuration 
process. I suspect that it includes SMP/e steps. I would need to see it but I'm 
leery that it will cause people to ignore recovery that needs to be planned 
during installation of products. 

>>You say EDIT CHANGE ALL instances is causing customers grief. Do you
> Again, don't disagree that they don't understand, but??

If a customer is complaining about changing the JCL, then they are complaining 
that it's tedious. While they are right, we also know that they are ignoring 
the planning and company policies. They can easily create an edit exec with all 
the change commands.

> But if I make the changes (via automation) and it screws up, it's my fault. 
> If I gave them something that won't run as provided, and 
> they make changes and it screws up, it's their fault. This matters.

What makes you think you screwed up? This is z/OS with all it's nuances. 
Automation can only get the customer in the ball park but their company 
policies dictate what they must change by hand. Do certain files require SYS1? 
How about impact of recovery? What about disaster recovery? How do they manage 
SMP/e CSIs so that libraries remain consistent. This isn't VM or Linux where 
everything is consistent. As a z/OS product developer, you can't ask questions 
to cover every situation. VM and Linux are limited to 1 system z where as z/OS 
sysplex can encompass 32 system z. 

> When they do get it wrong, SMP/E errors are usually incomprehensible. 
> I've said this repeatedly; are some of my posts not getting through? I see 
> them.

I stopped watching the list for a while so I probably missed them. If by SMP/e 
errors, you mean SMP/e messages, then is the SMP/e message manual not helpful? 
Are the actions you need to take unclear in the message manual? Is the 
terminology a problem? Is it a problem finding utility output in the job? Are 
the errors reported by the customer to you or are they problems with SMP/e 
statements?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Phil Smith III]

Jon Perryman wrote:

>Sorry, I should have been clear that "we" refers to product

>developers. After 40 years, the SMP/e install jobs haven't

>significantly changed to make things automatically change. We have the

>tools, but we choose to have people modify the JCL even today. We

>don't want customers to automate the process.

 

>Customers shouldn't automate these tasks but not having these skills

>tells us they should not be installing z/OS because they don't have

>experience with z/OS planning, recovery and other required skills.

>Simply put they need guidance because automating the installation

>ignores things they don't understand.

 

>The SMP/e install jobs are the easy part. Customers who get confused

>at this stage don't know their company z/OS strategy and are a danger.

>It's been many years since my last z/OS install but understanding and

>setting the strategy many times required changes to the install jobs.

>Target & dist datasets and CSI's have an impact on recovery, disaster

>recovery and much more. If someone is confused during install, then

>they were overwhelmed during planning.

 

I don't disagree, but I'm not really going to tell a customer, "I'm sorry, 
you're clearly not up to the job of installing this product. Who else there 
knows more than you do?" so I'm not sure what your real-world point is-IOW, 
what different action you're suggesting.

 

>It's absurd to say updating jobs automatically creates a maze for the

>customer. CA has successfully used it for many years and IBM has PSWI.

>I think they put you into edit of each job that you submit. From my

>perspective, this encourages the uninitiated to submit the job without

>reviewing the job. They have a false sense of reality because they are

>not spending time changing the JCL.

 

PSWI? Pharmacy Society of Wisconsin?

 

CA has built essentially a whole product for product installation and 
maintenance. They have (or at least had) the manpower to do that. I don't.

 

>You say EDIT CHANGE ALL instances is causing customers grief. Do you

>think these people understand their companies z/OS strategy, planning,

>recovery and more? SMP/e is not the point of grief. z/OS is so stable,

>many customers don't consider the impact of not choosing wisely during

>install on when it goes live.

 

Again, don't disagree that they don't understand, but??

 

>Just write a REXX exec that updates every JCL because customer coding

>accomplishes the same results. In both cases, the customers is going

>to blindly submit the job with the false impression you made the right

>choices for their environment.

 

But if I make the changes (via automation) and it screws up, it's my fault. If 
I gave them something that won't run as provided, and they make changes and it 
screws up, it's their fault. This matters.

 

>What SMP/e error handling are you recommending? Everything I'm hearing

>is confusion and annoyance about changing all occurrences in JCL. This

>has nothing to do with SMP/e.

 

When they do get it wrong, SMP/E errors are usually incomprehensible. I've said 
this repeatedly; are some of my posts not getting through? I see them.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Jon Perryman]

> On Friday, August 25, 2023 at 01:41:17 PM PDT, Phil Smith III 
>  wrote:

>> Jon Perryman wrote:
>> Do you think we can't write rexx, use ISPF JCL tailoring, ISPF edit 
>> macros or the many other tools that everyone else uses to tailor JCL?
> Not sure who "we" is. If you mean customers

Sorry, I should have been clear that "we" refers to product developers. After 
40 years, the SMP/e install jobs haven't significantly changed to make things 
automatically change. We have the tools, but we choose to have people modify 
the JCL even today. We don't want customers to automate the process.

>  I know from experience that many of "you" cannot do many of those things, or 
> have trouble with it.

Customers shouldn't automate these tasks but not having these skills tells us 
they should not be installing z/OS because they don't have experience with z/OS 
planning, recovery and other required skills. Simply put they need guidance 
because automating the installation ignores things they don't understand. 

> Even if "you" can, then having the instructions say "Update these SET 
> statements 
> but also make the same changes in a bunch of other places" feels like amateur 
> hour and confuses customers.

The SMP/e install jobs are the easy part. Customers who get confused at this 
stage don't know their company z/OS strategy and are a danger. It's been many 
years since my last z/OS install but understanding and setting the strategy 
many times required changes to the install jobs. Target & dist datasets and 
CSI's have an impact on recovery, disaster recovery and much more. If someone 
is confused during install, then they were overwhelmed during planning.

> We are the vendor. We're dealing with our customers. Giving them a program 
> that updates the jobs automatically leads down a twisty maze of 
> "Where are the jobs they're updating?" and "Where do they put the Rexx 
> program?" 
> and such that's at least as bad as the original problem. It's quite amazing 
> how little many customers know.

It's absurd to say updating jobs automatically creates a maze for the customer. 
CA has successfully used it for many years and IBM has PSWI. I think they put 
you into edit of each job that you submit. From my perspective, this encourages 
the uninitiated to submit the job without reviewing the job. They have a false 
sense of reality because they are not spending time changing the JCL.  

>> The bigger question is if using edit change commands causes this much
>> grief, have you considered the implications of how you plan to
>> maintain products?
> Don't understand this question. We give them SMP/E update packages that apply 
> with another job.

You say EDIT CHANGE ALL instances is causing customers grief. Do you think 
these people understand their companies z/OS strategy, planning, recovery and 
more? SMP/e is not the point of grief. z/OS is so stable, many customers don't 
consider the impact of not choosing wisely during install on when it goes live. 

> Anyway, when I get a chance, I'll look at the SYMBOLS= thing, 
> which will apparently solve our immediate problem. 

Just write a REXX exec that updates every JCL because customer coding 
accomplishes the same results. In both cases, the customers is going to blindly 
submit the job with the false impression you made the right choices for their 
environment. 

> I'd still suggest that a wee bit of effort in SMP/E error handling might be a 
> good investment.

What SMP/e error handling are you recommending? Everything I'm hearing is 
confusion and annoyance about changing all occurrences in JCL. This has nothing 
to do with SMP/e.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Paul Gilmartin]

On Fri, 25 Aug 2023 16:40:57 -0400, Phil Smith III wrote:
>
>>install JCL? Do you think we can't write rexx, use ISPF JCL tailoring,
>
>Not sure who "we" is. If you mean customers, then no, I know from experience 
>that many of "you" cannot do many of those things, or have trouble with it. 
>Even if "you" can, then having the instructions say "Update these SET 
>statements but also make the same changes in a bunch of other places" feels 
>like amateur hour and confuses customers.
>
Don't disparage; celebrate diversity.  Alas, in a diverse universe, regardless 
what
tool you select, you will find a subset of prospective customers who don't
understand it, or resent it.


>We are the vendor. We're dealing with our customers. Giving them a program 
>that updates the jobs automatically leads down a twisty maze of "Where are the 
>jobs they're updating?" and "Where do they put the Rexx program?" and such 
>that's at least as bad as the original problem. It's quite amazing how little 
>many customers know.
>
The JCL can reside in the same FB 80 library as the tools to tailor it.  Alas, 
you
will encounter some prospective customer sites with "standards" that JCL and
REXX must *never* reside in the same library.
(Ob five monkeys parable)

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Phil Smith III]

Jon Perryman wrote:

>Does anyone believe that symbols is causing the problem with SMP/e

>install JCL? Do you think we can't write rexx, use ISPF JCL tailoring,

>ISPF edit macros or the many other tools that everyone else uses to

>tailor JCL?

 

Not sure who "we" is. If you mean customers, then no, I know from experience 
that many of "you" cannot do many of those things, or have trouble with it. 
Even if "you" can, then having the instructions say "Update these SET 
statements but also make the same changes in a bunch of other places" feels 
like amateur hour and confuses customers.

 

>If simplifying the install process is so vital, then contact the

>vendors. I can only speak for myself but I don't feel asking you to

>spend 10 extra minutes to customize the install jobs is asking too

>much to guarantee you at least looked at the JCL and possibly realize

>that we did not make the correct choice for your environment. Do you

>think that in 40 years we couldn't come up with a completely automated

>install that fills in the blanks?

 

We are the vendor. We're dealing with our customers. Giving them a program that 
updates the jobs automatically leads down a twisty maze of "Where are the jobs 
they're updating?" and "Where do they put the Rexx program?" and such that's at 
least as bad as the original problem. It's quite amazing how little many 
customers know.

 

>The bigger question is if using edit change commands causes this much

>grief, have you considered the implications of how you plan to

>maintain products?

 

Don't understand this question. We give them SMP/E update packages that apply 
with another job.

 

Anyway, when I get a chance, I'll look at the SYMBOLS= thing, which will 
apparently solve our immediate problem. I'd still suggest that a wee bit of 
effort in SMP/E error handling might be a good investment.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Paul Gilmartin]

On Fri, 25 Aug 2023 18:49:49 +, Jon Perryman wrote:
>
>Does anyone believe that symbols is causing the problem with SMP/e install 
>JCL? Do you think we can't write rexx, use ISPF JCL tailoring, ISPF edit 
>macros or the many other tools that everyone else uses to tailor JCL?
> 
I believe that symbols don't cause a problem but, if used effectively, 
facilitate a solution.
But the process should be accessible with least effort to the greatest part of
the user base.

As I wrote previously, I once supplied an elaborate Edit macro in REXX to tailor
JCL including in streamdata.  My intent was that once configured by the user
that macro could be used to tailor subsequent install and service jobs.  I made
extensive use of SOURCELIND() and ADDRESS ISREDIT to spare the
user of dealing with REXX quoting rules.

I was dismayed when I asked one tester for feedback and she said she preferred
to Edit those jobs individually, by hand.  I felt that process was tedious,
repetitive without being repeatable, thus error prone.  I had failed.

>The bigger question is if using edit change commands causes this much grief, 
>have you considered the implications of how you plan to maintain products?
>
???
The Edit macro I described was equally applicable to installation and service 
jobs.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Jon Perryman]

 > On Friday, August 25, 2023 at 08:58:51 AM PDT, Paul Gilmartin wrote:
>> On Fri, 25 Aug 2023 10:15:59 -0400, David Spiegel wrote:
>> Hi Phil,
>> You said: "...The SYMBOLS= stuff might help here ..."
>> "might"??? -- No! ... "will"
> Your approach was similar to mine.  We agree; we must be right.
> Phil suspected problems with instream SYMBOLS-.  I envision a couple.

Does anyone believe that symbols is causing the problem with SMP/e install JCL? 
Do you think we can't write rexx, use ISPF JCL tailoring, ISPF edit macros or 
the many other tools that everyone else uses to tailor JCL?

If simplifying the install process is so vital, then contact the vendors. I can 
only speak for myself but I don't feel asking you to spend 10 extra minutes to 
customize the install jobs is asking too much to guarantee you at least looked 
at the JCL and possibly realize that we did not make the correct choice for 
your environment. Do you think that in 40 years we couldn't come up with a 
completely automated install that fills in the blanks?

The bigger question is if using edit change commands causes this much grief, 
have you considered the implications of how you plan to maintain products?


On Friday, August 25, 2023 at 08:58:51 AM PDT, Paul Gilmartin 
<042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:  
 
 On Fri, 25 Aug 2023 10:15:59 -0400, David Spiegel wrote:

>Hi Phil,
>You said: "...The SYMBOLS= stuff might help here ..."
>"might"??? -- No! ... "will"
>
Your approach was similar to mine.  We agree; we must be right.

Phil suspected problems with instream SYMBOLS-.  I envision a couple.

Ampersand pairs are not collapsed.  That behavior suits Jonathan Scott.
I'm less enthusiastic.  It makes it tricky to escape evaluation of symbols,
and deviates from general MVS convention.

Column alignment is preserved, like ISPF convention.  This is valuable
to preserve column 72, but could be undesirable if it changes the
length of spans of blanks in quoted strings.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Kurt Quackenbush]

> Is there a demo Portable Software Instance that could used to try out the 
> Z/OSMF stuff, for example a HelloWorld program

Absolutely!  Go to this page and find the "Try it" tab.  There you'll find 
links to where you can download a sample Portable Software Instance (PSWI) for 
a small fictitious software product, and to a set of tutorial videos that lead 
you through the process of installing the sample PSWI.
https://www.ibm.com/support/z-content-solutions/serverpac-install-zosmf/

Kurt Quackenbush
IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com

Chuck Norris never uses CHECK when he applies PTFs.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Colin Paice]

Kurt,
Is there a demo Portable Software Instance that could used to try out the
Z/OSMF stuff, for example a HelloWorld program
Colin

On Thu, 24 Aug 2023 at 21:47, Kurt Quackenbush  wrote:

> > Yes. As I wrote before, there's way too much "take this job
> and find the 27 places that say XYZZY and change them to the right HLQ."
> instead of "Run it with these variables set as follows". This makes
> creating and documenting SMP/E installs a lot more work than they should
> need to be.
>
> Yup, there's often lots of JCL samples to be massaged to perform an SMP/E
> install.  Create CSIs, allocate target and dlib data sets, update DDDEF
> entries, ...  Which is one of the reasons why z/OSMF Software Management
> and Portable Software Instances exist.  Any provider (not just IBM) can
> create a Portable Software Instance containing their software product using
> z/OSMF and distribute it to their clients, and the clients can install the
> software contained in the Portable Software Instance using z/OSMF.  No JCL
> massaging required.
>
> Kurt Quackenbush
> IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com
>
> Chuck Norris never uses CHECK when he applies PTFs.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Paul Gilmartin]

On Fri, 25 Aug 2023 10:15:59 -0400, David Spiegel wrote:

>Hi Phil,
>You said: "...The SYMBOLS= stuff might help here ..."
>"might"??? -- No! ... "will"
>
Your approach was similar to mine.  We agree; we must be right.

Phil suspected problems with instream SYMBOLS-.  I envision a couple.

Ampersand pairs are not collapsed.  That behavior suits Jonathan Scott.
I'm less enthusiastic.  It makes it tricky to escape evaluation of symbols,
and deviates from general MVS convention.

Column alignment is preserved, like ISPF convention.  This is valuable
to preserve column 72, but could be undesirable if it changes the
length of spans of blanks in quoted strings.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[David Spiegel]

Hi Phil,
You said: "...The SYMBOLS= stuff might help here ..."
"might"??? -- No! ... "will"

Here is another one you might like. (I use it to rename Cataloged 
Procedures during software upgrades.)

//  EXPORT SYMLIST=*
// SET DSN=my.PROCLIB
// SET VOLUME=xx
// SET MEM=member,NEW=member$,BKP=member@
//STEP001 EXEC PGM=IEHPROGM
//SYSPRINT DD SYSOUT=*
//DF0910   DD DISP=SHR,UNIT=3390,VOL=SER=
//SYSIN    DD *,SYMBOLS=JCLONLY
  SCRATCH MEMBER=,   X
DSNAME=,    X
VOL=3390=
//STEP002 EXEC PGM=IEHPROGM
//SYSPRINT DD SYSOUT=*
//DF0910   DD DISP=SHR,UNIT=3390,VOL=SER=
//SYSIN    DD *,SYMBOLS=JCLONLY
   RENAME MEMBER=,   X
NEWNAME=,   X
DSNAME=,    X
VOL=3390=
   RENAME MEMBER=,   X
NEWNAME=,   X
DSNAME=,    X
VOL=3390=

Regards,
David

On 2023-08-25 09:57, Phil Smith III wrote:

Gil wrote:

Is he too sharp tobe wrong?

Of course not. Why would you say that? I just meant that he was explicit about 
it, had used variables/symbols wherever possible, couldn't get them to work in 
this case.


What's he mean by "not just the single SET statement for each."?
It appears as if one SET can't govern multiple applied occurrences.
In what language is that true?  Did it antedate "DD *,SYMBOLS=JCLONLY"?

It means that you set the variable and use it and it *doesn't get substituted* 
in these cases. So the job fails with
INVALID DATA SET 

And yes, this most certainly predates z/OS 2.1. The SYMBOLS= stuff might help 
here; will tinker, thanks! (Yes, you mentioned it before, but I didn't quite 
take it in.)


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Phil Smith III]

David Spiegel wrote, in part:
>You said: "... as literal is never valid in those places, ..."
>You've made an incorrect assumption.

No, we've made an incorrect observation, or one that is no longer 
correct.thanks! You and Gil (and others) have pointed me in a new direction, 
which I will explore. This has been an irritation.

FWIW, no customer has said "Why aren't you doing.", so I suspect this is not 
well-understood usage in general. Either that or they're just laughing quietly 
at us :)


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Phil Smith III]

Gil wrote:
> Is he too sharp tobe wrong?
Of course not. Why would you say that? I just meant that he was explicit about 
it, had used variables/symbols wherever possible, couldn't get them to work in 
this case.

>What's he mean by "not just the single SET statement for each."?
>It appears as if one SET can't govern multiple applied occurrences.
>In what language is that true?  Did it antedate "DD *,SYMBOLS=JCLONLY"?
It means that you set the variable and use it and it *doesn't get substituted* 
in these cases. So the job fails with 
INVALID DATA SET 

And yes, this most certainly predates z/OS 2.1. The SYMBOLS= stuff might help 
here; will tinker, thanks! (Yes, you mentioned it before, but I didn't quite 
take it in.)


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Seymour J Metz]

> "take this job and find the 27 places that say XYZZY and change them to the 
> right HLQ."

The // SET XYZZY= statement addresses your 27 places issue. Are you asking for 
a symbol in the CSI itself rather than in the job?

> Consider installing products on other operating systems:

What other systems?

> you run the installer, and either it asks where you want stuff or
> it goes in the current directory (or subdirectories thereof).

Maybe in [PC|MS]-DOS. In most package managers the package metadata tell the 
installer what goes where. That's still true for the installers in ArcaOS, 
openSUSE and windows; I'd be very surprised if it wasn't still true for, e.g., 
Debian, RedHat.

Yesd, you can choose to distribute things as a tarball, but then your talking 
about not using the OS supported method.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Thursday, August 24, 2023 3:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is SMP/E needed for installs?

Shmuel wrote, in part:
>Symbols?

Yes. As I wrote before, there's way too much "take this job and find 
the 27 places that say XYZZY and change them to the right HLQ." instead of "Run 
it with these variables set as follows". This makes creating and documenting 
SMP/E installs a lot more work than they should need to be.

Consider installing products on other operating systems: you run the installer, 
and either it asks where you want stuff or it goes in the current directory (or 
subdirectories thereof). With SMP/E, you have to tell it many, many times, and 
(in my experience, which is admittedly quite limited) in subtly different ways: 
some places you need one level of HLQ and others you need more.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Seymour J Metz]

> There are places in SMP/E jobs that can't use symbols. 

What does that refer to? Are you saying that you want to be able to use a 
symbol in DDDEF and have it resolved dynamically each time SMP looks up the 
ddname in subsequent jobs?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Thursday, August 24, 2023 5:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is SMP/E needed for installs?

Gil wrote:
>I introduced "symbols".  Shmuel may have reintroduced it.  Are we thinking of 
>the same

>JCL SET?  Where is its behavior inconsistent?

It's not SET that's inconsistent, it's support for it in SMP/E. There are 
places in SMP/E jobs that can't use symbols. So you can't just have a chunk at 
the top that job where you fill in values-you have to tour the job and fix it 
27 times (OK, not 27, that's just a number I made up).

When I deliver the product to the customers, I'd like them to be able to just 
change stuff in ONE place per job. Otherwise they can (AND DO) miss a few, 
leading to hilarity.






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Seymour J Metz]

> Another thing ... Do you remember IPOUPDTE?

"The utility you are about to see is true; the name has been changed to protect 
the innocent." - Jack Webb, Dragnet.

Isn't it still there with CPP instead of IPO?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Spiegel [0468385049d1-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, August 24, 2023 5:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is SMP/E needed for installs?

Hi Phil,
I beg to differ.
You can use SET at the top of every Job to set ALL variables (as my
previous email said).
Can you please give me an example of what you're saying.

Another thing ... Do you remember IPOUPDTE? (It was a batch "editor" to
change all of the HLQ from ABC to DEF. This could be used instead of the
SET.)

Regards,
David


On 2023-08-24 17:02, Phil Smith III wrote:
> Gil wrote:
>> I introduced "symbols".  Shmuel may have reintroduced it.  Are we thinking 
>> of the same
>> JCL SET?  Where is its behavior inconsistent?
> It's not SET that's inconsistent, it's support for it in SMP/E. There are 
> places in SMP/E jobs that can't use symbols. So you can't just have a chunk 
> at the top that job where you fill in values-you have to tour the job and fix 
> it 27 times (OK, not 27, that's just a number I made up).
>
> When I deliver the product to the customers, I'd like them to be able to just 
> change stuff in ONE place per job. Otherwise they can (AND DO) miss a few, 
> leading to hilarity.
>
>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Seymour J Metz]

> He also noted this:

When? For decades there was no symbol substitution for instream data, but that 
hasn't been the case for a long time. Still, the rules are a bit clumsy.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Thursday, August 24, 2023 6:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is SMP/E needed for installs?

Gil wrote:
>I'm ignorant, or at best outdated.  I haven't known of use of symbols by SMP/E.
>But are there instances where the same  would need to appear in
>one instream data set where it should be evaluated and in another where it
>must not, regardless of  //name DD DATA,SYMBOLS=...?  Cite detailed
>example, please.

I mean things like the RFPREFIX value on a RECEIVE command, which apparently 
cannot be  but must specify the data set prefix of the RELFILEs. Same 
for the value for a PATH on a DDDEF.

>There are ways. however cumbersome, to escape symbol evaluation in
>instream data sets.

Well, maybe; I didn't write this stuff but the guy who did was pretty sharp, 
and couldn't figure out ways around the above. He also noted this:
//****NOTE*** Some references to variable values are in records
//*   provided as part of SYSIN DD *, and thus cannot be
//*   filled in using JCL variables ( et al.). Thus
//*   in this job, you must replace all references to
//*   !hlq!, !unit!, and !volser!, not just the single
//*   SET statement for each.

Maybe there's a clever way around that? It's referring to things like:
//SYSINDD *
  DEFINE CLUSTER(+
   NAME(!hlq!.GLOBAL.CSI)+
   VOLUMES(!volser!) +
   CYLINDERS(20 10)  +
   FREESPACE(2 2)+
   KEYS(24 0)+
   RECORDSIZE(24 143)+
   SHAREOPTIONS(2 3) +
   ) +
  DATA ( +
   NAME(!hlq!.GLOBAL.CSI.DATA)   +
   CONTROLINTERVALSIZE(8192) +


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Paul Gilmartin]

On Thu, 24 Aug 2023 18:45:23 -0400, Phil Smith III wrote:
>
>Well, maybe; I didn't write this stuff but the guy who did was pretty sharp, 
>and couldn't figure out ways around the above. He also noted this:
>
Is he too sharp tobe wrong?

>//****NOTE*** Some references to variable values are in records
>//*   provided as part of SYSIN DD *, and thus cannot be
>//*   filled in using JCL variables ( et al.). Thus
>//*   in this job, you must replace all references to
>//*   !hlq!, !unit!, and !volser!, not just the single
>//*   SET statement for each.
>
What's he mean by "not just the single SET statement for each."?
It appears as if one SET can't govern multiple applied occurrences.
In what language is that true?  Did it antedate "DD *,SYMBOLS=JCLONLY"?

>Maybe there's a clever way around that? It's referring to things like:
>
Can't it be refactored as:
//  EXPORT SYMLIST=*
//  SET HLQ=MYHLQ
//  SET VOLSER=MYVOL
//  SET UNIT=SYSALLDA
(All sucn might appear in a reusable JCLLIB member.  Then:
>//SYSINDD *,SYMBOLS=JCLONLY
>  DEFINE CLUSTER(   +
>   NAME()   +
>   VOLUMES()+
>   CYLINDERS(20 10) +
>   FREESPACE(2 2)   +
>   KEYS(24 0)   +
>   RECORDSIZE(24 143)   +
>   SHAREOPTIONS(2 3)+
>   )+
>  DATA (+
>   NAME()  +
>   CONTROLINTERVALSIZE(8192)+

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[David Spiegel]

Hi Phil,
Maybe the "***NOTE***" was written before the advent of the EXPORT 
Statement.
Had the //SMPCNTL been written with "&" instead of "!...", the 
substitutions could be done via EXPORT, SET and SYMBOLS=JCLONLY.

Here is a possible solution:

// EXPORT SYMLIST=*
// SET HLQ=SYSX
// SET VOLSER=ABC123
// EXEC SMPE
//SYSINDD *,SYNBOLS=JCLONLY
  DEFINE CLUSTER(+
   NAME()+
   VOLUMES()  +
   CYLINDERS(20 10)  +
   FREESPACE(2 2)+
   KEYS(24 0)+
   RECORDSIZE(24 143)+
   SHAREOPTIONS(2 3) +
   ) +
  DATA ( +
   NAME()   +
   CONTROLINTERVALSIZE(8192) +


Regards,
David

On 2023-08-24 18:45, Phil Smith III wrote:

Gil wrote:

I'm ignorant, or at best outdated.  I haven't known of use of symbols by SMP/E.
But are there instances where the same  would need to appear in
one instream data set where it should be evaluated and in another where it
must not, regardless of  //name DD DATA,SYMBOLS=...?  Cite detailed
example, please.

I mean things like the RFPREFIX value on a RECEIVE command, which apparently cannot 
be  but must specify the data set prefix of the RELFILEs. Same for the 
value for a PATH on a DDDEF.


There are ways. however cumbersome, to escape symbol evaluation in
instream data sets.

Well, maybe; I didn't write this stuff but the guy who did was pretty sharp, 
and couldn't figure out ways around the above. He also noted this:
//****NOTE*** Some references to variable values are in records
//*   provided as part of SYSIN DD *, and thus cannot be
//*   filled in using JCL variables ( et al.). Thus
//*   in this job, you must replace all references to
//*   !hlq!, !unit!, and !volser!, not just the single
//*   SET statement for each.

Maybe there's a clever way around that? It's referring to things like:
//SYSINDD *
   DEFINE CLUSTER(+
NAME(!hlq!.GLOBAL.CSI)+
VOLUMES(!volser!) +
CYLINDERS(20 10)  +
FREESPACE(2 2)+
KEYS(24 0)+
RECORDSIZE(24 143)+
SHAREOPTIONS(2 3) +
) +
   DATA ( +
NAME(!hlq!.GLOBAL.CSI.DATA)   +
CONTROLINTERVALSIZE(8192) +


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Phil Smith III]

Gil wrote:
>I'm ignorant, or at best outdated.  I haven't known of use of symbols by SMP/E.
>But are there instances where the same  would need to appear in
>one instream data set where it should be evaluated and in another where it
>must not, regardless of  //name DD DATA,SYMBOLS=...?  Cite detailed
>example, please.

I mean things like the RFPREFIX value on a RECEIVE command, which apparently 
cannot be  but must specify the data set prefix of the RELFILEs. Same 
for the value for a PATH on a DDDEF.

>There are ways. however cumbersome, to escape symbol evaluation in
>instream data sets.

Well, maybe; I didn't write this stuff but the guy who did was pretty sharp, 
and couldn't figure out ways around the above. He also noted this:
//****NOTE*** Some references to variable values are in records
//*   provided as part of SYSIN DD *, and thus cannot be
//*   filled in using JCL variables ( et al.). Thus
//*   in this job, you must replace all references to
//*   !hlq!, !unit!, and !volser!, not just the single
//*   SET statement for each.

Maybe there's a clever way around that? It's referring to things like:
//SYSINDD *
  DEFINE CLUSTER(+
   NAME(!hlq!.GLOBAL.CSI)+
   VOLUMES(!volser!) +
   CYLINDERS(20 10)  +
   FREESPACE(2 2)+
   KEYS(24 0)+
   RECORDSIZE(24 143)+
   SHAREOPTIONS(2 3) +
   ) +
  DATA ( +
   NAME(!hlq!.GLOBAL.CSI.DATA)   +
   CONTROLINTERVALSIZE(8192) +


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Paul Gilmartin]

On Thu, 24 Aug 2023 17:02:48 -0400, Phil Smith III wrote:
>
>>JCL SET?  Where is its behavior inconsistent?
>
>It's not SET that's inconsistent, it's support for it in SMP/E. There are 
>places in SMP/E jobs that can't use symbols. So you can't just have a chunk at 
>the top that job where you fill in values-you have to tour the job and fix it 
>27 times (OK, not 27, that's just a number I made up).
>
I'm ignorant, or at best outdated.  I haven't known of use of symbols by SMP/E.
But are there instances where the same  would need to appear in
one instream data set where it should be evaluated and in another where it
must not, regardless of  //name DD DATA,SYMBOLS=...?  Cite detailed
example, please.

There are ways. however cumbersome, to escape symbol evaluation in
instream data sets.

>When I deliver the product to the customers, I'd like them to be able to just 
>change stuff in ONE place per job. Otherwise they can (AND DO) miss a few, 
>leading to hilarity.
>
Better, to just change stuff in ONE JCLLIB member included in ALL relevant jobs.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[David Spiegel]

Hi Phil,
I beg to differ.
You can use SET at the top of every Job to set ALL variables (as my 
previous email said).

Can you please give me an example of what you're saying.

Another thing ... Do you remember IPOUPDTE? (It was a batch "editor" to 
change all of the HLQ from ABC to DEF. This could be used instead of the 
SET.)


Regards,
David


On 2023-08-24 17:02, Phil Smith III wrote:

Gil wrote:

I introduced "symbols".  Shmuel may have reintroduced it.  Are we thinking of 
the same
JCL SET?  Where is its behavior inconsistent?

It's not SET that's inconsistent, it's support for it in SMP/E. There are 
places in SMP/E jobs that can't use symbols. So you can't just have a chunk at 
the top that job where you fill in values-you have to tour the job and fix it 
27 times (OK, not 27, that's just a number I made up).

When I deliver the product to the customers, I'd like them to be able to just 
change stuff in ONE place per job. Otherwise they can (AND DO) miss a few, 
leading to hilarity.

  

  



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Phil Smith III]

Gil wrote:
>I introduced "symbols".  Shmuel may have reintroduced it.  Are we thinking of 
>the same

>JCL SET?  Where is its behavior inconsistent?

It's not SET that's inconsistent, it's support for it in SMP/E. There are 
places in SMP/E jobs that can't use symbols. So you can't just have a chunk at 
the top that job where you fill in values-you have to tour the job and fix it 
27 times (OK, not 27, that's just a number I made up).

When I deliver the product to the customers, I'd like them to be able to just 
change stuff in ONE place per job. Otherwise they can (AND DO) miss a few, 
leading to hilarity.

 

 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Kurt Quackenbush]

> Yes. As I wrote before, there's way too much "take this job and 
> find the 27 places that say XYZZY and change them to the right HLQ." instead 
> of "Run it with these variables set as follows". This makes creating and 
> documenting SMP/E installs a lot more work than they should need to be.

Yup, there's often lots of JCL samples to be massaged to perform an SMP/E 
install.  Create CSIs, allocate target and dlib data sets, update DDDEF 
entries, ...  Which is one of the reasons why z/OSMF Software Management and 
Portable Software Instances exist.  Any provider (not just IBM) can create a 
Portable Software Instance containing their software product using z/OSMF and 
distribute it to their clients, and the clients can install the software 
contained in the Portable Software Instance using z/OSMF.  No JCL massaging 
required.

Kurt Quackenbush
IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com

Chuck Norris never uses CHECK when he applies PTFs.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[David Spiegel]

Hi Phil,
You said: "... as literal is never valid in those places, ..."
You've made an incorrect assumption.
If the user codes:
// EXPORT SYMLIST=*
// SET HLQ=SYSX

// EXEC PGM=IDCAMS
//SYSIN DD *,SYMBOLS=JCLONLY
 DEL 

This will work.

Regards,
David
On 2023-08-24 15:35, Phil Smith III wrote:

Gil wrote:

How much of the need for symbols might be satisfied nowadays by:
o JCLLIB INCLUDE members containing numerous //   SET statements?

Sure.if // SET worked consistently. That's what I meant by "symbols", which was 
apparently unclear (I thought someone else had used that term, but am perfectly willing to 
believe I confused myself).  and the like. Some places in SMP/E jobs you can use 
these, others you cannot. Since  as literal is never valid in those places, adding this 
support would be a pure addition, with no downside AFAICT. If IBM were investing in such things, 
which they don't appear to be.


o //SMPCNTL DD DATA,SYMBOLS=JCLONLY?  (And other instream MCS.)

Not sure about this one. Might help.


... reuse available facilities rather than innovating.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Paul Gilmartin]

On Thu, 24 Aug 2023 15:35:13 -0400, Phil Smith III  wrote:

>Gil wrote:
>>How much of the need for symbols might be satisfied nowadays by:
>>o JCLLIB INCLUDE members containing numerous //   SET statements?
>
>Sure.if // SET worked consistently. That's what I meant by "symbols", which 
>was apparently unclear (I thought someone else had used that term, but am 
>perfectly willing to believe I confused myself). 
>
I introduced "symbols".  Shmuel may have reintroduced it.  Are we thinking of 
the same
JCL SET?  Where is its behavior inconsistent?


> ...  and the like. Some places in SMP/E jobs you can use these, 
> others you cannot. Since  as literal is never valid in those places, 
> adding this support would be a pure addition, with no downside AFAICT. If IBM 
> were investing in such things, which they don't appear to be.
>
I was assuming it was needed only in JCL statements and instream data sets.
Where else do you see a need for symbol substitution?

>>o //SMPCNTL DD DATA,SYMBOLS=JCLONLY?  (And other instream MCS.)

>Not sure about this one. Might help.
>
>>... reuse available facilities rather than innovating.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Tom Brennan]

That's it, thanks!  DIS(WRITE) and make sure you have a backup of your 
PDS's, because they will be junk if the job fails.  That's what I 
remember from the 1980's.


On 8/24/2023 12:36 PM, David Spiegel wrote:

Hi Tom,
"... And what was that option so it didn't read/write each PDS directory 
entry separately and take all day?  ..."

DIS (Directories in Storage)

Please see:
GC28-0673-6 OS/VS System Modification Program (SMP) System Programmer's 
Guide (prycroft6.com.au) 
<https://www.prycroft6.com.au/misc/download/GC28-0673-6_SMP_SysPgmrGde_Sep80OCR.pdf> 


Page 85

Regards,
David


On 2023-08-24 15:16, Tom Brennan wrote:
Wow, you reminded me of SMP4, my first.  Exclude lists!  And what was 
that option so it didn't read/write each PDS directory entry 
separately and take all day?  SMP/E was like a revolution.  Great work 
by the designers.


On 8/24/2023 12:05 PM, Seymour J Metz wrote:

Symbols?

SMP may not be perfect, but it's a lot better than what came before. 
SMP2, SMP3, SMP4 and SMP/E were each an improvement, and SMP/E has 
itself evolved significantly.


Perfect? Of course not. But still essential.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
behalf of Phil Smith III [li...@akphs.com]

Sent: Thursday, August 24, 2023 2:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is SMP/E needed for installs?

I don't think SMP/E is evil, I think it's unfinished. As I wrote 
before, the inconsistent support for symbols and the execrable error 
messages lead to tons of wasted time, frustration, and hatred. Yet 
the actual concepts and functioning are pretty cool-how often have 
you wanted to back off a Windows patch? So sad, too bad, you applied 
it, your only option is a rollback to a previous checkpoint, if you 
have one and can find it. Etc.




If it supported symbols consistently and someone paid attention to 
the errors and made them more coherent, several things would happen:


1.  Folks would make fewer errors
2.  When they do make errors, they'd be able to say "Oh, right" 
and fix them, rather than wasting hours

3.  They wouldn't hate SMP/E as so many seem to



Since, aside from vendors like us with automated testing, SMP/E 
results are (I think?) unlikely to be subject to automation, changing 
errors seems like it would be pretty safe. Actually, since the errors 
ARE so grim, what testing exists is, I expect, like ours: it looks 
for RC=0 (or 4, sometimes) and if it doesn't get what it wants, punts 
to a human anyway!



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[David Spiegel]

Hi Tom,
"... And what was that option so it didn't read/write each PDS directory 
entry separately and take all day?  ..."

DIS (Directories in Storage)

Please see:
GC28-0673-6 OS/VS System Modification Program (SMP) System Programmer's 
Guide (prycroft6.com.au) 
<https://www.prycroft6.com.au/misc/download/GC28-0673-6_SMP_SysPgmrGde_Sep80OCR.pdf>

Page 85

Regards,
David


On 2023-08-24 15:16, Tom Brennan wrote:
Wow, you reminded me of SMP4, my first.  Exclude lists!  And what was 
that option so it didn't read/write each PDS directory entry 
separately and take all day?  SMP/E was like a revolution.  Great work 
by the designers.


On 8/24/2023 12:05 PM, Seymour J Metz wrote:

Symbols?

SMP may not be perfect, but it's a lot better than what came before. 
SMP2, SMP3, SMP4 and SMP/E were each an improvement, and SMP/E has 
itself evolved significantly.


Perfect? Of course not. But still essential.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3 




From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
behalf of Phil Smith III [li...@akphs.com]

Sent: Thursday, August 24, 2023 2:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is SMP/E needed for installs?

I don't think SMP/E is evil, I think it's unfinished. As I wrote 
before, the inconsistent support for symbols and the execrable error 
messages lead to tons of wasted time, frustration, and hatred. Yet 
the actual concepts and functioning are pretty cool-how often have 
you wanted to back off a Windows patch? So sad, too bad, you applied 
it, your only option is a rollback to a previous checkpoint, if you 
have one and can find it. Etc.




If it supported symbols consistently and someone paid attention to 
the errors and made them more coherent, several things would happen:


1.  Folks would make fewer errors
2.  When they do make errors, they'd be able to say "Oh, right" 
and fix them, rather than wasting hours

3.  They wouldn't hate SMP/E as so many seem to



Since, aside from vendors like us with automated testing, SMP/E 
results are (I think?) unlikely to be subject to automation, changing 
errors seems like it would be pretty safe. Actually, since the errors 
ARE so grim, what testing exists is, I expect, like ours: it looks 
for RC=0 (or 4, sometimes) and if it doesn't get what it wants, punts 
to a human anyway!



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Phil Smith III]

Gil wrote:
>How much of the need for symbols might be satisfied nowadays by:
>o JCLLIB INCLUDE members containing numerous //   SET statements?

Sure.if // SET worked consistently. That's what I meant by "symbols", which was 
apparently unclear (I thought someone else had used that term, but am perfectly 
willing to believe I confused myself).  and the like. Some places in 
SMP/E jobs you can use these, others you cannot. Since  as literal is 
never valid in those places, adding this support would be a pure addition, with 
no downside AFAICT. If IBM were investing in such things, which they don't 
appear to be.

>o //SMPCNTL DD DATA,SYMBOLS=JCLONLY?  (And other instream MCS.)
Not sure about this one. Might help.

>... reuse available facilities rather than innovating.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Phil Smith III]

Shmuel wrote, in part:
>Symbols?

Yes. As I wrote before, there's way too much "take this job and find 
the 27 places that say XYZZY and change them to the right HLQ." instead of "Run 
it with these variables set as follows". This makes creating and documenting 
SMP/E installs a lot more work than they should need to be.

Consider installing products on other operating systems: you run the installer, 
and either it asks where you want stuff or it goes in the current directory (or 
subdirectories thereof). With SMP/E, you have to tell it many, many times, and 
(in my experience, which is admittedly quite limited) in subtly different ways: 
some places you need one level of HLQ and others you need more.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Paul Gilmartin]

On Thu, 24 Aug 2023 14:57:53 -0400, Phil Smith III  wrote:

>I don't think SMP/E is evil, I think it's unfinished. As I wrote before, the 
>inconsistent support for symbols
>
How much of the need for symbols might be satisfied nowadays by:
o JCLLIB INCLUDE members containing numerous //   SET statements?
o //SMPCNTL DD DATA,SYMBOLS=JCLONLY?  (And other instream MCS.)

... reuse available facilities rather than innovating.

>... and the execrable error messages lead to tons of wasted time, 
> frustration, and hatred. Yet the actual concepts and functioning are pretty 
> cool-how often have you wanted to back off a Windows patch? So sad, too bad, 
> you applied it, your only option is a rollback to a previous checkpoint, if 
> you have one and can find it. Etc.
>
>If it supported symbols consistently and someone paid attention to the errors 
>and made them more coherent, several things would happen:
>
>1. Folks would make fewer errors
>2. When they do make errors, they'd be able to say "Oh, right" and fix 
>them, rather than wasting hours
>3. They wouldn't hate SMP/E as so many seem to
>
>Since, aside from vendors like us with automated testing, SMP/E results are (I 
>think?) unlikely to be subject to automation, changing errors seems like it 
>would be pretty safe. Actually, since the errors ARE so grim, what testing 
>exists is, I expect, like ours: it looks for RC=0 (or 4, sometimes) and if it 
>doesn't get what it wants, punts to a human anyway!

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Tom Brennan]

Wow, you reminded me of SMP4, my first.  Exclude lists!  And what was 
that option so it didn't read/write each PDS directory entry separately 
and take all day?  SMP/E was like a revolution.  Great work by the 
designers.


On 8/24/2023 12:05 PM, Seymour J Metz wrote:

Symbols?

SMP may not be perfect, but it's a lot better than what came before. SMP2, 
SMP3, SMP4 and SMP/E were each an improvement, and SMP/E has itself evolved 
significantly.

Perfect? Of course not. But still essential.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Thursday, August 24, 2023 2:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is SMP/E needed for installs?

I don't think SMP/E is evil, I think it's unfinished. As I wrote before, the 
inconsistent support for symbols and the execrable error messages lead to tons 
of wasted time, frustration, and hatred. Yet the actual concepts and 
functioning are pretty cool-how often have you wanted to back off a Windows 
patch? So sad, too bad, you applied it, your only option is a rollback to a 
previous checkpoint, if you have one and can find it. Etc.



If it supported symbols consistently and someone paid attention to the errors 
and made them more coherent, several things would happen:

1.  Folks would make fewer errors
2.  When they do make errors, they'd be able to say "Oh, right" and fix 
them, rather than wasting hours
3.  They wouldn't hate SMP/E as so many seem to



Since, aside from vendors like us with automated testing, SMP/E results are (I 
think?) unlikely to be subject to automation, changing errors seems like it 
would be pretty safe. Actually, since the errors ARE so grim, what testing 
exists is, I expect, like ours: it looks for RC=0 (or 4, sometimes) and if it 
doesn't get what it wants, punts to a human anyway!


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Seymour J Metz]

Symbols?

SMP may not be perfect, but it's a lot better than what came before. SMP2, 
SMP3, SMP4 and SMP/E were each an improvement, and SMP/E has itself evolved 
significantly.

Perfect? Of course not. But still essential.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Thursday, August 24, 2023 2:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is SMP/E needed for installs?

I don't think SMP/E is evil, I think it's unfinished. As I wrote before, the 
inconsistent support for symbols and the execrable error messages lead to tons 
of wasted time, frustration, and hatred. Yet the actual concepts and 
functioning are pretty cool-how often have you wanted to back off a Windows 
patch? So sad, too bad, you applied it, your only option is a rollback to a 
previous checkpoint, if you have one and can find it. Etc.



If it supported symbols consistently and someone paid attention to the errors 
and made them more coherent, several things would happen:

1.  Folks would make fewer errors
2.  When they do make errors, they'd be able to say "Oh, right" and fix 
them, rather than wasting hours
3.  They wouldn't hate SMP/E as so many seem to



Since, aside from vendors like us with automated testing, SMP/E results are (I 
think?) unlikely to be subject to automation, changing errors seems like it 
would be pretty safe. Actually, since the errors ARE so grim, what testing 
exists is, I expect, like ours: it looks for RC=0 (or 4, sometimes) and if it 
doesn't get what it wants, punts to a human anyway!


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Phil Smith III]

I don't think SMP/E is evil, I think it's unfinished. As I wrote before, the 
inconsistent support for symbols and the execrable error messages lead to tons 
of wasted time, frustration, and hatred. Yet the actual concepts and 
functioning are pretty cool-how often have you wanted to back off a Windows 
patch? So sad, too bad, you applied it, your only option is a rollback to a 
previous checkpoint, if you have one and can find it. Etc.

 

If it supported symbols consistently and someone paid attention to the errors 
and made them more coherent, several things would happen:

1.  Folks would make fewer errors
2.  When they do make errors, they'd be able to say "Oh, right" and fix 
them, rather than wasting hours
3.  They wouldn't hate SMP/E as so many seem to

 

Since, aside from vendors like us with automated testing, SMP/E results are (I 
think?) unlikely to be subject to automation, changing errors seems like it 
would be pretty safe. Actually, since the errors ARE so grim, what testing 
exists is, I expect, like ours: it looks for RC=0 (or 4, sometimes) and if it 
doesn't get what it wants, punts to a human anyway!


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Paul Gilmartin]

On Thu, 24 Aug 2023 19:06:17 +0100, Colin Paice  wrote:
>...
>Only if you need >additional< fixes before the next download - do you need
>to do any SMP/E work. It would still be there if you need it.
>
This leads to personnel with little recent SMP/E practice performing emergency 
maintenance.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Jon Perryman]

 > On Thursday, August 24, 2023 at 11:06:43 AM PDT, Colin Paice 
 >  wrote:
> But this fix management would be done by IBM (or product owner).  


I'm guessing that IBM is still on a 2 year release cycle and they still have a 
custom-built offering so you're not dealing with a lot of tapes and files. With 
as many products that IBM deals with, packaging would be a nightmare. IBM's 
RHEL and other Linux distros exists solely to simplify the process and they 
don't deal with anywhere near the number of IBM z/OS products. SMP/e is a good 
compromise that guarantees everything was performed correctly for your needs. 
OEM vendors can easily provide choices because they don't deal with the 
magnitude of IBM.



On Thursday, August 24, 2023 at 11:06:43 AM PDT, Colin Paice 
 wrote:  
 
 ITSchak,
But this fix management would be done by IBM (or product owner).  We should
be able to download the image which has been tested by IBM Consolidated
Service Test in POK.
Only if you need >additional< fixes before the next download - do you need
to do any SMP/E work. It would still be there if you need it.
Colin

On Thu, 24 Aug 2023 at 17:08, ITschak Mugzach  wrote:

> Kurt,
>
> I think the power of SMP/E is not the initial install, but the fix
> management (ptf chain management). Actually many deliveries from IBM have
> SMP/E already populated and technically this is a kind of DSS dump (or can
> be).
>
> ITschak
>
>
> ITschak Mugzach
> *|** IronSphere Platform* *|* *Information Security Continuous Monitoring
> for z/OS, x/Linux & IBM I **| z/VM coming soon  *
>
>
>
>
> On Thu, Aug 24, 2023 at 6:48 PM Kurt Quackenbush  wrote:
>
> > Yes, thanks for asking, we have thought about an alternative.  And an
> > alternative exists in z/OSMF Software Management and Portable Software
> > Instances.  In this form you can package, deliver, and install software
> > whether it is SMP/E managed or not.  If it is SMP/E managed, as much of
> the
> > software on the z/OS platform is, then the package includes the SMP/E
> > artifacts like CSIs so you can install PTF fixes.  You can of course
> choose
> > to ignore the SMP/E artifacts and just repeat the process to install an
> > updated Portable Software Instance in 3 months as you suggest.
> >
> > Kurt Quackenbush
> > IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com
> >
> > Chuck Norris never uses CHECK when he applies PTFs.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of Colin Paice
> > Sent: Thursday, August 24, 2023 10:37 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [EXTERNAL] Is SMP/E needed for installs?
> >
> > This week, I did my first SMP/E install since my previous one over 40
> years
> > ago!  The process hasn't changed much.  It took me about half a day to
> > download the files and configure the jobs - making the same changes in
> > several jobs.
> > For people new to z/OS "installation" is hard to get into, understand,
> and
> > get working properly.
> >
> > Has anyone thought about alternative ways of shipping products?  For
> > example many products are now Web downloads, which you just restore.
> > I would like to see a DFDSS dump of the CST level of all objects and a
> > matching dump of the  SMP/E datasets of the product.
> > I can just restore the product stuff,and not the SMP/E stuff, or I can
> > install the SMP/E stuff as well.  If you want to install a fix, then
> apply
> > it to the SMP/E libraries.
> > In 3 months time,  repeat the whole process.
> >
> > I think we have to do something before all those with the knowledge and
> > experience retire!
> >
> > Colin
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> email
> > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Colin Paice]

ITSchak,
But this fix management would be done by IBM (or product owner).  We should
be able to download the image which has been tested by IBM Consolidated
Service Test in POK.
Only if you need >additional< fixes before the next download - do you need
to do any SMP/E work. It would still be there if you need it.
Colin

On Thu, 24 Aug 2023 at 17:08, ITschak Mugzach  wrote:

> Kurt,
>
> I think the power of SMP/E is not the initial install, but the fix
> management (ptf chain management). Actually many deliveries from IBM have
> SMP/E already populated and technically this is a kind of DSS dump (or can
> be).
>
> ITschak
>
>
> ITschak Mugzach
> *|** IronSphere Platform* *|* *Information Security Continuous Monitoring
> for z/OS, x/Linux & IBM I **| z/VM coming soon  *
>
>
>
>
> On Thu, Aug 24, 2023 at 6:48 PM Kurt Quackenbush  wrote:
>
> > Yes, thanks for asking, we have thought about an alternative.  And an
> > alternative exists in z/OSMF Software Management and Portable Software
> > Instances.  In this form you can package, deliver, and install software
> > whether it is SMP/E managed or not.  If it is SMP/E managed, as much of
> the
> > software on the z/OS platform is, then the package includes the SMP/E
> > artifacts like CSIs so you can install PTF fixes.  You can of course
> choose
> > to ignore the SMP/E artifacts and just repeat the process to install an
> > updated Portable Software Instance in 3 months as you suggest.
> >
> > Kurt Quackenbush
> > IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com
> >
> > Chuck Norris never uses CHECK when he applies PTFs.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of Colin Paice
> > Sent: Thursday, August 24, 2023 10:37 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [EXTERNAL] Is SMP/E needed for installs?
> >
> > This week, I did my first SMP/E install since my previous one over 40
> years
> > ago!   The process hasn't changed much.  It took me about half a day to
> > download the files and configure the jobs - making the same changes in
> > several jobs.
> > For people new to z/OS "installation" is hard to get into, understand,
> and
> > get working properly.
> >
> > Has anyone thought about alternative ways of shipping products?  For
> > example many products are now Web downloads, which you just restore.
> > I would like to see a DFDSS dump of the CST level of all objects and a
> > matching dump of the  SMP/E datasets of the product.
> > I can just restore the product stuff,and not the SMP/E stuff, or I can
> > install the SMP/E stuff as well.   If you want to install a fix, then
> apply
> > it to the SMP/E libraries.
> > In 3 months time,  repeat the whole process.
> >
> > I think we have to do something before all those with the knowledge and
> > experience retire!
> >
> > Colin
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> email
> > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Steve Thompson]

At Boole and Babbage, when I worked there in the early '90s, 
AutoOperator came on two tapes and you installed the first tape 
and it was ready to run. The second tape was the SMPE files 
(copied from the SMPE environment where the first tape was made).


So the install of the first tape had REXX|CLIST support for this 
so one could start a POC, or do it for real and run.


Then when you had time, you could install the second tape which 
was a copy of the SMPE environment at B again with CLIST and 
REXX to help you do that for your environment.


We sent out APARs and PTF (just like IBM did back then) and a 
type of PUT|Cum tapes.


If you wanted you could just re-order the product every six 
months and drop in the executables and run.


I've offered different entities where I've worked as a developer 
to set this up but they declined.


For simple installs, this is fairly easy to do. Add in where one 
has to do Usermods and it becomes a bit difficult.


Add in a product that has mutually exclusive components and it 
becomes difficult.


Steve Thompson (got delayed in posting this, so I know it is a 
bit behind, but history sometimes is useful)





On 8/24/2023 10:37 AM, Colin Paice wrote:

This week, I did my first SMP/E install since my previous one over 40 years
ago!   The process hasn't changed much.  It took me about half a day to
download the files and configure the jobs - making the same changes in
several jobs.
For people new to z/OS "installation" is hard to get into, understand, and
get working properly.

Has anyone thought about alternative ways of shipping products?  For
example many products are now Web downloads, which you just restore.
I would like to see a DFDSS dump of the CST level of all objects and a
matching dump of the  SMP/E datasets of the product.
I can just restore the product stuff,and not the SMP/E stuff, or I can
install the SMP/E stuff as well.   If you want to install a fix, then apply
it to the SMP/E libraries.
In 3 months time,  repeat the whole process.

I think we have to do something before all those with the knowledge and
experience retire!

Colin

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Jon Perryman]

 On Thursday, August 24, 2023 at 07:37:46 AM PDT, Colin Paice 
 wrote:

> I think we have to do something before all those with the knowledge and
> experience retire!

This is laughable because for the sysprog, the process can't be simpler. You 
were given a set of jobs to run and you changed nothing related to SMP/e. You 
entered information specific to your environment requirements (e.g DSN, DSN 
prefix, volser/unit and other environment specific information). When each job 
completed, you verified the completion code. Name 1 piece of SMP/e knowledge 
you as a sysprog used.

Unix install is far worse (e.g. apt install) because it's simple until it's 
not. Did you remember to pipe the log to a file in case of error (SMPLOG 
equivalent)? Too bad about utilities output not being fully available (SMP job 
output files). Did you think I don't need a backup because I'm only affecting 1 
app (SMP/e restore). Did you install on a shared readonly disk causing havoc?

Every question you answered in those SMP/e jobs was not about SMP/e. Instead, 
they get you to consider all the z/OS what if's and consider your installation 
strategy. For instance, you are running in a live sysplex and you don't want to 
install against live libraries and cause havoc.

Every reputable company requires important products to be installed using 
SMP/e. Unlike Unix, they don't want complete product replacement every time a 
critical bug is discovered. It's much safer to install 1 fix specific to the 
error they need fixed which can be quickly and easily tested. They want to see 
hold data that warns them about potential problems and actions they must take. 
Do I need to list more?

The heavy lifting for SMP/e lies with product developers. What are you 
proposing be changed?

On Thursday, August 24, 2023 at 07:37:46 AM PDT, Colin Paice 
 wrote:  
 
 This week, I did my first SMP/E install since my previous one over 40 years
ago!  The process hasn't changed much.  It took me about half a day to
download the files and configure the jobs - making the same changes in
several jobs.
For people new to z/OS "installation" is hard to get into, understand, and
get working properly.

Has anyone thought about alternative ways of shipping products?  For
example many products are now Web downloads, which you just restore.
I would like to see a DFDSS dump of the CST level of all objects and a
matching dump of the  SMP/E datasets of the product.
I can just restore the product stuff,and not the SMP/E stuff, or I can
install the SMP/E stuff as well.  If you want to install a fix, then apply
it to the SMP/E libraries.
In 3 months time,  repeat the whole process.

I think we have to do something before all those with the knowledge and
experience retire!

Colin

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[ITschak Mugzach]

Kurt,

I think the power of SMP/E is not the initial install, but the fix
management (ptf chain management). Actually many deliveries from IBM have
SMP/E already populated and technically this is a kind of DSS dump (or can
be).

ITschak


ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon  *




On Thu, Aug 24, 2023 at 6:48 PM Kurt Quackenbush  wrote:

> Yes, thanks for asking, we have thought about an alternative.  And an
> alternative exists in z/OSMF Software Management and Portable Software
> Instances.  In this form you can package, deliver, and install software
> whether it is SMP/E managed or not.  If it is SMP/E managed, as much of the
> software on the z/OS platform is, then the package includes the SMP/E
> artifacts like CSIs so you can install PTF fixes.  You can of course choose
> to ignore the SMP/E artifacts and just repeat the process to install an
> updated Portable Software Instance in 3 months as you suggest.
>
> Kurt Quackenbush
> IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com
>
> Chuck Norris never uses CHECK when he applies PTFs.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Colin Paice
> Sent: Thursday, August 24, 2023 10:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Is SMP/E needed for installs?
>
> This week, I did my first SMP/E install since my previous one over 40 years
> ago!   The process hasn't changed much.  It took me about half a day to
> download the files and configure the jobs - making the same changes in
> several jobs.
> For people new to z/OS "installation" is hard to get into, understand, and
> get working properly.
>
> Has anyone thought about alternative ways of shipping products?  For
> example many products are now Web downloads, which you just restore.
> I would like to see a DFDSS dump of the CST level of all objects and a
> matching dump of the  SMP/E datasets of the product.
> I can just restore the product stuff,and not the SMP/E stuff, or I can
> install the SMP/E stuff as well.   If you want to install a fix, then apply
> it to the SMP/E libraries.
> In 3 months time,  repeat the whole process.
>
> I think we have to do something before all those with the knowledge and
> experience retire!
>
> Colin
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Kurt Quackenbush]

Yes, thanks for asking, we have thought about an alternative.  And an 
alternative exists in z/OSMF Software Management and Portable Software 
Instances.  In this form you can package, deliver, and install software whether 
it is SMP/E managed or not.  If it is SMP/E managed, as much of the software on 
the z/OS platform is, then the package includes the SMP/E artifacts like CSIs 
so you can install PTF fixes.  You can of course choose to ignore the SMP/E 
artifacts and just repeat the process to install an updated Portable Software 
Instance in 3 months as you suggest.

Kurt Quackenbush
IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com

Chuck Norris never uses CHECK when he applies PTFs.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Colin Paice
Sent: Thursday, August 24, 2023 10:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Is SMP/E needed for installs?

This week, I did my first SMP/E install since my previous one over 40 years
ago!   The process hasn't changed much.  It took me about half a day to
download the files and configure the jobs - making the same changes in several 
jobs.
For people new to z/OS "installation" is hard to get into, understand, and get 
working properly.

Has anyone thought about alternative ways of shipping products?  For example 
many products are now Web downloads, which you just restore.
I would like to see a DFDSS dump of the CST level of all objects and a matching 
dump of the  SMP/E datasets of the product.
I can just restore the product stuff,and not the SMP/E stuff, or I can
install the SMP/E stuff as well.   If you want to install a fix, then apply
it to the SMP/E libraries.
In 3 months time,  repeat the whole process.

I think we have to do something before all those with the knowledge and 
experience retire!

Colin

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Is SMP/E needed for installs?

[Seymour J Metz]

Back in the "good old days" , there were alternative ways of shipping 
products and service. It was a nightmare, and SMP made things a lot more 
robust. Asking the z/OS community to abandon SMP is equivalent to asking the 
Linux community to abandon SCCS, CVS, svn and git. By all means look for ways 
to make the process smoother, but don't abandon the dependency checking.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Colin Paice [colinpai...@gmail.com]
Sent: Thursday, August 24, 2023 10:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Is SMP/E needed for installs?

This week, I did my first SMP/E install since my previous one over 40 years
ago!   The process hasn't changed much.  It took me about half a day to
download the files and configure the jobs - making the same changes in
several jobs.
For people new to z/OS "installation" is hard to get into, understand, and
get working properly.

Has anyone thought about alternative ways of shipping products?  For
example many products are now Web downloads, which you just restore.
I would like to see a DFDSS dump of the CST level of all objects and a
matching dump of the  SMP/E datasets of the product.
I can just restore the product stuff,and not the SMP/E stuff, or I can
install the SMP/E stuff as well.   If you want to install a fix, then apply
it to the SMP/E libraries.
In 3 months time,  repeat the whole process.

I think we have to do something before all those with the knowledge and
experience retire!

Colin

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN