Re: SMPE HOLDDATA - when received?

[Kurt Quackenbush]

> Does gimapi has access to this data?

No.

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: SMPE HOLDDATA - when received?

[ITschak Mugzach]

Does gimapi has access to this data?

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





בתאריך יום ד׳, 17 בינו׳ 2024 ב-22:36 מאת Kurt Quackenbush :

> > How can I check the date of HOLDDATA in my SMPE CSI?
>
> Examining the SMPLOG as already mentioned is one option.
>
> Another:  SMP/E does maintain the date each ++HOLD statement was received,
> but it does not expose it, not even in the CSI Query API.  However, z/OSMF
> Software Management has two reports which query the HOLDDATA and both
> expose that date.  So, if you define a Software Instance for your installed
> software you can perform the Maintenance Reports -> Missing Critical
> Service or Missing FIXCAT SYSMODs actions.  The resulting reports contain a
> "HOLDDATA Received" column indicating the most recent date ERROR or FIXCAT
> HOLDDATA was received into the global zone.
>
> 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: SMPE HOLDDATA - when received?

[Kurt Quackenbush]

> How can I check the date of HOLDDATA in my SMPE CSI?

Examining the SMPLOG as already mentioned is one option.

Another:  SMP/E does maintain the date each ++HOLD statement was received, but 
it does not expose it, not even in the CSI Query API.  However, z/OSMF Software 
Management has two reports which query the HOLDDATA and both expose that date.  
So, if you define a Software Instance for your installed software you can 
perform the Maintenance Reports -> Missing Critical Service or Missing FIXCAT 
SYSMODs actions.  The resulting reports contain a "HOLDDATA Received" column 
indicating the most recent date ERROR or FIXCAT HOLDDATA was received into the 
global zone.

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: SMPE HOLDDATA - when received?

[Tom Marchant]

Look at your SMPLOG for the most recent RECEIVE HOLDDATA.
Once you find it, look at that line in hex. The first few bytes is the date and 
time in packed decimal.

-- 
Tom Marchant

On Wed, 17 Jan 2024 17:47:33 +0100, Radoslaw Skorupka  
wrote:

>How can I check the date of HOLDDATA in my SMPE CSI?
>
>
>--
>Radoslaw Skorupka
>Lodz, Poland
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: SMPe securing zones

[Kurt J. Quackenbush]

> I've found that GIMSMP opens the datasets in UPDATE mode, so the user will 
> still need UPDATE or higher access.  READ access fails when the program 
> starts.

That is not true for all SMP/E commands.  LIST for example, or the REPORT 
commands, and the ISPF Query dialog, definitely open the SMPCSI data sets in 
READ mode.  But if you're complaining about APPLY CHECK, then yes, APPLY CHECK 
does open the SMPCSI data sets for UPDATE.

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: SMPe securing zones

[Mark Jacobs]

That's disappointing. It's not being done now, but another good way to handle 
that problem is to enhance the GIM.* Facility class profiles to include zone 
support for commands. User can run certain zone altering SMP/e commands against 
TZONE1, but not TZONE2. Something like that. 

Mark Jacobs 

Sent from ProtonMail, Swiss-based encrypted email.

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


--- Original Message ---
On Monday, March 27th, 2023 at 5:39 PM, Matthew Stitt 
 wrote:


> I've found that GIMSMP opens the datasets in UPDATE mode, so the user will 
> still need UPDATE or higher access. READ access fails when the program starts.
> 
> I've growled that GIMSMP needs to open in READ mode, then close/open in the 
> desired UPDATE mode if needed.
> 
> Matthew
> 
> On Mon, 27 Mar 2023 13:50:28 +, Mark Jacobs markjac...@protonmail.com 
> wrote:
> 
> > If you have those zones in their own CSI datasets, you can use your 
> > security system just to allow READ access.
> > 
> > Mark Jacobs
> > 
> > Sent from ProtonMail, Swiss-based encrypted email.
> > 
> > GPG Public Key - 
> > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
> > 
> > --- Original Message ---
> > On Monday, March 27th, 2023 at 9:46 AM, Bill Giannelli 
> > billgianne...@gmail.com wrote:
> > 
> > > I want to create another TARGET and DLIB zone for another level of 
> > > maintenance.
> > > I am currently, showing "newbie" offshore folks our SMPe environment.
> > > Is there a way to "secure" the newly created TARGET and DLIB zones so 
> > > they are not inadvertently updated?
> > > thanks
> > > Bill
> 
> 
> --
> 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: SMPe securing zones

[Matthew Stitt]

I've found that GIMSMP opens the datasets in UPDATE mode, so the user will 
still need UPDATE or higher access.  READ access fails when the program starts.

I've growled that GIMSMP needs to open in READ mode, then close/open in the 
desired UPDATE mode if needed.

Matthew

On Mon, 27 Mar 2023 13:50:28 +, Mark Jacobs  
wrote:

>If you have those zones in their own CSI datasets, you can use your security 
>system just to allow READ access.
>
>Mark Jacobs 
>
>
>Sent from ProtonMail, Swiss-based encrypted email.
>
>GPG Public Key - 
>https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
>
>
>--- Original Message ---
>On Monday, March 27th, 2023 at 9:46 AM, Bill Giannelli 
> wrote:
>
>
>> I want to create another TARGET and DLIB zone for another level of 
>> maintenance.
>> I am currently, showing "newbie" offshore folks our SMPe environment.
>> Is there a way to "secure" the newly created TARGET and DLIB zones so they 
>> are not inadvertently updated?
>> thanks
>> Bill

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

Re: SMPe securing zones

[Mark Jacobs]

If you have those zones in their own CSI datasets, you can use your security 
system just to allow READ access.

Mark Jacobs 


Sent from ProtonMail, Swiss-based encrypted email.

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


--- Original Message ---
On Monday, March 27th, 2023 at 9:46 AM, Bill Giannelli 
 wrote:


> I want to create another TARGET and DLIB zone for another level of 
> maintenance.
> I am currently, showing "newbie" offshore folks our SMPe environment.
> Is there a way to "secure" the newly created TARGET and DLIB zones so they 
> are not inadvertently updated?
> thanks
> Bill
> 
> --
> 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: SMPe securing zones

[Seymour J Metz]

Why not give them read-only access?


From: IBM Mainframe Discussion List  on behalf of 
Bill Giannelli 
Sent: Monday, March 27, 2023 9:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPe securing zones

I want to create another TARGET and DLIB zone for another level of maintenance.
I am currently, showing "newbie" offshore folks our SMPe environment.
Is there a way to "secure" the newly created TARGET and DLIB zones so they are 
not inadvertently updated?
thanks
Bill

--
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: SMPE recreate a target library... Possible?

[Dejan Stamatovic]

@Tom Marchant

Cloning is even better as it enables ease of rollback.


Dejan Stamatovic

CROZ D.O.O.

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

Re: SMPE recreate a target library... Possible?

[Tom Marchant]

One way of effectively providing a backup is to clone the target zone before 
applying maintenance. Then apply to the clone.

-- 
Tom Marchant

On Wed, 4 Jan 2023 09:16:58 -0600, Dejan Stamatovic  
wrote:

>I agree totally. Only backups provide a sure way out of problems during 
>applying maintenance. 

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

Re: SMPE recreate a target library... Possible?

[Dejan Stamatovic]

@ Michael Babcock 

I agree totally. Only backups provide a sure way out of problems during 
applying maintenance. 

All other methods mentioned here, might or might not work. 

So just to make a point here:  

Make sure you have a consistent backup of all affected data sets before 
applying maintenance. SMPE might not be able to recreate a target library or it 
might take too much effort to use SMPE to do that.

Dejan Stamatovic
CROZ D.O.O.

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

Re: SMPE recreate a target library... Possible?

[Rob Schramm]

Kurt, as always, many thanks.

Rob

On Wed, Jan 4, 2023, 08:30 Kurt J. Quackenbush  wrote:

> Yes, the GENERATE command will generate jobs to construct target libraries
> from the content in the distribution libraries.  However, APPLY REDO later
> for more than a handful of PTFs might be dicey.  If you go this route I
> suggest you first ACCEPT the PTFs that have not been accepted yet, then use
> GENERATE, and forego APPLY REDO.  Note, GENERATE will generate JCL to
> construct ALL target libraries, not just the zFS... be careful if you don't
> run the entire generated job stream as you have a great potential to create
> target libraries containing mismatched service levels.
>
> Depending on the product(s) you might be better off re-installing from
> scratch... its safer.
>
> > Look at the GENERATE command.  It should do what you want, but I haven't
> tried it.
>
> >> So I know all the information is in SMPE. I'm looking for if there's
> >> an easy way to do this..  The target library got smashed actually It's
> >> a ZFS file and none of the backups are available, but the distribution
> >> libraries are all intact..  I'm looking for an easy way to repopulate
> >> from the distribution libraries.  And then I suppose I would have to
> >> apply redo any PTFs that were not accepted.
>
> 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: SMPE recreate a target library... Possible?

[Michael Babcock]

And start making backups!   I always make backups of target and dlibs, SMPE
libs, ZFSs, SYSRES, and DLIB volumes too.   All right before applying
maintenance.

On Wed, Jan 4, 2023 at 4:00 AM Lizette Koehler 
wrote:

> You might want to open a case with IBM SMP/e on this issue
>
> Not knowing the product or how it is packed, you might see if they can
> help.
>
> Some of the ZONE* commands may work.  But I am not sure.
>
>
> Lizette
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Rob Schramm
> Sent: Tuesday, January 3, 2023 2:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMPE recreate a target library... Possible?
>
> So I know all the information is in SMPE. I'm looking for if there's an
> easy way to do this..  The target library got smashed actually It's a ZFS
> file and none of the backups are available, but the distribution libraries
> are all intact..  I'm looking for an easy way to repopulate from the
> distribution libraries.  And then I suppose I would have to apply redo any
> PTFs that were not accepted.
>
> Any thoughts and comments would be welcome.
>
> Rob
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead

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

Re: SMPE recreate a target library... Possible?

[Kurt J. Quackenbush]

Yes, the GENERATE command will generate jobs to construct target libraries from 
the content in the distribution libraries.  However, APPLY REDO later for more 
than a handful of PTFs might be dicey.  If you go this route I suggest you 
first ACCEPT the PTFs that have not been accepted yet, then use GENERATE, and 
forego APPLY REDO.  Note, GENERATE will generate JCL to construct ALL target 
libraries, not just the zFS... be careful if you don't run the entire generated 
job stream as you have a great potential to create target libraries containing 
mismatched service levels.

Depending on the product(s) you might be better off re-installing from 
scratch... its safer.

> Look at the GENERATE command.  It should do what you want, but I haven't 
> tried it.

>> So I know all the information is in SMPE. I'm looking for if there's 
>> an easy way to do this..  The target library got smashed actually It's 
>> a ZFS file and none of the backups are available, but the distribution 
>> libraries are all intact..  I'm looking for an easy way to repopulate 
>> from the distribution libraries.  And then I suppose I would have to 
>> apply redo any PTFs that were not accepted.

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: SMPE recreate a target library... Possible?

[Steve Smith]

 Look at the GENERATE command.  It should do what you want, but I haven't
tried it.

sas

On Tue, Jan 3, 2023 at 4:07 PM Rob Schramm  wrote:

> So I know all the information is in SMPE. I'm looking for if there's an
> easy way to do this..  The target library got smashed actually It's a ZFS
> file and none of the backups are available, but the distribution libraries
> are all intact..  I'm looking for an easy way to repopulate from the
> distribution libraries.  And then I suppose I would have to apply redo any
> PTFs that were not accepted.
>
> Any thoughts and comments would be welcome.
>
> Rob
>
> --
> 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: SMPE recreate a target library... Possible?

[Itschak Mugzach]

If you did not accept the functions and PTFs, try apply redo since they are
still in the SMPPTFand relfiles.

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





On Wed, Jan 4, 2023 at 12:00 PM Lizette Koehler 
wrote:

> You might want to open a case with IBM SMP/e on this issue
>
> Not knowing the product or how it is packed, you might see if they can
> help.
>
> Some of the ZONE* commands may work.  But I am not sure.
>
>
> Lizette
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Rob Schramm
> Sent: Tuesday, January 3, 2023 2:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMPE recreate a target library... Possible?
>
> So I know all the information is in SMPE. I'm looking for if there's an
> easy way to do this..  The target library got smashed actually It's a ZFS
> file and none of the backups are available, but the distribution libraries
> are all intact..  I'm looking for an easy way to repopulate from the
> distribution libraries.  And then I suppose I would have to apply redo any
> PTFs that were not accepted.
>
> Any thoughts and comments would be welcome.
>
> Rob
>
> --
> 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: SMPE recreate a target library... Possible?

[Lizette Koehler]

You might want to open a case with IBM SMP/e on this issue

Not knowing the product or how it is packed, you might see if they can help.

Some of the ZONE* commands may work.  But I am not sure.


Lizette

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Schramm
Sent: Tuesday, January 3, 2023 2:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPE recreate a target library... Possible?

So I know all the information is in SMPE. I'm looking for if there's an easy 
way to do this..  The target library got smashed actually It's a ZFS file and 
none of the backups are available, but the distribution libraries are all 
intact..  I'm looking for an easy way to repopulate from the distribution 
libraries.  And then I suppose I would have to apply redo any PTFs that were 
not accepted.

Any thoughts and comments would be welcome.

Rob

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

Re: SMPE recreate a target library... Possible?

[Attila Fogarasi]

BUILDMCS.  takes 5 seconds to type in the command, many hours to execute
:)  Re-install of the product might be the best alternative.

On Wed, Jan 4, 2023 at 8:07 AM Rob Schramm  wrote:

> So I know all the information is in SMPE. I'm looking for if there's an
> easy way to do this..  The target library got smashed actually It's a ZFS
> file and none of the backups are available, but the distribution libraries
> are all intact..  I'm looking for an easy way to repopulate from the
> distribution libraries.  And then I suppose I would have to apply redo any
> PTFs that were not accepted.
>
> Any thoughts and comments would be welcome.
>
> Rob
>
> --
> 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: SMPe REPORT by APPLY date

[Kurt J. Quackenbush]

> Is it possible to get a SMPe report in order of the date the sysmods were 
> applied?

The SMP/E LIST and UNLOAD commands outputs do not sort the currently installed 
SYSMODs by APPLY date.  You'll have to roll your own by either manipulating and 
sorting LIST or UNLOAD output, or using the GIMAPI program to query the target 
zone to read the SYSMOD entries and do the sorting yourself.

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: SMPe ACCEPT process

[Seymour J Metz]

There was a time when ACCEPT NOAPPLY followed by a Stage 1 Sysgen, a Stage 2 
Sysgen and a JCLIN was a common method for installing operating systems and 
program products. Most shops opted for IPO et al rather than going that route.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM 
Poncelet [03e99a92061c-dmarc-requ...@listserv.ua.edu]
Sent: Saturday, June 18, 2022 11:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPe ACCEPT process

In the 1980's, IMS SYSMODs (CBIPO/CBPDO etc.) had to be accepted before
they could be applied. It might have had to do with the macros needing
to be accepted before the rest of it could be applied.

Not sure how it is done now. The last IMS *native SMP/E* CBIPO I did was
in 2000 - probably an accept then apply 'as usual' but I can't remember.



On 17/06/2022 16:05, Ed Jaffe wrote:
> On 6/16/2022 3:02 PM, Bill Giannelli wrote:
>> For my prior maintenance I have run an APPLY excluding several PTFs
>> due to PEs and specified several bypass options.
>> But when running an ACCEPT do I run WITHOUT the excludes and the bypass?
>
> Nothing will be accepted that hasn't already been applied.
>

--
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: SMPe ACCEPT process

[CM Poncelet]

In the 1980's, IMS SYSMODs (CBIPO/CBPDO etc.) had to be accepted before
they could be applied. It might have had to do with the macros needing
to be accepted before the rest of it could be applied.
 
Not sure how it is done now. The last IMS *native SMP/E* CBIPO I did was
in 2000 - probably an accept then apply 'as usual' but I can't remember.
 


On 17/06/2022 16:05, Ed Jaffe wrote:
> On 6/16/2022 3:02 PM, Bill Giannelli wrote:
>> For my prior maintenance I have run an APPLY excluding several PTFs
>> due to PEs and specified several bypass options.
>> But when running an ACCEPT do I run WITHOUT the excludes and the bypass?
>
> Nothing will be accepted that hasn't already been applied.
>

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

Re: SMPe REPORT by APPLY date

[Rob Schramm]

Smplog has all the info.  Unless it was dummy'd out.

Rob

On Sat, Jun 18, 2022, 09:41 Bill Giannelli  wrote:

> Is it possible to get a SMPe report in order of the date the sysmods were
> applied?
> thanks
> Bill
>
> --
> 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: SMPe ACCEPT process

[Ed Jaffe]

On 6/16/2022 3:02 PM, Bill Giannelli wrote:

For my prior maintenance I have run an APPLY excluding several PTFs due to PEs 
and specified several bypass options.
But when running an ACCEPT do I run WITHOUT the excludes and the bypass?


Nothing will be accepted that hasn't already been applied.

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



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

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

Re: SMPe ACCEPT process

[Seymour J Metz]

Every shop has its own maintenance strategy. Think about what makes sense for 
your shop and document it.

Personally, I would bypass, e.g., action, documentation, holds. I would probaly 
bypass selected error holds as well.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bill Giannelli [billgianne...@gmail.com]
Sent: Thursday, June 16, 2022 6:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPe ACCEPT process

For my prior maintenance I have run an APPLY excluding several PTFs due to PEs 
and specified several bypass options.
But when running an ACCEPT do I run WITHOUT the excludes and the bypass?
thanks
Bill

--
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: SMPe ACCEPT process

[Mark Jacobs]

There's rarely a reason to fret about accept errors like that. I'd always just 
do an ACCEPT PTFS BYPASS(HOLDSYSTEM) and whatever got accepted was good enough 
for me at the time. If I ever needed to restore a PTF and it didn't work, then 
I'd dig deeper into accept processing/errors.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

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


--- Original Message ---
On Thursday, June 16th, 2022 at 7:48 PM, Bill Giannelli 
 wrote:


> thank you all for your help!
> Now i keep getting multiple GIM37905E errors
>
> --
> 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: SMPe ACCEPT process

[Bill Giannelli]

thank you all for your help!
Now i keep getting multiple GIM37905E errors

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

Re: SMPe ACCEPT process

[Allan Staller]

Classification: Confidential

I generally do not worry too much about the accepts. I would just go with a 
generic accept.
ACCEPT . (of course specifying the appropriate zones on the  SET BDY.

The purpose of the accept is to set a DLIB Level. If it becomes necessary to 
restore a PTF, all prereq/coreq.ifreq maint must be restored to the DLIB level 
(and possibly reapplied).
The shorer this chain is, the more less  work to perform the restore.

HTH

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Thursday, June 16, 2022 5:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPe ACCEPT process

[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.]

For my prior maintenance I have run an APPLY excluding several PTFs due to PEs 
and specified several bypass options.
But when running an ACCEPT do I run WITHOUT the excludes and the bypass?
thanks
Bill

--
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: SMPE apply error SYMLINKS

[Jake Anderson]

Hello All

Thanks to Kurt. Under the /Service some of the directories were missing and
I created those. Then tried applying again and it went fine.

Thanks all for your help

On Tue, 9 Nov, 2021, 7:51 pm Kurt J. Quackenbush,  wrote:

> > Based on reason code I have looked into each directory and it exists but
> > not sure which file it is looking for and failing.
>
> Unfortunately message BPXF170E truncates the desired SYMLINK value.  I
> can't see the ++APAR so don't know for sure the SYMLINK value but if it
> matches the prior value for EZAMLCAT the message is complaining about this
> directory:
>
> /Service/usr/lpp/tcpip/lib/nls/msg/C/IBM/
> ../../../../../../../../usr/lib/nls/msg/C/ezamlcat.cat
>
> After resolving the "../" you get this directory:
>
> /Service/usr/lib/nls/msg/C/
>
> Does that directory exist?  Is it mounted?  Does the SYMLINK value on the
> ++HFS statement in the ++APAR match the existing SYMLINK value for
> EZAMLCAT?  Look at the ++APAR in your SMPPTS and look at the HFS entry in
> the target zone to compare the SYMLINK values.
>
> Kurt Quackenbush -- IBM,  z/OS SMP/E and z/OSMF Software Management
>
> 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: SMPE apply error SYMLINKS

[Kurt J. Quackenbush]

> Based on reason code I have looked into each directory and it exists but
> not sure which file it is looking for and failing.

Unfortunately message BPXF170E truncates the desired SYMLINK value.  I 
can't see the ++APAR so don't know for sure the SYMLINK value but if it 
matches the prior value for EZAMLCAT the message is complaining about this 
directory:

/Service/usr/lpp/tcpip/lib/nls/msg/C/IBM/
../../../../../../../../usr/lib/nls/msg/C/ezamlcat.cat

After resolving the "../" you get this directory:

/Service/usr/lib/nls/msg/C/

Does that directory exist?  Is it mounted?  Does the SYMLINK value on the 
++HFS statement in the ++APAR match the existing SYMLINK value for 
EZAMLCAT?  Look at the ++APAR in your SMPPTS and look at the HFS entry in 
the target zone to compare the SYMLINK values.

Kurt Quackenbush -- IBM,  z/OS SMP/E and z/OSMF Software Management

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: SMPE apply error SYMLINKS

[Allan Staller]

Classification: Confidential

Check for action holds on the relevant PTF. If a new directory is required, IBM 
will typically detail what is required and (usually) supply a sample job to 
create the directories.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Dave Jousma
Sent: Tuesday, November 9, 2021 8:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE apply error SYMLINKS

[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.]

On Tue, 9 Nov 2021 08:04:56 -0600, Dave Jousma  wrote:

>
>Jake,
>
>Is that an APARfix for PH38318?   I see the APAR is still open.   Could be a 
>packaging error by IBM too…..
>
>
>I look up the same module in my 2.4 environment
>
>  Entry Type:  HFS  Zone Name: MVSTZN
>  Entry Name:  EZAMLCAT Zone Type: TARGET
>
>  FMID: HIP6240   DISTLIB : AEZAXLT3 LASTUPD: HIP6240  TYPE=ADD
>  RMID: UI66498   SYSLIB  : SEZAMMSC BINARY
>  SHSCRIPT:
>
>
> 
>
> LINK '../ezamlcat.cat'
> PARM PATHMODE(0,6,4,4)
> SYMLINK  '../../../../../../../../usr/lib/nls/msg/C/ezamlcat.cat'
> SYMPATH  '../../../../../usr/lpp/tcpip/lib/nls/msg/C/ezamlcat.cat'
>
>
>Yours seems to have an extra directory in it?  I don’t have /IBM/ in mine.
>
>BPXF150I MVS DATA SET WITH DDNAME SYSUT1 SUCCESSFULLY COPIED INTO
>BINARY HFS FILE /Service/usr/lpp/tcpip/lib/nls/msg/C/IBM/EZAMLCAT.
>
>BPXF170E RETURN CODE 0081, REASON CODE 0594003D. A SYMLINK FAILED
>FOR LINK NAME /Service/usr/lpp/tcpip/lib/nls/msg/C/IBM/../../
>
>../../../../../...
>

Correction.   I just went and looked at the actual filesystem

-rw-r--r--   2 BPXROOT  OMVSGRP  699 Sep 25  2019 EZAITMSG
-rw-r--r--   2 BPXROOT  OMVSGRP26230 Dec 23  2019 EZAMLCAT
-rw-r--r--   2 BPXROOT  OMVSGRP 5026 Sep 25  2019 EZAMLRPY
TEC1:$ pwd
/RST01A/usr/lpp/tcpip/lib/nls/msg/C/IBM
TEC1:$

My apologies for the red herring.   I'd still ask IBM to investigate a possible 
packaging error though since it appears to be an APARfix

--
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: SMPE apply error SYMLINKS

[Dave Jousma]

On Tue, 9 Nov 2021 08:04:56 -0600, Dave Jousma  wrote:

>
>Jake,
>
>Is that an APARfix for PH38318?   I see the APAR is still open.   Could be a 
>packaging error by IBM too…..
>
>
>I look up the same module in my 2.4 environment
>
>  Entry Type:  HFS  Zone Name: MVSTZN 
>  Entry Name:  EZAMLCAT Zone Type: TARGET 
>  
>  FMID: HIP6240   DISTLIB : AEZAXLT3 LASTUPD: HIP6240  TYPE=ADD   
>  RMID: UI66498   SYSLIB  : SEZAMMSC BINARY   
>  SHSCRIPT:   
>  
>  
>  
> LINK '../ezamlcat.cat'   
> PARM PATHMODE(0,6,4,4)   
> SYMLINK  '../../../../../../../../usr/lib/nls/msg/C/ezamlcat.cat'
> SYMPATH  '../../../../../usr/lpp/tcpip/lib/nls/msg/C/ezamlcat.cat'   
>
>
>Yours seems to have an extra directory in it?  I don’t have /IBM/ in mine.
>
>BPXF150I MVS DATA SET WITH DDNAME SYSUT1 SUCCESSFULLY COPIED INTO BINARY
>HFS FILE /Service/usr/lpp/tcpip/lib/nls/msg/C/IBM/EZAMLCAT.
>
>BPXF170E RETURN CODE 0081, REASON CODE 0594003D. A SYMLINK FAILED FOR
>LINK NAME /Service/usr/lpp/tcpip/lib/nls/msg/C/IBM/../../
>
>../../../../../...
>

Correction.   I just went and looked at the actual filesystem

-rw-r--r--   2 BPXROOT  OMVSGRP  699 Sep 25  2019 EZAITMSG
-rw-r--r--   2 BPXROOT  OMVSGRP26230 Dec 23  2019 EZAMLCAT
-rw-r--r--   2 BPXROOT  OMVSGRP 5026 Sep 25  2019 EZAMLRPY
TEC1:$ pwd
/RST01A/usr/lpp/tcpip/lib/nls/msg/C/IBM   
TEC1:$

My apologies for the red herring.   I'd still ask IBM to investigate a possible 
packaging error though since it appears to be an APARfix

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

Re: SMPE apply error SYMLINKS

[Dave Jousma]

On Tue, 9 Nov 2021 12:09:38 +0400, Jake Anderson  
wrote:

>Hello
>
>Cross posted
>
>I am applying a APAR related to CSSMTP to zOS 2.4 and it fails with below
>messge
>
>GIM42500W AN ATTEMPT TO OBTAIN THE NAME OF THE PHYSICAL DATA SET CONTAINING
>A
>
>  SYMBOLIC LINK FOR HFS EZAMLCAT IN SEZAMMSC FAILED. THE RETURN
>CODE
>
>  FROM THE BPX1LST CALLABLE SERVICE WAS '0081'X AND THE
>REASON
>
>  CODE WAS '0594003D'X.
>

Jake,

Is that an APARfix for PH38318?   I see the APAR is still open.   Could be a 
packaging error by IBM too…..


I look up the same module in my 2.4 environment

  Entry Type:  HFS  Zone Name: MVSTZN 
  Entry Name:  EZAMLCAT Zone Type: TARGET 
  
  FMID: HIP6240   DISTLIB : AEZAXLT3 LASTUPD: HIP6240  TYPE=ADD   
  RMID: UI66498   SYSLIB  : SEZAMMSC BINARY   
  SHSCRIPT:   
  
  
  
 LINK '../ezamlcat.cat'   
 PARM PATHMODE(0,6,4,4)   
 SYMLINK  '../../../../../../../../usr/lib/nls/msg/C/ezamlcat.cat'
 SYMPATH  '../../../../../usr/lpp/tcpip/lib/nls/msg/C/ezamlcat.cat'   


Yours seems to have an extra directory in it?  I don’t have /IBM/ in mine.

BPXF150I MVS DATA SET WITH DDNAME SYSUT1 SUCCESSFULLY COPIED INTO BINARY
HFS FILE /Service/usr/lpp/tcpip/lib/nls/msg/C/IBM/EZAMLCAT.

BPXF170E RETURN CODE 0081, REASON CODE 0594003D. A SYMLINK FAILED FOR
LINK NAME /Service/usr/lpp/tcpip/lib/nls/msg/C/IBM/../../

../../../../../...

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

Re: [EXTERNAL] Re: SMPE apply error SYMLINKS

[Pommier, Rex]

Check to see if there's a security violation in the path?  

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jake Anderson
Sent: Tuesday, November 9, 2021 5:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: SMPE apply error SYMLINKS

Hello

I have double checked the DDDEF and the path is correct for the failing DDDEF


On Tue, 9 Nov, 2021, 3:31 pm SUBSCRIBE IBM-MAIN Marc Yves Desravines, < 
marc.yves.desravi...@kyndryl.com> wrote:

> Hi Jake,
>
> I suspect  the problem is related with a wrong DDDEF. Could you list 
> the DDDEFs and check if the related pathname required is correct?
>
> --
> 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: SMPE apply error SYMLINKS

[SUBSCRIBE IBM-MAIN Marc Yves Desravines]

Hi Jake,

0594003D according to BPXMTEXT means:

JRDirNotFound: A directory in the pathname was not found

So it looks like your HFS files directories are not set up or mounted properly.

Could you check them and compare with what you have in the DDDEF?

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

Re: SMPE apply error SYMLINKS

[Jake Anderson]

Hello

I have double checked the DDDEF and the path is correct for the failing
DDDEF


On Tue, 9 Nov, 2021, 3:31 pm SUBSCRIBE IBM-MAIN Marc Yves Desravines, <
marc.yves.desravi...@kyndryl.com> wrote:

> Hi Jake,
>
> I suspect  the problem is related with a wrong DDDEF. Could you list the
> DDDEFs and check if the related pathname required is correct?
>
> --
> 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: SMPE apply error SYMLINKS

[SUBSCRIBE IBM-MAIN Marc Yves Desravines]

Hi Jake,

I suspect  the problem is related with a wrong DDDEF. Could you list the DDDEFs 
and check if the related pathname required is correct?

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

Re: SMPE Help

[Kurt Quackenbush]

On 9/21/2021 11:39 PM, Mohd Shahrifuddin Ahmad Masri wrote:

I have another problem.

DATE 09/22/21   TIME 11:31:01   
  SMP/E 36.109
UNIX COMMAND OUTPUT


  /bin/pax -zvrf /u/ssa/cics/SMPPTFIN/2021250221822812757.1of35 ./GIMFAF.XML


./GIMFAF.XML
905839 blocks
15874 blocks (compressed)
FSUM7131 Out of space or reached the end of the archive file.
   If you want to go on, type device or file name when ready

My question. Which directory is out of space? How to increase the space?
Did you specify the SMPWKDIR DD statement in the job?  If so, then that 
is the out of space directory.  If not, then the directory where the 
archive files reside, specified on the SMPDIR DD statement, is out of space.


I suggest you either add SMPWKDIR if its not already there, or change 
SMPWKDIR to point to a directory in a UNIX file system with plenty of 
space.  On some systems pointing SMPWKDIR to /tmp is reasonable, but 
you'll have to determine where you have plenty of UNIX file system space.


See the SMP/E Reference for information on how much space might be needed:
https://www.ibm.com/docs/en/zos/2.4.0?topic=routine-determining-required-size-smpwkdir

Kurt Quackenbush -- IBM, SMP/E Development
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: SMPe GIM30206E

[Allan Staller]

Classification: Confidential

An unresolved ERROR Hold will generate RC=8. To eliminate, exclude to PTF with 
the error hold.
DO NOT bypass error hold without a very good reason and understand the 
implications if you do.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Wayne Bickerdike
Sent: Friday, September 3, 2021 10:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPe GIM30206E

[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.]

It's always advisable to read the HOLDDATA, often these are advisory in nature, 
could be "check region size is a minimum" or "these parameters are now obsolete 
and will be ignored".  If you are happy that you understand the hold reasons, 
as previous posters said you can BYPASS.



On Sat, Sep 4, 2021 at 9:28 AM Retired Mainframer < 
03a485c129c3-dmarc-requ...@listserv.ua.edu> wrote:

> At my last site, the Quality Control folks would not accept anything
> higher than a four on a job they were required to review.  This was a
> result of some product teams bamboozling them on 8s and 12s in the
> past.  Management did not like it when the customers discovered
> delivery errors.  Once QC was required to review system updates as
> part of new security practices, 4 became the limit for SMPE also.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Mark Jacobs
> Sent: Friday, September 3, 2021 10:26 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMPe GIM30206E
>
> Look at the SMP/e CAUSER report and see what is/are the hold reasons.
> Then it depends on what they are. Bypass or not. There's no need to
> exclude them.
> Just
> expect an RC=8 on the apply.
>
> Mark Jacobs
>
> --
> 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
::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: SMPe GIM30206E

[Wayne Bickerdike]

It's always advisable to read the HOLDDATA, often these are advisory in
nature, could be "check region size is a minimum" or "these parameters are
now obsolete and will be ignored".  If you are happy that you understand
the hold reasons, as previous posters said you can BYPASS.



On Sat, Sep 4, 2021 at 9:28 AM Retired Mainframer <
03a485c129c3-dmarc-requ...@listserv.ua.edu> wrote:

> At my last site, the Quality Control folks would not accept anything
> higher
> than a four on a job they were required to review.  This was a result of
> some
> product teams bamboozling them on 8s and 12s in the past.  Management did
> not
> like it when the customers discovered delivery errors.  Once QC was
> required
> to review system updates as part of new security practices, 4 became the
> limit
> for SMPE also.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of
> Mark Jacobs
> Sent: Friday, September 3, 2021 10:26 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMPe GIM30206E
>
> Look at the SMP/e CAUSER report and see what is/are the hold reasons. Then
> it
> depends on what they are. Bypass or not. There's no need to exclude them.
> Just
> expect an RC=8 on the apply.
>
> Mark Jacobs
>
> --
> 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: SMPe GIM30206E

[Retired Mainframer]

At my last site, the Quality Control folks would not accept anything higher 
than a four on a job they were required to review.  This was a result of some 
product teams bamboozling them on 8s and 12s in the past.  Management did not 
like it when the customers discovered delivery errors.  Once QC was required 
to review system updates as part of new security practices, 4 became the limit 
for SMPE also.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Friday, September 3, 2021 10:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPe GIM30206E

Look at the SMP/e CAUSER report and see what is/are the hold reasons. Then it 
depends on what they are. Bypass or not. There's no need to exclude them. Just 
expect an RC=8 on the apply.

Mark Jacobs

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

Re: SMPe GIM30206E

[James Crudele]

I usually evaluate the holds. Then bypass them. Don’t bypass the errors though. 
A friend did that once. Not good. 

> On Sep 3, 2021, at 13:20, Bill Giannelli  wrote:
> 
> running an apply check and getting the following on several sysmods:
> GIM30206E ** APPLY PROCESSING FAILED FOR SYSMOD UI76575. HOLD REASON IDS WERE 
> NOT RESOLVED
> 
> What would the proper next steps be? Look into each sysmod for the hold 
> reason or exclude these sysmods?
> Bill
> 
> --
> 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: SMPe GIM30206E

[Gibney, Dave]

You can add
BYPASS( 
   HOLDSYSTEM   
   HOLDUSER 
   HOLDCLASS(UCLREL,ERRELL)
And see which one are still held due to error.
I agree with the folks that it's safe to just run, expect an 8, and see what's 
left.
But, I usually did try to EXCLUDE the error chains and try for a RC=4.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Bill Giannelli
> Sent: Friday, September 03, 2021 10:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMPe GIM30206E
> 
> running an apply check and getting the following on several sysmods:
> GIM30206E ** APPLY PROCESSING FAILED FOR SYSMOD UI76575. HOLD
> REASON IDS WERE NOT RESOLVED
> 
> What would the proper next steps be? Look into each sysmod for the hold
> reason or exclude these sysmods?
> Bill
> 
> --
> 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: SMPe GIM30206E

[Mark Jacobs]

Look at the SMP/e CAUSER report and see what is/are the hold reasons. Then it 
depends on what they are. Bypass or not. There's no need to exclude them. Just 
expect an RC=8 on the apply.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

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

‐‐‐ Original Message ‐‐‐

On Friday, September 3rd, 2021 at 1:19 PM, Bill Giannelli 
 wrote:

> running an apply check and getting the following on several sysmods:
>
> GIM30206E ** APPLY PROCESSING FAILED FOR SYSMOD UI76575. HOLD REASON IDS WERE 
> NOT RESOLVED
>
> What would the proper next steps be? Look into each sysmod for the hold 
> reason or exclude these sysmods?
>
> Bill
>
> -
>
> 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: SMPe deleting SMPPTS after receive

[Allan Staller]

Classification: Confidential

From the standpoint of just having a SMPPTS, you will be fine. I am hesitant to 
state "logical" effects of any of the contents of the SMPTS.
e.g. installed, but not yet accepted maintenance.

If it were my dog, I would work on the recovery of t he original SMPPTS.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Friday, September 3, 2021 6:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPe deleting SMPPTS after receive

[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.]

we are having an issue recalling a migrated SMPPTS dataset. if all my past 
maintenance is already received can I just delete and reallocate my SMPPTS 
datasets?
Thanks
Bill

--
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: SMPe deleting SMPPTS after receive

[Paul Gilmartin]

On Fri, 3 Sep 2021 06:53:39 -0500, Bill Giannelli wrote:

>we are having an issue recalling a migrated SMPPTS dataset. if all my past 
>maintenance is already received can I just delete and reallocate my SMPPTS 
>datasets?
>
I wouldn't do that before the APPLY.

And I believe there is a path where SMP/E will rebuild load modules
using elements that have not been ACCEPTed.  I'd expect that to
require SMPPRS.



-- gil

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

Re: SMPe deleting SMPPTS after receive

[Richards, Robert B. (CTR)]

Bill,

Do you mean "already ACCEPTED"?  My simple answer could be yes in that case. 
Regardless, I let SMP/E purge upon ACCEPT.

Don't you have a backup copy made prior to migration?

Bob

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Friday, September 3, 2021 7:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPe deleting SMPPTS after receive

we are having an issue recalling a migrated SMPPTS dataset. if all my past 
maintenance is already received can I just delete and reallocate my SMPPTS 
datasets?
Thanks
Bill


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

Re: SMPe automated job to receive maintenance

[Styles, Andy (ITS zPlatform Services)]

Classification: Public

There sure is; the SMPE manual has a whole section on receiving maintenance 
through a batch job:

https://www.ibm.com/docs/en/zos/2.4.0?topic=guide-preparing-use-internet-service-retrieval

I haven't been near Shopz for about 4 years for maintenance. 

Andy Styles
z/Series System Programmer

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: 02 September 2021 10:39
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPe automated job to receive maintenance

*** This email is from an external source - be careful of attachments and 
links. Please report suspicious emails ***

When getting maintenance, normally I sign onto Shopz, and order the latest 
maintenance, download it and receive it.
Is there a automated way to receive maintenance through a regularly scheduled 
batch job?
thanks
Bill

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC95000. Telephone: 0131 225 4555.

Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. 
Registered in England and Wales no. 2065. Telephone 0207626 1500.

Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC327000. Telephone: 03457 801 801.

Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London 
EC2V 7HN. Registered in England and Wales no. 10399850.

Scottish Widows Schroder Personal Wealth Limited. Registered Office: 25 Gresham 
Street, London EC2V 7HN. Registered in England and Wales no. 11722983.

Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are 
authorised by the Prudential Regulation Authority and regulated by the 
Financial Conduct Authority and Prudential Regulation Authority.

Scottish Widows Schroder Personal Wealth Limited is authorised and regulated by 
the Financial Conduct Authority.

Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned 
subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets 
Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 
6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht 
Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets 
Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für 
Finanzdienstleistungsaufsicht.

Halifax is a division of Bank of Scotland plc.

HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in 
Scotland no. SC218813.



This e-mail (including any attachments) is private and confidential and may 
contain privileged material. If you have received this e-mail in error, please 
notify the sender and delete it (including any attachments) immediately. You 
must not copy, distribute, disclose or use any of the information in it or any 
attachments. Telephone calls may be monitored or recorded.


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

Re: SMPe how to determine prior RSU level

[Chris Hoelscher]

It was indeed intended to be AMBLIST

Chris Hoelscher
Lead Sys DBA 
Kyndryl on assignment to IBM Global Technical Services on assignmemt to Humana 
Inc.
T 502.476.2538  or 502.407.7266


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Wayne Bickerdike
Sent: Saturday, August 28, 2021 11:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] SMPe how to determine prior RSU level


[External Email: Use caution with links and attachments]

Anything else run ABLIST on all modules??

AMBLIST or is ABLIST something else?

On Sat, Aug 28, 2021 at 6:05 AM Chris Hoelscher 
wrote:

> If its DB2 run MEPL
> If it’s a CA product run CAMODID
> Anything else run ABLIST on all modules
>
> In all cases sort the output by PTF# match the ptf# to the entry in 
> your CSI to determine the associated  RSU
>
>
>
>
> Chris Hoelscher
> Lead Sys DBA
> Kyndryl on assignment to IBM Global Technical Services on assignmemt 
> to Humana Inc.
> T 502.476.2538  or 502.407.7266
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Bill Giannelli
> Sent: Tuesday, August 24, 2021 6:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [IBM-MAIN] SMPe how to determine prior RSU level
>
> [External Email: Use caution with links and attachments]
>
>
> I have received and applied several months maintenance, but have not 
> yet moved it into our runtime libraries. How might I determine what my 
> prior RSU level is within my runtime libraries?
> thanks
> Bill
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> The information transmitted is intended only for the person or entity 
> to which it is addressed and may contain CONFIDENTIAL material.  If 
> you receive this material/information in error, please contact the 
> sender and delete or destroy the material/information.
>
> Humana Inc. and its subsidiaries comply with applicable Federal civil 
> rights laws and do not discriminate on the basis of race, color, 
> national origin, ancestry, age, disability, sex, marital status, 
> gender, sexual orientation, gender identity, or religion.
> Humana Inc. and its subsidiaries do not exclude people or treat them 
> differently because of race, color, national origin, ancestry, age, 
> disability, sex, marital status, gender, sexual orientation, gender 
> identity, or religion.
>
> English: ATTENTION: If you do not speak English, language assistance 
> services, free of charge, are available to you. Call 1‐877‐320‐1235 
> (TTY: 711).
>
> Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición 
> servicios gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 
> (TTY: 711).
>
> 繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助
> 服務。請致電 1‐877‐320‐1235 (TTY: 711)。
>
> Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, 
> gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 
> (TTY: 711).
>
> Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z 
> bezpłatnej pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 
> 711).
>
> 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 이용하실 수 있습니다. 
> 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.
>
>
> --
> 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

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights 
laws and
do not discriminate on the basis of race, color, national origin, ancestry, 
age, disability, sex,
marital status, gender, sexual orientation, gender identity, or religion. 
Humana Inc. and its subsidiaries do not
exclude people or treat them differently because of race, color, national 
origin, ancestry, age,
disability, sex, marital status, gender, sexual orientation, gender identity, 
or religion.

English: ATTENTION: If you do not speak English, language assistance services, 
free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis 
èd
pou 

Re: SMPe how to determine prior RSU level

[Wayne Bickerdike]

Anything else run ABLIST on all modules??

AMBLIST or is ABLIST something else?

On Sat, Aug 28, 2021 at 6:05 AM Chris Hoelscher 
wrote:

> If its DB2 run MEPL
> If it’s a CA product run CAMODID
> Anything else run ABLIST on all modules
>
> In all cases sort the output by PTF# match the ptf# to the entry in your
> CSI to determine the associated  RSU
>
>
>
>
> Chris Hoelscher
> Lead Sys DBA
> Kyndryl on assignment to IBM Global Technical Services on assignmemt to
> Humana Inc.
> T 502.476.2538  or 502.407.7266
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Bill Giannelli
> Sent: Tuesday, August 24, 2021 6:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [IBM-MAIN] SMPe how to determine prior RSU level
>
> [External Email: Use caution with links and attachments]
>
>
> I have received and applied several months maintenance, but have not yet
> moved it into our runtime libraries. How might I determine what my prior
> RSU level is within my runtime libraries?
> thanks
> Bill
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> The information transmitted is intended only for the person or entity to
> which it is addressed
> and may contain CONFIDENTIAL material.  If you receive this
> material/information in error,
> please contact the sender and delete or destroy the material/information.
>
> Humana Inc. and its subsidiaries comply with applicable Federal civil
> rights laws and
> do not discriminate on the basis of race, color, national origin,
> ancestry, age, disability, sex,
> marital status, gender, sexual orientation, gender identity, or religion.
> Humana Inc. and its subsidiaries do not
> exclude people or treat them differently because of race, color, national
> origin, ancestry, age,
> disability, sex, marital status, gender, sexual orientation, gender
> identity, or religion.
>
> English: ATTENTION: If you do not speak English, language assistance
> services, free
> of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).
>
> Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición
> servicios
> gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).
>
> 繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助
> 服務。請致電 1‐877‐320‐1235 (TTY: 711)。
>
> Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen
> sèvis èd
> pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).
>
> Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z
> bezpłatnej
> pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).
>
> 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
> 이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.
>
>
> --
> 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: SMPe how to determine prior RSU level

[Chris Hoelscher]

If its DB2 run MEPL
If it’s a CA product run CAMODID
Anything else run ABLIST on all modules

In all cases sort the output by PTF# match the ptf# to the entry in your CSI to 
determine the associated  RSU 




Chris Hoelscher
Lead Sys DBA 
Kyndryl on assignment to IBM Global Technical Services on assignmemt to Humana 
Inc.
T 502.476.2538  or 502.407.7266

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: Tuesday, August 24, 2021 6:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] SMPe how to determine prior RSU level

[External Email: Use caution with links and attachments]


I have received and applied several months maintenance, but have not yet moved 
it into our runtime libraries. How might I determine what my prior RSU level is 
within my runtime libraries?
thanks
Bill

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

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights 
laws and
do not discriminate on the basis of race, color, national origin, ancestry, 
age, disability, sex,
marital status, gender, sexual orientation, gender identity, or religion. 
Humana Inc. and its subsidiaries do not
exclude people or treat them differently because of race, color, national 
origin, ancestry, age,
disability, sex, marital status, gender, sexual orientation, gender identity, 
or religion.

English: ATTENTION: If you do not speak English, language assistance services, 
free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis 
èd
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.


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

Re: SMPe how to determine prior RSU level

[Kurt Quackenbush]

On 8/24/2021 6:41 AM, Bill Giannelli wrote:

I have received and applied several months maintenance, but have not yet moved 
it into our runtime libraries. How might I determine what my prior RSU level is 
within my runtime libraries?
Hopefully you kept a copy of the CSIs that represent your running 
software.  If so use the REPORT SOURCEID command to get a list of all 
the SOURCEIDs, including RSU, associated with applied PTFs.  Option 3.3 
in the SMP/E dialog will do similar.


Kurt Quackenbush -- IBM, SMP/E Development
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: SMPe how to determine prior RSU level

[Mark Jacobs]

When I built system environments at $previousjob I would use the CVTVERID field 
to document its RSU level.

http://planetmvs.com/mvstips/

Sent from ProtonMail, Swiss-based encrypted email.

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

‐‐‐ Original Message ‐‐‐

On Tuesday, August 24th, 2021 at 6:41 AM, Bill Giannelli 
 wrote:

> I have received and applied several months maintenance, but have not yet 
> moved it into our runtime libraries. How might I determine what my prior RSU 
> level is within my runtime libraries?
>
> thanks
>
> Bill
>
> --
>
> 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: SMPe how to determine prior RSU level

[Carmen Vitullo]

Part of my process moving maint forward is to run a static symbol 
update, it's a manual process but beats searching for an eyecatcher in a 
load module for a PTF number


//SYM EXEC PGM=IEASYMU2,PARM='RSU=2102'


On 8/24/2021 5:41 AM, Bill Giannelli wrote:

I have received and applied several months maintenance, but have not yet moved 
it into our runtime libraries. How might I determine what my prior RSU level is 
within my runtime libraries?
thanks
Bill

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


--
/I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live by the light that I have. I must stand 
with anybody that stands right, and stand with him while he is right, 
and part with him when he goes wrong. *Abraham Lincoln*/


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

Re: SMPe how to determine prior RSU level

[Seymour J Metz]

You have to build any required tracking into your maintenance strategy.


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



From: IBM Mainframe Discussion List  on behalf of 
Bill Giannelli 
Sent: Tuesday, August 24, 2021 6:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPe how to determine prior RSU level

I have received and applied several months maintenance, but have not yet moved 
it into our runtime libraries. How might I determine what my prior RSU level is 
within my runtime libraries?
thanks
Bill

--
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: SMPe how to determine prior RSU level

[James Crudele]

Smpe option 3.3 will list sourceid. 

> On Aug 24, 2021, at 06:41, Bill Giannelli  wrote:
> 
> I have received and applied several months maintenance, but have not yet 
> moved it into our runtime libraries. How might I determine what my prior RSU 
> level is within my runtime libraries?
> thanks
> Bill
> 
> --
> 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: SMPe how to determine prior RSU level

[James Crudele]

Smpe option 3.3 will list sourceid 



> On Aug 24, 2021, at 06:41, Bill Giannelli  wrote:
> 
> I have received and applied several months maintenance, but have not yet 
> moved it into our runtime libraries. How might I determine what my prior RSU 
> level is within my runtime libraries?
> thanks
> Bill
> 
> --
> 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: SMPe how to determine prior RSU level

[kekronbekron]

You're lucky if the dataset activity timestamp(s) matches with what's in the 
SMPE log files.
For situations like this, it's good to put an uncataloged text file in the same 
volume as a product/OS's target libraries with a couple of lines to say when it 
was built/APPLY'd.

- KB

‐‐‐ Original Message ‐‐‐

On Tuesday, August 24th, 2021 at 4:11 PM, Bill Giannelli 
 wrote:

> I have received and applied several months maintenance, but have not yet 
> moved it into our runtime libraries. How might I determine what my prior RSU 
> level is within my runtime libraries?
>
> thanks
>
> Bill
>
> --
>
> 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: SMPE

[Gibney, Dave]

COBOL runtime, which also runtime for other languages is called Language 
Environment, LE. And is part of base z/OS. in fact,  these days, z/os probable 
won't run without it.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of CarlosM
> Sent: Thursday, June 17, 2021 6:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMPE
> 
> Thank you all,,
> 
> Actually all I needed to know is if we have COBOL installed as an MVS
> newbe if did nor know how to list ALL software products installed. in
> VSE it's Simple
> 
> // EXEC MSHP,SIZE=456k
> 
> RETR
> 
> /*
> 
> /&
> 
> 
> And it'done.
> 
> we do not have the COBOL compiler  (Does MVS come with COBOL run time
> mods pre-installed?)
> 
> but we have COBOL runtime? (that is what I am trying to find out and if
> so what version?)
> 
> 
> we are running ZOS 1..23
> 
> 
> On 6/17/2021 2:18 PM, Seymour J Metz wrote:
> > Does the OP know what the relevant zones are? Has the installation
> configured z/OSMF to have the relevant global zones? The mechanics are
> easy once the requirements are laid out in detail.
> >
> > BTW, should the SMP documentation point to, e.g., z/OSMF, for things that
> SMP itself doesn't automate, or would that add too much clutter?
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> >
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg
> BY0HMszNaDT!5O8JicV9plSqz1_jxIwIlz2o3bF03pIvoVoIl05Dns9i4P-
> 19C0Go_2rGwgiOg$
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Kurt Quackenbush [ku...@us.ibm.com]
> > Sent: Thursday, June 17, 2021 10:24 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: SMPE
> >
> > On 6/16/2021 11:56 AM, CarlosM wrote:
> >> Would anyone have the JCL/statements necessary to produce a SMPE
> report
> >> of ALL installed products?
> > To be sure we're using the same terminology, a "PRODUCT" to SMP/E is a
> > collection of FEATUREs, and each FEATURE is a collection of FMIDs.  A
> > PRODUCT is identified by its Product ID and VRM.  For example, z/OS V2.4
> > has product ID "5650-ZOS" and VRM "2.4.0", which has a bunch of
> > FEATUREs, like the z/OS Base, and that FEATURE has lots of FMIDs, like
> > HBB77C0.  Is that the kind of "product" information you're looking for?
> >
> > Its easy to get a list of FMIDs which are installed in a particular
> > target zone.  Like this:
> >
> > //SMPE EXEC PGM=GIMSMP
> > //SMPCSI   DD DISP=SHR,DSN=globalZoneCsiName
> > //SMPOUT   DD SYSOUT=*
> > //SMPLIST  DD SYSOUT=*
> > //SMPCNTL  DD *
> > SET BDY(targetZoneName).
> >   LIST FUNCTIONS.
> > /*
> >
> > There is no simple SMP/E LIST command to precisely display the installed
> > PRODUCTs.  You can list the PRODUCTs which have been received, like
> > this, but not which have been installed into a particular target zone.
> >
> > //SMPE EXEC PGM=GIMSMP
> > //SMPCSI   DD DISP=SHR,DSN=globalZoneCsiName
> > //SMPOUT   DD SYSOUT=*
> > //SMPLIST  DD SYSOUT=*
> > //SMPCNTL  DD *
> > SET BDY(GLOBAL).
> >   LIST PRODUCT FEATURE.
> > /*
> >
> > A better approach is to use z/OSMF Software Management.  The Products
> > page displays exactly which Products, Features, and FMIDs are installed.
> >
> > Kurt Quackenbush -- IBM, SMP/E Development
> > 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
> 
> --
> 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: SMPE

[CarlosM]

Thank you all,,

Actually all I needed to know is if we have COBOL installed as an MVS 
newbe if did nor know how to list ALL software products installed. in 
VSE it's Simple


// EXEC MSHP,SIZE=456k

RETR

/*

/&


And it'done.

we do not have the COBOL compiler  (Does MVS come with COBOL run time 
mods pre-installed?)


but we have COBOL runtime? (that is what I am trying to find out and if 
so what version?)



we are running ZOS 1..23


On 6/17/2021 2:18 PM, Seymour J Metz wrote:

Does the OP know what the relevant zones are? Has the installation configured 
z/OSMF to have the relevant global zones? The mechanics are easy once the 
requirements are laid out in detail.

BTW, should the SMP documentation point to, e.g., z/OSMF, for things that SMP 
itself doesn't automate, or would that add too much clutter?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Kurt Quackenbush [ku...@us.ibm.com]
Sent: Thursday, June 17, 2021 10:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE

On 6/16/2021 11:56 AM, CarlosM wrote:

Would anyone have the JCL/statements necessary to produce a SMPE report
of ALL installed products?

To be sure we're using the same terminology, a "PRODUCT" to SMP/E is a
collection of FEATUREs, and each FEATURE is a collection of FMIDs.  A
PRODUCT is identified by its Product ID and VRM.  For example, z/OS V2.4
has product ID "5650-ZOS" and VRM "2.4.0", which has a bunch of
FEATUREs, like the z/OS Base, and that FEATURE has lots of FMIDs, like
HBB77C0.  Is that the kind of "product" information you're looking for?

Its easy to get a list of FMIDs which are installed in a particular
target zone.  Like this:

//SMPE EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=globalZoneCsiName
//SMPOUT   DD SYSOUT=*
//SMPLIST  DD SYSOUT=*
//SMPCNTL  DD *
SET BDY(targetZoneName).
  LIST FUNCTIONS.
/*

There is no simple SMP/E LIST command to precisely display the installed
PRODUCTs.  You can list the PRODUCTs which have been received, like
this, but not which have been installed into a particular target zone.

//SMPE EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=globalZoneCsiName
//SMPOUT   DD SYSOUT=*
//SMPLIST  DD SYSOUT=*
//SMPCNTL  DD *
SET BDY(GLOBAL).
  LIST PRODUCT FEATURE.
/*

A better approach is to use z/OSMF Software Management.  The Products
page displays exactly which Products, Features, and FMIDs are installed.

Kurt Quackenbush -- IBM, SMP/E Development
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


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

Re: SMPE

[Seymour J Metz]

 1. Which target zone? The OP may have many. Also, the OP may not know their 
names.

 2. The OP may want to report on accepted functions.

 3. At this point, none of us knows what the OP actually wants.

 4. Once the OP pins down the requirements, what's left is the easy part.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Gerhard Adam [gada...@charter.net]
Sent: Thursday, June 17, 2021 2:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE

There is only one relevant zone;  the TARGET for the system being examined.
The GLOBAL zone may have FMIDs deleted depending on the ACCEPT options and
items may not even be APPLIED (if they have only been RECEIVEd).The DLIB
zone will only show elements that have been ACCEPTed.  The PRODUCT function
may not be specific enough to indicate all the components that are
installed, so the FMID is the only way to be definitive.

The LIST command as the way to produce the report and the JCL can be created
in using the COMMAND GENERATION component of the SMP/E ISPF function.

There are also SMP/E basic utilities to provide a product list based on
correlating the FMID and PRODUCT/FEATURE pieces

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Thursday, June 17, 2021 11:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE

Does the OP know what the relevant zones are? Has the installation
configured z/OSMF to have the relevant global zones? The mechanics are easy
once the requirements are laid out in detail.

BTW, should the SMP documentation point to, e.g., z/OSMF, for things that
SMP itself doesn't automate, or would that add too much clutter?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Kurt Quackenbush [ku...@us.ibm.com]
Sent: Thursday, June 17, 2021 10:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE

On 6/16/2021 11:56 AM, CarlosM wrote:
> Would anyone have the JCL/statements necessary to produce a SMPE
> report of ALL installed products?
To be sure we're using the same terminology, a "PRODUCT" to SMP/E is a
collection of FEATUREs, and each FEATURE is a collection of FMIDs.  A
PRODUCT is identified by its Product ID and VRM.  For example, z/OS V2.4 has
product ID "5650-ZOS" and VRM "2.4.0", which has a bunch of FEATUREs, like
the z/OS Base, and that FEATURE has lots of FMIDs, like HBB77C0.  Is that
the kind of "product" information you're looking for?

Its easy to get a list of FMIDs which are installed in a particular target
zone.  Like this:

//SMPE EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=globalZoneCsiName
//SMPOUT   DD SYSOUT=*
//SMPLIST  DD SYSOUT=*
//SMPCNTL  DD *
   SET BDY(targetZoneName).
 LIST FUNCTIONS.
/*

There is no simple SMP/E LIST command to precisely display the installed
PRODUCTs.  You can list the PRODUCTs which have been received, like this,
but not which have been installed into a particular target zone.

//SMPE EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=globalZoneCsiName
//SMPOUT   DD SYSOUT=*
//SMPLIST  DD SYSOUT=*
//SMPCNTL  DD *
   SET BDY(GLOBAL).
 LIST PRODUCT FEATURE.
/*

A better approach is to use z/OSMF Software Management.  The Products page
displays exactly which Products, Features, and FMIDs are installed.

Kurt Quackenbush -- IBM, SMP/E Development 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

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

[Gerhard Adam]

There is only one relevant zone;  the TARGET for the system being examined.
The GLOBAL zone may have FMIDs deleted depending on the ACCEPT options and
items may not even be APPLIED (if they have only been RECEIVEd).The DLIB
zone will only show elements that have been ACCEPTed.  The PRODUCT function
may not be specific enough to indicate all the components that are
installed, so the FMID is the only way to be definitive.  

The LIST command as the way to produce the report and the JCL can be created
in using the COMMAND GENERATION component of the SMP/E ISPF function.

There are also SMP/E basic utilities to provide a product list based on
correlating the FMID and PRODUCT/FEATURE pieces

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Thursday, June 17, 2021 11:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE

Does the OP know what the relevant zones are? Has the installation
configured z/OSMF to have the relevant global zones? The mechanics are easy
once the requirements are laid out in detail.

BTW, should the SMP documentation point to, e.g., z/OSMF, for things that
SMP itself doesn't automate, or would that add too much clutter? 


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Kurt Quackenbush [ku...@us.ibm.com]
Sent: Thursday, June 17, 2021 10:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE

On 6/16/2021 11:56 AM, CarlosM wrote:
> Would anyone have the JCL/statements necessary to produce a SMPE 
> report of ALL installed products?
To be sure we're using the same terminology, a "PRODUCT" to SMP/E is a
collection of FEATUREs, and each FEATURE is a collection of FMIDs.  A
PRODUCT is identified by its Product ID and VRM.  For example, z/OS V2.4 has
product ID "5650-ZOS" and VRM "2.4.0", which has a bunch of FEATUREs, like
the z/OS Base, and that FEATURE has lots of FMIDs, like HBB77C0.  Is that
the kind of "product" information you're looking for?

Its easy to get a list of FMIDs which are installed in a particular target
zone.  Like this:

//SMPE EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=globalZoneCsiName
//SMPOUT   DD SYSOUT=*
//SMPLIST  DD SYSOUT=*
//SMPCNTL  DD *
   SET BDY(targetZoneName).
 LIST FUNCTIONS.
/*

There is no simple SMP/E LIST command to precisely display the installed
PRODUCTs.  You can list the PRODUCTs which have been received, like this,
but not which have been installed into a particular target zone.

//SMPE EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=globalZoneCsiName
//SMPOUT   DD SYSOUT=*
//SMPLIST  DD SYSOUT=*
//SMPCNTL  DD *
   SET BDY(GLOBAL).
 LIST PRODUCT FEATURE.
/*

A better approach is to use z/OSMF Software Management.  The Products page
displays exactly which Products, Features, and FMIDs are installed.

Kurt Quackenbush -- IBM, SMP/E Development 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

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

Re: SMPE

[Seymour J Metz]

Does the OP know what the relevant zones are? Has the installation configured 
z/OSMF to have the relevant global zones? The mechanics are easy once the 
requirements are laid out in detail.

BTW, should the SMP documentation point to, e.g., z/OSMF, for things that SMP 
itself doesn't automate, or would that add too much clutter? 


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Kurt Quackenbush [ku...@us.ibm.com]
Sent: Thursday, June 17, 2021 10:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE

On 6/16/2021 11:56 AM, CarlosM wrote:
> Would anyone have the JCL/statements necessary to produce a SMPE report
> of ALL installed products?
To be sure we're using the same terminology, a "PRODUCT" to SMP/E is a
collection of FEATUREs, and each FEATURE is a collection of FMIDs.  A
PRODUCT is identified by its Product ID and VRM.  For example, z/OS V2.4
has product ID "5650-ZOS" and VRM "2.4.0", which has a bunch of
FEATUREs, like the z/OS Base, and that FEATURE has lots of FMIDs, like
HBB77C0.  Is that the kind of "product" information you're looking for?

Its easy to get a list of FMIDs which are installed in a particular
target zone.  Like this:

//SMPE EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=globalZoneCsiName
//SMPOUT   DD SYSOUT=*
//SMPLIST  DD SYSOUT=*
//SMPCNTL  DD *
   SET BDY(targetZoneName).
 LIST FUNCTIONS.
/*

There is no simple SMP/E LIST command to precisely display the installed
PRODUCTs.  You can list the PRODUCTs which have been received, like
this, but not which have been installed into a particular target zone.

//SMPE EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=globalZoneCsiName
//SMPOUT   DD SYSOUT=*
//SMPLIST  DD SYSOUT=*
//SMPCNTL  DD *
   SET BDY(GLOBAL).
 LIST PRODUCT FEATURE.
/*

A better approach is to use z/OSMF Software Management.  The Products
page displays exactly which Products, Features, and FMIDs are installed.

Kurt Quackenbush -- IBM, SMP/E Development
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: SMPE

[Carmen Vitullo]

+ 1 for the suggestion to use z/OSMF to list products installed, once 
the CSI's are defined to the software management it queries the CSI and 
list all the currently installed products


Carmen

On 6/17/2021 9:24 AM, Kurt Quackenbush wrote:

On 6/16/2021 11:56 AM, CarlosM wrote:
Would anyone have the JCL/statements necessary to produce a SMPE 
report of ALL installed products?
To be sure we're using the same terminology, a "PRODUCT" to SMP/E is a 
collection of FEATUREs, and each FEATURE is a collection of FMIDs.  A 
PRODUCT is identified by its Product ID and VRM.  For example, z/OS 
V2.4 has product ID "5650-ZOS" and VRM "2.4.0", which has a bunch of 
FEATUREs, like the z/OS Base, and that FEATURE has lots of FMIDs, like 
HBB77C0.  Is that the kind of "product" information you're looking for?


Its easy to get a list of FMIDs which are installed in a particular 
target zone.  Like this:


//SMPE EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=globalZoneCsiName
//SMPOUT   DD SYSOUT=*
//SMPLIST  DD SYSOUT=*
//SMPCNTL  DD *
  SET BDY(targetZoneName).
    LIST FUNCTIONS.
/*

There is no simple SMP/E LIST command to precisely display the 
installed PRODUCTs.  You can list the PRODUCTs which have been 
received, like this, but not which have been installed into a 
particular target zone.


//SMPE EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=globalZoneCsiName
//SMPOUT   DD SYSOUT=*
//SMPLIST  DD SYSOUT=*
//SMPCNTL  DD *
  SET BDY(GLOBAL).
    LIST PRODUCT FEATURE.
/*

A better approach is to use z/OSMF Software Management.  The Products 
page displays exactly which Products, Features, and FMIDs are installed.


Kurt Quackenbush -- IBM, SMP/E Development
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



--
*Carmen Vitullo*

/“I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live up to what light I have.” ― Abraham Lincoln/



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

Re: SMPE

[Kurt Quackenbush]

On 6/16/2021 11:56 AM, CarlosM wrote:
Would anyone have the JCL/statements necessary to produce a SMPE report 
of ALL installed products?
To be sure we're using the same terminology, a "PRODUCT" to SMP/E is a 
collection of FEATUREs, and each FEATURE is a collection of FMIDs.  A 
PRODUCT is identified by its Product ID and VRM.  For example, z/OS V2.4 
has product ID "5650-ZOS" and VRM "2.4.0", which has a bunch of 
FEATUREs, like the z/OS Base, and that FEATURE has lots of FMIDs, like 
HBB77C0.  Is that the kind of "product" information you're looking for?


Its easy to get a list of FMIDs which are installed in a particular 
target zone.  Like this:


//SMPE EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=globalZoneCsiName
//SMPOUT   DD SYSOUT=*
//SMPLIST  DD SYSOUT=*
//SMPCNTL  DD *
  SET BDY(targetZoneName).
LIST FUNCTIONS.
/*

There is no simple SMP/E LIST command to precisely display the installed 
PRODUCTs.  You can list the PRODUCTs which have been received, like 
this, but not which have been installed into a particular target zone.


//SMPE EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=globalZoneCsiName
//SMPOUT   DD SYSOUT=*
//SMPLIST  DD SYSOUT=*
//SMPCNTL  DD *
  SET BDY(GLOBAL).
LIST PRODUCT FEATURE.
/*

A better approach is to use z/OSMF Software Management.  The Products 
page displays exactly which Products, Features, and FMIDs are installed.


Kurt Quackenbush -- IBM, SMP/E Development
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: SMPE

[Seymour J Metz]

Yes, but the OP still needs to identify the relevant zones and report types. 
Slapping the JCL together is the easy part.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Lizette Koehler [stars...@mindspring.com]
Sent: Wednesday, June 16, 2021 9:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE

If you have installed the SMP/e ISPF Interface, it can help generate
everything you need for Batch (Option 4) or use the ONLINE Panels to see
what you have and then generate the batch job.

Lizette


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Wednesday, June 16, 2021 9:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE

What kind or report? For what zones?

If I had to guess I'd say you want LIST FEATURE or LIST PRODUCT for one or
more zones, but there are lots of other possibilities.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
CarlosM [carl...@solracz.com]
Sent: Wednesday, June 16, 2021 12:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPE

Would anyone have the JCL/statements necessary to produce a SMPE report of
ALL installed products?




Thank Carlos Martinez

SUNY Downstate

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

[Lizette Koehler]

If you have installed the SMP/e ISPF Interface, it can help generate
everything you need for Batch (Option 4) or use the ONLINE Panels to see
what you have and then generate the batch job.

Lizette


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Wednesday, June 16, 2021 9:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE

What kind or report? For what zones?

If I had to guess I'd say you want LIST FEATURE or LIST PRODUCT for one or
more zones, but there are lots of other possibilities.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
CarlosM [carl...@solracz.com]
Sent: Wednesday, June 16, 2021 12:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPE

Would anyone have the JCL/statements necessary to produce a SMPE report of
ALL installed products?




Thank Carlos Martinez

SUNY Downstate

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

[Seymour J Metz]

What kind or report? For what zones?

If I had to guess I'd say you want LIST FEATURE or LIST PRODUCT for one or more 
zones, but there are lots of other possibilities.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
CarlosM [carl...@solracz.com]
Sent: Wednesday, June 16, 2021 12:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPE

Would anyone have the JCL/statements necessary to produce a SMPE report
of ALL installed products?




Thank Carlos Martinez

SUNY Downstate

--
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: SMPE query - ALIAS/MALIAS

[Kurt Quackenbush]

On 6/2/2021 10:43 AM, Binyamin Dissen wrote:

Ops. My mistake - they are aliases. I forgot how ISPF shows them.

As a side point, why does the RELFILE need the alias? Can't the apply process
assign them?
Why?  That's just the way APPLY works.  I don't know what the original 
design point was many years ago, but APPLY does not create aliases for 
elements copied from RELFILEs.


Kurt Quackenbush -- IBM, SMP/E Development
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: SMPE query - ALIAS/MALIAS

[Paul Gilmartin]

On Wed, 2 Jun 2021 17:43:10 +0300, Binyamin Dissen wrote:
>...
>As a side point, why does the RELFILE need the alias? Can't the apply process
>assign them?
> 
I believe Kurt is saying that IEBCOPY doesn't assign aliases.

OTOH, I was dismayed long ago when I tried such as:
//SYSLIN  DD  *
  INCLUDE alias-name
Alias-name existed in the RELFILE and the MCS (not
""Message Control Statements").
SMP/E failed the construct.  Went to SR.  Got WAD.

>On Wed, 2 Jun 2021 10:04:12 -0400 Kurt Quackenbush wrote:
>
>:>...  SMP/E APPLY
>:>simply tells IEBCOPY to copy the members (true and alias) from the
>:>RELFILE (actually, the SMPTLIB data set) to the target library.

-- gil

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

Re: SMPE query - ALIAS/MALIAS

[Binyamin Dissen]

Ops. My mistake - they are aliases. I forgot how ISPF shows them.

As a side point, why does the RELFILE need the alias? Can't the apply process
assign them?

On Wed, 2 Jun 2021 10:04:12 -0400 Kurt Quackenbush  wrote:

:>On 6/2/2021 8:57 AM, Binyamin Dissen wrote:
:>> I have inherited a product with MCS with ALIAS/MALIAS.
:>> 
:>> It appears that the RECEIVE process requires the alias to be in the RELFILE,
:>> and that the APPLY process creates true members instead of aliases.
:>> 
:>> Am I missing something obvious in the packaging? 
:>If the APPLY creates true members instead of aliases, then the REFILE 
:>incorrectly contains true members instead of aliases.  SMP/E APPLY 
:>simply tells IEBCOPY to copy the members (true and alias) from the 
:>RELFILE (actually, the SMPTLIB data set) to the target library.

--
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: SMPE query - ALIAS/MALIAS

[Kurt Quackenbush]

On 6/2/2021 8:57 AM, Binyamin Dissen wrote:

I have inherited a product with MCS with ALIAS/MALIAS.

It appears that the RECEIVE process requires the alias to be in the RELFILE,
and that the APPLY process creates true members instead of aliases.

Am I missing something obvious in the packaging? 
If the APPLY creates true members instead of aliases, then the REFILE 
incorrectly contains true members instead of aliases.  SMP/E APPLY 
simply tells IEBCOPY to copy the members (true and alias) from the 
RELFILE (actually, the SMPTLIB data set) to the target library.


Kurt Quackenbush -- IBM, SMP/E Development
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: SMPE Receive Order post May 1st

[Kurt Quackenbush]

On 5/12/2021 1:51 PM, Dave Jousma wrote:


We are still broke since the 5/1 TLSv1.2 cutover on your end.   We are assuming 
its a problem on our end.  We do have ticket open with ATTLS support group at 
IBM.

We do have HTTPS service working, but continue to pursue, as not sure if 
TESTCASE.boulder.ibm.com has same TLS requirement (havent tried that yet).

Glad to hear you're using HTTPS for your software downloads.

Regarding the TESTCASE servers, I'm told TLS 1.2 is NOT REQUIRED.  It is 
enabled, but not required at this time.


Kurt Quackenbush -- IBM, SMP/E Development
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: SMPE Receive Order post May 1st

[Kurt Quackenbush]

On 5/13/2021 8:54 AM, Michael Babcock wrote:

Oh, and the AT-TLS error was 402.

BPXF024I (STSYSLOG) May 12 20:26:41 X/TCPIP  TCPIP 256
TTLS[280]: 15:26:41 TCPIP    EZD1286I TTLS Error GRPID: 0017
ENVID: 008B CONNID: C6AD LOCAL: xxx.xxx.xxx.xxx..7199 REMOTE:
170.225.15.117..21 JOBNAME: RECV USERID:  RULE: 
Secure_FTP_Client_9921
RC:  402 Initial Handshake  
0052FDA4BC90


Which is "402: An SSL cipher suite could not be agreed upon between the 
client and server. "


Sorry you're still having trouble Michael, but this is now beyond my 
level of expertise.  I suggest you contact IBM Support if you have not 
done so already.


Kurt Quackenbush -- IBM, SMP/E Development
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: SMPE Receive Order post May 1st

[Michael Babcock]

Oh, and the AT-TLS error was 402.

BPXF024I (STSYSLOG) May 12 20:26:41 X/TCPIP  TCPIP 256
TTLS[280]: 15:26:41 TCPIP    EZD1286I TTLS Error GRPID: 0017
ENVID: 008B CONNID: C6AD LOCAL: xxx.xxx.xxx.xxx..7199 REMOTE:
170.225.15.117..21 JOBNAME: RECV USERID:  RULE: 
Secure_FTP_Client_9921
RC:  402 Initial Handshake  
0052FDA4BC90


Which is "402: An SSL cipher suite could not be agreed upon between the 
client and server. "


On 5/12/2021 3:47 PM, Michael Babcock wrote:

Kurt,

Unless I'm doing something wrong, my testing does not bear that out.

The only cipher in the list was:

    # Allow only AES ciphers
V3CipherSuites TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

PAGENT was refreshed.  Here’s the DEBUG ALL output.

SC0588 initConnection: Calling getaddrinfo() with 
deliverycb-bld.dhe.ibm.com

SC0627 initConnection: getaddrinfo() returned.
SC0798 initNamedConnection: entered
SC0960 initIPv4Connection: entered
CY3336 access_via_socks_server: entered
Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21.
SC3362 getReply: entered
SC4549 getNextReply: entered with waitForData = TRUE
220-IBM's internal systems must only be used for conducting IBM's
SC4549 getNextReply: entered with waitForData = TRUE
220-business or for purposes authorized by IBM management.
SC4549 getNextReply: entered with waitForData = TRUE
220-
SC4549 getNextReply: entered with waitForData = TRUE
220-Use is subject to audit at any time by IBM management.
SC4549 getNextReply: entered with waitForData = TRUE
220-
SC4549 getNextReply: entered with waitForData = TRUE
220-
SC4549 getNextReply: entered with waitForData = TRUE
220 dhebpcb01 secure FTP server ready.
SC4241 getLastReply: entered
SC4241 getLastReply: entered
SC4241 getLastReply: entered
SC7601 update_cntl_appldata: entered
GU5351 ftpSetApplData: entered
FC0259 ftpAuth: entered
FC0294 ftpAuth: security values: mech=TLS, tlsmech=ATTLS, tlsreuse=N, 
sFTP=R, sCC=P, sDC=P

FC2895 ftpAuthAttls: entered
FC2971 ftpAuthAttls: AT-TLS policy set as application controlled.
FU2410 printAttlsPolicyNames: entered
FU2420 TTLSRule: Secure_FTP_Client_9921
FU2426 TTLSGroupAction: grp_Production
FU2432 TTLSEnvironmentAction: Secure_FTP_Client_Env_Ext
FU2439 TTLSConnectionACtion: Secure_FTP_Conn_Ext
SC2899 sendCmd: entered
>>> AUTH TLS
SC3362 getReply: entered
SC4549 getNextReply: entered with waitForData = TRUE
234 SSLv23/TLSv1
SC4241 getLastReply: entered
FC3101 authServerAttls: entered
SC4405 getFNDELAY: entered
SC4440 setFNDELAY: entered
FC3140 authServerAttls: Start Handshake
FC3149 authServerAttls: ioctl() failed on SIOCTTLSCTL - EDC8121I 
Connection reset. (errno2=0x77A9733D)

SC4440 setFNDELAY: entered
Authentication negotiation failed
SC4289 inSession: entered
*** Control connection with dispby-117.boulder.ibm.com dies.
SC4332 SETCEC code = 10
SC3610 endSession: entered (sn=1BE35B18)
SC2776 dataClose: entered
SC3693 endSession: recv() failed - EDC8121I Connection reset. 
(errno2=0x76650446)

CZ1459 ftpClose: entered
SC4289 inSession: entered
SC4367 setLoggedIn: entered
You must first issue the 'OPEN' command

The rest of the ciphers were re-added and PAGENT refreshed.

   # Allow only AES ciphers
    V3CipherSuites    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    V3CipherSuites    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    V3CipherSuites    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
    V3CipherSuites    TLS_RSA_WITH_AES_256_GCM_SHA384
    V3CipherSuites    TLS_RSA_WITH_AES_256_CBC_SHA256
    V3CipherSuites    TLS_RSA_WITH_AES_256_CBC_SHA
    V3CipherSuites    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
    V3CipherSuites    TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
    V3CipherSuites    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
    V3CipherSuites    TLS_DHE_RSA_WITH_AES_256_CBC_SHA
    V3CipherSuites    TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
    V3CipherSuites    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
    V3CipherSuites    TLS_DH_RSA_WITH_AES_256_CBC_SHA
    V3CipherSuites    TLS_DH_RSA_WITH_AES_256_CBC_SHA256
    V3CipherSuites    TLS_DH_RSA_WITH_AES_256_GCM_SHA384
    V3CipherSuites    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
    V3CipherSuites    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
    V3CipherSuites    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    V3CipherSuites    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
    V3CipherSuites    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
    V3CipherSuites    TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
  }

Here’s the DEBUG ALL output for that.  As you can see the 009D cipher 
was picked.  It did not pick one of the stronger ciphers even though 
TLSv1.2 was used.


SC0588 initConnection: Calling getaddrinfo() with 
deliverycb-bld.dhe.ibm.com

SC0627 initConnection: getaddrinfo() returned.
SC0798 initNamedConnection: entered
SC0960 initIPv4Connection: entered
CY3336 access_via_socks_server: entered
Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21.
SC3362 getReply: entered
SC4549 getNextReply: entered with waitForData = TRUE

Re: SMPE Receive Order post May 1st

[Michael Babcock]

Kurt,

Unless I'm doing something wrong, my testing does not bear that out.

The only cipher in the list was:

    # Allow only AES ciphers
V3CipherSuites TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

PAGENT was refreshed.  Here’s the DEBUG ALL output.

SC0588 initConnection: Calling getaddrinfo() with deliverycb-bld.dhe.ibm.com
SC0627 initConnection: getaddrinfo() returned.
SC0798 initNamedConnection: entered
SC0960 initIPv4Connection: entered
CY3336 access_via_socks_server: entered
Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21.
SC3362 getReply: entered
SC4549 getNextReply: entered with waitForData = TRUE
220-IBM's internal systems must only be used for conducting IBM's
SC4549 getNextReply: entered with waitForData = TRUE
220-business or for purposes authorized by IBM management.
SC4549 getNextReply: entered with waitForData = TRUE
220-
SC4549 getNextReply: entered with waitForData = TRUE
220-Use is subject to audit at any time by IBM management.
SC4549 getNextReply: entered with waitForData = TRUE
220-
SC4549 getNextReply: entered with waitForData = TRUE
220-
SC4549 getNextReply: entered with waitForData = TRUE
220 dhebpcb01 secure FTP server ready.
SC4241 getLastReply: entered
SC4241 getLastReply: entered
SC4241 getLastReply: entered
SC7601 update_cntl_appldata: entered
GU5351 ftpSetApplData: entered
FC0259 ftpAuth: entered
FC0294 ftpAuth: security values: mech=TLS, tlsmech=ATTLS, tlsreuse=N, 
sFTP=R, sCC=P, sDC=P

FC2895 ftpAuthAttls: entered
FC2971 ftpAuthAttls: AT-TLS policy set as application controlled.
FU2410 printAttlsPolicyNames: entered
FU2420 TTLSRule: Secure_FTP_Client_9921
FU2426 TTLSGroupAction: grp_Production
FU2432 TTLSEnvironmentAction: Secure_FTP_Client_Env_Ext
FU2439 TTLSConnectionACtion: Secure_FTP_Conn_Ext
SC2899 sendCmd: entered
>>> AUTH TLS
SC3362 getReply: entered
SC4549 getNextReply: entered with waitForData = TRUE
234 SSLv23/TLSv1
SC4241 getLastReply: entered
FC3101 authServerAttls: entered
SC4405 getFNDELAY: entered
SC4440 setFNDELAY: entered
FC3140 authServerAttls: Start Handshake
FC3149 authServerAttls: ioctl() failed on SIOCTTLSCTL - EDC8121I 
Connection reset. (errno2=0x77A9733D)

SC4440 setFNDELAY: entered
Authentication negotiation failed
SC4289 inSession: entered
*** Control connection with dispby-117.boulder.ibm.com dies.
SC4332 SETCEC code = 10
SC3610 endSession: entered (sn=1BE35B18)
SC2776 dataClose: entered
SC3693 endSession: recv() failed - EDC8121I Connection reset. 
(errno2=0x76650446)

CZ1459 ftpClose: entered
SC4289 inSession: entered
SC4367 setLoggedIn: entered
You must first issue the 'OPEN' command

The rest of the ciphers were re-added and PAGENT refreshed.

   # Allow only AES ciphers
    V3CipherSuites    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    V3CipherSuites    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    V3CipherSuites    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
    V3CipherSuites    TLS_RSA_WITH_AES_256_GCM_SHA384
    V3CipherSuites    TLS_RSA_WITH_AES_256_CBC_SHA256
    V3CipherSuites    TLS_RSA_WITH_AES_256_CBC_SHA
    V3CipherSuites    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
    V3CipherSuites    TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
    V3CipherSuites    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
    V3CipherSuites    TLS_DHE_RSA_WITH_AES_256_CBC_SHA
    V3CipherSuites    TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
    V3CipherSuites    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
    V3CipherSuites    TLS_DH_RSA_WITH_AES_256_CBC_SHA
    V3CipherSuites    TLS_DH_RSA_WITH_AES_256_CBC_SHA256
    V3CipherSuites    TLS_DH_RSA_WITH_AES_256_GCM_SHA384
    V3CipherSuites    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
    V3CipherSuites    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
    V3CipherSuites    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    V3CipherSuites    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
    V3CipherSuites    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
    V3CipherSuites    TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
  }

Here’s the DEBUG ALL output for that.  As you can see the 009D cipher 
was picked.  It did not pick one of the stronger ciphers even though 
TLSv1.2 was used.


SC0588 initConnection: Calling getaddrinfo() with 
deliverycb-bld.dhe.ibm.com

SC0627 initConnection: getaddrinfo() returned.
SC0798 initNamedConnection: entered
SC0960 initIPv4Connection: entered
CY3336 access_via_socks_server: entered
Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21.
SC3362 getReply: entered
SC4549 getNextReply: entered with waitForData = TRUE
220-IBM's internal systems must only be used for conducting IBM's
SC4549 getNextReply: entered with waitForData = TRUE
220-business or for purposes authorized by IBM management.
SC4549 getNextReply: entered with waitForData = TRUE
220-
SC4549 getNextReply: entered with waitForData = TRUE
220-Use is subject to audit at any time by IBM management.
SC4549 getNextReply: entered with waitForData = TRUE
220-
SC4549 getNextReply: entered with waitForData = TRUE
220-
SC4549 getNextReply: entered with waitForData = TRUE
220 dhebpcb01 secure 

Re: SMPE Receive Order post May 1st

[Dave Jousma]

>This was confirmed by an individual that supports the server.  The 
>ciphers mentioned on the IBM Support page are a subset of the ciphers 
>actually enabled.
>https://www.ibm.com/support/pages/node/6417233

>I hope this helps.  Is anyone still having trouble connecting?

>Kurt Quackenbush -- IBM, SMP/E Development
>Chuck Norris never uses CHECK when he applies PTFs.

We are still broke since the 5/1 TLSv1.2 cutover on your end.   We are assuming 
its a problem on our end.  We do have ticket open with ATTLS support group at 
IBM.

We do have HTTPS service working, but continue to pursue, as not sure if 
TESTCASE.boulder.ibm.com has same TLS requirement (havent tried that yet).

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

Re: SMPE Receive Order post May 1st

[Kurt Quackenbush]

On 5/10/2021 4:57 PM, Michael Babcock wrote:

I did some testing on our sandbox (I commented out all ciphers except the
one I was interested in and refreshed policy agent) and here’s what I found.





The ECDHE ciphers were rejected but the TLS_RSA_WITH_AES_256_CBC_SHA did
work (I didn’t try the TLS_RSA_WITH_AES_128_CBC_SHA cipher).


In spite of what the IBM Support page says, my tests show the following 
ciphers enabled on the delivercb-bld.dhe.ibm.com server:


TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA

This was confirmed by an individual that supports the server.  The 
ciphers mentioned on the IBM Support page are a subset of the ciphers 
actually enabled.

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

I hope this helps.  Is anyone still having trouble connecting?

Kurt Quackenbush -- IBM, SMP/E Development
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: SMPE: Element Contains CLIST with ALIAS

[Paul Gilmartin]

On Mon, 10 May 2021 13:00:31 -0500, Paul Gilmartin wrote:
>
>The Ref. ...:
>...
>"message control statment" (dozens of times)?  "MCS (Modification Control 
>Statement)"?
>Whatever.
>
RCF submitted and promptly accepted for next refresh.

-- gil

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

Re: SMPE: Element Contains CLIST with ALIAS

[David Spiegel]

Hi Scott,
It's done by a BLDL and a STOW.

Regards,
David

On 2021-05-10 17:36, A T & T Management wrote:
  
OK

Now on to the problem, The alias should be created at apply time.  How this is 
done I don't recall and don't have access to my machine at this time.
Scott
 On Monday, May 10, 2021, 5:01:21 PM EDT, David Spiegel 
 wrote:
  
  Hi Scott,

You're right. I would've done this, but, the customer insisted it has to
be a PTF.

Regards,
David

On 2021-05-10 16:48, A T & T Management wrote:

   Why not do this in a usermod?
Scott

       On Monday, May 10, 2021, 2:25:47 PM EDT, Kurt Quackenbush 
 wrote:
   
   On 5/10/2021 1:15 PM, David Spiegel wrote:



I added a CLIST as part of a PTF.
(This is not vendor software.)
++CLIST(ABCXYZ) ALIAS(XYZ) DISTLIB(ACLIST) SYSLIB(CLIST).
PROC 0
WRITE HI

When I ran the APPLY Job, the IEBCOPY Output showed
COPY OUTDD=CLIST,INDD=SMPWRK6
      S M=((A000,ABCXYZ,R))

Where does (the ALIAS) XYZ get copied to //CLIST?
(It is there after the Job runs, but, there is no record of it in the
Job Output.)

After the IEBCOPY operation SMP/E creates the alias in the data set
directly using the STOW data management macro.

Kurt Quackenbush -- IBM, SMP/E Development
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
.

--
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: SMPE: Element Contains CLIST with ALIAS

[A T & T Management]

 
OK
Now on to the problem, The alias should be created at apply time.  How this is 
done I don't recall and don't have access to my machine at this time.
Scott
On Monday, May 10, 2021, 5:01:21 PM EDT, David Spiegel 
 wrote:  
 
 Hi Scott,
You're right. I would've done this, but, the customer insisted it has to 
be a PTF.

Regards,
David

On 2021-05-10 16:48, A T & T Management wrote:
>  Why not do this in a usermod?
> Scott
>
>      On Monday, May 10, 2021, 2:25:47 PM EDT, Kurt Quackenbush 
> wrote:
>  
>  On 5/10/2021 1:15 PM, David Spiegel wrote:
>
>> I added a CLIST as part of a PTF.
>> (This is not vendor software.)
>> ++CLIST(ABCXYZ) ALIAS(XYZ) DISTLIB(ACLIST) SYSLIB(CLIST).
>> PROC 0
>> WRITE HI
>>
>> When I ran the APPLY Job, the IEBCOPY Output showed
>> COPY OUTDD=CLIST,INDD=SMPWRK6
>>     S M=((A000,ABCXYZ,R))
>>
>> Where does (the ALIAS) XYZ get copied to //CLIST?
>> (It is there after the Job runs, but, there is no record of it in the
>> Job Output.)
> After the IEBCOPY operation SMP/E creates the alias in the data set
> directly using the STOW data management macro.
>
> Kurt Quackenbush -- IBM, SMP/E Development
> 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
> .

--
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: SMPE: Element Contains CLIST with ALIAS

[David Spiegel]

Hi Scott,
You're right. I would've done this, but, the customer insisted it has to 
be a PTF.


Regards,
David

On 2021-05-10 16:48, A T & T Management wrote:

  Why not do this in a usermod?
Scott

 On Monday, May 10, 2021, 2:25:47 PM EDT, Kurt Quackenbush 
 wrote:
  
  On 5/10/2021 1:15 PM, David Spiegel wrote:



I added a CLIST as part of a PTF.
(This is not vendor software.)
++CLIST(ABCXYZ) ALIAS(XYZ) DISTLIB(ACLIST) SYSLIB(CLIST).
PROC 0
WRITE HI

When I ran the APPLY Job, the IEBCOPY Output showed
COPY OUTDD=CLIST,INDD=SMPWRK6
    S M=((A000,ABCXYZ,R))

Where does (the ALIAS) XYZ get copied to //CLIST?
(It is there after the Job runs, but, there is no record of it in the
Job Output.)

After the IEBCOPY operation SMP/E creates the alias in the data set
directly using the STOW data management macro.

Kurt Quackenbush -- IBM, SMP/E Development
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
.


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

Re: SMPE Receive Order post May 1st

[Michael Babcock]

I did some testing on our sandbox (I commented out all ciphers except the
one I was interested in and refreshed policy agent) and here’s what I found.



According to https://www.ibm.com/support/pages/node/6417233



The cipher suites that will be enabled for AT-TLS for using FTPS are:

·   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

·   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

·   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

·   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

·   TLS_RSA_WITH_AES_128_CBC_SHA

·   TLS_RSA_WITH_AES_256_CBC_SHA




The ECDHE ciphers were rejected but the TLS_RSA_WITH_AES_256_CBC_SHA did
work (I didn’t try the TLS_RSA_WITH_AES_128_CBC_SHA cipher).

What gives IBM?


On Sun, May 9, 2021 at 1:01 PM Cieri, Anthony <
02d7f4ec1fff-dmarc-requ...@listserv.ua.edu> wrote:

>
> While I agree with your recommendations, the FTPS job does not
> work without the ciphers I listed below. Apparently IBM needs to make some
> adjustments first.
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Michael Babcock
> Sent: Wednesday, May 05, 2021 2:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMPE Receive Order post May 1st
>
> [[ SEI WARNING *** This email was sent from an external source. Do not
> open attachments or click on links from unknown or suspicious senders. ***
> ]]
>
>
> I would highly discourage the use of the ciphers listed.  I would use
> these more secure ciphers (I'm sure there are others that are acceptable).
>
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
>
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
>
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
>
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
>
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
>
> On 5/5/2021 12:58 PM, Cieri, Anthony wrote:
> >   Dave,
> >   Here you go:
> >
> > ##
> > # #
> > # Secure FTP Application  #
> > # #
> > ###
> >
>
> > TTLSRule  secure_ftp_client_rule
> > {
> >RemotePortRange 21   # This should be set to the port the FTP
> > # listening on
> >Direction  Outbound
> >TTLSGroupActionRef secure_ftp_client_group
> >TTLSEnvironmentActionRef   secure_ftp_client_env
> > }
> >
>
> > TTLSGroupAction   secure_ftp_client_group
> > {
> >TTLSEnabled On
> >Trace   7
> > }
> >
>
> > TTLSEnvironmentAction secure_ftp_client_env
> > {
> >TTLSKeyringParms
> >{
> >   Keyring  /u/ftps/zos17dbf.kdb
> >   KeyringStashFile /u/ftps/zos17dbf.sth
> >}
> >HandshakeRole   Client
> > TTLSEnvironmentAdvancedParms
> >{
> >   ApplicationControlledOn
> >   SecondaryMap On
> >   SSLV3Off
> >   TLSV1Off
> >   TLSV1.1  Off
> >   TLSV1.2  On
> >}
> >TTLSCipherParmsRef ftp_client_ciphers   # to cust ciphers
> > }
> >
>
> > TTLSCipherParms  ftp_client_ciphers
> > {
> > # Sample ciphers.  Should be customized!
> > V3CipherSuitesTLS_RSA_WITH_AES_256_CBC_SHA
> > V3CipherSuitesTLS_RSA_WITH_3DES_EDE_CBC_SHA
> > V3CipherSuitesTLS_RSA_WITH_NULL_SHA
> > }
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Dave Jousma
> > Sent: Wednesday, May 05, 2021 1:13 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: SMPE Receive Order post May 1st
> >
> > [[ SEI WARNING *** This email was sent from an external source. Do not
> > open attachments or click on links from unknown or suspicious senders.
> > *** ]]
> >
> >
> >>  Well, for what it's worth, I just tried it and my job was
> >> successful, however, I also received the SSLv23/TLSv1 messages. So I
> >> used the standard job that IBM provided (RFNJOBS) and I turned on Debug
> SEC.
> >> Here is what I got

Re: SMPE: Element Contains CLIST with ALIAS

[A T & T Management]

 Why not do this in a usermod?
Scott

On Monday, May 10, 2021, 2:25:47 PM EDT, Kurt Quackenbush 
 wrote:  
 
 On 5/10/2021 1:15 PM, David Spiegel wrote:

> I added a CLIST as part of a PTF.
> (This is not vendor software.)
> ++CLIST(ABCXYZ) ALIAS(XYZ) DISTLIB(ACLIST) SYSLIB(CLIST).
> PROC 0
> WRITE HI
> 
> When I ran the APPLY Job, the IEBCOPY Output showed
> COPY OUTDD=CLIST,INDD=SMPWRK6
>   S M=((A000,ABCXYZ,R))
> 
> Where does (the ALIAS) XYZ get copied to //CLIST?
> (It is there after the Job runs, but, there is no record of it in the 
> Job Output.)
After the IEBCOPY operation SMP/E creates the alias in the data set 
directly using the STOW data management macro.

Kurt Quackenbush -- IBM, SMP/E Development
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: SMPE: Element Contains CLIST with ALIAS

[Kurt Quackenbush]

On 5/10/2021 1:15 PM, David Spiegel wrote:


I added a CLIST as part of a PTF.
(This is not vendor software.)
++CLIST(ABCXYZ) ALIAS(XYZ) DISTLIB(ACLIST) SYSLIB(CLIST).
PROC 0
WRITE HI

When I ran the APPLY Job, the IEBCOPY Output showed
COPY OUTDD=CLIST,INDD=SMPWRK6
  S M=((A000,ABCXYZ,R))

Where does (the ALIAS) XYZ get copied to //CLIST?
(It is there after the Job runs, but, there is no record of it in the 
Job Output.)
After the IEBCOPY operation SMP/E creates the alias in the data set 
directly using the STOW data management macro.


Kurt Quackenbush -- IBM, SMP/E Development
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: SMPE: Element Contains CLIST with ALIAS

[Paul Gilmartin]

On Mon, 10 May 2021 13:15:38 -0400, David Spiegel wrote:
>
>I added a CLIST as part of a PTF.
>(This is not vendor software.)
>++CLIST(ABCXYZ) ALIAS(XYZ) DISTLIB(ACLIST) SYSLIB(CLIST).
>PROC 0
>WRITE HI
>
>When I ran the APPLY Job, the IEBCOPY Output showed
>COPY OUTDD=CLIST,INDD=SMPWRK6
>  S M=((A000,ABCXYZ,R))
> 
>Where does (the ALIAS) XYZ get copied to //CLIST?
>(It is there after the Job runs, but, there is no record of it in the
>Job Output.)
> 
Does IEBCOPY normally log that?

The Ref. is tantalizingly vague:
• Replacement elements (MACs, MODs, data elements, and program elements):
  1. If a list of aliases is specified on the SMP/E message control statement, 
these aliases
are used. The new list replaces any alias subentries in the distribution 
zone element entry.

It doesn't say how.  Perhaps SMP/E does ad-hoc STOWs.

"message control statment" (dozens of times)?  "MCS (Modification Control 
Statement)"?
Whatever.

-- gil

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

Re: SMPE Receive Order post May 1st

[Cieri, Anthony]

While I agree with your recommendations, the FTPS job does not work 
without the ciphers I listed below. Apparently IBM needs to make some 
adjustments first.



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Babcock
Sent: Wednesday, May 05, 2021 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE Receive Order post May 1st

[[ SEI WARNING *** This email was sent from an external source. Do not open 
attachments or click on links from unknown or suspicious senders. *** ]]


I would highly discourage the use of the ciphers listed.  I would use these 
more secure ciphers (I'm sure there are others that are acceptable).

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

On 5/5/2021 12:58 PM, Cieri, Anthony wrote:
>   Dave,
>   Here you go:
>
> ##
> # #
> # Secure FTP Application  #
> # #
> ###
>   
>
> TTLSRule  secure_ftp_client_rule
> {
>RemotePortRange 21   # This should be set to the port the FTP
> # listening on
>Direction  Outbound
>TTLSGroupActionRef secure_ftp_client_group
>TTLSEnvironmentActionRef   secure_ftp_client_env
> }
>   
>
> TTLSGroupAction   secure_ftp_client_group
> {
>TTLSEnabled On
>Trace   7
> }
>   
>
> TTLSEnvironmentAction secure_ftp_client_env
> {
>TTLSKeyringParms
>{
>   Keyring  /u/ftps/zos17dbf.kdb
>   KeyringStashFile /u/ftps/zos17dbf.sth
>}
>HandshakeRole   Client
> TTLSEnvironmentAdvancedParms
>{
>   ApplicationControlledOn
>   SecondaryMap On
>   SSLV3Off
>   TLSV1Off
>   TLSV1.1  Off
>   TLSV1.2  On
>}
>TTLSCipherParmsRef ftp_client_ciphers   # to cust ciphers
> }
>   
>
> TTLSCipherParms  ftp_client_ciphers
> {
> # Sample ciphers.  Should be customized!
> V3CipherSuitesTLS_RSA_WITH_AES_256_CBC_SHA
> V3CipherSuitesTLS_RSA_WITH_3DES_EDE_CBC_SHA
> V3CipherSuitesTLS_RSA_WITH_NULL_SHA
> }
>
>
> -----Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Dave Jousma
> Sent: Wednesday, May 05, 2021 1:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMPE Receive Order post May 1st
>
> [[ SEI WARNING *** This email was sent from an external source. Do not 
> open attachments or click on links from unknown or suspicious senders. 
> *** ]]
>
>
>>  Well, for what it's worth, I just tried it and my job was 
>> successful, however, I also received the SSLv23/TLSv1 messages. So I 
>> used the standard job that IBM provided (RFNJOBS) and I turned on Debug SEC.
>> Here is what I got
> (snip)
>
> Hey Tony,  Thanks for this.   For some reason we are still struggling.   
> Would you be willing to share what your pagent policy for these items:
>
> FU2420 TTLSRule: secure_ftp_client_rule
> FU2426 TTLSGroupAction: secure_ftp_client_group
> FU2432 TTLSEnvironmentAction: secure_ftp_client_env
>
> looks like?   I dont think there is anything sensitive, and if you'd rather, 
> you can send to me off-list (david.jou...@53.com)
>
> --
> 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: SMPE Receive Order post May 1st

[Michael Babcock]

Nevermind,  found this in the latest book


*TLSMECHANISM*

Use this statement to specify whether TLS is implemented by AT-TLS or by
FTP.*ATTLS indicates TLS processing is performed by AT-TLS, and must be
specified in order to support TLS 1.2 which is required by IBM's download
server.*


On Thu, May 6, 2021 at 7:46 AM Kurt Quackenbush  wrote:

> On 5/5/2021 1:13 PM, Dave Jousma wrote:
>
> > ...   For some reason we are still struggling.
> For anyone still struggling to connect with FTPS to IBM's download
> server after the May 1 server update, please, please, PLEASE consider
> telling SMP/E to use HTTPS for the downloads instead of FTPS.  It is a
> very simple update to your SMP/E job and for the vast majority of folks
> requires much less finagling with your firewall settings than for FTP.
>
> The short version: add downloadmethod and downloadkeyring to your
>  specification, like this:
>
> downloadmethod=”https”
>downloadkeyring=”javatruststore”
>javahome="/usr/lpp/java/J8.0"
>>
> 
>
> If you need more details, see the SMP/E User's Guide, here:
>
> https://www.ibm.com/docs/en/zos/2.4.0?topic=guide-preparing-secure-internet-delivery
>
> Kurt Quackenbush -- IBM, SMP/E Development
> 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
>
-- 
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead

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

Re: SMPE Receive Order post May 1st

[Michael Babcock]

What’s the secret decoder ring/handshake to make FTP work?  We need
AT-TLS?  Or can we make updates to the FTPDATA DD (using TLSMECHANISM FTP)?

On Thu, May 6, 2021 at 7:46 AM Kurt Quackenbush  wrote:

> On 5/5/2021 1:13 PM, Dave Jousma wrote:
>
> > ...   For some reason we are still struggling.
> For anyone still struggling to connect with FTPS to IBM's download
> server after the May 1 server update, please, please, PLEASE consider
> telling SMP/E to use HTTPS for the downloads instead of FTPS.  It is a
> very simple update to your SMP/E job and for the vast majority of folks
> requires much less finagling with your firewall settings than for FTP.
>
> The short version: add downloadmethod and downloadkeyring to your
>  specification, like this:
>
> downloadmethod=”https”
>downloadkeyring=”javatruststore”
>javahome="/usr/lpp/java/J8.0"
>>
> 
>
> If you need more details, see the SMP/E User's Guide, here:
>
> https://www.ibm.com/docs/en/zos/2.4.0?topic=guide-preparing-secure-internet-delivery
>
> Kurt Quackenbush -- IBM, SMP/E Development
> 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
>
-- 
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead

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

Re: SMPE Receive Order post May 1st

[Carmen Vitullo]

I was easier for me to setup and get permission from the security folks and our 
network folks, the only additional setting we needed were the proxy statements 
adding my LAN ID and password to pass thru the proxy 
   
Carmen Vitullo 

   

-Original Message-

From: Kurt 
To: IBM-MAIN 
Date: Thursday, 6 May 2021 7:46 AM CDT
Subject: Re: SMPE Receive Order post May 1st

On 5/5/2021 1:13 PM, Dave Jousma wrote: 

> ... For some reason we are still struggling. 
For anyone still struggling to connect with FTPS to IBM's download 
server after the May 1 server update, please, please, PLEASE consider 
telling SMP/E to use HTTPS for the downloads instead of FTPS. It is a 
very simple update to your SMP/E job and for the vast majority of folks 
requires much less finagling with your firewall settings than for FTP. 

The short version: add downloadmethod and downloadkeyring to your 
 specification, like this: 

 
 

If you need more details, see the SMP/E User's Guide, here: 
https://www.ibm.com/docs/en/zos/2.4.0?topic=guide-preparing-secure-internet-delivery
 

Kurt Quackenbush -- IBM, SMP/E Development 
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: SMPE Receive Order post May 1st

[Kurt Quackenbush]

On 5/5/2021 1:13 PM, Dave Jousma wrote:

...   For some reason we are still struggling.   
For anyone still struggling to connect with FTPS to IBM's download 
server after the May 1 server update, please, please, PLEASE consider 
telling SMP/E to use HTTPS for the downloads instead of FTPS.  It is a 
very simple update to your SMP/E job and for the vast majority of folks 
requires much less finagling with your firewall settings than for FTP.


The short version: add downloadmethod and downloadkeyring to your 
 specification, like this:





If you need more details, see the SMP/E User's Guide, here:
https://www.ibm.com/docs/en/zos/2.4.0?topic=guide-preparing-secure-internet-delivery

Kurt Quackenbush -- IBM, SMP/E Development
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: SMPE Receive Order post May 1st

[Tom Conley]

On 5/5/2021 2:58 PM, Michael Babcock wrote:
I would highly discourage the use of the ciphers listed.  I would use 
these more secure ciphers (I'm sure there are others that are acceptable).


TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384




I rise in agreement with my good friend Mr. Babcock.  Anything less than 
AES256/SHA384, you're asking for trouble.


Regards,
Tom Conley

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

Re: SMPE Receive Order post May 1st

[Michael Babcock]

I would highly discourage the use of the ciphers listed.  I would use 
these more secure ciphers (I'm sure there are others that are acceptable).


TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

On 5/5/2021 12:58 PM, Cieri, Anthony wrote:

Dave,
Here you go:

##
# #
# Secure FTP Application  #
# #
###
 
TTLSRule  secure_ftp_client_rule

{
   RemotePortRange 21   # This should be set to the port the FTP
# listening on
   Direction  Outbound
   TTLSGroupActionRef secure_ftp_client_group
   TTLSEnvironmentActionRef   secure_ftp_client_env
}
 
TTLSGroupAction   secure_ftp_client_group

{
   TTLSEnabled On
   Trace   7
}
 
TTLSEnvironmentAction secure_ftp_client_env

{
   TTLSKeyringParms
   {
  Keyring  /u/ftps/zos17dbf.kdb
  KeyringStashFile /u/ftps/zos17dbf.sth
   }
   HandshakeRole   Client
TTLSEnvironmentAdvancedParms
   {
  ApplicationControlledOn
  SecondaryMap On
  SSLV3Off
  TLSV1Off
  TLSV1.1  Off
  TLSV1.2  On
   }
   TTLSCipherParmsRef ftp_client_ciphers   # to cust ciphers
}
 
TTLSCipherParms  ftp_client_ciphers

{
# Sample ciphers.  Should be customized!
V3CipherSuitesTLS_RSA_WITH_AES_256_CBC_SHA
V3CipherSuitesTLS_RSA_WITH_3DES_EDE_CBC_SHA
V3CipherSuitesTLS_RSA_WITH_NULL_SHA
}


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Dave Jousma
Sent: Wednesday, May 05, 2021 1:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE Receive Order post May 1st

[[ SEI WARNING *** This email was sent from an external source. Do not open 
attachments or click on links from unknown or suspicious senders. *** ]]



Well, for what it's worth, I just tried it and my job was successful,
however, I also received the SSLv23/TLSv1 messages. So I used the
standard job that IBM provided (RFNJOBS) and I turned on Debug SEC.
Here is what I got

(snip)

Hey Tony,  Thanks for this.   For some reason we are still struggling.   Would 
you be willing to share what your pagent policy for these items:

FU2420 TTLSRule: secure_ftp_client_rule
FU2426 TTLSGroupAction: secure_ftp_client_group
FU2432 TTLSEnvironmentAction: secure_ftp_client_env

looks like?   I dont think there is anything sensitive, and if you'd rather, 
you can send to me off-list (david.jou...@53.com)

--
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: SMPE Receive Order post May 1st

[Dave Jousma]

>Dave,
Here you go:

>## 
># #
> 
># Secure FTP Application  #
> 
># #
> 
>###  

Thank you, Sir!

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

Re: SMPE Receive Order post May 1st

[Cieri, Anthony]

Dave,
Here you go:

## 
# # 
# Secure FTP Application  # 
# # 
### 

TTLSRule  secure_ftp_client_rule
   {
  RemotePortRange 21   # This should be set to the port the FTP 
   # listening on   
  Direction  Outbound   
  TTLSGroupActionRef secure_ftp_client_group
  TTLSEnvironmentActionRef   secure_ftp_client_env  
   }

TTLSGroupAction   secure_ftp_client_group   
{   
  TTLSEnabled On
  Trace   7 
}   

TTLSEnvironmentAction secure_ftp_client_env 
   {
  TTLSKeyringParms  
  { 
 Keyring  /u/ftps/zos17dbf.kdb  
 KeyringStashFile /u/ftps/zos17dbf.sth
  } 
  HandshakeRole   Client
TTLSEnvironmentAdvancedParms
  { 
 ApplicationControlledOn
 SecondaryMap On
 SSLV3Off   
 TLSV1Off   
 TLSV1.1  Off   
 TLSV1.2  On
  } 
  TTLSCipherParmsRef ftp_client_ciphers   # to cust ciphers 
   }

TTLSCipherParms  ftp_client_ciphers 
{   
   # Sample ciphers.  Should be customized! 
   V3CipherSuitesTLS_RSA_WITH_AES_256_CBC_SHA   
   V3CipherSuitesTLS_RSA_WITH_3DES_EDE_CBC_SHA  
   V3CipherSuitesTLS_RSA_WITH_NULL_SHA  
}   
  


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Dave Jousma
Sent: Wednesday, May 05, 2021 1:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE Receive Order post May 1st

[[ SEI WARNING *** This email was sent from an external source. Do not open 
attachments or click on links from unknown or suspicious senders. *** ]]


>   Well, for what it's worth, I just tried it and my job was successful, 
>however, I also received the SSLv23/TLSv1 messages. So I used the 
>standard job that IBM provided (RFNJOBS) and I turned on Debug SEC. 
>Here is what I got

(snip)

Hey Tony,  Thanks for this.   For some reason we are still struggling.   Would 
you be willing to share what your pagent policy for these items:

FU2420 TTLSRule: secure_ftp_client_rule
FU2426 TTLSGroupAction: secure_ftp_client_group
FU2432 TTLSEnvironmentAction: secure_ftp_client_env

looks like?   I dont think there is anything sensitive, and if you'd 

Re: SMPE Receive Order post May 1st

[Dave Jousma]

>   Well, for what it's worth, I just tried it and my job was successful, 
> however, I also received the SSLv23/TLSv1 messages. So I used the standard 
> job that IBM provided (RFNJOBS) and I turned on Debug SEC. Here is what I got

(snip)

Hey Tony,  Thanks for this.   For some reason we are still struggling.   Would 
you be willing to share what your pagent policy for these items:

FU2420 TTLSRule: secure_ftp_client_rule
FU2426 TTLSGroupAction: secure_ftp_client_group
FU2432 TTLSEnvironmentAction: secure_ftp_client_env

looks like?   I dont think there is anything sensitive, and if you'd rather, 
you can send to me off-list (david.jou...@53.com)

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

Re: SMPE Receive Order post May 1st

[Cieri, Anthony]

Well, for what it's worth, I just tried it and my job was successful, 
however, I also received the SSLv23/TLSv1 messages. So I used the standard job 
that IBM provided (RFNJOBS) and I turned on Debug SEC. Here is what I got:

220 dhebpcb01 secure FTP server ready. 
FC0294 ftpAuth: security values: mech=TLS, tlsmech=ATTLS, tlsreuse=N, sFTP=R, s
C=C, sDC=P 
FC2971 ftpAuthAttls: AT-TLS policy set as application controlled.  
FU2420 TTLSRule: secure_ftp_client_rule
FU2426 TTLSGroupAction: secure_ftp_client_group
FU2432 TTLSEnvironmentAction: secure_ftp_client_env
>>> AUTH TLS   
234 SSLv23/TLSv1   
FC3140 authServerAttls: Start Handshake
FC3171 authServerAttls: FIPS140 not enabled
FC3208 authServerAttls: Using TLSv1.2 protocol 
FC3226 authServerAttls: SSL cipher: 0035   
FU2135 getCtrlConnCertAttls: Request certificate, size 1581
FU2755 getSessionIdAttls: Issuing SIOCTTLSCTL to get decoded AT-TLS Session ID 
Authentication negotiation succeeded   
FC2028 setdlevel: entered  
FC2197 setpbsz: entered
>>> PBSZ 0 
200 PBSZ=0 
>>> PROT P 
200 Command PROT okay. 
Data connection protection is private 
NAME (deliverycb-bld.dhe.ibm.com:SCNS03T): 
   
> P8r12142 
>>> USER P8r12142  
331 Password required for P8r12142.
PASSWORD:  
   
> ***  
>>> PASS   
230 virtual user P8r12142 logged in from /12.31.24.5:6457. 
Command:   
   
> CCC  
> BINARY   
FC1559 ccc: entered
FC1757 setclevel: entered  
>>> CCC
200 Command Channel Cleared.   
FU2364 clear_connection_attls: Issue Stop request  
Control connection protection is clear 
Command: 
Command:   
CG1018 find_hfs_file: stat() failed on /u/smpe/smpnts/OSP08132/GIMPAF.XML - EDC
129I No such file or directory. (errno2=0x053B006C)
>>> EPSV   
229 Entering Passive Mode (|||65525|)  
>>> RETR 2021042900039/PROD/GIMPAF.XML 
150 Opening BINARY mode data connection for 2021042900039/PROD/GIMPAF.XML. 
FU1678 protDataConnAttls: Issuing SIOCTTLSCTL to query policy state
FU1720 protDataConnAttls: AT-TLS policy set as application controlled. 
FU2420 TTLSRule: secure_ftp_client_rule
FU2426 TTLSGroupAction: secure_ftp_client_group
FU2432 TTLSEnvironmentAction: secure_ftp_client_env
FU1834 protDataConnAttls: Issuing SIOCTTLSCTL to start handshake   
FU1866 protDataConnAttls: FIPS140 not enabled  
FU1907 protDataConnAttls: Using TLSv1.2 protocol
<<-TLSv1.2
FU1924 protDataConnAttls: SSL cipher: 0035 
FU2255 compareCertAttls: 

Re: SMPE Receive Order post May 1st

[Dave Jousma]

I should have commented that the HTTPS method is working fine.   And my last 
successful FTPs download was last week Monday April 26th.

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

Re: SMPe receive e37-04 on SMPPTS1

[Radoslaw Skorupka]

W dniu 25.04.2021 o 16:44, Paul Gilmartin pisze:

On Sun, 25 Apr 2021 03:08:44 +0200, Radoslaw Skorupka wrote:

Before APPLY - take care about SMPPTS1 DDDEFs in other zones.


Is it useful, or even safe, to define SMPPTS* in other than GLOBAL zone?

It is necessary.


Does SMP/E warn or prohibit inconsistent SMPPTS* definitions among
zones?

Yes. BTDT.


This implies that:
o SMP/E is aware of the GLOBAL SMPPTS definitions
o And prefers that the DLIB/TARGEt definitions match the GLOBAL.

So I wonder why SMP/E doesn't eliminate any requirement for
other zones and simply rely on the GLOBAL SMPPTS*.

Something I don't understand about SMP/E design philosophy.


Wrong answer, SMP/E does NOT warn or prohibit PTS inconsistency among 
zones.


Regarding design philosophy - I can only guess it is result of 40+ years 
old "not so good" decisions and limitations.
IMHO it would look completely different when created from scratch with 
no compatibility with "legacy".

However it works. And admins role is to follow the rules.

BTW: the more you know the SMP/E the idiosyncrasies are less and less 
annoying and sometimes you find something useful.



--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland

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

Re: SMPe receive e37-04 on SMPPTS1

[Paul Gilmartin]

On Sun, 25 Apr 2021 03:08:44 +0200, Radoslaw Skorupka wrote:
>>
>>> Before APPLY - take care about SMPPTS1 DDDEFs in other zones.
>>>
>> Is it useful, or even safe, to define SMPPTS* in other than GLOBAL zone?
>
>It is necessary.
>
>> Does SMP/E warn or prohibit inconsistent SMPPTS* definitions among
>> zones?
>
>Yes. BTDT.
>
This implies that:
o SMP/E is aware of the GLOBAL SMPPTS definitions
o And prefers that the DLIB/TARGEt definitions match the GLOBAL.

So I wonder why SMP/E doesn't eliminate any requirement for
other zones and simply rely on the GLOBAL SMPPTS*.

Something I don't understand about SMP/E design philosophy.

-- gil

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