HP Basic on Open VMS on VAX and Alpha

[Richard Glyn-Jones]

Using Basic on VAX to open a file with an illegal file name I get ERR 2 ILLFILMAN, the same program on the Alpha I get ERR 162 CANOPEFIL. Can anyone explain why I get a different error.

[Hein van den Heuvel]

So what is the filespec?
Anything 'funny' about the spec?
Is it expected to work?

What is the detail status (RMS -STS and RMS -STV), if you can get that?

ods-2 vs ods-5 ?

hth,
Hein.

[Richard Glyn-Jones]

Thanks for the quick response.
The original piece of cade was to trap any illegal fiel name entered by a User ( I used in this test filename Test.dat.dat.) When run on the VAX the error handler retunr ERR 2 and hence the ILLFILMAN. On the Alpha the error returned is ERR 162 RMS-E-CRE ACP file create failed.

[John Abbott_2]

The file spec mentioned is not legal on an ods-2 volume, which I suspect you're using.

J.

[Richard Glyn-Jones]

Thanks, I've looked at both Vax and Alpha and both disk structures are ODS-2.

[Steven Schweda]

> [...] both disk structures are ODS-2.

Ok, but the Basic RTL on a VAX has no need
to deal with an OSD5 extended file name,
while the Basic RTL on a non-VAX may need to
deal with one, so it's not very amazing that
one would give a different status code than
the other for an ODS5-legal name. On a VAX,
a name like that is always illegal, while on
a non-VAX, its validity depends on the
structure level of the device, so different
code may be complaining.

[Richard Glyn-Jones]

Thanks for all the info. I've been looking at the programs that I am transferring from VAX to Alpha and have found something which might help you with helping me. In the Program the User starts by entering a file name, or a db class name (indicates which db file will open). If you select the class first it opens a default file name, however if you select a file first the User has then to select a class. On the VAX this works ok and if the User put in either an illegal file name or class name then an appropriate error message is displayed and the User can cycle through these two commands putting in legal and illegal values, each occurence is handled correct by the error handler. On the Alpha however after an illegal file name which is handled correctly any subsequent legal entry produces an ERR 194 Non Basic.
I believe in one occurance the RMSSTATUS status was 8 but I can't find out what this means. I realy appreciate the help as I'm lost at the moment.

[Steven Schweda]

Sounds like a (potentially) actual program
bug, which needs to be removed the
old-fashioned way. Knowing nothing, I'd guess
that after the troublesome error, something
is not being reset properly for the next pass
through the code. It's possible that on the
Alpha, something got optimized away, which
had been helping you out on the VAX.

It could be some Basic defect, too, of
course, but proving that involves about the
same steps as finding the problem if it's
yours.

I don't know what "ERR 194 Non Basic" is
trying to say, but if it's decimal:

alp $ exit 194
%SYSTEM-E-GPTFULL, global page table is full

Perhaps a little AUTOGEN action is in order
on the new system? (Seems unlikely.)

[Richard Glyn-Jones]

Thanks I've tried most thing now and my problem seems to hinge around solving what ERR 194 means and how I translate the status from either VMSSTATUS or RMSSTATUS into something I can understand. Is there any documentation that lists these codes or sample code that can be used to translate them

[Ian Miller.]

Values from VMSTATUS or RMSSTATUS can be simply translated using the exit command at a dcl prompt

$ exit 194
%SYSTEM-E-GPTFULL, global page table is full

[Volker Halle]

... but you also need to know the radix (i.e. the actual print format statement used):

$ exit %x194
%SYSTEM-F-LKWSETFUL, locked portion of working set is full

This would be the correct message code, if the number is to be interpreted in HEX (hex numbers would usually be shown with leading zeroes, but you never know, if the message is coming from an application)

Volker.

[Steven Schweda]

I really don't do much with BASIC, but a
little looking at the documentation on the
HP Web site (HP BASIC for OpenVMS \ User
Manual -- Appendix B \ Run-Time Messages)
revealed this:

NOTBASIC, Not a BASIC error (ERR=194)
Explanation: The error is not a HP BASIC error and is not mapped to an alternative HP BASIC error message.
User Action: Use RMSSTATUS or VMSSTATUS to access the text of the error message.

> [...] how I translate the status from
> either VMSSTATUS or RMSSTATUS into
> something I can understand.

The DCL "EXIT " method might
work. Dare one ask what the VMSSTATUS and/or
RMSSTATUS values might be?

[Phil.Howell]

This link is a few years old, but should be worth a read as it focuses on basic.
Phil
http://www3.sympatico.ca/n.rieck/docs/alpha_diary.html

[Richard Glyn-Jones]

Okay so can anyone tell me what VMSSTATUS 135495866m 13548=95858 and 135495906 mean.

[Richard Glyn-Jones]

Okay so can anyone tell me what VMSSTATUS 135495866 135495858 and 135495906 mean.

[Ian Miller.]

On which version of VMS?

[Richard Glyn-Jones]

Oh just another development I also get VMSSSTATUS 16842772 which if I insert after exit 16842772 I getr the following
RTE-F_BADPARAM Bad parameter value.

[Richard Glyn-Jones]

Oh just another development I also get VMSSSTATUS 16842772 which if I insert after exit 16842772 I getr the following
RTE-F-BADPARAM Bad parameter value.

[Richard Glyn-Jones]

Oh just another development I also get VMSSSTATUS 16842772 which if I insert after exit 16842772 I get the following
RTE-F-BADPARAM Bad parameter value.

[Richard Glyn-Jones]

VMS Im running is OpenVMS V7.3-2

[Steven Schweda]

Those first VMSSTATUS values all look like
junk (%NONAME-E-NOMSG) to me. The last one
looks no better, really.

[Robert Brooks_1]

This thread has gotten a bit off the track.

What problem are you attempting to solve?

Once you've recognised that VAX BASIC and DEC BASIC for OpenVMS Alpha can return differing error messages in this specific instance, can't you simply account for that fact in your code?

Not that it's particularly relevant, but are you using the WHEN ERROR or ON ERROR GOTO contruct for error trapping?


-- Rob (VMS Engineering)

[Phillip Thayer]

Rob has a point. If you were using the WHER ERROR or ON ERROR GOTO constructs in the VAX to trap a specific error code it will be a different error code number on the Alpha. It seems to me that is where you need to make a change for the Alpha code. You can accomplish this all in the same code by using a compile variant as well.

Also, when I was doing some porting of VAX Basic to Alpha OpenVMS Basic if I did not use the /NOOPTIMIZE with my VAX code that I was trying to get to work on the Alpha it would cause some pretty strange problems. I can't remember specific problems but I do remember that I had to change my compile utility on the Alpha to use /NOOPTIMIZE.

Phil

[Robert Brooks_1]

Also, when I was doing some porting of VAX Basic to Alpha OpenVMS Basic if I did not use the /NOOPTIMIZE with my VAX code that I was trying to get to work on the Alpha it would cause some pretty strange problems. I can't remember specific problems but I do remember that I had to change my compile utility on the Alpha to use /NOOPTIMIZE.

---

Did you report that to us? I know that we've fixed a few DEC BASIC compiler optimization issues, and there is big difference on both Alpha and I64 between optimized and nonoptimized code.

I don't doubt that there may still be a few issues lurking, so please report it if you haven't already.

-- Rob

[Richard Glyn-Jones]

Yes I agree with most of what you say, it has got a little muddled. However I think I'm getting there. The offending line in the code is

file_status = rmsstatus(batch_channel,status)

This line of code is used to check whether a file is open on a channel. When executed by the error handler it returns Basic ERR 194.
File status is declared as a Double.