IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Extract a part from a cobol program


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Mahi_e

New User


Joined: 10 Dec 2010
Posts: 43
Location: hyderabad

PostPosted: Fri Jun 24, 2011 3:24 pm
Reply with quote

Hello all.......

I have a problem that i am describing here as follows.........

" Suppose I have to extract some only FD section( one or more FD Sections in single program) of a COBOL program as output file, ie.,


INPUT COBOL PROGRAM ( contains FD Section(s) with all variables)
|
|
ANOTHER COBOL PROGRAM ( PROGRAM TO EXTRACT FD Section(s) )
|
|
OUTPUT FILE( EXTRACTED FD PART OF INPUT)

please provide me the Program and JCL

Note : each FD section should be in a different file ) icon_rolleyes.gif
Back to top
View user's profile Send private message
Dsingh29

Active User


Joined: 16 Dec 2008
Posts: 132
Location: IBM

PostPosted: Fri Jun 24, 2011 3:28 pm
Reply with quote

Would you please elaborate what are you trying to achieve by extracting FD sections from programs? People here might suggest a better approach.
Back to top
View user's profile Send private message
GuyC

Senior Member


Joined: 11 Aug 2009
Posts: 1281
Location: Belgium

PostPosted: Fri Jun 24, 2011 3:36 pm
Reply with quote

Mahi_e wrote:
please provide me the Program and JCL
Do you have an amount in mind that you are willing to pay?
Back to top
View user's profile Send private message
Mahi_e

New User


Joined: 10 Dec 2010
Posts: 43
Location: hyderabad

PostPosted: Fri Jun 24, 2011 4:08 pm
Reply with quote

Quote:
Would you please elaborate what are you trying to achieve by extracting FD sections from programs? People here might suggest a better approach.


sure........


i want to make these FD sections as copy books to another programs, icon_neutral.gif
Back to top
View user's profile Send private message
Dsingh29

Active User


Joined: 16 Dec 2008
Posts: 132
Location: IBM

PostPosted: Fri Jun 24, 2011 4:15 pm
Reply with quote

Thats what I was guessing.

If you have a thorough look at FD sections, these contains some information like

Code:
BLOCK CONTAINS 0 RECORDS         
LABEL RECORD IS STANDARD         
RECORD CONTAINS xxx CHARACTERS   
RECORDING MODE IS F             
DATA RECORD IS xxxx-rec.


If you include these also, then the very purpose of copybooks ie re-usability would be defeated. Make copybooks for only record layouts.
Back to top
View user's profile Send private message
Mahi_e

New User


Joined: 10 Dec 2010
Posts: 43
Location: hyderabad

PostPosted: Fri Jun 24, 2011 5:10 pm
Reply with quote

Thanks Dave,

yeah i have to extract the Record Layout only from the Program,not the following.....
Code:
BLOCK CONTAINS 0 RECORDS         
LABEL RECORD IS STANDARD         
RECORD CONTAINS xxx CHARACTERS   
RECORDING MODE IS F             
DATA RECORD IS xxxx-rec.
Back to top
View user's profile Send private message
Mahi_e

New User


Joined: 10 Dec 2010
Posts: 43
Location: hyderabad

PostPosted: Fri Jun 24, 2011 5:11 pm
Reply with quote

how to do .............. icon_wink.gif ?
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Fri Jun 24, 2011 5:18 pm
Reply with quote

before getting down to the technicalities, there is quìte a bit of administrative work to be done

I would not expect that a record layout randomly chosen from a program would fit as is in any other program trying to us it!

anyway there is no way to automate the thing in an easy way

just edit each and every program using the layout ,
substitute the record description with the proper COPY directive

in the PDS holding the COPYbooks edit and save with the proper name the record definitions .

nothing that could not have been done by anybody with a basic cobol skill
as You declared to have in your profile
Back to top
View user's profile Send private message
Craq Giegerich

Senior Member


Joined: 19 May 2007
Posts: 1512
Location: Virginia, USA

PostPosted: Fri Jun 24, 2011 5:37 pm
Reply with quote

Don't forget that programs may do a 'read into' or a 'write from' and the record layouts may then be in WORKING-STORAGE SECTION instead of the FILE SECTION.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Sat Jun 25, 2011 4:30 am
Reply with quote

Mahi_e,

How many of these copybooks do you have to do? Is it a once-off task, or somehow ongoing?

If the number of programs/times needed is manageable, do it manually along the lines enrico has mentioned.

You could automate with rexx, or semi-automate with rexx (cursor on 01 level, press a function key assigned to your rexx, which extracts the record-layout in edit mode, allows you to save it in copybook PDS).

If you really want to do it in Cobol for some reason, it's not too bad.

Define your input record so you can ignore first six characters and the sequence number, along with column 7, and your actual data.

When reading, ignore all blank lines (in data part of your record) and all comments.

You have to be aware of what is possible for valid Cobol statements. You need the program name, but it can be on a different line than PROGRAM-ID, so deal with it. When you hit "WORKING-STORAGE" you have finished with the program. Bear in mind that maybe some programs have copybooks already. Otherwise, once you find FD, ignore records until you get "01" (remembering it does not have to be in a fixed position). Then rip everything out until you get to FD, then repeat until your logical end.

I'd put everything to one file in the format for automatic member creation, as well as a report showing which program it came from. PDS names would be something you'd need to sort out or look at doing it your original way if you really prefer.

I'd use UNSTRING and INSPECT. Use Inspect for removing all full-stops/periods. Unstring to get first and second "word" on the current line.

Prior to the arrival of STRING/UNSTRING I'd have used Occurs Depending On, but they've made that trickier now by pretending they've removed old-shcool "complex occurs depending on" from the compiler.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Sat Jun 25, 2011 8:20 am
Reply with quote

Hello,

Quote:
but they've made that trickier now by pretending they've removed old-shcool "complex occurs depending on" from the compiler.


Who are "they" wnd where have they done this?

One of my clients "went ape" 20-30 years ago and many of their main files still use ODO quite heavily. Best i can tell, it works just as expected up thru Enterprise COBOL 4.x.

Have i gotten myself lost again?

d
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Sat Jun 25, 2011 10:56 am
Reply with quote

"They" are the people who pretend to look in shop windows when you glance behind yourself walking down Baker Street :-)

What has been removed is the ability to redefine something which has Occurs Depending On. This is the "old complex". The "new complex" is just having multiple ODO in the same table.

Also some changes to when the variable length is calculated.

All the information is available for reading, usual place.

I think ANSI actually get the blame.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Sat Jun 25, 2011 11:19 am
Reply with quote

Sorry Dick, I only just got what you were thinking, so here again.

It was decided, by "them" (to bring into line with ANSI standard, I think)
that part of the way that ODO could be used should be removed.

To remove part of it, they had to give it a name, so they called it "complex occurs depending on", then said that you couldn't use "complex occurs depending on".

Then, to complex things further, they decided that any table with two or more ODOs was the "new" "complex occurs depending on".

So ODO itself is still there, and both the, presumably "simple", and "new complex" work around-about like they always have.

Redefines of, or with, ODO, however, won't work. Not directly. Indirectly you can do it. Hence "pretending they've removed" from my earlier post.
Back to top
View user's profile Send private message
Marso

REXX Moderator


Joined: 13 Mar 2006
Posts: 1353
Location: Israel

PostPosted: Sat Jun 25, 2011 10:21 pm
Reply with quote

Mahi_e wrote:
FD section
I know about FILE SECTION, where the FD entry is, but never heard of this. Is that a new cobol statement?

Mahi_e wrote:
please provide me the Program and JCL
Sure, why don't you take a few days off, work will be done when you come back.

...or...
Use Bill ideas and start working on your own. It's the best way to learn and get experience!

If you want to run your cobol program on many members of a library, you will also need a small rexx program that lists the members, allocates the files and executes your program.
You may want to reconsider and do everything in rexx.
Back to top
View user's profile Send private message
Mahi_e

New User


Joined: 10 Dec 2010
Posts: 43
Location: hyderabad

PostPosted: Mon Jun 27, 2011 10:38 am
Reply with quote

Thanks to all Suggestions.

icon_lol.gif
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Replace each space in cobol string wi... COBOL Programming 3
No new posts Using API Gateway from CICS program CICS 0
No new posts COBOL -Linkage Section-Case Sensitive COBOL Programming 1
No new posts COBOL ZOS Web Enablement Toolkit HTTP... COBOL Programming 0
No new posts Need help for File Aid JCL to extract... Compuware & Other Tools 23
Search our Forums:

Back to Top