| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1632.2 | SUBSCRIBER writes PROFILE | IOSG::TALLETT | Gimmee an Alpha colour notebook... | Wed Oct 21 1992 08:38 | 13 |
|
I remember digging into where the DDSID update gets done one time,
and I found that a WRITE ADD SUBSCRIBER updates the PROFILE entry
automatically but a WRITE CHANGE doesn't. The script you quoted
does do a WRITE ADD so I can't see why it wouldn't update the
PROFILE entry. Maybe you could look at the value of #dds_account
in the script and check that it is correct.
Judging by the comments in the script, you already have the
definitive answer in .1 ! :-)
Regards,
Paul
|
| 1632.3 | WRITE ADD Doesn't seem to work either. | WAYOUT::CLARKE | The Cat in the Hat comes back. | Wed Oct 21 1992 17:34 | 20 |
| If i use the WRITE ADD interactively this doesn't write back the DDSID into the
profile. eg
<WRITE ADD subscriber useridi="NEW", surname="NEW", useridi="NEW"
This definitely writes a new subscriber entry into DDS however
PROFIL.DDSID["NEW"] is still empty.
I assume #DDS_ACCOUNT is loaded correctly as after a user profile creation
SUBSCRIBER.USERIDI["surname"] returns the correct ALL-IN-1 username.
I think the problem is that if a WRITE ADD SUBSCRIBER is supposed to write a
DDSID back into profile auto-magicaly - it doesnt !
Does anybody know how the full account creation performs this, I don't think
that it uses subscriber_add_interactive.scp.
Regards
Aston
|
| 1632.4 | Old memories fading | AIMTEC::WICKS_A | Braves Win, Braves Win, Braves Win! | Wed Oct 21 1992 18:38 | 9 |
| Aston,
the full creation (Create user) used to use SUBSCRIBER_ADD. The
_INTERACTIVE version is only supposed to be used when you have the
PROFIL form current e.g <FORM PROFIL
regards,
Andrew.D.Wicks
|
| 1632.5 | depends on the profile record being there? | IOSG::TYLDESLEY | | Thu Oct 22 1992 13:14 | 15 |
| Re. .4 Correct. Sm_cr_user_details still uses subscriber_add.
Like Paul (.2), I have tried to track down where the Profile gets updated
with the DDSID, and I can only see that it must happen in the
subscriber dsab (nothing visible in subscriber_add, subscriber_add_
interactive, or subscriber_change).
The difference between what happens in CU to that in UP, seems to be
whether or not the profile record is in existence at the time that
the WRITE ADD is done. In CU the record has already been created; in
UP, it hasn't (form SM$CREATE$PROFILE does the add of the profile
data after the run of the subscriber_add_interactive).
DaveT[who_knows_little_about_DDS]
|
| 1632.6 | SUBSCRIBER is Innocent! | AIMTEC::WICKS_A | Braves Win, Braves Win, Braves Win! | Thu Oct 22 1992 13:33 | 15 |
|
DaveT,
If the _interactive script is run before the profile record is created
then how can any DSAB (particularly one as special as SUBSCRIBER!)
possibly be expected to write something to it?? I believe there's a
rectriction in RMS that the record has to exist before you can modify
data in it (:==:)
did this ever work? SPR against SM methinks
Regards,
Andrew.D.Wicks
|
| 1632.9 | More News. | WAYOUT::CLARKE | The Cat in the Hat comes back. | Fri Oct 23 1992 18:10 | 20 |
| I have traced a User Profile Creation and during SUBSCRIBER_ADD_INTERACTIVE
script it does try to write back the DDSID into the profile as follows;
![SYMBOL] Symbol: #dds_account, Value: BLACK6
![IO] Getting record from PROFIL, Key: , Key-of-ref: USER/0
![IO] Status: record not found
![IO] Putting field DDSID in PROFIL, Value: 21280A800096288525A17CA0A8A50000
![IO] Status: record not found
![IO] Updating current record in PROFIL
![IO] Status: no current record (operation not preceded by $GET/$FIND)
![IO] Deaccessing PROFIL, File: OA$DATA_SHARE:PROFILE.DAT
![IO] Status: record not locked
I am thinking that the DDS subscriber entry is created before the Profile entry
is saved and hence the 'record not found' errors above.
Has anybody any idea for a workaround, worse comes to the worse I will just
stick in a WRITE CHANGE PROFILE myself somewhere to put the DDSID into profile.
Thanks Aston
|
| 1632.10 | Not so easy | IOSG::TALLETT | Gimmee an Alpha colour notebook... | Mon Oct 26 1992 09:30 | 29 |
| Hi there!
>I am thinking that the DDS subscriber entry is created before the Profile entry
>is saved and hence the 'record not found' errors above.
>
One day, when I have the courage, I'll take a look at that line
of code!
>Has anybody any idea for a workaround, worse comes to the worse I will just
>stick in a WRITE CHANGE PROFILE myself somewhere to put the DDSID into profile.
No you won't. At least not reliably. I looked into something
similar a while back, and the problem is that you don't know the
DDSID until you have added the entry, and once you've added it,
the entry is no longer unique so you can't get it back. I suspect
that is why the SUBSCRIBER DSAB writes the PROFILE in the first place.
Could you not work around the problem closer to source by arranging
that the PROFILE entry is available for the SUBSCRIBER DSAB in
the first place? Actually, looking at the trace, the GET on PROFILE
has a null key value which looks wrong. If I get chance I'll look
at the code. Looking further at the trace, it seems that it steams
ahead with the update even if it fails to get the record, so it
will probably just update whatever PROFIL record is current (yuk).
Maybe you could exploit both bugs and arrange for the right PROFIL
record to be current.
Regards,
Paul
|
| 1632.11 | Retreat... | WAYOUT::CLARKE | The Cat in the Hat comes back. | Mon Oct 26 1992 16:58 | 35 |
| Can anybody see any problems with this as a temporary workaround.
I have tested it here and it seems to work but the customer involved is one of
our large account customers and I want to make sure it is right before making it
the 'official' workaround in Stars.
I will still SPR it for engineering fix, but a decent workaround will make this
lower priority.
Ta Aston
1. Remove DO SUBSCRIBER_ADD_INTERACTIVE from ~~POST_PROC~~ XOP branch on form
SM$CREATE$PROFILE.
2. Change Named Data of form SM$CREATE$MENU to call script SUBSCRIBER_ADD after
form SM$CREATE$PROFILE has been called as follows;
change
;;~~NEW_PROFILE~~;;
GET $SM_ACCOUNT = #SM_NEW_PROFILE \
.IF #SM_APP_CHANGE THEN
WRITE CHANGE PROFIL USER = #SM_NEW_PROFILE, CREATE$FAIL = "3" \\
OA$FAO SM$_CREATE_NOW,"OA$DISPLAY",#SM_NEW_PROFILE
to
;;~~NEW_PROFILE~~;;
GET $SM_ACCOUNT = #SM_NEW_PROFILE \
DO SUBSCRIBER_ADD\
.IF #SM_APP_CHANGE THEN
WRITE CHANGE PROFIL USER = #SM_NEW_PROFILE, CREATE$FAIL = "3" \\
OA$FAO SM$_CREATE_NOW,"OA$DISPLAY",#SM_NEW_PROFILE
|
| 1632.13 | | KERNEL::OTHENJ | | Tue Nov 03 1992 09:05 | 62 |
| Similarly,
To delete a user profile within ALL-IN-1 v3.0 also fails to delete
the DDS entry from MBMAN. The code deletes the record from profile, and
does not check up to see if it has been included in the mail directory.
The customer has included the following code changes which he feels
would correct the situation (and yes, you guessed it - this is the same
customer as the original note).
A) in SM$DELETE$PROFILE
change :
;;~~DELETE_PROFILE~~;;
WRITE DELETE PROFIL USER=$SM_ACCOUNT\
.IF OA$STATUS
to:
;;~~DELETE_PROFILE~~;;
GET #DDS_ACCOUNT = $SM_ACCOUNT\
DO SUBSCRIBER_DELETE\
WRITE DELETE PROFIL USER=$SM_ACCOUNT\
.IF OA$STATUS
b) In the named data of SM$DELETE$PROFILE, when deleting a profile where a file
cabinet also exists, the test on the prompt response is incorrect. The code
should be changed as follows:
change:
;;~~FC_EXISTS~~;;
PROMPT SM$_MUA_DEL_PROFILE_PROMPT\
OA$FLD_STAY\
.IF OA$PROMPT_DISPOSE EQS OA$Y
THEN
XOP "~~DELETE_PROFILE~~"
ELSE
GET OA$DISPLAY=SM$_MUA_DEL_PROFILE_QUIT
to:
;;~~FC_EXISTS~~;;
PROMPT SM$_MUA_DEL_PROFILE_PROMPT\
OA$FLD_STAY\
.IF OA$PROMPT_TEXT EQS OA$Y
THEN
XOP "~~DELETE_PROFILE~~"
ELSE
GET OA$DISPLAY=SM$_MUA_DEL_PROFILE_QUIT
|