IBM Mainframe Forum

CLIST 588 ERROR & How to read part of a record?

I want to read a flat file, the record lenth of the file is 310. Some fileds of the file are COMP. When you browse the file, you will see some special characters in these fields. Actually I just want the first 20 characters, which are all digits.This file contains several millions of records.

I have an old number, for example OLDNUM = 25465465133654785956, I need to find out if the OLDNUM in the file or not.

I try to read a whole record and use SUBSTR to get the first 20 characters, and then compare these two values.

The Clist program abended with 588 error code. Because of some records contains the characters: OTHER THAN DBCS CHARACTERS FOUND IN A DBCS STRING

I can not modify the file to delete the records containing the CHARACTERS. I have to modify my clist program so that it can process these records.

Here are my codes:



Because the records may contain some special characters, such as: < & ^ * > , some other clist errors may happer:
900 :Single ampersand was found.
860 :Multiplication error - character data.

Does anybody let me know how to only extract the first 20 characters regardless of the rest?

This file contains several millions of records.

CLIST is not the best tool for such a task,
meditate on different tools approach,
ISPF searchfor or a <SORT> approach ( the products are certainly available)
or ( if installed ) FILEAID or FILEMANAGER

Thanks enrico-sorichetti, however this is part of a big project. Not just this small task.
We will use Panels to ask the user input the number, and then do the validation. If ok, then do something else. So still need CLIST to control the whole process.

Is that possible to use SORT in the clist to do the validation? If I use clist to submit a jcl to do the validation, how clist get the return code from the JCL?

I am not good at Clist, Does anybody have some sample codes? Thanks!

however this is part of a big project. Not just this small task.
I am not good at Clist, Does anybody have some sample codes? Thanks!
So still need CLIST to control the whole process.

since as You say is a big project,
1)You should be more careful about the choice of tools!
2a)Your organization should make sure that the skills are available
2b)these are help forums, not do it for me
3)no You do not

nowadays CLIST is the wrong choice for scripting anyway , REXX should be the first choice
whether You like it or not!

ISPF libraries contain a few samples on how to invoke the search for utility for a REXX script

CLIST is not the best tool for such a task,

That is an understatement. Arguably, it is the second worst tool for such a task. The worst tool is if you print out your file and check each paper manually. </humor>

This file contains several millions of records.

Reading and checking each record is not well suited for rexx nor clist. I suspect that you will find that it takes several minutes for each search.

You did not say how frequently you want to check the file or how many people are doing this, or if there will be updates to the file. Consider REPRO'ing your file to a key sequenced indexed VSAM file and writing an assembler program to find the record in the VSAM file (returning RC=0 or RC=8). The indexing will vastly reduce the amount of i/o that will be performed.

And from your Big Program, call that assembler program as needed.

Pedro is dead on. This is not an appropriate task for any language that is a scripting language. I suspect the manager type that dreamed this up came from a Unix/Linux or toy machine environment where scripting is a more acceptable solution, whether it's appropriate or not.

I'm not so sure the idea of creating a VSAM data set using the data area that's being searched for as the key is such a grand idea, either, unless you plan to do thousands (or possibly just hundreds) of these searches. One problem that was glossed over is the possibility of duplicates.

In my opinion, if you must do this search a small program in a true compiled language (that excludes "compiled" Rexx, by the way) is probably the best solution.

If this is a really big file, then (as has already been noted) any process that relies on reading the whole file for any search is going to be slow and inefficient, and using a scripting language is not going to improve the situation. (steve-myers - even on a big *nix box, grepping a file of this size isn't going to be practical, but your point is well made)

How often is the file created versus how often do you need to scan it looking for records? What do you want to do with the record once you have found it? The VSAM solution might actually be workable if the file was created overnight - you could just define the VSAM file with a key of the first 20 bytes and use a program to access it. Assembler obviously works, but would be my last choice from a maintenance aspectas there aren't many folks around these days who can code assembler VSAM access (although using LSR pools it would be blindingly fast).

Have you considered loading the file into a DB2 table with an appropriate index? There is a simple enough REXX interface to DB2, and you could use the database to do all the heavy lifting for you - finding the record would be a simple SELECT * FROM mytable WHERE reference_number = ?".