V4.4.2

[4.4.2] - 2022-12-23

Added

• None Nothing added

Changed

• None Nothing changed

Fixed

• Fix I caused a regression with Viya 3.5 from having to rework authentication due to chages in
  Viya 4. This fixes that and requires no coding changes. This fixes issue #500

• Fix I fixed another issue with the same reworking as above that presented in another specific
  case. This fixes that and requires no coding changes. This fixes issue #503

Removed

• None Nothing removed

V4.4.1

[4.4.1] - 2022-12-01

Added

• Enhanced I added a number of security type enhancements to the repo; none of which has to do with
  how the code works, and requires no code changes. This was all based upon OpenSSF best practices for
  Cybersecurity regarding open source repos. You can see the new badge on the home page: in the README.

Changed

• None Nothing changed

Fixed

• Fix I made a fix to the IOM access method based upon a vulnerability scan from the newly added SAST
  tool that was part of the Security based enhancements added to the repo. This requires no code changes.

• Fix I made a fix for the SAS_kernel, which depends upon SASPY to do the work interacting with SAS.
  There was a breaking change in the Kernel interface regarding prompting. I fixed it so it still works
  with previous versions (of course; no breaking changes for my customers!), as well as with the new api.
  This fix addresses SAS_kernel issue sassoftware/sas_kernel#83

Removed

• None Nothing removed

V4.4.0

[4.4.0] - 2022-11-14

Added

• Enhanced @rayewright added a half dozen more ML procs to the sasViyaML package for Viya.

Changed

• Enhanced Added documentation specifically identifying datatype conversions between SAS data Sets
  and Pandas dataframes; both directions. This was added in the AdvancedTopics section of the doc and the other
  couple parts of that section also about data movement were moved to all be contiguous and thus make all more
  clear. No code changes, just documentation.

• Enhanced Added documentation for the IOM access method regarding authentication. The Configurations
  section already specifies how to authenticate with different means, but now there's a part of the doc explicitly
  identifying which methods are supported and the one method that is not supported; SAS Token Authentication.

• Enhanced @andyjessen cleaned up some links in the doc that were still referring to master instead of main
  for the branch they linked to.

• Enhanced The HTTP access method, to Viya, requires a valid authentication token be passes to every request.
  This token is acquired when calling SASsession(). This token had been set to expire after 10 hours. Viya has been changed
  to have these tokens expire after 1 hour, so to keep this from causing problems for SASPy sessions, which can be
  interactive and last much longer than one hour, I've added support to reauthenticate and get a new authtoken prior
  to the current one expiring. This happens as long as the SASsession object is valid and connected. There are no coding
  changes required in user code. This should all just happen under the covers with no requirements on the user or program.
  I did add a method for explicitly refreshing the authtoken, but that should not be required at any time. But, it may
  be of use as a diagnostic in the field if there are ever issues reauthenticating. So, again, no code changes required.

Fixed

• None Nothing fixed

Removed

• None Nothing removed

V4.3.5

[4.3.5] - 2022-10-17

Added

• None Nothing Added

Changed

• Tweak Had a PR with fixes to Doc; mostly typos and consistent use of terms. Also fixed a broken link.

Fixed

• Fix Fix for leaked resources. The pipes that are created between subprocess and Python were not being
  released prior to subtask termination. This results in a resource leak that is identified when running with
  settings that report these issues. I clean this up in both the IOM and STDIO access methods, they each had
  similar concerns. No programming changes required.

• Fix Fix for issue 487 where, in the df2sd() method, there was data that contained the data step
  termination string which resulted in the data step, which was retrieving the data and writing it to the SAS
  data step, terminating prior to processing all of the data and then SAS would take the rest of the stream
  as SAS code, which fails miserably and consumes memory with all of the errors going to the log. It also
  terminates the connection to the client. I've also added code in the java client to catch this kind of
  failure so it wouldn't hang, like it was. So this is addressed and fixed in this release, and requires no
  programming changes.

Removed

• None Nothing removed

V4.3.4

[4.3.4] - 2022-10-05

Added

• None Nothing Added

Changed

• Tweak I'm moving to a newer dev environment; newer OS version, newer Python version, and all the newer modules, ...
  Using Sphinx to build the doc fails with this newer version, so I've had to tweak and reworks things to get the doc to build
  with this newer version of evrerything. So, there were a lot of minor adjustments pushed to accomodate this. It's all working
  and, of course, requires no programming changes due to any of this. A plus is that now the index, shown on the left side of the
  page, finally has links to the individual methods, in the API section of the doc! This is a welcome enhancement.

Fixed

• Fix Fix for issue 480 was in the last version. That issue was a discrepency with how Python on MacOS works compared to
  any other operating system. I've had to implement workarounds for Mac Python for a number of issues in the past. This release
  has a couple more workarouds for problems with the Mac version of Python too. These are in the IOM access method, whereas the
  last versions fix was in the STDIO access method. Again, no programming changes required.

• Fix All of the analytic methods correspond to some SAS Procedure. Each method is one analytic PROC. The code that generates
  the PROC syntax for all of tese methods is a bit convoluted. While fixing the method signatures for the doc building issues,
  last release, I noticed that if the USER librfer is assigned, then none of the analytic method work. I've worked through that code
  to resolve this, so in this release, that problem is fixed and they all work as they should have regardless of is USER is assigned
  or not.

Removed

• None Nothing removed

V4.3.3

[4.3.3] - 2022-09-26

Added

• None Nothing Added

Changed

• Tweak The analytic methods all take a SASdata object, or the name of a SAS dataset (str). The method signatures used
  ['SASdata', str] to represent either/or, not a list. The current Spinx doc build no longer allows that and doesn't generate
  signatures, so I hade to replace the [] with (). No programming changes, just a tweak to get the doc to build right with the
  newer version of Spinx.

Fixed

• Fix Fix for issue 480. No programming changes required.

Removed

• None Nothing removed

V4.3.2

[4.3.2] - 2022-08-12

Added

• Enhanced Added another configuration key in the SAS_config_options dictionary for providing an override for the ODS type.
  This was already available tochenge as an attribute on the SASSession object, but in a SAS_Kernel notebook, there was no
  way to do that. So I added style to the config so it could be set when using SAS_Kernel in Jupyter.

Changed

• Tweak There are a number of methods which require querying SAS for information which is returned in the LOG and then
  parsed out by SASPy. If there's something wrong on the SAS side and somehow the information isn't in the LOG, it can cause
  exceptions in the method. I've added code to catch these exceptions and just handle them like an error so processing can
  continue. The methods will now just fail and you can look at the log to see what the problem was.

Fixed

• Fix There were a couple methods on the SASdata object which, when returning Pandas results, didn't specify the
  work library explicitly on the retrieval step. So if there was a user libref assigned, it would look there instead of
  work for the data and not find it. All better now.

• Fix In the IOM Access Method, the Java IOM Client code does some of the transcoding between Unicode and whatever the
  SAS Session Encoding is. If there is a transcode failure, it throws an exception which terminates the Java process and the
  SAS server process. I added code to catch this trye of failure, in my Java code, and return the failure, keeping the Java
  and SAS processes (and SASPy) going. I don't have a way to change the behavior of the client code, so catching this and
  keeping things running are what I can do, which is better than it all terminating out from under SASPy.

• Fix And the big fix for this release is for df2sd() and sd2df(), fixing problems when the record length is larger
  than the max (32767) for the infile statement, which is used in the SAS code for these methods. This caused problems in
  df2sd() if the row length was larger than 32767. There was also an issue that could be hit w/ regards to this in sd2df()
  also, so that's addressed with this fix to. This is for all 3 access methods; STDIO, IOM and HTTP.

Removed

• None Nothing removed

V4.3.1

[4.3.1] - 2022-07-06

Added

• Tweak Thanks to our graphics design dept for creating a cool logo for SASPy! I added the graphic to the main repo
  page (in the readme), and to the saspy-examples repo and to the documentation page. This has nothing to do with the code
  or functionality; just a cool logo for SASPy!

Changed

• Tweak Changed the prompt in the IOM access method which asks for userid/pw to use 'OMR' instead of 'IOM' since the
  configuration keys for user/pw are omruser/omrpw not iomuser/iompw. This has no effect on the code or processing, just
  changing the text of the message to better correlate with the right acronym.

• Tweak Made a change in the java IOM client code for upload/download to propagate and return the error if there was
  a failure during the data transfer phase. Never seen this case happen before, but if it does it should be more clear.

Fixed

• Fix Added a check in the HTTP access method in upload and download to see if the status for the HTTP call was an error
  and return the failure. Previously it didn't check and just returned success.

• Fix Made a change in the HTTP access method's download method to read/write chunks of the data instead of the whole
  file to keep from running out of, or using excess, memory in the Python process.

Removed

• None Nothing removed

V4.3.0

[4.3.0] - 2022-05-17

Added

• New Per a user request, I added the ability to use sshpass with the STDIO over SSH access method.
  This allows you to authenticate with user/pw instead of having to use rsa keys (passwordless shh). There
  are now two new keys (see the doc) for providing the path to the sshpass executable and the parameters to use.
  The ssh key and other keys for this configuration stay the same.

Changed

• Enhanced The sd2df methods require multiple interactions (code submissions) to the SAS server and if any of these
  intermediate steps fail or have some issue, then the method invocation fails. But, I wasn't catching these intermediate
  problems which could cause non-obvious exceptions and tracebacks which were confusing. I've added code to catch failures
  for these intermediate steps and throw a more clear exception if that happens. Nothing about how the methods works has
  changed, just better error handling.

• Enhanced The code that checks for an 'ERROR:' in the log and issues a warning to alert you to look to see what the
  error was, wasn't only looking for it to start in column 1 of the log. So, it could pick up 'ERROR:' in a comment in the
  code or anywhere in the log. I've enhanced this to limit false positives by only flagging 'ERROR:' starting in the first
  column of the LOG.

• Tweak Fixed a typo in an error message.

Fixed

• Fix The COM Access Method had a bug where the encoding was being used to transcode HTML results returned to
  SASPy when it shouldn't, since the HTML results are already utf-8. Other code paths retrieving data from SAS did need to
  use the provided encoding for transcoding from SAS Session encoding to utf-8. So, this one path was changed to not try to
  transcode the HTML results. This was a fix for issue 454.

Removed

• None Nothing removed

V4.2.0

[4.2.0] - 2022-03-22

Added

• None Nothing Added

Changed

• Tweak If the initial connection to SAS (a SASsession) fails then there will be a failure error provided, but there
  is also an exception thrown in subsequent code, trying to submit some of the initial code to gather info about the
  session. This was subordinate and inconsequential, yet was confusing and needed to be addressed. So, in this release, there
  is a specific exception being thrown instead of the one that happened to be thrown, which makes the problem more clear.

Fixed

• Fix There was an issue opened for the STDIO Access Method where if the code being submitted was longer than 128K,
  SASPy would deadlock with SAS due to both being single threaded and the way Pipes work; trying to flush STDIN would block
  in SASPy because SAS was blocked on writing to STDOUT/ERR, so they would both deadlock, not being able to read off of the
  other Pipes. I reworked how submit works in STDIO, so that there's a blocked amount of STDIN sent before trying to pull off
  of both STDOUT and STDERR, iterating till done, to circumvent this behavior. That works great, but it caused issues with
  ATTN handling that I support in that Access Method. I needed to rework that to compensate and it's handling it much better.

Removed

• None Nothing removed