Re: COBOL help for NJ
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
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
> 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
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
[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
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&search=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
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
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
Re: Cobol Help
[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 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
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 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
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
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
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, 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 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 on behalf of Farley, Peter x23353 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
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 on behalf of Farley, Peter x23353 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
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
[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
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
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