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

V4.1.0

Added

• New I added a new method, lib_path(), off the SASsession object which returns a list of the path(s) for
  the libref. Depending upon the engine, 'path' may mean different things. For BASE engines (Linux/PC), it's a directory
  or multiple directories if a concatenated libref. For database engines, it varies; may be the database name that you're
  connected to. On MVS, it could be then name of a bound library file, or a linux directory path.

Changed

• Tweak In the submit method of the HTTP access method, for results='text', I removed extraneous empty lines before
  and after the code. These resulted in extra 'return's being submitted. Removing these allows correct behavior when using
  saspy to interactively debug (w/ pdb) PROC PYTHON code. With the extra 'return' before and after the command you tried
  to submit, pdb executed extra commands. Now it's 1:1 with clean debugging using submit().

Fixed

• None No changes

Removed

• None Nothing removed

V4.0.0

Note the Major release number being incremented! This means there is a breaking change in this release (yes, the first time so far).

Also note the addition of the CHANGELOG.md file in the repo, where all release changes will be logged, starting with this release!

The breaking change is as follows. sasdata2dataframe (sd2df or other aliases), has returned None when the SAS Data Set provided doesn't exist. Of course, trying to use that as a dataframe results in an exception. But, if you coded a check for this and conditionally didn't use it, then this change will break that code. A FileNotFoundError exception is now thrown, as that's the appropriate Pythonic thing to do in this situation.

If you happened to code this:

df = sas.sd2df('table','libref')
if df is None:
   # do something because the data set wasn't found in the SAS session

Then you would need to change that to:

try:
   df = sas.sd2df('table','libref')
except FileNotFoundError:
   # do something because the data set wasn't found in the SAS session

There is another change that I had to make for the log4j problems. If you recently used the new 'log4j' configuration key in the pervious release, you may need to update the value. SASPy V3.7.8 had log4j 2.12.2 and 2.16.0 jars, but now 2.12.4 and 2.17.1 are included instead.

So, if you happened to use log4j='2.16.0', you need to change that to log4j='2.17.1' in this release. Be aware that this can continue to change if more vulnerabilities are found and fixed in log4j.

Note also that none of the vulnerabilities are exposed by SASPy as it doesn't use log4j, so there's no actual problem with these regardless of their version.

V3.7.8

This release addresses the current issues with log4j by providing both the fixed version (https://logging.apache.org/log4j/2.x/index.html) of log4j that still supports Java 7, saspy's minimum version of Java, using log4j 2.12.2, but also includes the 2.16.0 versions which you can choose to use, if you want and have Java 8 or higher. There is a new configuration definition key, 'log4j', that you can provide in either your config definition or on the SASsession() method (using 2.12.2 is the default - you don't need to provide this unless trying to use 2.16.0). This is documented in the SASPy V3.7.8 documentation under configuring the IOM using Java section.
Note that SASPy doesn't expose any log4j vulnerabilities, regardless of the log4j version, because it doesn't use or even initialize log4j. But, having these version in the deployment will mitigate security scans and 'false positives'. There is more discussion on all of this in the #429 issue. Feel free to read more there, an respond if you want or have any other questions or concerns.

V3.7.7

This version updates the log4j jar versions to patch the security issues reported in the last few days.
The details are found in #429.

Note that this change now causes the minimum Java version to move to Java 8, from the previous minimum of Java 7 (log4j version 2.12, which is what saspy included until now, was the highest version still supporting java 7). Also note that saspy does not expose any of the the log4j vulnerabilities, so it's not necessary nor required to move to this version. None of the known, or still to be found, log4j vulnerabilities are exposed by saspy because it neither uses nor even initializes log4j, so no logging is done via log4j; neither internal nor any containing user provided content.

V3.7.6

This release just has 2 fixes in it, from the previous version. Fixes for issues #421 and #422.