Can't create a new filePro file...

[Brian K. White]

On 10/19/2011 11:49 AM, Kenneth Brody wrote:
> On 10/19/2011 10:32 AM, Mike Schwartz wrote:
> [...]
>>>        *** A System Error Has Occurred ***
>>> Cannot open file.
>>> /u/appl/filepro/Roto Inc. (7)/map: No such file or directory
>>
>>        It was the PFNAME that was mis-set.  Thanks to Joe Chasan for getting
>> me the correct answer first!
>
> Your initial post also said:
>
>> Grepping "set" and "env" for PF and FP don't show me anything unusual.
>
> Did you not notice it, or was it set in the config file for some even
> stranger reason?
>

Since at least before I ever heard of filePro we've been doing that 
because "for some strange reason" runmenu never had a way to meet a 
certain need any better way.

Setting PFNAME is a way to get a string of your choice to appear at the 
top of all menus, dynamically, without actually editing the menu or it's 
name, which is a way to indicate which of countless environments you are 
currently in. It's pretty important to always know at a glance which 
PFDATA+PFDIR+PFQUAL you are currently using.


Current Workspace: Global System (unqualified) (54) 
dpromenu
┌──────────────────────────────────────────────────────────────────────────────┐
│                            filePro Plus Main Menu 
        │
├──────────────────────────────────────────────────────────────────────────────┤
│ 
        │


(I go a step further and binary edit runmenu to change Filename to 
Workspace)

The above string is generated automatically by an fp start script and 
contains a human-friendly proper name part first "Global System" or 
"Jacks Racks Inc." etc, the qualifier, and the tty.

The qualifier and tty are occasionally useful for support when a user 
calls in and we want to ttysnoop or double-vision their session, or find 
some problem process that they don't know about but we can see that 
there is some system or user command stuck in the background, or they 
lost connection and logged back in but their prior process is still 
holding records open, we can tell what to kill by the tty they see 
currently vs all the ttys we see associated with their username.
But mostly it's just to get the overall environment name on the menu, 
dynamically, not by editing the menu or it's name.

If we could put a variable into the menu title or if there was some 
other way to do the equivalent I would.

To avoid the problem Mike hit just edit the first line of dpromenu
from: ddefine
to  : ddefine ""

In ye olden ancient days some of our customers that had more than one 
company under one roof would handle this "what system am I in" problem 
by using strictly monochrome screens and menus, but have a color 
terminal and set the overall foreground, background, and highlight 
colors differently for different qualifiers. One company had all blue & 
white screens, one had all blue & yellow, another all cyan & white 
etc... That only scales to a handful of possible systems and even then 
half of them have to be terrible all purple and red etc, and no ability 
to use color to intelligently lay out your screens into clear sections 
where prompts look different than inputs look different than headings 
look different than other static screen content look different than 
popups, etc...

I object to the implications behind "for some strange reason".

-- 
bkw