Conference iosg::all-in-1_v30

    Martin,
    
    OK I read your note, but what's the question?
    
    the STARS article entitled
    Two New V3.0 UDP Level Privilege Flags In User Profile        
    explains your second error message.
    
    Regards,
    
    Andrew.D.Wicks

Hi Andrew,

sorry, I didn't make my problem clear.

User with only NETMBX and TMPMBX DCL privileges and NO ALL-IN-1 privileges e.g
NO PRVUDPDCL and NO PRVUDPFNC privilege !! experience the following problem.

1. user edits a document
2. By accident presses F19, F19.UDP doesn't exist.
3. User leaves wordprocessing and gets error message
   Error opening script ""
   File not found
4. After getting this message he/she decides to edit the document again
5. user selects option E <enter>
6. Error message 'No privilege to execute function directives in UDP'S'
7. After exiting from ALL-IN-1 and run ALL-IN-1 again, the user can edit the 
   document.

I hope you understand the problem now !

    Martin,
    
    but if you give them the UDP privs the message goes away?
    
    Regards,
    
    Andrew.D.Wicks

Hi Andrew,
    
>    but if you give them the UDP privs the message goes away?

Yes, but the system manager doesn't want to grant these UDP privs.

Futhermore why are they getting this error message. They didn't execute an
ALL-IN-1 function because F19.UDP doesn't exist.

Regards,

Martin

    Since this is (I presume) only happening from within the editor, and
    not if you are at a menu, it must be an editor problem. I suggest you
    ask the WPS-PLUS developers in their conference.
    
    Graham

Ok,

I got some information from the WPS-PLUS engineering folks.

>    When F17 is pressed in the WPS-PLUS editor, the editor makes a call to
>    the ALL-IN-1 function OA$MSG_CALL, in the following format:
>
>        OA$MSG_CALL(OA$CMD_DISPATCH, "USER1:[MCCLUNG.A1.UDP]F17.UDP")
>
>    You'll have to get further explanation from the ALL-IN-1 group.


Is there more information available about the OA$MSG_CALL function. I looked in
the programmer's manuals but didn't find anything.

Thanks,

Martin

   Martin,

   Oa$msg_call is a code-level routine allowing other routines to be called
   while having a standard ALL-IN-1 exception handler active.

   Oa$cmd_dispatch is the command dispatcher, so the bit in quotes is what is
   the API-level code, and it's wrong.

   �        OA$MSG_CALL(OA$CMD_DISPATCH, "USER1:[MCCLUNG.A1.UDP]F17.UDP")
                                          ^^^^
   For V3.0 and later it should be:

   �        OA$MSG_CALL(OA$CMD_DISPATCH, "UDP USER1:[MCCLUNG.A1.UDP]F17.UDP")
                                          ^^^
   For V2.4 it should be:

   �        OA$MSG_CALL(OA$CMD_DISPATCH, "SCRIPT USER1:[MCCLUNG.A1.UDP]F17.UDP")
                                          ^^^^^^

   WPS-PLUS is apparently missing dispatching the ALL-IN-1 function verb.

   Cheers,

   Ian

Hi Ian,

Thanks for explaining !

Could this also be causing the problem seen in reply .2 ?

If so, I have to raise at least a spr, even thinking about a cld. Because 
customer wants a solution.

Martin

   Martin,

   If you need a fix from Engineering, submit an SPR of suitable priority. 
   Don't put in a CLD unless it really, truly, honestly warrants it.  There has
   been a misapprehension going about in the field that CLDs are the only thing
   to do.

   However, before submitting a bug report of whatever type, try asking the
   people in your CSC and other support origanizations, as they may have
   sufficient information to help your customer work around the problem. 

   If this is insufficient the ground-rule is 

   "no bug report => no chance of a fix".

   Cheers,

   Ian

Hi Ian,

Thanks for explaining, customer for now accepts the workaround, but would like 
to have a solution for the future.

So I will submit a SPR.

Thanks for all effort,

Martin

Member of the Dutch CSC
Office Support

    Hello Ian,
    
>   If you need a fix from Engineering, submit an SPR of suitable priority. 
>   Don't put in a CLD unless it really, truly, honestly warrants it.  There has
>   been a misapprehension going about in the field that CLDs are the only thing
>   to do.
    
    The past has proven that the reponse to an SPR is often someting
    like "Thank you for you inputs, this problem might be solved in some 
    possible future release". A number of big customers finds this
    unacceptable. They thing known problems should be fixed within
    a reasonable timeframe. Say a year.
    
    Futhermore we (TSC/CSC Holland) where instructed to lower the 
    number of SPR by turning them into local calls when priority is 
    higher then 4 and the customer has a support contract.
    So only suggestions where allowed. Not much left than a CLD. Nothing
    in between.
    
    Regards,
    
    Jan 

    
    Jan,
    
    I with other members of the production group in IOSG check SPR answers
    before they go out.  
    
    I agree that they don't commit, though often the fix has been done. 
    I assume that one time we told customers we'd fix something and we
    didn't and so we're real careful not to commit now.
    
    To be honest a lot of them aren't big problems and there is very little
    chance of it being pulled out so maybe we should take the plung and
    commit.
    
    Mike

    Hi Mike,
    
    >To be honest a lot of them aren't big problems and there is very little
    >chance of it being pulled out so maybe we should take the plung and
    >commit.
    
    Well they may not be "big problems" but all the little problems add up
    in the customers mind.  The customers do not like the fact that we take so
    long to respond it gives the wrong impression. They do not like the SPR 
    system of reporting bugs.
    
    I have said it before and I will say it again as far as the customer is
    concerned *WE* introduced the misfeature and *WE* should put it right. 
    This is how customers see things and time and again they say exactly
    the same thing "it takes too long" or "nothing will get done" etc.
    
    SPRing is seen as not addressing the issue but fobbing off the customer
    at times !!!
    
    Regards,
    
    Sunil  

    
    re:-1
    
    Sorry, when I said 'big problems' I really meant big fixes.
    
    As I said I check the answers with others, if you think that you don't
    like em let us know.  We sit here and have to imagine what the
    customers would think of it, you know.  I always
    wonder what happens once the SPR answers goes out.
    
    Please any feedback would be appreciated (except takes too long, we
    know that already!).  Are they too technical or not enough.  Would you
    like to see more with code fixes in.  Do you think there is such a time
    that if we haven't answers an SPR after so long we should drop it to
    concentrate on newer ones?
    
    thanks,
    
    Mike

    Hi Mike,
    
>    customers would think of it, you know.  I always
>    wonder what happens once the SPR answers goes out.
    
    One large customer allways checks what happens to the
    things promised in the SPRs. They do this since version 1.4.
    2.3 was a major disappointment to them (wonder why). 40 out of 80
    SPR reported problems where not fix. Now its is going much better.
    
    >Please any feedback would be appreciated (except takes too long, we
    >know that already!).  Are they too technical or not enough.  Would you
    >like to see more with code fixes in.  Do you think there is such a time
    >that if we haven't answers an SPR after so long we should drop it to
    >concentrate on newer ones?
    
    I think this depends on the kind of problem. It is hard to
    explain to a customer why easy fixes are not done within a reasonable
    timeframe. 
    
    I want to repeat that we are only allowed to generate "suggestion"
    SPRs. I will try to find out why. And what is the problem with a low
    priority CLD ? 
    
    Regards,
    
    Jan
       

    There is NO such thing as a low priority CLD. CLDs are CLDs - they are
    only counted in units - and number of CLDs + days outstanding are what 
    very senior managers are rated on.
    
    Anyway, getting back to standard SPRs (lets start to call them IPMT
    cases eh? as I've seen implimentatioon plans for Europe soon now).
    
    Wherever possible - my support group NOW gives details of which
    Internal Change Order (ICO) (as in next actual/unannounced release - 
    actually fixes the reported problem). NOTE that we provide this
    information in the part of the SPR answer that is clearly flagged
    \************ INTERNAL USE ONLY **********
    maybe this is getting stripped out before CSC folks in Europe see the
    answer. Certainly we can't commit to the customer in this fashion. 
    
    Where the SPR'd problem is NOT yet fixed in next release - we simply
    cannot say.
    
    We can only provide this level of (internally available) commitment
    when there is a large lag-time between receipt of the SPR and it being
    formally answered by the support team. (we have large backlogs). It is
    interresting to note that if we did NOT have such large backlogs and
    WERE able to answer more SPRs in a timely manner - then even fewer
    details of what IS fixed in next release would be available.
    
    Also - there is the problem that one clearly NEVER actually knows how
    long an SPR will take to resolve - or whether the resolution will be
    one line of DCL, 2 lines in .SCP or 100 lines in BLISS code. Therefore,
    if the problem appears relatively minor, the ALL-IN-1 Support group will
    NOT investigate the root cause - and answer an SPR as RESTRICTION and
    "considered for inclusion in possible future release"
    
    There are certain people/groups within Digital that think that all SPRs
    should be answered immediately - the only way we can provide an
    immediate response is by answering ALL sprs as restrictions. 
    
    So what we actually do - is the best compromise between what
    customers/CSC and SPR admin and selected managers really want. 
    
    Regards
    		Martin Cook
    		ALL-IN-1 Support Manager