× 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.



Simon, many good points. The thing I am trying to juggle in my head is how
much yuck adding PASE software to the mix vs. the time saved it will add.
If we go with a pure native IBM i approach (which I prefer) then it *might*
require more work. Then again, it wouldn't be that hard to do HTTP
transactions back and forth of source (i.e. .RPGLE, .CLLE, etc) and binary
(i.e. .SAVF) objects. We would probably want a compression mechanism to
lessen the size of save files. If we don't have to use jar that would be
even better. I know Scott/others have written about various zip utilities
out there if I remember correctly.

I am a big fan of the command line (still do all of my work management,
compiling, machine admin, etc from there) but think the GUI would be a nice
addition for future generations to more easily adopt, and behind the scenes
it would just make use of the cmd line utilities. Which means we would
first develop the command line utilities, and if that worked well we would
move on to a GUI.

We can use the YiPs machine as the public IBM i machine where code
repositories are stored, so that base is covered.

Aaron Bartell
http://mowyourlawn.com
http://mowyourlawn.com/blog/


On Mon, Jul 19, 2010 at 7:51 PM, Simon Coulter <shc@xxxxxxxxxxxxxxxxx>wrote:


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



--
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: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.