Filtered parse breaks _correlate

[wizardofzos]

Looks like we cannot always 'just' activate the _correlate.. as there can be required other types. For instance, running a parse on users and groups only yields the following:

r2.parse(recordtypes=['0100','0200'])
True
>>> Exception in thread Thread-2 (parse_t):
Traceback (most recent call last):
  File "/usr/lib/python3.10/threading.py", line 1016, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.10/threading.py", line 953, in run
    self._target(*self._args, **self._kwargs)
  File "/home/henri/repos/pyracf/venv/lib/python3.10/site-packages/pyracf/__init__.py", line 339, in parse_t
    self._correlate()
  File "/home/henri/repos/pyracf/venv/lib/python3.10/site-packages/pyracf/__init__.py", line 379, in _correlate
    raise StoopidException("Need to parse GPMEM and USCON first...")
pyracf.StoopidException: Need to parse GPMEM and USCON first...

Maybe not run _correlate if recordtypes is specified? Maybe parse required records regardless of what user specified? Maybe even say goodbye to the selection of what records to parse, as parsing is lightning-fast now anyway?

[rob-vh]

I could remove the exceptions and rely on the existing warnings if unavailable properties are used?

[wizardofzos]

I think....... we could just run with 'just parse everything all the time' ..... just gotta check waht we need to do to keep z/Vm unloads still working (as they have far less recordtypes)

[rob-vh]

Maybe the better approach would be to:

• change the exception into a warning
• change the oh so funny name of the exception while we're at it
• distinguish exceptions into user interaction related vs. environment related, i.e. rely less on the message to convey the nature of the exception

For starters, I added conditional processing as opposed to exception and die in recent commit, to add IDSTAR and EFFECTIVE_UACC into _dataset and _generals, maybe that's the way forward?

[wizardofzos]

This is fixed :)