MPE On Linux - Hewlett Packard

This is a discussion on MPE On Linux - Hewlett Packard ; On Thu, 26 Jun 2008 17:32:23 -0700, "Peter M. Eggers" wrote: > What I think could work is this: > > Use a stripped down and optimized version of Linux to run MPE as a service. Sounds good to me. ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: MPE On Linux

  1. MPE On Linux

    On Thu, 26 Jun 2008 17:32:23 -0700, "Peter M. Eggers" wrote:

    > What I think could work is this:
    >
    > Use a stripped down and optimized version of Linux to run MPE as a service.


    Sounds good to me. Actually it was exactly what I was thinking, or almost - I was thinking "Why not modify the Linux kernel to boot into MPE (okay, an MPE-like environment)?" But MPE as a service works for me.

    So, who's interested in coding up a MPE environment in Linux? And where do I sign up?


    Jim Phillips




    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


  2. Re: MPE On Linux

    Well, Geert from Ordina Denkart has done it, and it's very good.* it's called MPUX
    *
    MPE-UX.
    *
    (Some how, I think Stan was involved)...
    *
    But Geert is no longer there.... so what has happened to Ordina-Denkart?*

    Can anyone respond?** I seriously don't know the answer.
    *
    -Craig

    --- On Fri, 6/27/08, Jim Phillips wrote:

    From: Jim Phillips
    Subject: MPE On Linux
    To: HP3000-L@RAVEN.UTC.EDU
    Date: Friday, June 27, 2008, 6:15 AM

    On Thu, 26 Jun 2008 17:32:23 -0700, "Peter M. Eggers"
    wrote:

    > What I think could work is this:
    >
    > Use a stripped down and optimized version of Linux to run MPE as a

    service.

    Sounds good to me. Actually it was exactly what I was thinking, or almost - I
    was thinking "Why not modify the Linux kernel to boot into MPE (okay, an
    MPE-like environment)?" But MPE as a service works for me.

    So, who's interested in coding up a MPE environment in Linux? And where do
    I sign up?


    Jim Phillips




    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


  3. Re: MPE On Linux - setting the record straight

    Actually, the first substantial version of a set of MPE API's on UNIX and,
    as far as I know Linux, was from SunGard Bi-tech. Their product Transport
    has been in continuous use since 1989. It runs on several flavors of UNIX,
    Linux and Windows. My company Transformix ported the original SunGard
    Bi-tech Transport product to Linux and Windows under contract for SunGard
    Bi-tech. The Linux version was used to replace 54 HP 3000's at a Fortune
    500 company. The replacement features SUSE Linux and Oracle on 8 very
    powerful Intel servers using VMWare.

    MPuX was developed by Jacques Van Damme and Luc Maas from Ordina Denkart. It
    was created from a combination of mostly some internal routines that Denkart
    already owned along with some ideas from SunGard Bi-tech Transport. The
    right to do this was acquired with an OEM license purchased from Summit
    Information Systems. Transport was used, at least in part, as a reference
    create MPuX. The product was initially developed for use by Summit
    Information systems. This was in 1997-2000. That version of MPuX only ran
    on HP-UX initially.

    I was intimately involved in the process of selling the idea of MPuX to
    Summit, making all of the initial contractual arrangements, etc. As far as I
    know, during the entire time I was involved ,Geert was not involved with
    MPuX until later. He became involved with MPuX after it already worked on
    HP-UX with Eloquence (and, although I don't know this for sure, maybe even
    after Jacques left Ordina). If it works on Linux today, he may have been
    involved in that.

    I am not aware of Stan's involvement in the project. Gavin on the other
    hand, played a peripheral role in advising Marxmeier Software about
    Eloquence features needed to clone TurboIMAGE and performing performance
    tests on Eloquence. At the time of my involvement, no one from Allegro
    contributed to MPuX except to advise Summit that it was a worthwhile product
    to pursue, Gavin did that.

    Charles Finley
    619-795-0720
    > -----Original Message-----
    > From: HP-3000 Systems Discussion [mailto:HP3000-L@RAVEN.UTC.EDU] On Behalf
    > Of Craig Lalley
    > Sent: Friday, June 27, 2008 4:49 AM
    > To: HP3000-L@RAVEN.UTC.EDU
    > Subject: Re: MPE On Linux
    >
    > Well, Geert from Ordina Denkart has done it, and it's very good.* it's
    > called MPUX
    >
    > MPE-UX.
    >
    > (Some how, I think Stan was involved)...
    >
    > But Geert is no longer there.... so what has happened to Ordina-Denkart?
    >
    > Can anyone respond?** I seriously don't know the answer.
    >
    > -Craig
    >
    > --- On Fri, 6/27/08, Jim Phillips wrote:
    >
    > From: Jim Phillips
    > Subject: MPE On Linux
    > To: HP3000-L@RAVEN.UTC.EDU
    > Date: Friday, June 27, 2008, 6:15 AM
    >
    > On Thu, 26 Jun 2008 17:32:23 -0700, "Peter M. Eggers"
    > wrote:
    >
    > > What I think could work is this:
    > >
    > > Use a stripped down and optimized version of Linux to run MPE as a

    > service.
    >
    > Sounds good to me. Actually it was exactly what I was thinking, or almost
    > - I
    > was thinking "Why not modify the Linux kernel to boot into MPE (okay, an
    > MPE-like environment)?" But MPE as a service works for me.
    >
    > So, who's interested in coding up a MPE environment in Linux? And where
    > do
    > I sign up?
    >
    >
    > Jim Phillips
    >
    >
    >
    >
    > * To join/leave the list, search archives, change list settings, *
    > * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
    >
    > * To join/leave the list, search archives, change list settings, *
    > * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
    >
    > __________ NOD32 3223 (20080627) Information __________
    >
    > This message was checked by NOD32 antivirus system.
    > http://www.eset.com


    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


  4. Re: MPE On Linux - setting the record straight

    --- On Fri, 6/27/08, Charles Finley wrote:
    I am not aware of Stan's involvement in the project. Gavin on the other
    hand, played a peripheral role in advising Marxmeier Software about
    Eloquence features needed to clone TurboIMAGE and performing performance
    tests on Eloquence. At the time of my involvement, no one from Allegro
    contributed to MPuX except to advise Summit that it was a worthwhile product
    to pursue, Gavin did that.

    Charles did* a great job of explaining history, and I don't doubt what hesaid is accurate.

    I did however, in my course of investigation, come across an e-mail addressfor stan@ordina-denkart.com....

    Care to explain Stan... or is he not part of the 3000-L anymore?* Could someone at Allegro fill him in on the quandary?

    -Craig




    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


  5. Re: MPE On Linux - setting the record straight

    Re:

    Craig writes:
    > --- On Fri, 6/27/08, Charles Finley wrote:
    > > I am not aware of Stan's involvement in the project. Gavin on the other


    Charles is right, IIRC. I recall having a few discussions with Jacques,
    who I worked with when we developed the SPLash! compiler, but I don't remember
    anything substantial enough to claim any influence on MPUX.

    I am curious...Craig writes:
    > I did however, in my course of investigation, come across
    > an e-mail address for stan@ordina-denkart.com....


    I have no idea what that might have been about.

    > Care to explain Stan... or is he not part of the 3000-L anymore?


    I don't check it as often as I used to, but I still do eventually

    Stan
    --
    Stan Sieler
    sieler@allegro.com
    www.allegro.com/sieler/wanted/index.html

    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


  6. Re: MPE On Linux

    On Fri, Jun 27, 2008 at 4:49 AM, Craig Lalley wrote:
    > Well, Geert from Ordina Denkart has done it, and it's very good. it's called MPUX
    >
    > MPE-UX.


    It is good to see that there is already a proof-of-concept that is
    actually working. When I originally presented the idea on the OpenMPE
    list, seemed like there were doubts that it would work, doubts that it
    was economically feasible, and doubts that MPE could be brought back
    from fading into the sunset.

    > (Some how, I think Stan was involved)...
    >
    > But Geert is no longer there.... so what has happened to Ordina-Denkart?
    >
    > Can anyone respond? I seriously don't know the answer.
    >
    > -Craig
    >
    > --- On Fri, 6/27/08, Jim Phillips wrote:
    >
    > From: Jim Phillips
    > Subject: MPE On Linux
    > To: HP3000-L@RAVEN.UTC.EDU
    > Date: Friday, June 27, 2008, 6:15 AM
    >
    > On Thu, 26 Jun 2008 17:32:23 -0700, "Peter M. Eggers"
    > wrote:
    >
    >> What I think could work is this:
    >>
    >> Use a stripped down and optimized version of Linux to run MPE as a

    > service.
    >
    > Sounds good to me. Actually it was exactly what I was thinking, or almost - I
    > was thinking "Why not modify the Linux kernel to boot into MPE (okay, an
    > MPE-like environment)?" But MPE as a service works for me.
    >
    > So, who's interested in coding up a MPE environment in Linux? And where do
    > I sign up?


    I tried to get the concept going many months ago on the OpenMPE list.
    Besides the naysayers, there was a couple of people that could have
    been very helpful to success of the project, but couldn't afford the
    time. A few with considerable encouragement, but couldn't help due to
    lack of technical ability. Yet, when asked to provide HP3000 access
    or make lists of essential software or lists SL routines or any kind
    of non-technical assistance, encouragement suddenly dried up as did my
    enthusiasm.

    I have some time that I could commit on an ongoing basis, with periods
    that I could spend considerable amount of time on the project. But, I
    don't have access to an HP3000, and I can't/won't do it alone.

    I would like to see a community supported and developed project,
    ending up with an official branded product that is easily verified.
    Third party commercial support could provide MPE on full blown server
    of workstation Linux. Third parties could have recommended 3rd party
    customized versions that are not officially supported, or if there is
    actually a high level of confidence in their ability and product, it
    could receive a special branding. In any case, commercial entities
    would be encouraged to provide highend utilities like Robelle's
    Suprtool , or services like high level security: penetration testing,
    security consulting, system hardning, etc. (the basic system should
    still provide really good and really simple security far beyond
    something like Windows in the MPE tradition). Not trying to put any
    commercial entities out of business, and would encourage their
    participation in both the community developed basic system and in
    creating niche or highend utilities, and of course commercial
    applications and systems to run on it. Should be a win-win for
    everyone involved.

    To start, I would create a command interpreter and login routine that
    is the shell for a Linux user "MPE" that would mimic the MPE's user
    login prompt, and an 80% solution for implementing the most important
    MPE commands and command options. Creating, listing, and purging
    empty files would be a good first step and a momentum builder.

    To start for ease of implementation, the Linux user MPE's home
    directory would be akin to a virtual machine map or database, if you
    prefer. I would like to see a 4th level of directory structure added
    to MPE: file.group.account.domain, i.e. ITEMS.DATA.ACME.PROD or
    SL.PUB.SYS.TEST -- same rules apply for assumed name parts. On the
    hidden Linux side [of the iron curtain], these files would be
    /home/MPE/PROD/ACME/DATA/ITEMS and /home/MPE/TEST/SYS/PUB/SL
    respectively. The file labels for could be put into Linux extended
    attributes, but level support has been dependent upon file system
    used. I think the better idea is just (using above example)
    /home/MPE/PROD/ACME/ITEMS.labels -- separate simple file: easy to
    code for on the Linux side, and presented normally on the MPE side
    with great flexibility going forward. Temporary files would be
    implemented as /home/MPE/temp/PROD/ACME/DATA/ITEMS or as
    /home/MPE/PROD/temp/ACME/ITEMS (pros and cons both ways - could be as
    system configuration). System tables, like JMAT, /home/MPE/.jmat, or
    in the domain as a virtual machine, /home/MPE/PROD/.jmat . Tables
    that are per user like the JITs: /home/MPE/PROD/CHRIS/.jit (where
    CHRIS is the MPE user). Down the road, if performance is an issue,
    these MPE system tables could be copied to ramdisk, memory mapped, or?
    (Linux never seems to be without options). On the MPE side, all looks
    normal and all of the Linux/Posix is hidden and only accessed
    indirectly through MPE's PM cap.

    In theory, when logged onto Linux as MPE, all should look and act like
    MPE. The window to the underlying Linux should be through SL.PUB.SYS
    .. Only system programmers would be modifying or adding routines to
    there, and provide normal looking procedures to applications and
    utilities. How to do this simply and elegantly, and still provide for
    ironclad security in the finished product, I am still pondering.

    This describes an alpha version, that if could be functional in less
    than a month could provide enormous momentum to the project. Once you
    are sitting there at an MPE prompt, creating/listing/purging files,
    you are going to want to put something in them to display. The
    framework to do so will be there, and most programmers will be hard
    pressed to resist the urge add a little magic to SL.PUB.SYS to make it
    happen. Using the Linux development model, maybe a couple of other
    programmers with less time or motivation will jump in with
    suggestions, bug fixes, or enhancements. Some official gatekeeper at
    some point will anoint some combined effort version golden, and give
    it an official stamp of approval (maybe gpg signed, and/or simply
    added to an official repository?). Then someone is going to want to
    edit the data in the files, and so hopefully the project begins to
    takeoff!

    As I stated before, the official version should me supported by a
    stripped down version of Linux that just provides the hardware support
    for MPE to grow into providing the ultimate RAD (Rapid Application
    Development) platform for business IT solutions, that is also quick
    and simple to operate. The best of the Linux options will be vetted
    by the community, and provided in a user friendly interface and
    platform, MPE.

    Running on a full blown Linux distribution should not be much of a
    problem, and provides yet another commercial opportunity.

    Pete

    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


  7. Re: MPE On Linux

    I thought that the great thing of the later versions of MPE was that it was
    POSIX compliant. If that is the case, couldn't you just load the OS modules
    on to Linix? Granted the hardware drivers would be different.

    -----Original Message-----
    From: HP-3000 Systems Discussion [mailto:HP3000-L@RAVEN.UTC.EDU]On
    Behalf Of Peter M. Eggers
    Sent: Saturday, June 28, 2008 3:03 PM
    To: HP3000-L@RAVEN.UTC.EDU
    Subject: Re: MPE On Linux


    On Fri, Jun 27, 2008 at 4:49 AM, Craig Lalley wrote:
    > Well, Geert from Ordina Denkart has done it, and it's very good. it's

    called MPUX
    >
    > MPE-UX.


    It is good to see that there is already a proof-of-concept that is
    actually working. When I originally presented the idea on the OpenMPE
    list, seemed like there were doubts that it would work, doubts that it
    was economically feasible, and doubts that MPE could be brought back
    from fading into the sunset.

    > (Some how, I think Stan was involved)...
    >
    > But Geert is no longer there.... so what has happened to Ordina-Denkart?
    >
    > Can anyone respond? I seriously don't know the answer.
    >
    > -Craig
    >
    > --- On Fri, 6/27/08, Jim Phillips wrote:
    >
    > From: Jim Phillips
    > Subject: MPE On Linux
    > To: HP3000-L@RAVEN.UTC.EDU
    > Date: Friday, June 27, 2008, 6:15 AM
    >
    > On Thu, 26 Jun 2008 17:32:23 -0700, "Peter M. Eggers"
    > wrote:
    >
    >> What I think could work is this:
    >>
    >> Use a stripped down and optimized version of Linux to run MPE as a

    > service.
    >
    > Sounds good to me. Actually it was exactly what I was thinking, or

    almost - I
    > was thinking "Why not modify the Linux kernel to boot into MPE (okay, an
    > MPE-like environment)?" But MPE as a service works for me.
    >
    > So, who's interested in coding up a MPE environment in Linux? And where

    do
    > I sign up?


    I tried to get the concept going many months ago on the OpenMPE list.
    Besides the naysayers, there was a couple of people that could have
    been very helpful to success of the project, but couldn't afford the
    time. A few with considerable encouragement, but couldn't help due to
    lack of technical ability. Yet, when asked to provide HP3000 access
    or make lists of essential software or lists SL routines or any kind
    of non-technical assistance, encouragement suddenly dried up as did my
    enthusiasm.

    I have some time that I could commit on an ongoing basis, with periods
    that I could spend considerable amount of time on the project. But, I
    don't have access to an HP3000, and I can't/won't do it alone.

    I would like to see a community supported and developed project,
    ending up with an official branded product that is easily verified.
    Third party commercial support could provide MPE on full blown server
    of workstation Linux. Third parties could have recommended 3rd party
    customized versions that are not officially supported, or if there is
    actually a high level of confidence in their ability and product, it
    could receive a special branding. In any case, commercial entities
    would be encouraged to provide highend utilities like Robelle's
    Suprtool , or services like high level security: penetration testing,
    security consulting, system hardning, etc. (the basic system should
    still provide really good and really simple security far beyond
    something like Windows in the MPE tradition). Not trying to put any
    commercial entities out of business, and would encourage their
    participation in both the community developed basic system and in
    creating niche or highend utilities, and of course commercial
    applications and systems to run on it. Should be a win-win for
    everyone involved.

    To start, I would create a command interpreter and login routine that
    is the shell for a Linux user "MPE" that would mimic the MPE's user
    login prompt, and an 80% solution for implementing the most important
    MPE commands and command options. Creating, listing, and purging
    empty files would be a good first step and a momentum builder.

    To start for ease of implementation, the Linux user MPE's home
    directory would be akin to a virtual machine map or database, if you
    prefer. I would like to see a 4th level of directory structure added
    to MPE: file.group.account.domain, i.e. ITEMS.DATA.ACME.PROD or
    SL.PUB.SYS.TEST -- same rules apply for assumed name parts. On the
    hidden Linux side [of the iron curtain], these files would be
    /home/MPE/PROD/ACME/DATA/ITEMS and /home/MPE/TEST/SYS/PUB/SL
    respectively. The file labels for could be put into Linux extended
    attributes, but level support has been dependent upon file system
    used. I think the better idea is just (using above example)
    /home/MPE/PROD/ACME/ITEMS.labels -- separate simple file: easy to
    code for on the Linux side, and presented normally on the MPE side
    with great flexibility going forward. Temporary files would be
    implemented as /home/MPE/temp/PROD/ACME/DATA/ITEMS or as
    /home/MPE/PROD/temp/ACME/ITEMS (pros and cons both ways - could be as
    system configuration). System tables, like JMAT, /home/MPE/.jmat, or
    in the domain as a virtual machine, /home/MPE/PROD/.jmat . Tables
    that are per user like the JITs: /home/MPE/PROD/CHRIS/.jit (where
    CHRIS is the MPE user). Down the road, if performance is an issue,
    these MPE system tables could be copied to ramdisk, memory mapped, or?
    (Linux never seems to be without options). On the MPE side, all looks
    normal and all of the Linux/Posix is hidden and only accessed
    indirectly through MPE's PM cap.

    In theory, when logged onto Linux as MPE, all should look and act like
    MPE. The window to the underlying Linux should be through SL.PUB.SYS
    .. Only system programmers would be modifying or adding routines to
    there, and provide normal looking procedures to applications and
    utilities. How to do this simply and elegantly, and still provide for
    ironclad security in the finished product, I am still pondering.

    This describes an alpha version, that if could be functional in less
    than a month could provide enormous momentum to the project. Once you
    are sitting there at an MPE prompt, creating/listing/purging files,
    you are going to want to put something in them to display. The
    framework to do so will be there, and most programmers will be hard
    pressed to resist the urge add a little magic to SL.PUB.SYS to make it
    happen. Using the Linux development model, maybe a couple of other
    programmers with less time or motivation will jump in with
    suggestions, bug fixes, or enhancements. Some official gatekeeper at
    some point will anoint some combined effort version golden, and give
    it an official stamp of approval (maybe gpg signed, and/or simply
    added to an official repository?). Then someone is going to want to
    edit the data in the files, and so hopefully the project begins to
    takeoff!

    As I stated before, the official version should me supported by a
    stripped down version of Linux that just provides the hardware support
    for MPE to grow into providing the ultimate RAD (Rapid Application
    Development) platform for business IT solutions, that is also quick
    and simple to operate. The best of the Linux options will be vetted
    by the community, and provided in a user friendly interface and
    platform, MPE.

    Running on a full blown Linux distribution should not be much of a
    problem, and provides yet another commercial opportunity.

    Pete

    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


  8. Re: MPE On Linux

    On Sat, Jun 28, 2008 at 3:53 PM, Ron Horner
    wrote:
    > I thought that the great thing of the later versions of MPE was that it was
    > POSIX compliant. If that is the case, couldn't you just load the OS modules
    > on to Linix? Granted the hardware drivers would be different.


    There are a number of good things about POSIX compliancy, especially
    on Unix. When from MPE, it adds complexity and more ways to screw
    things up. The underlying Linux is fully POSIX compliant and many,
    many other good things. You could also add Windows compliancy, MVS
    compliancy, and so on. But, integrating different designs necessarily
    causes complications and trade-offs.

    My point is to put a friendly MPE face on whatever is useful in Linux
    and not to expose it directly. Just add what you need to the API, and
    write a MPE utility to access it, or integrate it into an existing MPE
    utility. The KISS principle. MPE should be the quickest and easiest
    way to solve business information problems. The more time spent on
    technical details of the OS, the less focus and time spent on solving
    the problem at hand.

    My idea is that MPE should be focussed on solving business information
    problems only. The hardware and operating system details should be
    handed off to Linux, running below and out of sight.

    Pete

    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


  9. Re: MPE On Linux

    what Linux could REALLY benefit from is MPE's batch and spool
    environment, there's virtually nothing other than cron and regular
    disk files, it's a real pain in the butt and I'm really surprised no
    one has done something yet, well, maybe someone did and I didn't notice it yet.

    At 12:17 PM 6/29/2008, Peter M. Eggers wrote:
    >On Sat, Jun 28, 2008 at 3:53 PM, Ron Horner
    > wrote:
    > > I thought that the great thing of the later versions of MPE was that it was
    > > POSIX compliant. If that is the case, couldn't you just load the

    > OS modules
    > > on to Linix? Granted the hardware drivers would be different.

    >
    >There are a number of good things about POSIX compliancy, especially
    >on Unix. When from MPE, it adds complexity and more ways to screw
    >things up. The underlying Linux is fully POSIX compliant and many,
    >many other good things. You could also add Windows compliancy, MVS
    >compliancy, and so on. But, integrating different designs necessarily
    >causes complications and trade-offs.
    >
    >My point is to put a friendly MPE face on whatever is useful in Linux
    >and not to expose it directly. Just add what you need to the API, and
    >write a MPE utility to access it, or integrate it into an existing MPE
    >utility. The KISS principle. MPE should be the quickest and easiest
    >way to solve business information problems. The more time spent on
    >technical details of the OS, the less focus and time spent on solving
    >the problem at hand.
    >
    >My idea is that MPE should be focussed on solving business information
    >problems only. The hardware and operating system details should be
    >handed off to Linux, running below and out of sight.
    >
    >Pete
    >
    >* To join/leave the list, search archives, change list settings, *
    >* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *



    Regards,

    Shawn Gordon
    President
    theKompany.com
    www.thekompany.com
    www.mindawn.com
    949-713-3276

    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


  10. Re: MPE On Linux

    On Sun, Jun 29, 2008 at 12:44 PM, Shawn Gordon wrote:
    > what Linux could REALLY benefit from is MPE's batch and spool environment,
    > there's virtually nothing other than cron and regular disk files, it's a
    > real pain in the butt and I'm really surprised no one has done something
    > yet, well, maybe someone did and I didn't notice it yet.


    CUPS has a good spool environment, but the free clients to access it
    suck with the possible exception of "kprint". I think there is a good
    possibility that everything is there and a simple MPE interface to it.

    Batch jobs are a foreign concept to Unix/Linux. I'm not sure without
    doing some research whether all the pieces are there. Probably
    something that would need to be implemented mainly in MPE space and
    interfacing only to Linux processes.

    Pete

    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


  11. Re: MPE On Linux - PLUG

    Our company distributes and implements SunGard Bi-tech Transport
    http://www.xformix.com/xform/xformmf.htm which implements MPE CI (JCL,
    Command Files and UDC's) along with an MPE-like Batchjob scheduler and
    spooler. It has done so since 1989. Perhaps the reason that only users of
    Transport have heard of it is that those products are not sold separately.


    Charles Finley
    619-795-0720

    > -----Original Message-----
    > From: HP-3000 Systems Discussion [mailto:HP3000-L@RAVEN.UTC.EDU] On Behalf
    > Of Shawn Gordon
    > Sent: Sunday, June 29, 2008 12:44 PM
    > To: HP3000-L@RAVEN.UTC.EDU
    > Subject: Re: MPE On Linux
    >
    > what Linux could REALLY benefit from is MPE's batch and spool
    > environment, there's virtually nothing other than cron and regular
    > disk files, it's a real pain in the butt and I'm really surprised no
    > one has done something yet, well, maybe someone did and I didn't notice it
    > yet.
    >
    > At 12:17 PM 6/29/2008, Peter M. Eggers wrote:
    > >On Sat, Jun 28, 2008 at 3:53 PM, Ron Horner
    > > wrote:
    > > > I thought that the great thing of the later versions of MPE was that

    > it was
    > > > POSIX compliant. If that is the case, couldn't you just load the

    > > OS modules
    > > > on to Linix? Granted the hardware drivers would be different.

    > >
    > >There are a number of good things about POSIX compliancy, especially
    > >on Unix. When from MPE, it adds complexity and more ways to screw
    > >things up. The underlying Linux is fully POSIX compliant and many,
    > >many other good things. You could also add Windows compliancy, MVS
    > >compliancy, and so on. But, integrating different designs necessarily
    > >causes complications and trade-offs.
    > >
    > >My point is to put a friendly MPE face on whatever is useful in Linux
    > >and not to expose it directly. Just add what you need to the API, and
    > >write a MPE utility to access it, or integrate it into an existing MPE
    > >utility. The KISS principle. MPE should be the quickest and easiest
    > >way to solve business information problems. The more time spent on
    > >technical details of the OS, the less focus and time spent on solving
    > >the problem at hand.
    > >
    > >My idea is that MPE should be focussed on solving business information
    > >problems only. The hardware and operating system details should be
    > >handed off to Linux, running below and out of sight.
    > >
    > >Pete
    > >
    > >* To join/leave the list, search archives, change list settings, *
    > >* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

    >
    >
    > Regards,
    >
    > Shawn Gordon
    > President
    > theKompany.com
    > www.thekompany.com
    > www.mindawn.com
    > 949-713-3276
    >
    > * To join/leave the list, search archives, change list settings, *
    > * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
    >
    > __________ NOD32 3225 (20080629) Information __________
    >
    > This message was checked by NOD32 antivirus system.
    > http://www.eset.com


    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


  12. Re: MPE On Linux

    Shawn of the 'K' clan writes:

    >what Linux could REALLY benefit from is MPE's batch and spool
    >environment, there's virtually nothing other than cron and
    >regular disk files, it's a real pain in the butt and I'm
    >really surprised no one has done something yet, well, maybe
    >someone did and I didn't notice it yet.


    (sound of clearing throat), ummm well we did, sort of :-)

    At QSS we have an expectation that we can monitor and track all jobs that
    our customers run when using our QSS/OASIS software. This has been particularly
    easy with MPE since those features are built-in.

    We have ported our systems to HP-UX and Linux (RH and SuSE) and needed the
    same functionality on those platforms.

    This is what I can report:

    1. We contracted with an organization to create the basics of a job scheduling
    system that would run on hp-ux/linux that would support basic job scheduling
    as we use it on mpe:

    -- job queues, stdlists, scheduling, job management, programmatic interface for
    launching jobs

    -- ability to have input parms in the script (think jcl) as we did on mpe

    2. Took that system and have been refining it (and fixing issues that arise) and using
    it with our first deployed hp-ux/linux systems.

    3. Continue to evaluate the opportunities for productizing this resultant job management
    system, but currently cannot afford the distraction :-)

    4. We have always had our own print environment so we are not disadvantatedby the
    lack of a built-in spooler for our applications. However, we do use CUPSon our
    linux systems and find it to work quite nicely.

    For those that are interested, I have followed this with some screen shots from
    a running RH system using our applications. You might find it most interesting :-)
    (My comments preceeded by '***'...

    duane


    *** A simple script 'sj' does a 'showjob'...

    ----------------------------------------------------------
    QSS Job System 0.0.0 - Client Wed Jul 2 10:55:14 2008
    (c) 2003 QSS, RAC Consulting. All Rights Reserved
    ----------------------------------------------------------
    connecting to Job Server on 127.0.0.1:20001
    connected...
    ============================== 0 running jobs ==============================
    ============================== 2 waiting jobs ==============================
    id name queue user appuser pri state host
    intro-time/title start-at-time

    2887 ST024805.tmp default qssopr qssopr 5 waitlocalhost
    Tue Jul 1 22:03:14 2008 Wed Jul 2 21:59:00 2008
    venkld

    2888 ST025085.tmp default qssopr qssopr 5 waitlocalhost
    Tue Jul 1 23:02:06 2008 Wed Jul 2 22:59:00 2008
    actkld

    *** Waiting jobs in the queues directory ... .jc is the header and .js is the script/jcl that
    will get executed

    [qssmgr@qssapp ~]$ ll /var/opt/qss/jobsched/queues
    -rw-r--r-- 1 root qss 168 Jul 1 22:03 2887.jc
    -rw-r--r-- 1 root qss 4477 Jul 1 22:03 2887.js
    -rw-r--r-- 1 root qss 168 Jul 1 23:02 2888.jc
    -rw-r--r-- 1 root qss 17111 Jul 1 23:02 2888.js


    *** Generated stdlist(s) for job 2668. the .x flavor contains all the loginscript stuff
    that most people don't want to read...

    [qssmgr@qssapp ~]$ ll /var/opt/qss/jobsched/stdlists/stdlist.2668*
    -r--r--r-- 1 qssopr qss 15378 Jun 24 22:02 /var/opt/qss/jobsched/stdlists/stdlist.2668
    -rw-r--r-- 1 qssopr qss 38008 Jun 24 22:02 /var/opt/qss/jobsched/stdlists/stdlist.2668.x

    ** A snippet of 'prjob' showing the stdlist for job 2668...
    ** I have removed some things to keep it smaller and remove
    ** stuff not that important. However, I have left things in
    ** which those that 'peek' will find most interesting and wonder
    ** what it is all 'about' :-)

    [qssmgr@qssapp jcl]$ prjob 2668
    --------------------- START OF JOB -----------------------
    QSS Job System 2.0.0 Tue Jun 24 21:59:06 2008
    (c) 2006 QSS, RAC Consulting. All Rights Reserved

    jobfile=queues/2668.js
    jobid=2668
    user=qssopr
    appuser=MGR
    title=venkld
    stdlist=stdlists/stdlist.2668
    shell=/bin/sh options=-aev
    cwd=/home/qssopr
    ----------------------------------------------------------
    #!/bin/sh
    export QENV_JOBNO=2668
    # JS L.00.03 built 06/20/08 13.32
    # Copyright (c) 2007-2008 Quintessential School Systems
    # Job launched by:
    # PID = 010019
    # Application user = MGR
    export QSET_DISTNO=001
    export QSET_PRINTX=10
    export QSET_SITENO=0000
    export QSET_YEAR=2009
    export QSET_USERJCW1=0000
    export QSET_USERJCW2=0000
    export QSET_USERJCW3=0000
    export QSET_USERJCW4=0000
    export QSET_USERJCW5=0000
    export QSET_USERJCW6=0000
    export QSET_USERJCW7=0000
    export QSET_USERJCW8=0000
    export QSET_USERJCW9=0000
    export QSET_USERJCWA=0000
    envcln
    ENVCLN L.00.00 built 02/22/08 11.38 Cleanup (save QSET_) Environment Vars..

    # Desc: VENKLD - EXTRACT VENDOR ACTIVITY AND LOAD KSAM FILE

    # Edit History
    # ------------
    # 09/13/93 WH Initial setup
    # 12/20/95 WH Use Native mode ksam file if possible
    # 08/04/97 SHA Version H start here
    # 02/20/98 WH Adjust for Version H
    # 01/17/08 SH L.00.00 Upgrade to version 'L'
    # 06/19/08 DAP Setup to support multiple districts...
    # 06/23/08 DAP Change record size of fmve0300 file to be 303 from 287...


    rm -f $QSS_DATA/data/FMVE0300

    .. setjcw OPTION 1

    export QENV_DISTNO=001

    export FMVE0300=$QSS_DATA/data/FMVE0300
    export TMVE0300=TMVE0300

    $QSS_ROOT/$QSS_BINSCH/ve0300
    VE0300 L.00.04 built 06/23/08 17.04 Vendor History Report

    Extract file will be saved on disc...
    Report title?
    Load vendor detail; dist=001
    Totals only? (Y/N)
    Y
    Activity dated from (MMDDYY)?
    070107
    Activity dated through (MMDDYY)?
    063009
    Include forward balance on report? (Y/N)
    N
    Extract by: 1 = Date paid, 2 = Date entered?
    2
    Include unpaid payments? Y/N (Only applys if extracting by date entered)
    Y
    Primary sort (1=Vendor, 2=Category, 3=Type)?
    1
    Order vendors by (1=Number, 2=Name)?
    1
    Vendor # from?

    Vendor # to?

    Vendor name from?

    Vendor name to?

    Category from?

    Category to?

    Type from?

    Type to?

    Category +0001?

    Category +0002?

    Category +0003?

    Category +0004?

    Category +0005?

    Category +0006?

    Category +0007?

    Category +0008?

    Category +0009?

    Category +0010?

    Type +0001?

    Type +0002?

    Type +0003?

    Type +0004?

    Type +0005?

    Type +0006?

    Type +0007?

    Type +0008?

    Type +0009?

    Type +0010?

    Select accounts?
    N
    ACMACT L.00.00 built 02/22/08 11.14 Acctclass wildcard entry/check
    (Enter '\\' to Quit)
    Acctclass mask 1
    \\

    FRMACT L.00.01 built 05/29/08 14.04 Acctclass field range entry/check
    Enter Field Ranges (Field ## From Range To Range)
    (Enter '\\' to Quit)
    Enter field range:
    \\
    Exiting FRMREAD.


    EXTRACTING DATA FOR FY2008

    EXTRACTING credit_memo (CM)
    RECORDS EXTRACTED: 2 RECORDS OUTPUT: 2
    EXTRACTING est_payables (EP)
    RECORDS EXTRACTED: 2 RECORDS OUTPUT: 2
    EXTRACTING ep_payment (CL)
    RECORDS EXTRACTED: 0 RECORDS OUTPUT: 0
    EXTRACTING purchase_order (PO)
    RECORDS EXTRACTED: 19 RECORDS OUTPUT: 19
    EXTRACTING PAY-VOUCHERS (PV)
    RECORDS EXTRACTED: 8 RECORDS OUTPUT: 9
    EXTRACTING travel_claims (TC)
    RECORDS EXTRACTED: 1 RECORDS OUTPUT: 1
    EXTRACTING liability (LB)
    RECORDS EXTRACTED: 1 RECORDS OUTPUT: 1
    EXTRACTING hand_warrants (HW)
    RECORDS EXTRACTED: 0 RECORDS OUTPUT: 0
    EXTRACTING canned_warrants (CW)
    RECORDS EXTRACTED: 0 RECORDS OUTPUT: 0
    EXTRACTING rc_header (RC)
    RECORDS EXTRACTED: 0 RECORDS OUTPUT: 0


    *** what follows is the job trailer showing the statistics,
    *** don't be fooled by the wall time - there is a 'sleep 120'
    *** since this job resubmits itself to run each night at the
    *** the same time we force the time by pausing (sleep)...

    ---------------------- END OF JOB ------------------------
    QSS Job System 2.0.0 Tue Jun 24 22:02:01 2008
    pid=10267
    cpu time=6s
    wall time=175s
    num lines=596
    status=0 (exited-0)
    ----------------------------------------------------------

    * To join/leave the list, search archives, change list settings, *
    * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


+ Reply to Thread