× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




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 / \
--------------------------------------------------------------------




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.