2) what exactly do you have on input? You can print a separate output file, or specific field(s) of it, without any conversion applied (maybe, convert to HEX for clarity)
You are trying to guess, and to assume too many things. It would be useful to verify each of your assumption by printing the actual values. In that case, highly likely, you would find the reason of your issue by yourself.
117,4 - Is this the right offset? - Yes it is right i am sorting data from IDCAMS DCOLLECT output. below is the Dcollect record output structure interpreting dcollect output
112(X'70')
CHARACTER 4 DCDLSTRF DATE LAST REFERENCED (yyyyddd F)
sorry I am not getting "1)learn how to use code tags" what is the code tags that you are referring.
Regarding the output i just typed one line to show how the output looks like as i couldn't copy nothing fake. I provided the complete job i ran and the sample output of how it looks like not sure why you say this is fake information.
Thank you, That worked( I actually tried PD for YYYY-MM-DD format but it didn't worked as expected so assumed it won't work for Julian date as well).
Below are the ones that i tried
Code:
HEADER('LASTREF') ON(117,4,PD,E'9999-99-99'
Code:
HEADER('LASTREF') ON(117,4,DT1,E'9999/99/99'
Code:
HEADER('LASTREF') ON(117,4,DT3,E'9999-999'
Julain format is what I need and using the PD format it is reporting as expected.
Thanks for your help.
The major conclusion: there is absolutely no reason to ask questions like this one at the forum. The demonstrated problem is a normal everyday issue which can be easily solved by minor testing of your code, and comparison of results. This is a classic job for any software engineer (which he is paid for).
The reason I brought it up is to find out why the DT1 and DT3 formats are not reporting as expected, Thanks for the support.
In your case, DT1, and DT3 formats are not reporting as YOU expected, but they are definitely reporting as the DEVELOPERS OF ICETOOL expected.
In all cases like this one, a typical recommendations must be, as I mentioned:
1) print or display EXACTLY the content of your input fields under question. Do not rely on your hidden “assumptions” or “guessing”
2) try to use several variants of input values for testing
3) try to use several versions of your conversion/processing code, or parameters
4) print or display EXACTLY the content of your output fields, for EVERY version of your conversion code, and for EVERY variant of your input data.
5) compare all printed results, and try to use a sort of common sense to understand: why your original results are not what you expected? In most cases the reason would be - misunderstanding of the description taken from a manual (which in turn are often quite messy, or even misleading, or using a terminology different from the one you are familiar with)
6) even if you did not understand the reason of your issue, it always makes sense to ask your question at the forum, INCLUDING ALL THE PRINTED RESULTS mentioned in 1-5.
The major conclusion: there is absolutely no reason to ask questions like this one at the forum. The demonstrated problem is a normal everyday issue which can be easily solved by minor testing of your code, and comparison of results. This is a classic job for any software engineer (which he is paid for).
I disagree to this. Everyone takes learnings on Mainframes in different ways based on the experience level and this is one of the way to do it and I don't see anything wrong in it. Over a period of time when one gets 20+,30+,40+ years of Mainframes experience then they won't be asking these type of questions.
Second , TS has tried but did not work and hence posted on this forum ( as expected) and got the solution as well, End of the story. Your Advise is good to follow but can not be always a pre requisite before posting a quesiton on this forum.
