|
So perhaps the solution is a melding of thought. We use the PTF process tomake stuff available, e.g. loading an upgraded version. But then add to
Aaron,
I am guessing that you did do apply previously with other PTFs but
they are two separate steps. I will also agree that the parm in question
about IPL or not is one of the most confusing parms on the system. And that
*IMMDLY is what? Immediately??? BZZZZT! NO, sorry it's IMMEDIATE if
possible DELAYED if not. Clear once you KNOW, not clear when you don't.
The secret is understanding that ALL PTFs CAN be applied at IPL
but only SOME of them MUST be applied then. You (and most of us) want them
ALL to be allowed any time and for the OSS Stuff I would argue that should
be true.
Of course there may be other things needed for example the OpenSSL
updates might require that you end the *SSHD service and restart it. That
certainly happens with an IPL but can happen without one as well.
As to your defaults question yes, those can be changed. I do not
recommend that for this stuff but the admin on the machine could have done
that. Also the behavior could be different if the software did not exist
yet so the PTF applied immediately.
I can see your concern with rollback etc and we do have that to
one level with PTFs. For any PTF Temporarily applied you can Remove it (or
UN-Apply it) and bring back previous behavior. However as you point out
that is machine wide not just for one user.
So perhaps the solution is a melding of thought. We use the PTF
process to make stuff available, e.g. loading an upgraded version. But then
add to that the ability to use some flavor of container or chroot that
either copies the current version in or perhaps each new version is placed
in a new directory used only when developers specify that. You are clearly
more in a position to suggest what works best.
In short I really prefer that delivering servers with features
installed and doing upgrades to existing servers doesn't require the admins
to spend much time banging arround in some shell entering cryptic commands
like find . -name "*.sh" -mtime 1 -exec ls -lad {} \; | awk '{sum = sum
+ $5} END {print sum}‘
- Larry "DrFranken" Bolhuis
www.Frankeni.com
www.iDevCloud.com - Personal Development IBM i timeshare service.
www.iInTheCloud.com - Commercial IBM i Cloud Hosting.
On 7/20/2016 10:01 AM, Aaron Bartell wrote:
When you talk about doing the PTFs to 5733OPS have you found that any ofThis is the IBMi Open Source Roundtable (OpenSource) mailing list
those Required an IPL?
I am still foggy on this area so I may have misstepped. When I was
initially doing 5733OPS I did SNDPTFORD and then opt 8 to apply/install
with *SERVICE specified. When I do that (and I just did it yesterday) it
doesn't actually apply the PTF. I instead need to manually install them
with APYPTF and specify *IMMDLY. Before I discovered this (because it is
different than when I was applying PTFs for other licpgms) I was operating
on DSPPTF's "IPL Action"** column which made it appear as thought an IPL
was required. There was a "Yes" in that column so I assumed an IPL was
required.
** F1 help text for that column: "Indicates whether action will be taken
on
the next unattended normal IPL to apply or remove this PTF. If IPL action
is indicated, enter the option to display PTF details to determine which
action is to be performed."
I now believe it was user ignorance for this specific scenario. The
other
scenarios (i.e updating openssl) were also only resolved with IPLs, which
also might be user ignorance (me).
[30 minutes later after Aaron does more research based on Larry's
feedback]
I now see the "Other options" on GO PTF opt 8 and that opt 2 for "Apply
type" should be specified. I am now wondering if that is defaulted to a
different value on the machines where I didn't need to do a manual APYPTF.
>You say the PTFs are ALL or Nothing. That may be true for installing a
new OPS option since you need the product but after I don't see why you
couldn't add one PTF to fix a specific issue.
In short, I want to be able to change my PATH to include or omit a change
IBM has introduced. Today, a PTF completely replaces the existing
infrastructure, including upgrading a version of a language, and I need to
retain the previous version of the language (rollback, A/B testing, etc).
I can work around this with ibmichroot, but for those new to open source
and upgrading, well, there's a bigger risk of down time, or more expense
of
maintaining entirely different IBM i instances, to achieve multiple
dev/test/prod environments.
>I understand that you are 'not a fan' of the pTF process. However I
would
caution that we don't really want IBM to set us up that for every new
option their is Yet Another Setup Type (YAST :-) ) needed to make that
tool
available.
I hear ya, but we're entering a new age of containers (at least in the
open
space) and I just don't see PTFs working there, unless the containers are
completely separate IBM i instances, and separate IBM i instances are too
expensive on the time/money/hardware front (when compared to the rest of
the world, i.e. Docker).
Thanks for tempering me. I need it to be drawn back from the ledge of
frustration. IBM has given us excellent means for feedback (RFE, Advisory
councils, etc) and I need to be part of the solution (working towards
fixing, submitting feedback) instead of the problem (complaining).
Aaron Bartell
litmis.com - Services for open source on IBM i
On Wed, Jul 20, 2016 at 8:30 AM, DrFranken <midrange@xxxxxxxxxxxx> wrote:
Aaron,
I do PTFs in my sleep, before my sleep, after my sleep so my
point
of reference is different. I have loaded OPS a dozen times or more with
PTFs. But we are often doing this to new partitions and as part of
loading
other LPPs. I have had *ZERO issue with any of them.
When you talk about doing the PTFs to 5733OPS have you found that
any of those Required an IPL? I would not expect that as they are working
with things NOT part of the O/S itself. Perusing the PTFs they all appear
to be updating/adding just a very few objects so it would seem they would
be quick and apply *IMMED.
You say the PTFs are ALL or Nothing. That may be true for
installing a new OPS option since you need the product but after I don't
see why you couldn't add one PTF to fix a specific issue. IBM may
indicate
they are related/dependent of course but there is no requirement that
because they are PTFs they MUST be.
Am I missing something?
- L
- Larry "DrFranken" Bolhuis
www.Frankeni.com
www.iDevCloud.com - Personal Development IBM i timeshare service.
www.iInTheCloud.com - Commercial IBM i Cloud Hosting.
On 7/20/2016 8:48 AM, Aaron Bartell wrote:
So I don't know what else I can offer in terms of expounding on what
To post a message email: OpenSource@xxxxxxxxxxxx
hasn't been smooth.
I think what I'm now realizing, especially given your opening
declaration
of not being an admin, is that we're entering the world of developers
doing
operations/administration. Up to a couple years ago it was simply not
common for a developer to be able to provision your own IBM i at a
reasonable cost. That now exists because of IBM i in the cloud. Now
what
we'll also find is that systems will be administered by these same
people
who aren't focused on (don't care about?) the intricacies of when/how to
apply IBM i updates, they just want it to work like it does on their
phone.
I wanted to speak to my particular situation with 5733OPS
difficulties. I
did a SAVLICPGM/RSTLICPGM to get 5733OPS onto two machines. I was told
this could work but I probably missed a step. Once I installed 5733OPS
from an image catalog everything started working fine. With that said,
I
am not a fan of PTFs because it's all or nothing. I need to be able to
install PTFs into a temporary location on the same machine without
disrupting existing work. I need to be able to do this without an IPL.
My hope is the IBM i Dash project** can be a breeding grounds for
dashboards that take the pain out of IBM i administration. IBM has
given
us A LOT of tooling/metadata via the DB2 Services***, so now it's our
turn
to make them into useful user interfaces for the community.
**https://bitbucket.org/litmis/ibmidash
***http://bit.ly/db2-for-i-services
Aaron Bartell
litmis.com - Services for open source on IBM i
On Tue, Jul 19, 2016 at 6:00 PM, John Yeung <gallium.arsenide@xxxxxxxxx
wrote:
On Mon, Jul 18, 2016 at 10:34 AM, Aaron Bartell <aaronbartell@xxxxxxxxx
wrote:This is the IBMi Open Source Roundtable (OpenSource) mailing list
The bottom line is that the Zend PHP experience on the i has been
smoother
and generally better, by typical midrange standards, than the
experienceWell, keep in mind I am not an administrator. I don't have personal
with Node.js, Python, and 5733-OPS in general.
I am not IBM, but I am wondering if you could expound on what hasn't
been
as smooth so IBM can hear.
experience installing any of the things mentioned above. I was mainly
trying to take Jon's comments and your comments as both true, from
your respective viewpoints. And I've read other people's anecdotes on
these lists of their attempts to get things working. (I've only really
heard 5733-OPS stories, nothing regarding PHP for i.)
Given all that, I simply found myself more sympathetic to Jon's
position. It's not for folks from other platforms to say "hey you
midrangers, our stuff is so easy and works so awesome on our platform;
it's not fair for you to say our stuff is not easy just because it's
not easy on your platform". Well, midrangers aren't on Linux or even
Windows. They are on IBM i. And if it's not easy on IBM i, then it's
not easy for them. Period. How do we (all of us, collectively) improve
the situation?
I would think the bumpy ride for installation and setup of 5733-OPS is
already evident to you. And Kevin Adler has been not just monitoring
but actively participating in the process of getting you and others
set up. So I don't know what else I can offer in terms of expounding
on what hasn't been smooth.
I can *imagine* what a smooth installation would look like. To me, the
iSeriesPython installation is quite smooth. I mean, not as smooth as a
Windows installer, but at least the instructions given were very clear
and easy to follow, with not too many steps.
Conversely, I have always found licensed programs and PTFs and all
that jazz very arcane, unintuitive, and not easy or smooth. But that's
me. What I can say is, that kind of stuff is evidently *familiar* to
midrangers, and familiarity breeds a *sense* of ease. (I will note
that Jon said PHP for i had a *familiar* installation process, not an
easy one.) Since I don't have the required authority to install PTFs
even if I wanted to (and actually, I have wanted to!), there's no way
for me to develop the familiarity and thus ease with the typical IBM i
way of doing things. All I know is that it sounds complicated to me,
and even super-knowledgeable people like Rob can get tripped up by the
myriad PTFs involved. The situation seems to be improving (for
example, with the "grouped" PTFs, I don't remember the official
terminology), but I can't tell firsthand.
Also, I think it would be good to log RFEs so
we can vote on what we'd like to see changed.It would be good. I don't feel I'm the one to log them. At least not
regarding installation issues.
John Y.
--
This is the IBMi Open Source Roundtable (OpenSource) mailing list
To post a message email: OpenSource@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/opensource.
--
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/opensource.
--
To post a message email: OpenSource@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/opensource.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
