I didn't mean to imply dishonesty by my comment preferring the SQL services over many of the APIs. No offense to the poster I was replying to. And I can see how it could have been taken disparagingly and I apologize.
I only am saying that once these services are out there, and a version is available for all "supported" levels of the operating system, then why would anyone suggest using the API's?
Don't get me wrong, me and others where I work have used many APIs and are quite proud of our use of them. However it is simply not cost efficient for someone, such as the original poster, to write something using an API when it can easily be done using a single line of SQL. Coding error data structures, and PROPERLY handing looping can also be an issue when learning APIs. Who has not been enlightened by some of the knowledge passed on by people like Barbara Morris about how using common bad techniques in looping on an API can sometimes run into seemingly inconsistent errors?
I'm all for recommending an API if a service doesn't currently support what someone is requesting. I recently had to begrudgingly admit that the record format name may not currently be provided with any of the existing services and even recommended a possible record format needed by a particular api to get that.
But recommending an API over a service, or even mentioning one as an alternative, should be reserved for those cases where someone states they have a reason for doing so, like supporting 6.1.
To me, even mentioning an API when there's a service available is akin to replying to a question where someone asks "how do you add two numbers in RPG" with "we do it by calling this MI instruction..."
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Jay Vaughn
Sent: Monday, March 11, 2019 9:41 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: get cpu%
just as you would do a wrkactjob and view the cpu%...
is there an sql to retrieve that value?
tia
Jay
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
