With something like this there is not a simple conclusion to draw; there is an onion to be peeled. (gads I hate that cliché but it is appropriate here I guess...)
Here are the layers of the onion and I apologize in advance for the "book"
below.
---------------------------------------------------------------------------------------------------------------------------
The DataStation reads files, if the file is on a network as opposed to on the
PC itself, it is exactly like you opening the file manually on the PC. Of
course the DataStation also has to parse the file. Most file types don't take a
lot of resources to parse. Excel and XML use more than the others. When the
DataStation executes the d.Next_ command or updates D("Status") or similar, it
writes back to a text file that exists in the same directory as the source
file. That means a file write across the network. If the file is over 1000
records long, we create a new .BDS file every 1000 records for speed purposes.
The connection to Meditech Remote WorkStation (Magic) is via an API call that
continuously requests data from the Remote WorkStation. Of course, if the
screen is "thinking" the connection is still requesting and just getting back
nothing. This communication does not take a lot of resources.
The Remote WorkStation is communicating with the Meditech mainframe over some
sort of network protocol, it gets and sends data and renders the screen
accordingly (kind of like a web browser would). The faster/slower the network,
the faster/slower the screens of course adding in processing time of the
request on the mainframe.
Boston WorkStation is an EXE that embeds Microsoft Visual Basic for
Applications, like Excel does today. An average running script, especially
against Meditech Magic uses a negligible to slightly noticeable amount of PC
resources. One could put in lines of code in VBA that would dramatically
increase PC resource usage - I'll call that doing something you shouldn't have
- running this script
Sub LockUpBWS
Do
Loop
End sub
Would be bad for example J
A properly written script paces itself with the screen of the application and
goes as fast or slow as the screens let it.
RDP is a way to project an image of the remoted to PC onto your PC. It also
transmits your local keyboard and mouse actions over to that PC and something
on that pc "plays" those keyboard and mouse instructions back.
When you RDP into a PC, it's kind of like unlocking it and logging in as a
user. When you shut down the remote session on your PC, it's like locking the
PC. While there are hairs to split here, for simplicity sake, many scripts
cannot run when the PC is locked, some can run, but if you want a simple answer
- don't bother trying to run scripts when the PC is locked. When you are
remoting into a PC and you minimize the display on your PC, you "suspend" stuff
on the remoted to PC. There is a registry work around to solve this last bit.
Server OS's vs Desktop OS's for running scripts.
You don't gain anything running BWS on a Server OS. Server OS's are optimized
for performing server type tasks. Desktop OS's are optimized for performing
desktop type tasks. It's probably a push (my understanding here is limited) and
push goes to the dealer, which in this case is a Desktop OS.
64 bit - My understanding (and that is limited) is that 32 bit applications
don't really take advantage of the OS. Meditech Remote WorkStation is 32 bit,
as are 100% of all other applications we script today. BWS is 32 bit as well.
This means 32 bit apps run in a compatibility mode on the OS. I do not know if
that is good, bad or irrelevant. Drivers are especially impacted whatever that
means.
VMWare... Well in theory a virtual PC is the same as a physical PC. But it is
an OS running on (or with or whatever) a bunch of other stuff on a piece of
hardware running an OS. I don't know how VMWare works, that means I'm not
qualified to discuss what would cause it to not work well.
I've known folks who worked at VMWare, in my interactions with them, they seem
like a helpful company and may be worth talking to.
This was actually kind of neat.
http://communities.vmware.com/servlet/JiveServlet/downloadBody/14751-102-8-18266/VMwareWorkstation.pdf
Thom C. Blackwell
Vice President, Technical Services
Boston Software Systems
(866) 653-5105 ex 807
<http://twitter.com/thomcblackwell> @ThomCBlackwell
www.bossoft.com <http://www.bossoft.com/>
Learn about what we do <http://www.youtube.com/watch?v=Fbjk_4LUZYU>
Please follow us on Facebook
<http://www.facebook.com/pages/Boston-Software-Systems/122739774403349?> and
Twitter! <http://twitter.com/Bossoft>
LEGAL NOTICE Unless expressly stated otherwise, this message is confidential
and may be privileged. It is intended for the addressee(s) only. Access to this
E-mail by anyone else is unauthorized. If you are not an addressee, any
disclosure or copying of the contents of this E-mail or any action taken (or
not taken) in reliance on it is unauthorized and may be unlawful. If you are
not an addressee, please inform the sender immediately, then delete this
message and empty from your trash.
website:
http://www.bostonworkstation.com/customer_center/virtual_user_group_talk.aspx
--- To post a message to this list, send mail to: [email protected] You are
currently subscribed as: [email protected] Unsubscribe in the
customer center on our website:
http://www.bostonworkstation.com/customer_center/virtual_user_group_talk.aspx <<image002.png>>
