System call to Atlantis word processor hanging

General development discussion.

Moderators: Susan Smith, admin, Gabriel

dmeenen
Posts: 50
Joined: Mon Jun 08, 2009 8:34 pm
Contact:

Re: System call to Atlantis word processor hanging

Post by dmeenen »

Susan,

Looking over your steps to trouble shoot:
6. He disabled all security on the server and on the workstation, going so far as to uninstall the Sophos (their security product). No diff.

Sophos (and all other AV products) - if you insert an Exclusion or disable the AV, we have found that the Exclusion needs to be done on ALL workstations that use the shared network drive, not just the workstation and server that is having the issue.
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Re: System call to Atlantis word processor hanging

Post by Susan Smith »

Doug,

Thank you so much. You may have hit on a critical point. We were testing one of the workstations with the security changes! This gives me one more very important thing to try in addition to everybody else's great ideas.

-- Susan
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Re: System call to Atlantis word processor hanging

Post by Susan Smith »

To John and Gabriel (or anyone else who knows),

How do you set up your %appdata% or %programdata% substitutions so that 1) the folder structure exists and 2) BR knows about it?

When you deply your BR application, do you do a Windows install of BR that creates these Windows folders automatically? (We never did a Windows install on this system. We just copied everything where it needed to be, so the OS doesn't know much about it.) Or do manually create the folder structure on each workstation, and load that path into %appdata% (same idea if you use %programdata%)? I tried to change my BR Temp folder (C:\BRTEMP) to %appdata% which produced c:\users\susan\appdata\roaming. But that folder doesn't exist. Do I need to log into every workstation and create a c:\users\username\appdata\Roaming\BR folder and then get BR to know about it somehow?

-- Susan
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Re: System call to Atlantis word processor hanging

Post by Gabriel »

John may be able to help more, as he's does it for all his customers.

But I'm pretty sure you can just add a drive statement, such as:

Code: Select all

DRIVE T:,%appdata%\SherrifsRelief,.,\
you can make the folder (from command line or in a cmd file) by saying:

Code: Select all

cd %appdata%
mkdir SherrifsRelief
and so on.

Basically, you can use %appdata% anywhere in Windows and anywhere in BR where you would normally specify a folder. It will always translate to the full path to the appdata folder, something like "C:\Users\Susan\AppData\Roaming".
John
Posts: 555
Joined: Sun Apr 26, 2009 8:27 am

Re: System call to Atlantis word processor hanging

Post by John »

Gabriel is correct - you can do it in a drive statement like that. I don't use the drive statement, but instead set an environment variable and a substitute statement. I call it Q - it defaults to c:\programdata, but my data folder is defineable by a setenv in brconfig.sys. It's like a drive statement, but easier.

Code: Select all

     setQ$=env$('programData')
     setenv('Q',setQ$)
     execute 'config substitute [Q] "'&env$('Q')&'"'
In a non-client/server install it's much easier - just check env$('programdata') in BR - or in dos try echo %programdata%.
I use a function to get local env variables adding a client_ prefix to them. I think you're already doing this, but I'll provide a code snippet at the bottom of this, just in case. See fncs_env

I use env$('programdata')\ACS\Temp for my temp files, because I run from the temp folder and sometimes env$('temp') gets automatically cleaned out and fileio requires fileio.ini to be in the working folder and read/write access to the working folder. My programs generally install to c:\program files (x86)\ACS 5\etc which does not normally get write access.

When I launch my system I use fnMakeSurePathExists to make sure all the folders I want to exist are created. I started with a copy of fileio's fnmakesurepathexists, but it's grown to work better with UNC paths and such over the years. I've attached it both in compiled form and in source (though without line numbers)

I hope this helps.

Code: Select all

def fncs_env
	dim ce_line$*2048
	dim ce_prefix$
	ce_prefix$="Client_"
	dim ce_field$*2048
	dim ce_value$*2048
	dim ce_os_temp_file$*1048
	dim ce_br_temp_file$*1048
	! if env$('data')='/br/orders/brc_oe/Data' then        !  Gordon's Linux CS Server
	!   setenv('data','\\JAZZ\BR Order Entry\brc_oe\Data')  !  Gordon's Linux CS Server
	! end if                                                !  Gordon's Linux CS Server
	ce_os_temp_file$=rtrm$(env$('data'),'\')&'\cs-'&session$&'.txt'
	ce_br_temp_file$='[Q]\cs-'&session$&'.txt'
	ce_retry_4152_count=0
	CE_MAKE_TEMP_FILE: !
	fnmakesurepathexists(ce_br_temp_file$)
	execute '*sys -M set > "'&ce_os_temp_file$&'"'
	open #hOsSet:=fn_gethandle: "Name="&ce_br_temp_file$,display,input error CE_DEBUG_OPEN_ERR ! error XIT_FNCS_ENV
	do
		linput #hOsSet: ce_line$ error XIT_LOOP
		gw_wholeline=len(rtrm$(ce_line$)) 
		gw_addlen=1 
		gw_posfnwp=pos(uprc$(ce_line$),"=")
		if gw_posfnwp>0 then
			gw_equal =pos(ce_line$,'=')
			gw_nextequal =pos(ce_line$,'=',gw_posfnwp+gw_addlen)
			if gw_equal > 0 then
				ce_field$ = ce_prefix$&ce_line$(1:gw_posfnwp-1)
				ce_value$ = ce_line$(gw_posfnwp+1:gw_wholeline)
				setenv(ce_field$,ce_value$) error ignore
!       pr 'setenv("'&ce_field$&'","'&ce_value$&'")'
! Should SETENV FAIL, Ignore it
			end if
		end if
	loop
	CE_DEBUG_OPEN_ERR: ! 
	if err=4152 or err=4203 then
		if (ce_retry_4152_count+=1)<=3 then 
			goto CE_MAKE_TEMP_FILE
		else if (ce_retry_4152_count+=1)<=6 then 
			if ce_br_temp_file$(1:3)<>'@::' then
				ce_br_temp_file$(0:0)='@::'
			end if
			goto CE_MAKE_TEMP_FILE
		else if (ce_retry_4152_count+=1)<=9 then 
			fnmakesurepathexists('@::C:\ProgramData\ACS\Temp\Session'&session$&'\')
			ce_os_temp_file$='C:\ProgramData\ACS\Temp\Session'&session$&'\cs.txt'
			ce_br_temp_file$='@::'&ce_os_temp_file$
			goto CE_MAKE_TEMP_FILE
		end if
	end if
	exec 'con gui off'
	pr 'error '&str$(err)&' on open of ce_br_temp_file$'
	pr '     ce_os_temp_file$='&ce_os_temp_file$
	pr '     ce_br_temp_file$='&ce_br_temp_file$
	pr '          exists=';exists(ce_br_temp_file$)
	pr '    Press ENTER to Exit' : kstat$(1)
	goto XIT
	XIT_LOOP: ! End of Startloop
		close #hOsSet,free: error ignore
	!
	! XIT_FNCS_ENV: !
	execute "*sy -M CD > "&ce_os_temp_file$
	open #hOsCd:=fn_gethandle: "Name="&ce_br_temp_file$,display,input error XIT_FNCS_OS_PATH
	linput #hOsCd: client_os_path$ error ignore
	close #hOsCd,free: error ignore
	setenv('client_os_path',client_os_path$)
	XIT_FNCS_OS_PATH: ! 
fnend 
Attachments
fnMakeSurePathExists.br.brs
(1.91 KiB) Downloaded 805 times
fnMakeSurePathExists.br
(4.46 KiB) Downloaded 797 times
John Bowman
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Re: System call to Atlantis word processor hanging

Post by Susan Smith »

This is awesome, John. Thanks!

-- Susan
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Re: System call to Atlantis word processor hanging

Post by Susan Smith »

Hi all,

The network guy wanted to isolate the server and workstation to see if the problem was a connection between the two. I ran BR completely from a workstation and it still had the same problem with the network taken out of the mix.

So next, I tried Luis' suggestion of trying to nail down what's happening. I created a script called testprintatlantis.cmd which contains:

c:\Program Files (x86)\Atlantis\atlantis.exe /pt C:\brlocal\NOTE-c081.rtf "HP Universal Printing PCL 6"

and verified that it seems to work from the Start/Run commandline just fine.

Next, I called that same script from BR (where the hanging still occurred) and redirected output to a text file.
SYS testprintatlantis.cmd >TPA.txt This is what I got in TPA.txt:

To return to Business Rules!, type 'exit'.
L:\br>c:\Program Files (x86)\Atlantis\atlantis.exe /pt C:\brlocal\NOTE-c081.rtf "HP Universal Printing PCL 6"


It obviously has nothing to do with where the data was created (%appdata%, %programdata% or c:\brlocal because it runs fine from the WIndows command line. But I'm not sure what to do with this prompt to type Exit to return to BR. Is this where I need to implement Gabriel's suggestion to use a -C switch on the shell call?

-- Susan
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Re: System call to Atlantis word processor hanging

Post by Susan Smith »

I tried adding a "-C" to the system call, but got the same results (no document in the print queue and the same text file saying "press EXIT to return to BR".

-- Susan
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Re: System call to Atlantis word processor hanging

Post by Gabriel »

Just because it works from the command line from those non-standard paths doesn't mean that the location isn't necessarily part of the problem.

Still try %appdata%.

John, you say you have something easier then a drive statement but then you describe something much more complicated then a drive statement.

Susan, I'm pretty sure all you need to do is make a drive statement that maps "T:" to %appdata%. And then it will work the same both under client server, and locally. The one I typed will do it for you. Just try that.

The theory i'm working with is that, after a recent windows update, windows now performs a slower more careful set of verification tasks when programs try to run code outside of their %AppData% folder where windows thinks they belong.


Once you've tried that and it fails, let me know, and i'll start working with you on the Workaround solution that I described before, using the -C option.

Gabriel
John
Posts: 555
Joined: Sun Apr 26, 2009 8:27 am

Re: System call to Atlantis word processor hanging

Post by John »

Susan,
you said:
To return to Business Rules!, type 'exit'.
L:\br>c:\Program Files (x86)\Atlantis\atlantis.exe /pt C:\brlocal\NOTE-c081.rtf "HP Universal Printing PCL 6"
This doesn't look right to me. The c:\Program Files (x86)\Atlantis\atlantis.exe part needs to have double quotes around it. i.e. "c:\Program Files (x86)\Atlantis\atlantis.exe".

Try making that change and see if things work better. I've had issues in BR where Start won't work if it doesn't see the file it's pointing to, which failed with double quotes... To work around that I make a batch file in the working folder and call it, in it I point to the path with spaces encapsulated within quotes.

FYI - my normal shell call to atlantis looks like this:

Code: Select all

execute 'Sy -w -C "'&wordprocessor_exe$&'" "'&os_filename$(fnSrepEnv$(serverSendto$))&'"'
I have another that just prints to the default printer... I don't think it's been used in a long time though:

Code: Select all

execute 'Sy -w "'&wordprocessor_exe$&'" -st /p /npd "'&os_filename$(serverSendto$)&'"'
The fnSrepEnv function just looks for things in brackets and replaces them with their env values.

Gabriel - it's easier (to me) because it never conflicts with real drives and it's less confusing than keeping BR paths and OS paths being different but pointing to the same place. I prefer for all my paths to be OS Paths. I only use those weird BR paths when I have to.
John Bowman
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Re: System call to Atlantis word processor hanging

Post by Gabriel »

Gabriel - it's easier (to me) because it never conflicts with real drives and it's less confusing than keeping BR paths and OS paths being different but pointing to the same place. I prefer for all my paths to be OS Paths. I only use those weird BR paths when I have to.
The problem is then you have to worry about different configurations for every computer and different configurations for Client Server vs Native, and on and on and on.

Drive statements exist to make it so your applications can all run from the same environment. To not use them and then try to do a bunch of extra logic to work around it is counterproductive.

Gabriel
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Re: System call to Atlantis word processor hanging

Post by Susan Smith »

John,

I've done it both ways = with Program Files (x86) encapsulated in quotes and without. The one I posted previously just happened to be the most recent. When I change it to add the quotes, I still have the same problem. This is the new msg:

To return to Business Rules!, type 'exit'.
L:\br>c:\"Program Files (x86)"\Atlantis\atlantis.exe

Here's an interesting update though after a little more experimentation. We might be on the wrong track re: %appdata% or %programdata%. It doesn't seem to matter where the data is located (even if it's in the BR folder). So it took it further and just loaded Atlantis with NO parameters at all. This is the script:

c:\"Program Files (x86)"\Atlantis\atlantis.exe >tpa.txt

TPA.txt STILL contains the prompt to press EXIT to return to BR. That makes me think it's not the data folder at all (though I should still standardize on Operating System data folders as you mentioned.

-- Susan
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Re: System call to Atlantis word processor hanging

Post by Gabriel »

Susan, you're supposed to put your ""s around the entire path, not just the Program Files part.

L:\br>"c:\Program Files (x86)\Atlantis\atlantis.exe"
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Re: System call to Atlantis word processor hanging

Post by Susan Smith »

Oops! Thanks, Gabe. That was just a temporary typo in all of the millions of trials I've been doing. I grabbed the wrong script. I have the quote back the way they are supposed to go now. It made no difference. (Sorry for leading you down the wrong rabbit hole.)

-- Susan
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Re: System call to Atlantis word processor hanging

Post by Susan Smith »

I think it’s solved! And it had nothing to do with any of the things we thought. It was an age-old Microsoft problem that resurfaced - most likely because of a Windows update.

Years ago, Atlantis the Word Processor had a conflict with another product with the same name – a game. I don’t know if this game was ever a part of a Windows install or perhaps Windows had some default registry entries. But the problem was that even if you didn’t have the game installed, AND you called Atlantis the Word Processor from its full path, Windows would try to execute the game. First, it would load rundll32.exe. I remember having this issue about 15 years ago. Microsoft sent out a Windows update that solved this problem. Note that we NEVER had the Atlantis game installed on any workstations. Ever. These were Dell desktops from their business division. In any case, the Windows update “fix” worked all these years. And in the meantime, the people who developed the Word Processor renamed later versions of their product to AWP.exe to avoid this conflict. We were using a custom version of Atlantis that they developed for us because we needed to print files “silently” to a specified printer from a command line. (You could already print to the default printer, but we needed to print to two DIFFERENT printers from one job, so they customized it for us.) Because of this, we never upgraded Atlantis over the years, and besides, it still worked! Well, until April 1, 2019.

My belief is that a recent Windows update somehow reintroduced this issue. One of the symptoms of our problem that I might not have mentioned before (or maybe I did) was that some workstations were using 100% of their CPU and the network admin started getting notifications about it. I believe that this was because of the runaway rundll32.exe.

Ironically, I almost solved the problem, but then messed it up. As part of this troubleshooting process, last week I upgraded one of our workstations to the current Atlantis (now called AWP.exe), in hopes that a more recent version would somehow be different. The Atlantis developers generally incorporate the custom changes they make into later versions of the main product if they might be useful to more users. I figured that this might be the case, hoping that the current version would still run for us, but magically fix the unknown problem. But because I am calling it from multiple programs and didn’t want to mess with too many things at one time by changing the calls from Atlantis to AWP, I left the system calls the way they were and instead, I renamed the upgraded Atlantis exe (now called AWP.exe) back to “atlantis.exe” to match our other system calls. So unknowingly, I reversed the solution.

But today, I went on the Atlantis forum and saw that someone else had posted the exact same problem just last week (including the CPU usage issue and the fact that it worked on subsequent attempts). The admin on the forum sort of shut him down, saying that this was an ancient problem, long since fixed with an exe filename change to AWP.exe. Aha! This rang a bell. So I renamed the original Atlantis.exe to AWP.exe on one of the workstations and I ran a test. It worked!

I’m so thankful to all of you – my friends – for chiming in. I learned a lot! I learned from Luis to pare the test down to a small cmd file and output to a text file (which gave me the first clue that Atlantis was hanging and not releasing back to BR). I learned from Gabe and John about better places to store temp data to avoid Microsoft’s attempts to get ahead of the hackers. (I will come back to that and change our temp files over.) I learned from Doug and Steve about how important Client Server given the increasing problems with mapped shared drives and Doug showed me how to kill a task. This was a great learning experience!

I really should test this solution further before celebrating, but hey – go big or go home.

Thanks everybody!

- Susan
Post Reply