Forwarding this to the programmer. I had never thought of it. I'm not a COBOL programmer. I somewhat know the COBOL language, but I don't really use it.
On Mon, Sep 9, 2013 at 11:58 AM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > Have the programmer write two OPTIONAL FILE definitions with the same DD > name component, one for the F-format file and one for the V-format file, > both referencing the same FILE STATUS variable (PIC 99). The open > paragraph should first try to open the F-format file and then check the > FILE STATUS variable. If the status is 00 then a fixed file is the input > and the open paragraph should set a switch for the read and close > paragraphs to read or close the F-format file. If the status code from the > fixed open is not 00, then open the variable file and again check the FILE > STATUS variable. If it is not 00, then message the console and/or SYSOUT > and abend (no valid input file), otherwise set a switch for the read and > close paragraphs to read or close the V-format file. > > The read paragraph can move the record from the selected FILE record area > to a common working-storage definition so that the processing paragraphs > can all use common data names. > > Then just process as usual. > > HTH > > Peter > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of John McKown > Sent: Monday, September 09, 2013 12:33 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SORT? need. > > True. But I don't know of any way to code a COBOL file definition to be > either F or V. COBOL is just not designed for that. > > Hum, I almost want to do the following: have the programmer write the file > out to a UNIX "temporary" file using TSO OCOPY. UNIX doesn't have the > concept of fixed versus variable length text files (and it is text). Then > the COBOL program could read the UNIX file as VARIABLE. But that would even > more conceptually difficult than REXX. And you're right, in this > environment, I just don't have it in me anymore to "fight for the right". > Or for advancing knowledge. We are "stabilized" by IT decree. And actually > retreating as a company. > > > On Mon, Sep 9, 2013 at 11:26 AM, Lizette Koehler <stars...@mindspring.com > >wrote: > > > So, another question is, how would you code it normally in COBOL if the > > file > > could be VB one time and FB another? I do not think the technique for > that > > would be different for SORT. > > > > To me, this is not a SORT issue, but how COBOL handles a File IO section > > when the file could be any type (FB, VB, VSAM, etc...) > > > > > > Lizette > > > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of John McKown > > Sent: Monday, September 09, 2013 9:22 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: SORT? need. > > > > I haven't yet looked in the DFSORT manual, bad me, but I'll ask anyway. > > > > Programmer has a "problem". He is writing a COBOL program. No, that's not > > the problem <grin/>. He wants the input to be an OPTIONAL file which > might > > be VB in one run an FB in a different run. This file is "user" > generated. I > > told him to tell the user to put in the SITE command necessary to make > the > > uploaded file be VB. He basically said that he didn't think he could > > _force_ > > them to do that. The conversation degenerated after that. > > > > Anyway, DFSORT has a FTOV function. But I need an "any"TOV type function. > > That is, it will read FB or VB and output VB. > > > > If this were me, I'd use REXX because I've been told these will be > "small" > > files. But the programmer doesn't know REXX. And I'm not go write it for > > him > > because our programmers don't know REXX and so won't be able to support > it. > > And I'd end up being support-for-eternity for this. It's happened before > > with some HLASM code which is now "mine". > > > > -- > > As of next week, passwords will be entered in Morse code. > > > > Maranatha! <>< > > John McKown > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > -- > As of next week, passwords will be entered in Morse code. > > Maranatha! <>< > John McKown > > ---------------------------------------------------------------------- > 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 > -- As of next week, passwords will be entered in Morse code. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
