Shmuel,
Experience is the teacher. My problem is that a lot of folks with the
experience will be retiring, hence a lot of experience and insight goes
away..fwiw
Scott ford
www.identityforge.com
On Jun 22, 2012, at 10:02 AM, "Shmuel Metz (Seymour J.)"
wrote:
> In , on 06/21/2012
> at 01:51
In , on 06/21/2012
at 01:51 AM, Tom Ross said:
>We are working on adding help for messages where help is not
>available elsewhere, but including syntax descriptions and
>diagrams to a message manual to explain a COBOL syntax error
>would mean duplicating what is in the Language Reference Man
On Thu, 21 Jun 2012 01:51:21 -0700, Tom Ross wrote:
>
>For compiler messages all you need is the line of source gettin flagged, a
>description of what is wrong (the messae) and the Language Reference Manual.
>
Amen. Mostly. It would be further helpful if the message text
identified the specific
>>The issue of COBOL compiler messages was discussed here, and most
>>agreed it would not be that helpful, since it would mostly say
>>'please see the COBOL Language Reference Manual'.
>
>Those calling for a messages manual were asking IBM for a real manual,
>not for IBM to just go through the moti
In , on 06/17/2012
at 12:06 AM, Tom Ross said:
>The issue of COBOL compiler messages was discussed here, and most
>agreed it would not be that helpful, since it would mostly say
>'please see the COBOL Language Reference Manual'.
Those calling for a messages manual were asking IBM for a real m
On Sat, Jun 16, 2012 at 9:30 AM, Scott Ford wrote:
> Ed,
>
> We have our STCs written in COBOL calling assembler sub routines, which
> works great.
> We are a tcpip socket server and client ...the client is like a hybrid
> app. The point is the only drawback I see to using COBOL, is the ability t
Scott:
I do not know if your STC's are production or not. I would hope
changes go through change control.
I also do not know how you manage change when a OS demands that the
program goes though the update process. Generally I am for COBOL
(whatever works for you). What I am finding is that
On Jun 17, 2012, at 2:06 AM, Tom Ross wrote:
I know there is no reaching cranky Ed, but for others I can help:
The only reason I am cranky is I have been on the receiving end of
*SO* many irate calls to the systems group complaining about the bad
manuals. AFter 50 you give up.
Somewhere a
I know there is no reaching cranky Ed, but for others I can help:
>Somewhere around the mid 1990's IBM seem to have done a reverse and
>either stop issuing manuals (eg COBOL MESSAGES AND CODES) or made
The issue of COBOL compiler messages was discussed here, and most agreed
it would not be that h
Ed,
We have our STCs written in COBOL calling assembler sub routines, which works
great.
We are a tcpip socket server and client ...the client is like a hybrid app. The
point is the only drawback I see to using COBOL, is the ability to multi- task
or thread, I know COBOL can, but haven't seen s
On Fri, 2012-06-15 at 16:22 -0400, Ed Gould wrote:
> Manual reading has always been an issue. For year we have been asking
> IBM to write clear and useful manuals.
> Somewhere around the mid 1990's IBM seem to have done a reverse and
> either stop issuing manuals (eg COBOL MESSAGES AND CODES) o
Scott:
Manual reading has always been an issue. For year we have been asking
IBM to write clear and useful manuals.
Somewhere around the mid 1990's IBM seem to have done a reverse and
either stop issuing manuals (eg COBOL MESSAGES AND CODES) or made
them so complicated to read (COBOL conver
12 matches
Mail list logo
