Re: Help: SYS$ACM is driving me nuts!!

In article <QsV3E0ThHHjJ@xxxxxxxxxxxxxxxxx>, nothome@xxxxxxxxxxxxxxxxx (Malcolm Dunnett) writes:
> In article <A5TAOQOypgRb@xxxxxxxxxxxxxxxxxxxxxxxx>,
> Kilgallen@xxxxxxxxxxx (Larry Kilgallen) writes:
>
>> In article <439FEE4E.67C335E8@xxxxxxxxxxxxxxxxxxxxxxxxx>,
> Graham Burley <burley.not-this@xxxxxxxxxxxxxxxxxxxxxxxxx> writes:
>>>
>>> By passing a context longword with a value of -1 you're asking for
>>> dialogue mode when you don't want it.
>
> Doh! Thanks, I took out the context argument and now the
> code works.
>
>>
>> But there should be no dialogue if there is nothing to discuss.
>>
>
> That was my thought. However removing the context argument makes
> the code work. I would have expected that with a context argument
> there it would have supplied those output messages for information
> purposes but would still have proceeded to process the login ( since
> it had all the information it needed )

I believe it wants a callback after which it will return the
"all done" status.

>> I would be suspicious of the context area item that "appears to
>> be blank". What is the item code ?

> the item code is 8192 ( same as the welcome message ). If I
> understand the documentation ( a somewhat shaky premise ) that
> means it's an output code. So I have no idea what SYS$ACM thinks
> the empty string signifies, but it's apparently not asking me for
> further information.

I believe that is a "blank line" after the message.

>> As far as network logins getting SYS$ANNOUNCE, that is perfectly
>> reasonable. Consider those messages about "you may be monitored".
>> Transmitting that for a network access could be quite appropriate,
>> even though DECnet does not do it.
>
> I agree it's fine to return the messages so that the login program
> can do what it will with them, however I would have expected it to
> also process the login. The documentation states that providing a
> logon type of "NETWORK" specifically signals that no dialogue is
> possible, so if SYS$ACM is given adequate information to process
> the login I would expect it to do so, and simply return the
> announcement message for information purposes.

If you are in dialog mode you are supposed to keep calling ACM over
and over again until it is done. One more try should have done it.
.

Relevant Pages

  • Re: Help: SYS$ACM is driving me nuts!!
    ... I took out the context argument and now the ... > But there should be no dialogue if there is nothing to discuss. ... > Transmitting that for a network access could be quite appropriate, ... I agree it's fine to return the messages so that the login program ...
    (comp.os.vms)
  • How to persist change in context of a login with in a login trigge
    ... I have a lot of two tier applications used by users. ... permissioned in SQL Server in order for the applications to ... work under their user context. ... I was trying to achieve this by using Login trigger. ...
    (microsoft.public.sqlserver.security)
  • Re: Tribute to Andreas/GKar - video posted
    ... moments as G'Kar that John would have been hard pressed to include them all. ... dialogue didn't feel right in context with the other clips... ... problems on your server. ...
    (uk.media.tv.sf.babylon5)
  • Login mechanism for web apps
    ... I am writing a generic login mechanism for our web apps using ASP.NET / C# ... Various web pages need to present a login dialogue for the user to ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: putty question - port forwarding on a machine where I have no shell access
    ... you close it and bring up a small dialogue box and/or tray thing after ... > Presumably you open a full terminal rather than a login dialogue in the ... reauthenticate at all once you've started a session - so if you fire ... but people who stick to password authentication ...
    (comp.security.ssh)