Dynamically built selection sets

[Bill Vermillion]

Shakespeare wrote plays and sonnets that will last an eternity, 
but on Thu, Jul 08 02:15 , GCC Consulting wrote:" 

> > 
> > This code dates to about 1995.  The users liked it - and that's
> > what counts I guess. You have a dynamically update listed of what
> > you have selected on the screen for each item you enter.
> > 
> > ========================================
> > :' modify of original to ask if multiple key search or just one::
> > ::za(30,*,g); zb(2,.0,g); fl(1,*,g);:
> > ::zc(54,*) = "Please enter the code or codes for the search.":
> > ::zd(38,*) = "Enter a blank code to end the input.":
> > ::ze(32,*) = "So far you have entered codes -":
> > :fl eq "":gosub getcod; fl = "Y":
> > init::dim code[20](2,.0)
ca:
> > ::x = "1":
> > :1 ne "":gosub getdat:
> > ::end:
> > getdat:        '*************::
> > ::lookup dat = ptrakdat  k=1    i=a -nx:
> > :not dat:return:
> > datloop:dat:code[x] = dat(2):
> > :dat:ky = code[x]:
> > :dat and za co code[x]:select:
> > ::getnext dat:
> > :not dat:return:
> > :dat(1) ne 1:return:
> > :dat(1) eq 1:x = x + "1":
> > ::goto datloop:
> > getcod:        '******************::
> > ::input popup zb " \n " <zc< "\n " <zd< " \n " < ze < "\r" 
> > <za< "\r \n ":
> > :zb ne "":za = za < zb ; goto getcod:
> > :zb eq "":msgbox " \n You selected \r" <za< "\r as the search 
> > code(s). \n Is this correct? \n ","Enter \r Y \r or \r N \r .","YN":
> > :@bk eq "Y":return:
> > :@bk eq "N":za = ""; zb = ""; goto getcod:
> > ::errorbox " \n You must enter a \r Y \r or an \r N \r ! \n 
> > "; goto getcod:
> > :        '********** end of processing table ************::

> Just a layout of program question.

> If one is creating a selection program, why place the gathering
> of the selection criteria at the top and the actual selection
> processing at the bottom of the table?

> Since the entry of the selection criteria is done once and the
> selection process runs more then once, it seems more logical
> to place the entering of the criteria at the bottom of the
> processing table and the selection routines at the top.

That code was written so long ago I don't recall all the details, 
but I'll try to recall what was done.

I'm actually gathering the selection criteria at the bottom, only
if it has not been done.  That is the test for 'fl' being blank
and is a one time event. Then the array is initialized to 20, as
there will be maxium of 20 separate flags in the records being
checked.

Then the selection is being done in the middle, starting directly 
after the "end" statement.

This process was run on a file from the mainframe that covered
all the instructional employees as I recall.  At that time
there were about 700 full-time employees in that area.  The other
employees - in maintenance, etc, and part time, totalled over 1000.

The employees could have up to 20 two-character codes which
indentified certain criteria . As I recall this process was run
to check for all the credential needed for continued employment,
such as foreign teachers with 'green cards' [or equivalent],
valid certificates, degrees, etc., and then those that were
selected were sent written request for current information.

I don't recall the percentage of records that could/would be
selected but I was only a small percentage of the total records.
As above each employee could have up to 20 two-character codes
associated with their ID and with over 700 employess that were
coded - the donwload from the mainframe could run to about 15,000
records, but usually there were only 50 or so employees who were
selected based on this criteria.

So in reality I was skipping over 90% of the records by line 10 as
tests will fail for most.

It seemed like every month or so I'd get a request from the HR
department to run some process on MF data.  They found they could
request a dump from the MF and have me process it in filePro far
more quickly than having to have some MF programmers make a report.

Since HR also handled all the contacts directly - and they loved to
write their own output reports.  That turned out to be a major
problem. I'd be working on something and may be in the process of
restructuing a file, and they wanted to do something and find the
file lockec, so they would unlock it :-(

That's how I learned a few tricks on how to get back to real data
when the file restructure stopped when it hit something that caused
me to have different length records in the front of the file as
opposed to the end of the file.

The people there had been working on FP on their own for a couple
of years before they hired me part-time to do that so the employees
could get work done.

In on other department they had been running a program on the MF
that had a yearly license for whatever the program used.  So they
had me rewrite it in FP.  They gave me many sheets of COBOL
programming and a week or so later it was set up so the department
that needed it could run it on their on version of filePro and drop
the yearly MF costs.  

That was an interesing area as the person undestood data fairly
well.  He was the baseball coach.  And many people dismissed him
because of that.  They didn't know he had finished his pre-med
training but ran out of money so didn't get to go to medical
school, and the later wound up with a degree as an aeronautical
engineer.  But he found he loved to coach baseball more than
anything else in life.

What started out as 10-15 hours of part-time work that I figured
would be a year to 1.5 years at the most, turned out to be
10 years - until they said "everything shall be Microsoft".

[Except of course the mainframe.  The repalced one the year I
started and outgrew it later and replaced that for a bigger one
at about $3,000,000. But all the end users loved filePro and really
hated it when the move was made to Access.

> I realize that with the speed of the current computers, a gosub
> or goto doesn't take much time. However, is it much simpler to
> debug a selection program if the one doesn't have to jump to
> the bottom of the processing table on each record.

> I have some selection processing table which have a few hundred
> line of code to get and verify the information for a report.
> The actual selection routines only take up about 20 line of
> code. A Couple hundred line run once; 20 line or fewer run on
> each record.

On the above no more than 10 lines ran on the majority of records
processed.  If I had been processing filePro data and not data
downloaded from the mainframe and then loaded into an FP file
it would have been different.

> Granted one could run @once processing today to get
> information. But where in your coding would you place it?

> Top or bottom??

All that code was in the 4.1 era.  I could NOT get them to upgrade.

Bill
-- 
Bill Vermillion - bv @ wjv . com