Screen ghost??

ivan deweyweekender at yahoo.com
Wed Jan 6 07:22:02 PST 2010 

Thanks for another suggestion Nancy, but I got the same results that I have originally been getting.  We do system calls all throughout our programming and they typically work flawlessly.  I took out the -h and still the same results.  I also added a close statement to close any lingering lookups that might be out.  No change.

It seems like the general consensus is that there is a syntax or variable issue, but if either of these were the case wouldn't that also be true for running this as root?  It works fine when I run it as root.

I don't really know what the problem is that I'm looking at.  It seems like it is the same thing as when you enter a command from a prompt that you leave it open ended and just get a new line until you hit ctrl-d. Although hitting that does nothing, the only thing that gets me out is hitting ctrl-\.  Then it comes out of the system call and resumes processing the rest of the original file's program.

I can see how a lookup would cause the program to lock, I hadn't thought about that before, but the close comment didn't help with that, so I'm just puzzled as to what the cause to this issue could be.  It doesn't seem to be variable issue, it seems to be a permission issue, but it works fine in another file that has the exact same permissions, it is acting like it is getting locked on something, but nothing is open, and it works fine from root.  So any ideas what else could be causing this problem???

-Ivan

--- On Tue, 1/5/10, Nancy Palmquist <nlp at vss3.com> wrote:

> From: Nancy Palmquist <nlp at vss3.com>
> Subject: Re: Screen ghost??
> To: "ivan" <deweyweekender at yahoo.com>
> Date: Tuesday, January 5, 2010, 7:49 PM
> Ivan:
> 
> Try this:
> 
> declare doit(150)
> 
> doit="$PFPROG/fp/dclerk fesequip -sadd -lx -xa -d -t 130000
> -r \""&pm{"\" -h 'EQUIPMENT FILE'  "
> 
> system doit{""
> 
> If that is still funky try dropping the -h stuff at the
> end.  See if it is any better.
> 
> I have had issues in the past with the system command and
> generating an expression after the command.  I have had
> much better luck with giving the system command the
> expression already evaluated.
> 
> You could also expand the PFPROG for it by doing this:
> 
> doit=getenv("PFPROG"){"/fp/dclerk fesequip -sadd -lx -xa -d
> -t 130000 -r \""&pm{"\" -h 'EQUIPMENT FILE'  "
> 
> Hope that helps.  You know this kind of logic can be a
> real bear, opening another session during the first
> session.  It does work and I have seen entire systems
> written from one process table and system calls like
> this.  It seemed messy to my mind but seemed to work
> for them.  Sometimes I have to get my brain around this
> and it starts to add too many issues.
> 
> I do want to suggest that you want to be sure that you do
> not have any open lookups with locks when you do this. 
> It can put you in a deadlock very easily.
> 
> Nancy
> 
> 
> ivan wrote:
> > I was hoping that would be the answer Nancy, but there
> is no show in that file. There is an input popup command in
> the line above the system command but that variable is only
> 10 characters long.  When that line is disabled nothing
> changes.  Problem is still there.
> > 
> > Here is the system call we use:
> > 
> > system "$PFPROG/fp/dclerk fesequip -sadd -lx -xa -d -t
> 130000 -r \""&pm{"\" -h 'EQUIPMENT FILE'  "
> > 
> > This line is used in two files and one file runs
> great, no problems.  
> > The other file loads the screen, the debugger that is
> in the fesequip file shows at the bottom of the screen and
> the first line after the debug code shows: cr(7,rj), which
> is the line after a trigger key for getting into field 1, so
> it starts running some of the file, but then it is like it
> jumps into... space or something.  
> > If I hit the d then only a d appears on the screen, if
> I hit enter the screen jumps up a line for every time I hit
> enter.
> > 
> > What is throwing me is why it works fine in one file
> but not the other.  And why it would work fine under
> root for the file it doesn't in, but go through the problem
> I described when logged in under a regular user. 
> > So do you have any other ideas to look at?!?
> > 
> > -Ivan
> > 
> > --- On Tue, 1/5/10, Nancy Palmquist <nlp at vss3.com>
> wrote:
> > 
> >   
> >> From: Nancy Palmquist <nlp at vss3.com>
> >> Subject: Re: Screen ghost??
> >> To: "ivan" <deweyweekender at yahoo.com>
> >> Cc: "filepro" <filepro-list at lists.celestial.com>
> >> Date: Tuesday, January 5, 2010, 4:03 PM
> >> Ivan,
> >> 
> >> If you have a show at the bottom of the screen,
> such as:
> >> 
> >> show("23","1") variable
> >> 
> >> Where the variable might be longer than 80
> >> characters.  It will scroll the screen
> exactly as you
> >> indicate.  Fix would be to do this:
> >> show("23","1") variable{""
> >> 
> >> to remove any blank space at the end of the
> variable.
> >> 
> >> The debugger will often scroll the screen funny so
> I would
> >> not worry about that.  Try the command "D" in
> the
> >> debugger to redisplay the screen.
> >> 
> >> Nancy
> >> 
> >> ivan wrote:
> >>     
> >>> Hi all.  I am having some difficulty
> tracking
> >>>       
> >> down an issue that one of our files is
> having.  We do a
> >> system call from two separate files to add
> information into
> >> another file. The call from one file works fine,
> and the
> >> exact same call from another file brings up the
> screen to
> >> add information, then if the user hits enter the
> screen
> >> jumps up one line at a time and not from field to
> field like
> >> it should be.      
> >>> Here's where I get confused... when I set the
> >>>       
> >> debugger, the screen loads and has a line of code
> at the
> >> bottom.  All is normal, then if I hit the
> enter key to
> >> jump to the next line of code the screen moves up
> a line
> >> like when not in debugger mode.  The line of
> code is
> >> just assigning a variable, so there isn't anything
> that
> >> should affect the screen.
> >>     
> >>> Now if I run this as root, everything works
> fine. So I
> >>>       
> >> checked all of the permissions, mod, and owner of
> the two
> >> files that run these system calls and they are
> exactly the
> >> same.  So I'm a little lost here... 
> Anyone else
> >> have this problem? Anyone find a solution???
> >>     
> >>> We are running filePro version 5.6.06 on a sco
> unix
> >>>       
> >> machine.
> >>     
> >>> Losing more hair by the minute,
> >>> -Ivan Chason
> >>> 
> >>> 
> >>>          
> >>   
> _______________________________________________
> >>     
> >>> Filepro-list mailing list
> >>> Filepro-list at lists.celestial.com
> >>> http://mailman.celestial.com/mailman/listinfo/filepro-list
> >>> 
> >>>          
> >> 
> >> -- Nancy Palmquist        MOS
> & filePro Training Available
> >> Virtual Software Systems    Web Based
> >> Training and Consulting    PHONE: (412)
> 835-9417          Web site: 
> http://www.vss3.com
> >> 
> >> 
> >>     
> > 
> > 
> >       
> >   
> 
> 
> -- Nancy Palmquist        
> MOS & filePro Training Available
> Virtual Software Systems    Web Based
> Training and Consulting    
> PHONE: (412) 835-9417       
>    Web site:  http://www.vss3.com
> 
>

More information about the Filepro-list mailing list