| T.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 255.1 | version limit set ? | UTRTSC::BOSMAN | We're just sugar mice in the rain | Tue Mar 17 1992 10:34 | 4 | 
|  |     Do you have a version limit set on the directory where the log-files
    reside?
    
    Sjaak.
 | 
| 255.2 | No Version Limits set on directory.. | TAV02::CHAIM | Semper ubi Sub ubi ..... | Tue Mar 17 1992 13:29 | 7 | 
|  | Re: .1
There are no version limits set on this directory.
Thanks,
Cb.
 | 
| 255.3 | Check A1SUB.LOG files | IOSG::CHAPLIN | Andy Chaplin | Tue Mar 24 1992 10:01 | 6 | 
|  | It looks like the FCVR executable (which is run from the Manager's ALL-IN-1 
sub-process) is either exiting immediately or not running at all.  Check the 
A1SUB.LOG file from the run in Manager's ALL-IN-1 sub-directory - it will 
hopefully contain the error.
Andy
 | 
| 255.4 | Check list for Housekeeping jobs | GIDDAY::SETHI | Man from Downunder | Tue Mar 24 1992 23:40 | 29 | 
|  |     G'day Cb,
    
>***Error searching for $1$DUS32:[ALLIN1]SMLOG1.TMP;
>***File not found
>***Error opening $1$DUS32:[ALLIN1]SMLOG2.TMP; as input
>***File not found
    
    I would check the directory spec. for the ALL-IN-1 managers account. 
    It should be [ALLIN1.MGR] and I am taking a guess here that this could
    be the problem.
    
    Check to see if other Housekeeping procedures are failing with
    directory spec. problems.
    
    Also ask the customer if they have made changes to the various elements
    for the TRM Housekeeping procedures.  More often than not it's the
    case.  Don't take it at face value that they have not changed anything
    because it can waste time as I am finding out.
    
    So I would do the following :-)
                                                                        
    1. Check to see if the customer has made changes to the TRM elements
    2. Check if other Housekeeping procedures are failing
    3. Check the directory spec for the ALL-IN-1's managers account
    4. If the worse comes to the worse trace the problem with set verify
    
    Good Luck
    
    Sunil
 | 
| 255.5 | Not completely true ... | UTRTSC::BOSMAN | We're just sugar mice in the rain | Wed Mar 25 1992 09:07 | 8 | 
|  | �    I would check the directory spec. for the ALL-IN-1 managers account. 
�    It should be [ALLIN1.MGR] and I am taking a guess here that this could
�    be the problem.
    
    Not completely true, the manager's directory is in his PROFIL and
    A1CONFIG (base record). It worked for me with different values.
    
    Sjaak.
 | 
| 255.6 | About the SMLOG.TMP files | IOSG::CHAPLIN | Andy Chaplin | Wed Mar 25 1992 18:40 | 9 | 
|  |     FCVR will create the SMLOG%.TMP temporary files in the ALLIN1 account
    VMS login directory, unless the symbol OA$FCVR_FILES exists in the
    system PST.   It creates a logical OA$FCVR_FILES to reference them. 
    The fact that the schedule job can't find them is likely to be because
    the FCVR executable didn't/couldn't create them.
    
    The A1SUB.LOG file should give some more information.
    
    Andy
 | 
| 255.7 | A1$SUB.LOG shows OA$SM_FCVR is missing ... | TAV02::CHAIM | Semper ubi Sub ubi ..... | Thu Apr 02 1992 09:26 | 22 | 
|  | I think we got a hint....
A1$SUB.LOG shows an error in NOT finding OA$LIB:OA$SM_FCVR
This is a V2.3 system with patches including the FCVR patch.
In OA$lIB_SHARE he indeed does NOT have a file OA$SM_FCVR.EXE but rather
OA$SM_FCVR.EXE_DUMMY.
Looking in OA$SM_FCVR_SCHEDULE.COM shows a $RUN OA$LIB:OA$SM_FCVR (this is the
new patch version - the non-patched version had four run commands for each of
the OA$SM_FCVR_PHASEx.EXEs)
I reread the release notes for this patch and see that such a file is provided.
I could NOT find any instruction to rename this file or whatever.
At this stage what should he do?
Thanks,
Cb.
 | 
| 255.8 | Request for replies ... | TAV02::CHAIM | Semper ubi Sub ubi ..... | Wed Apr 08 1992 12:40 | 6 | 
|  | I know that issues in NOTES carry no commitment for replies, but I hope that
someone can please help me help OUR customer.
Thanks,
Cb.
 | 
| 255.9 |  | IOSG::MAURICE | IOSG ain't a place to raise a kid | Wed Apr 08 1992 17:59 | 12 | 
|  |     Sorry that your note did not get a reply. I've no idea where the file
    OA$SM_FCVR.EXE_DUMMY came from, gremlins I suppose. I suggest you get
    the real .EXE off the patch kit and put it where it's supposed to go
    which is OA$LIB_SHARE.
    
    There was a problem with K536 whereby it put it in OA$LIB, which would
    mean OA$SITE_LIB_LLV. Is it in there by any chance? If it is then move
    it to oa$lib_share.
    
    Cheers
    
    Stuart
 | 
| 255.10 | Will the REAL image please stand up ... | TAV02::CHAIM | Semper ubi Sub ubi ..... | Thu Apr 09 1992 06:13 | 5 | 
|  | Could someone post the SIZE and image I.D. for the real image?
Thanks,
Cb.
 | 
| 255.11 | K504 should have done LINK  ... | TAV02::CHAIM | Semper ubi Sub ubi ..... | Thu Apr 09 1992 08:23 | 17 | 
|  | I just read completely through the release notes for the TURBO FCVR patch
(K504). In it there is a specific referrence that a file oa$sm_fcvr.exe_dummy
IS supplied. 
I also looked through the patch kit itself and there is a command file to
perform a LINK of the real image. According to what I can see, this is done
during a preprocess phase.
HOWEVER, the example installation in the appendix of the release notes does NOT
seem to indicate that this is done. I myself installed the patch about a year
and a half ago. I do not recall receiving any errors during the installation.
Can anyone shed more light...
Thanks,
Cb.
 | 
| 255.12 |  | IOSG::MAURICE | IOSG ain't a place to raise a kid | Thu Apr 09 1992 13:56 | 12 | 
|  |     Hi,
    
    I think K504 is dead now (RIP). I recommend that you get K536 and install
    that. After installation you have to fix the K536 bug where it puts the
    .exe in the wrong directory (see .-3).
    
    I don't have access to K504 so I'm afraid I cannot answer .10, nor know
    why the link seems to have failed.
    
    Cheers
    
    Stuart
 |