"Commercial" code isn't magic. There are date and time API's in the CEE*
("common execution environment") world but many programmers don't know
about them--and they are documented. SQL has many date and time features.
In the System i world, a program written in one language can call/invoke a
program written in another language; "commercial" app developers write in
ILE RPG, CLLE, C++, and COBOL (maybe some MI but I think that's mostly
supplanted by C++) just like the rest of us. There are hundreds of
published features and functions available through API's (and SQL); none
require secret API's.
Moving into Luke Skywalker mode ("I used to bullseye womp rats in my T-16
back home"): IMO, the code to support user- and job-specific time zones
would not be hard to write. The hard part: coming up with a useful and
extensible feature set, a good technical design, support for HLL and SQL
apps, and easy-to-understand documentation. The hardest parts: funding the
project, designing a solution that doesn't upend your current app designs,
designing a solution that doesn't negatively affect other unrelated
applications (example: your app runs hosted in a partition with other
unrelated applications; this means you can't set the system time to UTC
because it would affect other hosted applications), and finding a couple of
good customers to give the product credibility while working in a
production environment. If you have to add lots of code to each
application program, it's not a good design. I implement my "system" API's
by adding to the binding directory, inserting a /COPY, and then calling
individual procedures as needed; a good commercial app should make it that
easy. It *is* all about design, and remember that weeks of coding can save
a few hours of planning. End Skywalker mode.
The thing about undocumented API's: that's Microsoft on the brain. MSFT
was guilty as charged and did it for many reasons (some nefarious, some
because they didn't have the time, others because they changed direction).
On the i, if an API isn't documented, it's not for you or me. An
undocumented API may change from release to release, thereby potentially
breaking your app; this is what caused 3rd party developers heartburn
during the early days of Windows. [Sidebar: IIRC, SNDSMTPEMM, at initial
announcement, was pretty close to being undocumented!]. Another reason: if
the secrets of an undocumented API were shared with some commercial
developers and not others, the lawyers would have a field day (notable
exception: pre-release collaboration with IBM under an NDA).
"CEE" you later.
On Wed, Nov 12, 2025 at 1:02 PM Gavin Inman <midrangelist@xxxxxxxxxxxxxx>
wrote:
If there is a commercial way to do it, there must be an API to use.
Anyone know what that might be?
On 11/12/2025 9:07 AM, Troy Foster via MIDRANGE-L wrote:
There is a paid way to do this Inpro International(
www.inprointernational.net/).
We use it.
Power i are not (yet) mainframes. The only solution to it as I see is a
separate partition, too expensive just for getting that. Unless....the
foreign users are a lot and the business does have a budget.
JS
El mié, 12 nov 2025 a las 5:57, Jim Oberholtzer (<
midrangel@xxxxxxxxxxxxxxxxx>) escribió:
<snip> That would mean every user should "see" their jobs like an
exclusive partition around timestamps.</snip>
IBM already did that with something called CMS. Ran under VM on the
mainframe. Don't see much if that around anymore. Maybe a reason is
session timestamps are not that big a deal?
Jim Oberholtzer
Agile Technology Architects
--
--
--
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@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
midrange.com
