[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

3893.0. "FN$Locate broken after MUPA install?" by GANTRY::HULL (Digital Consulting [Delivery]/Motown) Wed Feb 16 1994 18:41

I had some scripts break after the MUPA upgrade.  All .FLBs and the TXL's
were recompiled. The (fn$locate("FCPT", #send_choice)) segment was working
but now returns a null value, leaving the user in an infinite prompt loop
when they answer correctly.  Using fn$member accomplishes the same thing,
but why did fn$locate break now?

SPR time??

	Al


 scr_send.scp - allow mailing of an SCR listing
! written by Al Hull - Digital 8-Sep-1993

.label start
        prompt "Send (F)ull listing, (C)over only, (P)DL Listing, or (T)ext file: "
	oa$fld_stay
        .if oa$prompt_dispose ne 2 then .exit
        get #send_choice = fn$upper(oa$prompt_text)

!!      .if not (fn$locate("FCPT", #send_choice)) then .goto start
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
!!this broke after MUPA patch installed. ?????

        .if not (fn$member(#send_choice,"FCPT")) then .goto start
!! this style works 

        display(oa$_gbl_working)\force
 
T.RTitleUserPersonal
Name
DateLines
3893.1I would have thought this never worked?IOSG::BILSBOROUGHSWBFSThu Feb 17 1994 09:105
    
    I thought that fn$locate was used to check if a whole substring was in
    a string and not whole substring or partial.
    
    Mike
3893.2How about ...IOSG::MAURICEI left my heart in AlcatrazThu Feb 17 1994 11:1510
    Hi,
    
    FN$LOCATE returns a number rather than a TRUE/FALSE indicator. I think
    your line should be:
    
    .if not (fn$locate("FCPT", #send_choice) eq 0) then ...
    
    Cheers
    
    Stuart
3893.3I'm staying with fn$member anywayGANTRY::HULLDigital Consulting [Delivery]/MotownThu Feb 17 1994 19:4617
re:                <<< Note 3893.1 by IOSG::BILSBOROUGH "SWBFS" >>>
   >               -< I would have thought this never worked? >-

   > I thought that fn$locate was used to check if a whole substring was in
   > a string and not whole substring or partial.
    

Mike - 'F'  **is** a "whole" substring of string 'FTCP'  etc.  8^)


Stuart - you're probably right in usage, but nevertheless it worked fine
before the MUPA and now it doesn't.  I always thought you could treat any
0/1 value in a T/F boolean.

Regards,

	Al
3893.4IOSG::CARLINDick Carlin IOSG, Reading, EnglandFri Feb 18 1994 19:2912
    Al
    
    Even though it should have been coded differently (as Stuart pointed
    out) I am still bothered if your original fn$locate code is working in
    V3 but failing in MUPA since the code for lexicals didn't get changed.
    Since the (undocumented?) .IF rules are that 0=false and non-0=true you
    should be ok.
    
    I tried it on a MUPA system here and it seemed to work ok, how does it
    fail for you?
    
    Dick
3893.5So what changed in V3.0A?GANTRY::HULLDigital Consulting [Delivery]/MotownMon Feb 21 1994 15:5458
Dick -

Here's a short test version of the problem code.  It works fine on V3.0 and
V3.0-1, but fails to recognise the 'match' of the substring when running
under V3.0A.  I shortened the promt text just to fit the screen better.

.label start
        prompt "Send (F)ull listing, or (T)ext file: "\oa$fld_stay
        .if oa$prompt_dispose ne 2 then .exit
        get #send_choice = FN$UPPER(oa$prompt_text)
        .if not (fn$locate("FCPT", #send_choice)) then .goto start
        .exit

Here's the failing trace (I entered lowercase f as the response):
![SCRIPT] P Line 1: .label start
![SCRIPT] P Line 2: prompt "Send (F)ull listing, or (T)ext file:
"\oa$fld_stay
![FUNC]   Function: PROMPT, Cmd line: "Send (F)ull listing, or (T)ext file:
"
![SYMBOL] Symbol: "Send (F)ull listing, or (T)ext file: ", Value: Send
(F)ull li
!               sting, or (T)ext file:
![FUNC]   Function: OA$FLD_DONE, Cmd line:
![FUNC]   Function: OA$FLD_STAY, Cmd line:
![SCRIPT] P Line 3: .if oa$prompt_dispose ne 2 then .exit
![SYMBOL] Symbol: OA$PROMPT_DISPOSE, Value: 2
![SYMBOL] Symbol: 2, Value: 2
![SCRIPT] IF Operation starting
![SCRIPT] .IF condition OA$PROMPT_DISPOSE NE 2  is FALSE
![SCRIPT] Null ELSE clause detected
![SCRIPT] P Line 4: get #send_choice = FN$UPPER(oa$prompt_text)
![FUNC]   Function: GET, Cmd line: #send_choice = FN$UPPER(oa$prompt_text)
![SYMBOL] Symbol: oa$prompt_text, Value: f
!
!
!
!
![SYMBOL] Symbol: #send_choice = FN$UPPER(oa$prompt_text), Value: F
!
!
!
![SCRIPT] P Line 5: .if not (fn$locate("FCPT", #send_choice)) then .goto
start
![SYMBOL] Symbol: "FCPT", Value: FCPT
![SYMBOL] Symbol:  #SEND_CHOICE, Value: F
!
!
!
!
![SYMBOL] Symbol: FN$LOCATE("FCPT", #SEND_CHOICE), Value: 0
![SCRIPT] IF Operation starting
![SCRIPT] .IF condition NOT (FN$LOCATE("FCPT", #SEND_CHOICE))  is TRUE
![SCRIPT] THEN Operation starting
![SCRIPT] P Line 5: .goto start
![SCRIPT] P Line 2: prompt "Send (F)ull listing, or (T)ext file:
"\oa$fld_stay

endless prompt loop since F or T fails to be a match...
3893.6Here's a V3.0 (success) trace of the sameGANTRY::HULLDigital Consulting [Delivery]/MotownMon Feb 21 1994 16:0114
And here's the same code run on a V3.0 (unpatched) system.  As can be seen,
the FN$LOCATE returns a '1' (success/true) which failed under V3.0A.
Go figure...

![SCRIPT] P Line 5: .if not (fn$locate("FCPT", #send_choice)) then .goto
start
![SYMBOL] Symbol: "FCPT", Value: FCPT
![SYMBOL] Symbol:  #SEND_CHOICE, Value: F
![SYMBOL] Symbol: FN$LOCATE("FCPT", #SEND_CHOICE), Value: 1    <<<<<<<<<<<<
![SCRIPT] IF Operation starting
![SCRIPT] .IF condition NOT (FN$LOCATE("FCPT", #SEND_CHOICE))  is FALSE
![SCRIPT] Null ELSE clause detected
![SCRIPT] P Line 6: .exit

3893.7You're right!IOSG::CARLINDick Carlin IOSG, Reading, EnglandTue Feb 22 1994 07:5110
    Al
    
    Yes, sorry. I was wrong on most counts in my previous reply. The main
    lexicals module did not change, but an ancillary one did, causing the
    problem you found (and a couple you did not find). I couldn't reproduce
    the problem initially because I tried it out with literal strings
    rather than symbol references and they worked okay. Solution will be in
    a pfr. Thanks for your patience, things are fairly hectic here.
    
    Dick