Re: Converting assembler to COBOL help

[Mitch Mccluhan]

 Hello,
There is a vendor BP that does this sort of thing with an automated tool.
Mitch

  
 
 
 
-Original Message-
From: W Mainframe <01304632a58d-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Sat, Jul 9, 2022 9:23 am
Subject: Re: Converting assembler to COBOL help

Hi,A suggestion... I did similar thing some years ago using z390 Macro 
Language. In summary you can create macros and replace used macros by Cobol 
statements.The macros just punch Cobol statements to an output.I converted 
about 250 critical Cobol code.Main question... Is it 100%, of course not... But 
I would say 75%.
RegardsDan


Sent from Yahoo Mail for iPhone


On Friday, July 8, 2022, 8:53 PM, Paul Gilmartin 
<042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

On Fri, 8 Jul 2022 22:51:38 +, Farley, Peter x23353 wrote:
>
>    ...  The business logic was totally scrambled, sometimes by "old-timer" 
>tricks like non-reentrant branch gates and other such no-no's under current 
>maintainability and pipeline-flush avoidance rules, other times just by 
>flagrantly awful spaghetti code even a human would struggle to understand.
> 
Was that merely faithfully replicating deficiencies in the input?

What architecture level?

What might it do with such as RISBG?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Converting assembler to COBOL help

[Seymour J Metz]

Run some hairy test cases and evaluate the outputs for, e.g., completeness, 
effort for manual recodeing of anything not automatically converted, 
efficiency, readability, maintainability. It's a lot harder to do it well than 
to just do it. Using a program that only translates 75% of a module might 
require more manpower than translating the whole thing manually.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom 
Ross [tmr...@stlvm20.vnet.ibm.com]
Sent: Friday, July 8, 2022 6:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Converting assembler to COBOL help

Greetings mainframers!

This has porobbaly been asked and answered, but are there tools or companies
that can convert or help to rewrite assembler applications or just programs
into COBOL?  Any suggestions?


Cheers,
TomR  >> COBOL is the Language of the Future! <<
AKA:  Captain COBOL, Tom Ross

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Converting assembler to COBOL help

[Seymour J Metz]

Automatic conversion of assembler code has been around for decades. And, yes, 
it is a bear for complicated architectures and a lot of work even for simple 
machines. BTDT,GTA.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Farley, Peter x23353 [031df298a9da-dmarc-requ...@listserv.ua.edu]
Sent: Saturday, July 9, 2022 2:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Converting assembler to COBOL help

That's a reasonable suggestion.  Many pitfalls to watch out for (like the 
branch gates example I gave earlier), but like you said, possibly 75% coverage 
for the code portion.  System macro conversion could be a big headache too, but 
at least feasible to try.

Trickier could be conversion of the DSECT and non-reentrant variable storage 
area definitions.  I would expect much of that to need careful human review and 
manual adjustment.

Unlike HLL's, assembler allows many hardware-specific "tricks" that make 
automated analysis, like classical compiler construction to generate "parse 
trees" and "directed graphs" and such, much more difficult.  It may be possible 
to do, but the work involved to create and validate such a beast would be 
massive.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of W 
Mainframe
Sent: Saturday, July 9, 2022 10:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Converting assembler to COBOL help

Hi,A suggestion... I did similar thing some years ago using z390 Macro 
Language. In summary you can create macros and replace used macros by Cobol 
statements.The macros just punch Cobol statements to an output.I converted 
about 250 critical Cobol code.Main question... Is it 100%, of course not... But 
I would say 75%.
RegardsDan


Sent from Yahoo Mail for iPhone


On Friday, July 8, 2022, 8:53 PM, Paul Gilmartin 
<042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

On Fri, 8 Jul 2022 22:51:38 +, Farley, Peter x23353 wrote:
>
>    ...  The business logic was totally scrambled, sometimes by "old-timer" 
>tricks like non-reentrant branch gates and other such no-no's under current 
>maintainability and pipeline-flush avoidance rules, other times just by 
>flagrantly awful spaghetti code even a human would struggle to understand.
>
Was that merely faithfully replicating deficiencies in the input?

What architecture level?

What might it do with such as RISBG?

--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Converting assembler to COBOL help

[Farley, Peter x23353]

Apologies, you are probably correct.  Bad habits acquired dealing with 
management who don’t like that method.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Saturday, July 9, 2022 2:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Converting assembler to COBOL help

On Sat, 9 Jul 2022 18:10:54 +, Farley, Peter x23353 wrote:

>Answers in the order of your questions:
>
Wouldn't it be more legible to interleave your answers rather than "in the 
order of ..."?



--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Converting assembler to COBOL help

[Farley, Peter x23353]

That's a reasonable suggestion.  Many pitfalls to watch out for (like the 
branch gates example I gave earlier), but like you said, possibly 75% coverage 
for the code portion.  System macro conversion could be a big headache too, but 
at least feasible to try.

Trickier could be conversion of the DSECT and non-reentrant variable storage 
area definitions.  I would expect much of that to need careful human review and 
manual adjustment.

Unlike HLL's, assembler allows many hardware-specific "tricks" that make 
automated analysis, like classical compiler construction to generate "parse 
trees" and "directed graphs" and such, much more difficult.  It may be possible 
to do, but the work involved to create and validate such a beast would be 
massive.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of W 
Mainframe
Sent: Saturday, July 9, 2022 10:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Converting assembler to COBOL help

Hi,A suggestion... I did similar thing some years ago using z390 Macro 
Language. In summary you can create macros and replace used macros by Cobol 
statements.The macros just punch Cobol statements to an output.I converted 
about 250 critical Cobol code.Main question... Is it 100%, of course not... But 
I would say 75%.
RegardsDan


Sent from Yahoo Mail for iPhone


On Friday, July 8, 2022, 8:53 PM, Paul Gilmartin 
<042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

On Fri, 8 Jul 2022 22:51:38 +, Farley, Peter x23353 wrote:
>
>    ...  The business logic was totally scrambled, sometimes by "old-timer" 
>tricks like non-reentrant branch gates and other such no-no's under current 
>maintainability and pipeline-flush avoidance rules, other times just by 
>flagrantly awful spaghetti code even a human would struggle to understand.
> 
Was that merely faithfully replicating deficiencies in the input?

What architecture level?

What might it do with such as RISBG?

-- 


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Converting assembler to COBOL help

[Paul Gilmartin]

On Sat, 9 Jul 2022 18:10:54 +, Farley, Peter x23353 wrote:

>Answers in the order of your questions:
>
Wouldn't it be more legible to interleave your answers rather
than "in the order of ..."?



-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Converting assembler to COBOL help

[Farley, Peter x23353]

Answers in the order of your questions:

In most cases, yes, but the COBOL implementation chosen was MUCH worse than the 
original, far less readable or maintainable, and in many cases unnecessarily 
more complicated.

The converted assembler code was decades old, all pre-2000, so ESA at best, and 
most probably at XA level or earlier.

Nothing of the "newer" instruction sets (FSVO "new") was present in any of the 
converted assembler source that I was asked to review.  In all the cases that I 
reviewed, the code being converted could have run on the earliest 370 hardware 
and in some cases on 360 hardware.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Friday, July 8, 2022 7:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Converting assembler to COBOL help

On Fri, 8 Jul 2022 22:51:38 +, Farley, Peter x23353 wrote:
>
>...  The business logic was totally scrambled, sometimes by "old-timer" 
> tricks like non-reentrant branch gates and other such no-no's under current 
> maintainability and pipeline-flush avoidance rules, other times just by 
> flagrantly awful spaghetti code even a human would struggle to understand.
> 
Was that merely faithfully replicating deficiencies in the input?

What architecture level?

What might it do with such as RISBG?

-- 

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Converting assembler to COBOL help

[W Mainframe]

Hi,A suggestion... I did similar thing some years ago using z390 Macro 
Language. In summary you can create macros and replace used macros by Cobol 
statements.The macros just punch Cobol statements to an output.I converted 
about 250 critical Cobol code.Main question... Is it 100%, of course not... But 
I would say 75%.
RegardsDan


Sent from Yahoo Mail for iPhone


On Friday, July 8, 2022, 8:53 PM, Paul Gilmartin 
<042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

On Fri, 8 Jul 2022 22:51:38 +, Farley, Peter x23353 wrote:
>
>    ...  The business logic was totally scrambled, sometimes by "old-timer" 
>tricks like non-reentrant branch gates and other such no-no's under current 
>maintainability and pipeline-flush avoidance rules, other times just by 
>flagrantly awful spaghetti code even a human would struggle to understand.
> 
Was that merely faithfully replicating deficiencies in the input?

What architecture level?

What might it do with such as RISBG?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Converting assembler to COBOL help

[Paul Gilmartin]

On Fri, 8 Jul 2022 22:51:38 +, Farley, Peter x23353 wrote:
>
>...  The business logic was totally scrambled, sometimes by "old-timer" 
> tricks like non-reentrant branch gates and other such no-no's under current 
> maintainability and pipeline-flush avoidance rules, other times just by 
> flagrantly awful spaghetti code even a human would struggle to understand.
> 
Was that merely faithfully replicating deficiencies in the input?

What architecture level?

What might it do with such as RISBG?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Converting assembler to COBOL help

[Farley, Peter x23353]

Tom,

I don't know who the vendor actually was (it wasn't done in my application 
area), but a few years ago we tried one of them who had an automated tool of 
some kind to do that conversion, and the resulting COBOL code that I was asked 
to peer-review was unreadable and unmaintainable.  The business logic was 
totally scrambled, sometimes by "old-timer" tricks like non-reentrant branch 
gates and other such no-no's under current maintainability and pipeline-flush 
avoidance rules, other times just by flagrantly awful spaghetti code even a 
human would struggle to understand.

That project was canceled, and now we do it (when actually needed) in the 
old-fashioned way - by hand, by a senior programmer experienced in both 
languages.   Usually only when something breaks and management needs the 
business logic preserved in a more "supportable" form.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Ross
Sent: Friday, July 8, 2022 6:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Converting assembler to COBOL help

Greetings mainframers!

This has porobbaly been asked and answered, but are there tools or companies 
that can convert or help to rewrite assembler applications or just programs 
into COBOL?  Any suggestions?


Cheers,
TomR  >> COBOL is the Language of the Future! <<
AKA:  Captain COBOL, Tom Ross
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Converting assembler to COBOL help

[Joe Monk]

Why in the heck would you want to do that?

Joe

On Fri, Jul 8, 2022 at 5:32 PM Tom Ross  wrote:

> Greetings mainframers!
>
> This has porobbaly been asked and answered, but are there tools or
> companies
> that can convert or help to rewrite assembler applications or just programs
> into COBOL?  Any suggestions?
>
>
> Cheers,
> TomR  >> COBOL is the Language of the Future! <<
> AKA:  Captain COBOL, Tom Ross
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Converting assembler to COBOL help

[Tom Ross]

Greetings mainframers!

This has porobbaly been asked and answered, but are there tools or companies
that can convert or help to rewrite assembler applications or just programs
into COBOL?  Any suggestions?


Cheers,
TomR  >> COBOL is the Language of the Future! <<
AKA:  Captain COBOL, Tom Ross

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL help for NJ

[Bob Bridges]

Yeah, I may be wrong but I got the feeling the writer of that article didn't 
really know mainframes.  He probably had some old hazy opinions about 
mainframes, and he researched this article by talking to two or three Java 
programmers who'd been around z/OS a while back, and he combined the two 
sources and wrote what we saw before going back to his Real Job.

Maybe I'm doing him an injustice.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* There are two rules for ultimate success in life:
  1) Never tell everything you know.
  -Randy Keck */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Tuesday, April 7, 2020 12:58

Really?  40-year-old mainframes? That's close to impossible, and certainly
ridiculous.  I'm sure many of you remember better than me, but 1980 was the
era of needing a megawatt or so to generate 20 MIPS or something like
that.  If you could find the parts and the expertise to keep it going.

--- On Tue, Apr 7, 2020 at 11:44 AM Bob Bridges  wrote:
> In the original article (https://www.tomshardware.com/news/new-jersey-cobol-
> coders-mainframes-coronavirus) it said “The governor of New Jersey made a
> seemingly odd call for help last night: The state desperately needs COBOL
> programmers to revamp the 50-year-old software powering the 40-year-old
> mainframes behind the state's unemployment system”

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [External] Re: COBOL help for NJ

[Pommier, Rex]

Oh c'mon, Will, aren't you exaggerating just a bit?  I mean, really?  " with 
the manuals block printed on linen paper"?  They're chiseled on stone tablets!

OK, back to work...

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
William Donzelli
Sent: Tuesday, April 7, 2020 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: COBOL help for NJ

> Really?  40-year-old mainframes? That's close to impossible, and 
> certainly ridiculous.  I'm sure many of you remember better than me, 
> but 1980 was the era of needing a megawatt or so to generate 20 MIPS 
> or something like that.  If you could find the parts and the expertise to 
> keep it going.

Aren't all mainframes at least 40 years old? Hard carved out of wood with 
forged iron fittings, with the manuals block printed on linen paper??

Anyway, I always like to hear about 40 year old ancient mainframes (or even 
just peripherals) still kicking around, working or not.

--
Will

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL help for NJ

[William Donzelli]

> Really?  40-year-old mainframes? That's close to impossible, and certainly
> ridiculous.  I'm sure many of you remember better than me, but 1980 was the
> era of needing a megawatt or so to generate 20 MIPS or something like
> that.  If you could find the parts and the expertise to keep it going.

Aren't all mainframes at least 40 years old? Hard carved out of wood
with forged iron fittings, with the manuals block printed on linen
paper??

Anyway, I always like to hear about 40 year old ancient mainframes (or
even just peripherals) still kicking around, working or not.

--
Will

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL help for NJ

[Seymour J Metz]

I was impressed by the picture of a z13 in an article talking about 40 year old 
machines.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Steve Smith [sasd...@gmail.com]
Sent: Tuesday, April 7, 2020 12:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL help for NJ

Really?  40-year-old mainframes? That's close to impossible, and certainly
ridiculous.  I'm sure many of you remember better than me, but 1980 was the
era of needing a megawatt or so to generate 20 MIPS or something like
that.  If you could find the parts and the expertise to keep it going.

sas


On Tue, Apr 7, 2020 at 11:44 AM Bob Bridges  wrote:

> In the original article (
> https://secure-web.cisco.com/12_JKakBUzTAfWnVAfkM0izoXjTaKgj4xDrZKAHKxX6XAVITPysR-0E5xjOVre_LcykV3OKgLNYb99cnzBWs-mM-UbNUzT64BlWSiYJB5Pzd9Rs1ar1tz6koaSW2CZ6tLYclAFX7kV5MYXCiG_FO_FU_WpTqtmoI6nKZJRYTtAY5Vvoj-1g6HaLTGDG89VZPkfU10neGUgWuBwW4jO4inP4UouOawchOpnkZjxuwJAOdOUnO307w7OP62qzQnDIGH0sfrpyp6F5BcBT9rc8AaJS3NpTxXXn0K90qCXKgc1aqhPt69-GJtHI5c4S2SB528_3lAZf6PiUIR0kIA5KLHkTqBZo4ks-fF4BZ45Sz9Ic80HgCB5t_nyct9wsh7igEyaNVGwgFmwkuWBebNeCHhyV1wBVyRqWM7Qt5ndvF4Duufq-NCXdAbq9o_TP5u7FYfxRjWxYC0xqWAvcUgr83BdA/https%3A%2F%2Fwww.tomshardware.com%2Fnews%2Fnew-jersey-cobol-coders-mainframes-coronavirus%29
> it said “The governor of New Jersey made a seemingly odd call for help last
> night: The state desperately needs COBOL programmers to revamp the
> 50-year-old software powering the 40-year-old mainframes behind the state's
> unemployment system”.  When I reread the article yesterday I noticed there
> was a link (
> https://www.northjersey.com/story/news/new-jersey/2020/04/04/coronavirus-nj-40-year-old-system-adds-delay-unemployment-checks/2944985001/)
> attached to "odd call for help last night".  So I clicked on the link.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL help for NJ

[Clark Morris]

[Default] On 7 Apr 2020 09:58:43 -0700, in bit.listserv.ibm-main
sasd...@gmail.com (Steve Smith) wrote:

>Really?  40-year-old mainframes? That's close to impossible, and certainly
>ridiculous.  I'm sure many of you remember better than me, but 1980 was the
>era of needing a megawatt or so to generate 20 MIPS or something like
>that.  If you could find the parts and the expertise to keep it going.

Not only that but we don't have enough information to tell what the
true problems are.  If the need is for programmers, then they need
people who know the systems so either retired programmers or those who
have moved on from dealing with the respective systems.  It is no time
to get people who need to learn the systems no matter how much they
know COBOL.  The other need is for those who can assess what is needed
to handle the drastically increased volume and work with the equipment
and abilities to transparently upgrade it.  Note we don't know if the
mainframes are IBM, Unisys or some other vendor.  We also don't know
if the operating system, compilers, database management systems, etc.
are still within support. 

Clark Morris
>
>sas
>
>
>On Tue, Apr 7, 2020 at 11:44 AM Bob Bridges  wrote:
>
>> In the original article (
>> https://www.tomshardware.com/news/new-jersey-cobol-coders-mainframes-coronavirus)
>> it said “The governor of New Jersey made a seemingly odd call for help last
>> night: The state desperately needs COBOL programmers to revamp the
>> 50-year-old software powering the 40-year-old mainframes behind the state's
>> unemployment system”.  When I reread the article yesterday I noticed there
>> was a link (
>> https://www.northjersey.com/story/news/new-jersey/2020/04/04/coronavirus-nj-40-year-old-system-adds-delay-unemployment-checks/2944985001/)
>> attached to "odd call for help last night".  So I clicked on the link.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL help for NJ

[Mark Jacobs]

Ah the enjoyable times running MVS/SE1 on a 3033-AP system and experiencing ACR 
on almost a daily basis.

Mark Jacobs


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Tuesday, April 7, 2020 12:58 PM, Steve Smith  wrote:

> Really? 40-year-old mainframes? That's close to impossible, and certainly
> ridiculous. I'm sure many of you remember better than me, but 1980 was the
> era of needing a megawatt or so to generate 20 MIPS or something like
> that. If you could find the parts and the expertise to keep it going.
>
> sas
>
> On Tue, Apr 7, 2020 at 11:44 AM Bob Bridges robhbrid...@gmail.com wrote:
>
> > In the original article (
> > https://www.tomshardware.com/news/new-jersey-cobol-coders-mainframes-coronavirus)
> > it said “The governor of New Jersey made a seemingly odd call for help last
> > night: The state desperately needs COBOL programmers to revamp the
> > 50-year-old software powering the 40-year-old mainframes behind the state's
> > unemployment system”. When I reread the article yesterday I noticed there
> > was a link (
> > https://www.northjersey.com/story/news/new-jersey/2020/04/04/coronavirus-nj-40-year-old-system-adds-delay-unemployment-checks/2944985001/)
> > attached to "odd call for help last night". So I clicked on the link.
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL help for NJ

[Steve Smith]

Really?  40-year-old mainframes? That's close to impossible, and certainly
ridiculous.  I'm sure many of you remember better than me, but 1980 was the
era of needing a megawatt or so to generate 20 MIPS or something like
that.  If you could find the parts and the expertise to keep it going.

sas


On Tue, Apr 7, 2020 at 11:44 AM Bob Bridges  wrote:

> In the original article (
> https://www.tomshardware.com/news/new-jersey-cobol-coders-mainframes-coronavirus)
> it said “The governor of New Jersey made a seemingly odd call for help last
> night: The state desperately needs COBOL programmers to revamp the
> 50-year-old software powering the 40-year-old mainframes behind the state's
> unemployment system”.  When I reread the article yesterday I noticed there
> was a link (
> https://www.northjersey.com/story/news/new-jersey/2020/04/04/coronavirus-nj-40-year-old-system-adds-delay-unemployment-checks/2944985001/)
> attached to "odd call for help last night".  So I clicked on the link.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL help for NJ

[Bob Bridges]

In the original article 
(https://www.tomshardware.com/news/new-jersey-cobol-coders-mainframes-coronavirus)
 it said “The governor of New Jersey made a seemingly odd call for help last 
night: The state desperately needs COBOL programmers to revamp the 50-year-old 
software powering the 40-year-old mainframes behind the state's unemployment 
system”.  When I reread the article yesterday I noticed there was a link 
(https://www.northjersey.com/story/news/new-jersey/2020/04/04/coronavirus-nj-40-year-old-system-adds-delay-unemployment-checks/2944985001/)
 attached to "odd call for help last night".  So I clicked on the link.

Nothing there, though, that very much resembled a call for help from the 
governor.  The only mention of COBOL was this paragraph:

  “There will be lots of postmortems and one of them on our list will be:
  how did we get here when we literally need COBOL programmers,” Murphy
  said of the outdated computer language.

I'm thinking the headline writer got a little carried away.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Another reason why creative individuals prefer to work at home, as opposed 
to an office, is that when you need to scratch yourself, you don't have to 
sneak behind the copying machine and settle for a hasty grope.  At home, you 
can rear back and assault the affected region with both hands, or, if you want, 
gardening implements.  -Dave Barry */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Stan Saraczewski
Sent: Tuesday, April 7, 2020 06:58

I'd like to present myself to the NJ Labor Dept to assist with their COBOL
tasks... does anyone know of a direct e-mail where I won't have to go thru
their regular channels for jobs ?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

COBOL help for NJ

[Stan Saraczewski]

I'd like to present myself to the NJ Labor Dept to assist with their COBOL
tasks... does anyone know of a direct e-mail where I won't have to go thru
their regular channels for jobs ?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol Help

[Clark Morris]

[Default] On 27 Aug 2017 16:54:26 -0700, in bit.listserv.ibm-main
idfli...@gmail.com (scott Ford) wrote:

>David, All,
>
>I have to think about hardening a COBOL written STC performing security
>calls. This my main reason for the question regarding the I/O error
>handler, it makes sense to move the I/O into an assembler module or C..
>
If you want the program to control the I/O error handling, adding a
status code to the FD (the name of a 2 character PIC XX field normally
in WORKING-STORAGE) and checking it after ALL I/O operations to take
appropriate action should be adequate.

Clark Morris
>
>Scott
>
>
>On Fri, Aug 25, 2017 at 12:07 AM David Crayford <dcrayf...@gmail.com> wrote:
>
>> On 25/08/2017 11:10 AM, Farley, Peter x23353 wrote:
>> > That may well be true, but use of C stdio then requires POSIX mode,
>> which makes it not suitable for a *generalized* file handler which might,
>> for instance, need to be invoked in a totally non-LE environment.
>>
>> Good point about the non-LE environment.  The only time I run non-LE
>> these days is systems level programming and I don't do much of that. I'm
>> doing a lot of Java work these days and C stdio pops it's head up again
>> when using ZFile. It's remarkable that I only need one simple wrapper
>> class to access all the different file types on z/OS. It's not perfect
>> though. I wish it had better support for enumerating PDS members.
>>
>> There is no POSIX requirement for C stdio (or sockets). In my experience
>> the only time I've required POSIX semantics is to use runtime functions
>> for threads, mutexes and IPC stuff.
>>
>> > I would agree with "hundreds of lines" but not thousands.  QSAM support
>> only takes a few hundred, even including MOVE/LOCATE and UPDATE modes (and
>> a lot of that can be explanatory comments for the next maintainer).  Maybe
>> by the time the BSAM/BDAM/VSAM support was done you would have a thousand
>> or more lines, but not I think two or three thousand.
>> >
>> > Depending on how many bells and whistles you want to include of course.
>> As usual, YMMV.
>>
>> We've got a common code assembler VSAM I/O program that's ~1700 LOC, but
>> it does have quite a few bells and whistles. fopen() has extra bling
>> like dynamic allocation. Our assembler dynalloc routine is 987 LOC.  It
>> all adds up and that's before adding extra layers of abstraction.
>>
>> >
>> > Peter
>> >
>> > -Original Message-
>> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of David Crayford
>> > Sent: Wednesday, August 23, 2017 12:53 AM
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: Re: Cobol Help
>> >
>> > On 22/08/2017 11:59 PM, Farley, Peter x23353 wrote:
>> >> In that case the assembler I/O modules handled any errors that they
>> could (SYNAD, etc.) and passed back error code(s) and messages to the COBOL
>> interface module to pass up to the caller, simulating COBOL FILE STATUS and
>> VSAM error variable where possible.
>> >>
>> >> Metal C might be a better choice for more generalized file I/O
>> handling, one small step above assembler but with all assembler facilities
>> available.
>> > The best generalized file handling I've seen on z/OS is the C stdio
>> > fopen() and friends (by a country mile). That one factory function can
>> handle all the standard access methods: BSAM, QSAM, VSAM (KSDS, RRDS,
>> ESDS), hiperspaces and Unix files. It's a thing of beauty. To code the
>> equivalent functionality in Metal/C would take hundreds if not thousands of
>> lines of code.
>> >
>> > --
>> >
>> >
>> > This message and any attachments are intended only for the use of the
>> addressee and may contain information that is privileged and confidential.
>> If the reader of the message is not the intended recipient or an authorized
>> representative of the intended recipient, you are hereby notified that any
>> dissemination of this communication is strictly prohibited. If you have
>> received this communication in error, please notify us immediately by
>> e-mail and delete the message and any attachments from your system.
>> >
>> >
>> > --
>> > For IBM-MAIN subscribe / signoff / archive access instructions,
>> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol Help

[scott Ford]

David, All,

I have to think about hardening a COBOL written STC performing security
calls. This my main reason for the question regarding the I/O error
handler, it makes sense to move the I/O into an assembler module or C..


Scott


On Fri, Aug 25, 2017 at 12:07 AM David Crayford <dcrayf...@gmail.com> wrote:

> On 25/08/2017 11:10 AM, Farley, Peter x23353 wrote:
> > That may well be true, but use of C stdio then requires POSIX mode,
> which makes it not suitable for a *generalized* file handler which might,
> for instance, need to be invoked in a totally non-LE environment.
>
> Good point about the non-LE environment.  The only time I run non-LE
> these days is systems level programming and I don't do much of that. I'm
> doing a lot of Java work these days and C stdio pops it's head up again
> when using ZFile. It's remarkable that I only need one simple wrapper
> class to access all the different file types on z/OS. It's not perfect
> though. I wish it had better support for enumerating PDS members.
>
> There is no POSIX requirement for C stdio (or sockets). In my experience
> the only time I've required POSIX semantics is to use runtime functions
> for threads, mutexes and IPC stuff.
>
> > I would agree with "hundreds of lines" but not thousands.  QSAM support
> only takes a few hundred, even including MOVE/LOCATE and UPDATE modes (and
> a lot of that can be explanatory comments for the next maintainer).  Maybe
> by the time the BSAM/BDAM/VSAM support was done you would have a thousand
> or more lines, but not I think two or three thousand.
> >
> > Depending on how many bells and whistles you want to include of course.
> As usual, YMMV.
>
> We've got a common code assembler VSAM I/O program that's ~1700 LOC, but
> it does have quite a few bells and whistles. fopen() has extra bling
> like dynamic allocation. Our assembler dynalloc routine is 987 LOC.  It
> all adds up and that's before adding extra layers of abstraction.
>
> >
> > Peter
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of David Crayford
> > Sent: Wednesday, August 23, 2017 12:53 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Cobol Help
> >
> > On 22/08/2017 11:59 PM, Farley, Peter x23353 wrote:
> >> In that case the assembler I/O modules handled any errors that they
> could (SYNAD, etc.) and passed back error code(s) and messages to the COBOL
> interface module to pass up to the caller, simulating COBOL FILE STATUS and
> VSAM error variable where possible.
> >>
> >> Metal C might be a better choice for more generalized file I/O
> handling, one small step above assembler but with all assembler facilities
> available.
> > The best generalized file handling I've seen on z/OS is the C stdio
> > fopen() and friends (by a country mile). That one factory function can
> handle all the standard access methods: BSAM, QSAM, VSAM (KSDS, RRDS,
> ESDS), hiperspaces and Unix files. It's a thing of beauty. To code the
> equivalent functionality in Metal/C would take hundreds if not thousands of
> lines of code.
> >
> > --
> >
> >
> > This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> e-mail and delete the message and any attachments from your system.
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol Help

[David Crayford]

On 25/08/2017 11:10 AM, Farley, Peter x23353 wrote:

That may well be true, but use of C stdio then requires POSIX mode, which makes 
it not suitable for a *generalized* file handler which might, for instance, 
need to be invoked in a totally non-LE environment.


Good point about the non-LE environment.  The only time I run non-LE 
these days is systems level programming and I don't do much of that. I'm 
doing a lot of Java work these days and C stdio pops it's head up again 
when using ZFile. It's remarkable that I only need one simple wrapper 
class to access all the different file types on z/OS. It's not perfect 
though. I wish it had better support for enumerating PDS members.


There is no POSIX requirement for C stdio (or sockets). In my experience 
the only time I've required POSIX semantics is to use runtime functions 
for threads, mutexes and IPC stuff.



I would agree with "hundreds of lines" but not thousands.  QSAM support only 
takes a few hundred, even including MOVE/LOCATE and UPDATE modes (and a lot of that can 
be explanatory comments for the next maintainer).  Maybe by the time the BSAM/BDAM/VSAM 
support was done you would have a thousand or more lines, but not I think two or three 
thousand.

Depending on how many bells and whistles you want to include of course.  As 
usual, YMMV.


We've got a common code assembler VSAM I/O program that's ~1700 LOC, but 
it does have quite a few bells and whistles. fopen() has extra bling 
like dynamic allocation. Our assembler dynalloc routine is 987 LOC.  It 
all adds up and that's before adding extra layers of abstraction.




Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Wednesday, August 23, 2017 12:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol Help

On 22/08/2017 11:59 PM, Farley, Peter x23353 wrote:

In that case the assembler I/O modules handled any errors that they could 
(SYNAD, etc.) and passed back error code(s) and messages to the COBOL interface 
module to pass up to the caller, simulating COBOL FILE STATUS and VSAM error 
variable where possible.

Metal C might be a better choice for more generalized file I/O handling, one 
small step above assembler but with all assembler facilities available.

The best generalized file handling I've seen on z/OS is the C stdio
fopen() and friends (by a country mile). That one factory function can handle 
all the standard access methods: BSAM, QSAM, VSAM (KSDS, RRDS, ESDS), 
hiperspaces and Unix files. It's a thing of beauty. To code the equivalent 
functionality in Metal/C would take hundreds if not thousands of lines of code.

--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol Help

[Farley, Peter x23353]

That may well be true, but use of C stdio then requires POSIX mode, which makes 
it not suitable for a *generalized* file handler which might, for instance, 
need to be invoked in a totally non-LE environment.

I would agree with "hundreds of lines" but not thousands.  QSAM support only 
takes a few hundred, even including MOVE/LOCATE and UPDATE modes (and a lot of 
that can be explanatory comments for the next maintainer).  Maybe by the time 
the BSAM/BDAM/VSAM support was done you would have a thousand or more lines, 
but not I think two or three thousand.

Depending on how many bells and whistles you want to include of course.  As 
usual, YMMV.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Wednesday, August 23, 2017 12:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol Help

On 22/08/2017 11:59 PM, Farley, Peter x23353 wrote:
> In that case the assembler I/O modules handled any errors that they could 
> (SYNAD, etc.) and passed back error code(s) and messages to the COBOL 
> interface module to pass up to the caller, simulating COBOL FILE STATUS and 
> VSAM error variable where possible.
>
> Metal C might be a better choice for more generalized file I/O handling, one 
> small step above assembler but with all assembler facilities available.

The best generalized file handling I've seen on z/OS is the C stdio
fopen() and friends (by a country mile). That one factory function can handle 
all the standard access methods: BSAM, QSAM, VSAM (KSDS, RRDS, ESDS), 
hiperspaces and Unix files. It's a thing of beauty. To code the equivalent 
functionality in Metal/C would take hundreds if not thousands of lines of code.

--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol Help

[David Crayford]

On 22/08/2017 11:59 PM, Farley, Peter x23353 wrote:

In that case the assembler I/O modules handled any errors that they could 
(SYNAD, etc.) and passed back error code(s) and messages to the COBOL interface 
module to pass up to the caller, simulating COBOL FILE STATUS and VSAM error 
variable where possible.

Metal C might be a better choice for more generalized file I/O handling, one 
small step above assembler but with all assembler facilities available.


The best generalized file handling I've seen on z/OS is the C stdio 
fopen() and friends (by a country mile). That one factory function can 
handle all the standard access methods: BSAM, QSAM, VSAM (KSDS, RRDS, 
ESDS), hiperspaces and Unix files. It's a thing of beauty. To code the 
equivalent functionality in Metal/C would take hundreds if not thousands 
of lines of code.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol Help

[Scott Vetter]

Scott,
One thing to consider is to write an assembler subroutine called from COBOL to 
handle the file operations exceptions.  There is something I found in the COBOL 
language on the SELECT statement called "FILE STATUS IS" that returns a code 
two-byte alpha numeric (pic xx.) code in a variable in Working Storage.
Let me know how it works out!
Scott Vetter
 

On Tuesday, August 22, 2017 2:35 PM, Frank Swarbrick 
<frank.swarbr...@outlook.com> wrote:
 

 Can the OP elaborate on what the use case is for this "generalized file 
handler"?  What is it going to do?


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Farley, Peter x23353 <peter.far...@broadridge.com>
Sent: Tuesday, August 22, 2017 9:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol Help

Scott,

IMHO COBOL is highly unsuited for use as a *generalized* file handler.  For 
known files and record sizes and file types (i.e., application-specific I/O 
modules) the FILE STATUS variable and the VSAM feedback variable for VSAM files 
are your only choice for error handling.

I have seen a COBOL I/O module that handled any LRECL, QSAM or VSAM file of a 
particular variable-length record type by using three assembler modules (QSAM, 
ESDS and KSDS) for the actual I/O functions (open, close, read, write, keyed 
read, update, etc.), with the COBOL interface managing the internal data 
structures supporting the collection of files opened at the request of the 
caller(s) in any particular batch step.

In that case the assembler I/O modules handled any errors that they could 
(SYNAD, etc.) and passed back error code(s) and messages to the COBOL interface 
module to pass up to the caller, simulating COBOL FILE STATUS and VSAM error 
variable where possible.

Metal C might be a better choice for more generalized file I/O handling, one 
small step above assembler but with all assembler facilities available.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of scott Ford
Sent: Monday, August 21, 2017 8:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Cobol Help

Guys/Gals:

I need some help on a error I am not real familiar with in Cobol.
I need write a generalized file-handler for files. Where do I start ?
These are mostly QSAM files.. but i have to deal with Open/close/empty
files, wrong length records...I have seen U1035 or similar errors and have
done some reading in the manuals. Whats the easiest most effective method
to handle file errors ?

Regards,
Scott

--



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com<http://www.idmworks.com>

scott.f...@idmworks.com

Blog: www.idmworks.com/blog<http://www.idmworks.com/blog>





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol Help

[Frank Swarbrick]

Can the OP elaborate on what the use case is for this "generalized file 
handler"?  What is it going to do?


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Farley, Peter x23353 <peter.far...@broadridge.com>
Sent: Tuesday, August 22, 2017 9:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cobol Help

Scott,

IMHO COBOL is highly unsuited for use as a *generalized* file handler.  For 
known files and record sizes and file types (i.e., application-specific I/O 
modules) the FILE STATUS variable and the VSAM feedback variable for VSAM files 
are your only choice for error handling.

I have seen a COBOL I/O module that handled any LRECL, QSAM or VSAM file of a 
particular variable-length record type by using three assembler modules (QSAM, 
ESDS and KSDS) for the actual I/O functions (open, close, read, write, keyed 
read, update, etc.), with the COBOL interface managing the internal data 
structures supporting the collection of files opened at the request of the 
caller(s) in any particular batch step.

In that case the assembler I/O modules handled any errors that they could 
(SYNAD, etc.) and passed back error code(s) and messages to the COBOL interface 
module to pass up to the caller, simulating COBOL FILE STATUS and VSAM error 
variable where possible.

Metal C might be a better choice for more generalized file I/O handling, one 
small step above assembler but with all assembler facilities available.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of scott Ford
Sent: Monday, August 21, 2017 8:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Cobol Help

Guys/Gals:

I need some help on a error I am not real familiar with in Cobol.
I need write a generalized file-handler for files. Where do I start ?
These are mostly QSAM files.. but i have to deal with Open/close/empty
files, wrong length records...I have seen U1035 or similar errors and have
done some reading in the manuals. Whats the easiest most effective method
to handle file errors ?

Regards,
Scott

--



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com<http://www.idmworks.com>

scott.f...@idmworks.com

Blog: www.idmworks.com/blog<http://www.idmworks.com/blog>





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol Help

[Farley, Peter x23353]

Scott,

IMHO COBOL is highly unsuited for use as a *generalized* file handler.  For 
known files and record sizes and file types (i.e., application-specific I/O 
modules) the FILE STATUS variable and the VSAM feedback variable for VSAM files 
are your only choice for error handling.

I have seen a COBOL I/O module that handled any LRECL, QSAM or VSAM file of a 
particular variable-length record type by using three assembler modules (QSAM, 
ESDS and KSDS) for the actual I/O functions (open, close, read, write, keyed 
read, update, etc.), with the COBOL interface managing the internal data 
structures supporting the collection of files opened at the request of the 
caller(s) in any particular batch step.

In that case the assembler I/O modules handled any errors that they could 
(SYNAD, etc.) and passed back error code(s) and messages to the COBOL interface 
module to pass up to the caller, simulating COBOL FILE STATUS and VSAM error 
variable where possible.

Metal C might be a better choice for more generalized file I/O handling, one 
small step above assembler but with all assembler facilities available.

HTH

Peter
 
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of scott Ford
Sent: Monday, August 21, 2017 8:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Cobol Help

Guys/Gals:

I need some help on a error I am not real familiar with in Cobol.
I need write a generalized file-handler for files. Where do I start ?
These are mostly QSAM files.. but i have to deal with Open/close/empty
files, wrong length records...I have seen U1035 or similar errors and have
done some reading in the manuals. Whats the easiest most effective method
to handle file errors ?

Regards,
Scott

-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol Help

[Clark Morris]

[Default] On 21 Aug 2017 05:39:28 -0700, in bit.listserv.ibm-main
idfli...@gmail.com (scott Ford) wrote:

>Guys/Gals:
>
>I need some help on a error I am not real familiar with in Cobol.
>I need write a generalized file-handler for files. Where do I start ?
>These are mostly QSAM files.. but i have to deal with Open/close/empty
>files, wrong length records...I have seen U1035 or similar errors and have
>done some reading in the manuals. Whats the easiest most effective method
>to handle file errors ?

What are the characteristics of this file handler and how is it to be
use?  If this is to be a utility for any file, COBOL may not be
appropriate.  You would at least have to have separate FDs for
non-VSAM versus VSAM and FB non-VSAM versus VB non-VSAM versus V
non-VSAM.  While you at least used to be able to have RECORD 0, BLOCK
0 for input I don't recall what the limitations were on how you
described the record.  There are some cute things that can be done
with COBOL but there are limits.  

Clark Morris
>
>Regards,
>Scott

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol Help

[John McKown]

On Mon, Aug 21, 2017 at 7:40 AM, scott Ford  wrote:

> Guys/Gals:
>
> I need some help on a error I am not real familiar with in Cobol.
> I need write a generalized file-handler for files. Where do I start ?
> These are mostly QSAM files.. but i have to deal with Open/close/empty
> files, wrong length records...I have seen U1035 or similar errors and have
> done some reading in the manuals. Whats the easiest most effective method
> to handle file errors ?
>

​We generally use the FILE STATUS clause
https://www.ibm.com/support/knowledgecenter/en/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/ref/rliossta.htm

SELECT SOMEFILE ASSIGN TO UT-S-DDNAME
 FILE STATUS IS WS-SOMEFILE-STATUS WS-SOMEFILE-STATUS2
...

77 WS-SOMEFILE-STATUS PIC 99.​
01 WS-SOMEFILE-STATUS2.
   05 WS-SOMEFILE-VSAM-RC PIC S99 BINARY.
   05 WS-SOMEFILE-VSAM-FC PIC S99 BINARY.
   05 WS-SOMEFILE-VSAM-FB PIC S99 BINARY.


​The WS-SOMEFILE-STATUS2 only applies to VSAM data sets. This will handle
_most_ of the I/O "problems" which you may encounter. One thing you need to
remember is that a COBOL​ definition cannot handle a "generic" situation.
In particular, if you are reading an FB type data set, then the FD for that
data set _must_ have the proper record length. If it does not, you CANNOT
open it successfully. The above FILE STATUS will let you "trap" the problem
and report a failure. But that is _all_ that it can do. A single FD simply
cannot read both an FB/80 and an FB/90 (for example) file.

Another thing to look is the the DECLARITIVES section.
https://www.ibm.com/support/knowledgecenter/en/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/ref/rlpdsdec.htm
This section can handle most error situations on a file.

The last thing that I will mention is not really a COBOL language facility,
but an LE facility. That is the LE abend handler, CEEHDLR.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea300/clchdlr.htm
Being LE in nature, it is not as easy to understand as COBOL. But it is
LE's version of an ESTAE.



> Regards,
> Scott
>
> --
>
>
>
> *IDMWORKS *
>
> Scott Ford
>
> z/OS Dev.
>
>
>
>
> “By elevating a friend or Collegue you elevate yourself, by demeaning a
> friend or collegue you demean yourself”
>
>
>
> www.idmworks.com
>
> scott.f...@idmworks.com
>
> Blog: www.idmworks.com/blog
>
>
>
>
>
> *The information contained in this email message and any attachment may be
> privileged, confidential, proprietary or otherwise protected from
> disclosure. If the reader of this message is not the intended recipient,
> you are hereby notified that any dissemination, distribution, copying or
> use of this message and any attachment is strictly prohibited. If you have
> received this message in error, please notify us immediately by replying to
> the message and permanently delete it from your computer and destroy any
> printout thereof.*
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
If you look around the poker table & don't see an obvious sucker, it's you.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Cobol Help

[Lizette Koehler]

So do you need  complete code? Or just guidelines on how to code cobol?

Any general COBOL text (class book or book from Amazon) or internet search 
should get you started.

If you need a simple read a record write a record, let me know and I can send 
you a sample COBOL program


A quick internet search with the key words

COBOL READ WRITE A RECORD

Brought up this lovely little code

http://people.sju.edu/~jhodgson/cobol/sample.html


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of scott Ford
> Sent: Monday, August 21, 2017 5:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Cobol Help
> 
> Guys/Gals:
> 
> I need some help on a error I am not real familiar with in Cobol.
> I need write a generalized file-handler for files. Where do I start ?
> These are mostly QSAM files.. but i have to deal with Open/close/empty files,
> wrong length records...I have seen U1035 or similar errors and have done some
> reading in the manuals. Whats the easiest most effective method to handle
> file errors ?
> 
> Regards,
> Scott
> 
> --
> 
> 
> 
> *IDMWORKS *
> 
> Scott Ford
> 
> z/OS Dev.
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Cobol Help

[scott Ford]

Guys/Gals:

I need some help on a error I am not real familiar with in Cobol.
I need write a generalized file-handler for files. Where do I start ?
These are mostly QSAM files.. but i have to deal with Open/close/empty
files, wrong length records...I have seen U1035 or similar errors and have
done some reading in the manuals. Whats the easiest most effective method
to handle file errors ?

Regards,
Scott

-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN