Re: APAR theology (was: IBM APAR Names)

[Jon Perryman]

On Fri, 3 Nov 2023 22:24:02 -0400, Doug  wrote:

> SMPE claims to be the all knowing wizard but won’t do the resolution.

SMP/e is not (nor ever claimed) to be the all knowing wizard. It is a tool used 
by IBM and vendors for keeping your z/OS problem free.

It does not resolve problems. It simply does what vendors tell it to do through 
SMP/e statements. If a ++HOLD was forgotten, then you may not be aware of an 
action, doc change and much more that you must take after the PTF is applied. A 
tool is only as good as those who use it.

>The problem is I have to find and read every PTF / APAR one by one..

I'm not sure what you mean. Your processes for installing PTF's may be tedious 
but you could also take the UNIX approach where you don't get the choice and 
simply install bundled fixes call releases.

>Determine if the fix does what I need (maybe all the causes are documented But 
>hardly ever).

Processes are not the problem. APARs document the defect and it's resolution. 
Some causes may not be known.  Some people are more meticulous than others. The 
failure comes down to us being human.

Also remember that z/OS is becoming more like UNIX. Skills are being lost and 
diluted.

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

Re: APAR theology (was: IBM APAR Names)

[Jon Perryman]

On Fri, 3 Nov 2023 20:51:44 -0400, Phil Smith III  wrote:

> I�m interested in how this works.

This must be discussed in the bigger picture of problem management and the 
processes involved. Think about problems your child experiences. Your problem 
resolution processes for your child will be very different than their school 
principal and teachers.

For the z/OS world, the only consistent process is the tool SMP/e but even 
SMP/e has some flexibility. Understand that no 2 vendors (including IBM) will 
use the same process to go from having a problem to having a solved problem. 
This is a general description of the processes that is taken which will be 
missing a lot of detail.

>*  PMR: represents a customer issue, which may end there.

PMR (Problem Management Record) is IBM's tool used for working a problem. All 
vendors have a similar tool but with a different name and different 
functionality.

This tool allows us to efficiently work YOUR problem and access the processes 
needed to solve your problem. You send in a dump and we are notified. You call 
back, the operators know where to forward your call. The person working your 
problem is out and someone can see what they've done. The list of processes is 
simply to long to be discussed.

>*  APAR: represents a customer issue that at least seems to indicate a 
>code problem. 

An APAR is the public documentation of a product defect that has (or will be) 
fixed. PMR's contain confidential information and multiple PMR's may discuss 
the same problem, thus are not usable to document the fix to a product defect.

The definition of FIX is different between vendors (including IBM). All vendors 
agree that a PTF is a fix but some vendors include doc changes, faqs and more 
as product defect fixes. In other words, for some vendors, an APAR always fixes 
an actual product defect while other vendors muddy the waters by including any 
form of addressing a product defect.

SMP/e further muddies the definition of APAR by how it uses the word APAR. 
++APAR is one of several APAR processes that SMP/e provides. ++APAR is not an 
APAR nor is it a fix to the APAR. It's a process provided by SMP/e that allows 
us to circumvent problems so severe that you can't wait for the PTF. For 
instance, your system repeatedly crashes. I can create a ++APAR that stops the 
crashes but does not solve the defect. People ignore that removing the ++APAR 
is a critical part of the process.
 
>*  Existence of an APAR does not guarantee a fix will ever be created; 

As discussed above, an APAR will always be fixed. The definition of fixed is 
fuzzy.

>*  PTF: An actual fix

Yes and more to the point, a PTF fixes the APAR for a specific product release.

>Now y�all are talking about �APAR fixes�, which I�ve never heard of. 

Only PTF's fix a product defect. An APAR is the documentation for a product 
defect. As part of that documentation, It will contain a list of one or more 
PTF's that fix this APAR. These are the APAR fixes. 

> And I know there�s more to APARs than I wrote

I've only mentioned the APAR processes that are easily understood.

> Having worked for vendors for the last 37 years means I�ve been out of the 
> normal flow of such things

APARs are vendor processes that customers won't see. 

>ISTR that if a problem appears in multiple supported releases, one APAR might 
>result in multiple PTFs, one per release.

In the past, IBM releases were more frequent. It was not unusual to see 
multiple PTF. Today, with longer release cycles, I would expect one PTF per 
apar.

>I�m also interested in a definitive list of APAR closings.

With each vendor having different APAR processes, there isn't a common method 
of retrieving a list of APARs. With IBM selling off products but still 
marketing those products, it's unlikely you will find this list for IBM 
marketed products. With APAR processes differing by vendor, closed APAR could 
have muddy definition of closed.

>None of this matters a ton, of course, but it *works* when done right,
>which is more than I can say for many customer problem workflows!

This is more about the tools that implement the processes. Each vendor has 
their own tools and more important, those tools can be different within a 
vendor.

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

Re: IBM APAR Names

[Paul Gilmartin]

On Fri, 3 Nov 2023 22:05:41 -0500, Jon Perryman wrote:
>
>>Grrr.  IBM's registered component prefixes govern program objects, etc., but
>>not SYSMODs.  The best we could do was choose an unlikely prefix.
>
>What were you thinking! All IBM PTF's & APARs begin with XX#. Unless you 
>unwisely chose a component prefix with a number, your component code will 
>never conflict with IBM standards. As for distinguishing APARs from PTFs, 
>there's nothing stopping you from registering a second component code solely 
>for APARS. As for choosing an unlikely prefix, hopefully you didn't use a 
>registered component code because I think this is a standard vendor practice 
>(at least where I've been).
>
"Standard"?  Cite.  Does IBM state that component codes prefix SYSMOD IDs.

>>Almost so.  By IBM's convention, the APAR Fix SUPs the matching APAR.
>
>This makes no sense. You never SUP yourself. What you are calling APAR FIX 
>here refers to a PTF. Only resolving PTFs SUP the APAR. In fact, APARs will 
>never contain a SUP unless absolutely necessary. An incorrect used SUP can 
>cause a new APAR just to fix SMP/e.
>
OK.  A PTF SUPs an APAR it correcrs.  It may suffice for an APAR Fix to match 
the
APAR ID.

>>++HOLD identifies the APAR as the REASON().
>
>You don't understand ++HOLD because APAR numbers are not specified in 
>REASON(). The correct use is REASON(ERROR) ...  
>

Example 2: Marking a PTF that is in error
++HOLD (UZ12345)/* Hold this PTF*/
   FMID(FXY1040)/* for this function*/
   ERROR/* for APAR fix.*/
   REASON(AZ1)  /* APAR is AZ1. */
   COMMENT(this APAR causes loop) 

>>It is also allowed for the  APAR Fix to have the same ID as the APAR.
>>IBM doc has repeatedly misstated that and been fixed by my RCF.
>>
>>The ultimate PTF SUPs both.
>
>What you are saying makes no sense. In terms of SMP/e, ++APAR is what you call 
>APAR FIX. 
>
IBM chose ++APAR as the MCS to introduce what IBM calls an APAR FIX. 

In terms of SMP/e, what does "APAR' refer to that you can now specify and was 
implemented because of your RCF?
>
Nothing was "implemented" because of my RCF.  The RCF simply corrected
description of unchanged behavior.

>> Mind the distinction between "APAR" and "APAR Fix".
>>APARs are routinely created; APAR Fixes are not.
>>
>
>Actually, APAR is a logical process. You ignore other SMP/e APAR interactions 
>such as ++HOLD, ++PTF and more that don't require ++ APAR. And you ignore 
>important processes that are outside of SMP/e like the problem database. All 
>these processes must be coordinated which is where APAR id comes in. 
>
They're documented.  I needn't quote the entire manual.

>What you call "APAR FIX" refers to ++APAR 
>
What IBM calls an APAR Fix.

>which is just one optional piece of the APAR. To use it correctly, the APAR ID 
>must be specified in the PTF as a SUP. As part of the process, it provides a 
>convenient method to temporarily solve a critical customer problem where they 
>require the use of SMP/e.
>
I agree.

>>The name space is too damned small!  Listen, IBM!  (I'd like "com.".)
>
>As for name space, I'm not sure about the relevance to SMP/e. What is the 
>SMP/e statement / option to which you are referring?
>
Working for an ISV, I would have liked to embed a registered trademark in our 
SYSMOD IDs.

--  
gil

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

Re: IBM APAR Names

[Tony Harminc]

On Fri, 3 Nov 2023 at 18:03, Jon Perryman  wrote:
[...]

> Anything beginning with I to Z was reserved for IBM use (e.g. IEFJRASP,
> OA12345, UA12345). I suspect that most vendors use the IBM registry for 3
> character codes from A to H. Each product must choose a method that best
> fits the company requirements.
>

Backwards. A-I is IBM; J-Z (minus Q, which is reserved for IBM i) and
numerics is for everyone else. This applies to component IDs, and function
sysmods (FMIDs) are expected to take the form tcccrrr, where t values of
A-J are IBM's and everything else is user/vendor land, and ccc is the
component ID and rrr the version/release. But I don't think these have ever
applied to fix names like OA12345.

IBM seems to have abandoned the Standard Packaging Rules for z/OS-Based
Products book, in favour of a tiny section on naming in the SMP/E
Reference. Gone is the offer to register component IDs with
elem...@us.ibm.com .

Tony H.

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

Re: IBM APAR Names

[Jon Perryman]

On Fri, 3 Nov 2023 17:35:10 -0500, Paul Gilmartin  wrote:

>Grrr.  IBM's registered component prefixes govern program objects, etc., but
>not SYSMODs.  The best we could do was choose an unlikely prefix.

What were you thinking! All IBM PTF's & APARs begin with XX#. Unless you 
unwisely chose a component prefix with a number, your component code will never 
conflict with IBM standards. As for distinguishing APARs from PTFs, there's 
nothing stopping you from registering a second component code solely for APARS. 
As for choosing an unlikely prefix, hopefully you didn't use a registered 
component code because I think this is a standard vendor practice (at least 
where I've been).

>Almost so.  By IBM's convention, the APAR Fix SUPs the matching APAR.

This makes no sense. You never SUP yourself. What you are calling APAR FIX here 
refers to a PTF. Only resolving PTFs SUP the APAR. In fact, APARs will never 
contain a SUP unless absolutely necessary. An incorrect used SUP can cause a 
new APAR just to fix SMP/e.

>++HOLD identifies the APAR as the REASON().

You don't understand ++HOLD because APAR numbers are not specified in REASON(). 
The correct use is REASON(ERROR) and specify the resolving APAR. The fixing PTF 
SUPs the APAR thus releasing the ++HOLD ERROR.  

>It is also allowed for the  APAR Fix to have the same ID as the APAR.
>IBM doc has repeatedly misstated that and been fixed by my RCF.
>
>The ultimate PTF SUPs both.

What you are saying makes no sense. In terms of SMP/e, ++APAR is what you call 
APAR FIX. In terms of SMP/e, what does "APAR' refer to that you can now specify 
and was implemented because of your RCF?

> Mind the distinction between "APAR" and "APAR Fix".
>APARs are routinely created; APAR Fixes are not.
>

Actually, APAR is a logical process. You ignore other SMP/e APAR interactions 
such as ++HOLD, ++PTF and more that don't require ++ APAR. And you ignore 
important processes that are outside of SMP/e like the problem database. All 
these processes must be coordinated which is where APAR id comes in. 

What you call "APAR FIX" refers to ++APAR which is just one optional piece of 
the APAR. To use it correctly, the APAR ID must be specified in the PTF as a 
SUP. As part of the process, it provides a convenient method to temporarily 
solve a critical customer problem where they require the use of SMP/e.

>The name space is too damned small!  Listen, IBM!  (I'd like "com.".)

As for name space, I'm not sure about the relevance to SMP/e. What is the SMP/e 
statement / option to which you are referring?

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

Re: APAR theology (was: IBM APAR Names)

[Paul Gilmartin]

On Fri, 3 Nov 2023 20:51:44 -0400, Phil Smith III wrote:
>
>I�m also interested in a definitive list of APAR closings. I�ve never seen 
>one, and the lists I�ve seen have been conflicting and often included 
>different interpretations of the same closing.
>


-- 
gil

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

Re: APAR theology (was: IBM APAR Names)

[Doug]

The problem is I have to find and read every PTF / APAR one by one..
Determine if the fix does what I need (maybe all the causes are documented But 
hardly ever). 
Why ? SMPE claims to be the all knowing wizard but won’t do the resolution.

I’m with Phil on this issue.

Just my 2 cents 

.

On Nov 3, 2023, at 22:10, Paul Gilmartin 
<042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

On Fri, 3 Nov 2023 20:51:44 -0400, Phil Smith III  wrote:
> 
> My understanding is:
> 
> *PMR: represents a customer issue, which may end there.
> 
This generally embeds tie ID of the reporting customer.

> *APAR: represents a customer issue that at least seems to indicate a code 
> problem. Existence 
> 
Importantly, the APAR ID may appear as the REASON() of Error HOLDDATA.

> *PTF: An actual fix

> Now y�all are talking about �APAR fixes�, which I�ve never heard of.
> 
The term appears at least here:


(The PTF keyword/phrase index was my friend.)


-- 
gil

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

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

Re: APAR theology (was: IBM APAR Names)

[Paul Gilmartin]

On Fri, 3 Nov 2023 20:51:44 -0400, Phil Smith III  wrote:
>
>My understanding is:
>
>*  PMR: represents a customer issue, which may end there.
>
This generally embeds tie ID of the reporting customer.

>*  APAR: represents a customer issue that at least seems to indicate a 
>code problem. Existence 
>
Importantly, the APAR ID may appear as the REASON() of Error HOLDDATA.

>*  PTF: An actual fix

>Now y�all are talking about �APAR fixes�, which I�ve never heard of.
>
The term appears at least here:


(The PTF keyword/phrase index was my friend.)


-- 
gil

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

APAR theology (was: IBM APAR Names)

[Phil Smith III]

Without wanting to start a war, I’m interested in how this works. I’ve worked 
with IBM stuff for over four decades, but mostly with VM until the last 15 or 
so years.

 

My understanding is:

*   PMR: represents a customer issue, which may end there.
*   APAR: represents a customer issue that at least seems to indicate a 
code problem. Existence of an APAR does not guarantee a fix will ever be 
created; it’s more a recognition that there’s more to it than just “customer 
needs an existing fix”, “is doing something dumb”, etc. One APAR might thus map 
to multiple PMRs, if multiple customers have the same problem.
*   PTF: An actual fix

 

Now y’all are talking about “APAR fixes”, which I’ve never heard of. And I know 
there’s more to APARs than I wrote, just can’t remember it. Having worked for 
vendors for the last 37 years means I’ve been out of the normal flow of such 
things, too—when I was at UofWaterloo, we had a backlog of a couple of hundred 
things that we’d fixed in IBM code; we had an agreement with our PSR—the sort 
of “level 1 ½” that customers have [had, then, anyway] that we’d only have 5 
open at once. That was always fun: call IBM, “I want to open five problems.” 
“FIVE PROBLEMS???!” “Well, I have a couple of hundred, but I’m only opening 
five today.” “Oh, ok.”

 

ISTR that if a problem appears in multiple supported releases, one APAR might 
result in multiple PTFs, one per release.

 

I’m also interested in a definitive list of APAR closings. I’ve never seen one, 
and the lists I’ve seen have been conflicting and often included different 
interpretations of the same closing.

 

None of this matters a ton, of course, but it *works* when done right, which is 
more than I can say for many customer problem workflows!

 

I don’t see this as particularly sensitive info, but perhaps IBM will disagree, 
in which case I’ll STFU.


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

Re: Rocket miniconda frustrations

[David Crayford]

> On 4 Nov 2023, at 7:44 am, Jousma, David 
> <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
> 
> We do pay for GIT client support through IBM, which I realize is actually 
> rocket support behind the scenes.cURL used to come packaged with GIT 
> client but was removed with IBM ptf.

cURL is a pre-req for Git. IMO, this is a PE. I’ve asked the question at Rocket 
but I think you should open a case with IBM. 

> 
> I was able to just go to the public anaconda website, and download the cURL 
> tarball, upload it, and expand it and clone it where needed.   Our Jenkins 
> pipeline needs it.
> 
> Dave Jousma
> 
> Vice President | Director, Technology Engineering
> 
> 
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, 
> MI 49546
> 
> 616.653.8429
> 
> From: IBM Mainframe Discussion List  on behalf of 
> David Crayford 
> Sent: Friday, November 3, 2023 7:01:11 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Rocket miniconda frustrations
> 
>> On 3 Nov 2023, at 10: 32 pm, Paul Gilmartin <042bfe9c879d-dmarc-request@ 
>> LISTSERV. UA. EDU> wrote: > > On Fri, 3 Nov 2023 19: 42: 15 +0800, David 
>> Crayford wrote: >> >> Yes. But you still need the internet .. . >>
> 
> 
>> On 3 Nov 2023, at 10:32 pm, Paul Gilmartin 
>> <042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> On Fri, 3 Nov 2023 19:42:15 +0800, David Crayford  wrote:
>>> 
>>> Yes. But you still need the internet ...
>>> 
>> What's the alternative?  Railway Express?  Dialup modem?
> 
> A lot of customers air-gap their mainframe systems so you can’t use package 
> managers. Colin Paice opened an issue for my pyzfile Python package to 
> document installation methods on air-gapped systems 
> https://urldefense.com/v3/__https://community.ibm.com/community/user/ibmz-and-linuxone/discussion/reading-an-mvs-dataset-using-z-open-automation-utility__;!!MwwqYLOC6b6whF7V!nVlHVMjwgMI8doNcGXgOJIwnci0yoWLQREmOo_7c-J1hWzEQQaXiHBinMK7zqEFHNnMuAhcKDi1m24hwsjs$.
> 
> Dave Jousma seems to have found a solution to his problem. Rocket provide an 
> off-line channel for ported tools but it’s only available to customers with 
> commercial support, in which case you have the choice of SMP/E. Most 
> customers that are using ported tools for critical work, such as Git, have 
> commercial support. Z/OS Open Tools is a great alternative if you only 
> require free tools. They have ported tools not available from Rocket, such as 
> nano, which most ISPF users will find easier to use then vim.
> 
>> 
>> --
>> gil
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> This e-mail transmission contains information that is confidential and may be 
> privileged.   It is intended only for the addressee(s) named above. If you 
> receive this e-mail in error, please do not read, copy or disseminate it in 
> any manner. If you are not the intended recipient, any disclosure, copying, 
> distribution or use of the contents of this information is prohibited. Please 
> reply to the message immediately by informing the sender that the message was 
> misdirected. After replying, please erase it from your computer system. Your 
> assistance in correcting this error is appreciated.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Rocket miniconda frustrations

[David Crayford]

Thanks for the feedback Dave (and RS). I wish Rocket still had download links 
to the tarballs, or even better, pax files. I find this particularly useful 
when downloading new versions of Python from IBM, albeit once I’ve had to go 
through a couple of web forms to eventually get the link URL so I can curl it 
down. 

I’ll feed it back to the PT team. 

> On 4 Nov 2023, at 7:44 am, Jousma, David 
> <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
> 
> We do pay for GIT client support through IBM, which I realize is actually 
> rocket support behind the scenes.cURL used to come packaged with GIT 
> client but was removed with IBM ptf.
> 
> I was able to just go to the public anaconda website, and download the cURL 
> tarball, upload it, and expand it and clone it where needed.   Our Jenkins 
> pipeline needs it.
> 
> Dave Jousma
> 
> Vice President | Director, Technology Engineering
> 
> 
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, 
> MI 49546
> 
> 616.653.8429
> 
> From: IBM Mainframe Discussion List  on behalf of 
> David Crayford 
> Sent: Friday, November 3, 2023 7:01:11 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Rocket miniconda frustrations
> 
>> On 3 Nov 2023, at 10: 32 pm, Paul Gilmartin <042bfe9c879d-dmarc-request@ 
>> LISTSERV. UA. EDU> wrote: > > On Fri, 3 Nov 2023 19: 42: 15 +0800, David 
>> Crayford wrote: >> >> Yes. But you still need the internet .. . >>
> 
> 
>> On 3 Nov 2023, at 10:32 pm, Paul Gilmartin 
>> <042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> On Fri, 3 Nov 2023 19:42:15 +0800, David Crayford  wrote:
>>> 
>>> Yes. But you still need the internet ...
>>> 
>> What's the alternative?  Railway Express?  Dialup modem?
> 
> A lot of customers air-gap their mainframe systems so you can’t use package 
> managers. Colin Paice opened an issue for my pyzfile Python package to 
> document installation methods on air-gapped systems 
> https://urldefense.com/v3/__https://community.ibm.com/community/user/ibmz-and-linuxone/discussion/reading-an-mvs-dataset-using-z-open-automation-utility__;!!MwwqYLOC6b6whF7V!nVlHVMjwgMI8doNcGXgOJIwnci0yoWLQREmOo_7c-J1hWzEQQaXiHBinMK7zqEFHNnMuAhcKDi1m24hwsjs$.
> 
> Dave Jousma seems to have found a solution to his problem. Rocket provide an 
> off-line channel for ported tools but it’s only available to customers with 
> commercial support, in which case you have the choice of SMP/E. Most 
> customers that are using ported tools for critical work, such as Git, have 
> commercial support. Z/OS Open Tools is a great alternative if you only 
> require free tools. They have ported tools not available from Rocket, such as 
> nano, which most ISPF users will find easier to use then vim.
> 
>> 
>> --
>> gil
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> This e-mail transmission contains information that is confidential and may be 
> privileged.   It is intended only for the addressee(s) named above. If you 
> receive this e-mail in error, please do not read, copy or disseminate it in 
> any manner. If you are not the intended recipient, any disclosure, copying, 
> distribution or use of the contents of this information is prohibited. Please 
> reply to the message immediately by informing the sender that the message was 
> misdirected. After replying, please erase it from your computer system. Your 
> assistance in correcting this error is appreciated.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Rocket miniconda frustrations

[Jousma, David]

We do pay for GIT client support through IBM, which I realize is actually 
rocket support behind the scenes.cURL used to come packaged with GIT client 
but was removed with IBM ptf.

I was able to just go to the public anaconda website, and download the cURL 
tarball, upload it, and expand it and clone it where needed.   Our Jenkins 
pipeline needs it.

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Friday, November 3, 2023 7:01:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Rocket miniconda frustrations

> On 3 Nov 2023, at 10: 32 pm, Paul Gilmartin <042bfe9c879d-dmarc-request@ 
> LISTSERV. UA. EDU> wrote: > > On Fri, 3 Nov 2023 19: 42: 15 +0800, David 
> Crayford wrote: >> >> Yes. But you still need the internet .. . >>


> On 3 Nov 2023, at 10:32 pm, Paul Gilmartin 
> <042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Fri, 3 Nov 2023 19:42:15 +0800, David Crayford  wrote:
>>
>> Yes. But you still need the internet ...
>>
> What's the alternative?  Railway Express?  Dialup modem?

A lot of customers air-gap their mainframe systems so you can’t use package 
managers. Colin Paice opened an issue for my pyzfile Python package to document 
installation methods on air-gapped systems 
https://urldefense.com/v3/__https://community.ibm.com/community/user/ibmz-and-linuxone/discussion/reading-an-mvs-dataset-using-z-open-automation-utility__;!!MwwqYLOC6b6whF7V!nVlHVMjwgMI8doNcGXgOJIwnci0yoWLQREmOo_7c-J1hWzEQQaXiHBinMK7zqEFHNnMuAhcKDi1m24hwsjs$.

Dave Jousma seems to have found a solution to his problem. Rocket provide an 
off-line channel for ported tools but it’s only available to customers with 
commercial support, in which case you have the choice of SMP/E. Most customers 
that are using ported tools for critical work, such as Git, have commercial 
support. Z/OS Open Tools is a great alternative if you only require free tools. 
They have ported tools not available from Rocket, such as nano, which most ISPF 
users will find easier to use then vim.

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


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


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

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

Re: Rocket miniconda frustrations

[David Crayford]

> On 3 Nov 2023, at 10:32 pm, Paul Gilmartin 
> <042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Fri, 3 Nov 2023 19:42:15 +0800, David Crayford  wrote:
>> 
>> Yes. But you still need the internet ... 
>> 
> What's the alternative?  Railway Express?  Dialup modem?

A lot of customers air-gap their mainframe systems so you can’t use package 
managers. Colin Paice opened an issue for my pyzfile Python package to document 
installation methods on air-gapped systems 
https://community.ibm.com/community/user/ibmz-and-linuxone/discussion/reading-an-mvs-dataset-using-z-open-automation-utility.
 

Dave Jousma seems to have found a solution to his problem. Rocket provide an 
off-line channel for ported tools but it’s only available to customers with 
commercial support, in which case you have the choice of SMP/E. Most customers 
that are using ported tools for critical work, such as Git, have commercial 
support. Z/OS Open Tools is a great alternative if you only require free tools. 
They have ported tools not available from Rocket, such as nano, which most ISPF 
users will find easier to use then vim. 

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


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

Re: IBM APAR Names

[Paul Gilmartin]

On Fri, 3 Nov 2023 17:02:54 -0500, Jon Perryman  wrote:
>
>I think you misunderstand APARs because you question doesn't make sense.
>
>1. APARs are PTFs that are very rarely created and never required to be 
>applied.
>2. Most product developers will never write an APAR write an actual APAR 
>because the problem must be so serious that a customer can't wait for the PTF 
>solving the problem described in the APAR.
>
 Mind the distinction between "APAR" and "APAR Fix".
APARs are routinely created; APAR Fixes are not.


>4. The resolving PTF will always SUP the APAR. An SMP/e search for the APAR is 
>sufficient but you must verify the APAR has been SUP'd. An applied APAR is 
>considered a very temporary fix that may not completely resolve the problem. 
>
Almost so.  By IBM's convention, the APAR Fix SUPs the matching APAR.
++HOLD identifies the APAR as the REASON().
It is also allowed for the  APAR Fix to have the same ID as the APAR.
IBM doc has repeatedly misstated that and been fixed by my RCF.

The ultimate PTF SUPs both.

>6. The APAR number choice has no real significance except how a product has 
>chosen to avoid SMP/e collisions. For instance, you say AH went to 
>PHx, In the past, this told me that IBM probably acquired a vendor 
>product. Anything beginning with I to Z was reserved for IBM use (e.g. 
>IEFJRASP, OA12345, UA12345). I suspect that most vendors use the IBM registry 
>for 3 character codes from A to H. Each product must choose a method that best 
>fits the company requirements. 
>
Grrr.  IBM's registered component prefixes govern program objects, etc., but
not SYSMODs.  The best we could do was choose an unlikely prefix.
The name space is too damned small!  Listen, IBM!  (I'd like "com.".)

-- 
gil

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

Re: IBM APAR Names

[Jon Perryman]

On Fri, 3 Nov 2023 19:44:32 +0100, Radoslaw Skorupka  
wrote:
>>W dniu 03.11.2023 o 17:32, Shaffer, Terri pisze:ry
>> Can anyone give me the secret decoder
>> I know AHx went to PHx

I think you misunderstand APARs because you question doesn't make sense.

1. APARs are PTFs that are very rarely created and never required to be applied.
2. Most product developers will never write an APAR write an actual APAR 
because the problem must be so serious that a customer can't wait for the PTF 
solving the problem described in the APAR.
3. Unlike PTF's, most vendors use the same APAR number tailoring the APAR fix 
specific to each customer that needs it. For example, problem spans multiple 
versions of the product or maybe tailored specific to the customers 
environment. In contrast, a PTF is specific to a release and is the same for 
all customers using that release.
4. The resolving PTF will always SUP the APAR. An SMP/e search for the APAR is 
sufficient but you must verify the APAR has been SUP'd. An applied APAR is 
considered a very temporary fix that may not completely resolve the problem. 
5. Choosing an APAR number is completely flexible. The only requirement is to 
avoid SMP/e collisions. The same APAR number cannot occur multiple times in an 
SMP/e zone (global, target or dist).
6. The APAR number choice has no real significance except how a product has 
chosen to avoid SMP/e collisions. For instance, you say AH went to PHx, 
In the past, this told me that IBM probably acquired a vendor product. Anything 
beginning with I to Z was reserved for IBM use (e.g. IEFJRASP, OA12345, 
UA12345). I suspect that most vendors use the IBM registry for 3 character 
codes from A to H. Each product must choose a method that best fits the company 
requirements. 

>> But what do I search for CA and EA  APARs?
>
>IMHO there is no consistent rule, although majority conform the habit.

What are you "searching for"? In general, APAR numbering schemes does not have 
anything to do with a search. Either you have a specific APAR number or you are 
searching for an APAR number. In the past, APAR numbering had no meaning except 
for internal use. 

In the past, CA and EA would have been non-IBM APARs. Only the company 
producing these apars can tell you what they mean. For instance, a company 
could choose to use CA apars for multiple products.

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

Re: IBM APAR Names

[Radoslaw Skorupka]

W dniu 03.11.2023 o 17:32, Shaffer, Terri pisze:

Hi,
   So I should know this but apparently I missed the memo along the way, Can 
anyone give me the secret decoder

I know AHx went to PHx

But what do I search for CA and EA  APARs?


IMHO there is no consistent rule, although majority conform the habit. 
However... what's you goal? I guess it is not the rule or secret table 
itself. You know the apar ID and you want to check you SMP/E. In that 
case things can be simpler. First - check APAR description in IBM 
internet portal. You will see PTF which is cure for the problem (apar). 
Then check you SMP/E database against the PTF. In theory you could have 
APAR fix implemented, but this is rare IMHO and the delivery is 
different - fixes are not available in Shopzseries and are not delivered 
as a part of ServerPac or CBPDO. Of course you can quickly start from 
checking Aan when reading about Oan. HTH


--
Radoslaw Skorupka
Lodz, Poland

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

Re: IBM APAR Names

[Keith Gooding]

Should be OAx. I missed the memo too.

> On 3 Nov 2023, at 16:33, Shaffer, Terri 
> <017d5f778222-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Hi,
>  So I should know this but apparently I missed the memo along the way, Can 
> anyone give me the secret decoder
> 
> I know AHx went to PHx
> 
> But what do I search for CA and EA  APARs?
> 
> 
> 
> [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] 
> 
> This email message and any attachments may contain confidential, proprietary 
> or non-public information. The information is intended solely for the 
> designated recipient(s). If an addressing or transmission error has 
> misdirected this email, please notify the sender immediately and destroy this 
> email. Any review, dissemination, use or reliance upon this information by 
> unintended recipients is prohibited. Any opinions expressed in this email are 
> those of the author personally.
> 
> --
> 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

IBM APAR Names

[Shaffer, Terri]

Hi,
  So I should know this but apparently I missed the memo along the way, Can 
anyone give me the secret decoder

I know AHx went to PHx

But what do I search for CA and EA  APARs?



 [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] 

This email message and any attachments may contain confidential, proprietary or 
non-public information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

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

Re: Rocket miniconda frustrations

[Paul Gilmartin]

On Fri, 3 Nov 2023 19:42:15 +0800, David Crayford  wrote:
>
>Yes. But you still need the internet ... 
>
What's the alternative?  Railway Express?  Dialup modem?

-- 
gil

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

Re: Rocket miniconda frustrations

[Jousma, David]

RS,


“2. Quick & dirty: download the package as above and then use pax instead of 
miniconda.”



Thanks for the pointer, that worked perfectly.


Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu>
Date: Thursday, November 2, 2023 at 4:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Rocket miniconda frustrations
BTDT There are two way to circumvent the problem: 1. Use Miniconda with offline 
packages. Yes, you can download the packages manually on you PC then upload it 
to z/OS Unix. 2. Quick & dirty: download the package as above and then use pax


BTDT



There are two way to circumvent the problem:

1. Use Miniconda with offline packages. Yes, you can download the

packages manually on you PC then upload it to z/OS Unix.

2. Quick & dirty: download the package as above and then use pax instead

of miniconda.





My personal opinion: the mess is yet another way to convince user to buy

support.



--

Radoslaw Skorupka

Lodz, Poland









W dniu 02.11.2023 o 18:53, Jousma, David pisze:

> All,

>

> I have a simple need to make cURL available in my environment.   I 
> downloaded, and installed MiniConda from the Rocket open source webpage.   We 
> are behind a proxy, and am having all sorts of problems trying to get that to 
> work.

>

> Does anyone know of a way to download the needed “repository” that miniconda 
> uses, and do a disconnected install?

>

> Dave Jousma

>





--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: Rocket miniconda frustrations

[David Crayford]

> On 3 Nov 2023, at 7:05 pm, Lionel B. Dyck  wrote:
> 
> With the z/OS Open Tools you don't need to use zopen, or any front-end, to 
> install any of their ports.
> 
> For example, here is a direct link to the curl port 
> https://github.com/ZOSOpenTools/curlport
> 

Yes. But you still need the internet and access to Github. Customers that are 
air-gapped don’t have that acces. To me it’s as broad as it’s long. I 
appreciate that you like zopen but to me it’s no match for a real package 
manager like conda which can supports virtual environments. Easier doe not mean 
better. 


> 
> Lionel B. Dyck <><
> Website: https://www.lbdsoftware.com
> Github: https://github.com/lbdyck
> 
> “Worry more about your character than your reputation. Character is what you 
> are, reputation merely what others think you are.”   - - - John Wooden
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Jousma, David
> Sent: Thursday, November 2, 2023 5:30 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Rocket miniconda frustrations
> 
> I find having to have an entire front-end to install something that can just 
> be expanded with a tar or pax command way overkill.
> 
> 
> 
> Dave Jousma
> 
> Vice President | Director, Technology Engineering
> 
> 
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, 
> MI 49546
> 
> 616.653.8429
> 
> From: IBM Mainframe Discussion List  on behalf of 
> David Crayford 
> Sent: Thursday, November 2, 2023 6:21:52 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Rocket miniconda frustrations
> 
>> On 3 Nov 2023, at 1: 59 am, Lionel B. Dyck  wrote:
 You can get another port of curl from https: //urldefense. 
>> com/v3/__https: //zosopentools. github. 
>> io/meta/*/__;Iw!!MwwqYLOC6b6whF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZ
>> o3Woa9SZfCu8-YcuyurtSKg-wqbEMfgyiqFe5Wlf2nWnRsA$
> 
> 
>> On 3 Nov 2023, at 1:59 am, Lionel B. Dyck  wrote:
>> 
>> You can get another port of curl from 
>> https://urldefense.com/v3/__https://zosopentools.github.io/meta/*/__;I
>> w!!MwwqYLOC6b6whF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZo3Woa9SZfCu8-Y
>> cuyurtSKg-wqbEMfgyiqFe5Wlf2nWnRsA$
>> and it is very simple - much easier (imho) than using miniconda.
> 
> If he’s got problems going through a proxy couldn't the same kind of problems 
> occur using zopen and GitHub with Github tokens?
> 
> I don’t find using zopen to be easier to use then conda. It’s certainly 
> nowhere near as powerful, for example, virtual environments. I like zopen but 
> I find having to source .env files a PITA and slow when configured in profile 
> scripts. Using conda is just like using homebrew on my Mac. Hat’s off the 
> z/OS Open Tools devs for getting something working well enough with only 
> shell scripts.
> 
>> 
>> We also discuss things related to the z/OS Open Tools here 
>> https://urldefense.com/v3/__https://discord.com/channels/8803224716083
>> 44597/1118254421202182185__;!!MwwqYLOC6b6whF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZo3Woa9SZfCu8-YcuyurtSKg-wqbEMfgyiqFe5Wlf3e-1v2I$
>>  and you're welcome to join us.
>> 
>> 
>> Lionel B. Dyck <><
>> Website: 
>> https://urldefense.com/v3/__https://www.lbdsoftware.com__;!!MwwqYLOC6b
>> 6whF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZo3Woa9SZfCu8-YcuyurtSKg-wqb
>> EMfgyiqFe5WlfHGqYwrU$
>> Github: 
>> https://urldefense.com/v3/__https://github.com/lbdyck__;!!MwwqYLOC6b6w
>> hF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZo3Woa9SZfCu8-YcuyurtSKg-wqbEM
>> fgyiqFe5Wlfg7_GH4U$
>> 
>> “Worry more about your character than your reputation. Character is what you
>> are, reputation merely what others think you are.”   - - - John Wooden
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of Jousma, David
>> Sent: Thursday, November 2, 2023 12:54 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Rocket miniconda frustrations
>> 
>> All,
>> 
>> I have a simple need to make cURL available in my environment.   I
>> downloaded, and installed MiniConda from the Rocket open source webpage.
>> We are behind a proxy, and am having all sorts of problems trying to 
>> get that to work.
>> 
>> Does anyone know of a way to download the needed “repository” that 
>> miniconda uses, and do a disconnected install?
>> 
>> Dave Jousma
>> 
>> 
>> 
>> This e-mail transmission contains information that is confidential and may
>> be privileged.   It is intended only for the addressee(s) named above. If
>> you receive this e-mail in error, please do not read, copy or 
>> disseminate it in any manner. If you are not the intended recipient, 
>> any disclosure, copying, distribution or use of the contents of this 
>> information is prohibited. Please reply to the message immediately by 
>> informing the sender that the message was misdirected. After replying, 
>> please erase it from your computer system. Your assistance in correcting 
>> this error is appreciated.
>> 
>> ---

Re: Rocket miniconda frustrations

[Lionel B. Dyck]

With the z/OS Open Tools you don't need to use zopen, or any front-end, to 
install any of their ports.

For example, here is a direct link to the curl port 
https://github.com/ZOSOpenTools/curlport


Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

“Worry more about your character than your reputation. Character is what you 
are, reputation merely what others think you are.”   - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Thursday, November 2, 2023 5:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Rocket miniconda frustrations

I find having to have an entire front-end to install something that can just be 
expanded with a tar or pax command way overkill.



Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Thursday, November 2, 2023 6:21:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Rocket miniconda frustrations

> On 3 Nov 2023, at 1: 59 am, Lionel B. Dyck  wrote: 
> > > You can get another port of curl from https: //urldefense. 
> com/v3/__https: //zosopentools. github. 
> io/meta/*/__;Iw!!MwwqYLOC6b6whF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZ
> o3Woa9SZfCu8-YcuyurtSKg-wqbEMfgyiqFe5Wlf2nWnRsA$


> On 3 Nov 2023, at 1:59 am, Lionel B. Dyck  wrote:
>
> You can get another port of curl from 
> https://urldefense.com/v3/__https://zosopentools.github.io/meta/*/__;I
> w!!MwwqYLOC6b6whF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZo3Woa9SZfCu8-Y
> cuyurtSKg-wqbEMfgyiqFe5Wlf2nWnRsA$
> and it is very simple - much easier (imho) than using miniconda.

If he’s got problems going through a proxy couldn't the same kind of problems 
occur using zopen and GitHub with Github tokens?

I don’t find using zopen to be easier to use then conda. It’s certainly nowhere 
near as powerful, for example, virtual environments. I like zopen but I find 
having to source .env files a PITA and slow when configured in profile scripts. 
Using conda is just like using homebrew on my Mac. Hat’s off the z/OS Open 
Tools devs for getting something working well enough with only shell scripts.

>
> We also discuss things related to the z/OS Open Tools here 
> https://urldefense.com/v3/__https://discord.com/channels/8803224716083
> 44597/1118254421202182185__;!!MwwqYLOC6b6whF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZo3Woa9SZfCu8-YcuyurtSKg-wqbEMfgyiqFe5Wlf3e-1v2I$
>  and you're welcome to join us.
>
>
> Lionel B. Dyck <><
> Website: 
> https://urldefense.com/v3/__https://www.lbdsoftware.com__;!!MwwqYLOC6b
> 6whF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZo3Woa9SZfCu8-YcuyurtSKg-wqb
> EMfgyiqFe5WlfHGqYwrU$
> Github: 
> https://urldefense.com/v3/__https://github.com/lbdyck__;!!MwwqYLOC6b6w
> hF7V!k_US3TMoavpn0TTm6PL_t4rNIIj6tb_vQCrZo3Woa9SZfCu8-YcuyurtSKg-wqbEM
> fgyiqFe5Wlfg7_GH4U$
>
> “Worry more about your character than your reputation. Character is what you
> are, reputation merely what others think you are.”   - - - John Wooden
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Jousma, David
> Sent: Thursday, November 2, 2023 12:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Rocket miniconda frustrations
>
> All,
>
> I have a simple need to make cURL available in my environment.   I
> downloaded, and installed MiniConda from the Rocket open source webpage.
> We are behind a proxy, and am having all sorts of problems trying to 
> get that to work.
>
> Does anyone know of a way to download the needed “repository” that 
> miniconda uses, and do a disconnected install?
>
> Dave Jousma
>
>
>
> This e-mail transmission contains information that is confidential and may
> be privileged.   It is intended only for the addressee(s) named above. If
> you receive this e-mail in error, please do not read, copy or 
> disseminate it in any manner. If you are not the intended recipient, 
> any disclosure, copying, distribution or use of the contents of this 
> information is prohibited. Please reply to the message immediately by 
> informing the sender that the message was misdirected. After replying, 
> please erase it from your computer system. Your assistance in correcting this 
> error is appreciated.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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