debugging Pick
Dawn Green
database.
My client is using software written for a Pick database 8 years ago.
They purchased it for $200K and paid yearly maintenance support. They
say that a one time fee was paid to some sort of escrow fund should
something ever happen to the programmer. This would enable them to
get access to the source code. Now, the programmer has sold the code
and company. The sale would not be a problem except that the code has
three flaws. Two, a general format error which seems to be OS based,
and an "out of bounds error" which is tied to some accounting aspect
of the software, are too complex for my client's programmers to debug
without the original programmer's help. The third problem is from a
failed or nonexistent database locking function which, when a record
is accessed simultaneously by two or more users, causes the system to
crash.
The original programmer has said he will not support the software and
help in getting the system back up after crashes after August of this
year which leaves my client in a real mess when the system fails
again. Attempts at the getting the source code have failed and my
client's programmers, who seem relatively familiar with the system,
believe that the data dictionary is so poorly written/constructed and
the code flawed that they wonder if getting access is worth it. The
new acquiring company, well aware of the lack of support, is now
trying to sell my client a very expensive non-Pick replacement. My
client feels under the gun to make a decision.
My questions are:
1. Do you believe my client has the legal right to the source code so
that they may find a programmer to debug the software? What are your
thoughts on the lack of support?
2. Generally speaking, one can debug any source code. However, Pick
seems so obscure that I have no idea if it can even be done. What are
your thoughts here? Also, if the programmer refuses to turn over the
code, how difficult is it to reverse compile?
3. How difficult is it to extract the data for use with custom
software?
Again, please accept my apologies for my ignorance surrounding Pick.
I would appreciate any thoughts or opinions you have to help guide me.
Dawn Green
Ed Sheehan
"Dawn Green" <gr...@thunderdata.com> wrote in message
news:bbef4ee4.02031...@posting.google.com...
> First of all, please excuse my lack of knowledge about the Pick OS and
> database.
>
<snip>
>
> My questions are:
> 1. Do you believe my client has the legal right to the source code so
> that they may find a programmer to debug the software? What are your
> thoughts on the lack of support?
Your clients certainly have a legal interest in the source code. A copyright
attorney can help clarify your client's rights here.
There must either be some bad blood between programmer and client, or the
programmer has expended his incoming revenue stream and now must support the
product free, and wants out from under. Yes, it's appalling, but not that
rare.
> 2. Generally speaking, one can debug any source code. However, Pick
> seems so obscure that I have no idea if it can even be done. What are
> your thoughts here? Also, if the programmer refuses to turn over the
> code, how difficult is it to reverse compile?
With the source code, a competent and experienced analyst can get to the
bottom of these problems. To a Pick programmer, the system is not obscure.
The data dictionary you speak of is most likely used only for reporting
purposes; the business rules are probably contained in the BASIC source code
and control tables.
There is a source for a reverse compiler. See:
http://www.malone.net/Pages/Sales/Un-Basic/Un-Basic_Main.html
He supports several platforms. I have used the product, and it performs very
well.
> 3. How difficult is it to extract the data for use with custom
> software?
You'll likely need a programmer to get the data presented properly for
export. Depending on the needs of the destination host, the export can be
fairly simple or quite complex, requiring special programs to be written to
format the data. Your clients programmers can help in defining the export
requirements.
>
> Again, please accept my apologies for my ignorance surrounding Pick.
> I would appreciate any thoughts or opinions you have to help guide me.
You'll find a lot of free help here, but it sounds like you'll need some
hired help to recover completely.
>
> Dawn Green
Ed
Richard A. Wilson
some other things you can do
(by the way from your website it looks like you are in Corpus Christi
Tx)
so I assume the client is down that way.
If the software was placed in escrow then they definitely
have a right to the source code. especially if the new company
is trying to kill of the old software and only purchased the
software for its client base.
The Gfe's can be normally be solved without source code being
loaded on the system. It is a data/file structure problem
Record locking correction would require access to the source code.
Exporting the data is fairly easy these days but does require
an understanding of files/dictionaries. But any pick/MV consultant
should be able to get a handle on this in a couple of hours.
And finally if the new company is unwilling to support the software
line up the lawyers, your client has been paying maint. fee etc
for years and have a right to support. It all depends on what
the new company purchased.
Note: I am not an attorney but am familiar with your rights
within Texas (lived/worked/consulted there) since 1979
--
Richard A. Wilson
Lakeside Systems
Smithfield, RI, USA
rwi...@lakeside-systems.com
www.lakeside-systems.com
David Knight
It seems to me from reading between the lines that there is a bunch of
panicking going on; which is understandable. However, I suggest everyone
taking some good deep breaths and look at what is really going on here.
Firstly General Format Errors (GFE's) are not caused by the application; but
are a data store inconsistency. Think 'bad block'. Think 'someone turned off
the PC whilst it was writing'. Think 'hardware fault'. Anyway, GFE's are
often easy to fix & should not return unless someone is stupid with the
hardware. But hey, the same would happen to a *nix or M$ system if they were
stupid too. So 33% of the problem is not the application or PICK/D3.
Rainingdata should be able to help fix the GFE if you cannot find anyone
else locally.
I am concerned the client's 'programmers' do not know this already. If they
do not know it, then they are *not* qualified to comment on the system. Just
a lack of knowledge, that's all - but no reason for panic either!
Yes, you should get source either from the Escrow or via the Unbasic
facility from Malone if you cannot get support, because the other problems
should be easily debugged. As for the system crashing when two records are
simultaneously accessed, it could well be overstated. When an unresolvable
lock occurs in PICK, the user's screen who came in second 'beeps' and
refuses to proceed until the lock is resolved. Many users perceive this as a
'crash'. It is not, and is often simply resolvable without data corruption
(usually). I suggest you find out exactly what happens & post it here for
help.
If I'm close to being right, then > 60% of the 'problems' are simply
resolved with a little effort and education. I would have thought the
clients >$200k investment would be far better served by this approach,
rather than dumping it & finding an alternative?
My 2c worth anyway. HTH.
David
"Dawn Green" <gr...@thunderdata.com> wrote in message
news:bbef4ee4.02031...@posting.google.com...
> First of all, please excuse my lack of knowledge about the Pick OS and
> database.
>
<snip>
Ed Sheehan
news:QeRk8.3745$Hz2....@news-server.bigpond.net.au...
> Hi Dawn,
<snip>
> Firstly General Format Errors (GFE's) are not caused by the application;
but
> are a data store inconsistency.
<snip>
Group Format Errors can be categorized in two ways: soft and hard.
Soft ones certainly can be caused by applications. This happens when one a
program attempts a read of a frame while it is being updated by another (or
reentrant copy of the same) program. These go away instantly and cause only
worry, but if two programs are updating the same frame "simultaneously," you
can end up with hard GFE's.
Normally, hard ones are caused either by a hardware "glitch" or by forcing
(thru the use of badly undersized files) the system to "chase links" to the
point of return stacks getting hammered from overflowing.
I haven't seen them crop up for a while now; I guess the halt tolerance of
D3 is getting better.
Ed
David Knight
Being totally 'iggerant' of the internal working of PICK/D3...
<snip>
>
> > Firstly General Format Errors (GFE's) are not caused by the application;
> but
> > are a data store inconsistency.
>
> <snip>
>
> Group Format Errors can be categorized in two ways: soft and hard.
>
> Soft ones certainly can be caused by applications. This happens when one a
> program attempts a read of a frame while it is being updated by another
(or
> reentrant copy of the same) program. These go away instantly and cause
only
> worry, but if two programs are updating the same frame "simultaneously,"
you
> can end up with hard GFE's.
Wouldn't the 'scheduling' part of PICK/D3 handle this so that it is
impossible for 2 frames to be updated simultaneously? I mean, at a real low
level, doesn't everything actually happen serially? So is this an academic
issue or a real one?
>
> Normally, hard ones are caused either by a hardware "glitch" or by forcing
> (thru the use of badly undersized files) the system to "chase links" to
the
> point of return stacks getting hammered from overflowing.
Agreed. I'm thinking R83 here!
> I haven't seen them crop up for a while now; I guess the halt tolerance of
> D3 is getting better.
I've only seen 2 GFE's since moving to AP/D3 from R83 over 10 years ago!
Both were traceable to hardware failures! Yes, I think it is getting better.
Almost non-existant, which I guess was the point of my comment. In practice
they are non-application related.
Thanks for the feedback though.
David
Ed Sheehan
> Hi Ed,
> Being totally 'iggerant' of the internal working of PICK/D3...
>
> <snip>
> >
> > > Firstly General Format Errors (GFE's) are not caused by the
application;
> > but
> > > are a data store inconsistency.
> >
> > <snip>
> >
> > Group Format Errors can be categorized in two ways: soft and hard.
> >
> > Soft ones certainly can be caused by applications. This happens when one
a
> > program attempts a read of a frame while it is being updated by another
> (or
> > reentrant copy of the same) program. These go away instantly and cause
> only
> > worry, but if two programs are updating the same frame "simultaneously,"
> you
> > can end up with hard GFE's.
>
> Wouldn't the 'scheduling' part of PICK/D3 handle this so that it is
> impossible for 2 frames to be updated simultaneously? I mean, at a real
low
> level, doesn't everything actually happen serially? So is this an academic
> issue or a real one?
>
I believe what happens is that process "A" attempts to update a group of
several frames, one or more of which may not be in memory, causing process
"A" to lose its timeslice while the system get the frame from the disk. Then
process "B" updates the same group, and completes the act, having not lost
its timeslice, since the frames are now all in memory. Then process "A" gets
its turn again, and finds the group is no longer the way the process last
saw it, causing it to become veklempt.
I think that if this tug-of-war happens when both processes are updating the
same group, hard GFE's can and do happen. This can be avoided by using
READU's (and the MATREADU and READVU equivalents). This is rare, but does
happen to new and old systems alike, when the READUs are either left out of
the new progs or inadvertently changed to READs on old ones.
You're right, nothing is "simultaneous" on computers!
<snip>
Ed
sdavmor
> database.
Dawn,
at the risk of seeming glib, the issues you reference are fairly trivial to
resolve for competent Pick technicians. I say this with one assumption:
your client wouldn't have been using the software for 8 years if it didn't
generally get the job done. What version of Pick is your client running?
Knowing that would help the CDP brain-trust to help you with specific
answers.
>
> My client is using software written for a Pick database 8 years ago.
> They purchased it for $200K and paid yearly maintenance support. They
> say that a one time fee was paid to some sort of escrow fund should
> something ever happen to the programmer. This would enable them to
> get access to the source code.
We do the same thing with "The Cleaner System". The source has been
escrowed. Revision updates are also escrowed. If we go out of business,
the company's attorneys have standing instructions to contact our customer
base and arrange for the source code to be made available to them.
> Now, the programmer has sold the code
> and company.
Which should not be causing a problem. If it is, then your client might
need to seek the advice of counsel about enforcing the escrow contract.
> The sale would not be a problem except that the code has
> three flaws. Two, a general format error which seems to be OS based,
Almost certainly hardware, but even if it isn't, I'll bet you dollars to
donuts that some professional system administration by a Pick technician who
is competent to administer a Pick dbms will solve the problem. Note that
this may not even be the original programmer: there are many people coding
quite successfully in the MV world who lack in-depth knowledge of things
like staying on top of file-sizing, etc.
> and an "out of bounds error" which is tied to some accounting aspect
> of the software, are too complex for my client's programmers to debug
> without the original programmer's help.
<Thinking out loud>..."Array subscript out of range"...Could that be it?
> The third problem is from a
> failed or nonexistent database locking function which, when a record
> is accessed simultaneously by two or more users, causes the system to
> crash.
Huh? If this is really the case, that this causes the system to crash, then
something is going on at a deeper level than the application code. When was
the last time someone verified the system ABS code? When was the last time
someone ran a CHECK-FILES and watched for errors? However, it may simply be
that the collision occurring between two or more users is just not being
handled gracefully by the BASIC code [no use of the LOCKED condition in the
READU logic]. In this case your client appears to be getting a rather
severe case of "Deadly Embrace". This may be sloppy code at work, but it
could also be a situation where the database file is seriously into linked
overflow. I can see how this, in conjunction with no use of LOCKED could
get the users into such a state of "Deadly Embrace" that an unknowledgeable
sysadmin person might feel the only recourse is to reboot.
>
> The original programmer has said he will not support the software and
> help in getting the system back up after crashes after August of this
> year which leaves my client in a real mess when the system fails
> again. Attempts at the getting the source code have failed and my
> client's programmers, who seem relatively familiar with the system,
> believe that the data dictionary is so poorly written/constructed and
> the code flawed that they wonder if getting access is worth it.
<Loud raspberry> Sorry, but that sounds like pure bunk. Worst case: get
UnBASIC from Software By Malone, and some professional MV consulting help.
Suggestion: an on-site class in AQL [retrieval language/dictionaries] and
general system admin techniques/Pick fundamentals might help your client's
technical staff to better evaluate the system. Without the source code how
can they possibly know that the code is flawed or not?
> The
> new acquiring company, well aware of the lack of support, is now
> trying to sell my client a very expensive non-Pick replacement. My
> client feels under the gun to make a decision.
Don't let them panic. You can probably get all the free advice here at CDP
to help you [them] make rational decisions. If you need more after that
[i.e. on-site or remote-access help] there's plenty of top-notch consulting
talent in this pool <nods>.
>
> My questions are:
> 1. Do you believe my client has the legal right to the source code so
> that they may find a programmer to debug the software? What are your
> thoughts on the lack of support?
If the software was escrowed, and they paid a fee, and the new owner of the
code isn't prepared to provide proper support, then Yes. Are they still
paying maintenance? If so then they should be getting support. If not,
then <shrugs>.
> 2. Generally speaking, one can debug any source code. However, Pick
> seems so obscure that I have no idea if it can even be done. What are
> your thoughts here?
I've seen some badly written and poorly documented Pick-based systems over
the years, but I've never seen one that couldn't be debugged with access to
the source code.
> Also, if the programmer refuses to turn over the
> code, how difficult is it to reverse compile?
Not easy, but certainly straight-forward. See my comment above about
UnBASIC. As with all reverse-engineering tools, caveat emptor is the
watchword. You'll need high-level Pick consulting help, since it seems like
the client's internal staff might not up to the task. This is not a knock
on them,but I have the impression they wouldn't know what they were looking
at.
> 3. How difficult is it to extract the data for use with custom
> software?
Again, not easy, but straight-forward, assuming that you have appropriate
help to understand what you're looking at.
>
> Again, please accept my apologies for my ignorance surrounding Pick.
> I would appreciate any thoughts or opinions you have to help guide me.
No apology needed, Dawn. You did the smart thing by asking for help at CDP.
Keep asking...we'll keep answering. Get more specific, provide code and/or
dictionary examples, and we'll get specific in the answers.
>
> Dawn Green
--
Cheers,
SDM -- a 21st century schizoid man
mvdbmswizard at systemstheory dot net
www.systemstheory.net
www.thecleanersystem.com
Gulraj Rijhwani
<bbef4ee4.02031...@posting.google.com>
gr...@thunderdata.com "Dawn Green" wrote:
> and company. The sale would not be a problem except that the code has
> three flaws. Two, a general format error which seems to be OS based,
Correct. Any experienced Pick maintainer should be able to solve
this problem, which is actually a defect in the infrastructure of
a file, and not directly related to the overlying application.
> and an "out of bounds error" which is tied to some accounting aspect
> of the software, are too complex for my client's programmers to debug
> without the original programmer's help. The third problem is from a
> failed or nonexistent database locking function which, when a record
> is accessed simultaneously by two or more users, causes the system to
> crash.
The bounding error would require source code, in order to locate the
problem, if it is application based. However, as this is an 8 year
installation I would suspect, that the error could be the upshot of
another data corruption, which, again an experienced Pick supporter
may be able to locate and infer a solution for from surrounding data.
The locking error could also be due to a disk corruption "losing" a
compiled object. Unless you come back to tell us that this error
has "always" happened. Again, an experienced support might be able to
"tap into" the system by writing a dummy routine and investigating
that way, but it would be easier with base source to work from. It
may just require that the appropriate routine is recomiled and
re-CATALOGed.
> The original programmer has said he will not support the software and
> help in getting the system back up after crashes after August of this
> year which leaves my client in a real mess when the system fails
> again. Attempts at the getting the source code have failed and my
I would suggest that the
> client's programmers, who seem relatively familiar with the system,
> believe that the data dictionary is so poorly written/constructed and
> the code flawed that they wonder if getting access is worth it. The
> new acquiring company, well aware of the lack of support, is now
> trying to sell my client a very expensive non-Pick replacement. My
> client feels under the gun to make a decision.
> My questions are:
> 1. Do you believe my client has the legal right to the source code so
> that they may find a programmer to debug the software? What are your
> thoughts on the lack of support?
Both are subject to legal opinion, really. The escrow agreement
will have had very specific terms and conditions. Did your client
buy the product outright (unlikely) or sign an installation and
licence agreement (more likely). If the latter, then it is a
matter of BOTH parties agreeing to renew. If the supplier, or his
successors, no longer wish to renew, their obligatons will be
delineated in the original contracts (and a $200K installtion
must surely have been subject to contract?). The lack of
support is unfortuante, but as an 8-year-old product which
the original programmer is planning to divest himself of it is
a natural evolution. If the successor has purchased the product
rights, as already suggested, for the customer base, that is
their affair.
> 2. Generally speaking, one can debug any source code. However, Pick
> seems so obscure that I have no idea if it can even be done. What are
> your thoughts here? Also, if the programmer refuses to turn over the
> code, how difficult is it to reverse compile?
There is a decompiler - if you Google the newsgroup you will find
it mentioned repreatedly. Whether you use it or not is also a legal
minefield. Morally you may feel justified, although I'm agnostic.
Legally, the rights attached to the software are entirely dependendent
on the contracts, and it is up to the owner of those rights whether
they choose to release them or not. If decompiling is in breach of
the contract terms...
> 3. How difficult is it to extract the data for use with custom
> software?
As before, any decent Pick maintainer could infer the general
structures within the files (especially if they knew what the
application WAS). There are numerous means by which the data
could be extracted.
> Again, please accept my apologies for my ignorance surrounding Pick.
> I would appreciate any thoughts or opinions you have to help guide me.
You are entirely welcome.
[Posted and e-mailed. Propogation of news articles from here seems to be
a little erratic.]
--
Gulraj Rijhwani \\ Courtfields Limited, Chessington, Surrey, UK
g...@courtfields.com \\ Tel: +44 (0)20 8255 4667 Mo: 07976 431936
http://www.courtfld.demon.co.uk \\ Fax: +44 (0)20 8287 8381
----- Specialist in Pick, Unidata, datacomms and general connectivity -----
All material copyright Gulraj Rijhwani and Courtfields. ALL RIGHTS RETAINED.
Patrick Payne
fine, then your money is better spent getting a True Pick Consultant
to upgrade the system to a newer version of D3 (if your are on a pick
product, sounds like Ap/Pro or R83)
As for pick being obscure, well you may be right if you feel "basic"
is obscure. If you do have access to the source code, take a look at
it. It is all very standard basic. It gets to me when all these new
programmers tell me they can't figure out pick, but they have no
problem with Java or Perl. Please.
The biggest issue is that pick is also it's own operating system. You
must learn the editor (similiar to edlin in dos, yep, this is where
most people refure to continue). A command prompt. A database. And a
access language. I like to compare the basic pick environment to
foxpro (the older dos version). Just like foxpro, you must get into
our system. In foxpro it is the dot prompt. In pick it is TCL. Then
pick has a built in database (just like foxpro), and access language
for reports, selecting data, etc. And then it has a programming
language (basic) for writing applications. Again, just like foxpro,
and like foxpro it has unique commands for dealing with its database.
Your out of bounds error may be as simple as a mis-sized dimensional
array. Somebody is trying to access an element greater than the
dimensioned size.
Your GFE's and locking are more than likely a file-size problem. Pick
is very efficent, but you must Size your files up front. Pick uses a
hashing system with a pre-sized file (similiar to how Access and
microsoft SQL) work. When you create a file, you tell pick how many
frames to assign the file. The number of bytes in a frame depends on
your system (it is probably 2k on your system). When you write an
item to a file, pick uses a hash algorithim to determine what frame to
put this item in. It then reads in that entire frame (which may have
more than one record stored in it), and then gets our record out of
it. Ditto on the write. Once you get more items in the file than it
was originally sized for, pick links overflow frames to a frame. This
means when anybody read that frame, they know have to read in all the
linked frames. If the file gets really out of size (so now you have
possibly hundreds of linked overflow frames) you start getting the
results you are talking about.
Bottom line (just as others have stated) these are all very simple
issues for any real pick programmer. It sounds like the people on
site really don't know much about pick and are probably "Application
Experts", not Pick people.
Additional Note: Pick was designed for normal people, not
programmers. Many a pick system has been written not by Programmers
but by business owners. Get yourself a good pick book, do a little
reading, LEARN HOW TO USE THE LINE EDITOR, and you will find it very
simple to handle the system.
- Patrick
CWNoah2
This is very true, and one of Pick's many strengths. It is also a weakness (I'm
a rope system - I'll give you all the rope you want. If you hang yourself with
it, that's OK with me).
I've worked on many systems written by non-programmers, and to Pick's (excuse
me, MV's) credit, they usually work pretty well. A pain to understand, to
maintain, and to even look at, sometimes. but they do work.
Regards,
Charlie Noah
patric...@yahoo.com (Patrick Payne) writes:
>Additional Note: Pick was designed for normal people, not
>programmers. Many a pick system has been written not by Programmers
>but by business owners. Get yourself a good pick book, do a little
>reading, LEARN HOW TO USE THE LINE EDITOR, and you will find it very
>simple to handle the system.
>
>- Patrick
Charlie Noah (CWN...@aol.com)
Mike Preece
I'd bet big bucks that your Pick system is heavily fragmented and
would run a lot better after being saved and restored. It is most
unlikely that your problems are with software that hasn't changed for
8 years - if it ran OK then it should still run OK now.
Whatever you do, seek expert advice before using the "(F)ix" option on
the GroupFormatError handler message. This should really be more
accurately described in the message as "(F)ix up beyond all
recognition".
When files are first created on a Pick system they are allocated a
number of frames (usually 2000 bytes per frame). This is the file's
modulo or, in other words, the number of "groups" in the file. Should
any of the groups in the file require more than 2000 bytes, another
"overflow" frame is allocated automatically and a link is established
between the original/base frame and the overflow frame. When the
overflow frame fills up another frame is allocated and another link is
established from the 1st overflow frame to the next...and so on. Over
time, this can result in links all over the place. This causes the
system to have to go through many hoops to get anything done - and it
is this environment that Group Format Errors are most likely to occur.
The good news is that this is easily solved - although you must take
care to verify that you have a good save before you begin the restore
process.
The first thing to do is run "f-resize" from the TCL (terminal control
language) prompt if the DM (data manager) account. You might be
surprised to learn that this command does not in fact resize anything
at all. What it does is set the "reallocation parameter" for all
overflowed files on your system. You then do a file-save, verify that
the save is good, and restore (ensuring that you don't disable
file-resizing).
Your system will then run much better.
HTH
Mike.
gr...@thunderdata.com (Dawn Green) wrote in message news:<bbef4ee4.02031...@posting.google.com>...
Tony Gravagno
To help, we could use the following:
1) Specific type of Pick system. May be one of the following, could
be others:
D3, Advanced Pick, mvBase, mvEnterprise, R91, R95, Power95, UniVerse,
UniData. Some brands like jBASE are newer, some like Microdata or
Ultimate are older, but that's the sort of name we need.
2) The language of the software would help. There is a reasonable
assumption here that the language is BASIC. It could also be RPL.
3) If a 4GL was used, it would help to know that. Examples include:
System Builder, SB+, Wizard, (TPH) The Programmers Helper, Visual
Pick, Forge, Simple Source, etc...
I have a problem asking for #4 because I know there will be a problem
answering it, but...
4) What is the name of the software application?
The answer to #4 will tell someone here who your problem vendor is,
which might present legal issues. But the answer will also tell some
of us how difficult your client's problems really are. Someone here
might have the source that you need, or an answer to the problems
you've described.
If you can provide us with #1,2 and 3, you will probably get some
solitations by people here qualified to at least tell your client
where they stand with some of this.
If you'd like to contact me by e-mail, I can sign an NDA and act as a
liason to link you with some recognized and qualified providers, with
consideration of the political climate. I will provide my
qualifications for this task as required.
Don't worry, these systems are easy to work with, that's why we love
them. Your client will be OK with a little technical guaidance.
In any case, Good Luck,
Tony Gravagno
T...@leavethispartoutNebula-RnD.com
cmurthi
> I believe what happens is that process "A" attempts to update a group of
several frames, one or more of which may not be in memory, causing process
"A" to lose its timeslice while the system get the frame from the disk. Then
process "B" updates the same group, and completes the act, having not lost
its timeslice, since the frames are now all in memory. Then process "A" gets
its turn again, and finds the group is no longer the way the process last
saw it, causing it to become veklempt.
There is no pick or pick-like system that ever works this way! In the case you
are describing, the group is locked by the OS to prevent another process from
accessing it for read or write while it is being changed, so process B cannot
touch it until A has completed its update.
GFEs are caused by hardware problems (power failures, malfunctions) or OS-level
sofware bugs (which have probably been well sorted out by now); an application
cannot cause a GFE.
>This can be avoided by using READU's (and the MATREADU and READVU equivalents).
This is rare, but does happen to new and old systems alike, when the READUs are
either left out of
the new progs or inadvertently changed to READs on old ones.
No. READU's are solely to prevent application level errors in data, that is, A
can read an item, B update it, then A re-update it and create data errors, but
never in the file format.
Chandru Murthi
Peter Mowatt
I got tired of the debate and no one raised their hand to help.
The GFE issued can be resolved pretty easily and with regular system
maintenance, can go away for good.
The lock and abort sounds a bit odd. Until you can either get
source code or decompile it, you can add some manual locking methods
if you can restrict user access.
The out of bounds error sounds like an error message from a
program where the dimensioned array is smaller than the data it is
reading. This tends to not be corruptable since a reasonable
assumption can be made that the programs updating the records are
correctly fitted with the new array size while read-only may not.
If you need quick response, contact me at call...@verizon.net .
16 years of PICK programming support and development. Excellent
references.
gr...@thunderdata.com (Dawn Green) wrote in message news:<bbef4ee4.02031...@posting.google.com>...
Ed Sheehan
http://members.aol.com/mbtpublish/s.html
Soft GFE
A situation which is interpreted momentarily as a GFE but which later
resolves itself and does not appear again. It may be caused by a transient
condition when two processes are handling exactly the same data at the same
moment.
From Jon Sisk's site:
http://www.jes.com/pb/pb_wp9.html
The problem stems from the theory of how items are updated in a file. When a
new item is placed into a file, it is always placed at the "end" of the
group. When an item is updated in a group, the item is physically "pulled
out" of its old location. All the remaining items in the group "shift left"
to fill in the gap created by the departure of the updated item. (It's like
stepping out of a line for a movie: your space is immediately filled.) The
updated item then is put at the end of the group.
While the group is "in motion," that is, "shifting left," there is a danger
of another process attempting to update the group. If a second process does
attempt to update the group, it may result in what commonly has been called
a soft Group Format Error. This "transient" GFE is usually self-correcting.
It often displays the terror-inducing message GROUP FORMAT ERROR! and then
goes away. What happened is that once the update by the first process
completed, the group returns to a stable condition, where the second process
can now update the group. Realizing this, the second process effectively
says "Just kidding!" and then completes the update. In theory, no data is
lost.
Ed
"cmurthi" <cmu...@uswest.net> wrote in message
news:3C960A5A...@uswest.net...
> Ed Sheehan wrote:
> > I believe what happens is that process "A" attempts to update a group of
> several frames, one or more of which may not be in memory, causing process
> "A" to lose its timeslice while the system get the frame from the disk.
Then
> process "B" updates the same group, and completes the act, having not lost
> its timeslice, since the frames are now all in memory. Then process "A"
gets
> its turn again, and finds the group is no longer the way the process last
> saw it, causing it to become veklempt.
>
> There is no pick or pick-like system that ever works this way! In the case
you
> are describing, the group is locked by the OS to prevent another process
from
> accessing it for read or write while it is being changed, so process B
cannot
> touch it until A has completed its update.
<snip>
cmurthi
> http://www.jes.com/pb/pb_wp9.html
>
> The problem stems from the theory of how items are updated in a file. When a
> new item is placed into a file, it is always placed at the "end" of the
> group. When an item is updated in a group, the item is physically "pulled
> out" of its old location. ... The updated item then is put at the end of the
> group.
>
> While the group is "in motion," that is, "shifting left," there is a danger
> of another process attempting to update the group. If a second process does
> attempt to update the group, it may result in what commonly has been called
> a soft Group Format Error. "
Just an addendum- the above sentence MAY have been correct in R73 or so (before
group locks existed-anyone remember back that far?) but is impossible since
then. I repeat, when a group is being updated the updating process has it group
locked and no other process can update it.
Dawn Green
and even the debate over hard and soft errors from which I learned
more about the inner workings of Pick.
I should first say that my client does not wish to persue this legally
fearing no support until a legal matter is settled. For now, that is
not an option.
Here is some more information:
The client's programmers were concerned about the recurrance of GFEs.
After reading the debate here on that isssue, I believe those may be a
thing of the past since they have not seen a single GFE since
upgrading 6 months ago to mvBase running on a dual PIII 850Mhz on NT.
Good sign.
Though there has been an "out of bounds" error well into the past, it
seems it is an "out of balance" error that worries my client. The
"out of balance" occurs during a spreadsheet balance comparison when
figures generated from the day's balance do not concur with the
balance expected. This seems to be an application error we hope to
put to rest with access to readable code.
I have been told that the source code may be hidden on the machine.
We do know that some of the code is there yet the vast majority
appears to be missing. Efforts to find more have failed. As experts
in this field, can you suggest steps we might take to be certain that
we have made every attempt to find any hidden code? As an aside, the
entire machine the system is running on was shipped to the programmer
where everything was installed and the machine returned to the client.
We realize that the source may have been removed after compiling.
And the "crash" that occurs during record locks is indeed a case where
the terminals beep until the application is shut down on the NT
server. I will try to learn more about that if needed but believe
that that is also a case of poor coding in the application.
My additional questions:
Can Software by Malone be used on mvBase systems? If not, can you
recommend another decompiler? Also, how readable is the decompiled
code? Is the Basic used with MVBase general BASIC or an OS specific
Pick code? I have been told that if the symbol table is missing from
the object code, the decompiled code is very unfriendly. Comments?
Ed Sheehen wrote, "...the business rules are probably contained in
the BASIC source codeand control tables." Are one of these the same
as the symbol table or is this another worry?
We are not sure of the direction our client will go but we would like
to have a competent Pick consultant to turn to for guidance. I have
read several posts here and sent to me personally. I feel many of
those people responding might be able to help us. How do I go about
assessing a consultant's expertise? Can anyone here recommend some
people with whom you have worked? Finally, what information would I
need in order to have programmers quote on extracting data, reverse
compiling and/or debugging the software. Is there any benefit in
working with someone in close geographic proximity versus someone in
another region?
And finally, this has been a great learning experience for us. We
would like to try to learn more and persue this on our own. As
accomplished programmers, do you believe that we can solve this with
minimal outside help?
Thanks again,
Dawn Green
Ed Sheehan
> My thanks to all of you for all of your input on my client's concerns
> and even the debate over hard and soft errors from which I learned
> more about the inner workings of Pick.
>
> fearing no support until a legal matter is settled. For now, that is
> not an option.
>
> Here is some more information:
> After reading the debate here on that issue, I believe those may be a
> thing of the past since they have not seen a single GFE since
> upgrading 6 months ago to mvBase running on a dual PIII 850Mhz on NT.
> Good sign.
It sounds like your GFE problems are now a thing of the past. Congrats!
>
> Though there has been an "out of bounds" error well into the past, it
> seems it is an "out of balance" error that worries my client. The
> "out of balance" occurs during a spreadsheet balance comparison when
> figures generated from the day's balance do not concur with the
> balance expected. This seems to be an application error we hope to
> put to rest with access to readable code.
Definitely a source code issue.
>
> I have been told that the source code may be hidden on the machine.
> We do know that some of the code is there yet the vast majority
> appears to be missing. Efforts to find more have failed. As experts
> in this field, can you suggest steps we might take to be certain that
> we have made every attempt to find any hidden code? As an aside, the
> entire machine the system is running on was shipped to the programmer
> where everything was installed and the machine returned to the client.
> We realize that the source may have been removed after compiling.
Did you have any source code from the time before the installation? Any
competent Pick programmer can find the source if it exists in plain text on
your box.
>
> And the "crash" that occurs during record locks is indeed a case where
> the terminals beep until the application is shut down on the NT
> server. I will try to learn more about that if needed but believe
> that that is also a case of poor coding in the application.
Yep. A group lock conflict. The built in tools can help pinpoint the source.
Again, a good systems analyst can do it.
>
> My additional questions:
> Can Software by Malone be used on mvBase systems?
It looks like it is supported.
> If not, can you
> recommend another decompiler? Also, how readable is the decompiled
> code?
Often, it is more readable than the original. A programmer will not see any
comments left in the source, but if the symbol table is intact, all the
variable names will come back.
> Is the Basic used with MVBase general BASIC or an OS specific
> Pick code?
All implementations of Pick BASICs are enhanced in a mostly consistent
(across platforms) way from the original Dartmouth BASIC. The code is easily
understood by all Pick programmers.
> I have been told that if the symbol table is missing from
> the object code, the decompiled code is very unfriendly. Comments?
The symbol table stores all the variable names, so if it is "optioned out"
during compiling, the decompiler will assign its own variable names for
reconstructing the source. This will make it more difficult to analyze the
source, but not impossible.
>
> Ed Sheehan wrote, "...the business rules are probably contained in
> the BASIC source code and control tables." Are one of these the same
> as the symbol table or is this another worry?
The tables I spoke of are not the same as the symbol tables contained in the
program's object code. Control tables store things like instructions for
program flow, maybe a list of subroutines to call under certain conditions,
display formatting, help text, etc. These are sometimes associated with what
are called 4GL systems (or 4th Generation Language). This means that much of
the logic and parameters of programs are stored outside the programs
themselves. The programs read these tables to get their instructions instead
of all instructions being "hard coded" in the program. This speeds up
development and eases maintenance.
>
> We are not sure of the direction our client will go but we would like
> to have a competent Pick consultant to turn to for guidance. I have
> read several posts here and sent to me personally. I feel many of
> those people responding might be able to help us. How do I go about
> assessing a consultant's expertise? Can anyone here recommend some
> people with whom you have worked? Finally, what information would I
> need in order to have programmers quote on extracting data, reverse
> compiling and/or debugging the software. Is there any benefit in
> working with someone in close geographic proximity versus someone in
> another region?
I believe you are going to require someone on site to do some serious
digging. There may be someone in this group who is already nearby; maybe
they'll pipe up. I'm in Utah, so If I come down, it likely won't be a cheap
solution.
>
> And finally, this has been a great learning experience for us. We
> would like to try to learn more and pursue this on our own. As
> accomplished programmers, do you believe that we can solve this with
> minimal outside help?
I believe that you could get lucky and get a cheap fix, but more likely
you'll need to spend some decent bucks to get you back where you want to be:
have all your source code, debug your balancing problem, and possibly tune
up the code to avoid problems in the future.
Ed
>
> Thanks again,
> Dawn Green
Bob
<snip>
> And the "crash" that occurs during record locks is indeed a case where
> the terminals beep until the application is shut down on the NT
> server. I will try to learn more about that if needed but believe
> that that is also a case of poor coding in the application.
>
>
> Thanks again,
> Dawn Green
This is a case where two users are trying to access a record with locking
at the same time.
This can be a program issue or a user issue. I've had users that used the
edit screen to lookup jobs preventing other users from being able to
update the job. This ended up being a training issue and in one case
moving an employee to a position where they didn't use the computers
(he soon quit).
Some hopefully useful input.
-Bob
Tony Gravagno
First, I commend you, Dawn, on your professional and comprehensive
approach to this. Discussions like this prove the worth of CDP and
it's really a pleasure when someone seems to get so much out of it.
About that "out of balance" error, I think Ed meant it's definitely an
"application" issue, not just a "source code" issue. The beeps are
also an application issue, multiple users dead-locking some critical
record like the new invoice number key, security/password tables, etc.
Though decompilation is an option, after all this I think your best
luck will be had by trying to negotiate access to the source from the
new source owners. Source decompiled with no symbol table is going to
be a royal pain to work with, no matter how competent the programmer,
as well as very expensive. I understand that legal remedies are not
preferred, but, if it comes to that, you only have a few months to go
with this and it might be better to get started before you lose access
to the people involved. The client has already paid "insurance", it's
time for the VAR to process the claim.
Where are you physically located so that we might be able to offer
some on-site assistance?
Good luck,
Tony
T...@itshouldbesimplerNebula-RnD.com
Dawn Green
> some on-site assistance?
We are located in Corpus Christi, Texas.
I am meeting with my client today and hope to find out more about the
"out of balance" and record locks today.
I received some information via email about porting over the data to
an RDBMS. This was interesting because we had considered building a
second database that would work with a new software module on top of
the Pick system. The current system is made up of several modules and
it is only this one module that has problems. From what I was told,
building a relational database is very costly. Has anyone else had
experience with that?
Also, Tony, thank you for assuring me that I am contributing
to--rather than bothering with my novice questions--the CDP. :)
Dawn
Olwen
locking on MvBase, resulting is all screens sitting and beeping. I'm
not actively involved with the system admin, but we seem to have
resolved it by adding patch sets and maybe tinkering with some other
settings. Good mvBase support may be able to resolve this problem.
It's not necessarily poor coding.
Dawn Green wrote:
>
> And the "crash" that occurs during record locks is indeed a case where
> the terminals beep until the application is shut down on the NT
> server. I will try to learn more about that if needed but believe
> that that is also a case of poor coding in the application.
--
Olwen Williams
http://www.bandbclub.com
Tony Gravagno
>> Where are you physically located so that we might be able to offer
>> some on-site assistance?
>
>We are located in Corpus Christi, Texas.
It's amazing how much Pick activity there is in Texas these days. I
might just get an apartment there and set up shop if this keeps up.
Yeah, sure my wife can visit once in a while... :)
>I am meeting with my client today and hope to find out more about the
>"out of balance" and record locks today.
>
>I received some information via email about porting over the data to
>an RDBMS. This was interesting because we had considered building a
>second database that would work with a new software module on top of
>the Pick system. The current system is made up of several modules and
>it is only this one module that has problems. From what I was told,
>building a relational database is very costly. Has anyone else had
>experience with that?
Yes, building a relational environment has considerations. It's not
necessary to consider a relational solution because you have a bad MV
module. If you do, however, consider:
- Multivalue systems can talk to other multivalue systems.
- Current MV systems can function like a relational environment.
- Programs that need a relational DBMS can really work with MV.
- You can still build your own software into your current MV system,
even though you don't have source for your current apps. It's tougher
to implement realtime processing without real integration into your
existing code, but not impossible.
Alls boils down to a possible environment which makes the most use of
whatever you have, and may eliminate the need to buy another solution
which is foreign to your current internal personnel. Soemthing to
think about.
>Also, Tony, thank you for assuring me that I am contributing
>to--rather than bothering with my novice questions--the CDP. :)
>
>Dawn
No prob, I think we all get a little energy from inquiries like this,
so you're helping us too.
Tony
T...@dontthrowbabyoutwiththebathwaterNebula-RnD.com
KG
Unless you specifically received a license to modify the source code, you do
not have that right under federal law and you can be fined up to $10,000
and imprisoned up to 10 years for even accessing that source code without
permission of the author.
Copyrights to computer source code reside with the author automatically, the
same as a with a book.
Even providing the specs for the software does NOT give you any rights to
the source code.
The exclusive right to modify and enhance software carries as much weight as
to the right to copy and distribute those copies.
There is quite a push on to protect intellectual property these days.
Get permission in writing from the author, replace the system, or write your
own if you want to be safe.
Keith Grill
"Ed Sheehan" <NOed...@xmission.com> wrote in message
news:a6uigm$v5v$1...@terabinaries.xmission.com...
Anthony W. Youngman
<kei...@dbmsinc.com> writes
>I would be very cautious here.
>
>Unless you specifically received a license to modify the source code, you do
>not have that right under federal law and you can be fined up to $10,000
>and imprisoned up to 10 years for even accessing that source code without
>permission of the author.
>
>Copyrights to computer source code reside with the author automatically, the
>same as a with a book.
>
your own unless agreed otherwise, but if you're an employee it belongs
to your employer.
Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
Witches are curious by definition and inquisitive by nature. She moved in. "Let
me through. I'm a nosey person.", she said, employing both elbows.
Maskerade : (c) 1995 Terry Pratchett