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@xxxxxxxxxxxxxxxOn Tue, 28 Nov 2006 11:22:25 -0500, Michael Rosinger wroteList, 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? TIAThe 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
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.