Declare global in called table goes away following lookup?

[Brian K. White]

----- Original Message ----- 
From: "John Esak" <john at valar.com>
To: "Filepro-List at Lists. Celestial. Com" <filepro-list at lists.celestial.com>
Sent: Sunday, August 19, 2007 8:28 PM
Subject: FW: Declare global in called table goes away following lookup?


>> I'm not saying it's hard to remember what ,g does. I am saying it's only
>> possible to remember what ,g does because because everywhere else we
> strive
>> to have labels that relate to the contents, and so the occasional
> arbitrary
>> exception like this can be suffered. But that very same statement also
> shows
>
> Huh... you are all only calling this an exception or arbitrary *after the
> fact*... there was a time when it was perfectly logical... and then, when
> declare global didn't even exist for filePro, the ,g standing for global
> made perfect sense. Still does.

I did say that later.


>> that it is important to strive for meaningful labels as much as possible.
>> None of us is going to ever not-know what ,g is or how to make a variable
>> persistent across records.
>
> The ,g was not to represent a variable being persistent just across 
> records
> but just as importantly across processing tables.  It was perfectly 
> logical
> to use the term from other programming languages that conveyed this idea.
> The ,g gives you a variable that if created on the auot(matic) table had 
> its
> value available on the other tables like the -v sort/select and -z
> input/output table as well.

I thought any variable defined in auto had that property ,g or no ,g
Without the ,g it wouldn't live past the first record, but it would live for 
the initial transition from auto to input, or from any to any.


> Sounds like a dull day and we have nothing better to talk about.

It is.

Was going to go to a ren faire, held off to give someone a chance to get 
back to me if they wanted to go also, ended up never going myself.

So instead I'm writing hylafax integration and it's a pain in the butt as it 
has no db back end nor any good reporting tool despite what the web site 
claims. I'm too spoiled on vsifax. Make any use at all of the various record 
selecting methods of vfxolog/vfxilog/vfxstat and you'd never claim hylafax 
has "awesome reporting" for a second. (The accounting report generated by 
faxcron is pretty cool, just not what I need) The data is there, and 
accessible, but it's in ascii files. A seperate file for every job. Those, 
and there is a log file with mostly enough of the main info for each job in 
an imortable tab-delimited format. Both of those are useable from filepro, 
but neither is efficient. Especially in my case where I have several boxes 
submitting faxes to on fax server, so, each individual qualifier on each box 
would have to at least read all the records in the log file about every fax 
everywhere in order to know how to discard the non-matches, and then maybe 
need to get more info from the per-job files. Plus, there are more than one 
basic approach to fill my needs and I haven't yet decided which will be best 
and so I'm working on about 3 completely different ways at the same time.

1) client boxes all periodically download and import a copy of the log file.
Easy, but not very up to the minute and not efficient reading the log of 
thousands of faxes (per day, per update run) just to get updates on a few 
hundred that apply to you. And it gets worse ever month as the number of 
clients and the number of faxes per day grows. Still fine for now but a dead 
end I think.

2) client boxes request data about specific jobs they know about by hitting 
a cgi on the fax server (which I have to write).
Not too hard either, mainly I worry about the amount of work that cgi has to 
do parsing the per-job files, since each cgi hit would only be one fax, and 
it'd get it a lot, this might be the best way though.

3) fax server hits a cgi on the client (which I have to write) and posts the 
status change of a job right to the appropriate client & appropriate 
qualifier filepro file. There is a nice easy place to insert a shell script 
on one version of hylafax to do just exactly this.

4) sort of like 3 & 1, use the shell script hook place used by 3, but 
instead just have it write out fixed-length log files that can be used as 
alien files, and write seperate ones for each client box, or for each 
qualifier even. Then the clients could just periodically rsync their own 
alien file and run dxmaint. no reports or importing or updating, no delicate 
cgi's.

I said 3 and then listed 4, 'cuz I thought of 4 along the way. Thats part of 
the problem, since there is nothing at all there yet, I can probably think 
up ways to do the job all month, meanwhile not get any one of them coded 
enough to use.

pfff time to go eat and read some nice light Andre Norton I think...

Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!