filePro/menus/scripts/etc (was Re: [SOLVED] EXPORT ASCII won't - after action report)

[Richard Kreiss]

> -----Original Message-----
> From: filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com
> [mailto:filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com] On
> Behalf Of Nancy Palmquist
> Sent: Wednesday, June 11, 2014 4:44 PM
> To: Kenneth Brody; filepro-list at lists.celestial.com
> Subject: Re: filePro/menus/scripts/etc (was Re: [SOLVED] EXPORT ASCII won't
> - after action report)
> 
> Ken,
> 
> On 6/10/2014 3:06 PM, Kenneth Brody wrote:
> > On 6/10/2014 2:17 PM, Nancy Palmquist wrote:
> > [...]
> >> Example, I work on one app that the developer wrote with Batch DOS
> >> Scripts.  So instead of looking at the menu to see what happens, you
> >> have to hunt up a Script and then see what will happen.  It even goes
> >> to a filepro file and does IF THEN logic to decide which DOS script
> >> to run in some cases.  I find this approach very difficult to
> >> document and follow.  But it works.  I can see the beauty of a script
> >> to send an email or translate a PCL to a PDF where you can use it
> >> from anywhere, but filepro can run scripts right on the menus and it
> >> makes it easier to follow.  One less step of tracing.
> > [...]
> >
> > I saw a system that had replaced all of the filePro menus with a
> > filePro "menu" file, consisting of fields for the menu name, item
> > keystroke, command to run, and comment.  (It looked as if all of the
> > the filePro and user menus had been imported into this file.) Then,
> > there was a "permissions" table, which listed which users were allowed
> > to run which choices on any given menu.  A master processing table was
> > where everything started, which controlled access to all of the menus.
> >
> > Elegant solution, but a pain initially to figure out what command line
> > a particular user was running.
> >
> 
> I saw a project like that once - maybe the same one.  They opened Clerk and
> then executed SYSTEM commands to run menu options.  It gave them the
> control of access that is not otherwise afforded to filepro users.
> 
> At the time that took two licenses or seats to run since it had to execute
> Dclerk and then another dclerk/rclerk to actually run the option.
> 
> I am not sure if that still takes two licenses to run in the current version, but I
> recall it did so I avoided it as a model.  I do use it on occasion because it is nice
> to have a dclerk screen to collect report parameters nicely and then execute
> a report from there.  But I try not to make it a regular habit.
> 
> I have to say I learn tricks even from the most strangely set up system.  You
> can see that the programmer needed a solution to a problem and came up
> with one based on what they knew about filePro at the time and their thinking
> processes.  It can be enlightening.
> 
> Some of the most creative and well organized data processing code I have
> seen is by John Esak and Howard Wolowitz - back in the day. They both have
> very well organized minds. But usually get to see code written by a customer
> with no training in programming or logical thinking.  Those can be a bit of a
> mess.  I am still always amazed by what they can do when they have the drive
> to figure it out.
> 
Nancy,

As far as I am aware, opening a report or clerk session and then doing a system out to another clerk or report session now only uses 1 license.  

For *nix users this saves them 1 license and going from a clerk to report running s system command used 2 license positions.  For Windows users the license manager is hit for 1 session not 2. 

Per you earlier complaint, this is a session license not a per seat license.  Open 2 windows to filepro and that is 2 sessions even if on the same computer.  This is similar to QuickBooks which counts sessions (windows) not seats.


Richard Kreiss
GCC Consulting

Office: 410-653-2813