Unnamed struct members allowed?

[Jalapeno]

I've a CICS program that uses BMS maps. Our wysiwyg map editor produces
it's source in COBOL so I am manually creating C unions to match the
COBOL output. Can I convert the FILLER statements to unnamed struct
members or am I stuck with the scenario using filler0, filler1, filler2
etc. ?


01 PIDCI.
02 FILLER PICTURE X(12).
02 MAPTRANIDL COMP PICTURE S9(4).
02 MAPTRANIDF PICTURE X.
02 FILLER PICTURE X(04).
02 MAPTRANIDI PICTURE X(04).
etc...
etc...
etc...
01 PIDCO REDEFINES PIDCI.
02 FILLER PICTURE X(12).
02 FILLER PICTURE X(02).
02 MAPTRANIDA PICTURE X.
02 MAPTRANIDC PICTURE X.
02 MAPTRANIDP PICTURE X.
02 MAPTRANIDH PICTURE X.
02 MAPTRANIDV PICTURE X.
02 MAPTRANIDO PICTURE X(04).
02 FILLER PICTURE X(02).
etc...
etc...
etc...


union pidc {
struct pidci {
unsigned char filler0??(12??); /* <---<< here */
int maptranidl;
unsigned char maptranidf;
unsigned char filler1??(4??); /* <---<< here */
unsigned char maptranidi??(4??);
etc...
etc...
etc...
} pidci; /* struct pidci */

struct pidco {
unsigned char filler0??(12??); /* <---<< here */
unsigned char filler1??(2??); /* <---<< here */
unsigned char maptranida;
unsigned char maptranidc;
unsigned char maptranidp;
unsigned char maptranidh;
unsigned char maptranidv;
unsigned char maptranido??(4??);
unsigned char filler2??(2??); /* <---<< here */
etc...
etc...
etc...
} pidco; /* struc pidco */
} pidc; /* union pidc */

 

[Walter Roberson]

I've a CICS program that uses BMS maps. Our wysiwyg map editor produces
it's source in COBOL so I am manually creating C unions to match the
COBOL output. Can I convert the FILLER statements to unnamed struct
members or am I stuck with the scenario using filler0, filler1, filler2
etc. ?

Within a C struct: sorry, no, every field must be named
[with the exception of a bitfield specified as :0 -- which has
to do with bitfield alignment and has no practical value for
your situation.]

 

[CBFalconer]

I've a CICS program that uses BMS maps. Our wysiwyg map editor
produces it's source in COBOL so I am manually creating C unions
to match the COBOL output. Can I convert the FILLER statements
to unnamed struct members or am I stuck with the scenario using
filler0, filler1, filler2 etc. ?

Within a C struct: sorry, no, every field must be named
[with the exception of a bitfield specified as :0 -- which has
to do with bitfield alignment and has no practical value for
your situation.]

He was also reflecting a COMP 4 item as an int. Even if the
storage is the same, there may be alignment problems handled by
Cobol, but not C. IIRC, it's been at least 20 years since I did
any Cobol. Not greatly missed.

--
Some informative links:
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

 

[Charles Richmond]

I've a CICS program that uses BMS maps. Our wysiwyg map editor
produces it's source in COBOL so I am manually creating C unions
to match the COBOL output. Can I convert the FILLER statements
to unnamed struct members or am I stuck with the scenario using
filler0, filler1, filler2 etc. ?

Within a C struct: sorry, no, every field must be named
[with the exception of a bitfield specified as :0 -- which has
to do with bitfield alignment and has no practical value for
your situation.]

He was also reflecting a COMP 4 item as an int. Even if the
storage is the same, there may be alignment problems handled by
Cobol, but not C. IIRC, it's been at least 20 years since I did
any Cobol. Not greatly missed.

I do miss writing in Cobol, and I miss it quite pleasantly TYVM.

 

[Jalapeno]

Within a C struct: sorry, no, every field must be named

Thanks. I'm currently programming in COBOL, REXX, and C and maintaining
old BAL, CLIST and PL/I code and sometimes get the features mixed up.

 

[Jalapeno]

He was also reflecting a COMP 4 item as an int. Even if the
storage is the same, there may be alignment problems handled by
Cobol, but not C.

COMP S9(4) is a 32 bit signed computational field. It translates to int
with z/OS C compilers. It may not on other platforms but CICS regions
are sparse outside of z/OS (although I do have CICS for Windows loaded
on my PC and I've read some shops still use CICS for VSE).

... IIRC, it's been at least 20 years since I did
any Cobol. Not greatly missed.

I have no particular love for COBOL myself and I moved into CICS
systems programming when my COBOL application job went to India.
Unfortunately, we systems programmers are now spending half our time
"teaching" outsourced applications programmers how to do the jobs they
took from us.

 

[SM Ryan]

# I've a CICS program that uses BMS maps. Our wysiwyg map editor produces
# it's source in COBOL so I am manually creating C unions to match the
# COBOL output. Can I convert the FILLER statements to unnamed struct
# members or am I stuck with the scenario using filler0, filler1, filler2
# etc. ?

Unless you're exploiting compiler specific options, you cannot
depend on struct fields ending up on any particular byte or bit
boundary.

An alternative way is to use a char array and place fields
manually. Such as

# 01 PIDCI.
# 02 FILLER PICTURE X(12).
# 02 MAPTRANIDL COMP PICTURE S9(4).
# 02 MAPTRANIDF PICTURE X.
# 02 FILLER PICTURE X(04).
# 02 MAPTRANIDI PICTURE X(04).

typedef char PIDCI[12+4+1+4+4+...];
enum {
oPIDC1MAPTRANIDL = 12, lPIDC1MAPTRANIDL = 4,
oPIDC1MAPTRANIDF = 12+4, lPIDC1MAPTRANIDF = 1,
oPIDC1MAPTRANIDI = 12+4+1+4, lPIDC1MAPTRANIDI = 4,
...
};
int getInt1(char *a,int o,int l) {
int r = 0; memcpy(&r,a+o,l); return r;
}
void putInt1(char *a,int o,int l,int v) {
int r = v; memcpy(a+o,&r,l);
}

#define getInt(a,field) (getInt1(a,o##field,l##field))
#define putInt(a,field,v) (putInt1(a,o##field,l##field,v))

#define getChar(a,field) ((a)[o##field])
#define putChar(a,field,v) ((a)[o##field]=(v))

#define getChars(a,field,r) (memcpy(r,(a)+o##field,l##field))
#define putChars(a,field,v) (memcpy((a)+o##field,v,l##field))

 

[Jalapeno]

Unless you're exploiting compiler specific options, you cannot
depend on struct fields ending up on any particular byte or bit
boundary.

How the struct members are aligned is documented for both C and COBOL.
Without getting into off topic details, the COBOL and C compilers
"working storage"/"automatic variables" in CICS match the layout of the
BMS assembler macro. My job as a C programmer in this instance is
basically to make sure the C type matches the COBOL type and let the
compiler do the work. Using an unsigned (or plain) char array is, I
believe, actually treading on ice-more-thin in this situation. Thanks
for the interesting idea. My question was really about C's syntax
rather than about converting COBOL.

 

[Jalapeno]

Unfortunately, we systems programmers are now spending half our time
"teaching" outsourced applications programmers how to do the jobs they
took from us.

After rereading what I wrote here it sounds more harsh than I intended.
I have nothing against folks competing in a global economy. I work with
individuals who are quite bright. If I have a beef it is with
outsourcing companies that get a contract, hire newby programmers, give
them a few weeks training, and then put them on the job less than half
prepared. I hope I did not offend anyone with that statement.

 

[Keith Thompson]

How the struct members are aligned is documented for both C and COBOL.

Correction: it may be documented for your particular implementation.
The C standard makes only a few guarantees about how struct members
are allocated. A compiler may insert arbitrary padding between
members, or after the last member. I don't believe it's even required
to document how it does so, or to behave consistently across different
phases of the moon.

If you're working in an environment that makes additional guarantees,
of course, you're free to depend on those guarantees; just be aware
that your code could break if it's ported to another implementation.

 

[CBFalconer]

How the struct members are aligned is documented for both C and COBOL.

.... snip ...

Not for C it isn't. I believe the only guarantee you have is that
the address of the first component is also the address of the
complete structure.

 

[Keith Thompson]

... snip ...

Not for C it isn't. I believe the only guarantee you have is that
the address of the first component is also the address of the
complete structure.

And that addresses of other members increase in the order in which
they're declared, and (implicitly) that the layout leaves at least
enough room for each member.

 

[SM Ryan]

# How the struct members are aligned is documented for both C and COBOL.
# Without getting into off topic details, the COBOL and C compilers

For a specific C compiler. Other C compilers might lay out a
struct differently. The first field is at the very beginning
of the struct, and subsequent fields are strictly increasing
offsets, but there's no guarentee by the language definition
what those offsets will be.