Native Pick System Programmers

#31

My first Pick box was an ADDS Mentor in Tampa Florida circa 1982.

On Sep 4, 5:28*am, hbkeultjes <hbkeult... (AT) gmail (DOT) com> wrote:

Quote:

Last night I was prompted by a link to read one of Henry Eggers' CDP
posts which makes me curious; how many programmers are still around
who at one time worked on *Native* Pick and its variants like ADDS,
Microdata, Ultimate and such?

Henry Keultjes
hbkeultjesatarthlinkdotnet
Microdyne Company
Mansfield Ohio USA

#32

On Sep 14, 11:50*pm, Douglas Tatelman <doug... (AT) pickteam (DOT) com> wrote:

Quote:

My first Pick box was an ADDS Mentor in Tampa Florida circa 1982.

On Sep 4, 5:28*am, hbkeultjes <hbkeult... (AT) gmail (DOT) com> wrote:

Last night I was prompted by a link to read one of Henry Eggers' CDP
posts which makes me curious; how many programmers are still around
who at one time worked on *Native* Pick and its variants like ADDS,
Microdata, Ultimate and such?

Henry Keultjes
hbkeultjesatarthlinkdotnet
Microdyne Company
Mansfield Ohio USA

My first job was with ESCOM in Seattle in the late '70s. I remember
working on a really big MicroData with 64k of memory and an amazing 10
megabyte disk -- we had 10-12 people beating on it.

I believe we worked with a product called "Thor" (which was supposed
to be a 4th gl right? but was pretty much something that
documented)... and we programmed MMC... DMC... FMC (I think were their
initials). I remember getting this cool little box called ADDS Mentor
with serial number 6.

Even though I have always been an applications programmer... I have
certainly known a lot of native programmers... met Dave Otsby (sorry
about the spelling) and his Advanced Revelation... met the guys who
developed the IBM Series One o/s (thought Pick would rule the world
then... getting on an IBM box)... met the guys who did Prime
Information... Seattle was an amazing place to be back then
(especially for a kid who worked long hours, got paid dirt, and had a
lot of fun).

David

#33

On Sep 7, 2:35*pm, hbkeultjes <hbkeult... (AT) gmail (DOT) com> wrote:

Quote:

My objective is the have an ARM-64 based box that runs an Exo-kernel

Does ARM-64 exists? My understanding is that ARM is looking at a
segmented scheme
so the O/S can access more the 4Gb of memory but individual processes
are still limited
to the 4Gb limit. Perhaps ARM-64 means something completely different
to my understanding?

To combine the OS and the database would be a retrograde step IMHO.
R83 was very picky about
which disk controllers, I/O cards and tape devices it would work with.
By v3.0 they at
least allowed you to bypass their 'close to the metal' disk routines
and use the standard BIOS interrupt (14?).
When I first worked on UniData on Unix it was a revelation (no pun), I
could Xmodem files around, you could
use these new fangled ethernet networks to move files FAST when
setting up new clients machine.
Why go back?

#34

On Sep 6, 2:43*am, BobJX <bobjos... (AT) hotmail (DOT) com> wrote:

Quote:

On Sep 5, 8:27*pm, hbkeultjes <hbkeult... (AT) gmail (DOT) com> wrote:

On Sep 5, 4:02*pm, Tony Gravagno <nos... (AT) nospam (DOT) invalid> wrote:

hbkeultjes wrote:
sdavmor wrote:
I think most of them have picked up their toys and long since gone
home (from cdp).
Why use something, like Pick
Virtual Assembler when those who can use those tools are a tiny tiny
tiny fraction of those who know how to use Open Source Assembler and
high-level languages to write systems code?

Because the other languages don't work within the Pick environment or
on Pick data like PVA. PVA is used exclusively inside the DBMS, and to
my understanding, D3 is the only platform left where third-party
developers can use PVA.

This is about building a new system, not a virtual system, and thus it
would use an assembler for the specific processor which in this case
would be ARM-64.

Once again I don't even understand what this thread is about. *There
seems to be confusion between "Native" Pick and PVA:
- Native Pick is any system that doesn't run over a native OS because
it _is_ the native OS.

You are exactly right so Native Henry would-be-the-OS-and-the-Database
and whatever else, just like Native Pick.

This includes both the old software and > firmware machines, and AP/
Native and AP/Pro.

- Native Pick became obsolete when Pick was ported over an OS layer,
namely Unix and then Windows.

Obsolete is, of course, relative because our Native Pick works just as
good as it ever did, but the reason I am looking for something better
is because in character mode I cannot do all the things I want to do
yet I want to have a single integrated system just like Native Pick
is.

- Native Pick used PVA inside the DBMS, but the current D3 uses
virtually the same PVA. *Usage or non-usage of PVA have nothing to do
with whether the platform is native or not because it's a step removed
from the platform layer.

Whereas I don't care about that virtual layer, don't want it, don't
need it because I want to run on only one processor, an ARM-64 when
that becomes available.

- The language used under the MV environment, to integrate the DBMS
with the OS (the platform layer), is OS-specific assembler and/or
C/C++, depending on the platform, but this assembler is completely
unrelated to PVA.

In my case the assembler will be ARM-64 specific and not Linux
specific. *That assembler will build the "Henry" system code on top of
which application code runs which application code will be written in
just one language, *a type of Basic that will have new additions to do
whatever needs to be done. *Remember, any application can do only what
can be reflective of the instruction set so if you need to do
something that a certain Basic cannot do, the typical answer has been
to find a different language can do it and thus you have both a
solution and a problem. *I prefer the solution without the problem.
Pick did pretty amazing things with DataBasic. *I believe that the
"Henry System" can do pretty amazing thins with "Henry Basic".

By definition, PVA is "virtual" and not tied to the machine itself.
This is why PVA can run over a variety of hardware/software platforms..
It's just like emulator programs where you can play Atari or video
arcade games on your PC, because the assembler for those games (the
ROM) is parsed and processed by a lower tier that actually executes
the instructions.

Yes, indeed. *The only way to get work done on a processor is to use
the instruction set, with machine language or with a processor
specific compiler.

PVA is completely unique to the Pick environment. *It's based on
registers, bits, and bytes just like any BAL but all of the data is
resident in frames within the environment, not in CPU/memory
registers.

What am I missing? *Is there a hard and fast reason that other systems
could not work like that without any PVA, * Ultimately the chip has to
this so it is just a matter of instructing it to do it. * That nobody
else has ever done that does not mean that it is impossible. *If the
public domain concept of Pick can be implemented using a PVA it can be
implemented without the PVA. and without a firmware board but in a SoC
ARM implementation, programmable logic might be more efficient for
such an implementation than software.

**Other languages cannot access the in-frame data which is

operated upon by PVA (well, I could do it if someone put a gun to my
head) and PVA cannot be replaced or augmented with another language.

I hope that I explained this well enough now to convey that PVA does
not matter. *My first objectives of this threat was to get people buy
into the idea of a better Pick than Native Pick that was just as good
(can I say dear to us) as Native Pick. The other objective was to
convey the futility of trying to build on the old foundation because
there are not enough people left that know how to lay those old
"bricks". *My objective is to have the same system with increased
functionality and use Open Source "bricks" that literally thousands of
people all across the globe know how to lay. *The third objective is
to inspire those who know Pick, at whatever level, to suggest pieces
that might work to do this but all I get is suggestions of doing it
the way I don't want to do it. *C'est la Vie!

The notion of replacing PVA with another assembler is pure fantasy -
and once again without some definition of a usage case for doing so

You might be right but it does not matter because no type of PVA is in
my plans.
.

There are only a few products left in the MV market that are
completely reliant on PVA, and so far it has not been cost-justified
for them to transition away from it.

Until I would see the numbers I could not comment on that.

If you want an environment where PVA does not exist, consider QM or
one of the other platforms not descended from R83.

Correct me if I am wrong but I believe that QM is still strictly an
ASCII environment that runs on top of Linux (or whatever) and thus is
not a single integrated platform that supports a modern browser that I
am looking for.

Henry Keultjes
Mansfield Ohio USA

T- Hide quoted text -

- Show quoted text -

Long post, long answers. But if the bottom line is using a browser
there is no issue, if the bottom line is using a mouse then use the
Accuterm UI. *But if the bottom line is running a business then I
quote Dick "The mouse is not a business tool."
Bobj

He had no use for graphics either. Had a long argument with him at a
meeting at the La Quinta or Wooleys in Santa Ana many moons ago. I
think that he was wrong on both, as long as you don't ignore the
central data entry problem that is business.

#35

On Sep 4, 8:28*am, hbkeultjes <hbkeult... (AT) gmail (DOT) com> wrote:

Quote:

Last night I was prompted by a link to read one of Henry Eggers' CDP
posts which makes me curious; how many programmers are still around
who at one time worked on *Native* Pick and its variants like ADDS,
Microdata, Ultimate and such?

Henry Keultjes
hbkeultjesatarthlinkdotnet
Microdyne Company
Mansfield Ohio USA

I go back to the Microdata, Ultimate days. There's a few of us
still around.

4 programmers in the South Florida area are looking because we work
for a CD/DVD distributor that is downsizing. CDs and DVDs are going
the way of records, replaced by digital downloads. 3 of us have been
at this company for 14 years. At one point we had 14 programmers,
now down to 4, just had a round of lay offs and lost another
programmer. In a few months, there will be another round and we're
openly looking.

If anyone has leads please respond. We run Unidata on HP Unix.
Program sales (distribution), accounting, returns, web sales, EDI,
labels (Sato, Zebra), and work with Unix (file systems).

Thanks
Robert Viands
Alliance Entertainment
Coral Springs Florida

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Native Pick System Programmers

comp.databases.pick comp.databases.pick

Re: Native Pick System Programmers - 09-15-2010 , 12:50 AM

Re: Native Pick System Programmers - 09-15-2010 , 08:54 AM

Re: Native Pick System Programmers - 09-17-2010 , 12:00 AM

Re: Native Pick System Programmers - 09-18-2010 , 03:02 AM

Re: Native Pick System Programmers - 10-05-2010 , 01:05 PM