Hi all.

I have created a nice Login Screen using an INET function. Works well. It then calls another INET function to verify password etc. This time we get that unhappy sound that something is wrong. Sure enough, try and run Open Insight and I get the Attempt to log in too many users message. At this stage, I have to reboot computer to clear it. I have set up the registry for a Dynamic Engine (ShutdownSessios=1). It appears not to be closing the engine after the first log-in screen. Is there something I am supposed to do to at the end of an INET function to tell it to close the engine, or should that happen automatically?

Hello Robert,

First off, just to confirm your registry setting is ShutdownSessions=1. I'm hoping the typo was just in the post. As for INET functions, just return a variable that contains your html code in order to close it correctly.

Can you confirm that the dynamic engine that gets created to load the login screen does not close? If so, check to see if it is processing or idle. If it is processing, see what it is working on and if you can force it to the debugger.

psimonsen@srpcs.com

SRP Computer Solutions, Inc.

Hi Paul

Yeah ok, I can't spell / type. It is ShutdownSessions=1.

Re confirming that it has shut down, how would you suggest I do that? I can tell you that I can't find it in the task manager (Ctrl-Alt-Del). I can close all the Internet Explorer windows and everything else. Nothing at all shows in the Task manager, so I can't shut anything down there. I simply double-click on the usual OI icon (with the /dv switch), and that's when I get the Attempt to log in too many users message. Logging off doesn't clear it. Only Restarting.

The Inet function is simply returning the HTML code, so it sounds like I was right to assume that the Engine should auto-close at that point.

Robert

Roert,

When you check your Task Manager are you also looking in the Process tab for any OI components that load but don't appear in the Applications tab?

For the sake of testing/debugging, have you tried create a persistent engine? If there is a bug in your INET routine this might help you locate the source.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Hi Don

Bug in my INET routine? We have a strict policy against bugs in this establishment .

Ok, I have just learnt the expected behaviour of OECGI when it encounters a runtime errror (variable unassigned in this case). Debugging an INET routine looks like taking a trip down memory lane to the dim dark past before debugging tools were invented. In this case, not even an error message generated.

Ok, I know the rules now - I can handle that. I wonder if future releases will focus on improving feedback in this scenario.

Thanks Don

Robert

7.1 does a better job of handling VNAVs.

Pat

Hi Pat

Actually I am using 7.1.0.

What is it supposed to do? I did check the oiprofile.log file and didn't tell me anything relevant.

Robert

Robert,

You to have the debugger disabled. One way to do this is to rename off REVDEBUGG.DLL.

Pat

Robert,

There are a couple of ways you can get error information in OECGI in 7.1.

1) Interactive debugging. Launch a copy of OI on your server so it's running on the desktop. You can set the engine name via the /SN argument. Then set you OECGI to use the engine created by OI. When you hit a error condition the debugger will open and you'll get all the normal info you'd expect to see.

One of the main problems with debugging dynamic OECGI engines is that the process does not run in a normal desktop context. If the debugger opens during the process it opens on an 'invisible' desktop and appears to hang. This is why you need to link to an engine that *is* running already on the desktop.

2) Runtime debugging. As Pat mentioned the debugger needs to be turned off to do this. You can either rename REVDEBUG.DLL or set the system environment (field or use the DB Manager) to turn off the debugger. If you do this any information from the debugger should be returned in an HTML page (as used to happen in OICGI.)

There's also another case where your engine might appear to hang. Sometimes, when you log into your OI system you may get a message regarding problems attaching volumes or that the user count has been exceeded. This message is actually generated from the engine. If you launch the engine outside of the normal desktop context (e.g. from a web-server OECGI call ) the engine tries to display this message, but as it's not on the desktop you never see it so you can't dismiss it, therefore your engine appears hung. OI 7.1 has an extra flag you can use when setting the OECGI CreateFlags argument in the registry which should prevent this.

 equ CREATE_ENGINE_NO_UI$ to 0x40

So you can add this value to your existing createFlags argument and see if this makes a difference.

The Sprezzatura Group

World Leaders in all things RevSoft

Sometimes, when you log into your OI system you may get a message regarding problems attaching volumes or that the user count has been exceeded. This message is actually generated from the engine. If you launch the engine outside of the normal desktop context (e.g. from a web-server OECGI call ) the engine tries to display this message, but as it's not on the desktop you never see it so you can't dismiss it, therefore your engine appears hung. OI 7.1 has an extra flag you can use when setting the OECGI CreateFlags argument in the registry which should prevent this.

Is this the solution that was created specifically for this problem? I thought work was being done to make that a timed message instead so the engine wouldn't stay permanently hung.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

We are not aware of any other fix being worked on but we are not omniscient… that's just Andrew's delusions at work :]

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Thanks Sprezz.

On to it as usual.

R

why can't the engine figure this out by itself? Doesn't windows know how a process was started?

View this thread on the forum...