The list of OS and HW pairs ...
AIX-powerpc (or "ppc")
AIX-powerpc64 (or "ppc64")
CYGWIN-i386
CYGWIN-x86_64
Darwin-i386
Darwin-x86_64
Darwin-arm64
FreeBSD-i386
FreeBSD-amd64
HPUX-parisc
HPUX-ia64
Linux-i386 (or i486, i586, i686)
Linux-x86_64
Linux-s390
Linux-s390x
Linux-alpha
Linux-arm
Linux-arm64 (Linux-aarch64)
Linux-m68k
Linux-mips
Linux-mips64
Linux-ppc
Linux-ppc64
Linux-ppc64le
Linux-sparc
Linux-sparc64
Minix-i386
NetBSD-i386
NetBSD-amd64
OpenBSD-i386
OpenBSD-amd64
OS390-s390
OS390-s390x
SunOS-i386 (Solaris-i386)
SunOS-x86_64 (Solaris-x86_64 or Solaris-amd64)
SunOS-sparc (Solaris-sparc)
SunOS-sparc64 (Solaris-sparc64)
Windows-x86 (Windows-i386)
Windows-amd64
This is not an exhaustive list, just the pairs I've worked with. And
some are old: I haven't touched Linux-alpha in a lllooonnnggg time. I
also really only use one of the BSDs.
Some of the systems are bi-modal: AIX, Linux-s390x, and OS390 are all
64-bit systems these days, but usually still support 32-bit "user space"
programs.
The names, both left and right, are taken from 'uname' output. I
regularly butt heads with a good friend over names like "powerpc", but
that's what the systems say about themselves.
-- R; <><
On 8/24/23 15:23, Rick Troth wrote:
This topic has gotten fun.
RPM has an advantage over some installer methods that it includes the
architecture (e.g., "x86_64" or "s390x").
Sadly, it does *not* include the operating system (e.g., "Linux" or
"OS/390").
But, yeah, effective and widely used.
Tools like YUM (for RedHat) and ZYPPER (for SUSE) sit on top of RPM.
(YAST is another layer up from ZYPPER and is SUSE's equivalent to
AIX's SMIT, but less painful.)
In my experience, they're well done. (YAST is excellent.) You can
still install packages directly with 'rpm' and either YUM or
ZYPPER/YAST will figure things out, not break nor crash.
We're skipping the tools used in AIX, Slolaris, HP-UX, and others.
It's not rocket surgery.
Dependencies are always a problem when you stray outside the
distributor/vendor collection.
Many times 'rpm' has complained about dependencies/pre-reqs/co-reqs.
When I force the install, it usually works. Not always. Sometimes I
have to manually sym-link a shared lib with an older name.
For many years, I've used a point-n-shoot scheme, lately called
Chicory. (Didn't originally have a name.)
I use this for packages that I build from source. Once a package is
built for a slightly older (e.g.) RedHat Linux, said packages work
just fine on a slightly newer SUSE Linux or Debian Linux (of the same
HW architecture). Not always, but I've learned to isolate
co-reqs/pre-reqs/dependencies. Static linkage helps. In Chicory space,
the OS (e.g., "Linux" or "OS/390") and the HW (e.g., "x86_64" or
"s390x") are always indicated. This developed over more years than I
should admit. I'll enumerate in a separate note.
But I can't promote Chicory here: it's painfully close to TAR and ZIP
for delivery. (Then again, those *do* work, and are stilled used today
by vendors that I've worked for, so mebbe.)
Right now it only handles RSYNC or NFS or removable media. Doesn't
actually do TAR as such. (Acorse, if someone wants to contribute ...)
-- R; <><
On 8/24/23 14:57, Steve Thompson wrote:
With Linux distros there are a few maint systems. The one I am most
familiar with is RPM.
To me YAST (the Linux equivalent of SMP/E) handles upgrades and user
changes (if you know how to do them, I don't because I'm a SU in
Linux -- Stupid User).
Each product/component has its own main entry and then dependencies.
You can override them if you dare. If you are a developer you would
probably know if the override is a good idea.
So you decide to download an ISO. If you have a fat pipe and the
time, you download a NETWork install ISO.
You fill in all the stuff (Upgrade install or "NEW" INSTALL are the
primary options). The system loads and boots and if this is a "NEW"
install, formats and load partitions etc. etc.
Then it gets into all the stuff you said you want installed so it
pulls down all the related/needed repositories and packages and goes
to work.
At a certain point it reboots to the system it has built and then
continues with the applications level stuff.
From time to time you get notified, or you just check it yourself,
and see if there is maint to be added..... Yast handles it.
I thought it was a fairly good replacement for SMP/E for the Linux
side of things. I can see how it could be used to do z/OS and
related.....
Thoughts, and comments?
Oh, and I still only do programming on IBM type Mainframes.
Steve Thompson
On 8/24/2023 2:34 PM, Jon Perryman wrote:
> On Thursday, August 24, 2023 at 11:06:43 AM PDT, Colin Paice
<[email protected]> wrote:
But this fix management would be done by IBM (or product owner).
I'm guessing that IBM is still on a 2 year release cycle and they
still have a custom-built offering so you're not dealing with a lot
of tapes and files. With as many products that IBM deals with,
packaging would be a nightmare. IBM's RHEL and other Linux distros
exists solely to simplify the process and they don't deal with
anywhere near the number of IBM z/OS products. SMP/e is a good
compromise that guarantees everything was performed correctly for
your needs. OEM vendors can easily provide choices because they
don't deal with the magnitude of IBM.
On Thursday, August 24, 2023 at 11:06:43 AM PDT, Colin Paice
<[email protected]> wrote:
ITSchak,
But this fix management would be done by IBM (or product owner). We
should
be able to download the image which has been tested by IBM Consolidated
Service Test in POK.
Only if you need >additional< fixes before the next download - do
you need
to do any SMP/E work. It would still be there if you need it.
Colin
On Thu, 24 Aug 2023 at 17:08, ITschak Mugzach <[email protected]>
wrote:
Kurt,
I think the power of SMP/E is not the initial install, but the fix
management (ptf chain management). Actually many deliveries from
IBM have
SMP/E already populated and technically this is a kind of DSS dump
(or can
be).
ITschak
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous
Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon *
On Thu, Aug 24, 2023 at 6:48 PM Kurt Quackenbush <[email protected]>
wrote:
Yes, thanks for asking, we have thought about an alternative. And an
alternative exists in z/OSMF Software Management and Portable
Software
Instances. In this form you can package, deliver, and install
software
whether it is SMP/E managed or not. If it is SMP/E managed, as
much of
the
software on the z/OS platform is, then the package includes the SMP/E
artifacts like CSIs so you can install PTF fixes. You can of course
choose
to ignore the SMP/E artifacts and just repeat the process to
install an
updated Portable Software Instance in 3 months as you suggest.
Kurt Quackenbush
IBM | z/OS SMP/E and z/OSMF Software Management | [email protected]
Chuck Norris never uses CHECK when he applies PTFs.
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On
Behalf
Of Colin Paice
Sent: Thursday, August 24, 2023 10:37 AM
To: [email protected]
Subject: [EXTERNAL] Is SMP/E needed for installs?
This week, I did my first SMP/E install since my previous one over 40
years
ago! The process hasn't changed much. It took me about half a
day to
download the files and configure the jobs - making the same
changes in
several jobs.
For people new to z/OS "installation" is hard to get into,
understand,
and
get working properly.
Has anyone thought about alternative ways of shipping products? For
example many products are now Web downloads, which you just restore.
I would like to see a DFDSS dump of the CST level of all objects
and a
matching dump of the SMP/E datasets of the product.
I can just restore the product stuff,and not the SMP/E stuff, or I
can
install the SMP/E stuff as well. If you want to install a fix, then
apply
it to the SMP/E libraries.
In 3 months time, repeat the whole process.
I think we have to do something before all those with the
knowledge and
experience retire!
Colin
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
--
-- R; <><
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
