I'm having issues uploading .html files to our z/OS USS environment - specifically character set and code page conversions.
I telnet in with PuTTy, upload with WinSCP, and edit with Notepad++, but have the strange situation whereby I can have a USS shell session going and can CAT and VI a file and if it looks OK, it'll be displayed by the z/OS web server OK, but then if I try to edit it from WinSCP, I just get garbage:
LZÄÖÃãè×Å#ˆ£”“nLˆ£”“#n##Lˆ…„n####L”…£#ƒˆ™¢…£~äãÆ`øn####L£‰£“…nÃÉÃâ#
similarly, if it looks OK in Notepad++ then it'll look like garbage when served as a web page.
I have the text file traansfer options on and if I list the files in aa shell session I get:
t UTF-8 T=on -rw-r--r-- 1 JOCS065 JOCS2 9824 Jul 30 14:45 JS_Graphviz.html
t UTF-8 T=on -rw-r--r-- 1 JOCS065 JOCS2 29370 Jul 30 14:15 JS_Graphviz_new.html
JS_Graphviz.html won't show as a webpage but JS_Graphviz_new.html will.
Both have <meta charset="utf-8">, notepad++ shows both as ANSI.
Oddly, if I take the good code from Notepad++, and then edit the same file in vi via my shell session, delete everything and paste in the code I copied from Notepad++, it can then be served by the web server (and look like garbage in NPP etc).
So there's obviously some hidden flag or setting for the code page or character set. Does anyone have a rock-solid editing solution for text files in USS on z/OS?
EDIT
Screenshot showing errors with JavaScript files
I'm going to go ahead and answer, though this could be wrong. This is known SCP behavior. How can I convince z/OS scp to transfer binary files?. If you connect via FTP or FTPS, you should get the behavior you expect. Or you can try using code tagging, although that's beyond my scope of knowledge. See https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa400/bpxug294.htm.
In general my experience is that when environment variable _BPXK_AUTOCVT=ON you'll get auto conversion under the covers. See this article to get better insight on how this process works and adjust for your workflow:
_BPXK_AUTOCVT
Used when enabling automatic conversion of tagged files. When set, this variable overrides the AUTOCVT setting in BPXPRMxx.
For fork (BPX1FRK/BPX4FRK), spawn (BPX1SPn/BPX4SPN), exec
(BPX1EXC/BPX4EXC), and pthread_create (BPX1PTC/BPX4PTC), _BPXK_AUTOCVT
is propagated from the parent to the child. For pthread_create, the
parent is the Initial Program Task (IPT).
ON
Activates the automatic file conversion of tagged files. This
option affects conversion for I/O for regular, pipe, and
character-special files that are tagged.
OFF
Deactivates the automatic file conversion of tagged files. OFF is the default.
ALL
Activates the
automatic conversion of tagged files that are supported by Unicode
Services. This option affects conversion for I/O for regular and pipe
files that are tagged. Setting or unsetting ALL has no effect after
translation for a file begins. If the conversion is between EBCDIC and
ASCII, this option also affects conversion for I/O for character
special files.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxb200/bpxkenv.htm
Related
I'm looking for a editor in windows that constantly saves file.
In linux I do
cat>somefile
and then just start typing. somefile gets filled up as I type.
Is there editor or similar thing in WIndows? Preferably a non-dos tool?
I use WebStorm from JetBrains, which saves constantly and unobtrusively.
I really love it. I use it as a text editor and for my web development.
http://www.jetbrains.com/webstorm/
(and no I don't work there).
Its possible to install some unix features to windows.
Have a look at this CoreUtils
The shareware text editor UltraEdit by default works with using a temporary file which means create a copy of the file to edit in directory %TEMP% and copy this temporary file on save back to original file. The usage of a temporary file makes it possible to use Undo and Redo.
But it is possible at Advanced - Configuration - File Handling - Temporary Files to disable the usage of a temporary file for all files or just for large files depending on a threshold value in KB. All edits made on a file opened without usage of a temporary file are permanent which means immediately done on storage media.
Another feature of UltraEdit is automatic save in regular intervals which can be configured at Advanced - Configuration - File Handling - Save with or without making a backup on every save and even supporting version backups which means backups with an incrementing number on every save.
Last but not least on usage of a temporary file for editing a file as by default UltraEdit can recover last edits if UltraEdit crashes (uedit32.exe process killed with Windows task manager), or Windows crashes, or a sudden power loss occurs. The temporary file is updated quite often in the background by UltraEdit and therefore the restore on next start after an unexpected end of the editing session often restores nearly all edits made last on a file. The recovery feature includes also new files not being saved ever as file with a file name.
It would be interesting to know for offering a perhaps better solution why you want that any edit is immediately written to the file. In general this is the opposite of what users want on editing a text file and is not good on some storage medias like SSD hard disks.
I have an eclipse CDT C project on a windows machine with all files, inc. doxy file, encoded as UTF-8.
UTF-8 has been specified as encoding within the doxy file as well.
Yet the LaTex files produced are encoded in ISO-8859-1.
In fact if I open a .tex file (with TexWorks), change the file encoding, save it and close it, when I re-open it the encoding is still marked as ISO-8859-1.
This means that UTF-8 symbols (such as \Delta) in the source make it through a doxygen build OK, but cause the PDF make to fail.
Im not at all familiar with LaTex, so not sure where to even start searching on this one, Google queries to date have been fruitless. I'm also still not overly sure if this is a Doxygen, Tex or windows issue that causes the .tex file encoding to be ISO-8859-1!
Thus it would be good to know that, even though there's no specific option for setting doxygen .tex output encoding, would it be set to the same as the DOXYFILE_ENCODING setting?
Assuming that is the case, then moving one of the .tex files from the project folder to the desktop and attempting the encoding change via TexWorks still fails to hold, so it leads me to think either windows or TexWorks is preventing the encoding being UTF-8, but lack of knowledge on encodings and LaTex has left me at a loose end here, any suggestions on what to try next?
Thanks
:\ I basically just ended up re-installing everything and making sure git ignored the tex files and handled the PDF files separately to the code files, so that the encoding was forced. Not really a fix, but it builds.
I need to be able edit the content of index.dat file programmatically (C:\Documents and Settings\Username\Cookies\index.dat). More precisely I need to modify it in order that index.dat for one user can be used for a different user name. Is there any documentation out there for this kind of binary file?
Pasco (http://www.foundstone.com/us/resources/proddesc/pasco.htm) is a free index.dat parser that comes with the source code.
Docs will be hard to come by - Microsoft has never publicly documented the structure of the the structure of this file. That said, you can find docs on the web such as the one mentioned above.
However, note that IE keeps close tabs on this file. The file is locked while IE is running (meaning, you can open/read it in some modes but not in others) and you can certainly not write to it.
One method that might still work is to boot-up in safe mode and then assign yourself administrator rights and then see if you can find the files to delete them.
The method I now use is to create a batch file to rename the subfolder below the folder containing the index.bat files and to then only copy the folders back to the original location that don't contain these files but the resultant batch files needs to be run from a separate windows account that has full administrator permissions.
The freeware code editor PSPad will allow you to view and to edit the contents of all of the index.dat files on your computer in hexadecimal form. This is done by replacing all of the digits in the first eight columns with zeros. This removes all of the information contained in the files.
It's a tedious process, requiring holding down the "0" (zero numeric key) as all of the edits are made, but anyone then accessing any of the index.dat files will get no information.
IE must be closed when doing this or you may receive an error message when attempting to save the modified file(s).
My windows co-workers were asking me if I could modify my non-windows binary files such that when their "Properties" are examined under Windows, they could see a "Version" tab like that which would show for a Visual Studio compiled exe.
Specifically, I have some gzipped binary files and was wondering if I could modify them to satisfy this demand. If there's a better way, that would be fine, too.
Is there a way I could make my binaries appear to be exe files?
I tried simply appending the VS_VERSION_INFO block from notepad.exe to the end of one of my binaries in the hope that Windows scans for the block, but it didn't work.
I tried editing the other information regarding Author, Subject, Revision, etc. That doesn't modify the file, it just creates another data fork(what's the windows term?) for the file in NTFS.
It is not supported by windows, since each file type has their own file format. But that doesn't mean you can't accomplish it. The resources stored inside dlls and exes are part of the file format.
Display to the user:
If you wanted this information to be displayed to the user, this would probably be best accomplished with using a property page shell extension. You would create a similar looking page, but it wouldn't be using the exact same page. There is a really good multi part tutorial on shell extensions, including property pages starting with that link.
Where to actually store the resource:
Instead of appending a block to the file, you could store the resource into a separate alternate data stream on the same file. This would leave the original file stream non corrupted on disk and not cause its primary file size to change.
Alternate data streams allow more than one data stream to be associated with a filename. Each stream is identified by a colon : at the end of the filename and an identifier.
You can create them for example by doing:
notepad test.txt:adsname1
notepad test.txt:adsname2
notepad test.txt
Getting the normal Win32 APIs working:
If you wanted the normal API to work, you'd have to intercept the Win32 APIs: LoadLibraryEx, FindResource, LoadResource and LockResource. This is probably not worth the trouble though since you are already creating your own property page.
Can't think of any way to do this short of a shell extension. The approach I've taken in the past is a separate "census" program that knows how to read version information from any kind of file.
Zip files can be converted into exe files by using a program that turns a zip file into a self-extracting zip (I know that WinZip does this, there are most likely free utilities for this also; here's one that came up on a search but I haven't actually tried it). Once you've got an exe, you should be able to use a tool like Resource Hacker to change the version information.
It won't work. Either Windows would have to know every file format or no file format would be disturbed if version information were appended to it.
No, resource section is only expected inside PE (portable executable; exe, dll, sys).
It is more then just putting the data inside the file, you have a table that points to the data in the file header.
What you can do if you have NTFS drive, is to use NTFS stream to store custom properties this way the contact of the binary file will remain the same, but you will need to use a custom shell extension to show the content of the stream.
When I open a file in eclipse it shows with the improper line spacing showing an extra line break between every line. When I open the file with notepad or wordpad it doesn't show these extra line breaks that only eclipse shows. How do I get eclipse to read these files like notepad and wordpad without those line breaks?
-edit: I don't have this problem with all files but only a select few where I have made local changes > uploaded them to our sun station > then pulled those files back to my local workstation for future modifications.
Eclipse should have a File -> Convert Line Delimiters To... option that may correct this for you. (If it doesn't work on your file, this article may help.)
Really, though, you should have your file transfer program treat your source files as ascii instead of binary. Then your line ending problem should be moot.
It's possible that the server (or something in-between) is replacing all your CR+LF with CR LF (separate)?
Try specifically setting the Text File Encoding (Window->Preferences->General->Workspace), or alternatively use File->Convert Line Delimiters To->Windows every time you get the latest version (I know, not ideal).
It turns out that the problem was solved by doing my ftp in binary only, and setting the Eclipse encoding to US-ASCII. I don't fully understand why this fixed the problem but it worked. Thanks for the 2 answers they both lead me to my solution.