SPFLite session closes when Minimized

Meshuggenah: Hmm, yes the prod version fails. But my latest test version doesn't - odd, there have been no changes made in that area. For now, turn off the minimize to tray. Or you could try out the latest Beta from the forum, I tried that and it also seems fine.

George

George, recall that Meshuggenah is the same user that evidently had something wrong in the Minimum # of columns field for data shifts. As a new user, it is unlikely he would have tampered with this field himself, as his prior remarks imply that he didn't really know what the field was for, so he'd have no reason to change it.

You know everything about the code, and yet your production version ran into a problem. You would not have entered any fields incorrectly either, except during testing.

This suggests that something is corrupting the system configuration data. Since your own system has this problem, I would recommend doing a field-by-field comparison of the configuration data (some part of your SQLite database) to see if there are any anomalies.

Is it possible that your own production SPFLite that you use on a daily basis provides the "template" for the configuration data for new users? If that were the case, and your SQLite had some kind of corruption, it could get propagated to new users, almost like a virus of sorts.

Just a thought.

I am wondering if some aspects of SPFLite could benefit from a "failsafe" concept. Suppose you could identify certain conditions that you knew would cause problems. Of course, the list of possible problems will grow with time, as you discover new problem conditions. Then, at startup and at profile open time, you would run a "failsafe scan" on important resources. If you found a problem you knew to be an issue, you could have a popup that would offer to do an "emergency repair operation", to fix the problem at least well enough to allow the user to repair the rest on their own.

It's the sort of "fix" that would need to be tweaked over time, as new vulnerabilities became evident.

Again, just a thought.

As I mentioned, fixes "would need to be tweaked over time, as new vulnerabilities became evident." That does not require being a psychic. It just requires keeping a record of problems that users encounter when they are reported.

It is not strictly necessary for a 'solution' to be 'complete'. The truth is, a solution like this will never be literally 'complete', because the code base changes over time, and configuration conflicts may arise from new code - not necessarily from 'corruption' in the CFG per se.

If it is true that CFGMaint already validates the CFG, that must mean you already know how to find issues, because you already have the code to do it in this utility. The work that would remain is to adapt that logic to your base code. Probably not a trivial matter, but not impossible either. If you say you don't want to bother, that I understand, but the idea per se is not unreasonable, if in fact corruption exists as a possibility and evidently has already happened.

Finally, running CFGMaint to export and import is not simple if you don't know how. I personally have absolutely no idea how that thing works, and I would rather reinstall SPFLite and lose all my setting then take a risk using a utility I know nothing about. I have no idea how bad I could screw things up. But then, that's just me.

And just to repeat, this all was only a thought. I don't want to suggest you actually do anything, for reasons you know all too well.

Read the funny manual? Believe it or not, I am mentally at a point in my life where absorbing tech manuals is almost beyond me. It's a persistent fog, a kind of mental block, a 'bridge too far' so to speak.

No, it has nothing to do with me not being involved per se. But because I wasn't, I can't bridge the gap between what I know and what I need to understand to get a handle on what you've done. It's like your DIFF feature. I can't grasp it. I have tried, but it never worked like I expected and never did what I needed. I just gave up and use KDiff3 instead. At least I know how that works.

Regrettable? Yes, but so much of my life is regrettable, this is just the tip of the iceberg. Sigh.

I can still walk, and I am not in (much) pain, but in every real sense, I am on my last legs so to speak. I can hardly walk any distance without tiring out and sometimes feeling chest pain. I am getting to the point where going grocery shopping is fatiguing, and I have to rest before driving back home because it's so exhausting pushing a shopping cart around. I have given up almost everything in my life, between chronic fatigue and chronic depression. If I weren't dead set (ha ha) against guns, I'd end it right now. As it is, I'm just too lazy to pull it off. So all I have left is being a pain in your side. Aren't we a pair?

Good morning George and Robert,

May I join your old age club? I won't go into my ailments and pains, but believe me, I am qualified.

I have three additional differences between the mainframe ISPF and SPFLite. Should I list them here or create a new thread? They are:
1. Cursor placement after using the repeat command (i.e., &) syntax.
2. Copying (i.e., ctrl+C) lines when the HIDE command has been used on the dataset.
3. Using the D9999 column command to delete a dataset of unknown length.
I have workarounds for all but #2, which I had to return to the mainframe to accomplish.

I want you both to know that I think SPFLight is a great tool. My company is moving away from the mainframe, so I am recommending SPFLite be used in our new environment.