Creating JSON with DFSORT
MartinPacker 11000094DH Visits (1461)
This post is yet another spin off from the residency I'm on in Poughkeepsie.
But why would a residency on Batch Performance concern itself with JSON (and indeed XML, which I've also written about in the Redbook)?
The reason lies in the word "modernisation". This actually works two ways:
Now obviously not all batch jobs want modernising or cloning. But some in an installation probably do.
So below is a simple example of using DFSORT to create JSON from SYSIN. Consider the following JCL:
On my system it produces:
If you put that through a JSON validator, such as JSONLint it is reported as clean JSON. (This particular service reformats it prettily as well.)
There's a trick here, though, that's worth describing:
All the interesting action is in the INREC (could've been OUTREC or even OUTFIL OUTREC) statement. This has three IFTHEN clauses (or stages if you prefer):
I say "trick" but this is just the standard "treat each record according to its characteristics and through multiple stages" approach you can take with DFSORT IFTHEN.
In any case it produces 1 line without a comma and the following ones with a comma. And JSON rules are satisfied.
By the way you might be wondering why the values are capitalised or have trailing spaces. This is actually preserving what was in the original records (in in-stream SORTIN). You can certainly take trailing spaces out but it needs a little more work. Semantically both belong in the output data, of course.
And if you insist on taking trailing spaces off the lines - as opposed to out of the items - you can always use DFSORT's VLTRIM.
I think it looks a little odd to have the separator commas at the beginning of the lines. But I don't know of a way in DFSORT to test for the last line - to avoid placing a comma on it. If you can think of a way let us know.
And yes it would be nice to breathe new life into old data.
And - below the line - is a brief discussion on JSON itself.
which would - in a browser pop up a message box with "ALPHA" in it.
You mightn't want to do that as you can end up executing arbitrary code. So direct assignment should only be used where you can trust the JSON. Which is why people tend to use libraries to parse it - and the good ones don't do direct assignment.
People like JSON because it's easy to generate, less verbose than XML, and now has a lot of ways of processing it. What's not so good is that there is no notion of things like namespaces and schemas - so perhaps not so good for "Enterprise". And it doesn't have transformational tooling like XSLT. But it's very popular.