Discussion:
Cobol Help
(too old to reply)
scott Ford
2017-08-21 12:39:28 UTC
Permalink
Raw Message
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

***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2017-08-21 14:07:01 UTC
Permalink
Raw Message
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-----
Behalf Of scott Ford
Sent: Monday, August 21, 2017 5:41 AM
Subject: Cobol Help
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-08-21 14:50:36 UTC
Permalink
Raw Message
Post by scott Ford
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.
Post by scott Ford
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
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,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2017-08-21 17:08:36 UTC
Permalink
Raw Message
[Default] On 21 Aug 2017 05:39:28 -0700, in bit.listserv.ibm-main
Post by scott Ford
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
Post by scott Ford
Regards,
Scott
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2017-08-22 15:58:14 UTC
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On Behalf Of scott Ford
Sent: Monday, August 21, 2017 8:41 AM
To: IBM-***@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

***@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 ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Frank Swarbrick
2017-08-22 18:33:39 UTC
Permalink
Raw Message
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-***@LISTSERV.UA.EDU> on behalf of Farley, Peter x23353 <***@BROADRIDGE.COM>
Sent: Tuesday, August 22, 2017 9:59 AM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of scott Ford
Sent: Monday, August 21, 2017 8:41 AM
To: IBM-***@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>

***@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 ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Scott Vetter
2017-08-23 04:24:03 UTC
Permalink
Raw Message
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 <***@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-***@LISTSERV.UA.EDU> on behalf of Farley, Peter x23353 <***@BROADRIDGE.COM>
Sent: Tuesday, August 22, 2017 9:59 AM
To: IBM-***@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-***@LISTSERV.UA.EDU] On Behalf Of scott Ford
Sent: Monday, August 21, 2017 8:41 AM
To: IBM-***@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>

***@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 ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

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



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David Crayford
2017-08-23 04:51:41 UTC
Permalink
Raw Message
Post by Farley, Peter x23353
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2017-08-25 03:09:17 UTC
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On Behalf Of David Crayford
Sent: Wednesday, August 23, 2017 12:53 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Cobol Help
Post by Farley, Peter x23353
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
David Crayford
2017-08-25 04:06:18 UTC
Permalink
Raw Message
Post by 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.
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.
Post by Farley, Peter x23353
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.
Post by Farley, Peter x23353
Peter
-----Original Message-----
Sent: Wednesday, August 23, 2017 12:53 AM
Subject: Re: Cobol Help
Post by Farley, Peter x23353
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
scott Ford
2017-08-27 23:54:26 UTC
Permalink
Raw Message
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
Post by Farley, Peter x23353
Post by 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.
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.
Post by Farley, Peter x23353
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.
Post by Farley, Peter x23353
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.
Post by Farley, Peter x23353
Peter
-----Original Message-----
On Behalf Of David Crayford
Post by Farley, Peter x23353
Sent: Wednesday, August 23, 2017 12:53 AM
Subject: Re: Cobol Help
Post by Farley, Peter x23353
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.
Post by Farley, Peter x23353
Post by Farley, Peter x23353
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.
Post by Farley, Peter x23353
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.
Post by Farley, Peter x23353
--
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.
Post by Farley, Peter x23353
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
Scott Ford
IDMWORKS
z/OS Development

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2017-08-28 12:25:24 UTC
Permalink
Raw Message
[Default] On 27 Aug 2017 16:54:26 -0700, in bit.listserv.ibm-main
Post by 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..
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
Post by scott Ford
Scott
Post by Farley, Peter x23353
Post by 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.
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.
Post by Farley, Peter x23353
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.
Post by Farley, Peter x23353
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.
Post by Farley, Peter x23353
Peter
-----Original Message-----
On Behalf Of David Crayford
Post by Farley, Peter x23353
Sent: Wednesday, August 23, 2017 12:53 AM
Subject: Re: Cobol Help
Post by Farley, Peter x23353
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.
Post by Farley, Peter x23353
Post by Farley, Peter x23353
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.
Post by Farley, Peter x23353
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.
Post by Farley, Peter x23353
--
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.
Post by Farley, Peter x23353
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...