Multiple Sessions - what is shared?

Information and discussion about setup, brconfig.sys, installers and other configuration related topics.

Moderators: Susan Smith, admin, Gabriel

Post Reply
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Multiple Sessions - what is shared?

Post by Susan Smith »

Hi all,

When you launch a second or subsequent BR session, does each session inherit anything from the base session?

If I have a program that sets a bunch of things via immediate mode, such as environment variables, [ATTRIBUTES], a change of BR's copy of the LOGIN_NAME$, and other things like that...will my other sessions inherit these?

What is and what is NOT inherited across sessions?

-- Susan
GomezL
Posts: 258
Joined: Wed Apr 29, 2009 5:51 am
Contact:

Post by GomezL »

Pretty much the only thing that I can think of is the WSID with a different SESSION.

There is a way to force a NEW WSID for each session.

We have a "Startup Program" that sets up out environment so that all the "Persistant Settings" are configured. We store these setting on the hard disk.
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Post by Susan Smith »

Thanks Luis. That's a good thing generally. I was testing permissions (based on login_name$) in a program. Generally, I just break into the program, change the login_Name$ on the fly, and continue. (I know...short cuts!) But if I launch a second session, then that login_name$ doesn't stick across the sessions (I thought it would simply because it was a login name) so my testing wasn't working. I can reset it again in the new session, but by the the time it's launched, the permission setting is finished.

No biggie...there are zillion ways to get around this. I'll probably just set the login_name$ temporarily in my BRCONFIG.SYS then.

Thanks. You told me what I needed to know.

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

Post by gtisdale »

If you are looking for a way to get things passed from one session to another you might look into the AHOLD (that IS spelled with a "D" at the end, not an "E") utility that I showed at one of the recent conferences. AHOLD.DLL includes a number of unctions that will store and retrieve string and numeric data for a keyword from session to session and persistent for users who log off and then back on again.

I use it to store selection criteria for reports and other defaults.

fngeta(KEY$) retrieves a numeric
fngeta$(KEY$) retrievs a string
fnputa(KEY$) saves a numeric
fnputa$(KEY) saves a string

There are also

fnleara clears all saved varibles
fndeletea(KEY$) removes a specified KEY$
fnedit that allows a listbox/grid editing of saved varialbes simply by running the library

FNGeorge
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Post by Susan Smith »

Thanks George. It's always good to be reminded of AHOLD with the "D" :)

In this case, it'd a little stickier because it's a Login_name$ that I wanted to keep across sessions. I'm setting it manually in one session and then when I run a program that launches another session, the login_Name$ is reset to my "real" one.

It's not the biggest problem in the world because I can set it in BRCONFIG.SYS and then the 2nd session will snag it too. I just didn't realize that some settings like that aren't held across sessions. But now I know!

I'm glad you mentioned AHOLD and report criteria though. That brings to mind that in this new system I'm working on, I want to move away from writing values back and forth to control files for report settings. It's messy and AHOLD sounds like a much better solution - I don't have to think about where the values are stored. I just assign then a name and voila - instant pseudo-environment variables! I'll go look up the information you had on it at the conference. My conference books have been very helpful to me lately. I think I'm finally growing into some of the information that was once over my head. (It's about time!) Thanks.

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

Post by gordon »

For anyone who needs to do inter-process communication George's function is something that you should get ahold of. It was provided at the 2007 fall conference.

That being said, I have a question for George and a suggestion.

The documentation concerning AHOLD states:
It is important to know that FNGET, which is called by FNGETA and FNGETA$ will refresh or add to any key values already in the memory resident arrays. It will not remove a key that was not included in the disk file. This means that a supplementary array of constants could be written to disk and have every user, or selected users, read those keys and related arrays into memory in addition to keys created directly by the user.
This implies that multiple levels of data can be shared. How can this be done using the present functions if FNGET is always issued by FNGETA, etc?

I suggest that someone with a lot of time on their hands, or a team of people, write an expanded version of this that accomplishes the following:
  • GETA/PUTA reference universally shared values irrespective of login name or workstation ID.
  • GETB/PUTB reference values shared by a LOGIN_NAME$ irrespective of WSID or SESSION.
  • GETC/PUTC reference values associated with the current WSID, Irrespective of SESSION. A rule may be established that reassignment of a WSID to a different LOGIN_NAME$ is not a wise method of conveying data. Therefore if this condition is detected the routines should automatically perform an FNCLEARC. This would imply an internally managed FNPUTC("LOGIN_NAME",LOGIN_NAME$).
  • GETD/PUTD keys could reference values associated with a given session across multiple logins. However I consider this to be unwise and counter-productive. I believe it is best to not make anything SESSION sensitive across logins. Therefore I would not implement GETD/PUTD.
  • I think that GETC should perform a GETB when it has no value of it's own for the requested key, and GETB should act similarly. This supports the local override of universally disseminated values.
  • GETA, GETB and GETC should offer an optional numeric parameter passed by reference that would indicate (0=false) that the value has changed since the previous retrieval of this key by this BR session. This would enable cross session event triggering and semaphores.
I have looked at other forms of inter-process communication and, while each OS offers such facilities, this would provide a method that would work when using client server across mixed platforms, and would not break even if Bill Gates gets an epiphany.

This could also provide a method of broadcasting unobtrusively. The application would have to periodically test for the presence of a message, but this would make it convenient to do so.
gtisdale
Posts: 218
Joined: Sun Jun 07, 2009 7:54 am
Location: Concord, Massachusetts
Contact:

Post by gtisdale »

It would seem that this would be relatively easy to accomplish
The way that AHOLD.dll works is that
1. it is a library with its own variable space
2. when fngeta/fngeta$ gets invoked the library checks to see if the internal arrays have been built
If the arrays have not been built then the holding file is opened and they are built then the holding file dets closed and a flag is set to indicate that this has been done
When an FNPUTA/FNPUTA$ gets invoked the arrays are updated and written to the holding file
3. the init function can be run by calling FNGET and specifying a file name. If no nome is psecified then USER_NAME$ is defaulted. Calling a predetermined system wide file would be easy.

To inplement at lease level a and level b woulld simply be a matter of cloning ahold.dll to bhold.dll and renaming fngeta to fngetb etc. Because the arrays need to exist in separate memory spaces, having them in different libraries would accomplish this.

To turn ahold into a WSID level function you could call FNGET with a file name

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

Post by gordon »

It might be worthwhile to give people some time to ponder these specs before doing this. I've only got one pair of eyes so to speak. I'd like to know what others think about the specs.

Glad to hear that it appears to be pretty straight forward. I truly believe it is the best way to implement inter-process communication for the reasons listed.

I think an example function to support broadcasting would be quite useful as well. Something that can be called as a part of a program's main loop.
Post Reply