Admin server error (8336) with PET, 9.1e, Windows Server 2008 combination

GuyYeates

GuyYeates

New Member
Got a problem after installing Progress 9.1E on a 32bit Windows Server 2008 machine (a test machine). When I open up the PET and log onto the localhost I then get an "Unable to connect to Admin Server ...(8336)" message. Task manager shows the service is still running. I'm missing something obvious. I've not found any obviously similar entries on this forum. I run progress with an account with admin rights but is not a full-blown network admin. When I run "proadvs -query" I get a 'java.exe' has stopped working message box. I could use the proserve command (as dbman requires the java.exe as well) so do you have any pointers or directions to resources on how to use it? So before I switch back to a 2003 OS, any ideas?

many thanks,
Guy

Here's where I'm at so far:
1) Dropped the contents of the install and Patch CDs onto two folders on the desktop. Choose to run the setup.exe from these folders.
2) During the insall, at the summary screen, I open task manager and use it to delete the "_ISDEL.EXE" task that's listed before pressing ok to continue. (I repeat the same trick when installing the 04 patch).
3) I then hack the registry (updating and adding the entries listed in "Alasdair's brain dump" blog entry of 2011/02/17).
4) I choose Progress Explorer Tool icon from the programs menu, right-click, and choose "run as administrator".
5) When the PET opens I select the local host entry, choose action|connect from the menu and after adding username and password I get the 8336 message.
 
I won't even ask why you're trying to run an unsupported configuration consisting of an ancient Progress on Server 2008, nor why you want to run your database on a 32-bit OS.

Progress Explorer doesn't work on Windows Server 2008. You can try to run Progress Explorer remotely on a platform where it is supported.

From the Availability Guide, Note N:
N. Progress Explorer fails to start on the Windows Server 2008 and Windows 2008 R2 platform– If you want to run Progress
Explorer you need to run it on a different operation system like XP, Vista or 2003. SEE PRIMUS ENTRY: P129948
Or
In 10.2B OpenEdge Explorer is now bundled into OpenEdge, which is supported on OpenEdge operating systems except for
SCO UnixWare. However, with 10.2A, OpenEdge Explorer can be downloaded from the Progress® Deployment Components
web site for customers who have licenses for products that entitle them to Progress Explorer.
​


From the KB:
Cause:
​

[TD="colspan: 2"]
The Progress Explorer uses a Microsoft Java component that Microsoft stopped supporting, and hence does not work with Windows 2008.​
[/TD]

[TD="colspan: 2"]


Fixes:
Progress Explorer does not work on the Windows 2008 operating system, both Windows 2008 32-bit and Windows 2008 64-bit. In order to administer the Administration Server running on a Windows 2008 machine, Progress Explorer needs to run on a separate Windows machine like Windows XP, Windows 2003, or Windows Vista.

The suggested workaround for OpenEdge 10.1C04, 10.2A01 and 10.2B use the OpenEdge Explorer utility. Please refer to solution P142754 for more information about the OpenEdge Explorer utility.

Alternatively, run the Progress Explorer on a different Operating System like XP, Vista or 2003. Windows 2008 is a "Server" operating system, so typical networks will have a client PC that can connect to the Windows 2008 machine. This client PC would be a good candidate for installing Progress Explorer to administer Windows 2008 databases and servers.

NOTE: This does not include the running of associated command line utilities such as: dbman wbtman nsman asbman
​
[/TD]
 
Our Windows 2003 server died so I thought I'd switch to virtual and use our current baseline OS which is 2008. Did a bit of research knowing that Progress 9 and Server 2008 don't see eye-to-eye - hence the fixes. But looks like the java seems to be the issue as utilities such as dbman etc complained about the java.exe. So today I've had the server re-built as a 2003 and off we go.

We would love to run on 64bit but I believe we'd need to buy it as a new product - hurdle #1
The issues with 2008 and Progress 9 has spurred me on to re-start a project to upgrade from 9 to 10.2. We've had -nb issues prior to version 10.2 so if that hurdle can be cleared then we'll run on 2008 on 32bit (unless someone can supply proof positive that 64bit wipes the floor with 32bit).

many thanks for you reply anyway.

Guy
 
Had the same ajax error messages come up when the virtual server running Windows 2003 rebooted (I was getting these with the Server 2008 version). This time I had a look at the "Data Execution Protection" and I set DEP to "Turn on DEP for essential Windows programs and services only". Re-booted the server. This time no Java.exe message boxes. Now the Progress Explorer Tool works as expected. I've concluded that DEP was the core issue on the Server 2008 machine. Oh well, lesson learned. Now back to planning my Progress upgrade: 10.2B or 11 ?
 
GuyYeates said:
We would love to run on 64bit but I believe we'd need to buy it as a new product - hurdle #1
The issues with 2008 and Progress 9 has spurred me on to re-start a project to upgrade from 9 to 10.2. We've had -nb issues prior to version 10.2 so if that hurdle can be cleared then we'll run on 2008 on 32bit (unless someone can supply proof positive that 64bit wipes the floor with 32bit).
Click to expand...

I don't understand this. The -nb parameter defaults to 90 in 10.2B, and can increase on the fly up to 255. As far as I know there is no difference here between 32-bit and 64-bit OpenEdge. If you need more nested blocks than that I think you should be reviewing your code.

I'm not sure that you will see 64-bit "wiping the floor" with 32-bit. This implies to me you're looking for a performance boost. However unless you're running very small (and very few) databases, the virtual memory address space limitations of 32-bit Windows will constrain your buffer pool. 64-bit OE on a 64-bit OS is where you want to be for the database. The only potential "gotcha" is that there is no 64-bit GUI Windows client. So if you need to run GUI clients, they are either on a separate box or they connect client/server.
 
GuyYeates said:
Now back to planning my Progress upgrade: 10.2B or 11 ?
Click to expand...

That depends on what you need, and when. We'll have 11.0 soon, but not yet. And with the number of changes that come in a major release, I wouldn't be surprised to find a few regressions. Whereas 10.2B is pretty mature after 5 service packs.

So, do you need any functionality that is only in 11? And can you afford to wait until it is delivered and you have a chance to do your shake-down testing? If not, go with 10.2B.
 
-nb parameter
We have users that write 'freeform' search statements that are long, include many terms separated with "OR" and "AND NOT" together with a heft quantity of brackets and include other search statements (similar to an include file model). These statements are put through a parser tool to create FIND/FOR EACH structures that are applied to the database. A consequence of this parsing is a nesting of these 'FIND or FOR EACH' statements causing the -nb soft limit to be regularly exceeded in Progress 9. When we last tested an upgrade to OE10.1 too many of the these searches statements failed as the hard limit was only 50% that used in Progress 9. The scale of the problem put the business off from backing an upgrade. OE10.2 has a higher hard limit to the -nb parameter: "a change in the way -nb is calculated" was how it was phrased. I'm hoping to use the incompatibility between Progress 9 and Server 2008 as leverage for re-starting the upgrade project subject to priorities elsewhere.

64bit v 32bit
A swap from 32 to 64 bit would require additional licence purchases (? I may be wrong here) and that extra cost would have to be matched against greater performance. We only have 50 users of which only 10 are using Progress regularly (client/server) and the batch jobs take care of the 'heavy' work on the database server although they do use a GUI. Would an increased buffer pool in a 64bit environment improve things dramatically.

I certainly agree with your point that code re-design and even database restructure could give us the greatest gain in performance for effort expended.
 
If your annual maintenance is paid up changing platforms is free.

Servers should be 64 bits. The main benefit is that you can actually address all of the memory that your server has. With a 32 bit executable you are limited to 2GB. When was the last time you bought a phone with only 2GB in it? Remember Windows 3.11 and 16 bit code? It is past time to move to 64 bits.

As for -nb... are you using -hardlimit? Did you set -nb to some value? Or are you allowing it to default? IMHO someone didn't understand what was going on there -- there is no way that the situation that you describe should have been a barrier to upgrading.

The query parser that you describe could also probably use some modernization.
 
Tom,
many thanks for your input. Our annual maintenance is up to date so the cost issue about switching to 64bit is good news, and yes your comment "...It is past time to move to 64bit" is definitely applicable to us. We are not using "-hardlimit". The net result of using -hardlimit or allowing the session to hit its natural uppermost limit appears to be the same: an untrappable STOP condition. Is this true? If we use -hardlimit and set the client -nb to 255, would the STOP condition be triggered at a -nb value of 255?

Guy
 
The following code recurses 1,000 times. I ran it on 10.2B. I had to increase -s but did not change -nb.

Code: 
define input parameter d as integer.

if d < 1000 then
  do:
    display d with row 1 column 1 overlay.
    run ./recurse.p ( d + 1 ).
  end.

display d.
if d = 1000 then pause.
return.
 
Got this from George back in 2007 when this issue first raised it's head with us. Could you try it with 10.2B and see what max value of -nb is acheived in the log file?

prowin32 started with -s 100000 -noincrwarn.
Run:
DEFINE VARIABLE i AS INTEGER INITIAL 0.

PROCEDURE recur.
ASSIGN i = i + 1.
OUTPUT TO VALUE("recur.log").
PUT UNFORMATTED i SKIP.
OUTPUT CLOSE.
RUN recur.
END PROCEDURE.

RUN recur.
-------------

Result - session dies with error 1:
bfblst -- Too many block levels. Increase -nb parameter. (1)

Max number of recursive calls:
2698 10.1A
5418 9.1E
 
With -s 100,000 I got to 19,984.

So far as I can tell the only limit is with -s. And the limit on -s is supposedly 5,242,878.
 
Cor! Progress realy did change the way they calculate -nb !! Looks like there's plenty of "elbow-room"....perhaps too much.
I'm now just about to write to my sales rep. at Progress about testing 10.2B in the next few months.

Many thanks for running this test and your other advice and the feedback from Rob Fitzpatrick.
It was much appreciated.

Guy
 
You must log in or register to reply here.
Back
Top