This is another one of those onion situations worthy of a book response - really getting my money's worth out of that metaphor J
But I can make one definitive statement: Virtualization has nothing to do with
if you can run more than one script at a time.
In our world there are particular things that are technologically impossible to
perform simultaneously. Just like the law of gravity, these things are "laws of
the universe", therefore they are beyond our control and cannot be changed or
avoided (quantum physicists need not correct me here, I'm speaking NewtonianJ).
If a particular thing cannot be performed simultaneously, that also means it
cannot be performed if the PC is locked, or if a screensaver is active.
To generalize the type of screen we are scripting determines if those
particular things will matter or not.
Here's the rundown:
Notes on the below:
A. Task means something like pressing a key, clicking the mouse, reading
the screen etc. It does not mean "a script"
B. I use the phrase "specific things" -I know exactly what these
particular things are, but for brevity, I am not listing them out. I am not
suggesting there are "random few things" the world is not random, it's a PC.
C. Again, I am referring to individual screen situations below, not
scripts. So for example, I could write a thousand scripts against Meditech
Magic and never hit the "few things", or I could write just one, and hit one.
Here is the list:
1. Windows, Java, OCR scripted applications - most tasks cannot be
performed simultaneously - simultaneous scripts are not possible
2. Meditech Client Server 5.6 / 6.0 - most tasks cannot be performed
simultaneously - simultaneous scripts are not possible
3. Meditech Magic - most tasks can be performed simultaneously; there are
specific things that cannot - simultaneous scripts are possible so long as the
"few things" are not performed at the same time, handled by coordinating
between the scripts as needed.
4. Terminal emulator based applications (McKesson STAR, HMS, Siemens
Invision, etc) practically all tasks can be performed simultaneously unless
something occurs that is not "inside" the terminal emulator like a popup window
- simultaneous scripts are possible
5. Web - Practically all tasks can be performed simultaneously unless
something occurs that is not "inside" the browser like a popup window, or there
is something particular to the webpage itself that requires using physical
keystrokes or mouseclicks - simultaneous scripts are possible
Our world is also constrained by resources (PC, Network) or other laws (HLLAPI
allows for 26 shortnames), that limit the maximum number of simultaneous
scripts.
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.
From: [email protected] [mailto:[email protected]]
Sent: Friday, January 06, 2012 9:41 AM
To: Talk
Subject: RE: [talkbws] BWS and VMWare
Hi Thom -
Thank you for the explanation. I wasn't able to locate the Talk Archive for an
answer, but I know you'll be able to provide a definitive answer.
I believe I've read some posts that claim that it is not recommended to run
multiple scripts in a virtualized environment. Can you please elaborate?
TIA!
Jennifer Shwajlyk
Clinical Programmer Analyst, RN
(518)775-4185
[email protected]
________________________________
From: [email protected] [mailto:[email protected]]
Sent: Thursday, January 05, 2012 4:36 PM
To: [email protected]
Subject: RE: [talkbws] BWS and VMWare
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
--- 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
--- 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 <<image001.png>>
<<image002.jpg>>
<<image003.gif>>
