| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2850.1 | Are you running V3.0-1? | CHRLIE::HUSTON | | Mon Jun 14 1993 21:18 | 9 |
|
What version of IOS are you running?
There was a problem with IOS mistakenly using FAL rather than the
FCS for some remote reads. ALL remote access should be done using
the FCS, I believe (Kevin??) that patch K701 fixed this problem.
--Bob
|
| 2850.2 | Under review | IOSG::CARLIN | Dick Carlin IOSG, Reading, England | Mon Jun 14 1993 23:53 | 18 |
| In V3.0 and V3.0-1 ALL-IN-1 uses FAL to read remote documents and FCS
to read remote messages. This is under review for the pfr.
Using the FCS for remote messages is essential (to raise privs to
access the remote shared area) and the ensuing copy to the local system
is usually not noticeable (messages are small on average).
For documents the situation is not so clear cut. The document could be
enormous, in which case the copy could be a big overhead when the user
only wants to look at the first few pages of it.
We also need to be able to access remote files which may not be the
content file of the current document. In this case we can't easily use
the FCS.
Anyway, as I said, we are looking at it.
Dick
|
| 2850.3 | DSO is very poor | BERN02::MUELLERS | Stefan A Mueller 761-4864 | Thu Oct 21 1993 11:34 | 11 |
| ...some weeks later...
I am playing again with the FCS and DSO and found a 'workaround' to
access documents from a remote FCS: Add FAL$SERVER to the access list
with read access. This means, DSO is nearly unusable, because access
over the network can only be granted for *WORLD.
Any suggestions?
Stefan
|
| 2850.4 | FCS does not use FAL | CHRLIE::HUSTON | | Thu Oct 21 1993 15:51 | 9 |
|
I don't mean to pick nits, but this is a sore spot with me (and the
rest of the former FCS team). You are not having a problem with the
FCS you are having a problem with IOS not using the FCS for what it
should be using it for. ANything involving FAL$SERVER is not an FCS
issue.
--Bob
|
| 2850.5 | Should use FCS, why be inconsistant ? | IOSG::STANDAGE | | Thu Oct 21 1993 20:52 | 26 |
|
All,
The problem is not really a fault of IOS or FCS, it is entirely with FAL.
However, it is true to say that IOS could have bypassed FAL altogether,
and this is something we should aim to achieve in the future.
If there is a problem with FAL (and there can be various reasons),
then, as you have seen, the remote read of a private document will fail.
The most typical reason for this is the FAL password in NCP not
matching the password on the FAL$SERVER account in SYSUAF.
A good way to check if FAL is working and a proxy is correctly
defined is to do $DIR NODE:: to the node you are trying to access.
I don't know much about FAL I'm afraid, but perhaps this can help.
Hopefully soon we can get things changed a little so that FAL isn't
needed.
Kevin.
|
| 2850.6 | Existing applications? | IOSG::NEWLAND | Richard Newland, IOSG, REO2-G/L2 | Fri Oct 22 1993 12:15 | 12 |
| Bob and Kevin,
How would existing integrated applications which do their own opening of
files use the FCS instead of FAL? For example, the RUNOFF Handling type is
defined to execute a DCL command in the sub-process to perform formatting,
and the DSR image opens the files. Are you suggesting that every existing
Digital, Third Party and Customer application of this type be changed to
use the FCS?
Richard
|
| 2850.7 | Nobody mentioned 3rd party apps | CHRLIE::HUSTON | | Fri Oct 22 1993 18:27 | 25 |
|
No, I am suggesting the ALL-IN-1 use the FCS for what is was designed
for, I am not talking 3rd party apps, though they are free to use it
as well, if they have ALL-IN-1 installed, then they have teh client
image and can have at it.
If there is something that can be done via IOS that cannot be done
via the FCS (with respect to the FC and its contents) then it is
a bug or missing feature of the FCS and should be fixed/added, not
hacked around. At the point FAL is being used, an FCS link has already
been established, authentication done etc, by using FAL another link
is done, and authenticated. It also requires FAL to have access to
the documents, as well as OAFC$DEFAULT (or whatever ACLs were put
on by the drawer sharing code), this leads to confusion as the
base noter saw. He shared a drawer by following the rules and was
not able to access it because IOS was not following the rules and using
the FCS for all remote access.
I really don't want to go deeply into this, it is past history and
will do nothing but bring up problems that are meaningless. Alot of
water has gone under the bridge since the days of this decision and
I don't want to re-open the wars and battle wounds that occured.
--Bob
|