> 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 /
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**:
> 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
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
> 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
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
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
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
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
@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:
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
@ 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
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.
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
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
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
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**:
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
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
> 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
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
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
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
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.
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
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
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
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
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
> 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
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
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
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
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
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?
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
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
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
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
nal 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
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
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
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
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 -
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.
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
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,
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
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,
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
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
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
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
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
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:
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
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?
>
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
day, 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
&
etz3
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
(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
/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
@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,
+ 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
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
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
: 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
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
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
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 *
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
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?
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
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
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:
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()
>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 --
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
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
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,
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
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,
s 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@LISTSER
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
>
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))
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
: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
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,
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.
>
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, PLE
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
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
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
>Dave,
Here you go:
>##
># #
>
># Secure FTP Application #
>
>#
}
-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
> 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
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.
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
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
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
1 - 100 of 426 matches
Mail list logo
