Screen ghost?? SOLVED BUG???
ivan
deweyweekender at yahoo.com
Wed Jan 6 10:31:09 PST 2010
Since my system call worked from an @key I decided to move my call statement up to the front of my processing then move it down the chain until it failed. It didn't fail until the lookup I do to the file that I do right before my system call, but write and close it before I do the system call . And then I started to play around with that string of code until I came to the problem.
Before I did the system call I do a lookup to file. I fill in some information then I 'write' the lookup, then I 'close' the lookup. Then I do a system call that opens a screen and allows all of the processing on that file to check info that is entered in that file. This has worked fine for years, but recently that changed. It seems that if I leave the 'write lookup' command in there, followed by a 'close lookup' command, then the system call just locks, If I comment out the 'write lookup' and just leave 'close command' in there everything is fine!
Is this a bug or is this something that is to be expected?
On the road to growing my hair back,
-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