Unfortunately, it is the rules of the AIF intrinsics which need to be in
priv mode to operate.
Without being in priv mode the application program aborts with an "Internal
Trap" message.
My app needs to use these AIF intrinsics to retrieve data that the "normal"
MPEiX intrinsics
don't do.
I found a work around method,
a) Load all the data into an OCCURS table in working-storage which I don't
really like
doing.
What happens when the internal table gets full up? How large do I make
this table?
100, 1000, 5000, 10000 etc etc...
I discovered at compile/link and also the loading/running phase apparently
takes a bit longer
because of these oversized OCCURS table in the program.
Then I thought about having the AIF sub just write the data to a file and
when control returns
to the Cobol mainline have it read the file and process the data that way.
That was when I
began to discover the flakiness of doing the fopen/fwrite/fpoint/fread
after putting the
program into priv mode.
So a) wins it this time........
Thanks,
Brian.
On Mon, 19 Jul 2004 16:43:08 -0400, Olav Kappert <[log in to unmask]>
wrote:
>Hi:
>
>Just a friendly reminder for everyone who uses GETPRIVMODE.
>
>First the disclaimer, it is a very dangerous intrinsic in the hands of
>an an unseasoned Priv Application Development professional.
>Secondly, the GETPRIVMODE / GETUSERMODE Intrinsics should bracket only
>the commands(Intrinsics) that require their use. No other commands or
>Intrinsics should be nested within. File reads and writes generally are
>not recommended within the bracketting unless you are accessing
>PrivFiles. If you need to perform non-priv file access, load the
>required information into arrays prior to GETPRIVMODE, use the
>information in PRIVMODE, and store the information to the file from the
>arrays after exiting from PRIVMODE.
>
>Over the last 25 years, I have done my share of Priv programming and
>thank-heavens I never received a system abort for my efforts.
>
>Hopefully this helps.
>Olav.
>
>
>
>
>
>Brian Donaldson wrote:
>
>>Hi gang:
>>
>>After a bit of testing on all my file open, writes, closes etc I
discovered
>>that manipulating files after calling GETPRIVMODE causes some really flaky
>>results.
>>
>>Cobol OPEN I-O don't work, intrinsic FOPEN's and FWRITE's don't work. The
>>FOPEN returns a file code of zero upon a "successful" open, FWRITE returns
>>a zero error code, a seemingly successfuly write, but the records are not
>>being written to the file.
>>
>>However, without calling GETPRIVMODE all these file manipulations work
>>correctly.
>>
>>I had to do a work around to get it all to work correctly.
>>
>>Any privmode gurus out there know the answer to this one?
>>
>>TIA,
>>Brian.
>>
>>
>>On Thu, 15 Jul 2004 09:56:56 -0400, Doug Werth <[log in to unmask]> wrote:
>>
>>
>>
>>>Brian Donaldson wrote:
>>>
>>>
>>>>Are there any GETPRIVMODE experts out there who can tell me the
>>>>answer to this one?
>>>>
>>>>
>>>>
>>><snip>
>>>
>>>
>>>>...
>>>>...
>>>>CLOSE PAGE-031-FILE.
>>>>CLOSE =>42<
>>>>OPEN OUTPUT PAGE-031-FILE.
>>>>OPEN OUT=>00<
>>>>CLOSE PAGE-031-FILE.
>>>>CLOSE =>00<
>>>>OPEN I-O PAGE-031-FILE.
>>>>OPEN I-O=>00<
>>>>
>>>>CALL INTRINSIC "GETPRIVMODE" (need it so the AIF subs will work).
>>>>Works fine.
>>>>
>>>>Here's an interesting thing I just discovered:
>>>>
>>>>If I change things around slightly, thus:
>>>>
>>>>CALL INTRINSIC "GETPRIVMODE".
>>>>
>>>>CLOSE PAGE-031-FILE.
>>>>CLOSE =>42<
>>>>OPEN OUTPUT PAGE-031-FILE.
>>>>OPEN OUT=>9<
>>>>CLOSE PAGE-031-FILE.
>>>>CLOSE =>42<
>>>>OPEN I-O PAGE-031-FILE.
>>>>OPEN I-O=>9Z<
>>>>
>>>>Why can this file not be opened when the program is in priv mode?
>>>>
>>>>
>>>>
>>>Brian,
>>>
>>>The error 42 on CLOSE means you were trying to close a file that was
>>>previously closed. The error 9Z means you are trying to open a file that
is
>>>already accessed and you are trying to open it exclusively (9 means file
>>>system error, Z=ascii 90 or File System Error 90).
>>>
>>>Is it possible your program is executing routines twice? Trying to close
>>>
>>>
>>the
>>
>>
>>>file twice, trying to open the file twice? Only the second time through
>>>
>>>
>>each
>>
>>
>>>routine would be an error, the first time through would result in a
>>>successful open or close. This may be a logic flaw that is only revealed
>>>when you are in priv mode.
>>>
>>>Doug.
>>>--
>>>Doug Werth Beechglen Development Inc.
>>>[log in to unmask] Cincinnati, Ohio
>>>
>>>* To join/leave the list, search archives, change list settings, *
>>>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>>>
>>>
>>
>>* To join/leave the list, search archives, change list settings, *
>>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>>
>>
>>
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
