RE: [open-cobol-list] OC issues

[Bill Klein]

It sounds reasonable to include this in an extension (that gets flagged
when/if ANSI required flagging is in effect).

I haven't checked Micro Focus, but IBM does document this as a "valid"
extension at:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3lr30/APPENDIX
1.1 

"Specifying level numbers that are lower than other level numbers at the
same hierarchical level in a data   description entry. [Standard COBOL 85
requires that all  elementary or group items at the same level in the
hierarchy be assigned identical level numbers."

  ***

Just like providing FULL '85 Standard (and possibly '02 Standard) support
seems a reasonable goal, someone MAY want to track OC support for ALL of the
extensions documented in that appendix.

> -----Original Message-----
> From: Sergey Kashyrin [mailto:address@hidden 
> Sent: Tuesday, January 17, 2006 11:56 AM
> To: Bill Klein; address@hidden
> Subject: Re: [open-cobol-list] OC issues
> 
> Bill,
> 
> > So then, it has nothing to do with your original
> >  COPY C2 REPLACING ==01 == BY ==02 ==
> > If it DOES, then please show the exact COPY statement(s) 
> and what is in each
> > COPY member.
> 
> No, it's nothing to do with COPY REPLACING.
> It just happened in my particular case because of the COPY REPLACING.
> 
> > Certainly having an 02-level AFTER an 05-Level - when there 
> is no 02 level
> > above is NON-Standard and not something that COBOL source 
> code is SUPPOSED to do.
> 
> Yes, it's NON-standard. But what I'm telling is if we want 
> "dialects" like MVS, IBM or MF than we should react on this 
> NON-standard 
> situation the same way.
> 
> > P.S.  Having
> >    REPLACING ==01 == BY ==02 ==
> > in source code is ALWAYS dangerous, because given source code like:
> > 01 Field1.
> >       05  Field2  Pic X(01).
> > BOTH the 01 level indicator and the 01 in the picture will 
> get replaced. The
> > space is NOT significant in COPY REPLACING pseudo-text.
> 
> Yes, that's true, but I didn't wrote that stupid code !!!
> And as I see now the levels mismatch happens in the code not 
> only because of COPY.
> 
> Regards,
> Sergey.
> 
> 
> >> -----Original Message-----
> >> From: Sergey Kashyrin [mailto:address@hidden
> >> Sent: Tuesday, January 17, 2006 10:54 AM
> >> To: Bill Klein; address@hidden
> >> Subject: Re: [open-cobol-list] OC issues
> >>
> >> Bill,
> >>
> >> It's not about the margin.
> >> That will work:
> >> 01 A.
> >> 02 FILLER.
> >> 05 FIELD PIC X.
> >> 02 FLD2 PIC X.
> >>
> >> That does not work:
> >> 01 A.
> >> 05 FIELD PIC X.
> >> 02 FLD2 PIC X.
> >>
> >> ----- Original Message ----- 
> >> From: "Bill Klein" <address@hidden>
> >> To: "'Sergey Kashyrin'" <address@hidden>;
> >> <address@hidden>
> >> Sent: Tuesday, January 17, 2006 11:46 AM
> >> Subject: RE: [open-cobol-list] OC issues
> >>
> >>
> >> > Sorry,
> >> >  Your reply still doesn't make sense.  It is PERFECTLY
> >> legal to change an
> >> > 01-level to an 02-level (before an 05-Level) ASSUMING that
> >> you have an
> >> > 01-level in the structure.  As I indicated, there are
> >> issues about 01-levels
> >> > being in the A-margin and 02-levels being in the B-margin.
> >> >
> >> > I don't think anyone is going to be able to help you until
> >> you can show us
> >> > the actual code and error messages.
> >> >
> >> >> -----Original Message-----
> >> >> From: address@hidden
> >> >> [mailto:address@hidden On
> >> >> Behalf Of Sergey Kashyrin
> >> >> Sent: Tuesday, January 17, 2006 10:32 AM
> >> >> To: Bill Klein; address@hidden
> >> >> Subject: Re: [open-cobol-list] OC issues
> >> >>
> >> >>
> >> >> The issue is that level 02 is following level 05 and there
> >> >> was no 02 before.
> >> >> I'm not a Cobol guru but I expect that standard does not
> >> allow that.
> >> >> Tandem (HP Nonstop) Cobol gives an error too.
> >> >> The rest  - at least  all 390 mainframe, AS400, MFocus,
> >> >> Fujitsu are giving only warning and producing the correct code.
> >> >>
> >> >> I think if it's possible it's better to fix (at least for
> >> >> mf,ibm,mvs dialects)
> >> >>
> >> >> Regards,
> >> >> Sergey
> >> >>
> >> >> ----- Original Message ----- 
> >> >> From: "Bill Klein" <address@hidden>
> >> >> To: "'Sergey Kashyrin'" <address@hidden>;
> >> >> <address@hidden>
> >> >> Sent: Tuesday, January 17, 2006 11:03 AM
> >> >> Subject: RE: [open-cobol-list] OC issues
> >> >>
> >> >>
> >> >> >I don't understand the issue.  Is the problem that of
> >> "A-margin" vs
> >> >> > "B-margin" or what error are you getting?
> >> >> >
> >> >> > (The '85 Standard *did* have rules about replacing text
> >> >> must go in the
> >> >> > margin where replaced text was - but I thought OC had an
> >> >> option - or default
> >> >> > - to ignoring A-/B-margin issues).
> >> >> >
> >> >> > P.S.  It would NOT surprise me if this caused a problem on
> >> >> IBM mainframes.
> >> >> > Are you using one of those dialects?
> >> >> >
> >> >> >> -----Original Message-----
> >> >> >> From: address@hidden
> >> >> >> [mailto:address@hidden On
> >> >> >> Behalf Of Sergey Kashyrin
> >> >> >> Sent: Monday, January 16, 2006 11:27 PM
> >> >> >> To: address@hidden
> >> >> >> Subject: [open-cobol-list] OC issues
> >> >> >>
> >> >> >> Hi everybody,
> >> >> >>
> >> >> >> Currenltly I'm trying to make a small project (8M+ lines) to
> >> >> >> work under OC (amd64) :-)))
> >> >> >> Small annoying issues (currently just one but I expect more
> >> >> >> to follow) :
> >> >> >>
> >> >> >> The situation is that the very old dog has that construction:
> >> >> >> 01 XXX.
> >> >> >>    05 AAA PIC X.
> >> >> >>    02 BBB PIC Y.
> >> >> >>
> >> >> >> Not exactly initially but as a result of playing with a
> >> >> copybook like
> >> >> >> COPY C1
> >> >> >> COPY C2 REPLACING ==01 == BY ==02 ==.
> >> >> >> when they want to combine something in a woraking area or
> >> >> >> LINKAGE section :-(
> >> >> >>
> >> >> >> As a matter of fact all Cobols that I know (but Tandem) are
> >> >> >> giving the WARINING and working fine with that.
> >> >> >>
> >> >> >> OC gives an ERROR and not producing the code.
> >> >> >>
> >> >> >> I don't have a time right now to look into that but maybe
> >> >> >> will try later (it's not that critical, not too many
> >> occurances).
> >> >> >> Overall from 2800+ programs 350 didn't compile. Will look
> >> >> >> into all remaining issues and inform.
> >> >> >>
> >> >> >> Regards,
> >> >> >> Sergey
> 
>