|
|
Post by edliss on Mar 29, 2024 11:52:36 GMT -5
Hello I have a situation where the I am submitting JCL that uses a #INCLUDE for the input. The first record of the included record has 3 garbage characters added to the front of the records. I have included the output of the job that shows the junk characters. I also included a copy of the included file.
I recently upgraded to V3.0.24069. I have submitted this JCL numerous times before today with no problems since the upgrade. SlimAuth.pli (1.15 KB) Attachments:JOB-HERCELD-4176-A.txt (12.01 KB)
|
|
|
|
Post by George on Mar 29, 2024 13:15:19 GMT -5
Hi,
Can you send me the SPFLite.CFG file and the two files needed for the submit.
Also, what is your XTABS setting?
George
It's kinda hard to see where this code can go wrong.
'--------------------------------------------------------------------------------------------+
'- Setup to read the Included filename |
'--------------------------------------------------------------------------------------------+
FNum2 = FREEFILE ' Get another file #
Call3(TryOpenInput(INCLFile, FNum2), _ ' Try the open
MErrExit(%eFail, "SUBMIT INCLUDE file doesn't exist"), _ ' Oops? Bail out
MErrExit(%eFail, "OPEN of SUBMIT INCLUDE file failed"), _ ' Oops? Bail out
Nul) ' Continue
'--------------------------------------------------------------------------------------------+
'- Extract CBlines to the output file |
'--------------------------------------------------------------------------------------------+
DO WHILE ISFALSE EOF(# FNum2) ' Loop reading lines
LINE INPUT # FNum2, t ' Get one line
t = TAB$(t, FCB.ImportTabs) ' Do any needed tab conversion
PRINT # FNum, t ' Just write the line to SUBMIT file
INCR recs ' count it
LOOP ' Loop till all lines extracted
CLOSE # FNum2 '
|
|
|
|
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 George on Mar 29, 2024 21:21:44 GMT -5
Robert: I've been thinking the same,and since we have EBCDIC involved as well,this could be interesting.
George
|
|
|
|
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 edliss on Mar 29, 2024 23:29:57 GMT -5
|
|
|
|
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 George on Mar 30, 2024 10:59:02 GMT -5
Well, it's almost certainly BOM data. The #INCLUDE file reading simply ignores the possibility of BOM. I'll have to add it.
I'll do so and play with the provided data files. The Pli file is definitely has a UTF8 BOM marker.
George
|
|
|
|
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 George on Mar 30, 2024 11:24:58 GMT -5
A Beta with the correction will be uploaded today to correct this. NOTE: there will be no support in INCLUDE for UTF16/32 format encoding.
George
|
|
|
|
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 George on Mar 31, 2024 8:27:22 GMT -5
Robert: That's why I only added UTF8. The code for UTF16 is in there, but it's embedded in the main edit file read routine, so not easily accessable. I didn't think it worth the effort to clone it in another spot. Besides the justification just isn't there.
George
|
|
|
|
Post by edliss on Apr 1, 2024 12:05:36 GMT -5
I tried some things and I was able to re-create the text file. The original file was "printed" by Hercules TK5 to a text file. I copied the text file to a working directory and edited using SPFLite to delete the banner pages. When I submitted the JCL with the include, the junk characters appeared. After reading the comments, I thought maybe I might try a different way to download code. I created a new text file using explorer. Using notepad, I opened the original file generated by Hercules and select/copied the text I wanted. I then pasted the text into the new text file. I then submitted the JCL including the new file and there were no junk characters.
So I conclude that UTF8 vs UTF16 issue was caused by Hercules or the spool program.
Thanks for you attention in this matter.
|
|
|
|
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
|
|
