Re: SMP/E download anomaly

[Kurt Quackenbush]

> All cases, the CLIENT DD referenced the same PDS member.

Then I cannot easily explain the observed behavior.  If you want to pursue, 
then I suggest opening a support case and be prepared to supply the output for 
both a job that used HTTPS, and a job whose CLIENT DD uses the same PDS member 
and used FTPS.

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: SMP/E download anomaly

[Norbert Gál]

Hello Kurt,


All cases, the CLIENT DD referenced the same PDS member.


Regards, 
Norbert



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kurt Quackenbush
Sent: Friday, April 19, 2024 5:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: SMP/E download anomaly

> I have an interesting case what I cannot untangle. I was creating multiple 
> ORDERSERVER using the same job where downloadmethod="https" is specified, 
> only the SMPCSI changed. For products like zSecure, MFA, AO, Netview, etc, 
> the job ran fine and downloaded relevant PTFs, however in case I was using 
> z/OS 2.4 or 2.5 global zone, the download method set was not honored, and the 
> transfer turned into FTP.
Why? What am I missing?

Does your job define the  XML information, which includes the 
downloadmethod value, inline?  Or does it use a DDDEF entry to point to a data 
set that contains the  XML?

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

Unless stated otherwise above:
Kyndryl Hungary Korlátolt Felelősségű Társaság / Kyndryl Hungary Llc
8000 Székesfehérvár, Berényi út 72-100. 35. ép
Cg.07-09-031714 - registering court: Székesfehérvári Törvényszék Cégbírósága


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

Re: SMP/E download anomaly

[Kurt Quackenbush]

> I have an interesting case what I cannot untangle. I was creating multiple 
> ORDERSERVER using the same job where downloadmethod="https" is specified, 
> only the SMPCSI changed. For products like zSecure, MFA, AO, Netview, etc, 
> the job ran fine and downloaded relevant PTFs, however in case I was using 
> z/OS 2.4 or 2.5 global zone, the download method set was not honored, and the 
> transfer turned into FTP.
Why? What am I missing?

Does your job define the  XML information, which includes the 
downloadmethod value, inline?  Or does it use a DDDEF entry to point to a data 
set that contains the  XML?

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: SMP/E

[Steely.Mark]

Found the example that you provided. The execution that was performed was just 
the upgrade command by itself. 
Then the job was executed that performed the received and it failed. 

Then the job was executed as describe in the example as the first command then 
the receive command after the 
Upgrade command and that worked. I must have misunderstood how to use the 
UPGRADE command. 

Thanks for the assistance. 

Thank You  


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Feller
Sent: Friday, March 29, 2024 7:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E



CAUTION! EXTERNAL SENDER! STOP, ASSESS, AND VERIFY Do you know this person? 
Were you expecting this email? If not, report it using the Report Phishing 
Button!

I'll ask if you did the UPGRADE in the same run as the RECEIVE process.  The 
example from the z/OS SMP/E Commands manual shows the UPGRADE command as part 
of the same run.

The following is from the SMP/E command manual.

SET BDY(ZOSTGT).
 UPGRADE.
 BYPASS(HOLDSYS)
 CHECK.

In this example, the UPGRADE command indicates incompatible changes may be made 
to SMP/E data sets.  If UPGRADE is not specified, then SMP/E stops any 
processing that would make incompatible changes to SMP/E data sets.  In this 
example, the APPLY command would very likely fail if the UPGRADE command were 
not first run.  However, once the UPGRADE command is run for a particular zone, 
then all SMP/E commands are authorized to make incompatible changes to all 
SMP/E data sets in that zone.


Paul

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steely.Mark
Sent: Friday, March 29, 2024 5:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E

I did perform the upgrade command on the global and target zone and nothing 
happen. The SMP/e level stayed the same and the receive still failed with the 
same error.



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Friday, March 29, 2024 5:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E



CAUTION! EXTERNAL SENDER! STOP, ASSESS, AND VERIFY Do you know this person? 
Were you expecting this email? If not, report it using the Report Phishing 
Button!

Just issue the UPGRADE command. IIRC FIXCAT support was added to SMP/E around 
2008.
Your global zone must have been created with a release of SMP/E before that.

--
Tom Marchant

On Fri, 29 Mar 2024 21:59:49 +, Steely.Mark  wrote:

>I recently received this message: GIM58903WSMP/E COULD NOT PROCESS A 
>++HOLD FIXCAT MCS BECAUSE IT WOULD HAVE MADE A CHANGE TO THE GLOBAL ZONE THAT
>   
>   CANNOT BE PROCESSED COMPLETELY BY PRIOR LEVELS OF SMP/E. USE THE 
> UPGRADE COMMAND TO ALLOW SMP/E TO MAKE
>   
>   SUCH CHANGES.
>
>The message says you can execute the upgrade command.  ( I am not sure 
>if I can do that without having some type of maintenance applied)
>
>It has been a while since I upgraded SMP/e independently of a Service Pack or 
>some other type of installation.
>
>I thought I would just install the new release of SMP/e - for some reason I 
>can't find it on ShopzSeries.
>
>I have tried to look all over the internet for the answer, but I always gets 
>hits on installing other products using SMP/e.
>
>We are currently at SMP/E 37.13
>Our SMP/E is 2.4 FMID - HMP1K00.
>
>What should I do ?

--
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: SMP/E

[ITschak Mugzach]

You might use the steplib as the one used to create the One, so it upgrades
to same level. Which is level are you in?

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





בתאריך שבת, 30 במרץ 2024 ב-1:00 מאת Steely.Mark :

> I recently received this message: GIM58903WSMP/E COULD NOT PROCESS A
> ++HOLD FIXCAT MCS BECAUSE IT WOULD HAVE MADE A CHANGE TO THE GLOBAL ZONE
> THAT
>
>CANNOT BE PROCESSED COMPLETELY BY PRIOR LEVELS OF SMP/E. USE THE
> UPGRADE COMMAND TO ALLOW SMP/E TO MAKE
>
>SUCH CHANGES.
>
> The message says you can execute the upgrade command.  ( I am not sure if
> I can do that without having some type of maintenance applied)
>
> It has been a while since I upgraded SMP/e independently of a Service Pack
> or some other type of installation.
>
> I thought I would just install the new release of SMP/e - for some reason
> I can't find it on ShopzSeries.
>
> I have tried to look all over the internet for the answer, but I always
> gets hits on installing other products using SMP/e.
>
> We are currently at SMP/E 37.13
> Our SMP/E is 2.4 FMID - HMP1K00.
>
> What should I do ?
>
> 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: SMP/E

[Paul Feller]

I'll ask if you did the UPGRADE in the same run as the RECEIVE process.  The 
example from the z/OS SMP/E Commands manual shows the UPGRADE command as part 
of the same run.

The following is from the SMP/E command manual.

SET BDY(ZOSTGT).
 UPGRADE.
 BYPASS(HOLDSYS)
 CHECK.

In this example, the UPGRADE command indicates incompatible changes may be made 
to SMP/E data sets.  If UPGRADE is not specified, then SMP/E stops any 
processing that would make incompatible changes to SMP/E data sets.  In this 
example, the APPLY command would very likely fail if the UPGRADE command were 
not first run.  However, once the UPGRADE command is run for a particular zone, 
then all SMP/E commands are authorized to make incompatible changes to all 
SMP/E data sets in that zone.


Paul

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steely.Mark
Sent: Friday, March 29, 2024 5:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E

I did perform the upgrade command on the global and target zone and nothing 
happen. The SMP/e level stayed the same and the receive still failed with the 
same error. 



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Friday, March 29, 2024 5:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E



CAUTION! EXTERNAL SENDER! STOP, ASSESS, AND VERIFY Do you know this person? 
Were you expecting this email? If not, report it using the Report Phishing 
Button!

Just issue the UPGRADE command. IIRC FIXCAT support was added to SMP/E around 
2008.
Your global zone must have been created with a release of SMP/E before that.

--
Tom Marchant

On Fri, 29 Mar 2024 21:59:49 +, Steely.Mark  wrote:

>I recently received this message: GIM58903WSMP/E COULD NOT PROCESS A 
>++HOLD FIXCAT MCS BECAUSE IT WOULD HAVE MADE A CHANGE TO THE GLOBAL ZONE THAT
>   
>   CANNOT BE PROCESSED COMPLETELY BY PRIOR LEVELS OF SMP/E. USE THE 
> UPGRADE COMMAND TO ALLOW SMP/E TO MAKE
>   
>   SUCH CHANGES.
>
>The message says you can execute the upgrade command.  ( I am not sure 
>if I can do that without having some type of maintenance applied)
>
>It has been a while since I upgraded SMP/e independently of a Service Pack or 
>some other type of installation.
>
>I thought I would just install the new release of SMP/e - for some reason I 
>can't find it on ShopzSeries.
>
>I have tried to look all over the internet for the answer, but I always gets 
>hits on installing other products using SMP/e.
>
>We are currently at SMP/E 37.13
>Our SMP/E is 2.4 FMID - HMP1K00.
>
>What should I do ?

--
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: SMP/E

[Steely.Mark]

I did perform the upgrade command on the global and target zone and nothing 
happen. The SMP/e level stayed the same and the receive still failed with the 
same error. 



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Friday, March 29, 2024 5:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E



CAUTION! EXTERNAL SENDER! STOP, ASSESS, AND VERIFY Do you know this person? 
Were you expecting this email? If not, report it using the Report Phishing 
Button!

Just issue the UPGRADE command. IIRC FIXCAT support was added to SMP/E around 
2008.
Your global zone must have been created with a release of SMP/E before that.

--
Tom Marchant

On Fri, 29 Mar 2024 21:59:49 +, Steely.Mark  wrote:

>I recently received this message: GIM58903WSMP/E COULD NOT PROCESS A 
>++HOLD FIXCAT MCS BECAUSE IT WOULD HAVE MADE A CHANGE TO THE GLOBAL ZONE THAT
>   
>   CANNOT BE PROCESSED COMPLETELY BY PRIOR LEVELS OF SMP/E. USE THE 
> UPGRADE COMMAND TO ALLOW SMP/E TO MAKE
>   
>   SUCH CHANGES.
>
>The message says you can execute the upgrade command.  ( I am not sure 
>if I can do that without having some type of maintenance applied)
>
>It has been a while since I upgraded SMP/e independently of a Service Pack or 
>some other type of installation.
>
>I thought I would just install the new release of SMP/e - for some reason I 
>can't find it on ShopzSeries.
>
>I have tried to look all over the internet for the answer, but I always gets 
>hits on installing other products using SMP/e.
>
>We are currently at SMP/E 37.13
>Our SMP/E is 2.4 FMID - HMP1K00.
>
>What should I do ?

--
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: SMP/E

[Tom Marchant]

Just issue the UPGRADE command. IIRC FIXCAT support was added to SMP/E around 
2008. 
Your global zone must have been created with a release of SMP/E before that.

-- 
Tom Marchant

On Fri, 29 Mar 2024 21:59:49 +, Steely.Mark  wrote:

>I recently received this message: GIM58903WSMP/E COULD NOT PROCESS A 
>++HOLD FIXCAT MCS BECAUSE IT WOULD HAVE MADE A CHANGE TO THE GLOBAL ZONE THAT
>   
>   CANNOT BE PROCESSED COMPLETELY BY PRIOR LEVELS OF SMP/E. USE THE 
> UPGRADE COMMAND TO ALLOW SMP/E TO MAKE
>   
>   SUCH CHANGES.   
>
>The message says you can execute the upgrade command.  ( I am not sure if I 
>can do that without having some type of maintenance applied)
>
>It has been a while since I upgraded SMP/e independently of a Service Pack or 
>some other type of installation. 
>
>I thought I would just install the new release of SMP/e - for some reason I 
>can't find it on ShopzSeries. 
>
>I have tried to look all over the internet for the answer, but I always gets 
>hits on installing other products using SMP/e.  
>
>We are currently at SMP/E 37.13   
>Our SMP/E is 2.4 FMID - HMP1K00. 
>
>What should I do ?

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

Re: [EXTERNAL] Re: SMP/E can't find APAR

[Pommier, Rex]

Hi Ann and Mark,

That is what I ended up doing.  I was looking for the info APAR to see if there 
was any additional information available.  The fix I was trying to put on had a 
pre-req.  I had to install the pre-req fix by itself first then the fix I 
initially tried by itself to get them installed.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ann 
Kelley
Sent: Thursday, March 14, 2024 7:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: SMP/E can't find APAR

I also searched, and found an item in a PSP bucket -- I've encountered this 
situation before, and have successfully done the recommended local fix --

20/08/05 APPLY CHECK for sysmods UI67319, UI65815, UI67709,
 UI68251 is failing with:
GIM24608E ** SHELLSCR ENTRY BBLS1803 IS NEEDED TO PROCESS HFS
BBL18003 FOR SYSMOD UI65815, BUT SHELLSCR BBLS1803 IS NOT IN
THE SZMR0G ZONE.

GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI65815.

LOCAL FIX:
Apply the PTF by itself with NO Groupextend and then Apply the
remaining PTF's needed from the original Apply.

APPLY S(UI65815)
BYPASS(HOLDSYSTEM)
CHECK.

SMP/E APAR IO27985 has been created to address this issue.

Here's the link to the item I found:   
https://urldefense.com/v3/__https://www.ibm.com/support/pages/upgrade-zosv2r4-subset-zoswlpem__;!!KjMRP1Ixj6eLE0Fj!qhfRADhq0Lu7tyeATgSEC-qHsPN-P2MVSVDteam_RwkDVz9Gst0ijwYh6pmQNdkRQAKbDdA6_t5DhYXriKg6IwdD$
 

--
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: SMP/E can't find APAR

[Ann Kelley]

I also searched, and found an item in a PSP bucket -- I've encountered this 
situation before, and have successfully done the recommended local fix --

20/08/05 APPLY CHECK for sysmods UI67319, UI65815, UI67709,
 UI68251 is failing with:
GIM24608E ** SHELLSCR ENTRY BBLS1803 IS NEEDED TO PROCESS HFS
BBL18003 FOR SYSMOD UI65815, BUT SHELLSCR BBLS1803 IS NOT IN
THE SZMR0G ZONE.

GIM22601I APPLY PROCESSING FAILED FOR SYSMOD UI65815.

LOCAL FIX:
Apply the PTF by itself with NO Groupextend and then Apply the
remaining PTF's needed from the original Apply.

APPLY S(UI65815)
BYPASS(HOLDSYSTEM)
CHECK.

SMP/E APAR IO27985 has been created to address this issue.

Here's the link to the item I found:   
https://www.ibm.com/support/pages/upgrade-zosv2r4-subset-zoswlpem

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

Re: [EXTERNAL] Re: SMP/E can't find APAR

[Pommier, Rex]

Thank you.  

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Wednesday, March 13, 2024 12:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: SMP/E can't find APAR

I just looked on ServiceLink. It's an open APAR, with a current target date of 
24/10/25.

Mark Jacobs 

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get&search=markjacobs@protonmail.com__;!!KjMRP1Ixj6eLE0Fj!qmirLfaT5pf8lrYw8sv686mQb7cc439HbJpRt3jM2daaDKnKv2v6nfeOAo4wDsgE3Q_BzdwpXxjLkmp0z6OBPGmW0PvAIrCtp_WJ$
 


On Wednesday, March 13th, 2024 at 1:05 PM, Pommier, Rex 
 wrote:

> Hello list,
> 
> I'm apparently having a senior moment. I'm having trouble running an apply 
> check on my 2.4 system with a missing shell script that exists. In 
> researching it, I found a similar situation and as part of it I found this on 
> IBM's web site:
> 
> SMP/E APAR IO27985 has been created to address this issue.
> 
> I can't find hide nor hair of this APAR, except in the document that says to 
> go look at it (of course without a link). Any thoughts as to what/where I 
> should look? I looked for SMPE APAR 27985 without the letters.
> 
> TIA for helping unrattled this old brain.
> 
> Rex
> 
> --
> 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

--
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: SMP/E can't find APAR

[Mark Jacobs]

I just looked on ServiceLink. It's an open APAR, with a current target date of 
24/10/25.

Mark Jacobs 

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com


On Wednesday, March 13th, 2024 at 1:05 PM, Pommier, Rex 
 wrote:

> Hello list,
> 
> I'm apparently having a senior moment. I'm having trouble running an apply 
> check on my 2.4 system with a missing shell script that exists. In 
> researching it, I found a similar situation and as part of it I found this on 
> IBM's web site:
> 
> SMP/E APAR IO27985 has been created to address this issue.
> 
> I can't find hide nor hair of this APAR, except in the document that says to 
> go look at it (of course without a link). Any thoughts as to what/where I 
> should look? I looked for SMPE APAR 27985 without the letters.
> 
> TIA for helping unrattled this old brain.
> 
> Rex
> 
> --
> 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: SMP/E JCLIN processing for job updates

[Vickie Dault]

FYI again.. perhaps a little closer

Vickie Dault Spahn

eMail:  vickie_da...@triserv.com
Cell    (916) 792-7720
Alternate Cellphone (916) 792-7850

Web:  www.triserv.com

   

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Friday, April 21, 2023 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E JCLIN processing for job updates

Hi Dave,
Thanks for the response.
No I am not editing the target data directly. We are working out of a pds 
separate from SMPe libraries.
The user mod looks like what I'm after. I will look into that..
On Fri, 21 Apr 2023 13:37:15 -0500, Dave Jousma  wrote:

>On Fri, 21 Apr 2023 13:10:19 -0500, Bill Giannelli  
>wrote:
>
>>various jobs for Db2 software maintenance, such as DSNTIJUZ DSNTIJUA DSNTIJRT.
>>Bill
>>On Fri, 21 Apr 2023 10:19:07 -0500, Dave Jousma  wrote:
>>
>>>On Fri, 21 Apr 2023 06:36:40 -0500, Bill Giannelli  
>>>wrote:
>>>
>
>So, those are DB2 jobs.   So what that tells me is that you might be editing 
>and using the SMPE target data, vs copying the JCL out to another library to 
>use?   If so, that’s really a no-no.   But if you want to make your changes 
>properly to that dataset so that SMPE knows about the changes, you would 
>create a USERMOD to replace the JCL with your customized JCL after merging in 
>any changes made by the maintenance.   A USERMOD will then tell you when a PTF 
>will overwrite the JCL, and will be the signal to 1) remove your usermod and 
>apply the PTF, and 2) re-work your usermod, and re-apply it.
>
>--
>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: SMP/E question of the day

[Jon Perryman]

On Mon, 18 Dec 2023 08:12:33 -0600, Paul Gilmartin  wrote:

>In ,
>the entire description of the MAME parameter syntax is:name
>There is no mention of a limit of length.  You're making that up.

The SMP/e programming API tells you 
https://www.ibm.com/docs/en/zos/3.1.0?topic=command-valid-subentry-types about 
all the CSI entries.

First, ++ZAP does not create an SMP/e entry. The NAME specified references an 
entry that already exists. In this case, a MOD entry. 

Second, the MOD ENAME length is 8. In fact, look at each entry type and you 
will see all ENAMEs are 8 (or less) in length. 

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

Re: SMP/E question of the day

[Bob Bridges]

Oops.  I have a REXX exec that creates a TSO alias on command, just because I 
don't do it often enough to remember the syntax at the time.  I named it 
TALIAS.  Maybe I'd better find another name...at least I should if I put it in 
a team library.  If it's my own SYSPROC or SYSEXEC PDS I don't guess it matters.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Most people thought [in 2000] that Web content should somehow be “free,” a 
hopelessly naïve ideology known today as “dot-communism.”...Dot-communism has 
been discarded along with its political counterpart, as users find that the 
adjective “free” means, as it always does, “paid for by someone else,” who 
insists on getting it back one way or another.  -David S Platt, "Introducing 
Microsoft .NET, Third Edition", 2003 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Monday, December 18, 2023 13:21

TALIAS gives a name for both target and distribution libraries; DALIAS gives a 
name for only distribution.

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

Re: SMP/E question of the day

[Seymour J Metz]

TALIAS gives a name for both target and distribution libraries; DALIAS gives a 
name for only distribution.



--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, December 17, 2023 12:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E question of the day

On Sun, 17 Dec 2023 15:12:59 +, Seymour J Metz wrote:

>Given that a csect may be included in multiple program objects (is there a 
>generic term for LM & PO), I don't see whwre you would need an lmod parameter 
>on the NAME statement. Allowing SMP to zap one instance in the target 
>libraries but not all sounds like a service  nightmare.
>
The CSECT() option of the ++MOD MCS should clarify this.  But it's optional,
and I don't know that it's verified, even if present.

Fiendish case: a CSECT in one ++MOD is identical to the name of a different 
++MOD.

>Does the 8 character limitation apply to alias names? PDSE limits main names 
>too 8.
>
Why are TALIAS and DALIAS mutually exclusive?

SMP/E doesn't understand its own alias names.  Once, as an experiment I created
an alias.  In standalone JCL SYSLIN "INCLUDE alias" worked.  Failed in SMP/E.
Went to SR.  Got WAD.

--
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: SMP/E question of the day

[Paul Gilmartin]

On Mon, 18 Dec 2023 13:39:09 +, Kurt Quackenbush wrote:

 NAME ABCDITSK ABCPROC#C C_CODE
>
>>> I believe SMP/E supports a maximum of 8 characters for the LMOD, CSECT, and 
>>> CLASS names specified on the IMASPZAP NAME statement.  CSECT name ABCPROC#C 
>>> is 9 characters.
>
>> You're making that up.
>
>I'm making that up?  I don't think so, I counted carefully and double checked, 
>"ABCPROC#C" is indeed 9 characters long, I didn't make that up.
>
In ,
the entire description of the MAME parameter syntax is:
name
specifies the name of the module member in the distribution library and,
optionally, in the target system library. The name can contain any
alphanumeric characters and $, #, @, or hex C0.

There is no mention of a limit of length.  You're making that up.

-- 
gil

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

Re: SMP/E question of the day

[Kurt Quackenbush]

>>> NAME ABCDITSK ABCPROC#C C_CODE

>> I believe SMP/E supports a maximum of 8 characters for the LMOD, CSECT, and 
>> CLASS names specified on the IMASPZAP NAME statement.  CSECT name ABCPROC#C 
>> is 9 characters.

> You're making that up.

I'm making that up?  I don't think so, I counted carefully and double checked, 
"ABCPROC#C" is indeed 9 characters long, I didn't make that up.

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: SMP/E question of the day

[Jon Perryman]

On Sun, 17 Dec 2023 14:10:51 -0600, Paul Gilmartin  wrote:

>On Sun, 17 Dec 2023 12:52:49 -0600, Jon Perryman wrote:
>>
>>++ZAP does not document limitations already described in ++MOD and ++JCLIN.
>>
>And yet it says: 
>
>
>name
>... The name can contain any alphanumeric characters and $, #, @, or hex 
> C0.
>
>Is that documenting limitations already described, introducing further 
>limitations,
>or fully describing the lexical syntax.  The reader should be told.

Clearly this sentence is not necessary and as you say somewhat confusing why it 
is mentioned. In fact, "name" documentation should be rewritten. NAME must 
specify a valid SMP/e MOD entry. To say module member is outside the context of 
SMP/e if it does not reference an SMP/e object.

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

Re: SMP/E question of the day

[Jon Perryman]

On Sun, 17 Dec 2023 11:01:23 -0600, Paul Gilmartin  wrote:

>The CSECT() option of the ++MOD MCS should clarify this.  But it's optional,
>and I don't know that it's verified, even if present.

CSECT defaults to ++MOD name which generates BINDER REPLACE statements. 
Specifying additional CSECT names allows one ++MOD to contain multiple CSECTs. 
I suspect that this is important for packaging LE programs.

>Fiendish case: a CSECT in one ++MOD is identical to the name of a different 
>++MOD.

Having the same CSECT name in different ++MODs is not a problem. A problem only 
occurs if both MODs are included into the same LMOD.

>Why are TALIAS and DALIAS mutually exclusive?

++MOD have a dist library DDN but do not have a target library DDN. DALIAS has 
an obvious implementation. TALIAS on the other hand is used for something that 
is not obvious because the MOD does not physically exist as a member in a 
target library. What and where are you going to attach an alias name. I suspect 
that TALIAS has a meaning in both target and dist that conflicts with DALIAS.

>SMP/E doesn't understand its own alias names.  Once, as an experiment I created
>an alias.  In standalone JCL SYSLIN "INCLUDE alias" worked.  Failed in SMP/E.
>Went to SR.  Got WAD.

An alias is not a SMP/e object so JCLiN cannot process an alias. All SMP/e 
objects are unique but the same alias can be used for many objects. SMP/e 
cannot identify the SMP/e object which affected.

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

Re: SMP/E question of the day

[Paul Gilmartin]

On Sun, 17 Dec 2023 12:52:49 -0600, Jon Perryman wrote:
>
>He's not making it up the 8 char limit. ++MOD and ++JCLIN create those SMP/e 
>entries. ++ZAP does not document limitations already described in ++MOD and 
>++JCLIN.
>
And yet it says: 


name
... The name can contain any alphanumeric characters and $, #, @, or hex C0.

Is that documenting limitations already described, introducing further 
limitations,
or fully describing the lexical syntax.  The reader should be told.

This is "The exception that implies the rule."  Explicitly mentioning only some
limitations leads the reader to conclude that there are no others.

-- 
gil

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

Re: SMP/E question of the day

[Seymour J Metz]

In SMP you can specify an alias of a distribution or target library member. 
That works as expected. What you can't do is specify an alias of a SMP element.

Yes, the element name and the member name are normally the same, but they exist 
in different name spaces.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, December 17, 2023 12:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E question of the day

On Sun, 17 Dec 2023 15:12:59 +, Seymour J Metz wrote:

>Given that a csect may be included in multiple program objects (is there a 
>generic term for LM & PO), I don't see whwre you would need an lmod parameter 
>on the NAME statement. Allowing SMP to zap one instance in the target 
>libraries but not all sounds like a service  nightmare.
>
The CSECT() option of the ++MOD MCS should clarify this.  But it's optional,
and I don't know that it's verified, even if present.

Fiendish case: a CSECT in one ++MOD is identical to the name of a different 
++MOD.

>Does the 8 character limitation apply to alias names? PDSE limits main names 
>too 8.
>
Why are TALIAS and DALIAS mutually exclusive?

SMP/E doesn't understand its own alias names.  Once, as an experiment I created
an alias.  In standalone JCL SYSLIN "INCLUDE alias" worked.  Failed in SMP/E.
Went to SR.  Got WAD.

--
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: SMP/E question of the day

[Jon Perryman]

On Sun, 17 Dec 2023 15:12:59 +, Seymour J Metz  wrote:

>Given that a csect may be included in multiple program objects (is there a 
>generic term for LM & PO),
> I don't see whwre you would need an lmod parameter on the NAME statement.

It's rare but a ++ZAP circumvents a problem that the customer is experiencing. 
If the workaround is for a very specific situation, restricting the change to a 
specific LMOD may be necessary. 

>Does the 8 character limitation apply to alias names? PDSE limits main names 
>too 8.

I suspect that alias names are limited to 8 because IBM added SYMLINK for long 
name support needed by UNIX.

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

Re: SMP/E question of the day

[Jon Perryman]

On Sun, 17 Dec 2023 09:02:37 -0600, Paul Gilmartin  wrote:

>On Thu, 14 Dec 2023 22:22:51 +, Kurt Quackenbush wrote:
>
>>> NAME ABCDITSK ABCPROC#C C_CODE
>>I believe SMP/E supports a maximum of 8 characters for the LMOD, CSECT, and 
>>CLASS names 
> specified on the IMASPZAP NAME statement.  CSECT name ABCPROC#C is 9 
> characters.
>> 
>You're making that up.  The SMP/E Ref. for ++ZAP mentions no such maximum.

He's not making it up the 8 char limit. ++MOD and ++JCLIN create those SMP/e 
entries. ++ZAP does not document limitations already described in ++MOD and 
++JCLIN.

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

Re: SMP/E question of the day

[Paul Gilmartin]

On Sun, 17 Dec 2023 15:12:59 +, Seymour J Metz wrote:

>Given that a csect may be included in multiple program objects (is there a 
>generic term for LM & PO), I don't see whwre you would need an lmod parameter 
>on the NAME statement. Allowing SMP to zap one instance in the target 
>libraries but not all sounds like a service  nightmare.
>
The CSECT() option of the ++MOD MCS should clarify this.  But it's optional,
and I don't know that it's verified, even if present.

Fiendish case: a CSECT in one ++MOD is identical to the name of a different 
++MOD.

>Does the 8 character limitation apply to alias names? PDSE limits main names 
>too 8.
>
Why are TALIAS and DALIAS mutually exclusive?

SMP/E doesn't understand its own alias names.  Once, as an experiment I created
an alias.  In standalone JCL SYSLIN "INCLUDE alias" worked.  Failed in SMP/E.
Went to SR.  Got WAD.

-- 
gil

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

Re: SMP/E question of the day

[Seymour J Metz]

Given that a csect may be included in multiple program objects (is there a 
generic term for LM & PO), I don't see whwre you would need an lmod parameter 
on the NAME statement. Allowing SMP to zap one instance in the target libraries 
but not all sounds like a service  nightmare.

Does the 8 character limitation apply to alias names? PDSE limits main names 
too 8.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of Jon 
Perryman 
Sent: Saturday, December 16, 2023 5:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E question of the day

On Thu, 14 Dec 2023 11:54:28 -0500, Phil Smith III  wrote:

>++VER(Z038) FMID(VABC840) .
>++ZAP(ABCDITSK) .
>NAME ABCDITSK ABCPROC#C C_CODE
>--NAME ABCDITSK ABCPROC#C C_CODE.
>GIM23101E ** THERE IS A SYNTAX ERROR IN A ZAP CONTROL STATEMENT FOR MODULE
> ABCDITSK IN SYSMOD ABC8401.

Like ++JCLIN, ++ZAP contains pseudo statements instead of actual superzap 
statements. SMP/E processes these pseudo statements which are sometimes 
incompatible with the real functionality. This is an SMP/e error message (not 
superzap). SMP/e may or may not support certain features. You will need to 
determine how SMP/e handles the various NAME statement options.

Consider a simple ++ZAP where in superzap where you specify NAME MYLMOD 
MYCSECT. Your first problem is that you don't zap an SMP/e LMOD. Instead, you 
would ++ZAP (MYCSECT) and use NAME MYCSECT. I think you can specify the LMOD if 
you only want to affect a single load module instead of all load modules with 
that csect name.

Verify that ABCDITSK is an SMP/e LMOD. ABCPROC#C is too long for an SMP/e MOD 
name so I'm guessing that you omitted an optional superzap NAME that SMP/e is 
relying upon. Look at the superzap NAME statement.

LE programs complicate the situation a little. I've never packaged them so I 
can only suggest how I would approach this. I'm guessing that SMP/e either 
requires a superzap NAME option specifying module name or requires ABCPROC#C be 
renamed to a valid ++MOD name which can be specified in the ++ZAP name. I'm 
guessing by this time, superzap with PDS/e now supports "NAME load-module 
module csect".

Remember that SMP/e may not have implemented all of the superzap NAME options. 
I suspect the C_CODE option is supported but it's possible that it's 
automatically determined in SMP/e and should not be specified as a NAME option.



--
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: SMP/E question of the day

[Paul Gilmartin]

On Thu, 14 Dec 2023 22:22:51 +, Kurt Quackenbush wrote:

>> NAME ABCDITSK ABCPROC#C C_CODE
>
>I believe SMP/E supports a maximum of 8 characters for the LMOD, CSECT, and 
>CLASS names specified on the IMASPZAP NAME statement.  CSECT name ABCPROC#C is 
>9 characters.
> 
You're making that up.  The SMP/E Ref. for ++ZAP mentions no such maximum.

But APAR, please, not RCF.

-- 
gil

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

Re: SMP/E question of the day

[Jon Perryman]

On Thu, 14 Dec 2023 11:54:28 -0500, Phil Smith III  wrote: 

>++VER(Z038) FMID(VABC840) .
>++ZAP(ABCDITSK) .
>NAME ABCDITSK ABCPROC#C C_CODE
>--NAME ABCDITSK ABCPROC#C C_CODE. 
>GIM23101E ** THERE IS A SYNTAX ERROR IN A ZAP CONTROL STATEMENT FOR MODULE
> ABCDITSK IN SYSMOD ABC8401.

Like ++JCLIN, ++ZAP contains pseudo statements instead of actual superzap 
statements. SMP/E processes these pseudo statements which are sometimes 
incompatible with the real functionality. This is an SMP/e error message (not 
superzap). SMP/e may or may not support certain features. You will need to 
determine how SMP/e handles the various NAME statement options.

Consider a simple ++ZAP where in superzap where you specify NAME MYLMOD 
MYCSECT. Your first problem is that you don't zap an SMP/e LMOD. Instead, you 
would ++ZAP (MYCSECT) and use NAME MYCSECT. I think you can specify the LMOD if 
you only want to affect a single load module instead of all load modules with 
that csect name.

Verify that ABCDITSK is an SMP/e LMOD. ABCPROC#C is too long for an SMP/e MOD 
name so I'm guessing that you omitted an optional superzap NAME that SMP/e is 
relying upon. Look at the superzap NAME statement.

LE programs complicate the situation a little. I've never packaged them so I 
can only suggest how I would approach this. I'm guessing that SMP/e either 
requires a superzap NAME option specifying module name or requires ABCPROC#C be 
renamed to a valid ++MOD name which can be specified in the ++ZAP name. I'm 
guessing by this time, superzap with PDS/e now supports "NAME load-module 
module csect". 

Remember that SMP/e may not have implemented all of the superzap NAME options. 
I suspect the C_CODE option is supported but it's possible that it's 
automatically determined in SMP/e and should not be specified as a NAME option. 



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

Re: SMP/E question of the day

[Kurt Quackenbush]

>> name ABCPROC#C is 9 characters.

> Right, but that's the generated name-the module is ABCPROC, written in C. How 
> does one get around this?

As a circumvention you can create a ++MOD to replace the entire module instead 
of using a ++ZAP to zap the load module.  If you require SMP/E to support CSECT 
names >8 characters on the IMASPZAP NAME statement within a ++ZAP, you can open 
a case with IBM support and request an APAR to update SMP/E's processing in 
this regard.

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: SMP/E question of the day

[Paul Gilmartin]

On Fri, 15 Dec 2023 11:53:03 -0500, Phil Smith III wrote:
>
>Right, but that's the generated name-the module is ABCPROC, written in C. How 
>does one get around this? As Gil suggests, this seems like an SMP/E 
>bug/failing.
>
I'll generalize: It's improper for middleware, in this case SMP/E, to presume
to enforce syntactic rules of lower components.

Extreme example: any member name allowed by BLDL/STOW *should* be
accepted in JCL -- metacharacters escaped as needed.

Postel's Law is half wrong.

--
gil 

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

Re: SMP/E question of the day

[Phil Smith III]

Kurt Quackenbush wrote, re:

>> NAME ABCDITSK ABCPROC#C C_CODE

 

>I believe SMP/E supports a maximum of 8 characters for the LMOD,

>CSECT, and CLASS names specified on the IMASPZAP NAME statement. CSECT

>name ABCPROC#C is 9 characters.

 

Right, but that's the generated name-the module is ABCPROC, written in C. How 
does one get around this? As Gil suggests, this seems like an SMP/E bug/failing.


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

Re: SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's

[Ross Vaughn]

Thanks Kurt.   This will be helpful as well. 

Ross

> On Dec 15, 2023, at 9:52 AM, Kurt Quackenbush  wrote:
> 
> 
>> 
>> If he clones the existing target and dlib zones, updates the DDDEFs and 
>> receives the new version, will SMPE try to delete the old FMID and/or the 
>> contents of the existing libraries?
> 
> Typically a new release of a product does delete the prior releases.  If you 
> are careful to update all DDDEF entries in the new target and dlib zones to 
> point to the new target and dlib data sets, then you should be safe from 
> accidentally deleting the existing FMID in the existing data sets.  But if 
> you are concerned then don't clone the existing target and dlib zones and 
> libraries; just create new, which should be about the same amount of work as 
> cloning, and the new product release I suspect supplies sample jobs to do 
> exactly that.
> 
> 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: SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's

[Kurt Quackenbush]

> If he clones the existing target and dlib zones, updates the DDDEFs and 
> receives the new version, will SMPE try to delete the old FMID and/or the 
> contents of the existing libraries?

Typically a new release of a product does delete the prior releases.  If you 
are careful to update all DDDEF entries in the new target and dlib zones to 
point to the new target and dlib data sets, then you should be safe from 
accidentally deleting the existing FMID in the existing data sets.  But if you 
are concerned then don't clone the existing target and dlib zones and 
libraries; just create new, which should be about the same amount of work as 
cloning, and the new product release I suspect supplies sample jobs to do 
exactly that.

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: SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's

[Michael Babcock]

I work with Ross and can explain what he is trying to accomplish.   We have
a Db2 v13 Global zone for Db2 along with its associated target and DLIB
zones.   We have several Db2 related products (Admin Tool, etc) installed
into the Db2 global with their own target and dlib zones.   He wants to
upgrade an existing product but with new target and dlib zones without
losing the old version.   If he clones the existing target and dlib zones,
updates the DDDEFs and receives the new version, will SMPE try to delete
the old FMID and/or the contents of the existing libraries?

On Thu, Dec 14, 2023 at 2:42 PM Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> This statement is very confusing to me?So for DB2V13 is installed in
> its own global zone, with target and dlib zones.It’s the next part of
> your statement “use my existing target and dlib zones and update ddefs…”
> that is confusing me.   It sounds like you are trying to marry your V13
> work with some other downlevel environment?  To me it sounds like you
> already have a V13 environment, along with some “older” environment.I
> cannot tell what you are trying to accomplish.
>
>
> >> On Thu, 14 Dec 2023 11:27:16 -0600, Ross Vaughn <
> ross.vaugh...@gmail.com> wrote:
>
> >>
>
> >>> I’m upgrading a product in my DB2v13 global zone.  I plan to use my
> existing target & DLIB zones and just update my DDDEFs to point to my new
> dataset names.
>
> >>> My question is - if I want to create new CSI’s (copied from my
> existing CSIs) for
>
>
> Dave Jousma
> Vice President | Director, Technology Engineering
>
>
>
>
>
> This e-mail transmission contains information that is confidential and may
> be privileged.   It is intended only for the addressee(s) named above. If
> you receive this e-mail in error, please do not read, copy or disseminate
> it in any manner. If you are not the intended recipient, any disclosure,
> copying, distribution or use of the contents of this information is
> prohibited. Please reply to the message immediately by informing the sender
> that the message was misdirected. After replying, please erase it from your
> computer system. Your assistance in correcting this error is appreciated.
>
> --
> 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: SMP/E question of the day

[Paul Gilmartin]

On Thu, 14 Dec 2023 22:22:51 +, Kurt Quackenbush wrote:

>> NAME ABCDITSK ABCPROC#C C_CODE
>
>I believe SMP/E supports a maximum of 8 characters for the LMOD, CSECT, and 
>CLASS names specified on the IMASPZAP NAME statement.  CSECT name ABCPROC#C is 
>9 characters.
>
If the section name was generated by a supported IBM compiler and/or reported 
by AMBLIST,
SMP/E needs to be updated to match reality.

WAD is no excuse.

-- 
gil

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

Re: SMP/E question of the day

[Kurt Quackenbush]

> NAME ABCDITSK ABCPROC#C C_CODE

I believe SMP/E supports a maximum of 8 characters for the LMOD, CSECT, and 
CLASS names specified on the IMASPZAP NAME statement.  CSECT name ABCPROC#C is 
9 characters.

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: SMP/E question of the day

[Phil Smith III]

Binyamin wrote:
>Unless you are sending this via teletype or FAX, I question why you
>would provide a zap rather than a module replacement.

Well, we've been discussing that already. But we'd like to understand it at 
least.

Meanwhile, Tom Marchant's suggestion sounded helpful, except it's C code. So 
what should:
NAME ABCDITSK ABCPROC#C C_CODE
become? It complains about the ABCPROC#C.


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

Re: SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's

[Jousma, David]

This statement is very confusing to me?So for DB2V13 is installed in its 
own global zone, with target and dlib zones.It’s the next part of your 
statement “use my existing target and dlib zones and update ddefs…” that is 
confusing me.   It sounds like you are trying to marry your V13 work with some 
other downlevel environment?  To me it sounds like you already have a V13 
environment, along with some “older” environment.I cannot tell what you are 
trying to accomplish.


>> On Thu, 14 Dec 2023 11:27:16 -0600, Ross Vaughn 
>> mailto:ross.vaugh...@gmail.com>> wrote:

>>

>>> I’m upgrading a product in my DB2v13 global zone.  I plan to use my 
>>> existing target & DLIB zones and just update my DDDEFs to point to my new 
>>> dataset names.

>>> My question is - if I want to create new CSI’s (copied from my existing 
>>> CSIs) for


Dave Jousma
Vice President | Director, Technology Engineering





This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's

[Mark Zelden]

You might want to look at the sysres cloning example on my web site / CBT file 
434 also as that
clones the SMP/E ZONEs with it.  I don't clone the DLIB volser(s) / zones these 
days (haven't
in many years), but you can easily see how it is done. See URL below. 

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html




On Thu, 14 Dec 2023 14:24:30 -0600, Ross Vaughn  wrote:

>Thanks for the info Tom. 
>I had planned to use the ZONEEDIT to update my DDDEFs as well, so thanks for 
>that confirmation.
>
>Ross 
>
>
>> On Dec 14, 2023, at 12:44 PM, Tom Marchant 
>> <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> I should have added that when I clone zones, I like to copy the SMPLOG as 
>> well, so that the full history is preserved. Don't forget to define the 
>> disposition for SMPLOG as MOD or the SMPLOG will be useless.
>> 
>> -- 
>> Tom Marchant
>> 
>> On Thu, 14 Dec 2023 12:31:15 -0600, Tom Marchant  
>> wrote:
>> 
>>> Create a new ZONEINDEX in the Global zone for each new zone (target and 
>>> DLIB), and relate them to each other.
>>> 
>>> If each zone is in its own CSI you can copy with IDCAMS REPRO. Otherwise 
>>> use ZONECOPY.
>>> 
>>> You can use ZONEEDIT to change the DDDEFs in your new zone(s). Don't forget 
>>> that the target zone needs the DLIB data sets, must have their own SMPLTS, 
>>> SMPMTS, SMPSTS, SMPSCDS. These can also be defined to your DLIB zone. IIRC, 
>>> only the SCDS is required in the DLIB zone.
>>> 
>>> Your target and DLIB zones will need DDDEFs for the SMPPTS
>>> 
>>> Be careful that you have not left any DDDEFs pointing to the previous 
>>> zone's data sets.
>>> 
>>> -- 
>>> Tom Marchant
>>> 
>>> On Thu, 14 Dec 2023 11:27:16 -0600, Ross Vaughn  
>>> wrote:
>>> 
 I’m upgrading a product in my DB2v13 global zone.  I plan to use my 
 existing target & DLIB zones and just update my DDDEFs to point to my new 
 dataset names.  
 My question is - if I want to create new CSI’s (copied from my existing 
 CSIs) for the target & DLIB what’s the best way to point the target & DLIB 
 to those new CSI’s?   My thought is using new CSI’s would allow me to keep 
 the previous FMID around if I needed it for any reason.
 
 Thanks,
 Ross Vaughn
 OneMain Financial
 
 
 
 
 
 
 
 

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

Re: SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's

[Ross Vaughn]

Thanks for the info Tom. 
I had planned to use the ZONEEDIT to update my DDDEFs as well, so thanks for 
that confirmation.

Ross 


> On Dec 14, 2023, at 12:44 PM, Tom Marchant 
> <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> 
> I should have added that when I clone zones, I like to copy the SMPLOG as 
> well, so that the full history is preserved. Don't forget to define the 
> disposition for SMPLOG as MOD or the SMPLOG will be useless.
> 
> -- 
> Tom Marchant
> 
> On Thu, 14 Dec 2023 12:31:15 -0600, Tom Marchant  
> wrote:
> 
>> Create a new ZONEINDEX in the Global zone for each new zone (target and 
>> DLIB), and relate them to each other.
>> 
>> If each zone is in its own CSI you can copy with IDCAMS REPRO. Otherwise use 
>> ZONECOPY.
>> 
>> You can use ZONEEDIT to change the DDDEFs in your new zone(s). Don't forget 
>> that the target zone needs the DLIB data sets, must have their own SMPLTS, 
>> SMPMTS, SMPSTS, SMPSCDS. These can also be defined to your DLIB zone. IIRC, 
>> only the SCDS is required in the DLIB zone.
>> 
>> Your target and DLIB zones will need DDDEFs for the SMPPTS
>> 
>> Be careful that you have not left any DDDEFs pointing to the previous zone's 
>> data sets.
>> 
>> -- 
>> Tom Marchant
>> 
>> On Thu, 14 Dec 2023 11:27:16 -0600, Ross Vaughn  
>> wrote:
>> 
>>> I’m upgrading a product in my DB2v13 global zone.  I plan to use my 
>>> existing target & DLIB zones and just update my DDDEFs to point to my new 
>>> dataset names.  
>>> My question is - if I want to create new CSI’s (copied from my existing 
>>> CSIs) for the target & DLIB what’s the best way to point the target & DLIB 
>>> to those new CSI’s?   My thought is using new CSI’s would allow me to keep 
>>> the previous FMID around if I needed it for any reason.
>>> 
>>> Thanks,
>>> Ross Vaughn
>>> OneMain Financial
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> 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: SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's

[Tom Marchant]

I should have added that when I clone zones, I like to copy the SMPLOG as well, 
so that the full history is preserved. Don't forget to define the disposition 
for SMPLOG as MOD or the SMPLOG will be useless.

-- 
Tom Marchant

On Thu, 14 Dec 2023 12:31:15 -0600, Tom Marchant  
wrote:

>Create a new ZONEINDEX in the Global zone for each new zone (target and DLIB), 
>and relate them to each other.
>
>If each zone is in its own CSI you can copy with IDCAMS REPRO. Otherwise use 
>ZONECOPY.
>
>You can use ZONEEDIT to change the DDDEFs in your new zone(s). Don't forget 
>that the target zone needs the DLIB data sets, must have their own SMPLTS, 
>SMPMTS, SMPSTS, SMPSCDS. These can also be defined to your DLIB zone. IIRC, 
>only the SCDS is required in the DLIB zone.
>
>Your target and DLIB zones will need DDDEFs for the SMPPTS
>
>Be careful that you have not left any DDDEFs pointing to the previous zone's 
>data sets.
>
>-- 
>Tom Marchant
>
>On Thu, 14 Dec 2023 11:27:16 -0600, Ross Vaughn  
>wrote:
>
>>I’m upgrading a product in my DB2v13 global zone.  I plan to use my existing 
>>target & DLIB zones and just update my DDDEFs to point to my new dataset 
>>names.  
>>My question is - if I want to create new CSI’s (copied from my existing CSIs) 
>>for the target & DLIB what’s the best way to point the target & DLIB to those 
>>new CSI’s?   My thought is using new CSI’s would allow me to keep the 
>>previous FMID around if I needed it for any reason.
>>
>>Thanks,
>>Ross Vaughn
>>OneMain Financial
>>
>>
>>
>>
>>
>>
>>
>>
>> 
>> 
>>
>>
>>--
>>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: SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's

[Tom Marchant]

Create a new ZONEINDEX in the Global zone for each new zone (target and DLIB), 
and relate them to each other.

If each zone is in its own CSI you can copy with IDCAMS REPRO. Otherwise use 
ZONECOPY.

You can use ZONEEDIT to change the DDDEFs in your new zone(s). Don't forget 
that the target zone needs the DLIB data sets, must have their own SMPLTS, 
SMPMTS, SMPSTS, SMPSCDS. These can also be defined to your DLIB zone. IIRC, 
only the SCDS is required in the DLIB zone.

Your target and DLIB zones will need DDDEFs for the SMPPTS

Be careful that you have not left any DDDEFs pointing to the previous zone's 
data sets.

-- 
Tom Marchant

On Thu, 14 Dec 2023 11:27:16 -0600, Ross Vaughn  wrote:

>I’m upgrading a product in my DB2v13 global zone.  I plan to use my existing 
>target & DLIB zones and just update my DDDEFs to point to my new dataset 
>names.  
>My question is - if I want to create new CSI’s (copied from my existing CSIs) 
>for the target & DLIB what’s the best way to point the target & DLIB to those 
>new CSI’s?   My thought is using new CSI’s would allow me to keep the previous 
>FMID around if I needed it for any reason.
>
>Thanks,
>Ross Vaughn
>OneMain Financial
>
>
>
>
>
>
>
>
> 
> 
>
>
>--
>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: SMP/E question of the day

[Binyamin Dissen]

Unless you are sending this via teletype or FAX, I question why you would
provide a zap rather than a module replacement.

On Thu, 14 Dec 2023 11:54:28 -0500 Phil Smith III  wrote:

:>From a coworker, who tried to post but it seems to have vanished-not even a 
bounce?! If it just got stuck somewhere, this might be a duplicate, sorry.
:>
:> 
:>
:> 
:>
:>I am having problems trying to convert a normal ZOS AMASPZAP to a SMPE ++ZAP.
:>
:> 
:>
:>When I run the zap through a standalone AMASPZAP process everything works 
fine:
:>
:> 
:>
:>IGWSPZAP  INSPECTS, MODIFIES, AND DUMPS CSECTS OR SPECIFIC DATA RECORDS ON 
DIRECT ACCESS STORAGE.
:>
:>AMA168I SYSIN PROCESSING STARTED
:>
:>NAME ABCDITSK ABCPROC#C C_CODE
:>
:>VER 067A EC0A008C,A077
:>
:>VER 0680 5800926C
:>
:>VER 0684 A7011000
:>
:>VER 0792 58F0301E
:>
:>VER 0796 E54CD0E0,
:>
:>VER 07AA E300D13B,0094
:>
:>VER 07B0 EC060018,007E
:>
:>REP 067A EC0A0102,A077
:>
:>AMA122I OLD DATA WAS EC0A008CA077
:>
:>CHECKSUM C08C1494
:>
:>AMA132I CHECKSUM WAS CORRECT, IS NOW 0.
:>
:>AMA163I PREVIOUS GROUP ENDED, ASSOCIATED MESSAGES FOLLOW:
:>
:>AMA125I IDR COUNT = 1 FOR SECTION = ABCPROC#C
:>
:>AMA164I END OF MESSAGES FOR PREVIOUS GROUP
:>
:>AMA168I SYSIN PROCESSING COMPLETED
:>
:>AMA100I IGWSPZAP   PROCESSING COMPLETED
:>
:> 
:>
:>However when I try to apply:
:>
:> 
:>
:>++VER(Z038) FMID(VABC840) .
:>
:>++ZAP(ABCDITSK) .
:>
:>NAME ABCDITSK ABCPROC#C C_CODE
:>
:>VER 067A EC0A008C,A077
:>
:>VER 0680 5800926C
:>
:>VER 0684 A7011000
:>
:>VER 0792 58F0301E
:>
:>VER 0796 E54CD0E0,
:>
:>VER 07AA E300D13B,0094
:>
:>VER 07B0 EC060018,007E
:>
:>REP 067A EC0A0102,A077
:>
:> 
:>
:>SMPE has issues
:>
:> 
:>
:>  SET BOUNDARY(TARGET) .
:>
:>GIM20501ISET PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 00.
:>
:> 
:>
:> 
:>
:>  APPLY S(ABC8401) .
:>
:> 
:>
:>--NAME ABCDITSK ABCPROC#C C_CODE
:>
:>GIM23101E ** THERE IS A SYNTAX ERROR IN A ZAP CONTROL STATEMENT FOR MODULE
:>
:> ABCDITSK IN SYSMOD ABC8401.
:>
:>GIM30216IAPPLY PROCESSING FAILED FOR SYSMOD ABC8401. SYSTEM UTILITY
:>
:> PROCESSING FAILED FOR AN ELEMENT IN ABC8401.
:>
:>GIM20501IAPPLY PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 08.
:>
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

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

Re: SMP/E question of the day

[Tom Marchant]

Does this help, from the SMP/E User's Guide:


The superzap control statements are the same as you would use if you were 
calling 
the superzap utility. The only exception is that on the NAME statement, you 
should 
specify only the CSECT name within the distribution library module, rather than 
the 
load module name and the CSECT name. When SMP/E installs the SYSMOD, it 
determines all the load modules into which this distribution module was 
link-edited 
and then calls the superzap utility for each of these load modules, modifying 
the 
NAME statement as appropriate.


-- 
Tom Marchant

On Thu, 14 Dec 2023 11:54:28 -0500, Phil Smith III  wrote:

>From a coworker, who tried to post but it seems to have vanished-not even a 
>bounce?! If it just got stuck somewhere, this might be a duplicate, sorry.
>
> 
>
> 
>
>I am having problems trying to convert a normal ZOS AMASPZAP to a SMPE ++ZAP.
>
> 
>
>When I run the zap through a standalone AMASPZAP process everything works fine:
>
> 
>
>IGWSPZAP  INSPECTS, MODIFIES, AND DUMPS CSECTS OR SPECIFIC DATA RECORDS ON 
>DIRECT ACCESS STORAGE.
>
>AMA168I SYSIN PROCESSING STARTED
>
>NAME ABCDITSK ABCPROC#C C_CODE
>
>VER 067A EC0A008C,A077
>
>VER 0680 5800926C
>
>VER 0684 A7011000
>
>VER 0792 58F0301E
>
>VER 0796 E54CD0E0,
>
>VER 07AA E300D13B,0094
>
>VER 07B0 EC060018,007E
>
>REP 067A EC0A0102,A077
>
>AMA122I OLD DATA WAS EC0A008CA077
>
>CHECKSUM C08C1494
>
>AMA132I CHECKSUM WAS CORRECT, IS NOW 0.
>
>AMA163I PREVIOUS GROUP ENDED, ASSOCIATED MESSAGES FOLLOW:
>
>AMA125I IDR COUNT = 1 FOR SECTION = ABCPROC#C
>
>AMA164I END OF MESSAGES FOR PREVIOUS GROUP
>
>AMA168I SYSIN PROCESSING COMPLETED
>
>AMA100I IGWSPZAP   PROCESSING COMPLETED
>
> 
>
>However when I try to apply:
>
> 
>
>++VER(Z038) FMID(VABC840) .
>
>++ZAP(ABCDITSK) .
>
>NAME ABCDITSK ABCPROC#C C_CODE
>
>VER 067A EC0A008C,A077
>
>VER 0680 5800926C
>
>VER 0684 A7011000
>
>VER 0792 58F0301E
>
>VER 0796 E54CD0E0,
>
>VER 07AA E300D13B,0094
>
>VER 07B0 EC060018,007E
>
>REP 067A EC0A0102,A077
>
> 
>
>SMPE has issues
>
> 
>
>  SET BOUNDARY(TARGET) .
>
>GIM20501ISET PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 00.
>
> 
>
> 
>
>  APPLY S(ABC8401) .
>
> 
>
>--NAME ABCDITSK ABCPROC#C C_CODE
>
>GIM23101E ** THERE IS A SYNTAX ERROR IN A ZAP CONTROL STATEMENT FOR MODULE
>
> ABCDITSK IN SYSMOD ABC8401.
>
>GIM30216IAPPLY PROCESSING FAILED FOR SYSMOD ABC8401. SYSTEM UTILITY
>
> PROCESSING FAILED FOR AN ELEMENT IN ABC8401.
>
>GIM20501IAPPLY PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 08.
>
>
>--
>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: SMP/E and PATH existence

[Rob Scott]

Jon

Obviously APPLY CHECK is standard practice, however this will only check the 
DDDEFs referenced by the FMID/PTF being applied in the current target zone.

The purpose of these "check DDDEF" utilities is to validate the entire CSI 
across multiple zones.

Back in the day, I used to run them after cloning a CSI or performing ZONEEDIT 
functions.

I found them especially useful at sites where the sysprog team might well be 
producing system software configurations for multiple customers.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Tuesday, October 10, 2023 5:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E and PATH existence

EXTERNAL EMAIL





On Fri, 6 Oct 2023 15:46:25 +, Rob Scott  wrote:

>This was precisely the reason for the original implementation of DDDEFCHK/PTH.
>
>Being able to quickly sniff-test the DDDEFs (across multiple
>target/dlib zones) before an APPLY that might take many minutes was
>deemed useful (well .. at least to me at the time...25 years ago)

Is APPLY CHECK no longer standard practice when installing a PTF or product? 
Quackenbush says checking DDDEF's externally is unnecessary and will only take 
take the time required for APPLY CHECK.

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SMP/E and PATH existence

[Phil Smith III]

Jon Perryman wrote:
>Is APPLY CHECK no longer standard practice when installing a PTF or
>product? Quackenbush says checking DDDEF's externally is unnecessary
>and will only take take the time required for APPLY CHECK.

You missed my point-APPLY CHECK happens after doing several steps already, and 
if the user needs to then get help with USS, they're now half-done and will 
either have to start over (because things changed) or at least have to remember 
where they were.

Yes, this should all be easy. Sad to say, it's not, for many customers, where 
the grizzled veterans have retired (or worse).

Failfast is A Good Thing.


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

Re: SMP/E and PATH existence

[Jon Perryman]

On Fri, 6 Oct 2023 15:46:25 +, Rob Scott  wrote:

>This was precisely the reason for the original implementation of DDDEFCHK/PTH.
>
>Being able to quickly sniff-test the DDDEFs (across multiple target/dlib 
>zones) before 
>an APPLY that might take many minutes was deemed useful (well .. at least to 
>me at the time...25 years ago)

Is APPLY CHECK no longer standard practice when installing a PTF or product? 
Quackenbush says checking DDDEF's externally is unnecessary and will only take 
take the time required for APPLY CHECK.

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

Re: SMP/E and PATH existence

[Rob Scott]

Phil

This was precisely the reason for the original implementation of DDDEFCHK/PTH.

It could be that you have cloned the CSI, or performed some updates via 
ZONEEDIT or just wanted to make sure that no-one had moved/deleted anything 
since last-known-good.

Being able to quickly sniff-test the DDDEFs (across multiple target/dlib zones) 
before an APPLY that might take many minutes was deemed useful (well .. at 
least to me at the time...25 years ago)

Rob
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Friday, October 6, 2023 1:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E and PATH existence

EXTERNAL EMAIL





Jon Perryman wrote:
>Kurt is saying that APPLY CHECK does exactly what you want. CHECK
>verifies SMP/e has everything expected and will run 100% through. If 3
>DD / DDDEF's are missing, then you should see those 3 errors and any
>other errors that SMP/e detects. APPLY CHECK only validates DD /
>DDDEF's that are needed for the apply and ignores all other DD /
>DDDEF's. I've never experienced missing DD / DDDEF's, so I'm basing
>this on Kurt's recommendation.

Yep, I got that, thanks. But understand that by that point, they're halfway 
through the install. Far better for it to fail first thing, so they can fix 
that and then run through the entire process. Remember how alien many z/OS 
folks think USS is.


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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SMP/E and PATH existence

[Phil Smith III]

Jon Perryman wrote:
>Kurt is saying that APPLY CHECK does exactly what you want. CHECK
>verifies SMP/e has everything expected and will run 100% through. If 3
>DD / DDDEF's are missing, then you should see those 3 errors and any
>other errors that SMP/e detects. APPLY CHECK only validates DD /
>DDDEF's that are needed for the apply and ignores all other DD /
>DDDEF's. I've never experienced missing DD / DDDEF's, so I'm basing
>this on Kurt's recommendation.

Yep, I got that, thanks. But understand that by that point, they're halfway 
through the install. Far better for it to fail first thing, so they can fix 
that and then run through the entire process. Remember how alien many z/OS 
folks think USS is.


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

Re: SMP/E and PATH existence

[Jon Perryman]

On Thu, 5 Oct 2023 19:09:45 -0400, Phil Smith III  wrote:

>Kurt Quackenbush wrote:
>>SMP/E APPLY CHECK and similar commands verify existence of directories

>Thanks. Since I really, really don't want them to get 3/4 of the way through 
> and then have to go hunt down someone with USS access

Phil,

Kurt is saying that APPLY CHECK does exactly what you want. CHECK verifies 
SMP/e has everything expected and will run 100% through. If 3 DD / DDDEF's are 
missing, then you should see those 3 errors and any other errors that SMP/e 
detects. APPLY CHECK only validates DD / DDDEF's that are needed for the apply 
and ignores all other DD / DDDEF's. I've never experienced missing DD / 
DDDEF's, so I'm basing this on Kurt's recommendation.

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

Re: SMP/E and PATH existence

[Phil Smith III]

Kurt Quackenbush wrote:
>SMP/E APPLY CHECK and similar commands verify existence of directories
>and data sets from DDDEF entries before they are used. There is no
>independent SMP/E command or utility to perform this verification.
>However, there is a capability in z/OSMF Software Management, the
>Software Instance Validation action, which does this kind of checking,
>among others.

Thanks. Since I really, really don't want them to get 3/4 of the way through 
and then have to go hunt down someone with USS access, I'll use 
BPXBATCH/IDCAMS. At least now I know I'm not missing something obvious!


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

Re: SMP/E and PATH existence

[Kurt Quackenbush]

>>A long time ago, I wrote a program called DDDEFCHK that used the SMP/E 
>>API to check if normal DDDEF data sets exist - there is also a DDDEFPTH 
>>companion program to handle paths.

> Ah, so that kinda confirms that SMP/E can't do it natively. I think 
> BPXBATCH/IDCAMS are a better bet for us, then-nothing to maintain. Thanks.

SMP/E APPLY CHECK and similar commands verify existence of directories and data 
sets from DDDEF entries before they are used.  There is no independent SMP/E 
command or utility to perform this verification.  However, there is a 
capability in z/OSMF Software Management, the Software Instance Validation 
action, which does this kind of checking, among others.

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: SMP/E and PATH existence

[Phil Smith III]

Rob Scott wrote:
>A long time ago, I wrote a program called DDDEFCHK that used the SMP/E
>API to check if normal DDDEF data sets exist - there is also a
>DDDEFPTH companion program to handle paths.

Ah, so that kinda confirms that SMP/E can't do it natively. I think 
BPXBATCH/IDCAMS are a better bet for us, then-nothing to maintain. Thanks.


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

Re: SMP/E and PATH existence

[Rob Scott]

Phil,

A long time ago, I wrote a program called DDDEFCHK that used the SMP/E API to 
check if normal DDDEF data sets exist - there is also a DDDEFPTH companion 
program to handle paths.

I believe these programs still exist in the public domain in the CBT tape site 
(www.cbttape.org) - see files 411 and 412.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Thursday, October 5, 2023 4:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMP/E and PATH existence

EXTERNAL EMAIL





Is there a way to get SMP/E to validate the existence of a USS path on a DDEF? 
Thanks to y'all's help, I have externalized the USS path we use to a variable. 
However, if the directory doesn't exist, the user can get pretty far (to the 
RECEIVE step) before that's recognized. I've looked at the SMP/E doc but didn't 
find anything.

I realize I can do this with BPXBATCH:
//TESTDIR  EXEC PGM=BPXBATCH,PARM='SH test -d &USSPATH'

Or with IDCAMS:
//TESTDIR  EXEC PGM=IDCAMS,PARM='GRAPHICS(CHAIN(SN))'
//SYSINDD *,SYMBOLS=(JCLONLY,JESJCL)
ALLOCATE   DDNAME(VSHZFS1) PATH('&USSPATH')

But this seems like something SMP/E might reasonably also do "natively". Can it?


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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SMP/E and USS

[Seymour J Metz]

Remember that JCLIN was originally intended to process sysgen stage 2 input, 
which used true names.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, September 6, 2023 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E and USS

On Wed, 6 Sep 2023 19:27:36 +, Seymour J Metz wrote:

>The SMP convention is that LINK is a hard link and SYMLINK is a soft link.
>
Long ago I was (disingenuously) dismayed to learn that in SMP/E Linkage
Editor JCLIN:
INCLUDE SYSLIB(alias-name)

... failed even though alias-name was specified as both TALIAS and DALIAS
on ++MOD MCS.

Worked in stand-alone JCL, so I went to SR.  Got WAD.

--
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: SMP/E and USS

[Pommier, Rex]

Thanks for letting me know the resolution.  My feeble brain had symbolic and 
hard links mixed up in my head and I was thinking the "l" in column 1 was a 
hard link indication.  

You are correct that the link doesn't take extra space.  It's just a second 
pointer to the same file.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Wednesday, September 6, 2023 4:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: SMP/E and USS

Rex wrote:
> Ok, that is odd now.

Ah hah: 
https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/2.5.0?topic=examples-example-3-packaging-sysmod-symbolic-link__;!!KjMRP1Ixj6eLE0Fj!t645dKiW3bDKpcK_6oh2U2C-xgM14CQMbuWtK5y2ET3O0P-JUVrdT1HpIJ6VA0stLjzGmPd-0N6yVR8$
  is an example showing:
++HFS(GSKAH010)

and says
When SMP/E installs file GSKAH010 into the directory specified on the given 
DDDEF entry, the LINK and SYMLINK values will be resolved relative to the DDDEF 
directory.

and sure enough, ls -i shows the same inode. So it's a hard link, and it's not 
actually taking space for the actual data, right? That I can live with. Might 
even note it in the doc, in case someone gets inquisitive and asks. Deleting 
the GSKAH010 version seems harmless (based on my testing-I can continue after 
doing so), but also pointless. I was mostly just concerned with leaving cruft 
that someone could ask about.

Thanks to all-it was Shmuel's comments about LINK and SYMLINK that got me to 
this. I hadn't noticed SYMLINK in the doc, since it wasn't using it, and I was 
in fact not even thinking that LINK meant, well, a link-more just that it was 
some SMP/E jargon. But seeing SYMLINK Ied me to thinking "Well, if LINK means a 
hard link."

Note that what I'm doing here is unwinding some undocumented work left by 
someone departed. It all works, but I want to understand it and optimize it as 
much as possible. I keep hoping that my fumbling through this stuff saves 
someone a few hours next week/month/year/decade.

And, as ever, thanks for the assistance. You never know what offhand remark is 
going to lead to enlightenment!


--
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: SMP/E and USS

[Phil Smith III]

Rex wrote:
> Ok, that is odd now.

Ah hah: 
https://www.ibm.com/docs/en/zos/2.5.0?topic=examples-example-3-packaging-sysmod-symbolic-link
 is an example showing:
++HFS(GSKAH010)

and says
When SMP/E installs file GSKAH010 into the directory specified on the given 
DDDEF entry, the LINK and SYMLINK values will be resolved relative to the DDDEF 
directory.

and sure enough, ls -i shows the same inode. So it's a hard link, and it's not 
actually taking space for the actual data, right? That I can live with. Might 
even note it in the doc, in case someone gets inquisitive and asks. Deleting 
the GSKAH010 version seems harmless (based on my testing-I can continue after 
doing so), but also pointless. I was mostly just concerned with leaving cruft 
that someone could ask about.

Thanks to all-it was Shmuel's comments about LINK and SYMLINK that got me to 
this. I hadn't noticed SYMLINK in the doc, since it wasn't using it, and I was 
in fact not even thinking that LINK meant, well, a link-more just that it was 
some SMP/E jargon. But seeing SYMLINK Ied me to thinking "Well, if LINK means a 
hard link."

Note that what I'm doing here is unwinding some undocumented work left by 
someone departed. It all works, but I want to understand it and optimize it as 
much as possible. I keep hoping that my fumbling through this stuff saves 
someone a few hours next week/month/year/decade.

And, as ever, thanks for the assistance. You never know what offhand remark is 
going to lead to enlightenment!


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

Re: [EXTERNAL] Re: SMP/E and USS

[Pommier, Rex]

Ok, that is odd now.  

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Wednesday, September 6, 2023 3:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: SMP/E and USS

Thanks, Rex-they are not symlinks, I did check that (and should have said so!). 
They're all
-rw-r--r--


--
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: SMP/E and USS

[Phil Smith III]

Thanks, Rex-they are not symlinks, I did check that (and should have said so!). 
They're all
-rw-r--r--


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

Re: SMP/E and USS

[Paul Gilmartin]

On Wed, 6 Sep 2023 19:27:36 +, Seymour J Metz wrote:

>The SMP convention is that LINK is a hard link and SYMLINK is a soft link.
>
Long ago I was (disingenuously) dismayed to learn that in SMP/E Linkage
Editor JCLIN:
INCLUDE SYSLIB(alias-name)

... failed even though alias-name was specified as both TALIAS and DALIAS
on ++MOD MCS.

Worked in stand-alone JCL, so I went to SR.  Got WAD.

-- 
gil

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

Re: SMP/E and USS

[Seymour J Metz]

The SMP convention is that LINK is a hard link and SYMLINK is a soft link.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, September 6, 2023 3:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E and USS

On Wed, 6 Sep 2023 18:57:25 +, Seymour J Metz wrote:

>LINK and SYMLINK are for alternate names.
>
Don't know SMP/E conventions.  But in UNIX jargon a "link" is an
ordinary directory entry identifying a file by its I-number.  There
may be multiple such links for a single file.  In contrast to PDSE
these are equipotent: there is no primary name with the others being
"aliases".  Unlike PDSE, these may reside in different directories,
but only in the same filesystem (like "volume".)

A symbolic link identifies a file by (one of) its name(s) and may reside
in a different filesystem, much like IDCAMS SYMBOLICRELATE
which allows the RELATED entry to be in a different catalog.

--
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: SMP/E and USS

[Paul Gilmartin]

On Wed, 6 Sep 2023 18:57:25 +, Seymour J Metz wrote:

>LINK and SYMLINK are for alternate names.
>
Don't know SMP/E conventions.  But in UNIX jargon a "link" is an
ordinary directory entry identifying a file by its I-number.  There
may be multiple such links for a single file.  In contrast to PDSE
these are equipotent: there is no primary name with the others being
"aliases".  Unlike PDSE, these may reside in different directories,
but only in the same filesystem (like "volume".)

A symbolic link identifies a file by (one of) its name(s) and may reside
in a different filesystem, much like IDCAMS SYMBOLICRELATE
which allows the RELATED entry to be in a different catalog.

-- 
gil

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

Re: SMP/E and USS

[Seymour J Metz]

LINK and SYMLINK are for alternate names.


From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Wednesday, September 6, 2023 1:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMP/E and USS

Consider this from an SMPMCS:

++HFS()DISTLIB(lll)

   SYSLIB(sss)

   BINARY

   LINK('lib/lib.a')

   PARM(PATHMODE(0,6,4,4))

   RELFILE(5) .



That creates, in the directory specified on the DDDEF for sss, file 
; and in the lib\ directory under that, lib.a.



These files are identical. I don't need the  for linking etc.; do I 
need it for later service or something? If it's not required, why did SMP/E 
leave it there?



Reading the doc found very little about this. It's not a huge deal, just kinda 
ugly, UNLESS it's required for some reason.  Yes, I could us SHSCRIPT to run a 
script to delete it, but that seems unlikely to be necessary just to remove 
cruft.


--
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: SMP/E usermod build question for DFSMSdss change

[Pommier, Rex]

Thanks, Mark, for validating what I was pretty sure was my initial screw-up - 
and how to fix it.  

And don't apologize for top-posting.  I much prefer it that way.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Zelden
Sent: Wednesday, July 26, 2023 4:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: SMP/E usermod build question for DFSMSdss change

Sorry for top posting.

Yes, you want to zap the MOD (CSECT).SMP/E knows all the LMODs it is 
relevant to
be it one LMOD as in this case or many LMODs. 

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
https://urldefense.com/v3/__http://www.mzelden.com/mvsutil.html__;!!KjMRP1Ixj6eLE0Fj!oyjJoyZBRS8DoUCbL9ujIbWkp3e33ySRKzWle6YDmVc55Iq4HhdTHnOqLzlJaXoYDwWav5uPnNDHR_xS$
 




On Wed, 26 Jul 2023 21:19:34 +, Pommier, Rex  
wrote:

>Hello list,
>
>I'm pretty sure I know what I did wrong and what I must do to fix it, but 
>would like validation from the SMP/E gurus here.  
>
>DFSMSdss has a module ADRPATCH for activating optional behavior.  The DFDSS 
>manual shows the use of AMASPZAP for turning these flags on/off.  Very simple 
>zap process (sorry for alignment).
>
>//ZAP EXEC PGM=AMASPZAP,PARM='IGNIDRFULL'  
>//SYSPRINT DD SYSOUT=* 
>//SYSLIB   DD DISP=SHR,DSN=SYS1.LINKLIB
>//SYSINDD *
>  NAME ADRDSSU ADRPATCH
>  VER  0058 00 
>  REP  0058 F0 
>
>I didn't want to lose the zap in case of maintenance so I built a usermod to 
>install it as such:
>
>//SMPCSI   DD DISP=SHR,DSN=SMPE.ZOS24.GLOBAL.CSI
>//SMPCNTL  DD * 
>  SET BDY(GLOBAL).  
>  RECEIVE SYSMODS SELECT(DSSPT58).  
>  SET BDY (MVST100) .   
>  APPLY   SELECT(DSSPT58)CHECKRETRY(YES).   
>/*  
>//SMPPTFIN DD * 
>++USERMOD(DSSPT58) .
>++VER (Z038) FMID(HDZ2240) PRE(UJ01310) .   
>++ZAP ( ADRDSSU ) . 
> NAME ADRPATCH  
> VER  0058 00   
> REP  0058 F0   
>/*  
>//  
>
>We needed to subsequently remove the usermod to apply maintenance to ADRDSSU 
>and to our dismay, after the usermod was restored, the flag was still set.  We 
>found this when, after applying the maintenance and adjusting the PRE in the 
>++VER, and trying to do the reject/receive/apply of the usermod, the apply 
>failed because the VER failed.  Looking at the ADRPATCH CSECT in the load 
>module confirmed this.  Looking at the restore job showed that the job did a 
>relink of ADRDSSU, pulling the MOD ADRDSSU from the DLIB and the rest of the 
>LMOD ADRDSSU (which includes ADRPATCH) from the currently running LINKLIB.  To 
>get around the mismatch where the zap was still in place in the loadmod but 
>SMP/E said it isn't, I manually zapped the flag back off.  
>
>What I'm thinking I should have done initially was, instead of zapping the 
>ADRDSSU load module, would have been to zap the MOD ADRPATCH like this:
>
>++ZAP ( ADRPATCH) . 
> NAME ADRPATCH  
> VER  0058 00   
> REP  0058 F0   
>
>In doing so, I think SMP/E would have put the zap onto ADRPATCH and relinked 
>ADRDSSU with the zapped version of ADRPATCH, then when we needed to restore 
>the usermod, SMP/E would have relinked ADRDSSU with the unzapped version of 
>ADRPATCH in the DLIB.Am I correct in my assessment?  
>
>TIA,Rex(and apologies for the length of the email but I wanted to 
>include all pertinent info)
>
>--
>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

Re: SMP/E usermod build question for DFSMSdss change

[Mark Zelden]

Sorry for top posting.

Yes, you want to zap the MOD (CSECT).SMP/E knows all the LMODs it is 
relevant to
be it one LMOD as in this case or many LMODs. 

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html




On Wed, 26 Jul 2023 21:19:34 +, Pommier, Rex  
wrote:

>Hello list,
>
>I'm pretty sure I know what I did wrong and what I must do to fix it, but 
>would like validation from the SMP/E gurus here.  
>
>DFSMSdss has a module ADRPATCH for activating optional behavior.  The DFDSS 
>manual shows the use of AMASPZAP for turning these flags on/off.  Very simple 
>zap process (sorry for alignment).
>
>//ZAP EXEC PGM=AMASPZAP,PARM='IGNIDRFULL'  
>//SYSPRINT DD SYSOUT=* 
>//SYSLIB   DD DISP=SHR,DSN=SYS1.LINKLIB
>//SYSINDD *
>  NAME ADRDSSU ADRPATCH
>  VER  0058 00 
>  REP  0058 F0 
>
>I didn't want to lose the zap in case of maintenance so I built a usermod to 
>install it as such:
>
>//SMPCSI   DD DISP=SHR,DSN=SMPE.ZOS24.GLOBAL.CSI
>//SMPCNTL  DD * 
>  SET BDY(GLOBAL).  
>  RECEIVE SYSMODS SELECT(DSSPT58).  
>  SET BDY (MVST100) .   
>  APPLY   SELECT(DSSPT58)CHECKRETRY(YES).   
>/*  
>//SMPPTFIN DD * 
>++USERMOD(DSSPT58) .
>++VER (Z038) FMID(HDZ2240) PRE(UJ01310) .   
>++ZAP ( ADRDSSU ) . 
> NAME ADRPATCH  
> VER  0058 00   
> REP  0058 F0   
>/*  
>//  
>
>We needed to subsequently remove the usermod to apply maintenance to ADRDSSU 
>and to our dismay, after the usermod was restored, the flag was still set.  We 
>found this when, after applying the maintenance and adjusting the PRE in the 
>++VER, and trying to do the reject/receive/apply of the usermod, the apply 
>failed because the VER failed.  Looking at the ADRPATCH CSECT in the load 
>module confirmed this.  Looking at the restore job showed that the job did a 
>relink of ADRDSSU, pulling the MOD ADRDSSU from the DLIB and the rest of the 
>LMOD ADRDSSU (which includes ADRPATCH) from the currently running LINKLIB.  To 
>get around the mismatch where the zap was still in place in the loadmod but 
>SMP/E said it isn't, I manually zapped the flag back off.  
>
>What I'm thinking I should have done initially was, instead of zapping the 
>ADRDSSU load module, would have been to zap the MOD ADRPATCH like this:
>
>++ZAP ( ADRPATCH) . 
> NAME ADRPATCH  
> VER  0058 00   
> REP  0058 F0   
>
>In doing so, I think SMP/E would have put the zap onto ADRPATCH and relinked 
>ADRDSSU with the zapped version of ADRPATCH, then when we needed to restore 
>the usermod, SMP/E would have relinked ADRDSSU with the unzapped version of 
>ADRPATCH in the DLIB.Am I correct in my assessment?  
>
>TIA,Rex(and apologies for the length of the email but I wanted to 
>include all pertinent info)
>
>--
>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: SMP/E RECEIVE ORDER server IP address changes

[Kurt J. Quackenbush]

The deed is done.  Sorry, I don't know on which day the final server migrated, 
but as of May 8 both eccgw01.boulder.ibm.com and eccgw02.rochester.ibm.com have 
new ip addresses.

https://www.ibm.com/support/pages/node/6856445

> Sure, I'll post up here after I get notified the server IP address migration 
> is complete.

>> Will there be more announcements, saying the new IPs and DNS entries are in 
>> place and when the old ones will be shut off?

>>> SMP/E RECEIVE ORDER users, take note of the planned IBM order server IP 
>>> address changes on March 23.
>>> https://www.ibm.com/support/pages/node/6856445

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: SMP/E JCLIN processing for job updates

[Bill Giannelli]

Hi Dave,
Thanks for the response.
No I am not editing the target data directly. We are working out of a pds 
separate from SMPe libraries.
The user mod looks like what I'm after. I will look into that..
On Fri, 21 Apr 2023 13:37:15 -0500, Dave Jousma  wrote:

>On Fri, 21 Apr 2023 13:10:19 -0500, Bill Giannelli  
>wrote:
>
>>various jobs for Db2 software maintenance, such as DSNTIJUZ DSNTIJUA DSNTIJRT.
>>Bill
>>On Fri, 21 Apr 2023 10:19:07 -0500, Dave Jousma  wrote:
>>
>>>On Fri, 21 Apr 2023 06:36:40 -0500, Bill Giannelli  
>>>wrote:
>>>
>
>So, those are DB2 jobs.   So what that tells me is that you might be editing 
>and using the SMPE target data, vs copying the JCL out to another library to 
>use?   If so, that’s really a no-no.   But if you want to make your changes 
>properly to that dataset so that SMPE knows about the changes, you would 
>create a USERMOD to replace the JCL with your customized JCL after merging in 
>any changes made by the maintenance.   A USERMOD will then tell you when a PTF 
>will overwrite the JCL, and will be the signal to 1) remove your usermod and 
>apply the PTF, and 2) re-work your usermod, and re-apply it.
>
>--
>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: SMP/E JCLIN processing for job updates

[Dave Jousma]

On Fri, 21 Apr 2023 13:10:19 -0500, Bill Giannelli  
wrote:

>various jobs for Db2 software maintenance, such as DSNTIJUZ DSNTIJUA DSNTIJRT.
>Bill
>On Fri, 21 Apr 2023 10:19:07 -0500, Dave Jousma  wrote:
>
>>On Fri, 21 Apr 2023 06:36:40 -0500, Bill Giannelli  
>>wrote:
>>

So, those are DB2 jobs.   So what that tells me is that you might be editing 
and using the SMPE target data, vs copying the JCL out to another library to 
use?   If so, that’s really a no-no.   But if you want to make your changes 
properly to that dataset so that SMPE knows about the changes, you would create 
a USERMOD to replace the JCL with your customized JCL after merging in any 
changes made by the maintenance.   A USERMOD will then tell you when a PTF will 
overwrite the JCL, and will be the signal to 1) remove your usermod and apply 
the PTF, and 2) re-work your usermod, and re-apply it.

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

Re: SMP/E JCLIN processing for job updates

[Bill Giannelli]

various jobs for Db2 software maintenance, such as DSNTIJUZ DSNTIJUA DSNTIJRT.
Bill
On Fri, 21 Apr 2023 10:19:07 -0500, Dave Jousma  wrote:

>On Fri, 21 Apr 2023 06:36:40 -0500, Bill Giannelli  
>wrote:
>
>>Do many of you out there use SMP/E JCLIN processing to track and save job 
>>updates?
>>Currently we do not make use of this and manually keep JCL up to date.
>>It seems there is a value to have SMPe ke  
>>
>
>Bill,
>
>No one has asked yet, but I'm curious what JCL specifically, you are talking 
>about, and needing to keep up to date?
>
>--
>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: SMP/E JCLIN processing for job updates

[Tom Brennan]

But to be clear, this all has nothing to do with (mentioned) JCLIN 
processing, right?


On 4/21/2023 8:51 AM, David Spiegel wrote:

Hi Bill,
You could treat JCL (with line numbers on) as a ++MAC in SMP.
Each "PTF" (++MACUPD) could be IEBUPDTE Control cards (e.g. ./ CHANGE 
followed by numbered "cards".


Regards,
David


On 2023-04-21 08:51, Bill Giannelli wrote:

SCLM seems geared towards COBOL and PLI not JCL?
On Fri, 21 Apr 2023 22:18:52 +1000, Wayne Bickerdike 
 wrote:



Bill,

If SCLM is installed there is a sample project you can work from. That
should be a good starter.

There is a set of JCL members to set up a project, use that as a basis.

Any questions, just keep asking away.

On Fri, Apr 21, 2023 at 9:57 PM Bill Giannelli 
wrote:


Hi Wayne,
I see SCLM now in ISPF. I wasnt aware of it.
Is the IBM online doc good enough for a SCLM newbie?
thanks
Bill
On Fri, 21 Apr 2023 06:48:00 -0500, Bill Giannelli <
billgianne...@gmail.com> wrote:


hi wayne,
what is SCLM?
On Fri, 21 Apr 2023 21:43:25 +1000, Wayne Bickerdike 


wrote:

I would use SCLM if you don't have another source management tool.

On Fri, Apr 21, 2023 at 9:37 PM Bill Giannelli 


wrote:

Do many of you out there use SMP/E JCLIN processing to track and 
save

job

updates?
Currently we do not make use of this and manually keep JCL up to 
date.

It seems there is a value to have SMPe ke

-- 


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

--
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



--
Wayne V. Bickerdike

--
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: SMP/E JCLIN processing for job updates

[David Spiegel]

Hi Bill,
You could treat JCL (with line numbers on) as a ++MAC in SMP.
Each "PTF" (++MACUPD) could be IEBUPDTE Control cards (e.g. ./ CHANGE 
followed by numbered "cards".


Regards,
David


On 2023-04-21 08:51, Bill Giannelli wrote:

SCLM seems geared towards COBOL and PLI not JCL?
On Fri, 21 Apr 2023 22:18:52 +1000, Wayne Bickerdike  wrote:


Bill,

If SCLM is installed there is a sample project you can work from. That
should be a good starter.

There is a set of JCL members to set up a project, use that as a basis.

Any questions, just keep asking away.

On Fri, Apr 21, 2023 at 9:57 PM Bill Giannelli 
wrote:


Hi Wayne,
I see SCLM now in ISPF. I wasnt aware of it.
Is the IBM online doc good enough for a SCLM newbie?
thanks
Bill
On Fri, 21 Apr 2023 06:48:00 -0500, Bill Giannelli <
billgianne...@gmail.com> wrote:


hi wayne,
what is SCLM?
On Fri, 21 Apr 2023 21:43:25 +1000, Wayne Bickerdike 

wrote:

I would use SCLM if you don't have another source management tool.

On Fri, Apr 21, 2023 at 9:37 PM Bill Giannelli 
wrote:


Do many of you out there use SMP/E JCLIN processing to track and save

job

updates?
Currently we do not make use of this and manually keep JCL up to date.
It seems there is a value to have SMPe ke

--
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

--
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



--
Wayne V. Bickerdike

--
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: SMP/E JCLIN processing for job updates

[Dave Jousma]

On Fri, 21 Apr 2023 06:36:40 -0500, Bill Giannelli  
wrote:

>Do many of you out there use SMP/E JCLIN processing to track and save job 
>updates?
>Currently we do not make use of this and manually keep JCL up to date.
>It seems there is a value to have SMPe ke  
>

Bill,

No one has asked yet, but I'm curious what JCL specifically, you are talking 
about, and needing to keep up to date?

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

Re: SMP/E JCLIN processing for job updates

[Rob Scott]

SCLM has been functionality stabilized for many years now - I would suggest 
trying to find another alternative.

Perhaps use Git for z/OS ?

You could maintain the master JCL in zFS directories under Git control with a 
"deployment" method to copy to run-time PDS/Es.

There is also Lionel Dyke's "zigi" tool that might be of interest.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: 21 April 2023 12:57
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E JCLIN processing for job updates

EXTERNAL EMAIL





Hi Wayne,
I see SCLM now in ISPF. I wasnt aware of it.
Is the IBM online doc good enough for a SCLM newbie?
thanks
Bill
On Fri, 21 Apr 2023 06:48:00 -0500, Bill Giannelli  
wrote:

>hi wayne,
>what is SCLM?
>On Fri, 21 Apr 2023 21:43:25 +1000, Wayne Bickerdike  wrote:
>
>>I would use SCLM if you don't have another source management tool.
>>
>>On Fri, Apr 21, 2023 at 9:37 PM Bill Giannelli
>>
>>wrote:
>>
>>> Do many of you out there use SMP/E JCLIN processing to track and
>>> save job updates?
>>> Currently we do not make use of this and manually keep JCL up to date.
>>> It seems there is a value to have SMPe ke
>>>
>>> 
>>> -- 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
>
>--
>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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SMP/E JCLIN processing for job updates

[Bill Giannelli]

SCLM seems geared towards COBOL and PLI not JCL?
On Fri, 21 Apr 2023 22:18:52 +1000, Wayne Bickerdike  wrote:

>Bill,
>
>If SCLM is installed there is a sample project you can work from. That
>should be a good starter.
>
>There is a set of JCL members to set up a project, use that as a basis.
>
>Any questions, just keep asking away.
>
>On Fri, Apr 21, 2023 at 9:57 PM Bill Giannelli 
>wrote:
>
>> Hi Wayne,
>> I see SCLM now in ISPF. I wasnt aware of it.
>> Is the IBM online doc good enough for a SCLM newbie?
>> thanks
>> Bill
>> On Fri, 21 Apr 2023 06:48:00 -0500, Bill Giannelli <
>> billgianne...@gmail.com> wrote:
>>
>> >hi wayne,
>> >what is SCLM?
>> >On Fri, 21 Apr 2023 21:43:25 +1000, Wayne Bickerdike 
>> wrote:
>> >
>> >>I would use SCLM if you don't have another source management tool.
>> >>
>> >>On Fri, Apr 21, 2023 at 9:37 PM Bill Giannelli 
>> >>wrote:
>> >>
>> >>> Do many of you out there use SMP/E JCLIN processing to track and save
>> job
>> >>> updates?
>> >>> Currently we do not make use of this and manually keep JCL up to date.
>> >>> It seems there is a value to have SMPe ke
>> >>>
>> >>> --
>> >>> 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
>> >
>> >--
>> >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
>>
>
>
>-- 
>Wayne V. Bickerdike
>
>--
>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: SMP/E JCLIN processing for job updates

[Wayne Bickerdike]

Bill,

If SCLM is installed there is a sample project you can work from. That
should be a good starter.

There is a set of JCL members to set up a project, use that as a basis.

Any questions, just keep asking away.

On Fri, Apr 21, 2023 at 9:57 PM Bill Giannelli 
wrote:

> Hi Wayne,
> I see SCLM now in ISPF. I wasnt aware of it.
> Is the IBM online doc good enough for a SCLM newbie?
> thanks
> Bill
> On Fri, 21 Apr 2023 06:48:00 -0500, Bill Giannelli <
> billgianne...@gmail.com> wrote:
>
> >hi wayne,
> >what is SCLM?
> >On Fri, 21 Apr 2023 21:43:25 +1000, Wayne Bickerdike 
> wrote:
> >
> >>I would use SCLM if you don't have another source management tool.
> >>
> >>On Fri, Apr 21, 2023 at 9:37 PM Bill Giannelli 
> >>wrote:
> >>
> >>> Do many of you out there use SMP/E JCLIN processing to track and save
> job
> >>> updates?
> >>> Currently we do not make use of this and manually keep JCL up to date.
> >>> It seems there is a value to have SMPe ke
> >>>
> >>> --
> >>> 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
> >
> >--
> >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
>


-- 
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: SMP/E JCLIN processing for job updates

[Bill Giannelli]

Hi Wayne,
I see SCLM now in ISPF. I wasnt aware of it.
Is the IBM online doc good enough for a SCLM newbie?
thanks
Bill
On Fri, 21 Apr 2023 06:48:00 -0500, Bill Giannelli  
wrote:

>hi wayne,
>what is SCLM?
>On Fri, 21 Apr 2023 21:43:25 +1000, Wayne Bickerdike  wrote:
>
>>I would use SCLM if you don't have another source management tool.
>>
>>On Fri, Apr 21, 2023 at 9:37 PM Bill Giannelli 
>>wrote:
>>
>>> Do many of you out there use SMP/E JCLIN processing to track and save job
>>> updates?
>>> Currently we do not make use of this and manually keep JCL up to date.
>>> It seems there is a value to have SMPe ke
>>>
>>> --
>>> 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
>
>--
>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: SMP/E JCLIN processing for job updates

[Bill Giannelli]

hi wayne,
what is SCLM?
On Fri, 21 Apr 2023 21:43:25 +1000, Wayne Bickerdike  wrote:

>I would use SCLM if you don't have another source management tool.
>
>On Fri, Apr 21, 2023 at 9:37 PM Bill Giannelli 
>wrote:
>
>> Do many of you out there use SMP/E JCLIN processing to track and save job
>> updates?
>> Currently we do not make use of this and manually keep JCL up to date.
>> It seems there is a value to have SMPe ke
>>
>> --
>> 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

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

Re: SMP/E JCLIN processing for job updates

[Wayne Bickerdike]

I would use SCLM if you don't have another source management tool.

On Fri, Apr 21, 2023 at 9:37 PM Bill Giannelli 
wrote:

> Do many of you out there use SMP/E JCLIN processing to track and save job
> updates?
> Currently we do not make use of this and manually keep JCL up to date.
> It seems there is a value to have SMPe ke
>
> --
> 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: SMP)e

[Paul Gilmartin]

On Fri, 10 Mar 2023 23:17:09 -0600, Brian Westerman wrote:

>That's the main reason they want you to do these individually, they are really 
>big.
>
I suspect it's a genuine functional dependency.  Imagine a scenario:

PTFA upgrades the assembler by adding a new opcode.

PTFB contains a ++SRC element that uses that new opcode.

The assembler step for PTFB can not run before the load module
updates of PTFA are complete, but SMP/E generally performs
assembler steps before binder steps.

An RFE could provide for "firm" prerequisites such that SMP/E
performs all steps of the prerequisite PTF before any steps of
the dependent PTF.

-- 
gil

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

Re: SMP)e

[Brian Westerman]

That's the main reason they want you to do these individually, they are really 
big.

Brian

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

Re: SMP)e

[Paul Gilmartin]

On Fri, 10 Mar 2023 13:36:33 +, Seymour J Metz  wrote:

>Maybe it's time for an RFE. Is there a business case for a new hold class to 
>address this? something like MANUALPRE(UY12345)?
>
Not a new hold class, which would require multiple jobs with a BYPASS, but a
new sub-operand of PRE to automate the entire process, e.g.:
PRE((UY12345,SERIAL),...), requiring serial operations.

Doesn't "make" e.g. handle this correctly?  If a target appears as a 
prerequisite
of another target, the operations the targets will be built sequentially, in 
order.

-- 
gil

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

Re: SMP)e

[Steve Beaver]

The PTF I referenced. My smpwrk is a M54. The PTF is so large I had to add a 
second volume to be able to get the PTF applied 

Sent from my iPhone

No one said I could type with one thumb 

> On Mar 10, 2023, at 06:52, Allan Staller 
> <0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Classification: Confidential
> 
> I ask IBM and the said to install the PTFs serially to get around this issue.
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Steve Beaver
> Sent: Thursday, March 9, 2023 1:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: FW: SMP)e
> 
> [CAUTION: This Email is from outside the Organization. Unless you trust the 
> sender, Don’t click links or open attachments as it may be a Phishing email, 
> which can steal your Information and compromise your Computer.]
> 
> Are any of you that are having the following error in SMPe?  And if you
> 
> Have had it - How did you get passed it
> 
> 
> 
> GIM24608E ** SHELLSCR ENTRY BBLS2009 IS NEEDED TO PROCESS HFS BBL20009 FOR
> 
>  SYSMOD UI76945, BUT SHELLSCR BBLS2009 IS NOT IN THE MVST100 ZONE.
> 
> 
> 
> TIA
> 
> Steve
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> ::DISCLAIMER::
> 
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only. E-mail transmission is not 
> guaranteed to be secure or error-free as information could be intercepted, 
> corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses 
> in transmission. The e mail and its contents (with or without referred 
> errors) shall therefore not attach any liability on the originator or HCL or 
> its affiliates. Views or opinions, if any, presented in this email are solely 
> those of the author and may not necessarily reflect the views or opinions of 
> HCL or its affiliates. Any form of reproduction, dissemination, copying, 
> disclosure, modification, distribution and / or publication of this message 
> without the prior written consent of authorized representative of HCL is 
> strictly prohibited. If you have received this email in error please delete 
> it and notify the sender immediately. Before opening any email and/or 
> attachments, please check them for viruses and other defects.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / arc

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

Re: SMP)e

[Seymour J Metz]

Maybe it's time for an RFE. Is there a business case for a new hold class to 
address this? something like MANUALPRE(UY12345)?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Barbara Nitz [nitz-...@gmx.net]
Sent: Friday, March 10, 2023 12:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP)e

>I am assuming this is for z/OS 2.4.  At my current employer, I have the PTF 
>applied.  I think that at my past employer, I ran into the same problem you 
>did.  I never was able to resolve the error at the previous employer.
>
>The only difference between old employer and new employer, was the date of the 
>receiving of cumulative maintenance.  Previous employer, date of receiving 
>cumulative maintenance was third quarter 2021, current employer second quarter 
>of 2022.

I have run into this a number of times for different ptfs, starting back in 
z/OS 2.3. In the easy case I had the 'required' ptf (i.e. the ptf that was 
giving me the instructions on how to do the setup) already received or received 
in the same batch.

Despite using groupextent, that ptf's hold actions never showed up in the apply 
check output. Because it was not installable, and hold actions are only shown 
for installable ptfs. I had to go back to the smppts and browse the thing 
manually to get at the install instructions. This always happened when both the 
ptf and it's prereq were received at the same time. Provided IBM had bothered 
to even provide a prereq ptf. I remember one DFHSM ptf in 2.3 that just didn't 
have install instructions. I was lucky that that ptf was already in the 2.5 
base when I got 2.5.
I also had a case where I was unable to find out what the install instructions 
were. That ptf still hangs around in my 2.5 smppts. Since it's for a function 
we don't use, I don't much care. Until it impacts something we need due to 
coreqs.:-(

Best regards, Barbara

--
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: SMP)e

[Seymour J Metz]

Was there a HOLD un the PTF with an explanation that it had to be on a separate 
APPLY from the prereq?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Barbara Nitz [nitz-...@gmx.net]
Sent: Friday, March 10, 2023 4:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP)e

>No the problem is that you can't install these particular PTFs with everything 
>else, they have to be performed separately via an Apply the PTF by itself with 
>NO Groupextend and then Apply the
> remaining PTF's needed from the original Apply.

This is exactly what I did when I encountered this. First apply ptf A, then ptf 
B that needs whatever new path or something. The problem for me has always been 
to identify ptf A because ptf B's holddata don't show up on the apply check. 
And sometimes I just had to walk through each of the ++pre's of B to find it. 
Cumbersome is too easy a word for this process.

Regards, Barbara

--
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: SMP)e

[Ann Kelley]

See  IO27985: GIM24608E ** SHELLSCR ENTRY BBLS1803 IS NEEDED TO PROCESS HFS 
SYSMOD UI65815, BUT SHELLSCR BBLS1803 IS NOT IN THE SZMR0G ZONE.

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

Re: SMP)e

[Allan Staller]

Classification: Confidential

I ask IBM and the said to install the PTFs serially to get around this issue.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Thursday, March 9, 2023 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: FW: SMP)e

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Are any of you that are having the following error in SMPe?  And if you

Have had it - How did you get passed it



GIM24608E ** SHELLSCR ENTRY BBLS2009 IS NEEDED TO PROCESS HFS BBL20009 FOR

  SYSMOD UI76945, BUT SHELLSCR BBLS2009 IS NOT IN THE MVST100 ZONE.



TIA

Steve


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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


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

Re: SMP)e

[Barbara Nitz]

>No the problem is that you can't install these particular PTFs with everything 
>else, they have to be performed separately via an Apply the PTF by itself with 
>NO Groupextend and then Apply the
> remaining PTF's needed from the original Apply.

This is exactly what I did when I encountered this. First apply ptf A, then ptf 
B that needs whatever new path or something. The problem for me has always been 
to identify ptf A because ptf B's holddata don't show up on the apply check. 
And sometimes I just had to walk through each of the ++pre's of B to find it. 
Cumbersome is too easy a word for this process.

Regards, Barbara

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

Re: SMP)e

[Brian Westerman]

No the problem is that you can't install these particular PTFs with everything 
else, they have to be performed separately via an Apply the PTF by itself with 
NO Groupextend and then Apply the
 remaining PTF's needed from the original Apply.

Like:
APPLY S(UI76945)
BYPASS(HOLDSYSTEM)
CHECK.

Then after you see that works run it without the CHECK and you will be fine to 
go back and APPLY CHECK the rest of the RSU.  The important part is that you 
can't do these at the same time you do the rest of the RSU.  It sucks, but it 
is what it is.

You need to do this for all of the affected ptfs.  You can run them one after 
the other in the same job, but you MUST list them individually on a separate 
APPLY statement.  

There is a list job you can run to get them all so that you can put a single 
job together, but I don't remember the component that you are supposed to list.

This is a "new" thing that IBM is doing because if you try to do other PTFs at 
the same time, it can fail to do everything that it should do.

Brian

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

Re: SMP)e

[Barbara Nitz]

>I am assuming this is for z/OS 2.4.  At my current employer, I have the PTF 
>applied.  I think that at my past employer, I ran into the same problem you 
>did.  I never was able to resolve the error at the previous employer.  
>
>The only difference between old employer and new employer, was the date of the 
>receiving of cumulative maintenance.  Previous employer, date of receiving 
>cumulative maintenance was third quarter 2021, current employer second quarter 
>of 2022.  

I have run into this a number of times for different ptfs, starting back in 
z/OS 2.3. In the easy case I had the 'required' ptf (i.e. the ptf that was 
giving me the instructions on how to do the setup) already received or received 
in the same batch.

Despite using groupextent, that ptf's hold actions never showed up in the apply 
check output. Because it was not installable, and hold actions are only shown 
for installable ptfs. I had to go back to the smppts and browse the thing 
manually to get at the install instructions. This always happened when both the 
ptf and it's prereq were received at the same time. Provided IBM had bothered 
to even provide a prereq ptf. I remember one DFHSM ptf in 2.3 that just didn't 
have install instructions. I was lucky that that ptf was already in the 2.5 
base when I got 2.5. 
I also had a case where I was unable to find out what the install instructions 
were. That ptf still hangs around in my 2.5 smppts. Since it's for a function 
we don't use, I don't much care. Until it impacts something we need due to 
coreqs.:-(

Best regards, Barbara

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

Re: SMP/E RECEIVE ORDER server IP address changes

[Dana Mitchell]

On Fri, 3 Mar 2023 13:06:47 -0600, Paul Gilmartin  wrote:

>1141 $ date; nslookup eccgw.eastdata.ibm.com
>Fri Mar  3 11:35:00 MST 2023
>Non-authoritative answer:
>Name:   eccgw.eastdata.ibm.com
>Address: 170.225.123.67
>1142 $
>
>... so apparently both hostnames are now known to DNS.  Administrators can 
>simply enter both
>(sets of) IP addresses in firewall.  Programmers can use the old hostnames 
>(which will remain
>valid), switch at the appropriate time, and firewall administrators can then 
>remove the old ones.
>
>Service can be seamless; timing is not critical.
>

I'm testing with the new host name but getting 'Connection failed.'.I 
wonder if the new address is really active yet?  or my firewall is still 
blocking perhaps.

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

Re: SMP/E RECEIVE ORDER server IP address changes

[Paul Gilmartin]

On Wed, 1 Mar 2023 18:24:54 +, Kurt J. Quackenbush wrote:

>SMP/E RECEIVE ORDER users, take note of the planned IBM order server IP 
>address changes on March 23.
>https://www.ibm.com/support/pages/node/6856445
>
Thanks.  Testing a minimal sample from that page:
1140 $ date; nslookup eccgw01.boulder.ibm.com
Fri Mar  3 11:33:10 MST 2023
Non-authoritative answer:
Name:   eccgw01.boulder.ibm.com
Address: 207.25.252.197

1141 $ date; nslookup eccgw.eastdata.ibm.com
Fri Mar  3 11:35:00 MST 2023
Non-authoritative answer:
Name:   eccgw.eastdata.ibm.com
Address: 170.225.123.67
1142 $

... so apparently both hostnames are now known to DNS.  Administrators can 
simply enter both
(sets of) IP addresses in firewall.  Programmers can use the old hostnames 
(which will remain
valid), switch at the appropriate time, and firewall administrators can then 
remove the old ones.

Service can be seamless; timing is not critical.

-- 
gil

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

Re: SMP/E RECEIVE ORDER server IP address changes

[Doug Henry]

Hi Curt,
Thanks we are using that IP address since the change. Maybe it is just some 
problem with Bouder's site. 

Thanks. 
Doug

Regarding testcase.boulder.ibm.com, I thought the IP address changed last year:
https://www.ibm.com/support/pages/node/6587781

> I know this is not your area but when sending to Testcase today with z/OSMF 
> failed because we don't have this in are firewall. I didn't see any 
> notification for this.

> testcase.boulder.ibm.com >  Connecting to: testcase-yellow.southdata.ibm.com 
> 170.225.126.22 port: 21.:  

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

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

Re: SMP/E RECEIVE ORDER server IP address changes

[Kurt J. Quackenbush]

Regarding testcase.boulder.ibm.com, I thought the IP address changed last year:
https://www.ibm.com/support/pages/node/6587781

> I know this is not your area but when sending to Testcase today with z/OSMF 
> failed because we don't have this in are firewall. I didn't see any 
> notification for this.

> testcase.boulder.ibm.com >  Connecting to: testcase-yellow.southdata.ibm.com 
> 170.225.126.22 port: 21.:  

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

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

Re: SMP/E RECEIVE ORDER server IP address changes

[Doug Henry]

Hi Kurt,
I know this is not your area but when sending to Testcase today with z/OSMF 
failed because we don't have this in are firewall. I didn't see any 
notification for this.

testcase.boulder.ibm.com >  Connecting to: testcase-yellow.southdata.ibm.com 
170.225.126.22 port: 21.:  

Doug


On Fri, 3 Mar 2023 13:22:36 +, Kurt J. Quackenbush  wrote:

>Sure, I'll post up here after I get notified the server IP address migration 
>is complete.
>
>> Will there be more announcements, saying the new IPs and DNS entries are in 
>> place and when the old ones will be shut off?
>
>>> SMP/E RECEIVE ORDER users, take note of the planned IBM order server IP 
>>> address changes on March 23.
>>> https://www.ibm.com/support/pages/node/6856445 
>
>Kurt Quackenbush
>IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com
>
>

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

Re: SMP/E RECEIVE ORDER server IP address changes

[Kurt J. Quackenbush]

Sure, I'll post up here after I get notified the server IP address migration is 
complete.

> Will there be more announcements, saying the new IPs and DNS entries are in 
> place and when the old ones will be shut off?

>> SMP/E RECEIVE ORDER users, take note of the planned IBM order server IP 
>> address changes on March 23.
>> https://www.ibm.com/support/pages/node/6856445 

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: SMP/E RECEIVE ORDER server IP address changes

[Paul Gilmartin]

On Thu, 2 Mar 2023 21:14:31 +, Pommier, Rex wrote:

>Hi Kurt,
>
>Will there be more announcements, saying the new IPs and DNS entries are in 
>place and when the old ones will be shut off?
>
And/or update the cited site when "... or soon afterwards." becomes a firm date.

(If IBM owns both IP ranges, couldn't they refer to the same host for a period 
of
toleration?)

(For amusement, try "nslookup blackhole.nyx.net".  -- There was a reason for 
that.)

>-Original Message-
>From: IBM Mainframe Discussion List  On Behalf Of 
>Kurt J. Quackenbush
>Sent: Wednesday, March 1, 2023 12:25 PM
>
>SMP/E RECEIVE ORDER users, take note of the planned IBM order server IP 
>address changes on March 23.
>https://urldefense.com/v3/__https://www.ibm.com/support/pages/node/6856445__;!!KjMRP1Ixj6eLE0Fj!pXhHM269ze-arLEBFFWQyJqtu91Dt4Wh2-Osz8YaAZ4c6aW-y6KknttLgkiGq2_cN5eWzXM9DhDWlN12$
> 

-- 
gil

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

Re: SMP/E RECEIVE ORDER server IP address changes

[Pommier, Rex]

Hi Kurt,

Will there be more announcements, saying the new IPs and DNS entries are in 
place and when the old ones will be shut off?

Thanks,

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kurt J. Quackenbush
Sent: Wednesday, March 1, 2023 12:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] SMP/E RECEIVE ORDER server IP address changes

SMP/E RECEIVE ORDER users, take note of the planned IBM order server IP address 
changes on March 23.
https://urldefense.com/v3/__https://www.ibm.com/support/pages/node/6856445__;!!KjMRP1Ixj6eLE0Fj!pXhHM269ze-arLEBFFWQyJqtu91Dt4Wh2-Osz8YaAZ4c6aW-y6KknttLgkiGq2_cN5eWzXM9DhDWlN12$
 

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

--
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: SMP/E RECEIVE ORDER server IP address changes

[Dana Mitchell]

On Wed, 1 Mar 2023 13:09:58 -0600, Paul Gilmartin  wrote:

>On Wed, 1 Mar 2023 18:24:54 +, Kurt J. Quackenbush wrote:
>
>>SMP/E RECEIVE ORDER users, take note of the planned IBM order server IP 
>>address changes on March 23.
>>https://www.ibm.com/support/pages/node/6856445
>>
>Why should users be concerned with the IP address rather than relying on the
>domain name, which will remain valid?
>

Our firewall rules are based on the IP address not host name.  Those will have 
to be updated accordingly.

Dana

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

Re: SMP/E RECEIVE ORDER server IP address changes

[Mike Schwab]

Sometimes there are hiccups in the transition due to DNS caching.

On Wed, Mar 1, 2023 at 1:10 PM Paul Gilmartin
<042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Wed, 1 Mar 2023 18:24:54 +, Kurt J. Quackenbush wrote:
>
> >SMP/E RECEIVE ORDER users, take note of the planned IBM order server IP 
> >address changes on March 23.
> >https://www.ibm.com/support/pages/node/6856445
> >
> Why should users be concerned with the IP address rather than relying on the
> domain name, which will remain valid?
>
> "The host names are changing, but the existing host/domain will
> exist as an alias to the new hosts."
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: SMP/E RECEIVE ORDER server IP address changes

[Paul Gilmartin]

On Wed, 1 Mar 2023 18:24:54 +, Kurt J. Quackenbush wrote:

>SMP/E RECEIVE ORDER users, take note of the planned IBM order server IP 
>address changes on March 23.
>https://www.ibm.com/support/pages/node/6856445
>
Why should users be concerned with the IP address rather than relying on the
domain name, which will remain valid?

"The host names are changing, but the existing host/domain will
exist as an alias to the new hosts."

-- 
gil

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