By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,388 Members | 1,761 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,388 IT Pros & Developers. It's quick & easy.

Unnamed struct members allowed?

P: n/a
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 */

Jun 15 '06 #1
Share this Question
Share on Google+
12 Replies


P: n/a
In article <11*********************@c74g2000cwc.googlegroups. com>,
Jalapeno <ja*******@mac.com> wrote:
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.]
--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson
Jun 15 '06 #2

P: n/a
Walter Roberson wrote:
Jalapeno <ja*******@mac.com> wrote:
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:
news:news.announce.newusers
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
Jun 15 '06 #3

P: n/a
CBFalconer wrote:

Walter Roberson wrote:
Jalapeno <ja*******@mac.com> wrote:
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.

--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
Jun 16 '06 #4

P: n/a
Walter Roberson wrote:
In article <11*********************@c74g2000cwc.googlegroups. com>,
Jalapeno <ja*******@mac.com> wrote:
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


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.

Jun 16 '06 #5

P: n/a

CBFalconer wrote:
Walter Roberson wrote:
Jalapeno <ja*******@mac.com> wrote:
Our wysiwyg map editor produces it's source in COBOL so I am manually creating C unions
to match the COBOL output.
Within a C struct: sorry, no,


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.

Jun 16 '06 #6

P: n/a
"Jalapeno" <ja*******@mac.com> wrote:
# 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))

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Raining down sulphur is like an endurance trial, man. Genocide is the
most exhausting activity one can engage in. Next to soccer.
Jun 16 '06 #7

P: n/a

SM Ryan wrote:

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.

Jun 16 '06 #8

P: n/a

Jalapeno wrote:
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.

Jun 16 '06 #9

P: n/a
"Jalapeno" <ja*******@mac.com> writes:
SM Ryan wrote:
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.


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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jun 16 '06 #10

P: n/a
Jalapeno wrote:
SM Ryan wrote:

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.

.... 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.

--
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Jun 16 '06 #11

P: n/a
CBFalconer <cb********@yahoo.com> writes:
Jalapeno wrote:
SM Ryan wrote:

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.

... 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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jun 16 '06 #12

P: n/a
# 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.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
I love the smell of commerce in the morning.
Jun 16 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.