× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: ILE COBOL - What happend to '*NOSTDERR'??
  • From: Jon.Paris@xxxxxx
  • Date: Fri, 9 Jun 2000 16:10:52 -0400



 >> What is the equivalent to this when you compile programs of type CBLLE?

There is no equivalent.  To understand why you have to understand why *NOSTDERR
was there in the first place.

Some time during the life of COBOL/400 (can't recall exactly when) a number of
customers reported major inconsistencies in COBOL error handling particularly in
situation where one file had a file status defined but another did not.  On
investigation it was found that these inconsistencies could not be resolved (or
even adequately documented) since the combination of circumstances that caused
them were next to impossible to determine. The only way to fix them was to
introduce a completely new method of consistently handling COBOL's hierarchy or
error handling.  The result was known as Standard Error Handling.  Since this
would cause existing programs to change behaviour, it was decided that an option
had to be created that would allow existing programs to compile and to operate
as they had.  That option was *NOSTDERR.

OK - so now comes the new ILE compiler.  One of the design points was that as
far as possible the new one should be fully compatible with the old.  If it
could not be made compatible either the option had to be dropped or the compiler
had to reject the code as invalid.  The code that caused the original problems
was completely legal COBOL syntax so the "invalid" option was out.  Nor could
the compiler behave as the old one had done since a) the conditions under which
the old behaviour was generated were as close to unpredictable as you can get
and b) the new compiler was based on a completely different internal
architecture so that even if the conditions had been readily predictable,
duplication of the results would have been very iffy.  So, reluctantly the
decision was made to drop the option.

You may not like the answer, but I hope you'll understand why things happened
the way they did.


+---
| This is the COBOL/400 Mailing List!
| To submit a new message, send your mail to COBOL400-L@midrange.com.
| To subscribe to this list send email to COBOL400-L-SUB@midrange.com.
| To unsubscribe from this list send email to COBOL400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---END



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.