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:[email protected]] On Behalf Of John McKown Sent: Monday, September 09, 2013 12:33 PM To: [email protected] 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 <[email protected]>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:[email protected]] On > Behalf Of John McKown > Sent: Monday, September 09, 2013 9:22 AM > To: [email protected] > 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 [email protected] 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 [email protected] 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 [email protected] with the message: INFO IBM-MAIN
