Re: System Environment Variables



On Aug 30, 12:40 pm, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Charles Hottel wrote:
"Pete Dashwood" <dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:9c1mcjFbftU1@xxxxxxxxxxxxxxxxxxxxx
Charles Hottel wrote:
"HeyBub" <hey...@xxxxxxxxxxxxxxx> wrote in message
news:_JmdnVkGWspnu8fTnZ2dnUVZ_qSdnZ2d@xxxxxxxxxxxxxxxx
Charles Hottel wrote:
In my system environment variables, the OS variable has a value of
Windows_NT.  I don't know why this should be since the only OS my
computer has ever had is Windows XP professional.  I suppose this
is not really a problem since it has not caused me any trouble in
the last seven years.
If I did want to change it how would I do it?  I assume I would
have to edit the registry.  I tried changing it with MyComputer
and ControlPanel but the change does not survive  a reboot.  I
also tried a script that Pete Dashwood posted here last July,
setEV.wsf, but it seems to only permanently change user
environment variables, not system environment variables.

Select Start, Right-click My Computer, Properties, Advanced,
Environment Variables. Enjoy.

If you change the OS variable from Windows_NT, your computer will
not work and cannot be made to work.

I already tried that and my computer did work, perhaps because when
I rebooted it changed it back to Window_NT.  Anyway I will leave it
alone.
The VBScript book I am reading seemed to imply that you could use
the OS system variable to check which operating system the script is
running under. However I looked ahead in the and there seems a
better way to check this:
'*************************************************************************
'Script Name: GetOSInfo.vbs
'Author:      Jerry Ford
'Created:     09/08/08
'Description: This script demonstrates how to use WMI to retrieve
'             operating system information
'*************************************************************************

'Initialization Section

Option Explicit

'Main Processing Section

DisplayData("gateway-sdxyc16")  'Set the computer on which the
script will execute

WScript.Quit()  'Terminate script execution

'Procedure Section

'This function retrieves and displays operating system information
Function DisplayData(trgtSystem)

 DIM WMIServices, WMICollection, WMIObject

 Set WMIServices = GetObject("winmgmts:\\" & trgtSystem )
 Set WMICollection =
WMIServices.InstancesOf("Win32_OperatingSystem") For Each WMIObject In
WMICollection
   Wscript.Echo "Operating System:  " & WMIObject.Caption
   Wscript.Echo "OS Version Number: " & WMIObject.Version
   Wscript.Echo "OS Manufacturer:   " & WMIObject.Manufacturer
   Wscript.Echo "Service Pack:      " &
   WMIObject.ServicePackMajorVersion Wscript.Echo "SystemDirectory:
" & WMIObject.SystemDirectory Next

End Function

As you get more familiar with WMI (which is incredibly powerful) you
will realise that you could change the setEV script very easily (one
word) to manipulate System instead of User EVs...

I deliberately specified User EVs so people wouldn't do what you are
apparently trying to... :-)

Pete.
--
"I used to write COBOL...now I can do anything."

I really don't need to change it and I am not planning to change it. The
book seemed to imply that a VBScript could check the OS system
variable to determine what operating system  it is running on and
thus alter its execution path.  However the example in the book only
checked that the OS variable was not equal to "Windows_NT" and it did
not show how to check for the other operating systems.  Since I only
support one computer this is  not as important to me as it might be
to a system administrator using scripts to administer many machines
with different operating systems.
So far I am  impressed with VBScript's capabilities and can see using
it for some projects that I have in mind.  I think I will learn more
about Windows by using it , it has considerable power and the price
is right.

The price is indeed right. :-)

People like to jump on Microsoft, but they do provide some amazing
capability for free. I downloaded  the express version of SQL Server 2008 to
a VM the other day as part of duplicating a customer's environment. It is
every bit  as good (in fact, better...) than the full version of SQL Server
2005 I usually use, and have resisted upgrading.

While MS SQL Server Express server is 'free' it seems that it does
require CALs for each client machine at $US167 each, so _using_ it is
not free. Also it seems that it must run on a Server edition of
Windows, which is also not free.


I recently spent a couple of weeks working with PostgreSQL for another
customer and, although it was good in parts, overall it was much harder to
make things happen than with SQL Server.

What is 'easy' and what is 'hard' depends entirely on what you are
used to.

The problem with Open software is
that no-one seems to be responsible for it.

It may well be that you are unaware of who is 'responsible'. In many
cases it is a complete community, in others it is business based,
usually there is corporate support. For PostgreSQL there is financial
support from IBM. There is also EnterpriseDB which has a commercial
version of the free (actually free) PostgreSQL and provide additional
services and support (for money).


I needed a particular ODBC
driver for PG and there was one, but it was buggy. I got the impression it
was being written by enthusiasts after school and they weren't concerned
about when it would be right.

The PostgreSQL ODBC driver is a part of the project. It is easy to
find who is responsible, 20 seconds with google tells me the project
leader is David Page and lists the eight developers who work on it.

There are actually several version of the ODBC driver available going
back to 2001 so that you can match the version to that of the
PostgreSQL you are running. Did you post your 'bug' to the appropriate
forum ?


Commercial software doesn't have that problem, but you do have to pay for
it.

That is why it is called 'commercial'. You can get PostgreSQL as a
commercially supported version from EnterpriseDB, or get it free and
just pay for support.


UNLESS you can get it for free, like Express Editions from Microsoft.

But is isn't really free, is it. You need to buy a Windows Server
edition and you need to buy CALs. And it certainly isn't 'free'.

I
give thanks every day for products like C# which are not only free, but have
an enthusiastic user community who support them for free as well. The latest
incarnation of C# is moving towards asynchronous programming designed to run
on multiple processors. This language just gets better and better... and it
is still FREE!

I started off with a free Express Edition of Visual Studio, but within 3
months it had so blown me away I upgraded to the full version. (there wasn't
that much difference but there were some facilities I especially wanted for
web development.)

I wish I had learned it before now.  If not for your
posting about it and WSH I might not have realized it existed. Thanks.

You're very welcome, Charlie.

Most mainframe people couldn't imagine a world without JCL or REXX, yet they
resist looking at the PC equivalent, even when they are working with PCs
every day.

Scripting is definitely a very powerful tool for any system administrator or
programmer to have in their toolbox. I have been integrating WSH into
solutions for the Windows platform for a number of years now and am very
impressed at the way it opens up possibilities.

For example:

If you use Fujitsu COBOL (NetCOBOL or PowerCOBOL) you need to install it on
each machine you are using for development. This means a license for each
machine and all the unwieldy nonsense of transferring the license if you
move it to another machine. How much better would it be if you could install
it to ONE machine, then use that machine as a "COBOL server" and run the
compiler remotely from any machine where development was taking place? (If
the "COBOL Server" happens to be a Virtual Image and the hardware fails, you
can start it on another machine in seconds.)

(Micro Focus use the concept of a server very well with their COBOL)

You should note that you still need to buy a licence for each
developer that will use the software.

With, eg, PowerCOBOL it was necessary to have it available on the
machine being used because it was a GUI that ran locally. It may have
been possible to run it using, say, RDP or VLC, but only one user at a
time.

The same applied to MicroFocus COBOL if you were using their toolset,
such as the editor (spit) or Animator.

With both Fujitsu and Microfocus it would be possible to use the
compiler on a server under the control of, say, make to compile the
programs while developers used their own tools (editors etc, or even
Eclipse) to write the code which would be stored on the server.

In both supplier's case this would still require the purchase of a
licence for each user.


It wasn't until I got into WSH and WMI that I started to realise it would
probably be possibe to use Remote Procedure Calls (RPC) to activate COBOL on
a remote machine. I spent an interesting afternoon experimenting and now the
PRIMA Toolset can run the COBOL compiler locally or remotely, to instantly
compile the code it generates.

I no longer have COBOL installed on my own development machine. (It is a C#
environment with Visual Studio 2008 (I'm playing with VS 2010 at the moment
to see if I need to upgrade. At this stage it looks like I would only need
it for mobile and phone development, which I really don't have time to get
into seriously right now.))

Instead, I run different versions of COBOL on different Virtual Machines,
whenever I need them, to test things for various clients with different
versions of COBOL. The VMs appear on my wireless LAN just like any other
networked machine and I can run the COBOL on any one of them from any other
networked machine, using WSH and scripts I wrote to support that. Without
the power of WMI and WSH I don't think this would be easy. I can keep the
VMs on a separate hard drive (in fact, I have a couple of them backed up to
memory sticks...) and it leaves more space for development on my own
notebook. It takes less than 20 seconds to bring a VM on line (for some
reason which I haven't yet understood, the VMs boot into Windows in a
fraction of the time a real machine takes...it could be that they are
sharing some parts of the OS with the host, I don't know...))

I would strongly recommend any COBOL developers reading this to think about
using VMs as development machines. You can snapshot the whole machine image
in seconds, experiment and try out things you might hesitate to do on a real
machine, because the Virtual Image is "expendable" and easily replaced. I
wish I had moved into this environment many years ago instead of the five or
so I have been using it.

Check the conditions of you licence to ensure that this is allowed
first.


Latest versions of Windows come with Virtual Machine support. I use ORACLE's
VirtualBox and find it outstanding, but it really doesn't matter which
particular form of VM you decide to use; the concept is what is important..

I know you spent some time looking at Java, Charlie.

You should be aware that WSH can host JavaScript as well as VBScript.
Although JavaScript is NOT Java there are some passing similarities and I
have to admit that sometimes I prefer JScript to VBScript.

It's probably just me, but I think there is a brutality about VBScript. :-)
It doesn't have the elegant finesse of JavaScript. Maybe I'm being too
"touchy feely"... :-)

At the end of the day, tools are tools and whatever works is good.

Pete.
--
"I used to write COBOL...now I can do anything."

.



Relevant Pages

  • Re: System Environment Variables
    ... computer has ever had is Windows XP professional. ... also tried a script that Pete Dashwood posted here last July, ... posting about it and WSH I might not have realized it existed. ... If you use Fujitsu COBOL you need to install it on ...
    (comp.lang.cobol)
  • Re: Windows/Macro Language Info?
    ... The point is that malware is often using Windows _features_. ... I totally understand the difference between client and server side (and you ... subverted by script code (the facilities to change file size, dates, etc. ...
    (comp.lang.cobol)
  • Re: Expressions of interest in a Remote COBOL server, please?
    ... but here is a really simply little server ... my WLAN that has Fujitsu COBOL installed on it. ... There are a number of scripting options available under Windows (Scripting ...
    (comp.lang.cobol)
  • RE: NFS on w2k3 server question
    ... new Windows 2K3 server and it will work properly after migrating from ... Window NT4.0 to Windows 2K3. ... logon script migration is specific to how the logon ... it is recommended that you contact Microsoft Customer Support ...
    (microsoft.public.windows.server.migration)
  • Re: Windows 2008 Limitlogin
    ... We are using windows 2008 64 bit Enterprise, we are trying to limit concurrent user login using limit login but unfortunetely always fail. ... I'm one of the people that Paul was referring to who has written a script to control concurrent sessions. ... It currently prevents regular users from logging in more than once by first warning them of where their other session exists and then uses WMI to log the user off forcefully. ... For admins who log in to Windows Server, a separate perl script that ties into a 3rd party perl module must be used because for some reason WMI on Server is ignored. ...
    (microsoft.public.windows.server.active_directory)