Re: When is browser NOT being used

[Rob Dixon <rob.dixon@xxxxxxxxxxx>]

Hi Simon

Simon Coulter wrote:

> Hello Rob,
>
> Although there is a certain amount of schadenfreude to obtained from 
> watching this series of appends I've decided to put you out of your 
> misery. 

Many thanks - I was wondering how what I imagined would be a simple task 
could be so relatively complex.

> The host does not know whether an emulator or browser is being used. 
> That is because all the host sees is the virtual terminal. The 
> terminal is associated with a real interactive job and is no different 
> from any other interactive job hence no magic environment variables or 
> settings. The reason there is such a thing for WebFacing is because 
> they deliberately do something to track whether a device is a 
> WebFacing device. However, WSG does not 

This I know

> IP address won't work either because it should be set to the IP 
> address of the client. Both the Telnet and WSG servers set this 
> properly as do other properly written virtual terminal applications. 
> Therefore any client that creates a virtual device will set the IP 
> address to the same value--that of the client. 

This I also know

> IP port might work but seems clumsy. If you do take this approach then 
> ensure you determine the current telnet port from the services table 
> rather than presuming port 23. You will also have to allow for SSL 
> Telnet which uses a different port. 

That I knew.

> The getservbyname() API will give you the appropriate ports.
>
> The WSG sign-on validation exit program is unlikely to work because it 
> appears the exit program is invoked before a device is allocated.

That I did not know.

> It is also intended to allow automatic sign-on rather than be a 
> generic exit program. However, you may be able to put it to use.
>
> A method that may work:
>
> Use CHGWSGA to activate logging and get the device name from the 
> QATMLOG file in QUSRSYS. You will need to know some value from the 
> interactive job but the device name or client IP address will do. You 
> can get the device name from the job field in the PSDS and the IP 
> address from the device description. This file gets a record for 
> session start and another for session end. The file in unkeyed so you 
> may have to build your own logical over it. Be sure you don't set a 
> unique key that will break WSG. Although unless you expect large 
> numbers of users to be signing on at the same same time time you 
> should be able to position to the end of the file and read backwards 
> until you find the starting record for the current device.
>
> The reason I say 'may' work is because WSG will rename this file when 
> it becomes full. You'll need to experiment a bit to determine exactly 
> what WSG does with this file. There is some documentation in the 
> TCP/IP Configuration Reference but it's sparse.

Sounds  less than perfect.

> A method that will work:

Excellent!

> Use the DSM APIs to query the device capabilities and if it supports 
> the HTML keyword then it must be a browser (or at least a suitable 
> device). This approach is probably the best because that is what you 
> really want to know. Does the device support HTML. This will work with 
> WSG and any other client that supports HTML 

This seems good to me.  As I have rarely found that API's with a 
functionality of use to me and which I hadn't already coded years ago, 
before the days of API's , the only ones that I have used relate to the 
IFS.  As a result, I don't know my way around the documentation these 
days (it was much simpler many years ago when the system came with 
printed manuals, the API one being several inches thick).

> such as Arterial Software's aXesTS client. Note: You might want to 
> consider this as a replacement for WSG rather than embarking on a 
> complete CGI implementation.

I didn't know about this.  I have had a quick look at this and it sounds 
very interesting.   I will give it a try. 

Many thanks for all your help.

Rob Dixon