Hi,

> Is this the SCM Application, Direct Transfer Out interface ?

(BTW, I'm not the originator of the thread ... I have no idea what
application this is.)
 
> Your current error is a fserror 52 with same application.  I found an old=
> problem report that recommends the following;
> 
>      FSERR 52, PROGRAM ERROR #18 :PROCESS QUIT, PARAM=3D8
>      Intrinsic layer; a privilege violation occurred.
>      File System message 17
>      FFILEINFO intrinsic.

I want to know how the above text appears ... it isn't a simple QUIT
(which wouldn't mention anything about "Intrinsic layer", "File System",
or "FFILEINFO"), and the stack trace didn't show FFILEINFO calling QUIT.
...instead, it shows the application calling QUIT.


> This problem has been documented in SR  [5000-566695/STARS/English]  and is
> fixed in TOOLS C.00.00.=20=20

That's interesting...and very mysterious.  
It would appear to point to a TOOLSET (product name?) problem.
...but what problem?

 
>      !SETVAR FRMTSIZE FINFO('EDSFRMT1',19)+50
>      !FILE EDSFRMT1;DISC=3D!FRMTSIZE
>      !DELETEVAR FRMTSIZE

BTW, you can do that in one line (without a variable):

    !file edsfrmt1; disc = ![finfo ("EDSFRMT1", "EOF") + 50]

The above file equates, of course, should have no impact on a program
that's encountering a problem with FFILEINFO.  Why?  That's the kind
of file equate that would affect a program that's getting a premature
EOF because they were creating the output file too small ... one would
expect the problem then to have been on FWRITE/FWRITEDIR, not FFILEINFO.

An FFILEINFO 52 problem should occur only if a program tries to open
a file ... and the open fails ... and then, without checking, calls
FFILEINFO with the bad (zero) file number.  But, even then, the program
would not abort ... it would simply have an error signalled to FFILEINFO.

The user's file tombstone/quit could result from code that looked like:

     fid := fopen (....);

        ! missing code to check for success

     ffileinfo (fid, 10, eof);       ! find the EOF of the file
     if <> then
        begin         ! darn, ffileinfo failed...
        printfileinfo (fid);
        quit (18);
        end;

...then it would *approximate* the user's post, but still wouldn't
match it (there would be no "privilege" violation, for example).

In short, I'm puzzled as to the exact mechanism that causes the
user's observed output.

However, as I suggested, a simple use of Debug should pinpoint
the problem in mere seconds.

-- 
Stan Sieler
work:     www.allegro.com
personal: www.sieler.com/wanted/index.html  

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *