|
Post by Robert on Apr 30, 2024 10:13:32 GMT -5
Sure enough, one month later, there is HnD 9.2
|
|
|
Post by Robert on Apr 25, 2024 9:13:44 GMT -5
Randall, SPFLite uses ThinCore.dll to support macros, and this is located in C:\Program Files (x86)\SPFLite2\thincore.dll. So, it's different files and you won't have a wrong-version problem. SPFLite does not update the thinBasic binaries very often since they don't change that much and what gets changed is usually very obscure, the kind of stuff that macro writers hardly ever need.
Keep in mind that every time you install a new SPFLite update, it will refresh thinCore.dll with whatever the current SPFLite distribution version is. If you cared about version differences, it could be hard to keep a version installed that differed from the SPFLite distribution. If you wanted to do such a thing, you'd need to coordinate it with George.
R
|
|
|
Post by Robert on Apr 10, 2024 8:52:08 GMT -5
George,
I see you have now released SPFLite3. I don't approve of this, and I want you to understand why.
You know, there was a time when a change of this magnitude was something you'd talk over with me in great detail. We'd work out every nook and cranny of the design, so once it saw the light of day, there was a good chance (a) it was documented accurately, and (b) it worked as advertised. It would seem those days are over, since you are no longer interested in my opinion. But, what you have done forces me to give my opinion here, even though personally, I'd rather not. I hate arguing, but this is not an argument, because I am not asking you to change your ways. I know you won't.
I want you to think carefully about how in past times I proposed wild ideas for some damn thing or another. At first you went along with them, but over time and after having been burned enough, you tended to come up with a standard answer. Ready for it? The standard answer goes like this:
"I am trying to back away from major changes. I am XX years old and I can't do this forever. Besides, no one will even know the fix is in there. No one will use it. Putting this in is make-work. It doesn't buy me anything."
And you would summarily shut me down. The standard answer shuts down a lot these days. NOW, suppose some years ago that I had proposed to YOU to make the very change that YOU made to SPFLite3. Wouldn't YOU have given ME the standard answer? "It doesn't buy me anything. Why do it?"
So, George, what does SPFLite3 "buy me"?
1. You removed some perfectly good, working features, because you wanted to wrap up SPFLite3 development prematurely and were too lazy to keep those features in place in your rewrite. And, you were too lazy to properly reach out to the user community, a step that would have delayed the release. (BTW, what is your hurry, anyway?) And even if you did THAT, it overlooks a vital current-events fact: The SPFLite community has been AWOL for the last months at least, with days when NO ONE has even logged on, and when they did, it was just 2 or 3 people, sometimes only you, and sometimes literally no one. Not exactly the right circumstances to be conducting surveys, is it?
2. You completely changed the architecture of the "parser" (oh yeah, you never mentioned WHICH parser; I assume you mean the primary command one, which is not the only one, is it?) when no one that I know of has made a single complaint about the parser failing in years, that I can recall. Tell me again, what does this buy me? I know I didn't ask for this.
3. You have destroyed confidence in the editor. Your changes are so complex that even you, as the author, admit that you yourself are incapable of testing it - despite the fact that you have complete and total knowledge of what was done. So, instead of the only person in the world that even knows WHAT was changed going ahead and doing that necessary, time-consuming grunt work, you have handed off that testing to hundreds of your users, who don't know what the hell they are even looking for to test. And why? You're too bored to do it yourself. So, now every time the editor fails or a macro fails, we ALL are going to have to painstakingly run our own ad-hoc tests to try to figure out what the hell went wrong. Thanks for that.
Now, you can't judge by me, because my use of SPFLite is not at all typical. I am not trying to design software or run a business. But there are users out there who ARE trying to do those things. Maybe some of that activity is critical to a business, and if SPFLite3 is subtly broken, it could cause real harm to them. But, IS SPFLite3 subtly broken? I have absolutely no idea, nor do you, NOR do any of your users.
I can tell you right now, if I depended on SPFLite as part of a business process, there is no way I would use SPFLite3, unless some other braver and more-willing users had the time and energy to test it for me first. I would stay with SPFLite2 for at least a year, because I simply couldn't justify the risk of an unproven, untested editor breaking critical data or editing processes.
For my own use case, I have some quite large macros that I have used for years because they work, and now, I don't remember the details of all the hundreds of lines of macro code I wrote. With SPFLite3, I will have to go through all of them, line by line, to make sure the syntax of every one will still work in version 3, that I don't use any of the features you unceremoniously removed, etc. etc. And, at my stage of life, I am doing good just get up in the morning. Do I have the strength and resolve to exhaustively go through that make work to survive whatever you've done with SPFLite3?
NO.
As I see it, it's unforeseeable that I will use SPFLite3 any time soon, if at all.
I tried to tell you that you needed automated methods to test your changes. You dismissed that, because (again) it was your famed "make work" and you couldn't be bothered. Instead, you are 'bothering' your users to test a new editor that (I am sorry to say) sets back the editor's reliability by 15 years. And I will repeat, USERS are not qualified to properly test everything you've done, because you haven't told us what you changed - not EXACTLY. And even if you did, that presupposes that all of your users have the TIME to do that. Maybe they are very busy running a company, and just wanted their editor to work? Just a thought.
Now, if you at least had a DESIGN DOCUMENT, we could read it for ourselves and use it as a testing guideline. But you never design things first, do you? You haven't worked that way for 15 years, so why start now? Code first, design later, document last, right? We have no way to know if you've even revised everything in the Help to reflect the new circumstances. Documentation is such make work, isn't it?
Remember the bad old days when every other day, some bug was found where commands didn't work right or didn't support ISPF syntax? I remember. But constantly working on those problems as they arose served to address the issues, one at time. Yet now, you have thrown away years of all the hard work that made the old parser - such as it is - quite reliable. Perfect? No, but it was perfect enough. How could you do that to us - to pull the rug out from under us like that?
George, I am sorry to be so critical and throw cold water on your hard work. Perhaps I am too cynical and suspicious. Maybe 99% of the changes work right. Sorry for the poor guy who gets hit with the 1% bad part and ends up destroying their data, but oh well. Achieving perfection is such make work.
In my opinion, you have done your users a great disservice. If you had asked me beforehand (you know, like the "good old days" when you listened to me) I could have given you some advice, and I would have tried to find some way to help you automate your testing so that you might have had some grounds for confidence. I actually know something about this stuff. I worked on object oriented systems where they included testing stubs as part of the object design, and all you do is compile in "test-generator mode" and poof, your design gets tested. Yes, that is pie in the sky design, and SPFLite is not really an actual object-designed program. Still, I actually have testing insights that you don't have. Only thing is, you're not interested in my options and won't listen any more. We're two peas. Two geezers. Listening is just so time consuming, isn't it?
Maybe I'm wrong - and if I am, good for you and good for the users. You may be willing to foist an unproven, untested and untestable alpha program on your users and burden them with finding all the bugs in real time - bugs you yourself are unwilling to find. I just can't do it.
I could advise you on how to get out of this conundrum, but again, you won't listen, and I don't have the heart to argue. What's the use? It won't buy me anything.
Sorry.
|
|
|
Post by Robert on Apr 8, 2024 12:43:23 GMT -5
I have often thought that SPFLite should maintain "telemetry" data like Windows does. That would be where it actively kept and stored usage data on features. That way, you wouldn't have to keep asking (in vain) if anyone used feature XYZ. You could have a feature that would upload the user's activity stats, probably by email to an address reserved for that purpose.
But, I suspect you'd view this as make-work, so I haven't suggested it until now. As long as you didn't save anything personal, and let people see the collected data, users shouldn't have a big problem with this.
R
|
|
|
Post by Robert on Apr 1, 2024 12:28:33 GMT -5
Edliss, I feel that whatever you are doing, you have over-complicated matters. Whether you are using MVS or z/OS, they don't deal with Unicode or BOM codes - certainly not from a SYSIN file. Neither does SPFLite, UNLESS you have BOM ON in the profile of the file you are editing. I mentioned this above, but you didn't reply to the matter. I urge you to review the profiles of the files you are editing, to make sure you have BOM OFF in effect.
Since your SYSOUT display shows the EBCDIC version of BOM, I am wondering if you are editing in EBCDIC for your PL/1 files. In Hercules, it's not necessary to maintain your data files as EBCDIC, because the the SUBMIT action in conjunction with your virtual card reader device take care of that. You can use standard ASCII (ANSI) text files and submit them to Hercules and it will work fine.
This is what the Help says about submitting jobs to Hercules:
"For SPFSUBMIT to successfully submit a job to an emulated mainframe system, the Hercules configuration file must have an emulated card reader device configured to read from a socket rather than from a PC disk file. A sample card reader device line in the Hercules configuration file might look like this:
000C 3505 localhost:3505 SOCKDEV ASCII AUTOPAD TRUNC EOF # card reader
In the SPFSUBMIT.EXE command line, the “localhost” name can be specified literally as localhost or as 127.0.0.1"
If you do that, and your .JCL file has a profile with BOM OFF, you should be having these problems.
On the SOCKDEV line, "ASCII" means the reader will use the default codepage to convert to EBCDIC. In your Hercules config file, you need a line like this:
CODEPAGE 1252/1140
This will ensure the ANSI data in SPFLite will be correctly translated to the modern EBCDIC code page of 1140. This is what you most likely will need, unless you are working with a non-English version of z/OS.
I don't run Hercules any more, but I did in the past, and SPFLite's SUBMIT support works correctly. Several of our users run Hercules, and we never see the problem you originally posted from other users.
All the convolutions about cutting and pasting from Notepad are simply not necessary. Your whole process is far more complicated than it needs to be. This has all the earmarks of a misunderstanding, not a bug.
R
|
|
|
Post by Robert on Mar 30, 2024 12:38:22 GMT -5
Well, if you are capturing the 3-byte BOM (ANSI or EBCDIC) the remainder of the file is just characters. UTF16 requires interpretation and possible byte swapping. That's tricky. When UTF-16 is involved and somebody included the file, did they want the data to be byte swapped or not? I use UTF-16 LE files, but I always use them as is for an application that expects them that way, so no swapping is needed.
But, really, compiling PLI code shouldn't require BOM at all, and what's more, the SYSIN reader for Hercules already does ANSI to EBCDIC translation. All this stuff going on shouldn't even be done; it's not necessary, IMHO.
R
|
|
|
Post by Robert on Mar 30, 2024 11:21:25 GMT -5
That must mean the PLI file already has a BOM stored in it, and your code just copies what is already there and didn't add it.
R
|
|
|
Post by Robert on Mar 30, 2024 6:38:27 GMT -5
Can you show the original Jcl file, not just the sysout? The one with the #include in it? And, gor that file, what is it's Profile setting for BOM?
|
|
|
Post by Robert on Mar 29, 2024 22:51:01 GMT -5
Looking at the SYSOUT, the BAD DATA = 57 8B AB
And, as I noted above, the UTF-8 BOM in ASCII = EF BB BF
Looking up the bad data bytes in EBCDIC.SOURCE, the bad data is a direct translation of the BOM to EBCDIC.
That pretty much proves the data in question is a BOM.
R
|
|
|
Post by Robert on Mar 29, 2024 14:20:56 GMT -5
The complaint was, "The first record of the included record has 3 garbage characters added to the front of the records." There is a discrepancy where it starts "first records" and "the front of the RECORDS". I am going to assume this is a typo, and only ONE record, the first one, has the problem.
Correct me if that is wrong, but otherwise, this sounds like a Byte Order Mark issue. If a BOM is getting inserted, and the data is getting treated as UTF in any way, the UTF-8 conversion of a BOM is 3 characters containing EF BB BF.
I suggest looking at the profile for the file in question, and seeing if BOM ON is set. If so, set it to OFF and try again.
R
|
|
|
Post by Robert on Mar 27, 2024 19:06:50 GMT -5
In the latest never-ending HnD saga, there is now HnD 9.1 as of March 19, 2024. At the rate they keep changing this, you might need to check their web site once a month to see if they've pulled the rug out again.
R
|
|
|
Post by Robert on Mar 17, 2024 20:33:56 GMT -5
George,
1. I've operating under the assumption that I'm no longer in your good graces, so the idea that you're cursing me doesn't come as a big surprise.
2. How would I parse a command like RLOCFIND as you've described it? I do my serious parsing with YACC. In YACC it's quite straightforward:
parse_cmd : RLOCFIND | RLOCFIND reverse_arg | RLOCFILE find_class_syntax ;
reverse_arg :: REVERSE | REV ;
find_class_syntax /* the generic syntax for find/change/delete/join/split would be here */ ;
3. If your new parser cannot handle this, it suggests your parser design needs some work. Designing parsers is hard; that's why most commercial users of parsers never hand-craft their own, but use parser generators like YACC instead.
R
|
|
|
Post by Robert on Mar 8, 2024 13:04:46 GMT -5
That is regrettable. My experience with parsers and lexers is that they ALWAYS define a single interface. For compiler projects, they pretty much have to. That is because most compilers use parser generators like YACC and scanners like LEX to do the work. When these are used, you CAN swap in a new parser, just like that. That is standard operating procedure.
I know that using such tools would be hard in SPFLite, since most of them are written in C or C++.
But, I do wonder how you are going to manage plugging along this way. You started off by saying there was no way you could test the parser and all its possible combinations. Now you say that even doing that much is not enough. But attempting an automated validation is a waste of time to you, and so you are going to count on the users to debug your new code, since you see no way to test it yourself. That is large burden to give the users, especially when they don't even know what they are trying to find wrong.
I can't and won't argue with you, but there are times I wish you did things differently.
I would ask that you issue a new production release that represents the code prior to your parser change plus all outstanding beta changes, so that if your new code is not stable, users will have an official release to fall back on.
R
|
|
|
Post by Robert on Mar 7, 2024 16:48:38 GMT -5
Yes, the macro would end up creating thousands of command lines.
I believe the answer to "how the script could check if the commands were successful" is for the script NOT to check.
Instead, you would need to add some internal support for this functionality. What I mean is, let's say you have a macro whose purpose is to create a primary-command test suite. When you run the test suite, its first command would be some internal command, for YOUR use only, which would set a flag indicating that you were testing the operation of SPFLite and NOT operating it normally. Then, after each command were attempted, the command parser code would determine if the command were valid or not, then perhaps write out a "log file" with the results of parsing each line.
At this point, I am assuming that your goal here is to validate that the parser is working correctly, and not that SPFLite itself is working correctly. Let us assume that the bulk of your (unchanged) code still works, so we are not trying to validate each and every little tidbit of code, right?
I believe that the basic validation idea can in fact be done, and that it's NOT just a dream. Nor do you need a miraculously lengthened lifespan to get it all done.
I think you are looking at it the wrong way. I don't believe that it is an "enormous undertaking". Not if it's done right.
R
|
|
|
Post by Robert on Mar 7, 2024 14:43:02 GMT -5
Maybe what you need is a macro to generate all combinations of operands of all commands, and then run them as a script.
R
|
|