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

Any record length for input file in a same COBOL program ?


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

New User


Joined: 28 Dec 2006
Posts: 80
Location: France

PostPosted: Fri Mar 02, 2007 4:47 am
Reply with quote

I've created a COBOL program which increases several fields of a FB file.

(from parameters read in a work file)

But I'd like this program could be used for any record length (input or output) so that I haven't to duplicate it.

ex :

File A in input (100 bytes)
File B in input (150 bytes)

or

File A in input (110 bytes)
File B in input (140 bytes)

Is it possible to do it ? e.g with "depending on" ?
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ

PostPosted: Fri Mar 02, 2007 7:15 am
Reply with quote

I can't give you much help, what you want is pretty much a "no can do" with COBOL. but I saw this, I have not chased it down, but you might think of looking into it:
another Bill wrote:
Read up on the run-time option CBLQDA(ON), which allows dynamic access of QSAM files.
This has been around for at least 15 years, so unless you have a ancient version of COBOL, this should work for you.
BTW, this is clearly documented in the IBM manuals.


Thanks nice soft kitty.... icon_wink.gif
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: Fri Mar 02, 2007 7:27 am
Reply with quote

Hello,

Quote:
Is it possible to do it ? e.g with "depending on" ?


If you use a depending on, you have changed the format from fixed to variable - probably not what you want.

If you post a few examples of what you want to do, we may be able to offer suggestions.
Back to top
View user's profile Send private message
Searchman

New User


Joined: 28 Dec 2006
Posts: 80
Location: France

PostPosted: Fri Mar 02, 2007 5:44 pm
Reply with quote

Unfortunatly the files are FB, they can't be changed and for the run time option, I don't know if it's possible to modify parameters.
Back to top
View user's profile Send private message
acevedo

Active User


Joined: 11 May 2005
Posts: 344
Location: Spain

PostPosted: Fri Mar 02, 2007 6:32 pm
Reply with quote

Search for RECORD CONTAINS 0 CHARACTERS
Back to top
View user's profile Send private message
superk

Global Moderator


Joined: 26 Apr 2004
Posts: 4652
Location: Raleigh, NC, USA

PostPosted: Fri Mar 02, 2007 8:05 pm
Reply with quote

OK, programmers, here's a related question that's been bugging me as long as I've been doing this:

Why don't shops mandate standard for QSAM data such as:

1. All datasets must be of a pre-determined LRECL, making them easily shared among applications, and allowing for ease of adding additional fields in the future.

2. All datasets must be defined as VB.

3. All datasets must be VB, and the data must be delimited with a common delimiter, resulting in the smallest possible file sizes.

4. And, while I'm at it, that all fields be written and stored in text format, i.e. no binary, hexadecimal, or packed data fields.
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ

PostPosted: Fri Mar 02, 2007 8:44 pm
Reply with quote

superk wrote:
1. All datasets must be of a pre-determined LRECL, making them easily shared among applications, and allowing for ease of adding additional fields in the future.
Sounds OK.
Quote:
2. All datasets must be defined as VB.
That I like for most cases.
Quote:
3. All datasets must be VB, and the data must be delimited with a common delimiter, resulting in the smallest possible file sizes.
VB delimiters? Smallest size is good.
Quote:
4. And, while I'm at it, that all fields be written and stored in text format, i.e. no binary, hexadecimal, or packed data fields.
For a lot of intermediate stuff, that is good, but for the large, core, heavily used stuff, I tend to lean towards packed numerics.

BTW, Cute... icon_wink.gif That'll put 'em quite at ease..... icon_lol.gif
Back to top
View user's profile Send private message
Douglas Wilder

Active User


Joined: 28 Nov 2006
Posts: 305
Location: Deerfield IL

PostPosted: Wed Mar 07, 2007 3:54 am
Reply with quote

I have written COBOL programs as E15 sort exits for things like this.
The input record is read by sort and passed to the program.
The program can modify the record and then pass it back to sort
Sort will write the record, read the next record...

Maybe this will help.
Back to top
View user's profile Send private message
MoLong

New User


Joined: 07 Feb 2007
Posts: 32
Location: Chennai

PostPosted: Wed Mar 07, 2007 1:23 pm
Reply with quote

Try this logic. Hope it works.
Create multiple selects for each applicable len with RECLEN as max possible. Create FD entries with filler towards the end part. Pass the reclen with which you want to work as a parameter to the program. based on it access the correct rec.
But this can be used only if you have limited varlength combinations.
Back to top
View user's profile Send private message
jasorn
Warnings : 1

Active User


Joined: 12 Jul 2006
Posts: 191
Location: USA

PostPosted: Mon Apr 02, 2007 2:38 am
Reply with quote

superk wrote:
OK, programmers, here's a related question that's been bugging me as long as I've been doing this:

Why don't shops mandate standard for QSAM data such as:

1. All datasets must be of a pre-determined LRECL, making them easily shared among applications, and allowing for ease of adding additional fields in the future.

Space issue.

Quote:

2. All datasets must be defined as VB.

I don't think that's such a bad idea but in general vb is harder to work with. Maybe just different but perceived as harder.

Quote:

3. All datasets must be VB, and the data must be delimited with a common delimiter, resulting in the smallest possible file sizes.

Delimited files are definitely harder to work with.
Quote:

4. And, while I'm at it, that all fields be written and stored in text format, i.e. no binary, hexadecimal, or packed data fields.

[/quote]
Space issue(not so much anymore) and performance issue. The comp fieds are faster to work with.
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ

PostPosted: Mon Apr 02, 2007 2:43 am
Reply with quote

acevedo wrote:
Search for RECORD CONTAINS 0 CHARACTERS
I did and it is nice to learn something new... icon_smile.gif ..Thanks for the pointer.... 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 How to split large record length file... DFSORT/ICETOOL 7
No new posts Replace each space in cobol string wi... COBOL Programming 2
No new posts Using API Gateway from CICS program CICS 0
No new posts PARSE Syntax for not fix length word ... JCL & VSAM 7
No new posts Extracting Variable decimal numbers f... DFSORT/ICETOOL 17
Search our Forums:

Back to Top