Forced to use OPS$ in 7.0.16 - Yuck!

i always liked the "OPS$" login feature in ORACLE 6, but hated the prefix. i was thrilled when i saw that in ORACLE 7 it was possible to make the prefix null, i.e., so that a VMS User named FRED could have an ORACLE username FRED and not be forced to enter a second password when moving into ORACLE 7 from VMS.

the trouble is we're moving gradually toward a client-server environment wherein many of our users will be coming in from client software *sometimes* and VMS other times. as of version 7.0.16.4, we are now forced to choose from two unattractive alternatives:

1. force any user who is using both VMS and client stuff to enter their ORACLE password - always - even when they are using VMS.
2. go back to using the OPS$ prefix on usernames.

in this new version IDENTIFIED EXTERNALLY uses the coded password field to hold the value "EXTERNAL". hence, such a user *cannot* come into the same account using a password.

as a "concesssion", Oracle has provided the old "OPS$" mechanism as a kludge. if you set the os_authent_prefix to OPS$, then VMS users are allowed into an oracle username equal to their vms username with OPS$ in front - as if they were identified externally - even if they have a password.

in 7.0.15 and earlier, they did this differently, so we could have passwords on accounts *and* let VMS users into accounts with matching names - without using OPS$.

the way it works now is almost more obnoxious than it was in ORACLE 6. i would not be so annoyed if they hadn't led us to believe OPS$ was going away, but they seem quite adamant that it will continue to work the way it is now.

i assume it works the same way on other operating systems as it does on VMS. true?

what are others doing about this problem? we really don't want to go back to OPS$, but we also don't want people to have to always enter their oracle passwords when they are on vms. we've tried all the combinations we can think of and nothing gives us what we want.

does anyone have a good solution? is there any way we can pressure Oracle into allowing a single account to be identified *either* by a password *or* externally (which is what i *think* we want - and had in earlier versions of ORACLE 7).

please email to me (carl.pedersen_at_dartmouth.edu) and i'll post a summary of responses. thanks. Received on Tue May 24 1994 - 21:33:29 CEST