On 20/07/2010, at 4:32 AM, Nathan Andelin wrote:
Based on the earlier discussion that Mihael referenced, it appears
that Simon
Coulter, Tom Liotta, and Paul Nicolay had some success with IBM's
System
Manager, and accompanying API. Scott Kement indicated that he never
got the
hang of it. My experience was more like Scott's. System Manager
lets you use
RSTLICPGM to install software, but AFAIK it doesn't synchronize with
a Web based
repository.
Navigator supplies a simplified (and free) interface to these APIs
that allows you to package software. It's not as flexible as using the
APIs directly but it certainly works for many things. I imagine that
it would work quite well to package OS/400 open source stuff.
Even System Manager doesn't support all that the APIs currently allow
and it costs dollars so not much use for OSS which tends to want
"free" too.
I ultimately dropped the idea of using IBM's offering.
Still seems better to me to use what exists on the system than
reinvent things (or walk the PASE path to hell and damnation).
You could use Navigator to package source (and compiled objects) and
use RSTLICPGM to install.
You could save source (and compiled objects) into save files and use
RSTxxx to install.
You could 'package' source as in-line data in a job stream and use FTP
to download it to the host then use SBMDBJOB (or STRDBRDR) to run the
job stream. Here's a trivial example:
//BCHJOB JOB(BLD_OSS)
CRTCMD CMD(lib-name/cmd-name) PGM(cpp-name) SRCFILE(FILE1) +
TEXT('A suitable description')
CRTCLPGM PGM(lib-name/pgm-name) SRCFILE(FILE2) +
TEXT('A suitable description')
//DATA FILE(FILE1) FILETYPE(*SRC)
CMD PROMPT('Work Some Magic')
//
//DATA FILE(FILE2) FILETYPE(*SRC)
PGM
ENDPGM
//
//ENDBCHJOB
In all these cases the only part you need to build is the central
repository. I think FTP is fine to download such files but since the
younger set seems keen on some sort of GUI for this work then perhaps
the following will excite you:
The central repository would expose the list of available applications
as a web service supporting list, get, put (restricted), etc.
You provide an HTTP application that is installed in the receiver's
host system. User fires up a browser and points it to the local URL.
The HTTP application requests the list of available applications from
the central repository and presents it to the browser. User selects an
application (or multiple) from the list. HTTP application gets that
applications file (and any dependencies noted in the repository
database that are not already installed) and runs the appropriate
installation command.
Most of the necessary information would be stored in the central
repository database and anything not known until run-time could be
prompted for in the browser. Sounds simple but there would be a bit of
work to implement the repository and the interface.
This way you use existing facilities. You only need build the wrapper
components. And you don't build dependencies on PASE and therefore
Unix. If you go the route of PASE then at some point you'll be using
Unix (AIX/Linux) utilities to install Unix applications and large
parts of your business (maybe all) will be effectively running on Unix
and someone will then ask why is this not running on a Unix/Linux
system instead of in PASE under OS/400 (or whatever you call it) and
before you know it you won't be working on OS/400 anymore but will be
just another Unix dweeb among a horde of similar drones. Is that
really what you want?
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
