device Access violation

[Lim AY]

Hi

After i run my script and i check the log file i found the below error.....

Could anyone help on this problem pls.... ;)

$ Set NoOn
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))
%SET-W-NOTSET, error modifying $1$DGA4:
-SET-E-INVDEV, device is invalid for requested operation
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=FFFFFFFFFFFF
FFC0, PC=FFFFFFFF8098A8E8, PS=0000001B

Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000000
FFFFFFFFFFFFFFC0
FFFFFFFF8098A8E8
000000000000001B

Register dump:
R0 = 0000000000000001 R1 = 0000000000000020 R2 = 000000007BF6B300
R3 = 000000007AE563F0 R4 = 000000007AE563A8 R5 = 000000007AE563B8
R6 = 000000007AE563D0 R7 = FFFFFFFFFFFFFFC0 R8 = FFFFFFFFFFFFFFFF
R9 = 000000007BFD9DE8 R10 = 00000000000228BE R11 = 000000000000001B
R12 = 0000000000000000 R13 = 000000007AF005C0 R14 = 00000000000A51A8
R15 = 0000000000000000 R16 = FFFFFFFFFFFFFFC0 R17 = FFFFFFFFFFFFFFFF
R18 = 000000007AE56D10 R19 = 0000000000000000 R20 = 000000007BF6B328
R21 = 0000000000000000 R22 = 0000000000000000 R23 = 0000000000096080
R24 = 0000000000000000 R25 = 0000000000000001 R26 = FFFFFFFF80A1A354
R27 = 000000007BF78D70 R28 = FFFFFFFF80A1A2D0 R29 = 000000007AE56320
SP = 000000007AE56320 PC = FFFFFFFF8098A8E8 PS = 200000000000001B
TASADM job terminated at 18-MAR-2008 10:13:06.34

Accounting information:
Buffered I/O count: 479 Peak working set size: 3920
Direct I/O count: 1108 Peak virtual size: 170144
Page faults: 370 Mounted volumes: 0
Charged CPU time: 0 00:00:00.31 Elapsed time: 0 00:00:05.86

[Hein van den Heuvel]

The first error "%SET-W-NOTSET, error modifying $1$DGA4:
" It is sure to be a poorly written batch job or (SY)LOGIN.COM.

Dollars to donuts there is an unconditional SET TERM... command in there which should be in conditional based on F$MODE() being INTERACTIVE or not.

The ACCVIO may or might not be the same problem.

But how can we tell if you do not show which command caused the error?

You need to re-run with SET VERIFY active and hopefully also with a timestamp in the prompt string in the log.

YOU need to show us the command and then WE can try to help.

Regards,
Hein.

[Arch_Muthiah]

Lim,

As Hein said, if your procedure needs to display something to the terminal and/or expecting user response, then that com procedure needs to be run in interactive mode. If it runs in batch mode, then usually we will get the above error.

in this case we need to check the mode is interactive or batch to avoid this type of error.

But to make sure the exact reason, better if you could past the procedure, it would be nice.

Archie

[Jan van den Ende]

Lim,

I concur with Hein, the SET error and the ACCVIO are unrelated.

PLEASE make SYS$SYLOGIN execute the F$VERIFY conditionally; only in INTERACTIVE mode.
Your LOG files will be (some much) bigger, but they will tell you A LOT more if something goes wrong somewhere.

in addition to the request by Hein, please tell us the hardware (Vax, Alpha, IA64 ?) and the OpenVMS version.

Proost.

Have one on me.

jpe

[Hoff]

[[[As Hein said, if your procedure needs to display something to the terminal and/or expecting user response, then that com procedure needs to be run in interactive mode. If it runs in batch mode, then usually we will get the above error.

in this case we need to check the mode is interactive or batch to avoid this type of error.]]]

That refers to the SET command error, and not to the the ACCVIO.

The HELP /MESSAGE ACCVIO text has a starting point on what the access violation is telling you. From what initially looks to be cryptic, you can learn a whole lot -- if you still have the source listing(s) and the LINKER map(s) around for whatever is tipping over here.

The failing program counter is in system space. (No, that doesn't necessarily mean you've found a bug in OpenVMS. It's quite common for an errant system call in an application to lead to a similar footprint; the application passes in bad data to a system service, and OpenVMS eventually detects and punts the error.) The failing virtual address is -1, and the program counter that tried to access address -1 is at FFFFFFFF8098A8E8. (That's a local value, so you'll have to find out what is there on your system.)

The contents of the dump shown indicates the application was not built with traceback, which makes figuring out what happened rather more difficult.

Oh and FWIW, one subtlety here in how OpenVMS displays its error messages during its processing of the signal: the percent character indicates the first or primary message in a signal array, and the hyphen indicates a related or subsequent message associated with the primary message. The presence of the two percent signs shown in the dump indicates two different signal arrays are present. While it is possible to encounter two signals from one application, these percent signs (and longstanding familiarity with the SET TERMINAL /INQUIRE error -- the NOTSET and INVDEV signal -- that is likely arising here) is why most folks (including myself) are expecting that there are two separate and unrelated errors here.

As others have indicated, find the failing image using f$verify(1) or SET VERIFY. Then work with whomever supports the executable image. This whether supported by HP or a third-party vendor, or somebody locally. Or bring somebody in to look at the failing code if needed.

Stephen Hoffman
HoffmanLabs LLC

[Arch_Muthiah]

My goodness. Hoff! You are great!!!. This much info within this error?

Archie

[Hoff]

My bad. The address was FFFFFFFFFFFFFFC0 and not FFFFFFFFFFFFFFFF. (Read that too fast and missed the wrap.) if the application is written in C, it's probably a bad pointer somewhere.

Anyway, fire up the debugger and have a look at the code.

And if you rebuild the code, save the listings from the compiler (with machine code included), and save the full linker map(s).

If you program on OpenVMS at all, you'll see the following signal fairly regularly:

0000000000000005 : 5 (longword) args follow
000000000000000C : ACCVIO
0000000000000000 : attempted access bitmask
FFFFFFFFFFFFFFC0 : target address
FFFFFFFF8098A8E8 : failing instruction addr
000000000000001B : processor state

[DECxchange]

Usually, the term script is a Unix term. in the (Open)VMS world, we refer to files that end in .COM as command files.

I know I'm repeating in a slightly different way as others have already replied, but ... Edit the file and then comment out the line:
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))

by putting an ! point just after the $. Add line after the now commented line and put in:
$ set veify

Then run the command file, and as the others have said, provide the output. If you look at sys$manager:sylogin.com, you can see how it handles batch, interactive, and network modes. You can use that as a pattern to prevent errors from commands that are intended to be run interactively when you are running a command file in batch.

If you don't know how to compile and link with the debugger, let us know. Also, what is the commmand file intended to do?

[Willem Grooters]

@ECxchange: thick fingers? hurry? :D

[quote]
Edit the file and then comment out the line:
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))

by putting an ! point just after the $.
[/quote]

The first one in the line, that is ;)

[quote]
Add line after the now commented line and put in:
$ set veify
[/quote]

$ set verify

Even better (if you are the only group member (don't do this when a lot of users or jobs in a group are active!)

$ DEFINE /GROUP SYLOGIN_VERIFY 1

that would have logged every line in SYLOGIN.COM as well (without changing the file - which is actually a good thing for a basic file!) so an illegal SET TERMINAL would have been noticed.
And it's easier to reverse:

$ DEASSIGN /GROUP SYLOGIN_VERIFY

Actually the first thing I would have done.

[Jon Pinkley]

RE: "Also, what is the commmand file intended to do?"

My guess is that it is the system wide sylogin given:

$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))

If that's the case and you only want verification turned on for your specific username, you could put something like

$ if f$edit(f$getjpi("","USERNAME"),"TRIM") .eqs. "LIM" then set verify

immediately after the $ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))

and then verification would always be on for the username "LIM" (change to whatever username you want to test with.)

Good luck,

Jon