I want to search this secuential file in order to change the pos 24.
When I try to use this code no expected change happend, but if I delete the this --->(17,1,CH,EQ,X'09') the expected changes do happen, so I think im doing something wrong with the hex search i quoted.
the secuencial file is like this
----+----1----+----2-
¦ & 1211D 0027
(the hex number is in pos 17, the empty space, if I activate the HEX mode, I can see 0)
9
The input file is a secuencial that I converted from a VSAM with REPRO.
------------------------------------------------------------------------
Really I tried to figure out the solution but I cant found it.
There is no need for SORT to previous conversion of VSAM to PS. SORT can work easily with VSAM input.
There might be conversion of RECFM between VB and FB, which also affected field positions. You need to verify the ACTUAL input to SORT, not the original VSAM data if you converted with REPRO.
Joined: 06 Apr 2021 Posts: 123 Location: argentina
Joerg.Findeisen wrote:
What happens when you change (17,1,CH,EQ,X'09') to (17,1,BI,EQ,X'09')?
Also please post this:
Quote:
----+----1----+----2-
¦ & 1211D 0027
in Hex mode and use code tags for that.
Hello, this is not working. I have to say that the buid command I give it a parameter of 24 (BUILD=(1,24,C'3',26,949)) and it correctly change the position at pos 21, (yes, i have to put 24 to change the pos 21)
Joined: 06 Apr 2021 Posts: 123 Location: argentina
sergeyken wrote:
There is no need for SORT to previous conversion of VSAM to PS. SORT can work easily with VSAM input.
There might be conversion of RECFM between VB and FB, which also affected field positions. You need to verify the ACTUAL input to SORT, not the original VSAM data if you converted with REPRO.
Yes, when I see the input in the pos 17 I can finde the empty space and there is the HEX value, but when, as I said, searh in that 17 position it cant find the value searched.
1) absolutely no need for REPRO. Never do things more complicated than they are, if not strictly needed.
2) remains unclear: are the field positions counted keeping in mind the RDW from RECFM=VB, or not?
3) It would be more useful to trace the actual values of ALL involved fields, converted to printable format, rather to guess what they may, or should be equal to?
You need to add RDW +4 bytes to all starting positions in the INCLUDE and retry.
Instead of all these attempts to guess any of possible issues, the standard proven method should always be: tracing all involved data values during the test run
I am not guessing , I have tested yesterday against X’09’ if that’s what you need to know. It’s a simple INCLUDE to work as it works for any VB DS unless offsets are set wrong.
Second TS don’t need BUILD , simple OVERLAY should do. I wonder shouldn’t that be 1,25 than 1,24 to see changes at 21st position?
Please start debugging one INCLUDE condition at a time.
I am not guessing , I have tested yesterday against X’09’ if that’s what you need to know. It’s a simple INCLUDE to work as it works for any VB DS unless offsets are set wrong.
Second TS don’t need BUILD , simple OVERLAY should do. I wonder shouldn’t that be 1,25 than 1,24 to see changes at 21st position?
Please start debugging one INCLUDE condition at a time.
In order to make all these decisions - everyone, in every case, must first of all to clearly trace all the data values used in his own test, before hurrying to the forum and screaming: “Help! What is wrong in my super-excellent code??!!”
