IBM Mainframe Forum

Hi all,

When i copied records from one VSAM file to Physical seq file using IDCAMS utility, i could see some invalid (non-display) characters
in the PS file. Those were identified to be X’05’ and X’3F’. but we dont want it to be present in the PS file.

VSAM(KSDS) file was updated by a batch program and the VSAM records has redefine statements. here is the layout

01 WS-REC.
05 WS-KEY.
10 WS-NUM PIC X(10).
10 WS-DT PIC X(08).
10 WS-SEQ-NUM PIC 9(05).
05 WS-DETAILS.
10 WS-PROD-DETAILS PIC X(210).
10 WS-CNT-DETAILS REDEFINES WS-PRODUCER-DETAILS.
15 WS-EXT-NUM PIC X(03).
15 WS-EXT-NT-NUM PIC X(05).
15 FILLER PIC X(202).
10 WS-SUB-CLI-DETAILS REDEFINES WS-PRODUCER-DETAILS.
15 WS-CD PIC X(03).
15 WS-NUM1 PIC S9(4) USAGE COMP.
15 WS-GF-NUM PIC S9(4) USAGE COMP.
15 FILLER PIC X(203).
10 WS-SUBGT-DETAILS REDEFINES WS-PRODUCER-DETAILS.
15 WS-B-CD PIC X(01).
15 WS-SGA-PCT PIC S9(5)V9(4) USAGE COMP-3.
15 WS-SGA-R-PCT PIC S9(5)V9(4) USAGE COMP-3.
15 WS-SGA-IN PIC X(09).
15 FILLER PIC X(190).
05 FILLER PIC X(50).


all fields were initialized and populated and written into VSAM file.

so how do we get the clean Ps file ?... pls advice me on this

Hello,

Suggest you look into why these values are in the data. FWIW x'05' is a tab character (iirc) and actually is not invalid if the data is ever downloaded for use in a spreadsheet or database load . . .

Suggest you clean up the master file (if it is decided that these values really are invalid), fix the code that updates the master file so that "invalid" values are no longer allowed to be input, and the ps file will be correct when created.

Comp/comp--3 fields may have all sorts of "invalid values" to someone looking at the data in character mode.

Thanks for the prompt response,

these values are greatly invalid as we are FTPing the PS file to server. Actually we have these below lines in that batch pgm

INSPECT WS-REC REPLACING ALL X'0D' BY SPACES

INSPECT WS-REC REPLACING ALL LOW-VALUES BY SPACES

INSPECT WS-REC REPLACING ALL X'25' BY SPACES

these steps were included just before write statement... so from ur advice i should replace all the X’05’ and X’3F’with the spaces.

Correct me if i am wrong.

15 WS-NUM1 PIC S9(4) USAGE COMP.
15 WS-GF-NUM PIC S9(4) USAGE COMP.
15 WS-SGA-PCT PIC S9(5)V9(4) USAGE COMP-3.
15 WS-SGA-R-PCT PIC S9(5)V9(4) USAGE COMP-3.

Fields which are COMPutational of any sort should not be in records which are transferred to other systems where the transfer involves any sort of "translation". Going to your server, or on your server, I assume the data is translated from EBCDIC to ASCII. Any content in these fields is then open to irrrecoverable scrambling.

Take the "05" in EBCDIC, This is a "control code" HT. HT in ASCII is "09". So the 05 gets translated to 09,

Now, the thing is, the 05 could be part of any of those fields above, where it would mean something, After the ASCII translation it will no longer mean the same thing, it will have been corrupted.

No files you are transferring to non-mainframes should contain non-DISPLAY fields.

The code you point to that is doing "fixes" with INSPECT is rubbish. It will also be destroying parts of those four numeric fields. the "0D" is Carriage Return and the "25" is Linefeed. They are coming from somewhere to get into your record. If you don't want them, they should be excluded before getting into the record.

With the low-values, again, if they are occuring in non-display fields, fix the source, not splodge it about at the end, Fix the source does not mean do the INSPECT earlier, it means find out why low-values are there and fix the problem (raise the paperwork to complete the task),

So no, you should just include any extra values in the block of INSPECTs, they should all be removed and the work done properly.

These users thanked the author BillyBoyo for the post:

Arun Bv (Mon May 14, 2012 12:00 pm)

Hello,

As i mentioned previously:

Suggest you look into why these values are in the data.

From the little posted, there is no way we can say if the values are valid or invalid. . .

Before just changing them, you need to understand what the content should be.

How will this new ps file be used? If it is to be downloaded and used on a pc or unix system, it looks like you have additional "opportunities".

These users thanked the author dick scherrer for the post:

Arun Bv (Mon May 14, 2012 12:00 pm)

After consensus, here we changed the comp fields to full numeric (i.e., WS-NUM1 PIC S9(4) USAGE COMP to WS-NUM1 PIC 9(4))

when we viewed the PS file with hex on we found these X’05’ and X’3F’. hence we consider these as invalid.

so i dont think any problems after the declaration change and removing the invalids using INSPECT before writing into the file.



PS file has values extracted from the tbl and will be sent to server and will be viewed in the windows EXCEL.

i feel issue resolved

Did you change the COMP-3 fields as well, you should have done.

Did you confirm that your COMP fields were actually unsigned?

If you still have invalid data after the "comp-3" change, you still have to find out how it got there, not just remove it.

These users thanked the author BillyBoyo for the post:

Arun Bv (Mon May 14, 2012 12:00 pm)

yes all the comp fields were changed after analyzing whether any impacts

now we r not getting any invalid data in PS file..

So you never had any invalid data in the first place - just data in packed decimal or binary format that you wanted in zoned decimal format.

Now we're happier, Arun BV. Thanks for letting us know.

Now you know that one person's "invalid" is another person's "perfectly OK by me until you screwed it up"

There is never a good reason for "we didn't know what it was so we changed it to <x>". You always have to find out what it is before deciding what to do with it. Good luck,