Re: Getting products to run in IASPs

Hi Vern

you can certainly have more than one IASP varied on with the same library
name; that is actually the whole point of an IASP.
- You CAN have multiple version of the same library name so long as they
are in IASPS
- You CAN'T have a library in an IASP if it also exists in *SYSBAS - the
IASP will not vary on.
- You can only have one IASP Group active at any time which ensures only
one copy of the library will ever be resolved

I think visualizing IASPs as namespaces is sometimes helpful:

*SYSBAS -> IASP#1 -> MYLIB
*SYSBAS -> IASP#2 -> MYLIB



On Fri, Jan 12, 2018 at 10:37 AM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

Hi Nathan

Other than the HTTP setup, this sounds like the stuff listed in the IASP
manual - there is a list there of object types that have to be in *SYSBAS,
mostly these configuration things.

I'd worked on this when I was at RJS, to get those products to run in
separate IASPs - one of the primary use cases for me was having a way to
test a new version of a product - just have an option on a menu to use the
SETASPGRP.

Installation scripts need to be changed, seems to me. You have hinted at
some of that.

Yes, you can have the same library names in different IASPs, there just
must not be more than one of those IASPs varied on at the same time.

The HTTP config turned out to be butt-easy, as I recall - when I first
looked into this, it was not at all clear just HOW to do it. But a couple
additions of the IASP name in front of the library seemed usually to take
care of it. Memory does not serve me well, here, however.

Nice going - I think this is an under-utilized capability - I'd heard of
it at COMMON, and the first thought was not HA, it was test environments.

Cheers
Vern


On 1/11/2018 2:45 PM, Nathan Andelin wrote:

It takes some work. I've learned that much by trial and error. The purpose
of this discussion is to share tips about getting products to run in
IASPs.

In a prior discussion I asked about the pros and cons of using IASPs. I
concluded that the pros outweighed the cons. Now I'm testing that
hypothesis. If we're using IASPs in our development environment, I figure
we'll be able to support IASPs at customer sites.

I've configured 3 IASPs, so far. I have a number of use cases in mind. I
saved non-IBM product libraries from *SYSBAS, deleted them, then restored
them to IASPs. That part works. No problem having the same library names
in
multiple IASPs and using SETASPGRP to switch between them.

While attempting to get our products to run, I discovered that our Our
HTTP
server configurations needed to be changed to reference objects in IASP
directories.

I discovered that application-specific job queues, job descriptions,
message queues, subsystem descriptions, and subsystem-class definitions
needed to be moved back into *SYSBAS in order to use IBM i commands like
STRSBS, SBMJOB, and others that utilize such configuration objects.

I envision changing some application-specific commands to optionally
prompt
for IASP name in order to install and configure product environments.

Do you have any other tips or gotchas to share?

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD