Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Detecting non-printable characters 4

Status
Not open for further replies.
M

Member 310024

Guest
Environment: IBM Z series mainframe MVS COBOL/DB2 & MSWXP MS COBOL 2.4?.
I am unload records out of a DB2 table into a TSO dataset.
I then FTP the dataset to a PC.
The problem is that sometime there are non-printable
characters (NPC's) in field that come off the data-base and into the TSO-DS.
Normally I would check the TSO-DS with ISPF TSO editor (=2 option) and if there were non printable chars, there would be a message about using p'.' to find & change them.
I would normally change them to the underscore chjaracter.
I should have mentioned that I convert all numeric data into display format eg PIC 9(9).99- for example, and that the problem is not with numeric format data - it's with NPC's in PIC X fields. If the extract file is relatively small, it's no big deal to use the mainframe editor to do the change I have already described.
(By the way, the the NPC's are not supposed to be present, but getting the O/S company to tighten up their application is not going to happen)
Sometimes I might have over 1M records and it's to big for the editor.
What I need to do is to examine each record after by FETCH and before I load it into the sequential record.
What is the simplest and most generic means of doing this.
My dream would be something like
INSPECT DD-TABLE-FIELD (i.e. the group field containing all the fields of the SELECT/INTO clause).
REPLACING ALL NPC's (ie see p'.' values) BY '_'.
I want to avoid, if I can, having elaborate tables or scans if I can.
If I don't do this, the FTP (that I use anyway) will shift
all characters after the NPC, 1 character position to the left, which in turn means that the subsequent fields would be offset by 1 char posn, meaning the pic('s would now contain non-numeric chars and the pic x's would contain bits of other fields.
So then, when I upload from the PC seq file into the PC COBOL ISAM file, I will get a run time error when numeric data is tried to be loaded into a numeric field.
Thanks in anticipation for any good ideas.





 
01 NPC PIC X(n) VALUE '.....

After converting the numeric data:

INSPECT OUTPUT-RECORD CONVERTING NPC TO '_'.
 
Hi Term,

Webrabbit's suggestion is a good one, but I'd use a constant instead of a variable (NPC) for the npc list, e,g:

INSPECT OUTPUT-RECORD CONVERTING X'000DFFetc' TO '_'.

If a variable is used the Compiler uses a sub routine to perform the data conversion with a lot of added o'head. With a million recs that can be considerable.

If a constant data string is used the Compiler uses one assembler language TR instruction (so I've heard).

Depending on the number of non-prints you're looking for, you may need more than one INSPECT stmt. Check the compiler's Language Reference Manual for what the restictions on the contant length might be. I didn't see one, but there must be



Regards, Jack.

"A problem well stated is a problem half solved" -- Charles F. Kettering
 
Thanks Fella's!
 
If it were done in Assembly, a single TR instruction would suffice, depending on the length of the output record (TR will only process up to 256 bytes with a single instruction).
 
Hi guys,

I like webrabbit's TR suggestion. Others are good but I'm lazy.

Assuming you are FTP'ing from TSO:
You can create your own translate table for the ftp. As the FTP is using a translate table to begin with there is no additional overhead. Just make sure you start with whatever default table your shop is using. (Sometimes the system programmers are using a slightly modified version so check with them). The following DD statement names the translate table:
//SYSFTSX DD DISP=SHR,DSN=
You can copy the dataset to a new name. Edit with Hex On and create any table you need.

Take Care, Nick.
 
Nick's idea is excellent. Never having used FTP from TSO, I was not aware of the translation method involved, nor how easily it could be modified. I was aware that there had to be one somehow, thouigh.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top