PDA

View Full Version : DF3.2 for Linux problem



Larry R Pint
30-Nov-2005, 01:34 PM
The Basics:

We have 6 remote offices connected to the home office via prn
connections. All PCs are running Windows XP SP2. We use Ericom
Smartterm on all the PCs to run our DF 3.2 Linux applications (both at
the home office and all remote offices). Our newest remote office runs
Smartterm from a Citrix desktop, the home office and all other remote
offices run smartterm from their local desktop (not through Citrix).
The DataFlex applications have not changed and everyone is running the
same applications.

The problem:

The new remote office is having trouble. Some things seems to save
correctly, other things do not. For example: The basic file structure
for the rating worksheet is 1 parent file and 1 child file. We checked
5 ratings worksheets that they did recently and only one of them saved
correctly. At least one other one saved the child records but not the
parent. Most didn't save either. The save is done when they hit the
<print> key to print the worksheet, and before the worksheet is actually
printed. They have the printouts, so we know the save should have
occurred. The file in question is only 13% full, so it's not a file
size limitation - and other people are saving without having this problem.

The ratings worksheet is one of the easier things to check. I'm afraid
of what else might not be saving. That will be much harder to identify.

Other things, like the bind (basic client information) screen seem to be
saving fine. There are no reports of data missing from that file.

My main question is: Since they are running the Linux version through a
terminal emulator, where the application is not actually running on
their desktop, do any of the Windows locking settings apply to this
scenario? I don't think so, but ...

This one office is the only one having this problem. The only obvious
difference is that they are running from the Citrix desktop, rather than
their local desktop. While I don't think it will make any difference,
we are about to try putting the terminal emulator on that office's local
desktops and testing to see if the problem is with them running the
emulator under Citrix. (Again, since it's the linux version we're
talking about, the app isn't actually running on the user's PC, so I
don't see why running on the Citrix desktop should be any different than
running on their local desktop.)

Does anybody have any other ideas of what we might look at/for?

Thanks,

Larry Pint
SOFT-STAR, Inc.

Mark Rutherford
30-Nov-2005, 02:37 PM
So...
They telnet or SSH into the machine, am I folling you right?


Larry Pint wrote:
> The Basics:
>
> We have 6 remote offices connected to the home office via prn
> connections. All PCs are running Windows XP SP2. We use Ericom
> Smartterm on all the PCs to run our DF 3.2 Linux applications (both at
> the home office and all remote offices). Our newest remote office runs
> Smartterm from a Citrix desktop, the home office and all other remote
> offices run smartterm from their local desktop (not through Citrix). The
> DataFlex applications have not changed and everyone is running the same
> applications.
>
> The problem:
>
> The new remote office is having trouble. Some things seems to save
> correctly, other things do not. For example: The basic file structure
> for the rating worksheet is 1 parent file and 1 child file. We checked
> 5 ratings worksheets that they did recently and only one of them saved
> correctly. At least one other one saved the child records but not the
> parent. Most didn't save either. The save is done when they hit the
> <print> key to print the worksheet, and before the worksheet is actually
> printed. They have the printouts, so we know the save should have
> occurred. The file in question is only 13% full, so it's not a file
> size limitation - and other people are saving without having this problem.
>
> The ratings worksheet is one of the easier things to check. I'm afraid
> of what else might not be saving. That will be much harder to identify.
>
> Other things, like the bind (basic client information) screen seem to be
> saving fine. There are no reports of data missing from that file.
>
> My main question is: Since they are running the Linux version through a
> terminal emulator, where the application is not actually running on
> their desktop, do any of the Windows locking settings apply to this
> scenario? I don't think so, but ...
>
> This one office is the only one having this problem. The only obvious
> difference is that they are running from the Citrix desktop, rather than
> their local desktop. While I don't think it will make any difference,
> we are about to try putting the terminal emulator on that office's local
> desktops and testing to see if the problem is with them running the
> emulator under Citrix. (Again, since it's the linux version we're
> talking about, the app isn't actually running on the user's PC, so I
> don't see why running on the Citrix desktop should be any different than
> running on their local desktop.)
>
> Does anybody have any other ideas of what we might look at/for?
>
> Thanks,
>
> Larry Pint
> SOFT-STAR, Inc.
>

Larry R Pint
30-Nov-2005, 03:02 PM
Yes, they all use a terminal emulator (telnet session) to run native
Linux DataFlex. Not a DOS or Windows version of DataFlex against files
on the Linux server, but actually running the Linux version of DataFlex.

Larry


Mark Rutherford wrote:
> So...
> They telnet or SSH into the machine, am I folling you right?
>
>
> Larry Pint wrote:
>
>> The Basics:
>>
>> We have 6 remote offices connected to the home office via prn
>> connections. All PCs are running Windows XP SP2. We use Ericom
>> Smartterm on all the PCs to run our DF 3.2 Linux applications (both at
>> the home office and all remote offices). Our newest remote office
>> runs Smartterm from a Citrix desktop, the home office and all other
>> remote offices run smartterm from their local desktop (not through
>> Citrix). The DataFlex applications have not changed and everyone is
>> running the same applications.
>>
>> The problem:
>>
>> The new remote office is having trouble. Some things seems to save
>> correctly, other things do not. For example: The basic file
>> structure for the rating worksheet is 1 parent file and 1 child file.
>> We checked 5 ratings worksheets that they did recently and only one of
>> them saved correctly. At least one other one saved the child records
>> but not the parent. Most didn't save either. The save is done when
>> they hit the <print> key to print the worksheet, and before the
>> worksheet is actually printed. They have the printouts, so we know
>> the save should have occurred. The file in question is only 13% full,
>> so it's not a file size limitation - and other people are saving
>> without having this problem.
>>
>> The ratings worksheet is one of the easier things to check. I'm
>> afraid of what else might not be saving. That will be much harder to
>> identify.
>>
>> Other things, like the bind (basic client information) screen seem to
>> be saving fine. There are no reports of data missing from that file.
>>
>> My main question is: Since they are running the Linux version through
>> a terminal emulator, where the application is not actually running on
>> their desktop, do any of the Windows locking settings apply to this
>> scenario? I don't think so, but ...
>>
>> This one office is the only one having this problem. The only obvious
>> difference is that they are running from the Citrix desktop, rather
>> than their local desktop. While I don't think it will make any
>> difference, we are about to try putting the terminal emulator on that
>> office's local desktops and testing to see if the problem is with them
>> running the emulator under Citrix. (Again, since it's the linux
>> version we're talking about, the app isn't actually running on the
>> user's PC, so I don't see why running on the Citrix desktop should be
>> any different than running on their local desktop.)
>>
>> Does anybody have any other ideas of what we might look at/for?
>>
>> Thanks,
>>
>> Larry Pint
>> SOFT-STAR, Inc.
>>

Marco
30-Nov-2005, 08:13 PM
Larry,

To me this sounds like not possible (but obviously it is).

If all dfrun's are run on the same server linked to the same data, and
no other process is changing or buffering the data, there is should
indeed be no difference what process or O/S stars the telnet session.

I assume when you are talking about Header detail saves, these are
within a begin_transaction / end_Transaction pair, so even if the telnet
session gets cutoff at the weirdest times, the dfrun should rollback...

Wish I could help you more...

Cheers,
Marco


Larry Pint wrote:
> Yes, they all use a terminal emulator (telnet session) to run native
> Linux DataFlex. Not a DOS or Windows version of DataFlex against files
> on the Linux server, but actually running the Linux version of DataFlex.
>
> Larry
>
>
> Mark Rutherford wrote:
>
>> So...
>> They telnet or SSH into the machine, am I folling you right?
>>
>>
>> Larry Pint wrote:
>>
>>> The Basics:
>>>
>>> We have 6 remote offices connected to the home office via prn
>>> connections. All PCs are running Windows XP SP2. We use Ericom
>>> Smartterm on all the PCs to run our DF 3.2 Linux applications (both
>>> at the home office and all remote offices). Our newest remote office
>>> runs Smartterm from a Citrix desktop, the home office and all other
>>> remote offices run smartterm from their local desktop (not through
>>> Citrix). The DataFlex applications have not changed and everyone is
>>> running the same applications.
>>>
>>> The problem:
>>>
>>> The new remote office is having trouble. Some things seems to save
>>> correctly, other things do not. For example: The basic file
>>> structure for the rating worksheet is 1 parent file and 1 child
>>> file. We checked 5 ratings worksheets that they did recently and
>>> only one of them saved correctly. At least one other one saved the
>>> child records but not the parent. Most didn't save either. The save
>>> is done when they hit the <print> key to print the worksheet, and
>>> before the worksheet is actually printed. They have the printouts,
>>> so we know the save should have occurred. The file in question is
>>> only 13% full, so it's not a file size limitation - and other people
>>> are saving without having this problem.
>>>
>>> The ratings worksheet is one of the easier things to check. I'm
>>> afraid of what else might not be saving. That will be much harder to
>>> identify.
>>>
>>> Other things, like the bind (basic client information) screen seem to
>>> be saving fine. There are no reports of data missing from that file.
>>>
>>> My main question is: Since they are running the Linux version
>>> through a terminal emulator, where the application is not actually
>>> running on their desktop, do any of the Windows locking settings
>>> apply to this scenario? I don't think so, but ...
>>>
>>> This one office is the only one having this problem. The only
>>> obvious difference is that they are running from the Citrix desktop,
>>> rather than their local desktop. While I don't think it will make
>>> any difference, we are about to try putting the terminal emulator on
>>> that office's local desktops and testing to see if the problem is
>>> with them running the emulator under Citrix. (Again, since it's the
>>> linux version we're talking about, the app isn't actually running on
>>> the user's PC, so I don't see why running on the Citrix desktop
>>> should be any different than running on their local desktop.)
>>>
>>> Does anybody have any other ideas of what we might look at/for?
>>>
>>> Thanks,
>>>
>>> Larry Pint
>>> SOFT-STAR, Inc.
>>>

Larry R Pint
1-Dec-2005, 09:17 AM
Marco,

This is all old procedural DF 2.3 code that has just be re-compiled into
DF 3.2, so there are no transactions. That's a good idea, though. I
think I'll add begin_transaction / end_transaction to make sure things
are staying "in sync".

Thanks,

Larry


Marco Kuipers wrote:
> Larry,
>
> To me this sounds like not possible (but obviously it is).
>
> If all dfrun's are run on the same server linked to the same data, and
> no other process is changing or buffering the data, there is should
> indeed be no difference what process or O/S stars the telnet session.
>
> I assume when you are talking about Header detail saves, these are
> within a begin_transaction / end_Transaction pair, so even if the telnet
> session gets cutoff at the weirdest times, the dfrun should rollback...
>
> Wish I could help you more...
>
> Cheers,
> Marco
>
>
> Larry Pint wrote:
>
>> Yes, they all use a terminal emulator (telnet session) to run native
>> Linux DataFlex. Not a DOS or Windows version of DataFlex against
>> files on the Linux server, but actually running the Linux version of
>> DataFlex.
>>
>> Larry
>>
>>
>> Mark Rutherford wrote:
>>
>>> So...
>>> They telnet or SSH into the machine, am I folling you right?
>>>
>>>
>>> Larry Pint wrote:
>>>
>>>> The Basics:
>>>>
>>>> We have 6 remote offices connected to the home office via prn
>>>> connections. All PCs are running Windows XP SP2. We use Ericom
>>>> Smartterm on all the PCs to run our DF 3.2 Linux applications (both
>>>> at the home office and all remote offices). Our newest remote
>>>> office runs Smartterm from a Citrix desktop, the home office and all
>>>> other remote offices run smartterm from their local desktop (not
>>>> through Citrix). The DataFlex applications have not changed and
>>>> everyone is running the same applications.
>>>>
>>>> The problem:
>>>>
>>>> The new remote office is having trouble. Some things seems to save
>>>> correctly, other things do not. For example: The basic file
>>>> structure for the rating worksheet is 1 parent file and 1 child
>>>> file. We checked 5 ratings worksheets that they did recently and
>>>> only one of them saved correctly. At least one other one saved the
>>>> child records but not the parent. Most didn't save either. The
>>>> save is done when they hit the <print> key to print the worksheet,
>>>> and before the worksheet is actually printed. They have the
>>>> printouts, so we know the save should have occurred. The file in
>>>> question is only 13% full, so it's not a file size limitation - and
>>>> other people are saving without having this problem.
>>>>
>>>> The ratings worksheet is one of the easier things to check. I'm
>>>> afraid of what else might not be saving. That will be much harder
>>>> to identify.
>>>>
>>>> Other things, like the bind (basic client information) screen seem
>>>> to be saving fine. There are no reports of data missing from that
>>>> file.
>>>>
>>>> My main question is: Since they are running the Linux version
>>>> through a terminal emulator, where the application is not actually
>>>> running on their desktop, do any of the Windows locking settings
>>>> apply to this scenario? I don't think so, but ...
>>>>
>>>> This one office is the only one having this problem. The only
>>>> obvious difference is that they are running from the Citrix desktop,
>>>> rather than their local desktop. While I don't think it will make
>>>> any difference, we are about to try putting the terminal emulator on
>>>> that office's local desktops and testing to see if the problem is
>>>> with them running the emulator under Citrix. (Again, since it's the
>>>> linux version we're talking about, the app isn't actually running on
>>>> the user's PC, so I don't see why running on the Citrix desktop
>>>> should be any different than running on their local desktop.)
>>>>
>>>> Does anybody have any other ideas of what we might look at/for?
>>>>
>>>> Thanks,
>>>>
>>>> Larry Pint
>>>> SOFT-STAR, Inc.
>>>>

Joerg Thuemmler
1-Dec-2005, 09:38 AM
Larry,

sounds strange ... who gets the <print> key? Dataflex on the Llinux
box. Or just the Windows screen? What is printed? A screen copy? Or
something produced by Dataflex? The last would mean, df gets the
key, and if the df program has a secure "save" and "unlock" before
producing the output then there must be something very weird.
Otherwise, if the printing is done inside the save sequence or
before it (not a good idea) there maybe a problem by sending
incorrect keys by your terminal emulation, not impossible it sends
more then one key code for a pressed <print>. You can check this by
keylogging on the linux side maybe.

joerg

Larry Pint wrote:
> The Basics:
>
> We have 6 remote offices connected to the home office via prn
> connections. All PCs are running Windows XP SP2. We use Ericom
> Smartterm on all the PCs to run our DF 3.2 Linux applications (both at
> the home office and all remote offices). Our newest remote office runs
> Smartterm from a Citrix desktop, the home office and all other remote
> offices run smartterm from their local desktop (not through Citrix). The
> DataFlex applications have not changed and everyone is running the same
> applications.
>
> The problem:
>
> The new remote office is having trouble. Some things seems to save
> correctly, other things do not. For example: The basic file structure
> for the rating worksheet is 1 parent file and 1 child file. We checked
> 5 ratings worksheets that they did recently and only one of them saved
> correctly. At least one other one saved the child records but not the
> parent. Most didn't save either. The save is done when they hit the
> <print> key to print the worksheet, and before the worksheet is actually
> printed. They have the printouts, so we know the save should have
> occurred. The file in question is only 13% full, so it's not a file
> size limitation - and other people are saving without having this problem.
>
> The ratings worksheet is one of the easier things to check. I'm afraid
> of what else might not be saving. That will be much harder to identify.
>
> Other things, like the bind (basic client information) screen seem to be
> saving fine. There are no reports of data missing from that file.
>
> My main question is: Since they are running the Linux version through a
> terminal emulator, where the application is not actually running on
> their desktop, do any of the Windows locking settings apply to this
> scenario? I don't think so, but ...
>
> This one office is the only one having this problem. The only obvious
> difference is that they are running from the Citrix desktop, rather than
> their local desktop. While I don't think it will make any difference,
> we are about to try putting the terminal emulator on that office's local
> desktops and testing to see if the problem is with them running the
> emulator under Citrix. (Again, since it's the linux version we're
> talking about, the app isn't actually running on the user's PC, so I
> don't see why running on the Citrix desktop should be any different than
> running on their local desktop.)
>
> Does anybody have any other ideas of what we might look at/for?
>
> Thanks,
>
> Larry Pint
> SOFT-STAR, Inc.
>

Larry Heiges
1-Dec-2005, 11:49 AM
Larry,>
>This is all old procedural DF 2.3 code that has just be re-compiled into
>DF 3.2, so there are no transactions. That's a good idea, though. I
>think I'll add begin_transaction / end_transaction to make sure things
>are staying "in sync".
>
Remember there is an implicit transaction with the first reread or
lock until the last one. If the session is ended abnormally, there
will be a rollback. If the save happens in pieces, only part of the
whole save will be rolled back.


Larry Heiges
App-2-Win Systems, Inc.

Larry R Pint
1-Dec-2005, 12:05 PM
I have reviewed to code. The entire transaction (all saves) are doe
within a lock or reread (depending on if its a new worksheet or an
existing one) and the unlock, so it is all within one implicit transaction.

The printout is done _before_ the saves (but not within the
transaction). It consists of sending the screens that were used to
enter the data and do some calculations to the printer.

We made the changes to the workstations (Windows XP SP2) and Citrix
server (Windows 2003 Server) dealing with locking and caching. Some
simple tests, which failed before the changes, now seem to work. Go
figure! Windows - don't you just love it!

Thanks for everyone's help.

Larry

Larry Heiges wrote:
> Larry,>
>
>>This is all old procedural DF 2.3 code that has just be re-compiled into
>>DF 3.2, so there are no transactions. That's a good idea, though. I
>>think I'll add begin_transaction / end_transaction to make sure things
>>are staying "in sync".
>>
>
> Remember there is an implicit transaction with the first reread or
> lock until the last one. If the session is ended abnormally, there
> will be a rollback. If the save happens in pieces, only part of the
> whole save will be rolled back.
>
>
> Larry Heiges
> App-2-Win Systems, Inc.

Mark Rutherford
1-Dec-2005, 12:05 PM
I still dont see how windows has anything to do with it, if it runs on
the linux machine. but, ok :)

Larry Pint wrote:
> I have reviewed to code. The entire transaction (all saves) are doe
> within a lock or reread (depending on if its a new worksheet or an
> existing one) and the unlock, so it is all within one implicit transaction.
>
> The printout is done _before_ the saves (but not within the
> transaction). It consists of sending the screens that were used to
> enter the data and do some calculations to the printer.
>
> We made the changes to the workstations (Windows XP SP2) and Citrix
> server (Windows 2003 Server) dealing with locking and caching. Some
> simple tests, which failed before the changes, now seem to work. Go
> figure! Windows - don't you just love it!
>
> Thanks for everyone's help.
>
> Larry
>
> Larry Heiges wrote:
>
>> Larry,>
>>
>>> This is all old procedural DF 2.3 code that has just be re-compiled
>>> into DF 3.2, so there are no transactions. That's a good idea,
>>> though. I think I'll add begin_transaction / end_transaction to make
>>> sure things are staying "in sync".
>>>
>>
>> Remember there is an implicit transaction with the first reread or
>> lock until the last one. If the session is ended abnormally, there
>> will be a rollback. If the save happens in pieces, only part of the
>> whole save will be rolled back.
>>
>> Larry Heiges
>> App-2-Win Systems, Inc.

Larry R Pint
1-Dec-2005, 01:46 PM
Me either. Apparently Microsoft wants its fingers in anything that
happens on any computer running its operating systems. After all, they
know better how things should work than anybody else does. :-(

Larry


Mark Rutherford wrote:
> I still dont see how windows has anything to do with it, if it runs on
> the linux machine. but, ok :)
>
> Larry Pint wrote:
>
>> I have reviewed to code. The entire transaction (all saves) are doe
>> within a lock or reread (depending on if its a new worksheet or an
>> existing one) and the unlock, so it is all within one implicit
>> transaction.
>>
>> The printout is done _before_ the saves (but not within the
>> transaction). It consists of sending the screens that were used to
>> enter the data and do some calculations to the printer.
>>
>> We made the changes to the workstations (Windows XP SP2) and Citrix
>> server (Windows 2003 Server) dealing with locking and caching. Some
>> simple tests, which failed before the changes, now seem to work. Go
>> figure! Windows - don't you just love it!
>>
>> Thanks for everyone's help.
>>
>> Larry
>>
>> Larry Heiges wrote:
>>
>>> Larry,>
>>>
>>>> This is all old procedural DF 2.3 code that has just be re-compiled
>>>> into DF 3.2, so there are no transactions. That's a good idea,
>>>> though. I think I'll add begin_transaction / end_transaction to
>>>> make sure things are staying "in sync".
>>>>
>>>
>>> Remember there is an implicit transaction with the first reread or
>>> lock until the last one. If the session is ended abnormally, there
>>> will be a rollback. If the save happens in pieces, only part of the
>>> whole save will be rolled back.
>>>
>>> Larry Heiges
>>> App-2-Win Systems, Inc.

Joerg Thuemmler
6-Dec-2005, 01:34 AM
I think there is, indeed no Windows problem. As you told, you are
printing _before_ saving:

> "The printout is done _before_ the saves (but not within the
> transaction). It consists of sending the screens that were used
> to enter the data and do some calculations to the printer."

That seems not a good idea. Better do vice versa and print from what
was saved (maybe refill your screen with "entdisplay"...).

And as I told, I would check, whether df gets correct codes from the
<print> key. We use "putty" in connection from Windows and I found
keys producing codes that contain escape sequences. Therefore a
"save" may be stopped by this key sequence and you can't see this
because your printouts are well.
And more evil, error beeps and error infos in statusline are not
always seen by the client, depending on configuration of the
terminal program.

joerg

Larry Pint wrote:
> Me either. Apparently Microsoft wants its fingers in anything that
> happens on any computer running its operating systems. After all, they
> know better how things should work than anybody else does. :-(
>
> Larry
>
>
> Mark Rutherford wrote:
>
>> I still dont see how windows has anything to do with it, if it runs on
>> the linux machine. but, ok :)
>>
>> Larry Pint wrote:
>>
>>> I have reviewed to code. The entire transaction (all saves) are doe
>>> within a lock or reread (depending on if its a new worksheet or an
>>> existing one) and the unlock, so it is all within one implicit
>>> transaction.
>>>
>>> The printout is done _before_ the saves (but not within the
>>> transaction). It consists of sending the screens that were used to
>>> enter the data and do some calculations to the printer.
>>>
>>> We made the changes to the workstations (Windows XP SP2) and Citrix
>>> server (Windows 2003 Server) dealing with locking and caching. Some
>>> simple tests, which failed before the changes, now seem to work. Go
>>> figure! Windows - don't you just love it!
>>>
>>> Thanks for everyone's help.
>>>
>>> Larry
>>>
>>> Larry Heiges wrote:
>>>
>>>> Larry,>
>>>>
>>>>> This is all old procedural DF 2.3 code that has just be re-compiled
>>>>> into DF 3.2, so there are no transactions. That's a good idea,
>>>>> though. I think I'll add begin_transaction / end_transaction to
>>>>> make sure things are staying "in sync".
>>>>>
>>>>
>>>> Remember there is an implicit transaction with the first reread or
>>>> lock until the last one. If the session is ended abnormally, there
>>>> will be a rollback. If the save happens in pieces, only part of the
>>>> whole save will be rolled back.
>>>>
>>>> Larry Heiges
>>>> App-2-Win Systems, Inc.