I agree with Brian and Mitch. Unless you are scripting data in routines where
the 4.x workstation is required, stick with the 3.x workstation.
Another thing to keep in mind is how Meditech communicates with the workstation
software and internally with itself. Check out the following that I got from
Gary Gavaert on the Meditech-L:
First of all there is some background explanation needed. When a PC connects to
Meditech there are 2 things to keep in mind:
1. The workstation IP address (or DNS name) in the workstation setup will
connect you to the Meditech server indicated.
2. The OPS device setup entry which dictates which server you are to use is
which server will service your requests.
Once you are logged into Meditech, we all know that Meditech will
connect you to other Meditech servers as needed and your master session (see 2
above) will switch from master to slave as your machine focus changes to
different segments.
Now the above may sound simple but it can have dire implications for
performance if the following caveats are not kept in mind.
1. The IP defined in the workstation will ALWAYS be the machine
your workstation connects to - it does not move to the Meditech machine you are
currently working on.
2. The OPS device setup server will ALWAYS be the machine that is
your main server - it does not move to the Meditech machine you are currently
working on.
What that means is as follows:
1. The machine that your workstation connects is the ONLY machine
that can talk with your PC. All Data goes out that server's NIC.
2. The machine that has your master session is the only one that
can talk to the other segments and is your way out of the Meditech system
(before it goes to the workstation connector).
And is best described by an example.
- Lets say that you have your workstation defined to communicate
with machine A.
- Lets further say that you have your OPS device session setup to
the B machine.
- Lets further say that you work in the LAB, which is on the D
machine.
This means that the information has to travel from the D machine to the
B machine and then to the A machine before it gets back to your machine. You
are now involving 3 (THREE!!!) meditech servers to do your work and each takes
a small performance hit processing your Ethernet data. Multiply this by
thousands of users and you have a serious problem.
The answer therefore is simple. Ensure that all your users are
connecting to the proper machines and have the proper segments setup - ideally
they all match and your users use that Meditech machine only.
Sound easy? well, we found that the workstation setup and segment setup easily
diverge as instructions are forgotten or skipped. While you can't solve the
issue with users running apps and switching focus after they are logged in you
can ensure that, as much as possible, the workstation and segment match.
That is where telnet redirection comes in. it will ensure that the two
match by actually modifying the workstation machine connect parameters to match
what the OPS entries say. Thereby eliminating a large part of the possible data
flow problems and therefore performance problems.
So Telnet redirection is a good thing. (unless you already have a good
system in place where you ensure that the workstation and ops entry match).
To turn it on is easy but I would follow the steps next as they ensure
a smooth transition while allowing you to test it. The main item to keep in
mind is that a * (star) in the segment field in the OPS device setup will cause
the telnet redirect to ignore that entry. We therefore converted all of our OPS
entries first to have the *. Then we enabled telnet redirect. Then we tested it
so we understood it and then we started to convert other PC's to segments we
needed them to be on.
>>> On 2/4/2008 at 11:37 AM, in message
<[EMAIL PROTECTED]>, "Lawrence,
Mitchell" <[EMAIL PROTECTED]> wrote:
> Simple enough. Duplicate a Meditech 3.x script in BWS and compare the
> speeds (slowing down the waitspeed if necessary). Then you are comparing
> apples to apples.
>
>
>
> I agree with Brian, the problem is likely with the NUI client, not BWS.
>
>
>
>
>
> Thank you,
>
> Mitch Lawrence
>
> Lead Applications Analyst
>
> Technical Support - NPR/Automation
>
> CHRISTUS Information Management
>
> *: [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
>
>
>
> Send a "thank you
> <http://intranet.christushealth.org/spiritBuck/Default.asp> " to
> someone!
>
> ________________________________
>
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Gersh, Alan
> Sent: Monday, February 04, 2008 12:20 PM
> To: [email protected]
> Subject: RE: [Talk] Script very slow navigating thru Meditech 4.x NUI
> fields
>
>
>
> My organization are new BWS customers. The BWS is a powerful scripting
> tool. My colleges and I are very disappointed with how slow our test BWS
> Meditech Magic 4.x NUI scripts are executing compared to the performance
> of our current production Meditech Magic 3.x scripts which were built in
> a VB6 MicroScript environment. The programmer in me gives me a feeling
> that something in the Boston Workstation software/DLL is causing the 4.x
> scripts to execute slower than they have tool.
>
>
>
> Alan Gersh
>
> Systems Analyst, Information Technology Department
>
> Martin Memorial Health Systems, Inc.
>
> Phone: 772.223.5945 ext: 4825
>
> Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>
>
>
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Bennett, Brian
> Sent: Monday, February 04, 2008 12:43 PM
> To: '[email protected]'
> Subject: RE: [Talk] Script very slow navigating thru Meditech 4.x NUI
> fiel ds
>
>
>
> I doubt your going to get speeds anywhere close to what they were with
> Meditech 3.x. Even if you went completely VB based scripting in for 4.x
> you will have to slow down the script considerably (waits, pauseloops,
> Pause and stables) so that 4.x can keep up with the script. By going to
> rules based with a speed of .2 I've found BWS to be as fast as it was
> before I started using Rules, but I don't have to manually include so
> many slow downs so Meditech can keep up, nor do I worry about BWS and
> Meditech outpacing one or the other. I would say this is more of a
> Meditech interface issue than a BWS issue.
>
>
>
> Brian Bennett
> Affinity Health Systems
> PBS\Clinic Billing
> (920)628-9055
> [EMAIL PROTECTED]
>
>
>
>
>
> ________________________________
>
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Gersh, Alan
> Sent: Monday, February 04, 2008 10:11 AM
> To: [email protected]
> Subject: [Talk] Script very slow navigating thru Meditech 4.x NUI fields
>
> I am redeveloping a Meditech script using Boston Workstation Software
> 9.0 for Meditech Magic NUI 4.x. The script was originally developed for
> Meditech Magic 3.x using the MicroScript DLL and Visual Basic 6. The BWS
> version of the script is navigating thru Meditech 4.x fields at a much
> slow pace compared to the VB6, Meditech 3.x version. I have tested the
> following scripting scenarios in hopes to find a solution in improving
> the performance/speed while using the BWS or its DLL.
>
>
>
> BWS Rules Based Script, decreased WaitSpeed to lowest value 0.01
>
> Created BWS Procedural version of script.
>
> Created procedural version of script using VB6 and BWS DLL.
>
>
>
> The above testing scenarios did not show any real speed improvement
> between them.
>
>
>
> Where I was able to get a real speed improvement is when I created a
> procedural version of script using VB6 and the Meditech mrwscript.dll.
> But using the mrwscript.dll makes this type of scripting very tedious
> and archaic.
>
>
>
> * Does anyone have any ideas on how I can improve the performance/speed
> of navigating thru Meditech 4.x NUI fields while using the BWS or its
> DLL?
>
>
>
> Code Examples:
>
> [Rules Based]
>
> Title Enter/Edit Employee at 1,1 and Cursor within 7,1#31...Key "{F10}":
> Enter objRs("EAddrs1")
>
>
>
> [Procedural Based]
>
> Key "{F10}"
>
> Pause "@7,1"
>
> Enter objRs("EAddrs1")
>
>
>
> Alan Gersh
>
> Systems Analyst, Information Technology Department
>
> Martin Memorial Health Systems, Inc.
>
> Phone: 772.223.5945 ext: 4825
>
> Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>
>
