Re: question on BLK vs. NOBLK compiler option...

Answers in-line below Michael

On Tue, 28 Nov 2006 15:55:03 -0500, Michael Rosinger wrote

Jon,

I appreciate your response. Let me rephrase my issue/question. 
Perhaps the compiler option BLK/NOBLK has nothing to do with what I 
am wanting to know.

We READ and WRITE quite a few sequential files (not indexed or 
relative) in many of our COBOL programs. Virtually all of the FD's 
for those files have the BLOCK CONTAINS clause specified. Many of 
these sequential files have variable length records.

As you are hopefully aware by now - in the System i world there is no such
thing as a variable length record.  ILE COBOL does recognize a specific file
structure as being able to be treated as variable length and will calculate
the appropriate length and place it where COBOL expects to find it.  The
structure is one that contains zero or many fixed length fields followed by
one (and only one) variable length field.)

Other than for variable length records, the block contains clause is
completely ignored.
 

My question is what is the best combination to use in the iSeries world?

1) Remove the BLOCK CONTAINS altogether and let the compiler block 
and de-block as it sees fit? Does it do a good job?

The compiler will block and deblock as it sees fit regardless of the block
contains clause.  It has no impact.  Only those factors referenced in my
previous note have any effect.

2) Retain BLOCK CONTAINS and use what was originally specified in 
the VSE world?

Since it has no effect I would go with this option.
 

3) Retain BLOCK CONTAINS and but specify a new value that is more 
correct for the iSeries world? Is there a rule of thumb for this?

No point - see 2 above.


Not trying to get on your case or anything, but the majority of folks who come
from the mainframe world spend an enormous amount of time trying to find the
"best" way to do things that have no meaning/equivalent in the System i world.
 That's why when you first enquired on this list I suggested that you hire
someone who has "been there before" because for the sake of paying them for
four or five days you could have had all of these issues resolved long ago.  

 

-- 
Regards,

Michael Rosinger
Systems Programmer / DBA
Computer Credit, Inc.
640 West Fourth Street
Winston-Salem, NC  27101
336-761-1524
m rosinger at cciws dot com
"Jon Paris" <Jon.Paris@xxxxxxxxxxxxxx> wrote in message 
news:mailman.2884.1164732696.2629.cobol400-l@xxxxxxxxxxxxxxx

On Tue, 28 Nov 2006 11:22:25 -0500, Michael Rosinger wrote

List,

Another question related to the migration of our COBOL programs from
VSE to iSeries. We have a lot of sequential files that have a BLOCK
CONTAINS clause specified in the FD. I see that the default compiler
option is NOBLK and I am getting a "LNC0662 For file %1, BLOCK
CONTAINS clause syntax checked only." informational message in my 
compiles.

So what it is best to use (BLK or NOBLK) and why? TIA

The parameter you reference has nothing to do with the Block Contains 
clause -
which is ignored on the System i (I think it is on VSE as well but ...)

It has to do with whether you want to overrule the compiler's defaults for
blocking.

The compiler will automatically block and file that is processed 
sequentially
- but will not block any file for which a read by key operation exists. 
If
you _know_ that you are reading by key only to position prior to a read 
next
sequence then using the BLK to force blocking will help performance.  You 
can
also control blocking via the OVRDBF but that is a separate blocking 
operation
(i.e. how much of the file is retrieved into the OS buffers whereas BLK
controls the program's buffers).

Would write more but I'm on dial up today and can't research the stuff.


Jon Paris

-- 
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L)
 mailing list To post a message email: COBOL400-L@xxxxxxxxxxxx To 
subscribe, unsubscribe, or change list options, visit: 
http://lists.midrange.com/mailman/listinfo/cobol400-l or email: 
COBOL400-L-request@xxxxxxxxxxxx Before posting, please take a moment 
to review the archives at http://archive.midrange.com/cobol400-l.

Jon Paris
Partner400
www.Partner400.com