Client Server

More advanced topics discussed.

Moderators: Susan Smith, admin, Gabriel

bluesfannoz
Posts: 291
Joined: Fri Jun 19, 2009 9:01 am
Location: Lawrence, Kansas
Contact:

Post by bluesfannoz »

Good input Guys!

I agree ultimately the goal is to not need a Drive Share to the server.

My recent discovery of the 10 Let CL_F$=OS_FILENAME$("@:")

So if the Client is pointing to C:\mappcs Then CL_F$="c:\mappcs\."

To easily get the current folder the client is point to is going to allow me to get closer to that.

You can also change the directory on the fly by
doing

20 Execute "Config Client_Current_Dir Folder_you_want"


You can also set the default for your shell calls by setting the SHELL DEFAULT either in your BRConfig.sys or with an execute statement.

We actually have ours defaulting to shell calls on the server

SHELL DEFAULT SERVER
or
Execute "Config SHELL DEFAULT SERVER"

If you set it to CLIENT then your shell calls will run on the client without having to use -@ in your shell call. Also be aware that WBPLATFORM$ will now report the Clients OS.

I go into further detail on this stuff in the Manual from the last conference.
Steve Koger
Computer Specialist
SEKESC-MACS Division
gordon
Posts: 358
Joined: Fri Apr 24, 2009 6:02 pm

Post by gordon »

When you are first trying to get client server working, be sure to focus on the log files. This can give you feedback for identifying setup errors.

On Linux use the script BRLIST to do the installs. This is a human readable script that describes the installation process.

The brlistener.conf file is reread every time a client attempts to login. So you don't have to stop and start the listener to apply changes.

Originally the SYNC process required you to map client drive letters to the same physical drive as the server drive statement second parameter. This meant that client drive J: would be mapped to wherever server drive statement J: pointed to.

With the new third parameter on the drive statement, drive x: on the client can map to wherever the server BR drive J: points to. It's like having a second drive statement parameter for both the server and the client simultaneously.

The method of producing PDF files on a client and then archiving them on the server that I presented at the conference does NOT require VPN drive mappings. For those who are interested just review the code snippets presented.. or call.

For using client server over the internet for long periods of time I find that RECONNECT is pretty much indispensable.
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Post by Gabriel »

Is RECONNECT an option in your BRLISTENER.CONF file? How do you use it? This sounds really useful.

While I have very few problems with connections dropping over the internet, I have also written my programs with the idea in mind that the connection could be dropped at any moment.

But RECONNECT sounds like it would be much cleaner and more secure.

Gabriel
gordon
Posts: 358
Joined: Fri Apr 24, 2009 6:02 pm

Post by gordon »

From 4.3 release notes-

9) CLIENT SERVER RECONNECT Configuration Statement

CLIENT_SERVER RECONNECT_AFTER=20 RECONNECT_TIME=180

BR sends idle packets between the client and the server every 10 seconds. This statement specifies that after 20 seconds of not receiving such packets BR will attempt to reconnect. This reconnect process can last up to a maximum of 180 seconds, after which BR will issue a “lost connection” error and begin processing in unattended mode.


With respect to security-

Beginning with one of the later 4.20h# releases, possibly 4.20he, we began using the new brlistener which encrypts the initial login. The first main release with this was 4.20i.

Starting in 4.3 we encrypt all communication between the client and server.
gtisdale
Posts: 218
Joined: Sun Jun 07, 2009 7:54 am
Location: Concord, Massachusetts
Contact:

Post by gtisdale »

In Client server how can I get the TEMP path of the client vs the TEMP path of the server in a Windows environment.

In 4.2 ENV$("TEMP") would give me the TEMP path corrrectly. In 4.3 ENV$(TEMP") returns "C:\WINDOWS\TEMP" which is not only the incorrect temp directory, but it is a protected directory that I can not copy files to on the clinet.

I'd like to be able to copy EXE files from the server to a consistent tlocation on the client. I have installed BRCLIENT in the C:\PRogram Files\BusinessRules directorywith a vol002 and a temp directory under that. I was trying to copy the exe files to the vol002 directory for local use on the fly but in Vista this seems to be a protected directory so I swithched to ENV$("TEMP"), but that is the server designation and on the local machine the result is also a protected directory. I could hard code a location but would like to be able to use the client temp directory since many of my other files get created there as well, like for rtf documents and spreadsheets.

FNGeorge
gtisdale
Posts: 218
Joined: Sun Jun 07, 2009 7:54 am
Location: Concord, Massachusetts
Contact:

Post by gtisdale »

When I moved the BRCLIENT.exe file and the BR_PARMS.txt file to a new directory (C:\wb) that was not a protected directory by the operating system I was able to copy files back and forth between the client and server.

For the time bein I am setting up two directories below the WB directory that carries BRCLIENT.exe and BR_PARMS.txt named "vol002" and "TEMP".

The vol002 directory will receive and hold copies of the EXE's that I use including David B's BRREISTER2.exe that I use fo find the installed location of things like WORD. On the one program that I have modified to work with CS this has worked well. I find that A cannot launch a Word or Excel program and then continue BR with a -c however, becasue the data file gets copied to the TEMP directory on the client, it then gets manipulated and stored again on the client. After WORD or Excel closes the file then has to be transferred back to the server with a BR COPY command. If BR were allowed to keep running as I now do in NON-CS mode then the modified file would not get back to the server.

I am moving the file to a dummy name on the client, like letter.rtf, but I expect that I will need to change the nomenclature of the dummy filr to include the session number to avoid stepping on different files if more than one session is running.

Other considerations include possibly a dialog box after the file is closed, but before it is copied back to the server saying, much like word or excel do, "The file XXXXX.xls has been modified, do you want to replace the existing file with the updated version?" or something like that built into the function that will copy the file back to the server.

Two new functions to be created:

FNCOPYC2S(clientname$*100,servername$*100;default,message$*1000)
and
FNCOPYS2C(servername$*100,clientname$*100;default,message$*1000)

Look for them in the next FNSNAP..dll

FNGeorge
gordon
Posts: 358
Joined: Fri Apr 24, 2009 6:02 pm

Post by gordon »

Hi George.

There are a number of functions that you have provided from time to time that are quite useful to programmers irrespective of whether they generally use FNSNAP.

It would take a quite an effort to acclimate my application to FNSNAP because it relys on 90 column screens and a variety of other setup considerations.

Can you identify which environmental dependencies the various FNSNAP functions have so people who want to use selective functions will know what they face if they attempt to implement them? Of course this would include any child FNSNAP functions called by each function.

This sounds like a lot of work and may be out of the question, but maybe you could document a select group of functions that have minimal dependencies.
GomezL
Posts: 258
Joined: Wed Apr 29, 2009 5:51 am
Contact:

Post by GomezL »

I use this function to get all of the workstation environment.

I use "CS_" + the workstation environment field.

A few useful things I do with this.
  • CS_TEMP = Client Temp Folder.
    CS_COMPUTERNAME = Client Computer Name (WSID is not as useful as it used to be because in Client Server because you can only tie it to a user, not a machine).
    CS_WBStart = This is actually our own variable, but we use this to perform startup automation.
    CS_USERNAME = The real user for a particular computer.
    CS_USERPROFILE = The folder where all Appdata, MyDocuments, etc. reside. This is really where all the "Temp Stuff" belongs.
** Note: My function assumes that the "EXE SYS" folder is actually the same as my "Default Folder", it may be appropriate to change 1 line #

Code: Select all

39050     OPEN #1: "NAME=@::"&Cs_Textfile$,DISPLAY,INPUT ERROR XIT_FNCS_ENV
Here is My Function:

Code: Select all

00010   LET Fncs_Env
00020   PRINT Env$("CS_TEMP")
39000   DEF Fncs_Env
39010     DIM Tempenv$*2048, Addstr$*3, Leftstr$*2048, Rightstr$*2048, Cs_Textfile$*256
39030     LET Cs_Textfile$="cs-"&Session$&".txt"
39040     EXECUTE "*sys -M set > "&Cs_Textfile$
39050     OPEN #1: "NAME="&Cs_Textfile$,DISPLAY,INPUT ERROR XIT_FNCS_ENV
39060 STARTLOOP: ! 
39070     LET Addstr$="CS_"
39080     DO 
39090       LINPUT #1: Tempenv$ ERROR XIT_LOOP
39100       LET Gw_Wholeline=Len(Rtrm$(Tempenv$))!:
            LET Gw_Posfnwp=Pos(Uprc$(Tempenv$),"=")
39110       IF Gw_Posfnwp>0 THEN 
39120         LET Gw_Equal =Pos(Tempenv$,'=')
39140         IF Gw_Equal > 0 THEN
39150           LET Leftstr$ = Addstr$&Tempenv$(1:Gw_Posfnwp-1)
39160           LET Rightstr$ = Tempenv$(Gw_Posfnwp+1:Gw_Wholeline)
39170           LET Setenv(Leftstr$,Rightstr$) ERROR 39180
39180 ! Should SETENV FAIL, Ignore it
39190         END IF 
39200       END IF 
39210     LOOP 
39220 XIT_LOOP: ! End of Startloop
39230     CLOSE #1: ERROR 39240
39240 ! 
39300 XIT_FNCS_ENV: ! 
39499   FNEND 
bluesfannoz
Posts: 291
Joined: Fri Jun 19, 2009 9:01 am
Location: Lawrence, Kansas
Contact:

Post by bluesfannoz »

Very cool function Luis! One Caveat, that is only going to work if you have 'Shell Default Client' set in your BRCONFIG.SYS.

If you have 'Shell Default Server' set in your BRCONFIG.SYS like we do then you would need to change line 39040

Execute "*sys -M " to Execute "*sys -@ -M"

That way it executes your shell call on the client.
Steve Koger
Computer Specialist
SEKESC-MACS Division
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Post by Gabriel »

If you always put the -@ in your shell call, it should work everywhere, because the -@ is ignored in non Client Server versions of BR.
bluesfannoz
Posts: 291
Joined: Fri Jun 19, 2009 9:01 am
Location: Lawrence, Kansas
Contact:

Post by bluesfannoz »

Not true with Luis Function. Doing so with SHELL DEFAULT CLIENT set in your BRCONFIG.SYS would cause the shell to run on the SERVER. Not where you would want it.

I am trying to show that the SHELL DEFAULT setting affects your outcome.

Gabriel wrote:If you always put the -@ in your shell call, it should work everywhere, because the -@ is ignored in non Client Server versions of BR.
Steve Koger
Computer Specialist
SEKESC-MACS Division
GomezL
Posts: 258
Joined: Wed Apr 29, 2009 5:51 am
Contact:

Post by GomezL »

It seems to be working using the '-@'.

I have my default to the client.

Still, it's worth keeping in mind when I eventually start using server calls.
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Post by Gabriel »

-@ forces the shell call to run on the Client. -s forces the shell call to run on the Server. If you don't specify either one, then the shell call runs in the default location. If you're not using Client Server then both of these flags are ignored, as the client and the server are the same computer.
bluesfannoz
Posts: 291
Joined: Fri Jun 19, 2009 9:01 am
Location: Lawrence, Kansas
Contact:

Post by bluesfannoz »

I stand corrected in 4.18 I see Gabe's described behavior. '-s' was ignored when I first worked with it. It seemed to do what I subscribed of flip flop '-@' structure dependent upon the SHELL DEFAULT setting. I will go back and see what version I was seeing that in.
Steve Koger
Computer Specialist
SEKESC-MACS Division
gtisdale
Posts: 218
Joined: Sun Jun 07, 2009 7:54 am
Location: Concord, Massachusetts
Contact:

Post by gtisdale »

Very interesting function Luis.

I've played with it a little because sometimes I want to know the Environment of the server and sometimes I want the Client so I have changed the routine to pass an "S" or a "C" and each then sets a separate ENV C_ or S_ rather than CS_.
00010 LET FNCS_ENV("C")
00020 PRINT ENV$("C_TEMP")
00030 LET FNCS_ENV("S")
00040 PRINT ENV$("S_TEMP")
00050 STOP
39000 DEF FNCS_ENV(;CS$)
39010 DIM TEMPENV$*2048, ADDSTR$*3, LEFTSTR$*2048, RIGHTSTR$*2048, CS_TEXTFILE$*256
39030 LET CS_TEXTFILE$="cs-"&SESSION$&".txt"
39040 IF UPRC$(CS$)="C" OR CS$="" THEN EXECUTE "*sys -M -@ set > "&CS_TEXTFILE$ ELSE !:
IF UPRC$(CS$)="S" THEN EXECUTE "*sys -M -S set > "&CS_TEXTFILE$ !:
EXECUTE "copy "&CS_TEXTFILE$&" @:"&CS_TEXTFILE$&" -n"
39050 OPEN #1: "NAME=@:"&CS_TEXTFILE$,DISPLAY,INPUT ERROR XIT_FNCS_ENV
39060 STARTLOOP: !
39070 LET ADDSTR$=UPRC$(CS$)&"_"
39080 DO
39090 LINPUT #1: TEMPENV$ ERROR XIT_LOOP
39100 LET GW_WHOLELINE=LEN(RTRM$(TEMPENV$)) !:
LET GW_POSFNWP=POS(UPRC$(TEMPENV$),"=")
39110 IF GW_POSFNWP>0 THEN
39120 LET GW_EQUAL =POS(TEMPENV$,'=')
39140 IF GW_EQUAL > 0 THEN
39150 LET LEFTSTR$ = ADDSTR$&TEMPENV$(1:GW_POSFNWP-1)
39160 LET RIGHTSTR$ = TEMPENV$(GW_POSFNWP+1:GW_WHOLELINE)
39170 LET SETENV(LEFTSTR$,RIGHTSTR$) ERROR 39180
39180 ! Should SETENV FAIL, Ignore it
39190 END IF
39200 END IF
39210 LOOP
39220 XIT_LOOP: ! End of Startloop
39230 CLOSE #1: ERROR 39240
39240 !
39300 XIT_FNCS_ENV: !
39499 FNEND
Inorder to get the Server valiues to the client I needed to copy the server txt file to the client.

FNGeorge
Post Reply