Conference iosg::all-in-1_v30

    
    I tried your program on an ALL-IN-1 V3.0 system.  I didn't get an
    ACCVIO, however it did flag the .exit in the script as invalid.
    
    I changed the .exit in the script to exit, and took the .exit out
    of the command procedure.  Worked fine for me after that.
    
    I also added sys$login in the Do statement - "Do sys$login:test"
    Is it possible that the script isn't being found ? Do you have it
    in the oauser area or in sys$login, or saomewhere else.
    
    Here's the files:
    
$!=======================================================================
$!              TEST.COM
$!
$! procedure voor testen dump/trace
$!
$!=======================================================================
$!
$ set verify
$ START:
$ WRITE SYS$OUTPUT "   Allin1 wordt opgestart !"
$!
$ set def sys$login
$!
$	allin1  /noinit -
		/reenter 
OA$INI_INIT            
<oa$tra_set all,log
<do sys$login:test
$!
$ WRITE SYS$OUTPUT "   Bestand is aangemaakt !"
$ set noverify
$!
    
    
!
!! TEST.SCP
!
     form auto select for profil do sel_style -
          .%key/style=file/list="md_asz.sel"

	get oa$display="aantal geselecteerd = " oa$src_count \force

.label einde 
       exit
    
    
    The logfile - test.log
    
$ ON CONTROL_Y THEN $LOGOUT
$ ON ERROR THEN $LOGOUT
$ SET NOON
$ @SYS$MANAGER:GLOBALS.COM
$ ! G L O B A L S . C O M
$ !
$ ! Place symbols that you want to be available to all users, within this file
$ ! This file is called from SYSTARTUP.COM
$ ! ===========================================================================
$ !
$ SET NOON
$ IF "BATCH" .NES. "INTERACTIVE" THEN $EXIT
$ SET NOON
$!=======================================================================
$!              TEST.COM
$!
$! procedure voor testen dump/trace
$!
$!=======================================================================
$!
$ set verify
$ START:
$ WRITE SYS$OUTPUT "   Allin1 wordt opgestart !"
   Allin1 wordt opgestart !
$!
$ set def sys$login
$!
$	allin1  /noinit -
		/reenter 
OA$INI_INIT            

<oa$tra_set all,log
<do sys$login:test





	VIGNEAULT finished using ALL-IN-1 at 28-Feb-1992 09:14am


$!
$ WRITE SYS$OUTPUT "   Bestand is aangemaakt !"
   Bestand is aangemaakt !
$ set noverify
  VIGNEAULT    job terminated at 28-FEB-1992 09:14:24.94

  Accounting information:
  Buffered I/O count:             163         Peak working set size:    2352
  Direct I/O count:               216         Peak page file size:     15417
  Page faults:                   1878         Mounted volumes:             0
  Charged CPU time:           0 00:00:22.46   Elapsed time:     0 00:00:33.34

    
    Sorry, I forgot to give the ALL-IN-1 version(s) I used.
    The problem is on V2.3 and V2.4. The TEST script is in SYS$LOGIN
    and I think the problem is the OA$TRA_SET option because there's no
    problem when I leave it out.
    
    John.

Also, you really don't need the "<" leadin for functions in your .COM.  Maybe
this is somehow to blame.  You might want to try it without them.

/Marty

re .3

Nice try Marty, but it did not help.

Script was copied from the customer and I didn't notice them, but it did 
not help.

I had a look in STARS and found a problem with OA$DTR functions and 
OA$TRA_SET, but I don't know if this has anything to do with it ? We do not 
have DTR on the system, but it might be the same problem area.

Regards

John.

PS Marty, we will have to find a new restaurant in Munich, the Russian is 
closed.

	Hi, John!  A couple of additional notes (just so you know you're not
going crazy!):

	1)  The problem *does* exist; I can duplicate it on our V2.4 system.

	2)  While some of the earlier replies re: syntax (e.g., the "<" or the
	    .EXIT) are technically correct, they do not affect the problem;
	    I can reproduce it even with the correct syntax.

	3)  It doesn't even require the TEST.COM procedure to cause the error;
	    I can duplicate it manually.

	4)  I'm not sure it's directly related to your TEST script; but it does
	    appear to be related to the OA$TRA_SET function.

	Here's why I say the latter.  I run $ALLIN1/NOINIT/REENT (as your .COM
procedure does).  Then, I <DO TEST and it runs fine.  I can even <DO TEST again
and again.  *After* I've done that, I <OA$TRA_SET ALL,LOG.  If I <DO TEST once
more, I get the ACCVIO.

	*HOWEVER*...  it doesn't even require that I <DO TEST after I turn on
tracing!  If I change your order, so that I <DO TEST, then turn on tracing, and
then do something like <LIST MD_ASZ.SEL, I still ACCVIO!  The wierd part is that
I can <DO TEST, turn on tracing, and do *other* things (like <GET OA$TIME, or
something trivial).  But then something like the <LIST function crashes 
ALL-IN-1.  Yet if I <DO TEST and immediately <LIST MD_ASZ.SEL (without turning
tracing on), it's OK.

	So... now we're going to simplify the problem.  If I enter ALL-IN-1 as
before, then (after the OA$INI_INIT and turning on tracing) I say <FOR PROFIL,
I get no problem.  Yet if I say <FORM AUTO SELECT FOR PROFIL, I get the ACCVIO.
So it seems to have something to do with the *interaction* between tracing and
processing the select form.

	BTW, one last piece of information:  the problem does *not* have any-
thing to do with the /REENTER qualifier; it happens even without it.  But it
*IS* related to the /NOINIT.  That is, if I log into ALL-IN-1 normally, and
enter the commands, it works fine.  Only when I use /NOINIT, followed by the
OA$INI_INIT function (and then, of course, the FORM AUTO SELECT FOR PROFIL)
does the ACCVIO occur.

	That's about as far as I've taken it; maybe this information will help
someone else spot the "flaw in the flow"  8^).

	F

	P.S.  Maybe it's the Dutch; I didn't try replacing the messages with
English text!  8^)

This problem has nothing to do with the select form.  It has to do with ANY
form being displayed!

The same ACCVIO can be seen by turning on trace, followed by FORM xyz, where
"xyz" was PROFIL, MAIN, DEFAULT, whatever (FORM DSAB access fails).

Doing SHOW_FORM PROFIL also ACCVIOed.

DSR references to PROFIL were successful and correct (DATA DSAB access works).

All the ACCVIOs I got were read references to VA %X50 from PC 18587C.  According
to the link map for my image this is in module OAFLO.

Here is the relevant parts of a SHOW CALL:

 module name     routine name                     line       rel PC    abs PC
*OAFLO           OA$FLO_DUMP_STACK                2401      0000003C  0018587C
*OAFRM           OA$FRM_DISPATCH                  1020      000000F0  001809CA
*OACMD           OA$CMD_DISPATCH                  1380      0000044C  0017CE0A
*OAMSG           OA$MSG_CALL                       311      0000001C  0018B52C
*OA              OA$MAIN                           439      00000253  000E96B9

This ACCVIO is because of OA$GL_DBF being 0 when OA$FLO_DUMP_STACK is called.
That should normally be okay.  The %X50 offset from 0 (VA %X50) is because of
the .DBX[DSA$W_FIELD] reference, which SHOULD be conditional, as the rest of
the routine is when .DBX NEQ 0.

/Marty

    Marty,
    
    The change on 12-Aug-1985 looks particularly dodgy to me!
    
    regards,
    
    Andrew.D.Wicks

RE: .7

If you are referring to a revision by me, I wouldn't doubt it.  I don't have
the CMS history for anything before V2.4 handy.

But my hat off to the developer that could introduce a bug into software this
popular that took 6.5 years to be reported, or at least identified to the
module level in this, our ALL-IN-1 conference!

/Marty

    Thanks for the comments so far.
    
    It leaves me with two points.
    
    1. Is this unknown officially ? if so I will send an SPR.
    
    2. Is it fixed in V3.0 ?
    
    Regards
    
    John
    

�    1. Is this unknown officially ? if so I will send an SPR.

	Based on the replies you've seen here, I'd say "not until now, it hasn't
been!"  So go ahead and SPR it.

�    2. Is it fixed in V3.0 ?
 
	It appears to be.  I haven't looked at the code yet, but I tried the
same test on a V3.0 system, and it works just fine.

	HTH,

	F

I've never seen this bug reported, however, it's quite likely that this has
been fixed as a side effect of the new tracing which changed this code 
extensively. Oa$tra_set in V3 uses this new code, so I've been unable to 
reproduce it here. In V3, the new set_trace function should be used in
preference to oa$tra_set if you want a better UI and the full tracing 
functionality, eg filtering

eileen