Client Server 4.2
Moderators: Susan Smith, admin, Gabriel
I think I have it working very well now!
Rem [---- START OF CM-SETUP ----]
WBSERVER J:\WBWIN
REM WBSERVER D:\VOL1\WBWIN
ONQPath J:\CLSINC\ONQ
SpoolCmd @ S:\CLSINC\Batch\WinSpool.cmd [SPOOLFILE] [QUEUE] [PRINTER] \\CLS-APP OUTPUT [WSID] [PROGRAM]
SetEnv Excel_It Installed
Drive F,E:\VOL2,Drive_E,CLSINC
Drive G,D:\VOL1\Clntdata,Drive_D,LEE\LCS_DATA
Drive H,E:\VOL2,Drive_E,CLSINC\History
Drive I,E:\VOL2,Drive_E,CLSINC\Data
Drive K,E:\VOL2,Drive_E,CLSINC\Perm
Drive L,E:\VOL2,Drive_E,CLSINC\Common
Drive M,E:\VOL2,Drive_E,CLSINC\Share
Drive N,E:\VOL2,Drive_N,Users\[LOGIN_NAME$]
Drive J,D:\VOL1,CLS-APP:1,\
Drive S,E:\VOL2,CLS-APP:2,SUPPORT
Rem [---- END OF CM-SETUP ----]
REM [---- Start of Client Server Settings] ---
SETENV TEMP J:\TEMP
SETENV WBWORK J:\TEMP
SETENV WBTEMP J:\TEMP
SUBSTITUTE [WBWORK] J:\TEMP\
SUBSTITUTE [WRKDRV] J:\TEMP\
DRIVE C,D:\VOL1\C,Drive_D,\
DRIVE D,D:\VOL1\D,Drive_D,\
DRIVE E,D:\VOL1\E,Drive_D,\
REM [---- End of Client Server Settings] ---
I was able to implement Client Server by only modifying my WBCONFIG.SYS.
S: is mapped on the workstation, and I use "S:" to call the application. I would have used "F:" but I have a conflict.
TEMP is part of the magic. I mapped "J:" at the workstation, and the server puts all the 'TEMP FILES" in J:\TEMP (D:\VOL1\TEMP). The J: Drive statment makes it work inside BR, and the "Real Map" works on the workstation.
WBWORK and WRKDRV are similar to "TEMP", so I do the same thing.
Notice that "Dummy Drive C,D & E" drives. On my real server, I have "Real C,D & E drives". I really didn't want to expose them, so I just re-mapped them to a 'DUMMY Folder", I don't use these drives for anything, but it prevents users from snooping.
I expect when I go into production I will have additional "Issues", but for now, it's really working well. GUI ON/GUI OFF, Spooled Printing, NWP Printing, shelling to "EXE" programs, everything seems to work properly.
Rem [---- START OF CM-SETUP ----]
WBSERVER J:\WBWIN
REM WBSERVER D:\VOL1\WBWIN
ONQPath J:\CLSINC\ONQ
SpoolCmd @ S:\CLSINC\Batch\WinSpool.cmd [SPOOLFILE] [QUEUE] [PRINTER] \\CLS-APP OUTPUT [WSID] [PROGRAM]
SetEnv Excel_It Installed
Drive F,E:\VOL2,Drive_E,CLSINC
Drive G,D:\VOL1\Clntdata,Drive_D,LEE\LCS_DATA
Drive H,E:\VOL2,Drive_E,CLSINC\History
Drive I,E:\VOL2,Drive_E,CLSINC\Data
Drive K,E:\VOL2,Drive_E,CLSINC\Perm
Drive L,E:\VOL2,Drive_E,CLSINC\Common
Drive M,E:\VOL2,Drive_E,CLSINC\Share
Drive N,E:\VOL2,Drive_N,Users\[LOGIN_NAME$]
Drive J,D:\VOL1,CLS-APP:1,\
Drive S,E:\VOL2,CLS-APP:2,SUPPORT
Rem [---- END OF CM-SETUP ----]
REM [---- Start of Client Server Settings] ---
SETENV TEMP J:\TEMP
SETENV WBWORK J:\TEMP
SETENV WBTEMP J:\TEMP
SUBSTITUTE [WBWORK] J:\TEMP\
SUBSTITUTE [WRKDRV] J:\TEMP\
DRIVE C,D:\VOL1\C,Drive_D,\
DRIVE D,D:\VOL1\D,Drive_D,\
DRIVE E,D:\VOL1\E,Drive_D,\
REM [---- End of Client Server Settings] ---
I was able to implement Client Server by only modifying my WBCONFIG.SYS.
S: is mapped on the workstation, and I use "S:" to call the application. I would have used "F:" but I have a conflict.
TEMP is part of the magic. I mapped "J:" at the workstation, and the server puts all the 'TEMP FILES" in J:\TEMP (D:\VOL1\TEMP). The J: Drive statment makes it work inside BR, and the "Real Map" works on the workstation.
WBWORK and WRKDRV are similar to "TEMP", so I do the same thing.
Notice that "Dummy Drive C,D & E" drives. On my real server, I have "Real C,D & E drives". I really didn't want to expose them, so I just re-mapped them to a 'DUMMY Folder", I don't use these drives for anything, but it prevents users from snooping.
I expect when I go into production I will have additional "Issues", but for now, it's really working well. GUI ON/GUI OFF, Spooled Printing, NWP Printing, shelling to "EXE" programs, everything seems to work properly.
-
- Posts: 25
- Joined: Thu Jun 11, 2009 9:04 am
- Location: Edmonton
- Contact:
I tried that one as well, it says it copied, but I can't find the file.
I also tried:
pr exists("@:C:\TEST.TXT")
This returns 0
I might have a really old client server version, perhaps this version isn't working correctly.
I also tried:
pr exists("@:C:\TEST.TXT")
This returns 0
I might have a really old client server version, perhaps this version isn't working correctly.
Last edited by GomezL on Thu Feb 18, 2010 3:05 pm, edited 1 time in total.
-
- Posts: 25
- Joined: Thu Jun 11, 2009 9:04 am
- Location: Edmonton
- Contact:
I ultimately figured out that @::C:\WORK is require to find an "Absolute Path".
I have been trying to figure out how to assign a "WSID" for each workstation. In our "Regular WB32.EXE", we have a command line as follows:
F:\CLSINC\WBWIN\WB32.exe -%WSID% -WBCONFIG.SYS RUN STARTUP/WBWIN
Each workstatino is assigned a specific WSID.
With Client Server, I can't seem to use the WSID assigned to the workstation. I ultimately decided to use WSID=800+, but it results in a "Very Random" WSID assigned. We use the Workstation ID to assign Machine preferences like the default printer.
I have been trying to figure out how to assign a "WSID" for each workstation. In our "Regular WB32.EXE", we have a command line as follows:
F:\CLSINC\WBWIN\WB32.exe -%WSID% -WBCONFIG.SYS RUN STARTUP/WBWIN
Each workstatino is assigned a specific WSID.
With Client Server, I can't seem to use the WSID assigned to the workstation. I ultimately decided to use WSID=800+, but it results in a "Very Random" WSID assigned. We use the Workstation ID to assign Machine preferences like the default printer.
-
- Posts: 292
- Joined: Fri Jun 19, 2009 9:01 am
- Location: Lawrence, Kansas
- Contact:
We include a wsid.sys file in wbconfig.sys/brconfig.sys
In it we have
@doug WSID 01
@steve WSID 02
@jamie WSID 03
etc..
This will assign an id based upon the username the logged into client server with.
In it we have
@doug WSID 01
@steve WSID 02
@jamie WSID 03
etc..
This will assign an id based upon the username the logged into client server with.
GomezL wrote:I ultimately figured out that @::C:\WORK is require to find an "Absolute Path".
I have been trying to figure out how to assign a "WSID" for each workstation. In our "Regular WB32.EXE", we have a command line as follows:
F:\CLSINC\WBWIN\WB32.exe -%WSID% -WBCONFIG.SYS RUN STARTUP/WBWIN
Each workstatino is assigned a specific WSID.
With Client Server, I can't seem to use the WSID assigned to the workstation. I ultimately decided to use WSID=800+, but it results in a "Very Random" WSID assigned. We use the Workstation ID to assign Machine preferences like the default printer.
Steve Koger
Computer Specialist
SEKESC-MACS Division
Computer Specialist
SEKESC-MACS Division
I realize that we have attached login name to workstation ID in many examples, and more importantly, by enabling the use of WSID in file access SUBSTITUTE statements. In doing so we have hampered the independent specification of actual client machine preferences. I still think this was wise because the majority of processing individualization is done by people, not machines. People run programs and we are here to make them happy, not machines. That being said, we absolutely need to have a way to identify client machines in programs.
Rick Graham once suggested that we make the MAC address visible. This at one point was a good idea, but in the new operating environments with things like terminal server and virtual machines the MAC address of the client machine is no longer available to BR.
I suggest that we use an environmental variable to identify the client machine. This can be controlled at the server through a series of client machine oriented BRCONFIG files. All of the client-machine config files can INCLUDE common config files as appropriate.
I would like to keep the client icon specification as simple as possible limiting it to WSID, config file and initial command. In my opinion, all other variables should be controlled by the configuration files. In actual practice the specification of WSID and an initial command are both discouraged. I can see how something on a client machine should allow it to identify itself, so such use of the config file name for this purpose is appropriate.
Rick Graham once suggested that we make the MAC address visible. This at one point was a good idea, but in the new operating environments with things like terminal server and virtual machines the MAC address of the client machine is no longer available to BR.
I suggest that we use an environmental variable to identify the client machine. This can be controlled at the server through a series of client machine oriented BRCONFIG files. All of the client-machine config files can INCLUDE common config files as appropriate.
I would like to keep the client icon specification as simple as possible limiting it to WSID, config file and initial command. In my opinion, all other variables should be controlled by the configuration files. In actual practice the specification of WSID and an initial command are both discouraged. I can see how something on a client machine should allow it to identify itself, so such use of the config file name for this purpose is appropriate.
-
- Posts: 45
- Joined: Sun Jun 07, 2009 10:50 pm
I'm now of the option that MAC isn't a good solution, too many hardware changes. However every PC has a unique COMPUTERNAME, maybe access to that name similar to USERNAME. Most of my clients have "roaming" employees who might signon upstairs in the morning, but downstairs in the afternoon, therefore needing to print to completely different printers. Of couse sometimes the client decides to move machines to different locations, so another problem. Maybe I need to write a non-BR application as a front end that says, "where are you" and then pass a WSID to BR at it's startup.
Rick Graham
Rick Graham
-
- Posts: 717
- Joined: Sun Aug 10, 2008 4:24 am
- Location: Southern California
I always thought it would be nice to be able to include information in the command line.
Our workaround was to create environment variables that BR uses to trigger
The answer might be to support @%ENV%@ or something like that in Client Server. That way, BR an have a command like
SETENV CLIENT_COMPUTERNAME @%COMPUTERNAME%@
Our workaround was to create environment variables that BR uses to trigger
The answer might be to support @%ENV%@ or something like that in Client Server. That way, BR an have a command like
SETENV CLIENT_COMPUTERNAME @%COMPUTERNAME%@