How about WTO ROUTE=11 to JESSYSMG, not the console?
On Sun, Jan 19, 2025 at 7:26?PM Tom Brennan via groups.io
<tom@...> wrote:
You're correct, WTO can only send the hard-coded string between the
ticks. But - for quick tests I'll often modify that string, something like:
MVC WTO1+8+7(8),MODNAME
WTO1 WTO 'MODULE XXXXXXXX WAS LOADED'
The WTO macro expansion produces the hard-coded string, but since I know
where it is with WTO1+8, I'll poke my own data in there before it gets
executed.
By coincidence, I wrote my own C-style ASM macros and supporting code
many years ago, probably a whole lot like Greg's. Here's an example of
my version, and we both apparently chose # as the macro prefix:
#WTOF 'THIS IS LINE %D OF %D',PARM1,PARM2
ASM gets really difficult when formatting variable length text,
converting numeric/hex for output, and things like that. #WTOF (and
others in my set like #PRINTF and #SPRINTF) make ASM coding a lot easier.
On 1/19/2025 4:40 PM, Fish Fish via groups.io wrote:
Bob Polmanter wrote:
[...]
Instead of sprinkling more #MSG macros around, use WTO. Its
super simple: the format is WTO 'message text here'
For example:
WTO 'Arrived at label process_vtoc'
Just change the message text as needed. You can put as many
of these in as you like, although if you were to get super crazy
with them you could blow a base register and cause assembly problems.
Understood. HOWEVER... If I'm not mistaken, WTO cannot *format* the message text it is to display. Correct? It can only display an already formatted message. It can't substitute values into the text that it is to display. Yes?
That's the beauty of Greg's #MSG macro: it provides 'C' language type string formatting syntax (e.g. %s, %d, %x, etc) to make it easier to issue a dynamically constructed message.
So I'd prefer to stick with #MSG instead, and just fix the abend code so that any messages that haven't been "flushed out" are forced to be written to SYSPRINT before the ABEND is issued.
That and the fact that WTO writes its messages to the operator console too, which I'd like to avoid. (I'd rather they all go to SYSPRINT where they belong.)
[...]
In any case, it really doesn't matter. These are unconditional
OBTAINs, so if the system cannot acquire the storage for you,
the program will abend with a system abend code (not a user U0099).
Ah. Okay. I should have realized that. My bad.
Since that is not occurring, I wouldn't worry about storage.
10-4.
I can't think of a good way to help you get the code into your
system if you don't know how to use the system.
I think I'm just going to FTP upload the stuff I think I'm going to need, such as the source code and the JCL needed to assemble it, along with the OBJECT code for ZLIB and the JCL to link it all together into an executable, etc. Basically, I'm going to TRY following Greg's $$README. But a lot of it is stuff I've never done before, which I'm a little worried about. But I'll try to give it a try. I might just get lucky and managed to get it all working. (I really REALLY want to clean up the source code to CCKDDU64 so I can get a pretty looking assembler listing that I can better follow! That's my immediate goal. Once I get that, then I'll be in a better place to try and debug this thing!)
You need to have a basic knowledge of how to logon, to use ISPF,
access datasets, submit jobs and view output.
Which I already know how to do. I'm not a *complete* z/OS idiot after all. Just a very, VERY inexperienced one! :)
3270 file-transfer would be the easiest way,
Or FTP! Yes?
but that also depends on your 3270 emulator. I could put the
CCKDDU64 source and JCL on a tape image and send it to you,
I've already got the source. And the JCL, etc. Basically I already have everything that is in Herc's "cckddump-cckdload.zip" file in its 'util' subdirectory.
but you would still need to know how to run a job to load the tape.
As I said, I'm not a COMPLETE idiot. ;-)
I think I can handle that. :)
Providing the proper JCL would help though. I'm very weak on z/OS JCL. (JECL?)
BUT... That shouldn't be necessary. I've think I've already got everything I need.
I could put it in a small dataset on a small 3390 volume and you could
bring that online via your Hercules config, but with this method and
all of the above you would still need to be able to use ISPF to access
it, modify it, submit it, and do typical programming/debugging with it.
As I said, don't bother. I'm just going to FTP it to my z/OS system, placing it all in some dataset somewhere (maybe xxxx.LIB.JCL) and just try to hack my way through it all with the help of Greg's $$README.
Further, using a foreign 3390 volume would likely cause RACF security
access issues to gain access to that dataset, and RACF is an area that
I have struggled with long ago.
I have ZERO experience with that! As I understand it, it's some type of security thing (yes?), and after (or during??) linking of CCKDDU64, the option or flag or something needs to be set so it can directly access the volume that is to be dumped. I might need some help from somebody for that. But I *think* I might be able to slog my way through the rest. Hopefully.
I don't have any way to assemble and execute this code in its proper
environment, so I am limited to just looking at the code.
Same with me, for the moment. But as soon as I have time (HA! THAT'S a joke!) I'm going to *try* and give all of this a go.
(I *hate* having to debug this thing myself! I'm a *Hercules* developer, *not* a z/OS developer! Technically I shouldn't be wasting my time on this. Guest o/s issues are the responsibility of the user. MY responsibility is only with Hercules. I can't be expected to be an expert at every damn operating system that is able to be run under Hercules! That would be ridiculous.)
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
