| Title: | ACMSxp product questions and comments |
| Notice: | Refer to notes 1 through 11 for conference information |
| Moderator: | DUCAT::ROSCOE |
| Created: | Tue Oct 05 1993 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 282 |
| Total number of notes: | 1134 |
Hello, I got a 'complaint' from a programmer that STDL compiling is taking so long. E.g. on an Alpha 2100 4/275 (OpenVMS V6.2-1H2) it takes about an hour to generate about 300 tasks. The STDL files themselves are about 720 blocks total in size. Is there any way of speeding up the compiling? I couldn't think of a way, but maybe someone has an idea? Cheers, Willem
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 267.1 | sounds like some customer training is needed | CAMINO::ROSCOE | Wed Mar 26 1997 00:18 | 51 | |
Before, I start in on what can be done I should let you know that I've
already answered this question from ECT. ECT asked the same question
through VX8000 and I responded to them, on March 17th. I guess they
have not yet received the information, so I'll state it again.
I would also suggest that ECT receive some training on developing
ACMSxp applications. Please ask the customer if they have received
such training. Training is available if they are willing to pay for it.
I consider it a bad design to have all 300 tasks in one task
server. Tasks should be grouped according to business functions.
ACMSxp has a feature called task-call-task. This implies that a
task can call a task in the same or different task groups.
If the task is in different task group that implies you are
calling another task server. This feature of ACMSxp is not
present in ACMS. Perhaps they are not aware of this feature.
In addition the documentation does a decent job of explaining
design decisions.
Assuming they must have all 300 tasks in the same task group
there are several things they can do.
1. Make sure the file sys$startup:decc$startup.com is run during
system startup. Make sure that the account that is doing the
compiling has sufficient quotas. For example are large working
set.
2. Compile the task group specification file separately
from the STDL code that implements the individual tasks.
If they are not adding or deleting tasks, or changing
task aruguments they do not need to recompile the task
group specification file. They are probably recompiling
the task group specification more than they need to.
3. Compile the task code definitions with the /task_only switch.
This implies that all referenced task and processing group
definitions must be compiled separately.
4. Break the task code definitions up into individual STDL source
code modules, or at least group them into smaller units. Use
MMS to decide which source code modules must be recompiled.
5. When they are just trying to get the STDL syntax to compile
have them compile with the /syntax_only switch. Using this
switch will just check the syntax but not actually cause any
output files to be produced.
If they implement these suggestions they should be able to cut the
compile time significantly.
Rich
| |||||
| 267.2 | What version of ACMSxp are they using? | CAMINO::ROSCOE | Wed Mar 26 1997 00:21 | 1 | |
| 267.3 | UTRTSC::WDEBAKKER | Feed your head | Wed Mar 26 1997 05:49 | 11 | |
Thanks for your reply. I've forwarded your suggestions to them. So I didn't even have to mention the name of the customer... (you were right, it's ECT) They're using ACMSxp 2.2 and DCE 1.3B Did they ask you also about a performanceproblem when repeating functions (memoryleak-like symptoms) ? The problem does not occur when the Processing Server is a Dummy. Willem | |||||
| 267.4 | DUCAT::ROSCOE | Wed Mar 26 1997 12:29 | 18 | ||
>>>Did they ask you also about a performance problem when >>>repeating functions (memoryleak-like symptoms) ? No, I've not heard of this. >>>The problem does not occur when the Processing Server >>>is a Dummy. If this means that they call the processing procedure and it does nothing but return, this implies that the problem is almost certainly with the code they wrote in the "real" processing procedure. Given that version 3.0 of ACMSxp on AlphaVMS has been out for a while can they upgrade to that version? It would be easier to support them on that version and they would be able to take advantage of several new features as well as better performance. rich | |||||
| 267.5 | UTRTSC::WDEBAKKER | Feed your head | Wed Apr 02 1997 08:32 | 298 | |
Well, this is the code they're using:
/* DB_T_GETDELINSCNB.C
/*
/*----------------------------------------------------------------
*/
#include "n_src:vms_types.h"
#include "n_src:include.h"
#include <eclass.h>
#include <einfo.h>
#include "n_src:grp_civ_pilot.h"
static char *ModuleName = "DB_T_GETDELINSCNB";
static char *SoortFunctie = "select";
static long TransactionModeTest = TR_Write;
static struct wrk_dbkey * PODbKey;
static struct wrk_primkey * POPrimKey;
struct wrk_aantalrec UAantal;
/*
________________________________________________________________________________
*/
static
int UitvoerenTest(long ITransAantal)
{
int Status = FAE0101_SUCCES;
char ErrorTxt[128];
struct wrk_primkey LPrimKey;
struct wrk_cnb LCNBRec;
struct wrk_dbkey LCNBKey;
struct wrk_recpresent LRecordPresent;
static char *FunctionName;
LRecordPresent.recordpresent = True;
LPrimKey.cnbnr = POPrimKey[0].cnbnr;
FunctionName = "TstGetDelInsCNB";
mta01_getdelinscnb (&LPrimKey
,&LCNBRec
,&LCNBKey
,&LRecordPresent
);
if (einfo.eclass) {
Status = FAE0101_TASK_EXCEPTION;
sprintf( ErrorTxt, "Class = %d, Error code = %d\n", einfo.eclass,
einfo.ecod
e );
LogSysError(ModuleName,FunctionName,Status,ErrorTxt);
}
/*
FunctionName = "TstDelCNB";
mta01_delcnb (&LCNBKey
);
if (einfo.eclass) {
Status = FAE0101_TASK_EXCEPTION;
sprintf( ErrorTxt, "Class = %d, Error code = %d\n", einfo.eclass,
einfo.ec
ode );
LogSysError(ModuleName,FunctionName,Status,ErrorTxt);
}
else {
FunctionName = "TstInsCNB";
mta01_inscnb (&LCNBRec
,&LCNBKey
);
if (einfo.eclass) {
Status = FAE0101_TASK_EXCEPTION;
sprintf( ErrorTxt, "Class = %d, Error code = %d\n", einfo.eclass,
einfo.ecode )
;
LogSysError(ModuleName,FunctionName,Status,ErrorTxt);
}
}
}
*/
return Status;
}
/*
________________________________________________________________________________
_________________________
InitTest
________________________________________________________________________________
_________________________
*/
static
int InitTest()
{
int Status = FAE0101_SUCCES;
static char *FunctionName = "TstGetDelInsCNB";
POPrimKey = NULL;
PODbKey = NULL;
UAantal.aantal = 200;
if (NotStatusOk(Status)) {
LogSysError(ModuleName,FunctionName,Status,"Aanroep van
Settransaction");
}
else {
Status = MDB_LSTCNBNR(&POPrimKey
,&PODbKey
,&UAantal
);
if (NotStatusOk(Status)) {
LogSysError(ModuleName,FunctionName,Status,"MDB_LSTCNBNR");
}
}
if (UAantal.aantal < 1) {
printf("Geen gegevens om de test uit te voeren");
Status = FAE0101_NIET_VERWERKT;
}
return Status;
}
#include "n_src:Test_Acms_Main.c"
=====================================
/*----------------------------------------------------------------
/* DB_T_GETDELINSCNB.C
/*
/*----------------------------------------------------------------
*/
#include "n_src:vms_types.h"
#include "n_src:include.h"
static char *ModuleName = "DB_T_GETDELINSCNB";
static char *SoortFunctie = "select";
static long TransactionModeTest = TR_Write;
static struct wrk_dbkey * PODbKey;
static struct wrk_primkey * POPrimKey;
static struct wrk_aantalrec UAantal;
/*
*/
static
int UitvoerenTest(long ITransAantal)
{
int Status = FAE0101_SUCCES;
struct wrk_primkey LPrimKey;
struct wrk_cnb LCNBRec;
struct wrk_dbkey LCNBKey;
struct wrk_recpresent LRecordPresent;
static char *FunctionName;
LRecordPresent.recordpresent = True;
LPrimKey.cnbnr = POPrimKey[0].cnbnr;
FunctionName = "TstGetCNB";
Status = MDB_GETCNB (LPrimKey
,&LCNBRec
,&LCNBKey
,&LRecordPresent
);
if (NotStatusOk(Status)) {
LogSysError(ModuleName,FunctionName,Status,"Aanroep van
TstGETCNB");
}
else {
FunctionName = "TstDelCNB";
Status = MDB_DELCNB (LCNBKey
);
if (NotStatusOk(Status)) {
LogSysError(ModuleName,FunctionName,Status,"Aanroep van
TstDELCNB");
}
else {
FunctionName = "TstInsCNB";
Status = MDB_INSCNB (LCNBRec
,&LCNBKey
);
if (NotStatusOk(Status)) {
LogSysError(ModuleName,FunctionName,Status,"Aanroep van
TstINSCNB");
}
}
}
return Status;
}
/*
*/
static
int InitTest()
{
int Status = FAE0101_SUCCES;
static char *FunctionName = "TstGetDelInsCNB";
POPrimKey = NULL;
PODbKey = NULL;
UAantal.aantal = 200;
if (NotStatusOk(Status)) {
LogSysError(ModuleName,FunctionName,Status,"Aanroep van
Settransaction");
}
else {
Status = MDB_LSTCNBNR(&POPrimKey
,&PODbKey
,&UAantal
);
if (NotStatusOk(Status)) {
LogSysError(ModuleName,FunctionName,Status,"MDB_LSTCNBNR");
}
}
if (UAantal.aantal < 1) {
printf("Geen gegevens om de test uit te voeren");
Status = FAE0101_NIET_VERWERKT;
}
return Status;
}
#include "n_src:TestMain.c"
==================================================
#CINCLUDE "wrk_dbkey.stdl"
#CINCLUDE "wrk_primkey.stdl"
#CINCLUDE "wrk_cnb.stdl"
#CINCLUDE "wrk_recpresent.stdl"
#CINCLUDE "wrk_aantalrec.stdl"
#CINCLUDE "prc_civ_pilot.stdl"
#CINCLUDE "grp_civ_pilot.stdl"
TASK mta01_getdelinscnb
WORKSPACES ARE
wrk_primkey,
wrk_cnb,
wrk_dbkey,
wrk_recpresent;
TASK ARGUMENTS ARE
wrk_primkey passed as input,
wrk_cnb passed as output,
wrk_dbkey passed as output,
wrk_recpresent passed as inout;
BLOCK WITH TRANSACTION
PROCESSING
CALL PROCEDURE mps_getcnb
IN prc_civ_pilot
USING wrk_primkey,
wrk_cnb,
wrk_dbkey,
wrk_recpresent;
PROCESSING
CALL PROCEDURE mps_delcnb
IN prc_civ_pilot
USING wrk_dbkey;
PROCESSING
CALL PROCEDURE mps_inscnb
IN prc_civ_pilot
USING wrk_cnb,
wrk_dbkey;
END BLOCK
ACTION IS
EXIT TASK WITH COMMIT TRANSACTION;
END ACTION
EXCEPTION HANDLER IS
EXIT TASK WITH ROLLBACK TRANSACTION;
END EXCEPTION;
END TASK;
| |||||
| 267.6 | escalation seems premature | CAMINO::ROSCOE | Thu Apr 03 1997 03:29 | 13 | |
I assume you posted this code because this is the code that is
leaking memory? I did look briefly through the code and nothing
jumped out at me. Also some of the code used by the processing procedure
was not included. Since the customer has proven that the leak is being
caused by their code (the processing procedure does not leak when a
dummy routine is called) I suggest that they systematically stub out
various part of their code until they find the leak.
If the customer cannot find the leak perhaps local Digital
support personnel be contracted to help? It seems premature to
escalate this to ACMSxp Engineering at this point don't you think?
Rich
| |||||
| 267.7 | UTRTSC::WDEBAKKER | Feed your head | Thu Apr 03 1997 06:04 | 6 | |
Yes, thanks Rich.
I agree it's too early to escalate, I thought I'd just drop
the question. We'll investigate further.
Cheers,
Willem
| |||||