AUTOGEN abort

[Martin Vorlaender]

Hi,

just saw an AUTOGEN abort at a customer's site. The environment: OpenVMS V7.3-2 with all but the most recent ECOs, SAVEDUMP=1 and DUMPSTYLE=9 set in the MODPARAMS file, and AUTOGEN having calculated a new size for the pagefile. Then:

%DCL-W-UNDSYM, undefined symbol - check validity and spelling
\DUMPFILE\

I resolved the situation by fixing the pagefile size in MODPARAMS, but I think this is an error in AUTOGEN.

cu,
Martin

[Uwe Zessin]

Interesting... I'm sure you know that there is a 'pseudo-parameter' in MODPARAMS.DAT
- DUMPFILE=size

I am a bit confused as the parameter is for SYSDUMP.DMP, but you talk about a pagefile.

[Martin Vorlaender]

Uwe,

the parameter SAVEDUMP=1 directs the system to write the dump to the pagefile. You then have to take action in the course of the system startup to e.g. copy it elsewhere, and free up the space taken in the pagefile.

The environment where this is useful is a space-constrained system disk.

cu,
Martin

[Martin Vorlaender]

Okay, so this is not quite correct. The dump is written to the pagefile when no dumpfile exists. SAVEDUMP governs whether the dump is retained until it is copied or released.

cu,
Martin

[Volker Halle]

Martin,

what did you 'fix' in MODPARAMS.DAT to make the problem go away ?

Volker.

[Martin Vorlaender]

Volker,

I set the pagefile size to a fixed value (I used the size it did have, but could have used 0), thereby inhibiting AUTOGEN to calculate a new size. Then the abort doe not occur.

cu,
Martin

[Volker Halle]

Martin,

I gave this a quick try unter OpenVMS Alpha V8.2:

- renamed dumpfile, so there is none
- added SAVEDUMP=1 into MODPARAMS.DAT
- DUMPSTYLE=9 is the default
- removed PAGEFILE=0 and DUMPFILE=0 from MODPARAMS.DAT
- @sys$update:autogen savparams setparams feedback

A new pagefile has been created in the GENFILES phase, but AUTOGEN did not abort.

So it's either fixed in V8.2 or there is some piece of information missing for this simple reproducer.

Volker.

[Martin Vorlaender]

Volker,

thanks for trying.

After a big computer room rebuild, I just put my VMS support machine back into action. Set SAVEDUMP=1 and DUMPSTYLE=9, deleted SYS$SYSTEM:SYSDUMP.DMP, shrank the pagefile from 270000 to 100000 blocks. Reboot, autogen, and BANG:

%AUTOGEN-I-BEGIN, TESTFILES phase is beginning.

Calculations for page, swap, and dump files.
--------------------------------------------

Errorlog dumpfile calculations:

No errorlog dump file modifications should be made.
Errorlog dumpfile will remain at 42 blocks.

Dump file calculations:
No dump file modifications should be made.
Dumpfile on device, VMSSPT$DKA100:, will remain at 0 blocks.

Page file calculations:

PAGEFILE1_SIZE information (for SYS$SYSTEM:PAGEFILE.SYS):
PAGEFILE1_SIZE will be modified to hold 270300 blocks
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
\DUMPFILE\
%AUTOGEN-I-ERROR, TESTFILES phase was aborted due to an unexpected error.
%SYSTEM-F-ABORT, abort

DIFF-ing AUTOGEN.COM vs. an 8.2 system indeed shows they worked on it (replace "Compaq" by "Hewlett-Packard" integrate Integrity platform, and other things...)

cu,
Martin

cu,
Martin

[Volker Halle]

Martin,

I've repeated your test with V8.2 and it did not fail. So it either seems to be fixed or the conditions for reproducing are still not met.

Volker.

[Jan van den Ende]

@Volker:

but the FAILING version was 7.3-2....

Sorry, no system available for that kind of testing momentarilt.

Proost.

Have one on me.

jpe

[John Gillings]

Martin,

Could you please package up your complete MODPARAMS.DAT file, and a transcript of the failing run of AUTOGEN and log a case with your local customer support centre.

There's obviously something wrong in AUTOGEN, but from the comments, I think we'd need to see the COMPLETE input file to work out what.

[Petr Spisek]

Martin,
it looks you have switch DUMPFILE defined to an incorrect value. Try to find in your sys$system:*.DAT string DUMPFILE. Correct use is DUMPFILE=0 to disable resize of sysdump.dmp in MODPARAMS.DAT, or remove this switch for changing size in phase SETPARAMS.

Petr

[comarow]

I always tell people to put
pagefile=0
dumpfile=0
swapfile=0
and only let autogen make your first pagefile.

$the command
Show mem/file show's pagefile use
You want it to be 50% free.
also, when you run
$autogen savparams
you can read agen$feedback.dat and look
at peak pagefile useage.


However, a bug in your autogen should be reported.

The real problem, and a real danger is over time the system disk becomes very fragmented, and autogen may try to increase the size of a pagefile. However, it can't and creates a tiny one. Your system is now in big trouble.

To change the size of your primary pagefile
@sys$update:swapfiles
will let you resize you swap, page and dumpfile.

In addition, you can create secondary pagefiles

mcr sysgen
sysgen create disk:[directory]pagefile2.sys/size= xxxx
then to use it
sysgen>instal disk:[directory]pagefile2.sys/page

Each of those commands should be in one line. The second command should be in your startup file.

Getting a secondary pagefile off the system disk usually improves performance.


If you get low on pagefile space immediately create a secondary pagefile and install it or you system will likely hang.
Get users to log out and log back in after creating it.

[Martin Vorlaender]

@Petr,

$ SEARCH SYS$SYSTEM:*.DAT DUMPFILE
%SEARCH-I-NOMATCHES, no strings matched

@Bob,

nice summary. Thanks. I second setting all 'pseudo parameters' to 0 once the files have been set up.

@All,

I reset the parameters to DEFAULT, reboot, did an AUTOGEN INITIAL, reboot, and the problem has gone away. Of course, this will not help my customer, but it's a sign that it's just some bad combination of values.

When I find the time, I'll go and dig up the differences in the parameter settings.

cu,
Martin

[Martin Vorlaender]

I wrote:
>>>
When I find the time, I'll go and dig up the differences in the parameter settings.
<<<

...but you never find the time...

Case closed.