Repository navigation
Long-standing inconsistencies with the z/OS log API request handling - #462
Merged
Merged
Conversation
frankgiordano
marked this pull request as ready for review
April 25, 2026 03:30
Refactor URL building for z/OS log command to use a list for query parameters. This change improves clarity and maintains optional parameters. Signed-off-by: Frank Giordano <giofr01@yahoo.com>
Updated Javadoc comments for the time parameter to clarify its usage and format. Signed-off-by: Frank Giordano <giofr01@yahoo.com>
Signed-off-by: Frank Giordano <giofr01@yahoo.com>
frankgiordano
changed the title
Signed-off-by: Frank Giordano <giofr01@yahoo.com>
Signed-off-by: Frank Giordano <giofr01@yahoo.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR fixes long-standing inconsistencies with the z/OS log API request handling.
The z/OS log request URL is now built more accurately, and the SDK no longer sends a client-generated
timeparameter unless the caller explicitly provides astartTime.Previously, the SDK always added a
timequery parameter when calling the z/OS log API. WhenstartTimewas not provided, the default value was generated on the client side using the local/runtime clock. This caused two issues:Additional query parameters could be appended incorrectly depending on the input combination.
The generated client-side time could be slightly ahead of the z/OSMF server time, causing z/OSMF to reject the request with:
Internal testing with formatter as UTC-compatible exposed the remaining timing issue: even a correctly formatted UTC timestamp can still be rejected if the client clock is ahead of the z/OSMF server clock.
The fix now omits the
timeparameter unlessstartTimeis explicitly provided. This lets z/OSMF use its own server-side current time, which avoids client/server clock drift issues and aligns with the documented API behavior.The query-string construction was also simplified by collecting optional query parameters and joining them with
&, preventing malformed URLs when multiple optional parameters are supplied.