| Title: | *OLD* ALL-IN-1 (tm) Support Conference |
| Notice: | Closed - See Note 4331.l to move to IOSG::ALL-IN-1 |
| Moderator: | IOSG::PYE |
| Created: | Thu Jan 30 1992 |
| Last Modified: | Tue Jan 23 1996 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4343 |
| Total number of notes: | 18308 |
IOS 2.4 and K602 on VMS 5.5-1 Intermittent errors on FCVR runs when it complained about : Error opening A1DISK:[OA$SHARE]OA$DAF_E.DAT, error = ?Cannot open file Terminating Program in early part of Phase 3. This system was using all 5 areas A-E and Phase 2 happily processed all 5 areas reporting a number of records of each area, e.g. Processing USERDISK8:[OA$SHARA]OA$DAF_A.DAT file at 03:25 AM Processing USERDISK7:[OA$SHARB]OA$DAF_B.DAT file at 03:26 AM Processing USERDISK7:[OA$SHARC]OA$DAF_C.DAT file at 04:06 AM Processing $1$DUS7:[OA$SHARD]OA$DAF_D.DAT file at 04:44 AM Processing A1DISK:[OA$SHARE]OA$DAF_E.DAT file at 05:07 AM then moved on to PENDING I found from the Internals manual that Phase 3, in addition to rewinding the master SDAF file, it does that to the SDAF memory table as well. Any quick way of telling if the error did occur at one of these tasks ? The customer did try to explicitly specify all these areas in submitting TRM run but had same error. Their SDAF master file and RMS file specs matched OK and the logical used by OA$DAF_E was valid. I was told there's no bad SDAF record in this area but haven't got around to verify it myself. Thanks for advices Hong CSC Sydney
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2015.1 | IOSG::MAURICE | Is there life on IOSG? | Thu Dec 24 1992 12:23 | 12 | |
Hi Hong,
First advice is to get patched up to date!
I vaguely remember this problem occurring if the customer types in the
shared areas to be processed on the schedule form, but puts them in the
"wrong" order, e.g. A,B,C,E,D. I think this got fixed in one of the
later patches.
Happy Christmas
Stuart
| |||||
| 2015.2 | seeking more advices on FCVR job failure | GIDDAY::LEH | Wed Jan 20 1993 04:26 | 56 | |
Stuart
Back to original problem after customer's holidays
Some more interesting things have since then emerged:
o the list of SDAFs was always in alphetical order
o latest run with all SDAFs specified as physical devices but still failed at
same point in Phase 3, i.e.:
Error opening $1$DUS3:[OA$SHARE]OA$DAF_E.DAT, error = ?Cannot open file
Terminating Program
Other areas were on $1$DUS7 and $1$DUS8
o customer wasn't sure but noticed since the addition of the 5th area, the
last specified area in form SM_SKEDFORM_FCVR_MAIL_AREA, which is OA$DAF_E,
wasn't accessible, as in above error.
Historically, OA$DAF_E was used under 2.3 and this site created additional
areas OA$DAF_D, OA$DAF_C, OA$DAF_B and finally OA$DAF_A when this problem
occurred. Prior to this creation date, about 11-Nov-92, accessing other 4
areas was never a problem. Patch K602 was also put in before this date.
o I noticed while dialling in something was amiss in the files in
OA$ADMIN_DATA, that stored the list of SDAFs to be processed. It was the
second last field, OAFCVR_SHR_SUB_FILE, in form SM_FCVR_SCHEDULE.
Those indexed files seemed to have contained the incomplete list of SDAFs
despite of their being specified in the entry form. Examples for these files:
One file contained only 3 areas
1 OA$SHARA
2 OA$SHARB
3 OA$SHARC
4
while the other 2 contained only 1 area
1 OA$SHARA
2
Was my assumption correct that they should have stored all 5 SDAFs if the
latter were specified in FCVR entry form ?
Tracing wouldn't be very useful thanks to the .EXE being utilized. Any other
advices are appreciated
Hong
CSC Sydney
| |||||
| 2015.3 | More | IOSG::MAURICE | Because of the architect the building fell down | Wed Jan 20 1993 13:14 | 16 |
Hi Hong,
Three things:
1. Do a $dir oa$lib:OA$SM_FCVR.EXE and check that there is only one
version. Some sites have run into problems by running an old
version.
2. Next time TRM is run leave the list of SDAFs blank. This will signal
that all SDAFs are to be processed.
3. Get those patches on!
Cheers
Stuart
| |||||