开云体育

SHOWMVS uses a technique that doesn't require jump support, see the P$BEGIN macro. It will increase the overall CSECT size but might be a decent alternative to an extensive rewrite.

I did a backport to MVS38j which includes an assembler listing (showmvs.list) made with the Dignus assembler due to the code needing more than just ASMF. I don't believe Dignus offers the hobbyist license I used anymore, bu more modern assemblers than ASMF should be fine. I don't recall trying ASMG, something even more modern may be needed.



There's also a STRING.MAC that sounds a bit like #MSG.

Hope that helps. Jim

Do the older ARCHMODE settings in Hercules include the jump instructions? I would think no, since they didn't exist way back when.

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 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.)

Providing the proper JCL would help though. ?I'm very weak on z/OS JCL. (JECL?)

Which I already know how to do. ?I'm not a *complete* z/OS idiot after all. ?Just a very, VERY inexperienced one! ?:)

Andrew wrote:

I believe I know where/why it's going wrong with anything
greater than 3390-27. In my test with a 3390-54, the size of
the L1TAB needed for 982800 tracks is 30720. Adding the 1024
bytes for the header gives 31744 bytes. CCKDDU64 does not
seem to deal with this, when this first record is greater
than the lrecl/blksize of 16384, and it looks like the rewrite
table gets corrupted.

That's GREAT news, Andrew! THANK YOU!! :))

I did use #MSG to assist in debugging, but could not use too
many of them as it caused base register addressability to
fail due to the increase in csect length.

Sounds like CCKDDU64 needs to be "jumpified" so that base registers aren't needed.

Now looking at how to correct this........

MUCH appreciated! :-D

(This is GREAT!)

<me: does happy dance>

:))
--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

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?

And before people step all over me, I'm talking about a simple WTO 'XYZ' statement, not other menthods of telling WTO to spit out a pre-formatted string with MF=E and all that. I don't think that's what Fish is talking about.

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.

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.)

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Could you also sprinkle some more #MSG at some key places too?

I'm having a hard time following the code in just source form, but I don't like what I'm seeing. ?I'm seeing a lot of STORAGE OBTAIN calls, but I can't see where any of them are being testing for actual success or failure.

?

(I sure wish I could figure out how to get this thing on my own system so I could play around with it!)

Andrew wrote:

I found a 3390-54 and was able to reproduce the problem.
The error message is 'logic error writing track' which is
triggered on line 1174 in the source code. The Message is
at x'438' from register 13 in the dump.

I'll scratch around in my spare time.

Much appreciated, Andrew!

Could you also sprinkle some more #MSG at some key places too?

I'm having a hard time following the code in just source form, but I don't like what I'm seeing. I'm seeing a lot of STORAGE OBTAIN calls, but I can't see where any of them are being testing for actual success or failure.

This is especially concerning since it appears as if the 'write_track' subroutine is obtaining storage but never releasing it?

If that's true though, then maybe we're just running out of storage?

According to Brian, he's trying to dump 281380 tracks:

"281380 tracks out of 901530 will be dumped"

That's a lot of tracks and a lot of storage being obtained and never released!

Just thinking out loud...

(I sure wish I could figure out how to get this thing on my own system so I could play around with it!)

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Bob Polmanter wrote:

I looked at the code in CCKDDU64 and just prior to every branch
to the user abend 99 code, there is a #MSG message macro that will
print a single line explaining why the program is abending. This
message should be written to the SYSPRINT DD dataset.

Unfortunately, whomever decided to write this code

That would be the late great Greg Smith. One of the original Hercules developers from long ago. A truly brilliant man. I really miss him. :(

chose to use PUT-Locate for the writes to SYSPRINT.

I have no idea what that means. :(

This is a problem in the abend case because the line won't be
written until either (a) another PUT is issued (which there is
not), or (B), a CLOSE macro is issued against the SYSPRINT DCB
before the ABEND macro.

Would it be possible to issue a "dummy" PUT after each message (#MSG?) that didn't actually print anything? (Or perhaps one that only printed, say, a single blank character?)

If the program did not force an abend, then the message would
be written properly. This message could provide a clue on why
it is failing for a 3390-54.

The easiest solution is to add a CLOSE (prdcb) statement just
prior to the ABEND 99,DUMP macro, so it would go from this:

abend ABEND 99,DUMP

to this:

abend EQU *
CLOSE (prdcb)
ABEND 99,DUMP

The CLOSE macro will alter registers 14-1 before the dump is taken,
which isn't ideal in most cases, but right now the priority is to
get the error message text.

Couldn't registers 14-1 simply be saved beforehand and restored afterwards?

abend EQU * (something went very wrong somewhere!)
STM 14,1,saveregs (save registers before CLOSE)
CLOSE (prdcb) (close SYSPRINT to see our ABEND message)
LM 14,1,saveregs (restore registers after CLOSE)
ABEND 99,DUMP (ABEND with DUMP)
saveregs DC 4F'0' (registers 14-1 save area)

After that, one could examine the older U0099 dump without the CLOSE.

Eh? Wouldn't simply trying CCKDDU64 again (with the above modified code) produce a valid dump that could be examined? (AND also provide a good SYSPRINT output with the needed #MSG explaining why the abend was occurring too?) What am I missing?

Alternately, the message buffer should be in the dumps you already
have. But finding it means following a trail of control blocks and
it won't be easy.

Why can't we just make the proposed "fix" to CCKDDU64 as suggested and re-assemble and re-link it and use THAT new version of CCKDDU64 instead of the old broken one? Yes, it obviously won't magically fix whatever is ultimately causing the abend with 3390-54's, but at least we'll be able to see our abend message! Again, what am I missing here?

Longer term, the PUT-Locate method and logic for handling SYSPRINT
should probably changed to use PUT-Move (MACRF=PM) and this lack-of-
message-on-abend issue will go away.

Well then let's do THAT then! Yes?!

I'm not a z/OS programmer. I programmed on DOS/VS(E) and VM/SP. I never wrote a single program on z/OS in my life. So someone else (Brian himself maybe?) is going to need to make and test these proposed changes (fixes) to CCKDDU64 for us. Once they're made and we can see why it's failing, we would then need to basically repeat the same procedure: update the CCKDDU64 source code with the modified (fixed) code, rebuild and retest, until it eventually works correctly.

Then we can commit the newly updated/fixed CCKDDU64 program to Hercules so others won't be having the same problem that Brian is having.

Come on guys! Help me with this! Please?

Even better, just use a WTO macro to display it on the console and
job log.

Then let's do THAT instead! Sheesh! Let's FIX this thing! (Please?)

When I last used CCKDDUMP in approximately 2014, I used it against
a 3390-54 volume, but that volume was not full and the resulting cckd
dasd image was a little over 3 GB in size. CCKDDU64 did not exist
at the time. However, in order to get CCKDDUMP to work at all, I
had to modify the SYSUT2 DCB in the code to add a DCBE macro, and the
DCBE needed to specify BLOCKTOKENSIZE=LARGE. However, I see now
that in the current version of CCKDDUMP and CCKDDU64, this DCBE
parameter is now coded in the source.

Well that's good to know! :)

So.... Who is going to volunteer to make these changes to CCKDDU64 and test them?

Brian? Are you up to the challenge?

I certainly can't make or test them! I know *nothing* about software development on z/OS!

Help!

(Please?)


p.s. THANK YOU for looking into this issue for us, Bob!! MUCH appreciated!!

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

SUGGESTION?

Standard stupid-simple basic debugging:

Sprinkle as many additional detailed "#MSG" macro calls after the last one that was successfully issued ("file SYSUT2 opened for output") in the CCKDDU64 source code itself, and then re-assemble and re-link the CCKDDU64 program, and give it another try!

We have simply GOT to determine WHERE things went wrong.

We have simply GOT to determine where Brian's USER=99 abend is occurring, and WHY it is occurring.

Guessing will get us nowhere, and is a big waste of time.

Let's get to the root of the problem.

Let's fix the bug in CCKDDU64.

Or am I crazy.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Mike Ward wrote:

Mr. Fish. I don't know much about Github so I don't know
how to get to the development branch. Would you please tell
me how to access 4.8 development?

You need to build it for yourself using Hercules Helper for Windows.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Mr. Fish. I don't know much about Github so I don't know how to get to the development branch. Would you please tell me how to access 4.8 development?

Thanks in advance.