hi!
I have a need to run ARSDOC GET to get the 'most recent' version of a report. I don't see an option for this, so I have come up with a couple ways to do it:
1. First run a QUERY (sorted), use the results of the query to get a REPORT_DATE and then run an ARSDOC GET with that date as criteria.
This would totally work but, I would need to do that programmatically and I will be turning this process over to others, so the simpler the better.
2. Running an ARSDOC GET -L 1 (limit 1) actually does the trick because the reports are sorted in descending order and the '-L 1' limits it to one report only. I always get the most current report. So that works, BUT when I use that I get
ARS6055E A maximum of '1' hits(s) were requested for this query. The number of matching hits found was '1982'.
and ARSDOC returns 768.
It's odd that this is an "error" because I specifically asked for '1' result, and that's what I got. The rc768 would get flagged by the scheduling software and force an abend. I could tell the scheduler to ignore the rc 768 but rc 768 could happen for other reasons which need addressed, and SHOULD abend.
Has anyone come up with a simple way to get "most current report" that is not either of these two? :) I thought about putting in an enhancement request to IBM to ask them to not produce an error/rc 768 for the second case. (I know that would take time even if it were acceptable. )
I reached this post via a link from a CMOD Wiki page relating to arsdoc Return Codes.
When I run a similar command, I receive RC 3, not 768. The main differences:
a. I run on a Windows cmd client, a Windows 2022 server, and I use CMOD version 10.5.0.7 (on both ends)
b. I run arsdoc QUERY, not GET:
arsdoc query -h ondemand -f "myFolder" -i "WHERE field1='value1' AND field2='value2'" -u LILOLDME -p C:\Temp\my.stash -L 1
Maybe they changed the return code in a later version, or maybe it is different whether you run GET or QUERY?
I know the z/OS versions sometimes are quite different, and that they may not be in sync with the Multiplatform versions, but it would be interesting to know; If you run the same again, do you still get the same RC? Or has it indeed been changed.
@Admins: please don't ban me for typing the "W" word in a z/OS sub-forum! ;)
Hi Grahaj & Lars.
There's no real standard for what the various return codes mean, it's up to the developer to define them for each utility.
I'm guessing that in this situation, I'm guessing both 3 and 768 are warnings. I'll test out this specific situation and see if I can narrow it down. Both 3 and 768 are peculiar numbers, as they translate to 0000000011 and 1100000000 in binary, so the return codes might be different based on the 'endianness' of the CPU/OS.
-JD.