Home > Archive > Cobol > August 2005 > Supress Option List
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
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?
| |
| William M. Klein 2005-08-22, 6:55 pm |
| 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:
http://publibz.boulder.ibm.com/cgi-...0/APPENDIX1.5.5
for information on PRTEXIT
http://publibz.boulder.ibm.com/cgi-...0/APPENDIX1.5.9
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?
>
| |
| Colin Campbell 2005-08-23, 3:55 am |
| 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.
| |
| William M. Klein 2005-08-23, 6:55 pm |
| 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 to
ever report a "problem" they will want to KNOW what options are in effect and
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? Do
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. 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.
| |
|
| 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.
| |
| William M. Klein 2005-08-23, 6:55 pm |
| 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).
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 compilers
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 the
same as OS/VS COBOL V1 - but OS/VS COBOL V2 included LANGLVL(1) - 68 Standard
and LANGLVL(2) - 74 Standard - support).
P.S. I wasn't offended by your question, I was just trying to figure out WHY
you wanted this ... and depending upon your answer, thought I might have some
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 lots
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.
>
| |
| Colin Campbell 2005-08-23, 9:55 pm |
| 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.
| |
| Rick Smith 2005-08-24, 3:55 am |
|
"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.
| |
| William M. Klein 2005-08-24, 3:55 am |
| "IKFCBL00" was certainly what one "executed" for OS/VS COBOL (and I think for
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.
>
>
>
| |
| Pete Dashwood 2005-08-24, 7:55 am |
|
I remember the unbundling furore and I worked with IBM COBOL before it
happened. Unfortunately, I don't directly recall if it was COBOL(F),
although I have certainly heard the term used for one of the early COBOL
compilers. I remember the first ANSI COBOL compiler replacing what we were
then using, (it might have been COBOL(F) but I can't be sure) and I remember
discussing new features in the ANSI version with people at IBM in Auckland.
Here's what I remember on IBM COBOL Compilers:
(It is a long time ago and I was working on different platforms, so I could
be in error, but this is my recollection).
1. The first one I used was COBOL 59 and it was running on a 360-30 under
TOS which replaced a 1401 in (or around) 1967.
2. The compiler was upgraded sometime a few years later around the time of
unbundling.
3. Everyone got very excited about COBOL 74 which I think was the first ANSI
release (?).
4. Somewhere in there, disks became available and the OS became DOS, then
later, DOS/VS. I have a feeling this also coincided with a new compiler
release but I can't be certain.
Pete.
TOP POST nothing new below.
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:PQUOe.120084$576.107641@fe02.news.easynews.com...
>
> "IKFCBL00" was certainly what one "executed" for OS/VS COBOL (and I think
> for 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...
>
>
>
| |
| Colin Campbell 2005-08-24, 6:55 pm |
| Pete,
This is my memory / knowledge on the subject of IBM COBOL compilers:
I started to work for Hughes Aircraft Co. in October, 1966. I was hired
as an operator. After some months, I transferred to a programming
group. This group had just begun to work on the IBM 360, perhaps a
model 40 or 50. They didn't have anyone to train folks, so I was handed
over to a "scientific" guy. He made sure I knew ForTran, then with
another new hire, we started on the IBM. The "scientific" guy would
learn something, then teach us. We learned Assembler, the Linkage
Editor, and JCL. The "scientific" guy turned us over to our
supervisors, saying we were trained.
Well, of course, the first thing I learned was that all our programs
were written in COBOL, so I had to learn that on my own. The compiler I
used was COBOL(F), although I also worked with COBOL, ForTran, and
assembler on the GE-635, which was brought in to replace the IBM 7094.
That went on for about two years. In about 1970, there was a
consolidation of programming groups at Hughes, and I moved to another site.
Just at that time, ANS COBOL V2 came in, and I started to use that. The
other programmers weren't aware of it yet, so suddenly, I became the
trainer. Just as we got somewhat comfortable with ANS COBOL V2, in came
V4. The name of these compiler signified that they were the first
compilers IBM offered that conformed to the 1968 ANSI COBOL Standard.
The second ANSI COBOL Standard was adopted in 1974, and led to the
release of OS/VS COBOL. As Bill said, it offered 1968 and 1974 COBOL
language support. In our shop(s), both LANGLVL(1) and (2) were used,
right up until we forced everyone to adopt a new, supported compiler
right around Y2K time.
Between the mid-1970's and Y2K, IBM released multiple versions of OS/VS
COBOL, then started with VS COBOL II. This was again a sort of "any
type of COBOL you want" compiler, with support for 1974 and 1985 ANSI
COBOL, and maybe even extensions allowing some 1968 syntax. VS COBOL II
was pretty much a "new" compiler, not based on the technology of the
earlier compilers. The basic code of VS COBOL II, as I understand it,
continues today, through the COBOL/370, COBOL for MVS & VM, COBOL for
OS/390 & VM, and COBOL for z/OS & OS/390 offerings.
Our shop(s) pretty much became consolidated down to two development
environments (from at one time, as many as eleven or maybe more), and
the one in California moved everyone onto the latest COBOL, and kept
moving forward as compilers were released, and the operating system was
updated.
I spent time in the late 1970's until the mid-1980's working with the
man who had been the project leader for COBOL(F) at IBM. (We wrote
COBOL compilers for a number of mini- and micro-computer companies,
including MicroSoft.) The story I was told was that IBM had started
three COBOL projects when S/360 came out - COBOL(D) for DOS, COBOL(E)
for MFT, and COBOL(F) for MVT. My man was first to deliver by a good
amount of time, and the three compilers were rather different in design
and performance.
I believe that the COBOL(F) code was the base used for the ANS COBOL and
OS/VS COBOL compilers, but I am not positive of that. Tom Ross of IBM
might know, but he's too young to have been there, I think.
Colin Campbell
=====
Pete Dashwood wrote:
[color=darkred]
>
>I remember the unbundling furore and I worked with IBM COBOL before it
>happened. Unfortunately, I don't directly recall if it was COBOL(F),
>although I have certainly heard the term used for one of the early COBOL
>compilers. I remember the first ANSI COBOL compiler replacing what we were
>then using, (it might have been COBOL(F) but I can't be sure) and I remember
>discussing new features in the ANSI version with people at IBM in Auckland.
>Here's what I remember on IBM COBOL Compilers:
>(It is a long time ago and I was working on different platforms, so I could
>be in error, but this is my recollection).
>
>1. The first one I used was COBOL 59 and it was running on a 360-30 under
>TOS which replaced a 1401 in (or around) 1967.
>2. The compiler was upgraded sometime a few years later around the time of
>unbundling.
>3. Everyone got very excited about COBOL 74 which I think was the first ANSI
>release (?).
>4. Somewhere in there, disks became available and the OS became DOS, then
>later, DOS/VS. I have a feeling this also coincided with a new compiler
>release but I can't be certain.
>
>Pete.
>
>TOP POST nothing new below.
>
>"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
>news:PQUOe.120084$576.107641@fe02.news.easynews.com...
>
>
| |
| Pete Dashwood 2005-08-24, 6:55 pm |
|
Thanks for that, Colin.
It was interesting and jogged my memory on a few things.
When I think about those days now, it is like another lifetime... :-)
Pete.
TOP POST nothing new below.
"Colin Campbell" <cmcampb@adelphia.net> wrote in message
news:2_2dnWbl7o-TfZHeRVn-1w@adelphia.com...
> Pete,
> This is my memory / knowledge on the subject of IBM COBOL compilers:
> I started to work for Hughes Aircraft Co. in October, 1966. I was hired
> as an operator. After some months, I transferred to a programming group.
> This group had just begun to work on the IBM 360, perhaps a model 40 or
> 50. They didn't have anyone to train folks, so I was handed over to a
> "scientific" guy. He made sure I knew ForTran, then with another new
> hire, we started on the IBM. The "scientific" guy would learn something,
> then teach us. We learned Assembler, the Linkage Editor, and JCL. The
> "scientific" guy turned us over to our supervisors, saying we were
> trained.
>
> Well, of course, the first thing I learned was that all our programs were
> written in COBOL, so I had to learn that on my own. The compiler I used
> was COBOL(F), although I also worked with COBOL, ForTran, and assembler on
> the GE-635, which was brought in to replace the IBM 7094. That went on
> for about two years. In about 1970, there was a consolidation of
> programming groups at Hughes, and I moved to another site.
>
> Just at that time, ANS COBOL V2 came in, and I started to use that. The
> other programmers weren't aware of it yet, so suddenly, I became the
> trainer. Just as we got somewhat comfortable with ANS COBOL V2, in came
> V4. The name of these compiler signified that they were the first
> compilers IBM offered that conformed to the 1968 ANSI COBOL Standard.
>
> The second ANSI COBOL Standard was adopted in 1974, and led to the release
> of OS/VS COBOL. As Bill said, it offered 1968 and 1974 COBOL language
> support. In our shop(s), both LANGLVL(1) and (2) were used, right up
> until we forced everyone to adopt a new, supported compiler right around
> Y2K time.
>
> Between the mid-1970's and Y2K, IBM released multiple versions of OS/VS
> COBOL, then started with VS COBOL II. This was again a sort of "any type
> of COBOL you want" compiler, with support for 1974 and 1985 ANSI COBOL,
> and maybe even extensions allowing some 1968 syntax. VS COBOL II was
> pretty much a "new" compiler, not based on the technology of the earlier
> compilers. The basic code of VS COBOL II, as I understand it, continues
> today, through the COBOL/370, COBOL for MVS & VM, COBOL for OS/390 & VM,
> and COBOL for z/OS & OS/390 offerings.
>
> Our shop(s) pretty much became consolidated down to two development
> environments (from at one time, as many as eleven or maybe more), and the
> one in California moved everyone onto the latest COBOL, and kept moving
> forward as compilers were released, and the operating system was updated.
>
> I spent time in the late 1970's until the mid-1980's working with the man
> who had been the project leader for COBOL(F) at IBM. (We wrote COBOL
> compilers for a number of mini- and micro-computer companies, including
> MicroSoft.) The story I was told was that IBM had started three COBOL
> projects when S/360 came out - COBOL(D) for DOS, COBOL(E) for MFT, and
> COBOL(F) for MVT. My man was first to deliver by a good amount of time,
> and the three compilers were rather different in design and performance.
>
> I believe that the COBOL(F) code was the base used for the ANS COBOL and
> OS/VS COBOL compilers, but I am not positive of that. Tom Ross of IBM
> might know, but he's too young to have been there, I think.
> Colin Campbell
> =====
> Pete Dashwood wrote:
>
>
| |
| Clark Morris 2005-08-25, 7:56 am |
| On Wed, 24 Aug 2005 06:54:39 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:
>"IKFCBL00" was certainly what one "executed" for OS/VS COBOL (and I think for
>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.
COBOL F was definitely bundled. I think that I was still stuck on
COBOL D for DOS (real not VS) until 1975 or so.
| |
| Frank Swarbrick 2005-08-26, 6:55 pm |
| For whatever it's worth, IBM DOS/VS COBOL REL 3.1 is executed via "EXEC
FCOBOL". This is, of course, for VSE (previously DOS/VSE), not for MVS and
its descendants.
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:6xOOe.105532$576.81016@fe02.news.easynews.com...[color=darkred]
> 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.
|
|
|
|
|