Conference iosg::all-in-1_v30

� It seems that the script and the command procedure are processed in "parralel".

	First of all, of course they are!  The only synchronization is whatever
the application  institutes.  That's why the normal procedure is to write to
OAMAILBOX, and then read DCLMAILBOX.  That causes the "synchronization".

	Secondly, I have never tried using the "@" syntax with the OA$DCL special
symbol, but I would have guessed that it would *not* work.  As far as I've ever
used it, the "@" is simply a shorthand way of entering DCL command procedures
from the CHOICE field.

	Even if it should work, however, you have to realize that you're, in
essence, trying to invoke a command procedure while another command procedure is
still in effect in the subprocess.  And that's a No-no in ALL-IN-1.  For the same
reason, you can't have a statement such as:

	$ WRITE OAMAILBOX "OA COMMAND xxxxxx"

executed from the subprocess.

	It sounds like you're tripping over a synchronization problem.  I'd
re-think what you're trying to do, with the above comments in mind.

	F

    The code in .0 does work just fine as soon as the WRITE OAMAILBOX has
    the OA inserted at the beginning of the command line.  As .1 says,
    there is a synchronization problem between the main process and the
    subprocess.  In point of fact, there is a race condition between the

    get oa$dcl = "@sub_2"
    get oa$display = log$test

    lines.  The sub_2 command procedure is being executed in parallel with
    the script which invoked it.  In spite of what would be expected (and
    stated in .1), the DCL commands are indeed being executed in the
    subprocess even though the subprocess is 'occupied' by the initial
    COMMAND SUB_1 function.  This can be seen by turning on DCL verify.

    This can be seen quite easily by executing the code in .0 (after
    correcting the aforementioned WRITE OAMAILBOX).  I also set TEST to
    "BEFORE ANYTHING" at the start of SUB_1 just for clarity.  I also added

    get oa$display = "before @sub_2 - " log$test

    between the other two get oa$dcl functions in DOSCP.SCP just to watch
    the 'progress'.

    This brings us back to the question in .0 about how to explain this
    behaviour.  .1 is right in saying how it SHOULD behave but it appears
    that it is possible to insert DCL commands in the midst of a COMMAND
    function.

    .1 is also right in saying that the apparent logic in .0 should be
    examined.  I assume that this is a cutdown version of something much
    larger and that there is good reason for this rather strange approach.
    It would probably be a good idea to examine how the application could
    be made more simple so that the DCL 'weave' is not necessary.  In
    addition to having to face the race condition you have discovered, it
    would be the type of application that would be very hard to maintain.

    Have fun,
    don

Hello again,

Thanks for your replies, here are some comments...

�It seems that the script and the command procedure are processed in "parralel".

��First of all, of course they are! 

I understand that they run in the same time, what I meant is the "race
condition".

�   I assume that this is a cutdown version of something much
    larger and that there is good reason for this rather strange approach.
 
It comes from a special.COM written to send telexes: one of the customer
request was to have the TOs and CCs list in the telex body (as they don't 
appear in the header). So a boilerplate is used to merge this list in the
text of the mail.

write oamailbox "oa merge to_cc_list.blp,to_cc_list.lis"
@dclmailbox

This boilerplate calls a do script that uses MERGE_LINE after formatting
the TO or CC found with CAB$ATTRIBUTES DSAB.

The formatting uses the GET_TOKEN function which causes the problem when
the string contains a single quote (see not 2116 of old conf).

I've tried to GET OA$DCL = "@FORMAT_TO_CC.COM " #TO to workaround this 
problem and this is the "why" of .0

Thanks again for your help.

Pas.

PS. our customer uses V2.4

    

    Re .3
    
> The formatting uses the GET_TOKEN function which causes the problem when
> the string contains a single quote (see not 2116 of old conf).
    
    GET_TOKEN is fixed in V3.0 and V2.4 patched up to date. So hopefully
    you can eliminate the workround.
    
    Cheers
    
    Stuart