Progress Explorer Tool

[David Lewis]

Good Evening,

SyteLine 6.01
Progress 9.1C18

We currently have our databases running with ProControl. I’ve created a new
multi-site structure with 6 new databases, and I’m having difficulty getting
these databases I’ve created to start with ProControl, so I thought I would
try using Progress Explorer Tool. This is on a Windows Server 2012 machine.
I’ve set up Progress Explorer Tool to run in Windows Compatibility mode for
Windows XP, and I’m running as administrator. When attempting to run
Progress Explorer Tool, after a few seconds I get:

A problem caused the program to stop working correctly. Windows will close
the program and notify you if a solution is available.

Is Progress Explorer Tool compatible with Windows Server 2012?

Thanks, Dave

[David Lewis]

I looked at the Event Log, and this is the error when trying to run Progress
Explorer Tool:

Faulting application mmc.exe, version 6.0.6002.18005, time stamp 0x49e01c0a,
faulting module unknown, version 0.0.0.0, time stamp 0x00000000, exception
code 0xc0000005, fault offset 0x06b1b9c4, process id 0x1758, application
start time 0x01d135629c9efb45.

[Chris Ruprecht]

no in 9.1c ...

trying to run an ancient version on a fairly recent operating system isn't recommended. i wouldn't run 9.1c on anything newer than win 2003. if you do, all bests are off.

if you must run dos 2012, use oe 11.3 or 11.6.
if you must run 9.1c, use dos 2003 as an os.

best regards,
chris
--
chris ruprecht · independent thinker

email: crup...@progress.com · direct number: +1 678 225 6327

> On Dec 13, 2015, at 10:34, Marcos Kirchner <marcos....@totvs.com.br> wrote:
>
> It's not compatible. Try OEExplorer:
> http://your-server:9090/
>
>
> -----Mensagem original-----
> De: David Lewis [mailto:dlewi...@msn.com]
> Enviada em: domingo, 13 de dezembro de 2015 03:18
> Para: d...@peg.com
> Assunto: Re: Progress Explorer Tool

[Chris Ruprecht]

it's all dos. some have a gui, some don't.
dos = desktop operating system. that means, no server either. why people bother with it to run databases on, i never understood. such a painful mess.

best regards,
chris
--
chris ruprecht · independent thinker

email: crup...@progress.com · direct number: +1 678 225 6327

> On Dec 13, 2015, at 13:11, Marcos Kirchner <marcos....@totvs.com.br> wrote:
>
> Right, 9.1C, I missed that. Sorry.
>
>
> Never knew there was dos 2012 or even 2003.
> As far as I knew the last one was DOS 6 :)
>
>
>
> Regards,
> Marcos
>
>
> -----Mensagem original-----
> De: Chris Ruprecht [mailto:crup...@progress.com]
> Enviada em: domingo, 13 de dezembro de 2015 13:58
> Para: d...@peg.com
> Assunto: Re: RES: Progress Explorer Tool

[Grant Maizels]

Hi David,

I always (almost) agree with Tom, and while I've actually been there and done this, what he said is correct (but it was not practical in my situation).

I support a system with Syteline 6.somehting on 9.1D09 on Windows 2012.

Actually the clients are still on 9.1C18

We upgraded from 9.1C to 9.1D because of the strent error where the client server servers have a memory leak and fall over frequently.

Anyway, I got some advice from PEG and to get Progress Explorer working you need to.
1. install Progress using "Run as administrator". A user in the administrator group is not enough.
2. every time you run it you need to right click and go "Run as administrator".

This worked for a few weeks/months and then it stopped working again.

Now I use dbman -start <dbname>, etc from the command line. It works reasonably well.

Occasionally the databases don't register with the admin sever properly and my monitoring goes haywire. I will be restarting a database in a couple of hours to fix an instance of this.

Grant

-----Original Message-----
From: Tom Bascom [mailto:basco...@gmail.com] On Behalf Of Tom Bascom
Sent: Monday, 14 December 2015 3:00 AM
To: d...@peg.com
Subject: Re: Progress Explorer Tool

Procontrol does not work with modern operating systems. If I recall
correctly it does not even work with Windows XP.

You probably don't want to hear it and I am likely tilting at windmills
but version 9 is ancient, obsolete and unsupported. 9.1c18 is even worse
than that.

You should upgrade. Someone obviously sees the value of upgrading
Windows... why not Progress?

Is this application at all important to the smooth running of the
company? Is it critical to the company's very survival?

Version 9 isn't just unsupported - it is insecure and not suited to the
modern IT environment. It was designed nearly 20 years ago for a very,
very different world. There are many reasons that you are no longer
running Windows 98, IE 4 or Oracle 6 and so forth. Why should Progress
be any less subject to those considerations?

Yes, it is well known that "syteline won't support anything else" is the
standard mantra from support.

That is also not exactly true.

0) Requiring 9.1c18 is not what any rational person would call "support".

1) Other people are in fact running syteline 6 on more modern releases
-- sometimes they even post here.

2) If you can compile the code you can upgrade to the most recent
release of Progress (11.6 as of this writing) and be just as "supported"
as you are right now.

The most common real reason that people have for still being on version
9 is that they stopped paying maintenance and have thus lost access to
upgrades. That is not an unrecoverable situation. It is possible to
work with Progress (and/or Infor) and fix that. Yes it will cost money.
Presumably you are running the application in a business so spending
money for value received shouldn't be mystery.

If this application is at all important to the company it really
shouldn't take a lot of convincing.

--
Tom Bascom
603 396 4886
t...@greenfieldtech.com


CAUTION - This message may contain privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify Orora immediately. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of Orora.

[David Lewis]

Thanks Grant and Tom for your input. We're probably going to upgrade to SL9
eventually, by then perhaps SL10 will be out. In the event that we don't,
I'll suggest that we try upgrading our version of Progress, and I'll try
compiling all of the SyteLine code with the new version of Progress in a
test environment. ProControl does work for our live databases, and also a
set of Test databases that are a copy of Live, but when I try and and start
one of the new databases, as soon as I click Start, I get dbname ERROR. I
do have the databases running using a batch file. The only thing I don't
like about that technique is that each time I end my Remote Desktop session
to the server, I have to terminate the session by clicking X in the upper
right corner instead of gracefully logging off. If I log off, the databases
stop.

Thanks again!
Dave

[David Lewis]

Good Evening,

I think I'm getting close on this one. When I run this batch file, I'm
getting:

Unable to locate database plugin insure adminserver is running and is
properly configured <DBMan023>

Here is the batch file I'm testing starting a database with dbman:

set DBDIR=D:\SL60100.NEWtest.db
set DLC=D:\Progra~1\Progress91c
rem call %DLC%\bin\dbman -database %DBDIR%\HSM -start -B 2000 -H
syteline01 -S HSM -N TCP -L 10000 -n 200
call %DLC%\bin\dbman -host syteline01 -port 31480 -database
%DBDIR%\HSM.db -start
pause

Here is my conmgr.properties file:

#
# Connection Manager Properties File
#
%% Juniper Properties File
%% version 1.1
%% 01-Apr-90 4:02:09 PM

#
# The following are optional configuration
# properties and their default values.
# The legacy option, if applicable,
# is listed after the second comment.
# Property values set at this level become
# the default values for all configuration
# subgroups.
#
[configuration.symix.defaultconfiguration]
database=HSM
displayname=defaultConfiguration
locktableentries=100000
maxservers=80
maxusers=300
otherargs=-B 100000
servergroups=symix.defaultconfiguration.defaultservergroup,
symix.defaultconfiguration.sqlservergroup
sharedmemoryoverflowsize=32
spinlockretries=8000

# afterimagebuffers=5 # -aibufs
# afterimageprocess=false # n/a
# afterimagestall=true # -aistall
# asynchronouspagewriters=1 # n/a
# beforeimagebufferedwrites=false # -r
# beforeimagebuffers=5 # -bibufs
# beforeimageclusterage=60 # -G
# beforeimagedelaywrites=3 # -Mf
# beforeimageprocess=true # n/a
# blocksindatabasebuffers=0 # -B (calculated as 8*(-n))
# casetablename=basic # -cpcase
# collationtable=basic # -cpcoll
# conversionmap=convmap.cp # -convmap
# crashprotection=true # -i
# databasecodepage=basic # -cpdb
# directio=false # -directio
# hashtableentries=0 # -hash (calculated as (-B)/4)
# internalcodepage=iso8859-1 # -cpinternal
# locktableentries=10000 # -L
# logcharacterset=iso8859-1 # -cplog
# maxservers=4 # -Mn
# maxusers=20 # -n
# nap=1 # -nap
# napmax=1 # -napmax
# pagewritermaxbuffers=25 # -pwwmax
# pagewriterqueuedelay=100 # -pwqdelay
# pagewriterqueuemin=1 # -pwqmin
# pagewriterscan=1 # -pwscan
# pagewriterscandelay=1 # -pwsdelay
# semaphoresets=1 # -semsets
# sharedmemoryoverflowsize=0 # -Mxs
# spinlockretries=0 # -spin
# sqlyearoffset=1950 # -yy
# watchdogprocess=true # n/a

# The following are optional database
# properties and their default values.
# Property values set at this level become
# the default values for all database
# subgroups.
#
[database.HSM]
autostart=true
configurations=symix.defaultconfiguration
databasename=D:\sl60100.NEWtest.db\HSM.db
defaultconfiguration=symix.defaultconfiguration
displayname=HSM

# autostart=false # autostart the defaultconfiguration?
# databasename=demo # absolute or relative path + database
name

# The following are optional server group
# properties and their default values.
# The legacy option, if applicable,
# is listed after the second comment.
# Property values set at this level become
# the default values for all servergroup
# subgroups.
#
[servergroup.symix.defaultconfiguration.defaultservergroup]
configuration=symix.defaultconfiguration
displayname=defaultServerGroup
maxclientsperserver=6
minclientsperserver=3
numberofservers=60
port=31480
type=4gl

# host=localhost # -H
# initialservers=0 # n/a
# maxclientsperserver=0 # -Ma (calculated value)
# maxdynamicport=5000 # -maxport (5000 for NT; 2000 for UNIX)
# messagebuffersize=350 # -Mm (4gl only)
# minclientsperserver=1 # -Mi
# mindynamicport=3000 # -minport (3000 for NT; 1025 for UNIX)
# networkclientsupport=true # false for self-service
# numberofservers=0 # -Mpb
# port=0 # -S ; Must be non-zero
# # when networkclientsupport=true
# prosqltrc=nnnnnnnnnnn # turn on various levels of SQL tracing
# reportinginterval=1 # -rpint (4gl only)
# serverexe=<4gl server location> # _mprosrv (4gl only)
# type=both # n/a

The port number in my services file is 31480. I'm able to start the
database using _mprsrv, but I prefer not to use this technique, because if I
log off of the database server, the database stops.

The Progress AdminService for Progress 9.1C is running as a Local system
account on the Log On tab. Could that be the problem?

Thanks, Dave

-----Original Message-----
From: Grant Maizels
Sent: Monday, December 14, 2015 1:09 AM
To: David Lewis
Subject: RE: Progress Explorer Tool

The logout problem is why we use the admin service and dbman.

Dbman just sends a message to the admin service to tell it to start the db.
Since the db is started by the service it does not stop when the user logs
off RDP.

You do need to set up the conmanager.properties (or something like that) in
%DLC%\properties.

Grant

[David Lewis]

Good Morning,

I was never successful at getting dbman to work with the conmgr.properties
file, kept getting a message that the Progress Admin Service wasn't
configured properly. However, I was able to get the databases to start with
ProControl. I had to log onto the database server as administrator to
accomplish this.

Happy New Year!

Thanks, Dave

-----Original Message-----
From: Grant Maizels

Sent: Monday, December 14, 2015 1:09 AM

To: David Lewis
Subject: RE: Progress Explorer Tool

The logout problem is why we use the admin service and dbman.

Dbman just sends a message to the admin service to tell it to start the db.
Since the db is started by the service it does not stop when the user logs
off RDP.

You do need to set up the conmanager.properties (or something like that) in
%DLC%\properties.

Grant

-----Original Message-----
From: David Lewis [mailto:dlewi...@msn.com]
Sent: Monday, 14 December 2015 3:21 PM