Conference iosg::all-in-1_v30

    Hi,
    
    Can you give a sample of the log.
    
    Thanks
    
    Stuart

Other than to prove my point this info will be useless to you:

The PT run log had:
-----
A total of 790 user accounts were processed.

199 corrupt accounts were detected, they are:

SMITHBW
SMITHC
SMITHDW   

  etc etc.   a list of 199 acct names.
-----

That's it. All the info it shows.  Based on this total lack of info as to
the problems that A1 is 'detecting', how do we get the details on a V2.4
system?

We need this ASAP.

Thanks,

	Al

    Hi,
    
    I know the V2.4 PT was bad but ...
    
    Are you sure you're looking at the correct log file. I think this
    utility produced 2 log files - one for the Manager and one the
    Administrator. The Administrator's log file just had the list of bad
    accounts, whereas the Manager's log file had the gory details as well.
    
    Do a $dir of OA$LOG and check that there are two log files.
    
    HTH
    
    Stuart

re: lack of PT detail:

We are aware of the 2 files per run, etc. (SA vs. SM).  The SA file had all
the user acct names listed, and the SM file had just the following
(summarized from a FAX From the customer):

All the batch startup stuff ( %START_BATCH-I Performing statrt batch
procedure for "PT"

%SMJACKET-I  Invoking utility command file
"OA$LIB:OA$SM_FCVR_PRE_PHASE1_SCHEDULE"  etc

%OA-I-LASTLINE,  12:15PM
%OA-I-LASTLINE,  12:24PM


	MANAGER finished using ALL-IN-1 at 04-Mar-1994 12:24pm

Error opening VPC$USR4:[ALLIN1.LIB_SHARE]PRE_FCVR.TRC; as input
File not found

%SMJACKET-I  Invoking common END_BATCH procedure
%END_BATCH-I  Performing End batch job for "PT"


then  Deleting old log files, etc.

So the only error was the -FNF- one listed above.  No other output was
listed or produced.

Regards,

	Al

    I ventured out late last night and went to the local cemetary. It was a
    cold night, but the moon shone bright, thus enabling me to find the
    stone I was looking for. Owls hooted, and in the distance I could hear
    the tormented howls of night creatures cursing their sentence to life
    on earth.
    
    I put the spade to work, and though the subject had been long buried,
    it was not long before it struck rotten wood. I lifted the lid and saw
    to my horror that the worms had got in. It seems as if they all as one
    turned to glare at me, daring me to pluck the forbidden secrets away
    from them. I felt their sliminess as I thrust my hand into the coffin
    and groped for the manuscript I knew to be there.
    
    I have it now. An evil and wretched document, that has saddened the
    lives of many men. It will have to be taken to the fire, but before
    that I have some of its secrets to relate. Later.

    In V2.4 the Pre-Test program was a .EXE written in BASIC and thus a
    closed black box. As related earlier, I obtained a copy of the source
    code. AT he end I found the lines:
    
    The_End:
             msg_buffer$ = str$(Corrupt_Account%)
             open "oa$lib:pre_fcvr.trc" for output as file #6, access write
             print #6, msg_buffer$
             close #6
    
    So it looks as if there should be a file called oa$lib:pre_fcvr.trc if
    PT managed to complete. It doesn't look as if there will anything
    useful in it.
    
    The mechanism it uses to write to the manager's log file is just a
    PRINT function, so the logging information is going to A1SUB.LOG. The
    outer .COM (OA$SM_FCVR_PRE_PHASE1_SCHEDULE.COM) uses DCL $TYPE to copy
    A1SUB.LOG to the log file. Perhaps another housekeeping procedure ran
    at the same time, and the wrong A1SUB.LOG file got TYPEd into the log
    file. 
    
    The list of possible errors is:
    
    WARNING - there is a blank user profile record
    
    User xxxx has a bad default directory -- (field DIRECT in Profile)
    
    Error detected with account xxxx -
    Account is using same directory as user yyyy
    
    WARNING: VMSUSR field not defined in profile of xxxxx
    
    WARNING: Invalid VMSUSR field defined in profile of xxxxx
    
    WARNING: LANGUAGE field not defined in profile of xxxxx
    
    WARNING: Invalid LANGUAGE field defined in profile of xxxxx
    
    Error detected with account xxxx Couldn't open xxxx's DOCDB 
    
    Error detected with account xxxx Couldn't open xxxx's DAF
    
    I hope that is enough so that we can bury it again.
    
    Stuart

We found the A1SUB.LOG file in the manager's acct with the "details"
listed, per your -.1 list of errors.

Some of the accts had no VMS user name filled in the VMSUSR field, some by
oversight by the customer, some on purpose to do the ugly sharing of an
acct.  I told them this will have to be changed or V3.

From the error listings, we also had some accts show up with "Invalid
VMSUSR field defined in profile of xxxx".  A call to CSC found these to be
caused by the UAF recs for those entries not having a Rightslist Identifier
defined, only a numeric value.  Added the /Idents and those cleared up.

The final remaining error is repeated in the log file for >100 accts in a
row, tarting around the mid-S's of the alphabet.  We figured it was a quota
of some sort.  Error was "Error detected with account xxx...Couldn't open
xxx's DAF.DAT file -- ?Cannot open file"

CSC thinks this is due to a low sysgen param  CHANNELCNT.  This site was
set to only 600.  There are 766 A1 entries.  We've got a reboot set for
tonight to boost the param to 1200.  Hopefully that will be the final
hurdle to getting all these cleaned up.

Thanks again for the humor and assistance resurrecting this old problem.

Regards,

	Al