Supress Option List

IGYCRCTL lists all the options in effect for compile. For us, this list
will never change. Is there a way to suppress this option listing so
the resulting source listing begins with the IDENTIFICATION DIVISION?

Certainly not any easy way (that I am aware of).  HOWEVER, it would be
"medium-easy" to create a PRTEXIT routine of your own to do this.

See:
[url]http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG30/APPENDIX1.5.5[
/url]

for information on PRTEXIT

[url]http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg30/APPENDIX1.5.9[
/url]

includes an example of an INEXIT routine, that I *think* you could modify to
 do
what you want.


--
Bill Klein
wmklein <at> ix.netcom.com
"bfwd" <bforward@texarkanacollege.edu> wrote in message
news:1124743391.914029.85230@g47g2000cwa.googlegroups.com...
> IGYCRCTL lists all the options in effect for compile. For us, this list
> will never change. Is there a way to suppress this option listing so
> the resulting source listing begins with the IDENTIFICATION DIVISION?
>

bfwd wrote:

>IGYCRCTL lists all the options in effect for compile. For us, this list
>will never change. Is there a way to suppress this option listing so
>the resulting source listing begins with the IDENTIFICATION DIVISION?
>
>
>
I assume you are referring to IBM mainframe COBOL, such as COBOL for
z/OS and OS/390.

It seems pretty unlikely that the option list would NEVER change.

Doesn't anyone in your shop compile for testing, as opposed to production?

Will you never need to see the generated code for a program (LIST vs.
OFFSET)?

Will you always (or never) compile programs for 31-bit mode execution
and shared use under IMS or CICS?

Will there never be a time when you want to use either the CICS or SQL
pre-processor/compiler?

Will you never write any international applications (which might use
different currency symbols)?

Do you always (or never) use extended arithmetic?

Will you never need to check that a program meets the applicable COBOL
standard?

Is there no chance that you would ever want to switch between ANSI and
Lillian date formats?

I could go on....

I hope you have made sure that the options such as BUFSIZE, COMPILE,
NUMPROC, OPTIMIZE, TEST, and the like have been optimized to provide the
best compiler and run unit performance, and the most useful output in
case of an abnormal termination.

Bill Klein's response that you could write a PRTEXIT routine to control
what parts of the listing actually get printed is true; of course, that
would change the option list when it is in use.

Another simple option is to write the listing to a temporary data set,
and write a simple program to read that, and omit the portions of the
listing you don't want to see.

If you use a tool such as CA-Endevor to install your application
programs, it is likely that you'll have different compiles for batch
programs, IMS transactions, CICS transactions, 31-bit programs, etc,
with different options.  Having the options listed would be one way to
check that a program was compiled the right way.

Perhaps we will just stick with FCOBOL.

I agree with Colin, that actually having "non-changing" compiler options
PROBABLY means that your shop has other (serious?) problems.  In addition to
what he mentions, I would ask what 3rd party products you use for COBOL
development?   Some require NOOPT (which I certainly HOPE you don't use in
production).  Same for TEST/NOTEST.

I *can* imagine (but not recommend) a shop that doesn't want application
programmers to SEE what options are in effect.  OTOH, if you work with IBM t
o
ever report a "problem" they will want to KNOW what options are in effect an
d
will (in some cases) ask you to run with different options.

Can you tell us WHY the "lengthy" list of options in effect is a problem?  D
o
programmers have problems "scrolling" to the identification division when
viewing output?  Do you use the FLAG(I,I) (now the default - but previously 
not)
option to see compiler messages by source code causing the problem?  Is the
problem, that every listing (in hard-copy) is ONE page longer?

Again, simply WHY do you want this "feature"?

--
Bill Klein
wmklein <at> ix.netcom.com
"Colin Campbell" <cmcampb@adelphia.net> wrote in message
news:fcCdnRDnC8AiJpfeRVn-hQ@adelphia.com...
> bfwd wrote:
> 
> I assume you are referring to IBM mainframe COBOL, such as COBOL for z/OS 
and
> OS/390.
>
> It seems pretty unlikely that the option list would NEVER change.
> Doesn't anyone in your shop compile for testing, as opposed to production?
> Will you never need to see the generated code for a program (LIST vs. OFFS
ET)?
>
> Will you always (or never) compile programs for 31-bit mode execution and
> shared use under IMS or CICS?
>
> Will there never be a time when you want to use either the CICS or SQL
> pre-processor/compiler?
> Will you never write any international applications (which might use diffe
rent
> currency symbols)?
> Do you always (or never) use extended arithmetic?
> Will you never need to check that a program meets the applicable COBOL
> standard?
> Is there no chance that you would ever want to switch between ANSI and Lil
lian
> date formats?
>
> I could go on....
>
> I hope you have made sure that the options such as BUFSIZE, COMPILE, NUMPR
OC,
> OPTIMIZE, TEST, and the like have been optimized to provide the best compi
ler
> and run unit performance, and the most useful output in case of an abnorma
l
> termination.
>
> Bill Klein's response that you could write a PRTEXIT routine to control wh
at
> parts of the listing actually get printed is true; of course, that would
> change the option list when it is in use.
>
> Another simple option is to write the listing to a temporary data set, and
> write a simple program to read that, and omit the portions of the listing 
you
> don't want to see.
>
> If you use a tool such as CA-Endevor to install your application programs,
 it
> is likely that you'll have different compiles for batch programs, IMS
> transactions, CICS transactions, 31-bit programs, etc, with different opti
ons.
> Having the options listed would be one way to check that a program was
> compiled the right way.

Again, simply WHY do you want this "feature"?

Didn't mean to offend--I'm just curious to see if anyone has tried to
suppress that part of the listing.  We've been using FCOBOL for years
and just now got this newer compiler--really haven't started using it a
whole lot. We don't use a lot of IBM or 3rd party software--don't even
use CICS or VSAM.  We just don't get too stressed out about
programming--if we don't program it today then we'll do it tomorrow.
Around here, we have more time than money, so when we find something
that works well, we don't keep changing it.

Do you SERIOUSLY mean the IBM "COBOL-F" version (that pre-dated their ANS CO
BOL
product that predated their OS/VS COBOL), i.e. the compiler that (sort-of) m
eet
the '68 Standard, but didn't even include support for the '74 Standard.
????

Someone else may actually have a better view of exactly when/what "COBOL-F"
(from IBM) was.  I didn't start using COBOL(IBM COBOL) until OS/VS COBOL was
available, in 1978 (or so - as I recall).

I think, but won't swear to it, that the TSO COBOL prompter was actually
compatible with COBOL-F.

When I worked with/for 3rd party vendors the EARLIEST version of IBM's compi
lers
that I knew of any "active" use of (and this was in the late '80's) was ANS
COBOL V2.  (That was pretty rare, but ANS COBOL V4 which was SUBSTANTIALLY t
he
same as OS/VS COBOL V1 - but OS/VS COBOL V2 included LANGLVL(1) - 68 Standar
d
and LANGLVL(2) - 74 Standard - support).

P.S.  I wasn't offended by your question, I was just trying to figure out WH
Y
you wanted this ... and depending upon your answer, thought I might have som
e
other suggestions.

P.P.S.  If you are doing a conversion from any pre-VS COBOL II compiler to a
"currently supported" (i.e. Enterprise COBOL) compiler, then you will have l
ots
AND LOTS of problems much more difficult that listing formats ... IMHO.

--
Bill Klein
wmklein <at> ix.netcom.com
"bfwd" <bforward@texarkanacollege.edu> wrote in message
news:1124830291.305600.236300@f14g2000cwb.googlegroups.com...
> Again, simply WHY do you want this "feature"?
>
> Didn't mean to offend--I'm just curious to see if anyone has tried to
> suppress that part of the listing.  We've been using FCOBOL for years
> and just now got this newer compiler--really haven't started using it a
> whole lot. We don't use a lot of IBM or 3rd party software--don't even
> use CICS or VSAM.  We just don't get too stressed out about
> programming--if we don't program it today then we'll do it tomorrow.
> Around here, we have more time than money, so when we find something
> that works well, we don't keep changing it.
>

bfwd wrote:

>Perhaps we will just stick with FCOBOL.
>
>
>
All I can add to what Bill has said, is "Day-um"!

I'm a native Texan, and to hear that an educational institution in Texas
may be using the COBOL(F) compiler is like getting hit with a stun gun.
Isn't there a "No College Left Behind" program you need to comply with?
If that is really and truly the compiler you're using, I'd love to hear
your Y2K remediation stories!  That sucker is over 40 years old, and has
been superceded by perhaps 20 or more later releases.  IBM support ended
over 30 years ago, I'm sure.

I'm almost afraid to ask, but what operating system is being used, on
what hardware?  (Actually, if you have a new compiler, your shop has to
be fairly current in operating system version, or you couldn't run it.)

By the way, I happen to have worked with the project leader whose team
created COBOL(F) at IBM around 1964.

I would encourage you and your fellow programmers to embrace the new
technology (be forward, if you will, making a play on your e-mail name),
and learn how to write much improved application programs.  Some of the
options I mentioned in my earlier reply provide you with the capability
to do things that "old COBOL" never dreamed of.

Converting existing programs won't be that easy, but will be possible.
I wouldn't be surprised if you were able to reduce the cost of running
many of your ancient apps.

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:6xOOe.105532$576.81016@fe02.news.easynews.com...
> Do you SERIOUSLY mean the IBM "COBOL-F" version (that pre-dated their ANS
COBOL
> product that predated their OS/VS COBOL), i.e. the compiler that (sort-of)
meet
> the '68 Standard, but didn't even include support for the '74 Standard.
>   ????
>
> Someone else may actually have a better view of exactly when/what
"COBOL-F"
> (from IBM) was.  I didn't start using COBOL(IBM COBOL) until OS/VS COBOL
was
> available, in 1978 (or so - as I recall).

Bill, I think COBOL F was the same as ANS COBOL.
The manual I have, GC28-6396-5, IBM OS Full American
National Standard COBOL, shows, in the JCL for a sample
program, "EXEC PGM=IKFCBL00". This manual also has
the documentation for the first release of OS/VS COBOL
and the publication date on the amendment is May 15, 1974.
Only the standards X3.23-1968 and ISO/R 1989-1972 are
mentioned for both.

While I said "I think", above, I never used the OS compiler
at the college; but I do have a source listing produced by a
DOS compiler I used at work. The title on the output is IBM
DOS AMERICAN NATIONAL STANDARD COBOL
with the additional text CBF CL3-6, which I take to mean
COBOL F or ANS COBOL Version 3.

"IKFCBL00" was certainly what one "executed" for OS/VS COBOL (and I think fo
r
ANS COBOL Vx).  However, COBOL(F) was a specific release (version) - very
early - of IBM's COBOL.  It was (as I recall) one of the early "bundled in"
software products that caused the original "IBM decree" starting "unbundling
" of
software from O/S (and hardware).  Again, this was all before my time, so I
could be mistaken on all/some of it.

--
Bill Klein
wmklein <at> ix.netcom.com
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:11gnpfvpmma64fe@corp.supernews.com...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:6xOOe.105532$576.81016@fe02.news.easynews.com... 
> COBOL 
> meet 
> "COBOL-F" 
> was 
>
> Bill, I think COBOL F was the same as ANS COBOL.
> The manual I have, GC28-6396-5, IBM OS Full American
> National Standard COBOL, shows, in the JCL for a sample
> program, "EXEC PGM=IKFCBL00". This manual also has
> the documentation for the first release of OS/VS COBOL
> and the publication date on the amendment is May 15, 1974.
> Only the standards X3.23-1968 and ISO/R 1989-1972 are
> mentioned for both.
>
> While I said "I think", above, I never used the OS compiler
> at the college; but I do have a source listing produced by a
> DOS compiler I used at work. The title on the output is IBM
> DOS AMERICAN NATIONAL STANDARD COBOL
> with the additional text CBF CL3-6, which I take to mean
> COBOL F or ANS COBOL Version 3.
>
>
>