Re: Getting products to run in IASPs

Vern,

Yes, I see new RDB directory entries, one for each IASP, by using the
WRKRDBDIRE command. I also see new directories in the IFS, one for each
IASP.

I find that all the IASPs can be varied on at the same time. Then just use
the SETASPGRP command to swap from one to the other, easily and quickly. If
you don't want users to be able to swap to another IASP, then don't give
them authority to the device description pertaining to that IASP.

Our HTTP server configuration includes, for example:

HTTPStartJobQueue RDAPPDEV/RDWEBDEV
HTTPStartJobDesc RDAPPDEV/RDWEBDEV
HTTPRoutingData HTTPSVR
HTTPSubsystemDesc RDWEBDEV/RDAPPDEV

The HTTP server simply failed to start, until I moved the Job Queue, Job
Description, and Subsystem Description objects back into *SYSBAS.

I then discovered the need to map to objects in the new IASP directory, for
example:

ScriptAliasMatch ^/(.*)\.shtml$ /IASP100/QSYS.LIB/RDWEBSHR.LIB/RDAPHINF.PGM

Notice the reference to the IASP path "/IASP100/" in front?

Like you, one of my planned use cases for IASPs, is to be able to maintain
and support multiple versions of applications on a single server.






On Thu, Jan 11, 2018 at 2:38 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

One other thing that did not get in my way - Db2 - each IASP can have its
own RDB entry - in fact, might have to.

So it's something to consider, I think - as I say, I did not find it an
issue, but it IS there, right?

Regards
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