Showing results for 
Search instead for 
Did you mean: 


Occasional Advisor


I have one problem with VAX BASIC.
In one program i used the routine sys$asctim and it worked fine. but when i called this routine inside another routine some error is coming.
The error code i am getting is 35(memory access problem)
please help me how to solve this problem.
Steven Schweda
Honored Contributor


It sounds as if there may be an error in your
program. I'm pretty sure that if you find
it and fix it, that will solve your problem.

If you can't provide a simple test case, you
might try calling a Psychic Hot-line, as
that's about as likely to work as any
guessing you can get here based on virtually
no information.
Robert Gezelter
Honored Contributor



Without the program (and I am not offering do debug your program), I suggest that you compare the parameters in the two codes, the one that works, and the one that does not work. There is likely a difference in the declaration of the parameters to the sys$asctim system service.

There is also a lesser possibility that the "working" version also is incorrect, and succeeded due to some quirk of the way that the code was compiled, or the time value or format being used for the conversion.

- Bob Gezelter,
Hein van den Heuvel
Honored Contributor


>> i used the routine sys$asctim and it worked fine.

No kidding. Applause! :-).

Actually... are you _sure_ it worked fine, or did it happen to work?

Is it supposed to return date, date+time, or delta? the 4th argument (cvtflg) is NOT optional. If a program fails to provide it, then $ASCTIM will test an uncontrolled bit of memory to decide what to do.

>> please help me how to solve this problem.

How did you know it was that particular call? (Basic ERL?)

Does it always fail?

Using the debugger, can you verify all the arguments to the call, notably the string descriptor internals using DBG> ex/hex/quad
If the descriptor is hosed, then you'll need a SET WATCH on it. You DID use a fixed length string descriptor (BASIC: STATIC STRING in COMMON or MAP) or at least a conciously pre-allocated dynamic string? (BASIC: my_date$ = "xx-xxx-xxxx xx:xx:xx.xx")

The debugger may be able to help more if you do a SET BREAK/EXCEP before the prolem and trap the bad memory reference right when it happens.

For us to help you'll have to provide some code snippets for the suspected call, and the declarations and recent usage for the arguments (and prototype).

Ideally you isolate that problematic call
to a seperate program and you will likely find the cause even before you share the code here!


Honored Contributor


Hello and welcome to ITRC.

35? The system service status code 35 is either a (bogus) no-privileges error, or a (bogus) bad-attribute status, assuming decimal or hexadecimal. It's not a valid error for a system service, based on what I can locate. The most classic memory access problem on OpenVMS is the ACCVIO, and that is 12 (decimal). If you're looking at the BASIC error code 35, that is "MEMMANVIO, Memory management violation (ERR=35)". But that's not the status from the sys$asctim system service call. Most system services return a status code, and you'll want to process that and particularly determine if the value is even (failure) or odd (success), and for specific errors.

Here is some example code; this corner of the OpenVMS manuals specifically shows a BASIC program calling sys$asctim service:

As for research, I'd encourage you to avoid the HP search engine to search the HP website, or the HP manuals. Use Google with the keyword. If you're specifically searching the manuals, use

Beyond the manuals, there are also source code examples available from various sources, including the HP support databases and the OpenVMS Freeware. Pointers to typical resources are in the OpenVMS FAQ and other documents.

What to do? Start with the source code from the manual, and compare it to your source code. Then use the debugger to walk through the code, and through the particular argument list and the before and after.

And again, welcome to the ITRC.

Stephen Hoffman
Occasional Advisor


thank you very much for your kind information