D3 vs jBase vs mvBase
Richard Ginsburg
Well here's a little ditty that's sure to set someone's pants on fire.
We've been testing D3, jBase and mvBase. Interested in our findings? Follow
the link below:
http://www.fawnridge.com/compare.htm
--
Richard Ginsburg can be reached at:
e-mail...: mailto:compass_...@yahoo.com
internet.: http://www.fawnridge.com
telephone: 908.236.2334
fax......: 908.236.2109
Luke Webber
"Richard Ginsburg" <compass_...@yahoo.com> writes:
>Well here's a little ditty that's sure to set someone's pants on fire.
>We've been testing D3, jBase and mvBase. Interested in our findings? Follow
>the link below:
> http://www.fawnridge.com/compare.htm
Thanks for that Richard. I'm not sure my pants are on fire, but it's good
of you to share your experiences with the rest of us.
Seems to me the big point in favour for mvBase is compatibility with
existing Pick applications. Interesting that it should be more stable and
possibly even more compatible than D3! <g>
As Fran pointed out, you don't have to code in VB (ptooie!) or even Delphi
(hurrah!) to use jBASE. The great strength of jBASE in my eyes is its
close integration with the host environment. As you pointed out, this can
lead to some points of incompatibility, but I think the game is well and
truly worth the candle.
Overall, I'd say your tests may have been coloured by the use of Win95.
From all I've seen to date I'd say Win95 is fine as a client OS, as in
that VB client programming scenario you don't want to take on just yet,
but not suitable as a server. That leaves it out as far as running a
centralised Pick-style application.
As for the period problem with program names, I haven't seen that, but
then I'm using the Unix versions. On the versions I've seen, illegal
characters in subroutine names are converted during compilation and there
is no problem with periods in mainline binaries.
AFAIK, there shouldn't *really* be a problem with periods in binaries
under Winblows either, except that you need to call them with an explicit
.exe suffix, Maybe VC++ won't let you create them, but then that could be
addressed by a RENAME after the linking phase. If your M/DICT had an entry
for the program and you were using the jshell you should then be OK.
Still, maybe it goes deeper than that.
Great comments on the JAC support, and I agree fully. They're top-notch.
--
Luke Webber
* Note: The opinions expressed by Luke Webber are in no way supported *
* by his employers, Luke Webber Consulting Services *
Richard Ginsburg
Luke Webber <lu...@oberon.sub.net.au> wrote in article
<luke.893377571@oberon>...
Overall, I'd say your tests may have been coloured by the use of Win95.
From all I've seen to date I'd say Win95 is fine as a client OS...
Luke, you are correct about Windows95 being useless for a large network.
However that's exactly what we are coming up against with new prospects. So
many people out in the real world jumped on Windows95 and its ease of
creating a file-sharing network not realizing that it's slow and really not
designed for a Pick type business application. So, we are then faced with
a) forcing these small sites (5 to 25) users into adding an NT server or b)
a Pick host with Pic-Lan. For my 10 cents, I'd stay with the Pick
host/Pic-Lan scenario only due to my total lack of experience with NT. My
goal, of course, is to sell my application to every retail store in the
world regardless of the platform!
Richard Ginsburg
Luke,
$300? Wrong! Try $10,000. By the by, we've found that AP-Pro and Pic-Lan
on a 5 to 25 user system works just fine even in a Windows95 peer-to-peer
or small hub network. Even with 'cheap' hardware we don't see any problems
with the over 100 installed sites we have now. Hey, if the user has the
money to buy 'good' hardware and set up an NT server, etc, etc. all the
power to them. Remember, we go out of our way NOT to sell hardware. We're a
software company. If the hardware doesn't work they can't blame us. Of
course they call us either way! But when we propose a new system we always
let the user decide what they want to spend on the hardware.
--
Richard Ginsburg can be reached at:
e-mail...: mailto:compass_...@yahoo.com
internet.: http://www.fawnridge.com
telephone: 908.236.2334
fax......: 908.236.2109
Luke Webber <lu...@oberon.sub.net.au> wrote in article
<luke.893429002@oberon>...
"Richard Ginsburg" <compass_...@yahoo.com> writes:
>Luke, you are correct about Windows95 being useless for a large network.
>However that's exactly what we are coming up against with new prospects.
So
>many people out in the real world jumped on Windows95 and its ease of
>creating a file-sharing network not realizing that it's slow and really
not
>designed for a Pick type business application. So, we are then faced with
>a) forcing these small sites (5 to 25) users into adding an NT server or
b)
>a Pick host with Pic-Lan. For my 10 cents, I'd stay with the Pick
>host/Pic-Lan scenario only due to my total lack of experience with NT. My
>goal, of course, is to sell my application to every retail store in the
>world regardless of the platform!
Wow. Nice ambition, but you may need a reality check. Even a 5-user
network should have a proper server. Peer-to-peer simply doesn't cut it,
and if you have opposition who say that it does you should be able to cut
them to ribbons.
Be honest now, do you really want to sell a million systems at $300 and
change on a half-arsed OS and (most likely) crappy hardware? The big
problem is, even at $300 a pop, those buggers are going to expect you to
*support* it. Blame M$ all you like, the fact is that *you* chose the
platform, and if it doesn't work for you, Bill won't be the one taking the
fall.
Pleasant dreams,
Luke Webber
Luke Webber
"Richard Ginsburg" <compass_...@yahoo.com> writes:
>Luke,
> $300? Wrong! Try $10,000. By the by, we've found that AP-Pro and Pic-Lan
>on a 5 to 25 user system works just fine even in a Windows95 peer-to-peer
>or small hub network. Even with 'cheap' hardware we don't see any problems
>with the over 100 installed sites we have now. Hey, if the user has the
>money to buy 'good' hardware and set up an NT server, etc, etc. all the
>power to them. Remember, we go out of our way NOT to sell hardware. We're a
>software company. If the hardware doesn't work they can't blame us. Of
>course they call us either way! But when we propose a new system we always
>let the user decide what they want to spend on the hardware.
Richard,
Forgive me for jumping to comclusions, but it certainly sounded like you
were going out of your way to sell cheap solutions. Networks need servers.
Keeping your data on a client PC which could be going up and down for any
number of reasons, from software bugs to operator error, is not a good or
safe solution. If the hardware doesn't work, they can't blame you, but if
hardware or network or other failures lead to data corruption, you'll wear
it.
Seriously, peer-to-peer is OK for printer sharing, *just*, but a network
without a server is a ticking time bomb.
Homer Hazel
Luke,
"Networks need servers!" ???
That sounds like a truism more than a fact. Now - that I've disagreed with
you, I will agree with you on certain aspects of networks. Networks do need
a central focus for certain functions. Among these functions are Printing,
Faxing, and File Sharing.
Gee, Mr.. Hazel, isn't that about all you do with a network?
Yes of course, except for attaching to the Internet & Electronic Mail and
Such. However, each of these functions can readily be performed by
dedicating a Windows 95 machine to be a dedicated "whatever" server. It is
incredibly easy to set up a Win95 Computer as a FAX server, or as a Print
server or even as an Electronic Mailbox, or all three on the same computer.
It all comes free and included with Windows 95. You could run D3 atop 95 on
a very big box, or you could get a small Pentium computer and run AP/PRO
with PicLan. I've got clients running the AP/PRO PicLan combination with 60
users. One runs on a 486-100 they are very happy with.
Of course, you can buy Windows NT for about 6 times the cost of Windows 95,
and you get many other benefits, including security, RAID software for
disks, and fairly good backup software. But you do not get shared Faxing
without an extra cost.
If you have a conventional database solution (Access, SQL, Progress) with a
shared database system, then I agree whole heartedly that you need a server.
A very large server since most if not all of the data will be stored on the
server. In today's large GUI based systems, whether it be Win95 or WinNT or
whatever, the amount of data stored on each individual's computer is
extremely large. It's my believe that the days of storing all of the
company's data, including spreadsheets, word processing, etc., is over.
Granted that large disks are falling in price, but the size of data is
increasing even faster.
Most of my clients use the server for sharing resources and data, but not
for storing all files
Larry Hazel
Bye the way, this is my opinion, and most of the time it is supported by my
employer
Homer L. Hazel Consulting.
Luke Webber wrote in message ...
Jim Idle
Luke Webber wrote in message ...
>"Richard Ginsburg" <compass_...@yahoo.com> writes:
>>As for the period problem with program names, I haven't seen that, but
>then I'm using the Unix versions. On the versions I've seen, illegal
>characters in subroutine names are converted during compilation and there
>is no problem with periods in mainline binaries.
I think that what Richard may have experienced, is that the linker that
comes with C++, neglects to add a .EXE to the executable it produces, if the
name of the executable alrady contains a period. It is a left over from the
DOS attitude to files, of course. While in most cases this is irrelevant,
because an executable is an executable and it will still run, certain
programs don't recognize .EXEs if they don't actually end in .EXE.
Therefore sometimes you go:
BASIC BP My.Prog
CATALOG BP My.Prog
My.Prog
[3] Unable to execute program 'My.Prog'
But if you add the .EXE to My.Prog, then it miraculously can exectute the
binary. I forget under what circumstances this happens and I am unable to
reproduce it on my NT system here at my desk. It may be a Windows 95 only
thing (again ;-).
Jimi
Jim Idle
Richard Ginsburg wrote in message
<01bd6f6e$a8356840$49e8...@compass.blastnet>...
>
>Luke Webber <lu...@oberon.sub.net.au> wrote in article
><luke.893377571@oberon>...
>Overall, I'd say your tests may have been coloured by the use of Win95.
>From all I've seen to date I'd say Win95 is fine as a client OS...
>
>Luke, you are correct about Windows95 being useless for a large network.
>However that's exactly what we are coming up against with new prospects. So
>many people out in the real world jumped on Windows95 and its ease of
>creating a file-sharing network not realizing that it's slow and really not
>designed for a Pick type business application. So, we are then faced with
>a) forcing these small sites (5 to 25) users into adding an NT server or
In fact NT workstation would be fine Richard, and it costs not that much
more than Windows 95, but a lot less to look after ;-).
Jimi
Richard Ginsburg
Jim, is it really less to look after? I've gotten used to installing AP-Pro
on computer and rarely, if ever, had a system hang (other a user hitting
ctrl-S by accident or a poorly configured modem). Again, please keep in
mind that I've had no contact yet with NT.
--
Richard Ginsburg can be reached at:
e-mail...: mailto:compass_...@yahoo.com
internet.: http://www.fawnridge.com
telephone: 908.236.2334
fax......: 908.236.2109
Jim Idle <noth...@spam.com> wrote in article
<6i46m1$hs2$1...@supernews.com>...
Luke Webber
I think I've been arguing at cross-purposes for my last couple of posts. I
had my blinkers on because the initial post concerned mvBase on Win95 and
I missed the switch to AP on Piclan. This is naturally a more stable
platform than Win95, although far from open.
Still, I can't help wondering what Richard is going to get from going
mvBase on Winblows or jBASE on Wintel or Unix if he's going to cut and run
to AP Native for smaller implementations. The need to support the two
separate platforms abates any real advantage to be gained from the switch.
It feels wrong to embrace new technology on the one hand, while clinging
to the apron strings with the other. What happens when Pick Systems drops
support for AP? I have some sympathy for those who don't want to learn
Unix or Winblows, but I don't get this half in, half out approach.
Oh, one other thing. If the users are encouraged to just plonk their data
(be it spreadsheets, word-processor documents or whatever) anywhere they
like on their local disk, it becomes virtually impossible to maintain
backups. That's one more area where a proper server and some care in
setting it up will certainly show its merit.
The other area, naturally, is in database applications, but the AP/Piclan
scenario has that covered. Of course, as I've already said, this isn't
very open. For example Piclan doesn't support the Winsock API, so you
have to use a TE that supports the Piclan API. This can end up adding
significantly to the cost of ownership, even compared to the price of an
NT license, particularly as Jim Idle has pointed out that NT Workstation
is all that's needed.
"Homer Hazel" <hom...@home.com> writes:
>"Networks need servers!" ???
>That sounds like a truism more than a fact. Now - that I've disagreed with
>you, I will agree with you on certain aspects of networks. Networks do need
>a central focus for certain functions. Among these functions are Printing,
>Faxing, and File Sharing.
>Gee, Mr.. Hazel, isn't that about all you do with a network?
>Yes of course, except for attaching to the Internet & Electronic Mail and
>Such. However, each of these functions can readily be performed by
>dedicating a Windows 95 machine to be a dedicated "whatever" server. It is
>incredibly easy to set up a Win95 Computer as a FAX server, or as a Print
>server or even as an Electronic Mailbox, or all three on the same computer.
>It all comes free and included with Windows 95. You could run D3 atop 95 on
>a very big box, or you could get a small Pentium computer and run AP/PRO
>with PicLan. I've got clients running the AP/PRO PicLan combination with 60
>users. One runs on a 486-100 they are very happy with.
>Of course, you can buy Windows NT for about 6 times the cost of Windows 95,
>and you get many other benefits, including security, RAID software for
>disks, and fairly good backup software. But you do not get shared Faxing
>without an extra cost.
[snip]
Richard Ginsburg
Luke,
A couple of clarifications...
First, we have always produced application software that is generic in
nature. Meaning that the port to ANY flavor of the Pick OS should be
simple. We avoid user exits and machine-specific features at all costs, we
limit our use of proc for menus and front-ends to print jobs and the basic
code is all in upper-case (a limitation of far too many Pick-like
implementations.)
Second, we are already supporting 6 different OS implementations with the
same application - GA, Fujitsu, R83, AP-Native, AP-Pro, and now mvBase on
Win95. Our goal has been on moving some of the older sites to, at least,
AP-Pro with Pic-Lan and giving future customers the offerings of both the
AP-Pro/Pic-Lan scenario and the WindowsNT version. As far as Pick Systems
no longer supporting AP-Pro - we have had no need to contact them or anyone
else about AP-Pro problems for years. Like I said, if we keep it simple, it
always works. The only contact we've had with anyone at Pick for support is
for the miserable D3 product. We've put up AP-Pro on all sorts of machines
with some of the wildest combinations of peripheral devices you can imagine
- and they all work! (Jeez, does this make me an expert???)
As far as backups go...Rule #1 at COMPASS Software - no incremental
file-saves only full system file-saves are permitted. Rule #2 - we backup
the Pick System only, the user is responsible for anything else. We are not
in the business of supporting Excel or Word or any other Windows or DOS
product or its resultant data. I DO agree that an NT environment that
backups EVERYTHING is going to be much easier on the user and I DO look
forward to that day.
Last, explain the Winsock API? Why do I need to concern myself with this?
What is it used for and how does it enhance our applications?
--
Richard Ginsburg can be reached at:
e-mail...: mailto:compass_...@yahoo.com
internet.: http://www.fawnridge.com
telephone: 908.236.2334
fax......: 908.236.2109
Luke Webber <lu...@oberon.sub.net.au> wrote in article
<luke.893822522@oberon>...
I think I've been arguing at cross-purposes for my last couple of posts. I
had my blinkers on because the initial post concerned mvBase on Win95 and
I missed the switch to AP on Piclan. This is naturally a more stable
platform than Win95, although far from open.
Still, I can't help wondering what Richard is going to get from going
mvBase on Winblows or jBASE on Wintel or Unix if he's going to cut and run
to AP Native for smaller implementations. The need to support the two
separate platforms abates any real advantage to be gained from the switch.
It feels wrong to embrace new technology on the one hand, while clinging
to the apron strings with the other. What happens when Pick Systems drops
support for AP? I have some sympathy for those who don't want to learn
Unix or Winblows, but I don't get this half in, half out approach.
Oh, one other thing. If the users are encouraged to just plonk their data
(be it spreadsheets, word-processor documents or whatever) anywhere they
like on their local disk, it becomes virtually impossible to maintain
backups. That's one more area where a proper server and some care in
setting it up will certainly show its merit.
The other area, naturally, is in database applications, but the AP/Piclan
scenario has that covered. Of course, as I've already said, this isn't
very open. For example Piclan doesn't support the Winsock API, so you
have to use a TE that supports the Piclan API. This can end up adding
significantly to the cost of ownership, even compared to the price of an
NT license, particularly as Jim Idle has pointed out that NT Workstation
is all that's needed.
Luke Webber
Jim Idle
Richard Ginsburg wrote in message
<01bd7310$ee696f00$d4e8...@compass.blastnet>...
>Jim, is it really less to look after? I've gotten used to installing AP-Pro
>on computer and rarely, if ever, had a system hang (other a user hitting
>ctrl-S by accident or a poorly configured modem). Again, please keep in
>mind that I've had no contact yet with NT.
>In fact NT workstation would be fine Richard, and it costs not that much
>more than Windows 95, but a lot less to look after ;-).
>
>Jimi
Yes Richard, I beleive it is. Ihe reason is essentially that it is more
robust than Windows 95. We definately seem to spend a lot more time
supporting people using jBASE on Windows 95 (and not because they are any
less competent). Things just don't quite work as well as on NT and it is
definately a lot slower (for jBASE at least). Therefore more support time,
means more cost and less margin to the selling company.
Having said that, Windows 95 is OK, or we would not sell a version of jBASE
for it. It's just that if were a business user, of jBASE, I personally would
feel happier running NT for more than a single user system and it is more of
a pain to configure it.
I should also qualify my last statement by the way, because I beleive that
Microsoft's official position on this type of thing, is that you can make 10
connections like telnet to an NT workstation, then they expect you to buy NT
Server. Seems a fairly reasonable stance to take to me, although it means
that an 11 user system costs more than 1 more jBASE license of course ;-).
Jimi
Doug Dumitru
Richard, et. al.
I really enjoy watching these discussions, but in that PicLan has been
mentioned a few times, I would like to chime in with a bit of
clarification and news (sorry for the ads that are mixed in).
*** The Winsock API vs the PicLan API ***
This is a "funny" distinction being that the PicLan client uses the
Winsock API. Regardless here is the distinction.
PicLan uses a proprietary API (Applications Programming Interface)
that involves linking to PLAN.DLL (or PLAN32.DLL for Win32). Even
though the PicLan API is proprietary, it is definately not secret.
You can freely download documentation about all of the entry points
from our web site. We have even received word of several TE
products that include PicLan support that had ZERO contact with
Modular Software while integrating this communications layer.
TCP/IP TELNET connections use a non-proprietary API that involves
linking to WINSOCK.DLL (or WSOCK32.DLL for Win32).
Once the connections are established, the interfaces between these
two services are very similar in terms of functionality and
performance. PicLan is a bit better at handling things like
"break character" symantics wheras TELNET is more Unix-like with
things like option negotiation.
The primary differences between the two interfaces is how
servers are located. TELNET uses IP address, perhaps through a
hosts file or DNS lookup. PicLan uses advertising IPX servers
allowing interactive connect "select from list" type functions.
In terms of performance and network overhead, PicLan is a bit
more efficient in local network environments because IPX packet
headers are a bit shorter than TCP/IP headers. In wide-area
environments (and particularily the internet), TELNET is a bit
better because of sliding windows and the TCP/IP congestion and
retry algorithms.
The main difference between setting up PicLan and setting up TELNET
involves the difference in setting up an IPX network versus setting up
a TCP/IP network. Setting up a TCP/IP network is much more
complicated than is setting up an IPX network. Configuring routers,
assigning IP addresses, setting up DHCP and DNS servers are all issues
that IPX networks just do not have to deal with.
The last point mentioned was the available of TE (Terminal Emulators)
for PicLan versus Winsock TELNET. While it is true that PicLan
support tends to be limited to Pick-market TE products, to my
knowledge every reasonably successful Pick-market TE has PicLan
support included. In addition, the bundled PicLan TEs (PLT, PL-TERM,
PLTW, and PLTW32) provide most of the basic TE functions so most sites
do not buy aftermarket TE products anyway (we have had such good
feedback about PLTW and PLTW32, that we are going to release TELNET
connection support in these programs in the next several days [sorry,
but it won't be free {it will be cheap}]).
*** Other Ways out of the Pick Host ***
If the IPX nature of PicLan is still too limiting, there are a couple
of other network mechanism to reach out from the native Pick box.
** Using a PicLan DOS Services Gateway
One of the more flexible things about PicLan lies in the ability
to use a PicLan DSG to reach network printer and file system
resources. With the release of the 32-bit Windows DSG over a
year ago, this allows you to reach network resources that may
reside across non-IPX networks. It is quite easy to print to
a TCP/IP print server, or reach a distant Windows NT file system
that only has NETBEUI or TCP/IP connectivity.
*** START OF ADVERTISEMENT ***
** The PicLan TELNET Gateway
In response to a "perceived need", we released the PicLan
TELNET gateway (again over a year ago). This product consists of
a very small 32-bit Visual Basic application that listens for
inbound TCP/IP TELNET connections and "routes" them to a native
Pick host through IPX PicLan connections. This is a low-tech,
low-cost solution for people that just have to have TELNET and
TCP/IP. It also works with any PicLan host including older
systems like R83, AP/Native, and Upboard.
** PicLan-IP
The TELNET Gateway was just a stop-gap product (although it still
has it's applications). PicLan-IP is the more direct approach.
PicLan-IP actually adds TCP/IP protocol support to the PicLan
eternet and fast-ethernet driver allowing you to directly reach
32-bit native Pick host with TELNET, HTTP, SMTP and POP3
services. The current set of supported Pick hosts include
AP/Pro, Mentor PRO, Sequoia PRO, and Pick/64+.
One last note about PicLan-IP. PicLan-IP is ***NOT*** a native-
only Pick product. The HTTP, SMTP, and POP3 functions are
currently shipping on three NT-hosted (mv*Base, D3, Universe)
platforms with many more NT and Unix ports in the works.
If you want to see PicLan-IP run, you should visit
http://piclan.com or just send me email (do...@modsoft.com). Both
HTTP and SMTP/POP3 services at Modular Software are running
completely on a MultiValue host (mv*Base on Windows NT in this
case).
*** END OF ADVERTISEMENT ***
I am not trying to imply here that native Pick hosts are the best
choice for all users. I would also take exception that hosted Pick
environments are the best choice for all users. Native systems are
simple and reliable. While there may be some functinality that native
hosts lack, the general inability to communicate with a network is not
included in that list.
Doug Dumitru
Modular Software Corporation
do...@modsoft.com
http://modsoft.com Our main public site
http://piclan.com The PicLan-IP demo site
Luke Webber
do...@modsoft.com (Doug Dumitru) writes:
[snip]
>The last point mentioned was the available of TE (Terminal Emulators)
>for PicLan versus Winsock TELNET. While it is true that PicLan
>support tends to be limited to Pick-market TE products, to my
>knowledge every reasonably successful Pick-market TE has PicLan
>support included. In addition, the bundled PicLan TEs (PLT, PL-TERM,
>PLTW, and PLTW32) provide most of the basic TE functions so most sites
>do not buy aftermarket TE products anyway (we have had such good
>feedback about PLTW and PLTW32, that we are going to release TELNET
>connection support in these programs in the next several days [sorry,
>but it won't be free {it will be cheap}]).
Well I do have a TE product for sale, but I haven't considered adding
Piclan support. My position is that Winsock is based on an open standard
which has supposedly freed us of the need to write platform-specific code
for comms. I offer serial and Winsock telnet and since nobody has yet even
inquired after a Piclan interface, I'm not keen to invest my time in it. I
guess Piclan just isn't all that widely used in Australia.
I don't mean to belittle your product in any way, but I do like to make
use of industry standards wherever possible. Like it or not, the IP
protocols are the most popular data comms standard for Unix and
heterogeneous environments, and the Internet has done a lot to extend
that dominance. So that's what I tend to work with. It's a lot
easier to find people who understand IP as well, so I'm pretty comfortable
with my choice.
Of course your Piclan IP product gives you the ability to mix and match
as well, but the last time I inquired the price of Piclan with IP in
Australia was ruinously high. That may no longer be the case, but I'm
really no longer interested in native Pick implementations. My own bias
showing through, there.
It may be I came by my aversion to proprietary solutions by way of Smile.
Anybody remember Smile on Sanyo/Icon? Probably way too many.
[snip]
> In response to a "perceived need", we released the PicLan
> TELNET gateway (again over a year ago). This product consists of
> a very small 32-bit Visual Basic application that listens for
> inbound TCP/IP TELNET connections and "routes" them to a native
> Pick host through IPX PicLan connections. This is a low-tech,
> low-cost solution for people that just have to have TELNET and
> TCP/IP. It also works with any PicLan host including older
> systems like R83, AP/Native, and Upboard.
Coff! Why VB, in Heaven's name? <g>
> ** PicLan-IP
> The TELNET Gateway was just a stop-gap product (although it still
> has it's applications). PicLan-IP is the more direct approach.
> PicLan-IP actually adds TCP/IP protocol support to the PicLan
> eternet and fast-ethernet driver allowing you to directly reach
> 32-bit native Pick host with TELNET, HTTP, SMTP and POP3
> services. The current set of supported Pick hosts include
> AP/Pro, Mentor PRO, Sequoia PRO, and Pick/64+.
> One last note about PicLan-IP. PicLan-IP is ***NOT*** a native-
> only Pick product. The HTTP, SMTP, and POP3 functions are
> currently shipping on three NT-hosted (mv*Base, D3, Universe)
> platforms with many more NT and Unix ports in the works.
This last struck me as very strange until I realised that these products
really do need some middleware even for simple things like mail. I guess
I've been thinking in terms of jBASE for too long. <g>
>*** END OF ADVERTISEMENT ***
>I am not trying to imply here that native Pick hosts are the best
>choice for all users. I would also take exception that hosted Pick
>environments are the best choice for all users. Native systems are
>simple and reliable. While there may be some functinality that native
>hosts lack, the general inability to communicate with a network is not
>included in that list.
I fear I've been turned off the native Picks by the slow pace of their
development and limited device support (including networking). Unix
and even NT support TCP/IP and installable device drivers, and I'm very
fond of those features. Again, my bias showing through.
How much administration is required in a properly installed system, either
Pick or Unix, anyway? Backups can be scripted on both systems and recovery
should be just as simple unless problems arise, in which case things can
get just as sticky on Pick as Unix. Maybe starting printers and changing
form queues - also scriptable. There isn't much for the user to worry
about in having a Unix or NT system as opposed to native Pick, and they
can even load other DBMSs and applications beside Pick if they so choose.
Native Pick restricts the options too much for my liking.
Again, just my HO.
--
Luke Webber
"Richard Ginsburg" <compass_...@yahoo.com> writes:
>Luke,
> A couple of clarifications...
>First, we have always produced application software that is generic in
>nature. Meaning that the port to ANY flavor of the Pick OS should be
>simple. We avoid user exits and machine-specific features at all costs, we
>limit our use of proc for menus and front-ends to print jobs and the basic
>code is all in upper-case (a limitation of far too many Pick-like
>implementations.)
I don't know that it's what I'd call a *significant* limitation. In fact,
despite being an old C hand I'd argue that support for mixed case can be a
source of confusion. Why should the case of a keyword or identifier have
any significance to the compiler? This really comes home to roost in Java
when a single mistake in a long string of identifiers (methods or
properties of object, etc) can lead to an "Unknown method error". Why is
it unknown? Did you misspell it or get the case wrong? Were youi mistaken
as to which object supported this method? Did you pass a data type that
isn't accepted by any of the thirty or forty similarly named methods of
this class? Just another source of confusion.
And naturally when Pick Systems gave us support for mixed case in BASIC
they sneakily put the support into the COMPILE verb but not the BASIC
verb. What the ...? <g>
>Second, we are already supporting 6 different OS implementations with the
>same application - GA, Fujitsu, R83, AP-Native, AP-Pro, and now mvBase on
>Win95. Our goal has been on moving some of the older sites to, at least,
>AP-Pro with Pic-Lan and giving future customers the offerings of both the
>AP-Pro/Pic-Lan scenario and the WindowsNT version. As far as Pick Systems
>no longer supporting AP-Pro - we have had no need to contact them or anyone
>else about AP-Pro problems for years. Like I said, if we keep it simple, it
>always works. The only contact we've had with anyone at Pick for support is
>for the miserable D3 product. We've put up AP-Pro on all sorts of machines
>with some of the wildest combinations of peripheral devices you can imagine
>- and they all work! (Jeez, does this make me an expert???)
It's not just support as in GFE fixing or bug reports or whatever. What if
your customer wants to license some more users and Pick Systems have
finally dumped AP/Pro? What if they want to license a machine in another
state? I don't see any future in it, even if it is as comfortable as a
worn, old slipper.
>As far as backups go...Rule #1 at COMPASS Software - no incremental
>file-saves only full system file-saves are permitted. Rule #2 - we backup
>the Pick System only, the user is responsible for anything else. We are not
>in the business of supporting Excel or Word or any other Windows or DOS
>product or its resultant data. I DO agree that an NT environment that
>backups EVERYTHING is going to be much easier on the user and I DO look
>forward to that day.
Indeed. Most networks I've seen still have users saving their crap to
their local disks, just waiting for a power surge or disk crash to wipe
out months of productivity. Crazy.
>Last, explain the Winsock API? Why do I need to concern myself with this?
>What is it used for and how does it enhance our applications?
You see a lot of posts in this group from people looking for terminal
emulation software, and there are usually some posters who recommend Telix
or Ewan or QVTNet or Hyperterm or other freeware, shareware or bundled
products. Those won't work with Piclan. Or take the case of a customer
with an existing Unix host who wants to add your application onto his
network and continue using his current telnet client. No go.
Of course, with your strategy you have the freedom to recommend mvBase on
NT, but suppose the customer wants Unix and not NT? I'd say jBASE provides
a better solution because it is more portable.
With apologies to Doug, I still have a problem embracing Piclan, although
I do acknowledge the valuable contribution it has made in Pick
connectivity prior to the availability of the current array of hosted Pick
and Pickish products.
Doug Dumitru
lu...@oberon.sub.net.au (Luke Webber) wrote:
>do...@modsoft.com (Doug Dumitru) writes:
>[snip]
>>The last point mentioned was the available of TE (Terminal Emulators)
>>for PicLan versus Winsock TELNET. While it is true that PicLan
>>support tends to be limited to Pick-market TE products, to my
>>knowledge every reasonably successful Pick-market TE has PicLan
>>support included. In addition, the bundled PicLan TEs (PLT, PL-TERM,
>>PLTW, and PLTW32) provide most of the basic TE functions so most sites
>>do not buy aftermarket TE products anyway (we have had such good
>>feedback about PLTW and PLTW32, that we are going to release TELNET
>>connection support in these programs in the next several days [sorry,
>>but it won't be free {it will be cheap}]).
>
>Well I do have a TE product for sale, but I haven't considered adding
>Piclan support. My position is that Winsock is based on an open standard
>which has supposedly freed us of the need to write platform-specific code
>for comms. I offer serial and Winsock telnet and since nobody has yet even
>inquired after a Piclan interface, I'm not keen to invest my time in it. I
>guess Piclan just isn't all that widely used in Australia.
Some of our first PicLan installs on R83 were in Australia and New
Zealand (serial number 3 was an all token-ring LAN in Sydney). The
number of TE products that have PicLan support is definately over a
dozen, and the number of Pick hosts running PicLan is estimated at
well over 5000 (the bundle copies with Pick Systems and GA make this
number somewhat open for discussion. The actual count of total
systems is more, but the number using PicLan is probably 4000-6500
based on surveys that Pick Systems has done).
>I don't mean to belittle your product in any way, but I do like to make
>use of industry standards wherever possible. Like it or not, the IP
>protocols are the most popular data comms standard for Unix and
>heterogeneous environments, and the Internet has done a lot to extend
>that dominance. So that's what I tend to work with. It's a lot
>easier to find people who understand IP as well, so I'm pretty comfortable
>with my choice.
IP is a very popular standard now. Three years ago, the state of
affairs was very different. In those days IPX ruled the corporate
LAN. It may be that IPX is still more popular in corporate LANs, but
I admin that there is definately a shift toward IP. In terms of
finding people who know IPX versus IP, the reason you think there are
more people that know IP is that there is very little you need to know
about IPX. IPX virtually self-configures whereas IP definately does
not. Which is "better". IPX is easier to configure, more efficient
in a local LAN environment, has smaller stacks, etc. Popular
"non-Unix" protocols such as Windows Network file sharing and NetWare
services run "better" over IPX than IP (faster, less network traffic).
This would tend to make IPX a better choice for installations that are
inherently simple. This is where native Pick systems are sold. Does
that mean that all systems should run IPX. Definately not. The fact
that you do not work with them does not mean that there are a lot of
them out there.
>Of course your Piclan IP product gives you the ability to mix and match
>as well, but the last time I inquired the price of Piclan with IP in
>Australia was ruinously high. That may no longer be the case, but I'm
>really no longer interested in native Pick implementations. My own bias
>showing through, there.
PicLan-IP is not "freeware", but I do believe that it is reasonably
priced. Telnet support into native Pick hosts costs from 65$/port
($500/8-ports) to $35/port ($1100/32-ports) and lower depending on
system size. This pricing has also been static since product launch
so I am not sure where your "ruinously high" description comes from.
>It may be I came by my aversion to proprietary solutions by way of Smile.
>Anybody remember Smile on Sanyo/Icon? Probably way too many.
Unfortunately, I do. I also wrote some of the Smile code.
Considering the timeframe that SMILE (Share Memory Interface Local
Extension) was developed in, it was amazing stuff. For a while, an
ICON Unix system talking to a PC with a SMILE target card was the
fastest PC disk subsystem that you could buy and Icon sold quite a few
of these "disk servers" into the NetWare market. Did this make the
SMILE solution a "bad" choice. Not any more than paying $50K for an
external RAID subsystem that can now be had for $2K. The truth is
that you should consider your use of any technology in terms of it's
value and longevity (remember that all computer solutions are obsolete
before they actually ship). Regardless, a proprietary solution may
still be the best choice if it works and the "standards based"
solution does not. Also remember that a "standard" today may be cast
aside tomorrow (just think about all of the false starts that
Microsoft has put us through (OS2, OLE, NetDDE, ...).
>[snip]
>> In response to a "perceived need", we released the PicLan
>> TELNET gateway (again over a year ago). This product consists of
>> a very small 32-bit Visual Basic application that listens for
>> inbound TCP/IP TELNET connections and "routes" them to a native
>> Pick host through IPX PicLan connections. This is a low-tech,
>> low-cost solution for people that just have to have TELNET and
>> TCP/IP. It also works with any PicLan host including older
>> systems like R83, AP/Native, and Upboard.
>
>Coff! Why VB, in Heaven's name? <g>
Why not VB. Quick development. Less possibility of obscure GPF type
bugs. Sure performance is a little less than optimal, but were
talking terminal emulation here. Saying "why VB" is like saying "why
Pick/BASIC" instead of C++.
>> ** PicLan-IP
>
>> The TELNET Gateway was just a stop-gap product (although it still
>> has it's applications). PicLan-IP is the more direct approach.
>> PicLan-IP actually adds TCP/IP protocol support to the PicLan
>> eternet and fast-ethernet driver allowing you to directly reach
>> 32-bit native Pick host with TELNET, HTTP, SMTP and POP3
>> services. The current set of supported Pick hosts include
>> AP/Pro, Mentor PRO, Sequoia PRO, and Pick/64+.
>
>> One last note about PicLan-IP. PicLan-IP is ***NOT*** a native-
>> only Pick product. The HTTP, SMTP, and POP3 functions are
>> currently shipping on three NT-hosted (mv*Base, D3, Universe)
>> platforms with many more NT and Unix ports in the works.
>
>
>This last struck me as very strange until I realised that these products
>really do need some middleware even for simple things like mail. I guess
>I've been thinking in terms of jBASE for too long. <g>
There is even a jBase port of PicLan-IP in the works. Before you
start asking why, realize that PicLan-IP is intended to let you manage
internet tasks without ever leaving the Pick environment. The best
example of this is our programming interface for web applications.
PicLan-IP implements "active server pages" with embedded Pick/BASIC
code stored directly in HTML documents. No CGI, ODBC, or other layers
of any kind. Just fast, event-driven Pick code.
>>*** END OF ADVERTISEMENT ***
>
>>I am not trying to imply here that native Pick hosts are the best
>>choice for all users. I would also take exception that hosted Pick
>>environments are the best choice for all users. Native systems are
>>simple and reliable. While there may be some functinality that native
>>hosts lack, the general inability to communicate with a network is not
>>included in that list.
>
>I fear I've been turned off the native Picks by the slow pace of their
>development and limited device support (including networking). Unix
>and even NT support TCP/IP and installable device drivers, and I'm very
>fond of those features. Again, my bias showing through.
>
>How much administration is required in a properly installed system, either
>Pick or Unix, anyway? Backups can be scripted on both systems and recovery
>should be just as simple unless problems arise, in which case things can
>get just as sticky on Pick as Unix. Maybe starting printers and changing
>form queues - also scriptable. There isn't much for the user to worry
>about in having a Unix or NT system as opposed to native Pick, and they
>can even load other DBMSs and applications beside Pick if they so choose.
>Native Pick restricts the options too much for my liking.
How quickly you dismiss the complexity of some hosted environments. I
am not-so-fondly reminded of a system running here that had to have
NT-Server reloaded (for no apparent reason by the way). The process
of installing NT, service packs, optional add-ons from Microsoft,
third-party products, etc. took a total of 17 system boots and the
better part of a day to perform. And the sad thing is that I don't
think it could have been automated much better. I also do not think
this is an exageration. I have talked with a number of people who's
experience with NT is "load and configure it correctly the first time
or you will have to format the drive and start over to get a stable
install". Remember that native Pick is 6-8 floppies (PicLan-IP is
only 2 floppies including TELNET/HTTP/SMTP/POP3) versus Win95/NT which
is most of a CD.
Also the concept of "load other DBMSs and applications" should strike
fear into any system administrator with NT. The easiest way to insure
an unstable NT system is to run multiple applications on it unless you
are very careful.
>Again, just my HO.
>
>
>--
>Luke Webber
>
>* Note: The opinions expressed by Luke Webber are in no way supported *
>* by his employers, Luke Webber Consulting Services *
Doug Dumitru
Modular Software Corporation
Doug Dumitru
"Jim Idle" <noth...@spam.com> wrote:
>...
>
>I should also qualify my last statement by the way, because I beleive that
>Microsoft's official position on this type of thing, is that you can make 10
>connections like telnet to an NT workstation, then they expect you to buy NT
>Server. Seems a fairly reasonable stance to take to me, although it means
>that an 11 user system costs more than 1 more jBASE license of course ;-).
>Jimi
When Windows NT 4 was in Beta, Microsoft released a version that
limited the number of inbound TCP/IP connections. The user community
went postal. The company line was that Microsoft wanted to position
NT workstation as a workstation. The general take in the public was
that Microsoft wanted to use this as another tool in trying to kill
NetScape (remember that NetScapes servers run well on NT workstation
and that Microsoft bundles IIS with NT server only). Regardless,
Microsoft dropped this rediculous limit both in the code and in their
license and now considers NT workstation as 10-users in regards to use
of Windows NT file and print sharing functions. If you want to run a
mail server, web server, or Pick server on NT workstation, the sky's
the limit (actually 2 processors is the limit).
You should also note that the difference between NT server and NT
workstation from a technical point of view are:
o NT workstation supports at most 2 CPUs
o NT workstation runs longer timeslices and thus is a bit
"chunkier".
o NT server has a bunch of additional functionality such as
routing, RAS enhancements, bundled servers (HTTP, FTP, DNS),
and domain controller functions.
NT workstation and NT server have "identical" kernels.
Luke Webber
do...@modsoft.com (Doug Dumitru) writes:
>When Windows NT 4 was in Beta, Microsoft released a version that
>limited the number of inbound TCP/IP connections. The user community
>went postal. The company line was that Microsoft wanted to position
>NT workstation as a workstation. The general take in the public was
>that Microsoft wanted to use this as another tool in trying to kill
>NetScape (remember that NetScapes servers run well on NT workstation
>and that Microsoft bundles IIS with NT server only). Regardless,
>Microsoft dropped this rediculous limit both in the code and in their
>license and now considers NT workstation as 10-users in regards to use
>of Windows NT file and print sharing functions. If you want to run a
>mail server, web server, or Pick server on NT workstation, the sky's
>the limit (actually 2 processors is the limit).
I remember that. I also recall one clever fellow who shortly thereafter
discovered a registry setting which caused NT Workstation to suddenly
start reporting itself as NT Server and which lifted the limit. This
despite the fact that M$ were trying to maintain that they were two
separate products. I think that was probably the funniest part of the
whole fiasco.
It can be enormously amusing watching the contortions some companies go
through in trying to establish differntiation in their own product line
<g>.
[snip]
Richard Ginsburg
Luke,
With regard to Pick Systems dropping AP-Pro...
Yes, it's going to happen in the not to distant future and when it does
there's always MentorPro which, as I understand, now has at least a 10 year
commitment from the folks at GA. Secondly, even if Pick is no longer
selling AP-Pro to new sites they will sell additional licenses for existing
sites since it only involves a re-activation, no physical product.
And as far as case-sensitive basic code is concerned...
I agree with you that making COMPILE work and BASIC not was a pretty
short-sited plan on their part. But original premise of having total
compatibility to all Pick and Pick-like implementations has always been a
standard at COMPASS. Quite frankly, I much prefer all caps in the code. It
makes it much easier to see where the code begins and the screen printed
comments end.
Sorry but I still don't get the need for API...
We've sold hundreds of copies of Accuterm for our Pic-Lan sites and
everyone seems happy. I sure that one of these days Doug is going to really
jazz-up the TE that comes with Pic-Lan as well (are you listening Doug???)
And so the final, final is that AP-Pro, while it's around, or MentorPro
together with Pic-Lan seems to be the best solution for our smaller (5 to
15 user) sites and the larger ones are going to require an NT server
environment with, for now, mvBase. By the way, as far as UNIX is concerned,
we're not...
Doug Dumitru
Luke Webber <lu...@webber.com.au> wrote:
> ...
>
>>Unfortunately, I do. I also wrote some of the Smile code.
>>Considering the timeframe that SMILE (Share Memory Interface Local
>>Extension) was developed in, it was amazing stuff. For a while, an
>>ICON Unix system talking to a PC with a SMILE target card was the
>>fastest PC disk subsystem that you could buy and Icon sold quite a few
>>of these "disk servers" into the NetWare market. Did this make the
>>SMILE solution a "bad" choice. Not any more than paying $50K for an
>>external RAID subsystem that can now be had for $2K. The truth is
>>that you should consider your use of any technology in terms of it's
>>value and longevity (remember that all computer solutions are obsolete
>>before they actually ship). Regardless, a proprietary solution may
>>still be the best choice if it works and the "standards based"
>>solution does not. Also remember that a "standard" today may be cast
>>aside tomorrow (just think about all of the false starts that
>>Microsoft has put us through (OS2, OLE, NetDDE, ...).
>
>... and BlackBird, BoB, VBX, the list goes on. It was exactly those
>"false
>starts" I was talking about with SMILE. I know at least three sites here
>in Melbourne running SMILE and they don't have a big choice of
>emulators,
>especially since SMILE client support has been left behind in the
>16-bit DOS stone age.
*** START OF ANOTHER AD ***
If you are "really desperate", you can actually run PicLan on top of
SMILE. This lets you use all of the PicLan TE products and even the
PicLan TELNET Gateway if you are really desperate. I am not saying
that this is the "best" solution (a boat in a large lake is probably
better at this point), but it may be at least slightly better than the
current state of affairs.
*** END OF ANOTHER AD ***
>>>Coff! Why VB, in Heaven's name? <g>
>
>>Why not VB. Quick development. Less possibility of obscure GPF type
>>bugs. Sure performance is a little less than optimal, but were
>>talking terminal emulation here. Saying "why VB" is like saying "why
>>Pick/BASIC" instead of C++.
>
>OTOH, there's always the OCX Hell and the 1Mb runtime DLL. I don't love
>C++ much either (crappy syntax). Delphi is the One True Tool for native
>Winblows programming. ;^)
Agreed, the run-time support required is quite big. Remember that we
ship both 16-bit and 32-bit clients, so the run-time support files are
actually there twice.
>>There is even a jBase port of PicLan-IP in the works. Before you
>>start asking why, realize that PicLan-IP is intended to let you manage
>>internet tasks without ever leaving the Pick environment. The best
>>example of this is our programming interface for web applications.
>>PicLan-IP implements "active server pages" with embedded Pick/BASIC
>>code stored directly in HTML documents. No CGI, ODBC, or other layers
>>of any kind. Just fast, event-driven Pick code.
>
>I haven't done anything with ASP myself. Knowing their history, aren't
>you worried about committing to a relatively Microsoft standard. <g>
What Microsoft Standard. "active server pages" in the PicLan-IP web
server are completely controlled by PicLan-IP. IIS is not involved at
all. Also the PicLan-IP active server pages use Pick/BASIC and not
VB/script.
... more snipped
Morph
Richard Ginsburg wrote in message
<01bd7425$b01dd900$36e8...@compass.blastnet>...
<snip>
>We've sold hundreds of copies of Accuterm for our Pic-Lan sites and
>everyone seems happy. I sure that one of these days Doug is going to really
>jazz-up the TE that comes with Pic-Lan as well (are you listening Doug???)
> And so the final, final is that AP-Pro, while it's around, or MentorPro
>together with Pic-Lan seems to be the best solution for our smaller (5 to
>15 user) sites and the larger ones are going to require an NT server
>environment with, for now, mvBase. By the way, as far as UNIX is concerned,
>we're not...
I agree with your sentiments about the Pic-Lan TE, I seem to remember that
it either doesn't, or a previous version didn't, support Cut&Paste (Windows
version)!
However, I don't totally agree with your comment about Mentor PRO 4.x for
5-15 user sites, and NT for anything higher. NT is an exciting solution
(compared to something we already know), but seeing as Mentor PRO appears to
be able to support a much higher number of users (I'm told there's a site in
the states running a box with 100+ users, I'm not sure what h/w it's running
on though), why add a more complicated layer like the NT operating system?
Surely that will just make it a more expensive solution, both in terms of
start-up costs, and ongoing costs?
Pete
Richard Ginsburg
Pete - sorry, typo, should read 5 to 25 users. I don't know where I would
go over 25 users. You might be right that MentorPro would work just fine
for 100+ users. Most of our sites are less than 25 users... Might be that a
10 user site would want NT as opposed to Pro. Who knows? My basic premise
has always been to make my job as easy as possible!
--
Richard Ginsburg can be reached at:
e-mail...: mailto:compass_...@yahoo.com
internet.: http://www.fawnridge.com
telephone: 908.236.2334
fax......: 908.236.2109
Morph <mo...@softhome.net> wrote in article
<6iao0m$h3u$1...@news.u-net.com>...
Luke Webber
do...@modsoft.com (Doug Dumitru) writes:
>Some of our first PicLan installs on R83 were in Australia and New
>Zealand (serial number 3 was an all token-ring LAN in Sydney). The
>number of TE products that have PicLan support is definately over a
>dozen, and the number of Pick hosts running PicLan is estimated at
>well over 5000 (the bundle copies with Pick Systems and GA make this
>number somewhat open for discussion. The actual count of total
>systems is more, but the number using PicLan is probably 4000-6500
>based on surveys that Pick Systems has done).
I guess I don't get out enough <g>. I can honestly say that I have never
seen Piclan working on an end-user site. The only time I *have* seen it
was at a software house, where they'd just taken it out of the box and
were wondering what to do with it.
[snip]
>IP is a very popular standard now. Three years ago, the state of
>affairs was very different. In those days IPX ruled the corporate
>LAN. It may be that IPX is still more popular in corporate LANs, but
>I admin that there is definately a shift toward IP. In terms of
>finding people who know IPX versus IP, the reason you think there are
>more people that know IP is that there is very little you need to know
>about IPX. IPX virtually self-configures whereas IP definately does
>not. Which is "better". IPX is easier to configure, more efficient
>in a local LAN environment, has smaller stacks, etc. Popular
>"non-Unix" protocols such as Windows Network file sharing and NetWare
>services run "better" over IPX than IP (faster, less network traffic).
>This would tend to make IPX a better choice for installations that are
>inherently simple. This is where native Pick systems are sold. Does
>that mean that all systems should run IPX. Definately not. The fact
>that you do not work with them does not mean that there are a lot of
>them out there.
It's really not just the IP vs IPX thing I'm talking about, it's more
the
API. Let's face it, the Internet has ensured that Winsock and Berkely
Sockets own the world. I'm not saying those are good APIs, mind you. In
fact I find them unnecessarily abstruse, and the terminology seems
designed to confuse. Still, if you want to support *any* client software
your little heart desires, Winsock is the name of the game.
>>Of course your Piclan IP product gives you the ability to mix and match
>>as well, but the last time I inquired the price of Piclan with IP in
>>Australia was ruinously high. That may no longer be the case, but I'm
>>really no longer interested in native Pick implementations. My own bias
>>showing through, there.
>PicLan-IP is not "freeware", but I do believe that it is reasonably
>priced. Telnet support into native Pick hosts costs from 65$/port
>($500/8-ports) to $35/port ($1100/32-ports) and lower depending on
>system size. This pricing has also been static since product launch
>so I am not sure where your "ruinously high" description comes from.
I believe the Australian pricing was considerably higher than that. IAC,
it was a long time ago that I enquired.
>>It may be I came by my aversion to proprietary solutions by way of Smile.
>>Anybody remember Smile on Sanyo/Icon? Probably way too many.
>Unfortunately, I do. I also wrote some of the Smile code.
>Considering the timeframe that SMILE (Share Memory Interface Local
>Extension) was developed in, it was amazing stuff. For a while, an
>ICON Unix system talking to a PC with a SMILE target card was the
>fastest PC disk subsystem that you could buy and Icon sold quite a few
>of these "disk servers" into the NetWare market. Did this make the
>SMILE solution a "bad" choice. Not any more than paying $50K for an
>external RAID subsystem that can now be had for $2K. The truth is
>that you should consider your use of any technology in terms of it's
>value and longevity (remember that all computer solutions are obsolete
>before they actually ship). Regardless, a proprietary solution may
>still be the best choice if it works and the "standards based"
>solution does not. Also remember that a "standard" today may be cast
>aside tomorrow (just think about all of the false starts that
>Microsoft has put us through (OS2, OLE, NetDDE, ...).
... and BlackBird, BoB, VBX, the list goes on. It was exactly those
"false
starts" I was talking about with SMILE. I know at least three sites here
in Melbourne running SMILE and they don't have a big choice of
emulators,
especially since SMILE client support has been left behind in the
16-bit DOS stone age.
>>Coff! Why VB, in Heaven's name? <g>
>Why not VB. Quick development. Less possibility of obscure GPF type
>bugs. Sure performance is a little less than optimal, but were
>talking terminal emulation here. Saying "why VB" is like saying "why
>Pick/BASIC" instead of C++.
OTOH, there's always the OCX Hell and the 1Mb runtime DLL. I don't love
C++ much either (crappy syntax). Delphi is the One True Tool for native
Winblows programming. ;^)
>There is even a jBase port of PicLan-IP in the works. Before you
>start asking why, realize that PicLan-IP is intended to let you manage
>internet tasks without ever leaving the Pick environment. The best
>example of this is our programming interface for web applications.
>PicLan-IP implements "active server pages" with embedded Pick/BASIC
>code stored directly in HTML documents. No CGI, ODBC, or other layers
>of any kind. Just fast, event-driven Pick code.
I haven't done anything with ASP myself. Knowing their history, aren't
you worried about committing to a relatively Microsoft standard. <g>
>How quickly you dismiss the complexity of some hosted environments. I
>am not-so-fondly reminded of a system running here that had to have
>NT-Server reloaded (for no apparent reason by the way). The process
>of installing NT, service packs, optional add-ons from Microsoft,
>third-party products, etc. took a total of 17 system boots and the
>better part of a day to perform. And the sad thing is that I don't
>think it could have been automated much better. I also do not think
>this is an exageration. I have talked with a number of people who's
>experience with NT is "load and configure it correctly the first time
>or you will have to format the drive and start over to get a stable
>install". Remember that native Pick is 6-8 floppies (PicLan-IP is
>only 2 floppies including TELNET/HTTP/SMTP/POP3) versus Win95/NT which
>is most of a CD.
It may seem an obvious suggestion, but did you ever consider backing the
thing up to tape? I expect it would make recovery simpler.
BTW, if the floppy count is important, how do you handle the fact that
you small, simple VB app has to be distributed on more floppies than
Piclan itself? ;^)
In any case, I'm no real NT advocate. As you pointed out, the thing has
to
be rebooted every time you change the simplest setting, which is not a
good qualification for a server platform. I'd much prefer to go Unix
myself, but not native. Apart from anything else, it's too hard to find
vendors willing to commit to long term support of native Pick
implementations.
>Also the concept of "load other DBMSs and applications" should strike
>fear into any system administrator with NT. The easiest way to insure
>an unstable NT system is to run multiple applications on it unless you
>are very careful.
Mebbe so, but that's still NT we're talking, so I'll happily agree with
you. The NT answer would usually be to have two servers side-by side and
hope that if they want to share data that the software responsible
doesn't
suck entire tables acrosss for every simple query <g>. I don't mind
monolithic systems myself.
Cheers,
Doug Dumitru
lu...@oberon.sub.net.au (Luke Webber) wrote:
>do...@modsoft.com (Doug Dumitru) writes:
>
>>*** START OF ANOTHER AD ***
>
>>If you are "really desperate", you can actually run PicLan on top of
>>SMILE. This lets you use all of the PicLan TE products and even the
>>PicLan TELNET Gateway if you are really desperate. I am not saying
>>that this is the "best" solution (a boat in a large lake is probably
>>better at this point), but it may be at least slightly better than the
>>current state of affairs.
>
>>*** END OF ANOTHER AD ***
>
>It's not TE's they're desparate for. I added support for SMILE to my DOS
>TE (LikeWyse+) long ago. What they really need is support for 32-bit
>client OSs.
PicLan for SMILE consists of a DOS executable that runs on a single
system with a SMILE target card. It advertises itself as a standard
PicLan host over ethernet or whatever type of network you are using
(assuming that you have a Novell IPX driver loaded). The actual
clients run the standard PicLan client which includes support for DOS,
Win3.1, Win95, and WinNT. Only the single system with the SMILE
target has to run DOS. The rest of the users can run Win32.
You can also run the PicLan TELNET Gateway on one of the clients to
get TCP/IP TELNET support. This then becomes a three-step scenario
(Pick to SMILE to TELNET Gateway to Client), but performance should
still be pretty good. The apparent limit of PicLan on SMILE appears
to be about 80 users. After that you start to run out of DOS-mode
memory on the gateway system. SMILE has an absolute max of 126 ports
+- (I think).
>>>I haven't done anything with ASP myself. Knowing their history, aren't
>>>you worried about committing to a relatively Microsoft standard. <g>
>
>(I meant tp say "relatively *new* Microsoft standard" of course.)
>
>>What Microsoft Standard. "active server pages" in the PicLan-IP web
>>server are completely controlled by PicLan-IP. IIS is not involved at
>>all. Also the PicLan-IP active server pages use Pick/BASIC and not
>>VB/script.
>
>Maybe you should watch your terminology. You don't want Billy's lawyers
>after you for pinching their trademarks. Care to expand on how this works?
>I mean functionally; I wouldn't expect you to give away any secrets.
I'm not too worried about Microsoft's claim on things like Active
Service Pages. It is just too generic a term to copyright. Anyways,
remember that "Windows" is *NOT* a Microsoft trademark (registered or
otherwise).
The general methodology for active server pages in the PicLan-IP web
server goes as follows:
When the web server gets a request for an HTML web page, it looks in
the contents of the page for the string "PicLan-IP/Basic". If this
string does not exist, the page is processed as a static page. If the
string does exist, the page is used as a source document that is part
HTML and part Pick/BASIC.
An example, is the easiest way of looking at this (I usually do not
write HTML by hand, so excuse any syntax errors).
---------------------------------------------------------
<HTML>
<HEAD>A PicLan-IP Active Server Page</HEAD>
<BODY>
The time is currently |T.VAR|.<P>
The contents of attribute one is |D<1>|<P>
<PRE>PicLan-IP/BASIC | |
T.VAR = TIMEDATE()
OPEN 'DATA.FILE' TO FILE.VAR ELSE
CALL PLW.PAGE('ERR.HTM','','')
RETURN
END
READ D FROM FILE.VAR , 'TEST.ITEM' ELSE
CALL PLW.PAGE('ERR.HTM','','')
RETURN
END
</PRE>
</BODY>
-----------------------------------------------------------
This page, when accessed, should display two lines of plain text:
The time is currently 20:42:00 30 APR 1998
The contents of attribute one is John Doe
Here is what the syntax means:
o The PicLan-IP/BASIC line tells the web server where the
block of executable BASIC code starts. The code continues
through the end of the current HTML paragraph. You usually
put Pick/BASIC source code in a <PRE> paragraph because it
is hard to read indented source code in a proportional font.
o The | | characters after PicLan-IP/BASIC define the start and
stop characters that are used to delimit insertion points.
You can use any characters that you wish provided that they
do not interfere with other elements in the page.
o The |T.VAR| is an example of a simple insertion point. The
value T.VAR will be merged into this point when the page is
accessed.
o The |D<1>| is an example of a slightly more complex insertion
point. This shows the ability to insert any Pick/BASIC
statement that evaluates to a string.
Underneath, the PicLan-IP web server is doing a lot of dirty work for
you. First, all page accesses are "server-side cached". This means
that the process of deciding if a page has Pick/BASIC embedded in it,
etc., is handled only when the page is changed. This allows most page
accesses to run without requiring extensive pre-processing. When a
page is accessed the first time, the proceedure is something like:
o The HTML text is split into N+1 segments where N is the number
of insertion points. In the above example, the HTML text would
be split into three segments and stored in a Pick item on three
attributes.
o The Pick/BASIC code is used to build an external Pick subroutine
that is then pre-processed and finally compiled and cataloged with
the standard Pick/BASIC compiler. The end of this subroutine has
a machine generated merge concatenate opertion that actually
merges the variable text with the static HTML data. In this
example it would look something like this:
DIM A(3)
DIM B(2)
B(1) = T.VAR
B(2) = D<1>
MATREAD A FROM CTRL.FILE , CTRL.ID ELSE STOP 'X'
RES.PAGE = A(1) : B(1) : A(2) : B(2) : A(3)
There is actually a little more that happens here because of
having to deal with HTML quoting (converting a < into <) but
you should get the idea. The good part of this is because the
code is actually generated into compiled code, the run-time
performance is typically better than if you hand-coded the same
proceedure.
This illustrates one of the things that I like most about Pick. Pick
is one of the few environments where an applications program can
efficiently generate application source code, compile that code, and
then run it on the fly. Perhaps this is why 4GLs are so easy to
implement in Pick.
If you want to see more detailed examples of this, go to
http://piclan.com and look at some of the examples that are posted.
>Cheers,
>Luke
Nick
Morph wrote in message <6iao0m$h3u$1...@news.u-net.com>...
Nick
Agreed... Once my user count approaches 12+ I force the issue to a small
RS6000..
Morph wrote in message <6iao0m$h3u$1...@news.u-net.com>...
>
>Richard Ginsburg wrote in message
><01bd7425$b01dd900$36e8...@compass.blastnet>...
>
><snip>
>
Michael Talbot-Wilson
In article <luke.893914879@oberon>, Luke Webber wrote:
>And naturally when Pick Systems gave us support for mixed case in BASIC
>they sneakily put the support into the COMPILE verb but not the BASIC
>verb. What the ...? <g>
Luke, this distinction's been around as long as I have (but probably
not as long as you have, old chap:). It was in OA/RT nine years ago,
and if my memory isn't playing tricks it was on ADDS Mentor a dozen
years ago, so I assumed it was R83.
If you want to compile case-insensitive, use COMPILE. If you want
to compile case sensitive, use BASIC. In other words, you get a
choice. Where's the problem?
Personally, I use BASIC. Exclusively. I think that the all-lower-
case code that came out of Pick Systems was unreadable shit. But
that's just me.
--Mike
Richard Ginsburg
Nick,
12+ USERS??? What does a, let's say, 15 user RS6000 system cost the end
user? And maintenance?
Soup to nuts, a 15 user PC based system with a 525mb tape backup, tapes,
16 serial ports, an Ethernet card, and AP-Pro with Pic-Lan is around $8000
to the end user.
--
Richard Ginsburg can be reached at:
e-mail...: mailto:compass_...@yahoo.com
internet.: http://www.fawnridge.com
telephone: 908.236.2334
fax......: 908.236.2109
Nick <nqu...@ibl.bm> wrote in article
<6icctp$2e3$1...@news0-alterdial.uu.net>...
Nick
Richard,
Yes... but what is the MTBF on it's components,,,,, doesn't PC mean PERSONAL
COMPUTER...
If a client is going to use a computer system for a 'mission critical'
application then the 20K for a small RS6000, with 750 per year in mantenance
should be our first offer... let them downgrade it, not us. What price is a
good night's sleep for me as the consultant.. I think we've all gone pretty
nuts in this PC world... price is not everything, especially on hardware. I
don't forget that the first 'windows' which worked has the name '95' right
on it.
Best regards,
Nick
(still going to call for the demo when I get my clients together in one
room!)
Richard Ginsburg
Nick,
Do you really think that the RS6000 is built any better than a PC? Can you
really justify the huge difference in price?? I've got over 100 systems
running out in the world with PC's of all shapes and sizes. Sure
occasionally one goes bad, but I would guess that occasionally an RS6000
sputters and dies as well. For $750 per year a customer could buy a spare
computer and keep it in the closet. Then when the old one blows up, he
moves the peripherals over restores his OS and File-Save and bang zoom he's
back in business...
--
Richard Ginsburg can be reached at:
e-mail...: mailto:compass_...@yahoo.com
internet.: http://www.fawnridge.com
telephone: 908.236.2334
fax......: 908.236.2109
Nick <nqu...@ibl.bm> wrote in article
<6id13p$fdv$1...@news0-alterdial.uu.net>...
Nick
Yup... Please notice the first 'qualifier' (12 Users) in my first response
on this thread.
I like this one because I've 'followed' a few competitors over the past
'novell' years with xbase, btrieve solutions that are nightmares.... not
because of the competitiors APPLICATION but because of my competitors
refusal to understand that the first responsibility of any consultant is to
teach...
If we spent as much time learning how to put our good work into supportable
and safe environments as we do trying to 'save' a few bucjs we would all
have a better repin this trade.
Once that level of usage (12+) is breached the incremental five year (cost
of ownership) hourly cost per user is pretty insignificant.
Mctun is wooried that we are fighting this out over the VAR vs Retail
thread... I don't beilieve that any difference exists in the target market..
only in the mindset we use as professionals to deal with that market..
Best regards,
Luke Webber
Hi Mike.
ta...@atom.forensic.sa.gov.au (Michael Talbot-Wilson) writes:
>Luke, this distinction's been around as long as I have (but probably
>not as long as you have, old chap:). It was in OA/RT nine years ago,
>and if my memory isn't playing tricks it was on ADDS Mentor a dozen
>years ago, so I assumed it was R83.
If that's the case (no pun intended), it's an ADDS mistake that Pick
Systems embreaced, but I'm jiggered if I know why. It certainly isn't R83
because R83 never allowed lowercase keywords or variable names.
>If you want to compile case-insensitive, use COMPILE. If you
want >to compile case sensitive, use BASIC. In other words, you get a
>choice. Where's the problem?
I still say it's a mistake, mainly because in R83 the BASIC and COMPILE
verbs were synonymous, and to suddnely make one different from the other
in this way is a foolish way to draw the distinction. It would have been
far better to allow the programmer to establish a global default and then
to modify the default behaviour by means of an option on the command-line.
Better yet, the option should be capable of being specified in the
program itself by means of some kind of compiler directive, such as $CASE
ON/OFF or $OPTION MIXEDCASE/UPPERCASE.
In effect you *can* do some of this, simply by overwriting the BASIC verb
with the COMPILE verb, but that's probably a bit of a cop-out. FWIW, I
would tend to use the COMPILE verb except that BASIC has always been
preferred because it saves typing.
>Personally, I use BASIC. Exclusively. I think that the all-lower-
>case code that came out of Pick Systems was unreadable shit. But
>that's just me.
It's not just you, because I happen to agree. OTOH, it may be that the
"structurists" at Pick Systems helped to make this stuff unreadable with
programs that look like...
gosub xxx
gosub yyy
stop
xxx ...
return
yyy ...
return
Yuck!
FWIW, I think the behaviour of COMPILE is just fine, because it will
compile the old uppercase-only code as well. I still use BASIC most of
the time though, partly because it's shorter and partly because I'm an
old dog. It only ever bites me if I use the standard INCLUDEs from
DM,BP,INCLUDE.H with their mixed-case identifiers.
Hey, I'd have hated to have to write mixed-case on an AWA VTE-6 terminal.
They didn't have a caps-lock key, and it took multiple keystrokes to
change the caps state. <g>
Robert R. Joslyn
Luke Webber wrote:
> * by his employers, Luke Webber Consulting Services *..
I'm even lazier! I wrote a small basic program to change all of Pick's BP and
the includes to upper case.
Bob
Jim Idle
Doug,
I am not sure how current your information is, but requested this
information from Microsoft well after the beta. Their answer was taht telnet
sessions are actually real users, wheras TCP server connections are not
considered so. If you are installing systems assuming that it is OK wiht
Microsoft, then I urge you to double check with them, rather than assuming
so. I will also re-ask the question and see if they have changed their mind.
The NT Kernel and Workstation, while being the same code, do not actually
run quite the same. In theory you coudl go through the regsitry and make
them do the same thing (there is a web site about this kind of stuff), but
right out of the box, NT Server is desgined to give you better throughput
than a workstation for some things.
Jimi
Doug Dumitru wrote in message
<3548185b...@news.alsv1.occa.home.com>...
>"Jim Idle" <noth...@spam.com> wrote:
>
>>...
>>
>>I should also qualify my last statement by the way, because I beleive that
>>Microsoft's official position on this type of thing, is that you can make
10
>>connections like telnet to an NT workstation, then they expect you to buy
NT
>>Server. Seems a fairly reasonable stance to take to me, although it means
>>that an 11 user system costs more than 1 more jBASE license of course ;-).
>
>>Jimi
>If you want to run a
>mail server, web server, or Pick server on NT workstation, the sky's
>the limit (actually 2 processors is the limit).
>
PS: I would not mind being wrong about this at all ;-)
Doug Dumitru
"Jim Idle" <noth...@spam.com> wrote:
>Doug,
>
>I am not sure how current your information is, but requested this
>information from Microsoft well after the beta. Their answer was taht telnet
>sessions are actually real users, wheras TCP server connections are not
>considered so. If you are installing systems assuming that it is OK wiht
>Microsoft, then I urge you to double check with them, rather than assuming
>so. I will also re-ask the question and see if they have changed their mind.
I stand corrected. Microsoft apparently does restrict Windows NT
workstation to "workstation only" applications. More information is
available at:
http://www.microsoft.com/ntworkstation/info/ntlicensing.htm
On the other front, Windows NT Server specifically excludes MultiValue
type accesses as counting against your Windows NT "Client Access
License":
http://www.microsoft.com/products/prodref/427_faq.htm
I have no idea what is written down concerning using Windows 95 as a
"server".
I also had a very hard time finding the actual Windows NT "EULA" on
Microsoft's web site. There were references to it, but I could not
locate the actual document. I would also tend to use what is written
in the EULA as gospel and not what is in a Microsoft summary if at all
possible.
I had some things to say about Microsoft's "reasoning" for this, but
repeatedly hit the delete key on second thought.
>The NT Kernel and Workstation, while being the same code, do not actually
>run quite the same. In theory you coudl go through the regsitry and make
>them do the same thing (there is a web site about this kind of stuff), but
>right out of the box, NT Server is desgined to give you better throughput
>than a workstation for some things.
The main difference in performance is how process timeslices are
handled. Workstation gives more priority to the forground task and
runs shorter timeslices elsewhere. This gives better "interactive"
responsiveness to desktop applications. Server give more equal
timeslices to forground and background tasks and lets CPU intensive
tasks run longer without being interrupted. This makes overall
throughput of server better, but actually increases latency and
apparent "jerky" responsiveness. I personally always run server, not
because of any performance benefit, but because I am used to having
access to all of the features (after all, I pay the "big bucks" for
the developers license, I might as well use it).
George Shaunfield
> >not as long as you have, old chap:). It was in OA/RT nine years ago,
> >and if my memory isn't playing tricks it was on ADDS Mentor a dozen
> >years ago, so I assumed it was R83.
>
> If that's the case (no pun intended), it's an ADDS mistake that Pick
> Systems embreaced, but I'm jiggered if I know why. It certainly isn't R83
> because R83 never allowed lowercase keywords or variable names.
>
I don't remember about keywords, but R83 did allow lowercase variable
names and mixed-case variable names. VARIABLE, Variable, variable were
all acceptable variable names. However, because R83 was case sensitive
each of the three were separate and distinct variables (as is the case
if a program is compiled using the BASIC verb in AP). That is also true
in AP if one uses the COMPILE verb but the program contains the
statement "casing on". And, case sensitivity can be turned on for the
current port by issuing the TCL command "case-on".
> >If you want to compile case-insensitive, use COMPILE. If you
> want >to compile case sensitive, use BASIC. In other words, you get a
> >choice. Where's the problem?
>
> I still say it's a mistake, mainly because in R83 the BASIC and COMPILE
> verbs were synonymous, and to suddnely make one different from the other
I was never aware of a COMPILE verb in R83. However, checking the R83
manual did mention it in one sentence. Don't have R83 running any more
to actually check it.
> in this way is a foolish way to draw the distinction. It would have been
> far better to allow the programmer to establish a global default and then
> to modify the default behaviour by means of an option on the command-line.
>
> Better yet, the option should be capable of being specified in the
> program itself by means of some kind of compiler directive, such as $CASE
> ON/OFF or $OPTION MIXEDCASE/UPPERCASE.
>
See above comments about case sensivity choices in AP.
[SNIP]
> --
> Luke Webber
>
To me lower case text is far easier to read. Perhaps similiar to typing
an email in all upper case is like screeming at someone.
I use to write Pascal and Modula2 code in lower case or mixed case and
run it through a prettyprinter that converted keywords only to all upper
case for readability/maintainablilty. Case sensitivity when typing mixed
case for variables can be tricky if you happen to miss a capital some
place.
George Shaunfield
AccounTron
JDB
Come on guys! This thread has been interesting if not opionionated but I
drecall creating a verb in R83 called compile as a synonym for basic.
Compile was originally shunned because the snobbish felt that creating
pcode was not the same as compiling. Compiling is what the Pick
Assembler did. A rose by any other name will wither as quickly. The long
time blessing (and trap) of Pick has been the ease of creating synonyms
for data fields, files as wll as actions. The name is not the thing.
After all they could have made it so BASIC was case sensitive and Basic
wasn't.
Thanks for all the good read in this thread anyway.
> I still say it's a mistake, mainly because in R83 the BASIC and COMPILE
> verbs were synonymous, and to suddnely make one different from the other
Doug Dumitru
JDB <smal...@ntr.net> wrote:
I just had a look at the SYSPROG MD and NEWAC file for R83 3.1 on the
PC. COMPILE is present and is identical to BASIC.
Michael Talbot-Wilson
In article <354FED...@accountron.com>, George Shaunfield wrote:
>Luke Webber wrote:
>> >choice. Where's the problem?
>>
>> I still say it's a mistake, mainly because in R83 the BASIC and COMPILE
>> verbs were synonymous, and to suddnely make one different from the other
>
>I was never aware of a COMPILE verb in R83. However, checking the R83
>manual did mention it in one sentence. Don't have R83 running any more
>to actually check it.
>
>> in this way is a foolish way to draw the distinction. It would have been
>> far better to allow the programmer to establish a global default and then
>> to modify the default behaviour by means of an option on the command-line.
My impression (from looking at the "*" items in ERRMSG) is that it is
fundamentally case sensitive, i.e. the parser looks for keywords in
caps.
So COMPILE would be a pre-processor that does gross things to the text and
then hands it to BASIC.
This would explain, I think, why there are two separate names.
Perhaps someone who saw Ken Sims' early versions could comment.
--Mike