Any Masterpack sites out there?
David A. Knollhoff
Looking to start some type of masterpack technical group on the
net. I certainly have questions and may also be able to answer
some questions concerning Masterpack. I'm running it using
Unidata & SB (character mode. May go to GUI after bugs get
worked out by someone else). Please reply if interested.
--
CyberDave
gndixon
Masterpack has finally infected the good 'ol US of A.
We in Western Australia were burnt way back in 1989. We are still
stuck with the legacy. We have versions 2.x to 3.? under System
Builder (which of course is not SB+, cos then they would not be able
suck more blood!).
Lets get a real discussion going on what good Pick Application software
(which Mastepack ain't) should look like when developed using a good 4gl (which SB+
could be if it weren't run by a bunch of Yarpies (i.e SA'ns)).
Let's hope Unidata can make SB+ work for the entire Pick community
and that some can develop a "professional" suite of base commerical
applications (GL,AP,AR,IN,JC,Payroll,Etc.)to form the foundation
for added value supply to vertical markets. GUI should not be an
issue with such a product.
but if wishes were ......
Mark Jenks
: Masterpack has finally infected the good 'ol US of A.
: We in Western Australia were burnt way back in 1989. We are still
: stuck with the legacy. We have versions 2.x to 3.? under System
: Builder (which of course is not SB+, cos then they would not be able
: suck more blood!).
: Lets get a real discussion going on what good Pick Application software
: (which Mastepack ain't) should look like when developed using a good 4gl (which SB+
: could be if it weren't run by a bunch of Yarpies (i.e SA'ns)).
: Let's hope Unidata can make SB+ work for the entire Pick community
: and that some can develop a "professional" suite of base commerical
: applications (GL,AP,AR,IN,JC,Payroll,Etc.)to form the foundation
: for added value supply to vertical markets. GUI should not be an
: issue with such a product.
: but if wishes were ......
So, tell me.. Where does Masterpack fail so bad that you say this about
them. We are currently looking at SW vendors for our company, and they are
on the list of possibilities.
Any input is welcome.
Mark
David L. Wasylenko
master pack... hum... rings a bell
We did a search for a product to replace the RESULTS distribution
package. Master Pack was NOT the one we PICKed ;) It was a mix of
SB+ and SB, was slow, ugly and hard to modify.
-
This was over 4 years ago though... SB+ is still S L O W
We have a client running an HP 9000 G70 with 300 users running a
HEAVY BASIC order entry system. They tried using SB+ and the machine
DIED at about 90 users.
--
______ ______ _ ___ David L. Wasylenko __ _
(_____ \ (_____ \ (_) ( / \ o / ( / /
_____) ) _____) ) _ / / __, _ ,_, __/ / / /
| ____/ | ____/ | | (/\_/ (_/(_/ |/ (_(_/_ (_/_/ o
| | | | | | http://www.inlink.com/~dlw
|_| |_| |_| mailto:d...@inlink.com
http://www.pick.com Pick Professionals, Inc.
Davidangl
>master pack... hum... rings a bell
>We did a search for a product to replace the RESULTS distribution
>package. Master Pack was NOT the one we PICKed ;) It was a mix of
>SB+ and SB, was slow, ugly and hard to modify.
>-
>This was over 4 years ago though... SB+ is still S L O W
>We have a client running an HP 9000 G70 with 300 users running a
>HEAVY BASIC order entry system. They tried using SB+ and the machine
>DIED at about 90 users.
Has it occured to you that there are good practices and bad in developing
SB+ applications, just as there are good and bad in basic. A badly
written SB+ application will be slower than a well written one in basic, a
well written SB+ application will be faster than a badly written basic
one. The only way to compare is to get experienced SB+ and basic
developers to write the same application in both and run them on the same
hardware - but by the time the basic developers have something to show the
SB+ developers will be long gone leaving a consistent, tested application
complete with GUI. That is why so many software companies use it.
Ross Ferris
Yeah, but hang on guys. MASTERPACK is (supposed) to be written by people who
ARE very well versed in SB+ and all things system builder. If anyone
should/could have been able to make SB+ sing, surely it would be a company
where the architects of SB+ had a stake holding ?
I therefore don't think ithis is necessarily a valid comment to make.
I think it would be more correct to sya, in general terms, any product
developed using a 4GL is going to be slower RUNNING than one developed in a
3GL (assuming moderate proficiency in both), which in turn in going to be
slower than something written in assembler.
I would therefore suggest that your closing comment is correct (ie: SB+ or any
4GL environment is going to be more productive than cutting code in Basic),
but the suggestion that MasterPack was written by people who didn't know their
way around SB/SB+ is (I hope for all concerned) false
I have to say, however, that I HAVE NOT seen MasterPack code, but have heard
frequently the general comment that MasterPack (and indeed MOST) SB+
applications are not renowned for speed.....
any comment from the masterpack developers ?
Davidangl
In article <4v5u87$f...@ghostgum.hunterlink.net.au>, ro...@stamina.com.au
(Ross Ferris) writes:
I was not talking about Masterpack specifically - I was commenting on the
point rasied about someone trying to move their order entry system from
basic to SB+. I haven't seen Masterpack since the late eighties and have
no idea haow good they are at using SB+. However I am not sure that your
comment about the architects of SB+ having a stakeholding in Masterpack is
correct. SB+ originates from Derek and Neill Miller - my understanding is
that it is their cousin, Desmond Miller, who is associated with
Masterpack. Des is not one of the architects of SB+ - he is a
marketing/sales specialist and not technical.
>I therefore don't think ithis is necessarily a valid comment to make.
>
>I think it would be more correct to sya, in general terms, any product
>developed using a 4GL is going to be slower RUNNING than one developed in
a
>3GL (assuming moderate proficiency in both), which in turn in going to be
>slower than something written in assembler.
>
SB+ runs in two modes, interpretive or generated source. With source
generated you are running basic, so the issue is how efficient that basic
code is as opposed to hand crafted code. On the surface the SB+ code will
probably be slower but you have to take into account all the extra
facilities you get - the ability to call process from any input, lookups
and help at every input and so on. Build all these into your basic
application and you might start to have something you can compare. OK if
you don't care about these then your basic will be faster because you
can't strip these functions from SB+. Many developers do not generate the
basic code and run interpretively which is slower than basic.
The comment concerned an order entry application which is potentially one
of the most difficult to develop in SB+. The obvious way to do it
involves building large multi-values which can kill your response. But if
you know SB+ well enough you appreciate that there are a number of other
options available, the most suitable depending on the circumstances -
number of lines per order in particular. So the fact that a system running
300 users was not able to support more than 90 under SB+ does not mean
much unless you know how the SB+ was being used.
>I would therefore suggest that your closing comment is correct (ie: SB+
or
>any
>4GL environment is going to be more productive than cutting code in
Basic),
>but the suggestion that MasterPack was written by people who didn't know
>their
>way around SB/SB+ is (I hope for all concerned) false
>
>I have to say, however, that I HAVE NOT seen MasterPack code, but have
heard
>frequently the general comment that MasterPack (and indeed MOST) SB+
>applications are not renowned for speed.....
>
>any comment from the masterpack developers ?
>
>
I have no idea how well the Masterpack developers know SB+, I don't know
them or their product. My comments related to SB+ applications generally
and not to Masterpack specifically.
ro...@hkstar.com
I have just spent the last two years with Masterpack up to the latest
version. It is functionally OK but SLOW and dangerous to modify. The
upgrade costs are significantly more than the instalation / purchase
cost. We were spending AUS$100,00 every three months just stabilising
the systems. This has reduced now. The guys have taken aboard a bunch
of ex. Masterpack Guys direct and things have settled down.
We were using UniVerse and this is part of the problem one would
guess. I would have liked to see unidata put through its paces.
Des Miller is now the principal. The other Major shareholder bailed
out after Des took the bulk of the shares.
Masterpack is on a heavy recruiting campaign as they are having
trouble holding onto staff. Thin on the ground is an understatement.
APTTELFORD
I was involved in the first attempted introduction of Masterpack in the UK
in the late 80's. The product was marketed through any SB VAR's looking
for an accounts system without having to develop it.
Although Masterpack was a comprehensive product (and it did do a lot to
enhance the look and feel of System Builder v5) the conversion to the UK
market (VAT regulations etc) was a dismal failure. Also the product was so
complex to install I think that I was the only individual to actually get
the product working to any great success (this was only the ledger side
(GL, PL and SL) as the SOP, POP and Stock were even more of a nightmare.
Since 1989 I have been involved in writing our own ledger systems
(STRATUM) which we have now used to replace all of our Masterpack sites
plus many other installations. I should explain the I am a director and
one of the owners of APT SOLUTIONS LIMITED, a very successful UK based
software house. I do not know of any company still running the original
Masterpack versions in the UK.
One of our major strengths (and we have a dealer network which proves
this) is to interface our own STRATUM ledgers with other companies
vertical market products (ie. Time management software, vehicle leasing
products) so that companies can choose the best accounts software together
with the best software for dealing with what their company actually does.
I believe Masterpack are having another go at the UK market using a GUI
version running under SB+ with limited success. The infrastructure they
have put in place is negligable and I pity any users who may take the
product on (Not because I think Masterpack as a product is that bad, but
just try and get support on it if things go wrong).
We already use System Builder (SA) to market our products in their part of
the world, and would be only to interested to hear from anyone wanting to
get involved in the USA.
Please contact me if I can be of any more help.
I apologise if this comes across as a bit of a sales pitch for our
company, it is not intended to do so, but is a valid attempt to answer the
original question about my experience with Masterpack
Regards
Stuart Shepherd
APT Solutions Limited
Telford, Sheffield and London
England
James Verlare
We have been working with the Masterpack series now for nearly two
years. We have highly customized it to meet our internal accounting
models. We were the first site to get the series on UniData (ver 5.5 in
US) rather than UniVerse. Our plan is to use it at 10 international
sites in over 17 different currencies and have all companies roll up at
several levels and finally into one single US$ holding company. Some
observations:
1) The basic GL AR and AP are fine (by now). I can't speak to the
balance of the modules since we haven't deployed them yet.
2) When we made our selection two years ago, no other package (other
than MasterPeice from Computer Associates) could handle our
requirements. That package was out of our league. Without question,
our application has stretched Masterpack to the limit (in the area of GL
and cost centers, etc).
3) The real costs to Masterpack come after you purchase it, though. It
is certainly not your son's PC package. If you are already an SB+ shop
and need a base package to develop enterprise MIS systems from, it is a
good choice.
4) There have been a lot of pains in getting Masterpack ported to
UniData and getting the GL-Consolodation module to work (nearly two
years). But performance is not much of an issue running MP on UniData
on RS6Ks. We have found UniData to be incredibly stable and requires no
database administraor. Our system availability has been well over 99%
over the past 5 years on the RS6K boxes.
5) Ommiting SBClient, if you can live in a character world, SB+ is a
great development environment. We have been able to really tie
everything together to make all our MIS systems and the Masterpack
series look and feel the same so users view all MIS systems as just one
big system. There are indeed lots of tricks and ideas that we have
learned from Masterpack code that have helped us maximize our other
developments in the SB+ environment.
Jim Verlare
jver...@twr.org
Brian Barnes
of our customers in Tennessee (USA). I thought it was impossible for
an end user or external software house to install the package. We had
the Masterpack people do the install.
I customized this package for a year before I moved on to other things.
The support was not very good. Once we began to get support from
Dallas, Texas it got a lot better.
I have not heard anything good about the GUI version of SB+. If
Masterpack is using this, well ....
Brian Barnes
Davidangl
>
>I have not heard anything good about the GUI version of SB+. If
>Masterpack is using this, well ....
The GUI version of SB+ works extremely well if you follow some simple
rules:
1. Do not attempt to run it on inadequate hardware - The desktop PC needs
to have at least 8Mb and preferably 16Mb.
2. You can run it over a serial line but really you want to be on a
network. If running serially make sure you have good quality serial
cards.
3. Keep you screens fairly uncluttered. If you have fields running into
each other or overlapping on your character screen you will have a mess in
the GUI.
4. Do all of your screen handling in SB+ - if you are printing to the
screen in paragraphs or basic you will need to do some work to integrate
them into the GUI.
5. Before you upgrade to SB+ 3.3.2 make sure that your FILES record in the
xxCONTROL file contains all of your files. Only definitions against the
files in there will be converted and if you try to run GUI on screens that
have not been converted it will be a mess.
The early versions of the software had problems but if you run 3.3.2 SB+
with SBClient 2.3.2 then it works very well. The result is by far the
best GUI I have seen for a Pick application, bear in mind that you can
still run your application character based if you want and you can still
develop character based with the GUI being automatically generated for
you.
I don't know whether Masterpack uses this, but if they do there is no
reason why it shouldn't run very well.