T.R | Title | User | Personal Name | Date | Lines |
---|
1760.1 | set watch ? | UTRTSC::SCHOLLAERT | DEC 1000 AXP for me please | Thu Nov 12 1992 11:21 | 14 |
| Hoi Martin,
How is live in the far south of Holland ?
I ran FCR with set watch. Do the same and compare it with
FILE_CABINET_REPORT_SM.LOG1992111220000000 on UTRYIT.
See you,
Jan
CSC Holland Central
|
1760.2 | Set watch results | UTRTSC::SMEETS | Martin Smeets DS SSO Utrecht (NL) | Thu Nov 12 1992 12:14 | 23 |
| Hi jan,
I already did run FCR with the set watch utility.
The customers has four mail areas OA$DAF_A.DAT, OA$DAF_B.DAT, OA$DAF_C.DAT and
OA$DAF_E.DAT.
First I had the situation that after opening correctly OA$DAF_C.DAT I've got the
error mentioned in .0
Last weekend the system manager rebooted the ALL-IN-1 cluster via autogen
because he needed to adjust some systemparameters.
Yesterday I ran FCR again and the message did appear after opening correctly
OA$DAF_B.DAT.
Maybe, there's something wrong with system parameter values
Greeting from the rainy but most of the times sunny south.
Martin
|
1760.3 | FCR problem opening SDAFs | SIOG::T_REDMOND | Thoughts of an Idle Mind | Fri Nov 13 1992 14:12 | 32 |
| The error is coming from a sub-routine that attempts to open all of the
known SDAFs on a system.
Is there a duff record in the SDAFs master file? For example, is a
record pointing to an SDAF that doesn't exist or is in the wrong
location?
Tony
Code extract:
1600 ! ALL-IN-1 V2.3 allows a system to have up to 5 SDAFs. To
! find out which ones are available on this target system we have to
! open the SDAF master file and read down through it to see what's
! around.
! Once we find something we can open it.
until end_of_sdaf_master%
get #11%
daf_file_spec$ = trm$(daf_location$) + trm$(daf_file$)
1601 select daf_area$
1602 case "OA$SHARA"
open daf_file_spec$ for input as file 15% &
,organization indexed variable &
,allow modify &
,access read &
,map daf
daf_a% = 1%
case "OA$SHARB"
|
1760.4 | Found a bug in FCR | UTRTSC::SMEETS | Martin Smeets DS SSO Utrecht (NL) | Mon Nov 16 1992 09:53 | 40 |
| Hi tony,
> Is there a duff record in the SDAFs master file? For example, is a
> record pointing to an SDAF that doesn't exist or is in the wrong
> location?
No, there's isn't a duff record in the SDAFs master file.
But there's an error in FCR !!!!!
I can even reproduce the error.
I've a VAXstation with VMS 5.4-3 and ALL-IN-1 V2.4 (patch K603) and FCR.
I did the following tests:
1. Ran FCR with OA$SHARE active --> no problems
2. Created OA$SHARA, ran FCR with OA$SHARA and OA$SHARE active --> no problems
3. Created OA$SHARB, ran FCR with OA$SHARA, OA$SHARB and OA$SHARE active -> no
problems
4. Created OA$SHARC, ran FCR with OA$SHARA, OA$SHARB, OA$SHARC and OA$SHARE
active --> Error
5. Delete OA$SHAREC, ran FCR with OA$SHARA, OA$SHARB, OA$SHARE active -> no
problems
6. Created OA$SHARD, ran FCR with OA$SHARA, OA$SHARB, OA$SHARD and OA$SHARE
active --> Error
7. Delete OA$SHARED, ran FCR with OA$SHARA, OA$SHARB, OA$SHARE active -> no
problems
So running FCR with more than 3 mailareas open results in an error message.
Martin Smeets
|
1760.5 | | SIOG::T_REDMOND | Thoughts of an Idle Mind | Mon Nov 16 1992 17:36 | 7 |
| I'll check this on my system when I get home, but FCR V4 is out of
support (not supported) now that FCR V5.0 has shipped for ALL-IN-1
V3.0. Actually, FCR V4 was never supported as it was always provided
as a Solution Tool from ASSETS. FCR V5.0, on the other hand, is a PASS
and comes with support.
Tony
|
1760.6 | Works fine for me -- V5.0/5 SDAFs | SIOG::T_REDMOND | Thoughts of an Idle Mind | Tue Nov 17 1992 13:24 | 10 |
| I have now run FCR V5.0 on ALL-IN-1 V3.0 with 5 SDAFS (A through E)
open and active. No problems occurred.
I know that this isn't very helpful (the next version always fixes a
problem), but can you tell me what minor version number is reported by
FCR V4.1? There may be alater version of V4.1 available where the
problem was fixed. I sometimes took fixes across into V4.1 after
making them in V5.0, so maybe I can give you a new version...
Tony
|
1760.7 | FCR V4.1-003 | UTRTSC::SMEETS | Martin Smeets DS SSO Utrecht (NL) | Tue Nov 17 1992 16:23 | 7 |
| Tony,
It's FCR V4.1-003.
Regards,
Martin
|
1760.8 | Old versions die hard | SIOG::T_REDMOND | Thoughts of an Idle Mind | Tue Nov 17 1992 17:19 | 7 |
| The latest code I have for FCR V4.1 is V4.1-006 dated 2 March 1992.
I can produce a new version of the program if you want, but it will
have to wait until I get home (sometime next week). Is this for a
customer? If so, will they pay ;-)
Tony
|
1760.9 | Customers have to pay for "bugs" ? | UTRTSC::SMEETS | Martin Smeets DS SSO Utrecht (NL) | Thu Nov 19 1992 12:07 | 5 |
| Hi Tony,
Yes it is a customer, but I don't think they will pay !
Martin
|
1760.10 | | SIOG::T_REDMOND | Thoughts of an Idle Mind | Thu Nov 19 1992 14:50 | 4 |
| Well, then they'll have to wait until I get the chance to do some
unfunded work. I should manage to do this in late 1994.
Tony
|
1760.11 | Fragmented pagefiles | UTRTSC::SMEETS | Martin Smeets DS SSO Utrecht (NL) | Fri Nov 20 1992 09:07 | 9 |
| Hi Tony,
> Well, then they'll have to wait until I get the chance to do some
> unfunded work. I should manage to do this in late 1994.
Maybe you don't have to do any unfunded work. Could the error been a result of
low pagefile or badly fragmented pagefiles ?
Martin
|
1760.12 | | SIOG::T_REDMOND | Thoughts of an Idle Mind | Fri Nov 20 1992 11:25 | 5 |
| Maybe. I know that I tested multiple SDAFs when the program was
written, so maybe it is due to other system influences... like drink
(too much on the part of the system manager), or some other reason.
Tony
|
1760.13 | it was GBLPAGFIL | UTRTSC::SMEETS | Martin Smeets DS SSO Utrecht (NL) | Mon Apr 26 1993 10:19 | 5 |
| Finally, I've found the error. The problem was caused by a low GBLPAGFIL value.
So raising the value did the job.
Martin
|