DEC C/TCPWARE/globalvalue problem

DEC C/TCPWARE/globalvalue problem

Post by covendotartdottalk21dotco » Thu, 26 Jun 2003 04:59:06



Hi, folks.

I'm trying to provide an interim solution prior to some Vaxen
(5.5-2H4) being replaced with Alphas running somewhat more
recent versions of OVMS, which necesssitates me developing a
C program (to avoid the hideous error-handling problems of
DCL) to FTP some files to/from a U*ix box.

However, I'm encountering a problem whilst trying to use
mandatory globalvalue "definitions" that TCPWARE uses for
its error codes (TCPWARE_NONODE &etc.).

Okay, things are obviously a little bit out of date, but the
TCPWARE 5.1 programmer's reference manual says that in order
to access these codes, they need to be defined as globalvalues.

I don't have a problem with this (I've never used globalvalue
before, only globaldef and globalref, so you'll pardon my
ignorance if I don't understand why TCPWARE doesn't just use
header files and #defines), but I'm having a problem with the
use of the values.

If I try to reference the values using

int a = TCPWARE_NONODE ;

or

printf("\nValue of TCPWARE_NONODE is %d", TCPWARE_NONODE) ;

then this doesn't prove to be a problem.

However, if I do something like:

switch (tcpware_error)
{
   case TCPWARE_NONODE :
    /* blah */
    break ;

   default :
    break ;

Quote:}

Then the DEC C compiler complains, saying that (in the case
statement) the TCPWARE_NONODE needs to be a constant, but
actually isn't (dialled in from PC at home at the moment, so
I don't recall the exact error message).

I've done a search on Google, and tried using references to

#pragma extern_model save
#pragma extern_model globalvalue
globalvalue TCPWARE_NONODE ;
#pragma extern_model restore

from a posting by Wayne Sewell (with me adding the globalvalue
reference as it appears here), to no avail.

On rereading the posting, I may have misspelt the "extern_model"
as "external_model" (but can't check just now), but the use of the
pragmas makes no difference, nor does it make any difference as to
whether or not /STANDARD=VAXC is used on the compilation.

Can anyone tell me what I'm doing wrong (and more importantly,
why?), and what benefits there are to using globalvalue on DEC C
or VAX C on a Vax, or plain old DEC C on an Alpha?

Are there any benefits at all, or is this just a peculiarity of
(extensions to) ANSI which would only be of use when porting to
other O/Ses?

I've also seen references to using "extern" as opposed to
"globalvalue" when using DEC C, and that it is an acceptable
alternative (according to one of the posts that the OpenVMS
Wizard shows on www.hp.com), but isn't (due to the obvious
default inference of "int") according to a comp.os.vms post,
and am somewhat perplexed.

Regards,

Mark (who doesn't read his Vax and Alpha architecture reference
manuals on a regular basis)

 
 
 

DEC C/TCPWARE/globalvalue problem

Post by John E. Malmber » Thu, 26 Jun 2003 07:05:09



> Hi, folks.

> I'm trying to provide an interim solution prior to some Vaxen
> (5.5-2H4) being replaced with Alphas running somewhat more
> recent versions of OVMS, which necesssitates me developing a
> C program (to avoid the hideous error-handling problems of
> DCL) to FTP some files to/from a U*ix box.

It may be simpler to solve that problem with DCL.  I use an FTP script
that copies the file to a temporary name and then renames it.  That way
the receiver never sees a partial transfer.  The $status code and
checking the output of the script can both be used to determine success.
  The SEARCH command can search for appropriate codes in a simple log
with out having to parse the logs.

Quote:> However, I'm encountering a problem whilst trying to use
> mandatory globalvalue "definitions" that TCPWARE uses for
> its error codes (TCPWARE_NONODE &etc.).

> Okay, things are obviously a little bit out of date, but the
> TCPWARE 5.1 programmer's reference manual says that in order
> to access these codes, they need to be defined as globalvalues.

> I don't have a problem with this (I've never used globalvalue
> before, only globaldef and globalref, so you'll pardon my
> ignorance if I don't understand why TCPWARE doesn't just use
> header files and #defines), but I'm having a problem with the
> use of the values.

A globalvalue is a link time constant.

Quote:> If I try to reference the values using

> int a = TCPWARE_NONODE ;

> or

> printf("\nValue of TCPWARE_NONODE is %d", TCPWARE_NONODE) ;

> then this doesn't prove to be a problem.

> However, if I do something like:

> switch (tcpware_error)
> {
>    case TCPWARE_NONODE :
>     /* blah */
>     break ;

>    default :
>     break ;
> }

> Then the DEC C compiler complains, saying that (in the case
> statement) the TCPWARE_NONODE needs to be a constant, but
> actually isn't (dialled in from PC at home at the moment, so
> I don't recall the exact error message).

The C compiler probably requires a case label to be a compile time
constant, so a global value can not be used.

Quote:> I've done a search on Google, and tried using references to

> #pragma extern_model save
> #pragma extern_model globalvalue
> globalvalue TCPWARE_NONODE ;
> #pragma extern_model restore

The extern model has nothing to do with how a global value is interpreted.

The extern model determines how "extern" declarations are handled by the
compiler.

The default for DEC/COMPAQ/HP C for OpenVMS is to treat extern variables
as global variables for other programming languages.  This is what most
programmers would expect.

The default for VAXC is to treat extern variables as psects or FORTRAN
common blocks.

globalref and globaldef were needed so that VAXC could access global
variables from other languages.

globalref is the same as extern with out assigning a value to to the
variable.  "extern int foo;"

globaldef is the same as extern when you assign a value to the variable.
  "extern int foo = 1".

Quote:> from a posting by Wayne Sewell (with me adding the globalvalue
> reference as it appears here), to no avail.

> On rereading the posting, I may have misspelt the "extern_model"
> as "external_model" (but can't check just now), but the use of the
> pragmas makes no difference, nor does it make any difference as to
> whether or not /STANDARD=VAXC is used on the compilation.

> Can anyone tell me what I'm doing wrong (and more importantly,
> why?), and what benefits there are to using globalvalue on DEC C
> or VAX C on a Vax, or plain old DEC C on an Alpha?

globalvalue may be easier to code than the ANSI equivalent.

Lets see if I can get this right from memory.

The C compiler really only knows external symbols as addresses, so with
out a globalvalue specification, you have to declare

    globalvalue int foo;

as:

    extern int *foo;

And then make sure that everything can accept a pointer.

Or you can use:

    extern int foo;

And then make sure that you reference &foo when ever you need it's value.

Quote:> Are there any benefits at all, or is this just a peculiarity of
> (extensions to) ANSI which would only be of use when porting to
> other O/Ses?

The use of /STANDARD=VAXC will supress some diagnostics from the
compiler.  I would recommend avoiding using it.

I would use /WARN=ENABLE=(LEVEL4, QUESTCODE) instead and fixing the bugs
that it reports, or using the #pragma message codes to disable the ones
that you think will not hurt your program.

-John

Personal Opinion Only

 
 
 

DEC C/TCPWARE/globalvalue problem

Post by covendotartdottalk21dotco » Thu, 26 Jun 2003 07:48:12




Quote:> Lets see if I can get this right from memory.

> The C compiler really only knows external symbols as addresses, so with
> out a globalvalue specification, you have to declare

>     globalvalue int foo;

> as:

>     extern int *foo;

> And then make sure that everything can accept a pointer.

> Or you can use:

>     extern int foo;

> And then make sure that you reference &foo when ever you need it's value.

However, the TCPWARE programmer's reference manual to which I have access,
doesn't say whether or not these "constant"s are char, unsigned char, int,
unsigned int, long, unsigned long, or exactly what "type" of variable, so I
have no idea whether or not "int" is the corect variable type!

I can't imagine that it is "safe" to just assume "int" (and that this, if
I'm currently correct, DEC C will continue to assume so for <indiscernible
time in the future>), or am I wrong?

I still don't see what PSC have to benefit by effectively using
globalvalue FOO as extern (*)FOO (and hence, by default, int (*) FOO in
both cases) - why the h*ll not just use #define???

Mark
(hoping to try out suggestions at work tomorrow if the $Ford_motor_vehicle
doesn't keep on spouting "EAC [Electronic ACcelerator] Fail" every time the
ignition is switched on, much less fail at $exceeding_speed_limit_MPH in
lane 2 of the motorway...)

 
 
 

DEC C/TCPWARE/globalvalue problem

Post by covendotartdottalk21dotco » Thu, 26 Jun 2003 20:02:36





> > Lets see if I can get this right from memory.

> > The C compiler really only knows external symbols as addresses, so with
> > out a globalvalue specification, you have to declare

> >     globalvalue int foo;

> > as:

> >     extern int *foo;

> > And then make sure that everything can accept a pointer.

> > Or you can use:

> >     extern int foo;

> > And then make sure that you reference &foo when ever you need it's

value.

[deletia]

Quote:> (hoping to try out suggestions at work tomorrow

Unfortunately, neither of these suggestions work.  In the meantime, I'm
using a repetetive

if (tcpware_error == TCPWARE_NONODE)
{

Quote:}

else if (tcpware_error == TCPWARE_NEEDACCT)
{
Quote:}

else if (tcpware_error == TCPWARE_OPENDATA)
{

Quote:}

yada yada yada.

Hardly elegant, but it works (or rather, compiles without error)

 
 
 

DEC C/TCPWARE/globalvalue problem

Post by John E. Malmber » Thu, 26 Jun 2003 23:38:05



> However, the TCPWARE programmer's reference manual to which I have access,
> doesn't say whether or not these "constant"s are char, unsigned char, int,
> unsigned int, long, unsigned long, or exactly what "type" of variable, so I
> have no idea whether or not "int" is the corect variable type!

Since this is VAX, the safe thing to assume is that it is unsigned long.

For more details, you would have to contact someone who supports TCPWARE.

Quote:> I can't imagine that it is "safe" to just assume "int" (and that this, if
> I'm currently correct, DEC C will continue to assume so for <indiscernible
> time in the future>), or am I wrong?

C tends to assume that some things are "int", but generaly it will
believe what you tell it.

In some cases, there is a significant difference between how an unsigned
and signed variable is treated, and /STANDARD=VAXC will usually not tell
you about the problem.

Quote:> I still don't see what PSC have to benefit by effectively using
> globalvalue FOO as extern (*)FOO (and hence, by default, int (*) FOO in
> both cases) - why the h*ll not just use #define???

You would have to ask the TCPWARE developer.  Some global values are
generated at compile time, so that it would take some work to update and
maintain a header file to #define them.

I prefer "const static int FOO = 0x00ffh" instead of a #define in some
cases, because #define macros are not visible to the de*.

Quote:> Mark
> (hoping to try out suggestions at work tomorrow if the $Ford_motor_vehicle
> doesn't keep on spouting "EAC [Electronic ACcelerator] Fail" every time the
> ignition is switched on, much less fail at $exceeding_speed_limit_MPH in
> lane 2 of the motorway...)

Open gas cap to equalize pressure and then close it before activating
ignition and see if that makes a difference.

-John

Personal Opinion Only

 
 
 

DEC C/TCPWARE/globalvalue problem

Post by John E. Malmber » Thu, 26 Jun 2003 23:51:15







>>>Lets see if I can get this right from memory.

>>>The C compiler really only knows external symbols as addresses, so with
>>>out a globalvalue specification, you have to declare

>>>    globalvalue int foo;

>>>as:

>>>    extern int *foo;

>>>And then make sure that everything can accept a pointer.

>>>Or you can use:

>>>    extern int foo;

>>>And then make sure that you reference &foo when ever you need it's

> value.

> [deletia]

>>(hoping to try out suggestions at work tomorrow

> Unfortunately, neither of these suggestions work.  In the meantime, I'm
> using a repetetive

As to if they work or not, it depends on what you are trying to do.

The three different codings still produce a link time constant, and if
you are trying to do something that requires a compile time constant, of
course it will not work.

I was just pointing out that the VAXC globalvalue notation is easier to
read and understand than the two equivalent ANSI C notations.

The C language (to my knowlege) does not have a concept of an external
constant that is not known at compile time, so the only way to represent
it is a hack to treat it as an external address.

A switch statement requires a compile time constant to operate on.

Quote:> if (tcpware_error == TCPWARE_NONODE)
> {
> }
> else if (tcpware_error == TCPWARE_NEEDACCT)
> {
> }
> else if (tcpware_error == TCPWARE_OPENDATA)
> {
> }

> yada yada yada.

> Hardly elegant, but it works (or rather, compiles without error)

If these values were generated by the MESSAGE utility, then they are bit
encoded and should comply with the OpenVMS conventions, and that will
allow more efficient coding.  You will have to check the documentation
or contact someone at TCPWARE to confirm that.

-John

Personal Opinion Only

 
 
 

DEC C/TCPWARE/globalvalue problem

Post by covendotartdottalk21dotco » Sat, 28 Jun 2003 06:56:10





> > Mark
> > (hoping to try out suggestions at work tomorrow if the
$Ford_motor_vehicle
> > doesn't keep on spouting "EAC [Electronic ACcelerator] Fail" every time
the
> > ignition is switched on, much less fail at $exceeding_speed_limit_MPH in
> > lane 2 of the motorway...)

> Open gas cap to equalize pressure and then close it before activating
> ignition and see if that makes a difference.

A call from the dealership today says that (and I'm not sure whether, like
the
last "fix", this is because they're trying it to see if it fixes the
problem,
or because they've definitely determined that this is the cause) a
replacement
module and/or part of the wiring loom has been ordered, because for some
reason
the male/female connectors weren't making a snug fit.

Bad batch?  Design fault?  who knows.  All I hope is that they get it done
soon, because the courtesy car doesn't have (and $deity knows I coped before
without) aircon!

 
 
 

DEC C/TCPWARE/globalvalue problem

Post by covendotartdottalk21dotco » Sat, 28 Jun 2003 07:10:36




Quote:> As to if they work or not, it depends on what you are trying to do.

> The three different codings still produce a link time constant, and if
> you are trying to do something that requires a compile time constant, of
> course it will not work.

Although I bought a book (cough) years ago on compiler design, I never
got around to reading it.

Is this likely to be just the DEC C (and possibly VAX C) compiler(s) that
require case statements to have compile-time constants, but (e.g.) Micro$oft
and various U*ix wannabes/contenders don't?  Where would this be documented
that DEC C (rightly/wrongly) imposes this constraint?  (I don't have the
manuals to hand, and I often find that knowing what to look up in the
indices
is the main problem - you don't know what you're looking for much less where
to look for it)

The IF..ELSE IF...ELSE IF...ELSE IF construct did work (although I accept
you may have misgivings as to whether or not things "seem" to work because
of the use of /STAND=VAXC) - I had success in connecting, logging in,
changing directory and getting a directory listing from the remote U*ix
box.

So, I've got about 1/3 of the FTP stuff implemented now (as I worked from
home, and omitted to take a copy of the TCPWARE programmer's reference
home with me;  had a go at guessing the params for its FTP_PRINT_DIRECTORY
function, but got that wrong!).

All I need now (apart from implementing about another 10 "logical" FTP
functions) is a routine to parse the directory listing (of the specific
version of Slowlartis running on the Sun box that I'm doing this initial
development for);  I've no idea whether or not U*ix boxes in general return
the same "ls {-l}" format, because I think that without being able to REXEC
(which might be disabled for obscurity^W security reasons), you wouldn't be
able to tell what U*ix flavour was running on the remote box, much less
which version, and whether or not "ls {-l}" output changes significantly
between flavours/versions - although I'd hope not!

Quote:> I was just pointing out that the VAXC globalvalue notation is easier to
> read and understand than the two equivalent ANSI C notations.

Agreed.  I got the impression that you weren't sure if the ANSI notations
would work, so was just letting you know for your own benefit, should this
come up in future.

Thanks for your sage advice though.

Mark

 
 
 

DEC C/TCPWARE/globalvalue problem

Post by Bob Koehl » Sat, 28 Jun 2003 21:26:19



Quote:

> Is this likely to be just the DEC C (and possibly VAX C) compiler(s) that
> require case statements to have compile-time constants, but (e.g.) Micro$oft
> and various U*ix wannabes/contenders don't?  Where would this be documented
> that DEC C (rightly/wrongly) imposes this constraint?

   I looked this up once upon a time when VAX C refused to accept link
   time constants for case labels.  It was in the VAX C reference
   manual, not highlighted as an extension or exception to the then
   new ANSI C standard.

   And I thought it was silly, but I had to code up a whole bunch of
   else if to deal with it.

 
 
 

DEC C/TCPWARE/globalvalue problem

Post by Ed Voge » Sat, 28 Jun 2003 23:22:14


| Is this likely to be just the DEC C (and possibly VAX C) compiler(s) that
| require case statements to have compile-time constants, but (e.g.)
Micro$oft
| and various U*ix wannabes/contenders don't?

    I don't know of any compiler that accepts a link-time constant for a
case statement.

    To quote from the (C99) Standard:

        "The expression of each case label shall be an integer constant
expression...."

| The IF..ELSE IF...ELSE IF...ELSE IF construct did work (although I accept
| you may have misgivings as to whether or not things "seem" to work because
| of the use of /STAND=VAXC) - I had success in connecting, logging in,
| changing directory and getting a directory listing from the remote U*ix
| box.

    Another option to the nested if stuff is to create a function dispatch
table that
    will dispatch to the correct function based on a runtime value.  The
function dispatch
    table can be initialized using designated initializers once at runtime.

    Ed Vogel
    HP C for OpenVMS Development.

 
 
 

1. Globalvalue in DEC-C

|>   Here's one that got me baffled. We are moving from VAX C to DEC C, going
|>from VMS5.5-2 to 6.1. Now, DEC C does not support globalvalue and on Alpha,
|>there is no VAX C options, which we are also migrating to. However, globalvalue
|>seems to be the only way to reference status codes in objects generated
|>by the message facility (from .msg files).
|>   The question is, how do I reference status code generated by the message
|>facility from C? Defining them as constants in header does not seem to make
|>sense and can be tedious to maintain. Using extern in place of globalvalue
|>doesn't work either.
|>Thanks!

    You can get what you want using extern and the external models,
    but I would avoid the global* extensions.  Check the documentation
    included on the OpenVMS VAX consolidated on-line documentation
    CD-ROM for details on migrating from VAX C to DEC C -- including
    information on global* migration.  This documentation is located
    in the DEC C bookshelf.

    I would suggest a completely different approach, though.  I would
    obtain a copy of the (unsupported) SDL utility from the DECUS
    (unsupported) Freeware CD-ROM.

    The standard MESSAGE utility can generate an SDL file containing
    the message code definitions, and the SDL utility can be used to
    convert this file into a file suitable for inclusion into most
    languages.

    Here is an example of the commands used to do this:

      $ MESSAGE/SDL=mumble.SDL mumble.MSG
      $ SDL/VMS/LANGUAGE=C=mumble.h mumble.SDL

    This is the method used by many Digital products to generate message
    condition value include files...  SDL and the MESSAGE/SDL stuff is,
    however, unsupported.  (Have I said the `u-word' often enough? :-)

    Don't ask me where the freeware CD-ROM is available -- I don't know.
    I have seen references to its availability at various sites, though.
    Hopefully somebody will jump in here with a pointer.

  ------------------------------ Opinionative -------------------------------

        OpenVMS Engineering, Digital Equipment Corporation, Nashua NH

2. network scanner

3. DEC now cooperates with TCPware

4. WatchGuard Firebox SOHOtc any good?

5. "globalvalue" in VAX-Pascal?

6. Perl

7. TCPware to TCPIP FTP connect problem.

8. Will the one, the true, WEB stand up, please?

9. Apache (CSWS), TCPware and DCL cgi-bin problems

10. Apache CGI Problems on VMS with TCPware

11. TCPware/Purveyor Problem - Part 2

12. TCPware/Purveyor Problem

13. NFS problems over TCPWARE