Re: Software/Code Delivery Mechanism

[Aaron Bartell <aaronbartell@xxxxxxxxx>]

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.