Feature #16780
Multiple User Support for SRFILE Reading
0%
Description
Currently, any application that views an SRFILE sets G:SRFILE to the file number for desired viewing. This only allows one user at a time to view their file. When G:SRFILE is set by a user, users who have already interfaced with an SRFILE are then given data from the new file set by the more current user.
My request is that each user/DPM have its own instance of the SRFILE request and be able to view an SRFILE without the potential of being shown the results of another user's request.
Connected but not directly related, the current scenario can lie to the user. It would be good if when using an SRFILE that doesn't match the user choice that it show an error as not to mislead the user.
History
#1 Updated by Richard Neswold about 2 years ago
Beau Harrison wrote:
My request is that each user/DPM have its own instance of the
SRFILErequest and be able to view anSRFILEwithout the potential of being shown the results of another user's request.
This is actually an issue for the SRFILE OAC, not new DPM. Since very little of our department's source is using issue tracking, we'll keep this issue as-is so we don't forget about it.
Connected but not directly related, the current scenario can lie to the user. It would be good if when using an
SRFILEthat doesn't match the user choice that it show an error as not to mislead the user.
When redirection was implemented, they wanted it to appear transparent to the client so all redirection services speak RETDAT/GETS32. The replies for those protocols don't have any place to provide the extra information.
Charlie King and I discussed ways to fix this (using a non-GETS32 protocol.) The same protocol could also let us redirect to logger data. Since new DPM would need to support these new protocols, I guess attaching this issue to it isn't such a bad idea. :)