×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
I was not trying to open the can of worms of printed output vs alternatives.
-----Original Message-----
From: John Yeung [mailto:gallium.arsenide@xxxxxxxxx]
Sent: Saturday, January 14, 2017 3:46 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: Python on iSeries
On Sat, Jan 14, 2017 at 1:49 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx> wrote:
Hi Justin - I need to hear more - What is the context of your comment?
Do you mean that in your shop, every report is done with O-specs?
I think that is what he means. I think he would prefer to use PRTFs.
Or are you saying we should not be using PRTFs at all?
No one is saying that.
I will still hold that externalizing display and print to DSPFs and
PRTFs was and continues to be going far past internally-described in O-specs.
Well, there's practically no other way to do 5250 displays than with DSPFs. Is there such a thing as an "internally described" display? I know there are the DSM APIs, but few people get trained on those. I think fewer people even know about those than people who knew about Python on the i five years ago.
Anyway, I don't think a reasonable argument can be made that the built-in support for "in-line" screen programming is nearly as strong as the support for in-line spooled output programming. That was a long way for me to say that DSPF and PRTF cannot really be argued on the same terms.
The question of going to other target output is a different one, IMO.
It's a different question, but relevant. In the real world, someone might be trying to make a decision between O-specs and a PRTF, when it could be that their situation would actually be better served if they chose neither.
John Y.
midrange.com
