Conference iosg::all-in-1_v30

Your base note doesn't really spell out just what your problem is, but I'll
assume you mean the code as shown doesn't retrieve the values you expect.

Why not just code the FOR DO loop with a bit more criteria on the RSE, like

	FOR SEM$DATA with .%key == '1' DO           etc

I have a feeling your generic loop isn't doing what you want.  Other than
that, your code looks fine.

	Al

What I'm doing is strictly legal and it works in V2.4.  'FOR FIRST dsab' should
simply act on the first record in the dataset, and it does as long as I do not
stack multiple GETs to retrieve multiple fields. But I'll check out your
suggestion by explicitly selecting key = "1".

Paul.

If this is in a DO script, i don't think that you need the DOUBLE
backslashes (although i am not totally sure).

One workaround is to do a

for THINGY do get oa$function='first function\second function ...'

but that is limited to 255 characters in the quotes.

Also, try

for THINKY do do ANOTHER_SCRIPT

and put the multiple GETs in there!


hth,


mb

By just fooling around with the code I found the cause of the problem. I think
it's actually a bug. The following piece of code did not work because it
contained TABs...

    FOR FIRST sem$data DO -
       GET #sem_drafted_by     = .drafted_by     \\-
       GET #sem_date           = .date           \\-
       GET #sem_from_company   = .from_company   \\-
       GET #sem_from_city      = .from_city      \\-
       GET #sem_extension      = .extension      \\-
       GET #sem_from_refind1   = .from_refind1   \\-
       GET #sem_from_refind2   = .from_refind2   \\-
       GET #sem_classification = .classification \\-
       GET #sem_acknowledgment = .acknowledgment \\-
       GET #sem_reference      = .reference      \\-
       GET #sem_subject = #sem_subject_old = .subject

After replacing the TABs by spaces (just so that the code looks neat) it works.
However, I always make it a habit to 'align' such large statements, just to make
the code more readable. This never was a problem in V2.4.

Am I really the first to discover...?

Paul.

Although you're right of course, I still think this is a workaround. The
construction with the backslashes should work, just as it did in V2.4. In my
application I use this construction on numerous places and they all worked, but
now they don't anymore. In some Do scripts I found that it had something to do
with TABs in the statements. Removing TABs by spaces solves the problem for some
scripts, but not for all.

For the moment I'm, still quite puzzled.

Paul.

My shout for joy in .4 came a little early. Removing the TABs solved the problem
only sor some scripts, but not all.
Are there more such 'known problems'. Please make them known to me also.
Is there a limit to the number of functions you can stack in a FOR loop.
I noticed a difference in not using continuation lines. Since the total FOR loop
exceeds 255 characters that will not be a solution for me, but it shows that
there must be problems with the FOR function.

Paul.

    see also 900.*, 969.*
    
    the problem seems to be fixed with one of the V3.0 patches. Does
    anyone know which patch actually fixed this problem?
    
    Fritz

    re. .4
    >>> Is there a limit to the number of functions you can stack in 
    >>> a FOR loop?
    -------------
    Yes. It is a known problem. Extract from THR-17403:
    "  In a script, if you have a long FOR loop statement e.g.:
    
          FOR sm$global$edit WITH .%KEY EQS #ge_admin DO -
                  GET #ge_depart            = .depart\\-
                  GET #ge_location          = .location\\-
    
                   ...and so on, up to 80 or so fields,
    
                ... you get an access violation as the script processing
            concatenates the GET statements into a command line before
            parsing....
    
    .... The place of failure is variable, and seems to depend on system
          setup/environment. The failure is not always reproducible.
    
          A simple work around is to chop the FOR loop up into 10 x
          GET statement blocks, which cures the problem. But it is a bit
          irritating."
    
    HTH.
    DaveT