Hello Peter,

Am 18.11.2020 um 02:42 schrieb pjfarley3 <pjfarley3@...>:

I disagree with Patrik on one point: Many of us who use MSWin hosts aren’t all necessarily competent enough or have enough “round tuits” available to “build our own” SDL Hercules from source.

That’s why I wrote: ?or readily compiled for their particular platform“. :-)

:wq! PoC

开云体育

开云体育

Hello 闯ü谤驳别苍,

Am 17.11.2020 um 22:27 schrieb Juergen <winkelmann@...>:

Although the MVS 3.8j component of TK4- does not require modern z/Arch features, it is out of question to publish a TK4- release based on a Hyperion version that doesn't support key features required by the modern counterpart of MVS 3.8j. This simply because I know, that there are many people out there, running just that inside of TK4- instead of the MVS 3.8j it comes with.

Sorry, but I disagree. I don’t see why TK4- (in it’s original meaning as Turn-Key MVS 3.8j) is supposed to be delayed for something clearly not needed by it. People wanting to run newer OS’s can readily use the available online resources to get a newer Hyperion version as source to compile themselves, or readily compiled for their particular platform. Or they can ask here for advice.

I really do appreciate your work and efforts, and I really do not want to offend you. But please rethink your decision. I guess many of us are (more or less patiently) waiting for a newer TK4-: Updated and/or newly added programs, better settings in the countless PDS, and whatnot within the MVS environment. Not for a newer Hyperion. I can’t tell how many people are waiting for Hyperion, and how many are waiting for what I described. Maybe take a poll? ;-)

Maybe a good way ?in the middle“ would be to release TK4- 8.5, with all the newer stuff outlined above, but with an older Hyperion, or even the one being distributed currently with TK4-? What’s your opinion with that?

:wq! PoC

Thank you Rob,

I have also used RPF.? As a matter of fact, the difference between the panels in REVIEW and RPF was what puzzled me to start with.

All the best

--
Marco Antoniotti
Somewhere over the rainbow

Thank you Greg for the explanation.

Things do make more sense now.

--
Marco Antoniotti
Somewhere over the rainbow

Thanks.? Understood.

I presume that to figure out all the defaults in TSO, one has to do some... RTFM.
--
Marco Antoniotti
Somewhere over the rainbow

Hi Jeremy

Ok. Point taken :)? I should not complain too much about IBM, given that it payed my wife's salary for more than ten years :)

What I meant is that somehow, it looks like at a certain point IBM "froze" some organizational practices into its products.

--
Marco Antoniotti
Somewhere over the rainbow

Have the various issues holding up the next release of tk4 been resolved
yet? Is there any possibility of a Christmas present of a new tk4 this
year?

Hi All

sorry for the delay with releasing TK4- Update 09.

The major issue holding the release up is the current state of SDL Hyperion, which will be the engine running TK4- Update 09. Although the MVS 3.8j component of TK4- does not require modern z/Arch features, it is out of question to publish a TK4- release based on a Hyperion version that doesn't support key features required by the modern counterpart of MVS 3.8j. This simply because I know, that there are many people out there, running just that inside of TK4- instead of the MVS 3.8j it comes with. The main missing/instable feature is the transactional execution facility, as Fish described in this post:?.

I'm doing the utmost to help the Hercules developers community (which I'm part of) with straightening that implementation, But this really is a _very_ complex feature that, when done wrong, will inevitably lead to instability, miserable performance and data integrity issues when running an OS requiring that facility. So, bear with me (us), we really don't have reached a state yet in which it can be released.

Christmas present? Well, probably not: Once SDL Hyperion 4.3 is released, I'll require some 6 weeks to get TK4- out. So, clearly, this cannot be done before Christmas. Sorry again :-(

Cheers
闯ü谤驳别苍

On 11/16/20 5:43 AM, Vince Coen wrote:

IBM created the format for using the system based on their design BUT they were one of the first in creating a commercial computer system from scratch starting with the 1401 and for science based the 7090 series (i.e., 7094 as it had a built in arithmetic control unit)).
This kind of thinking was a bit like the first micros which did not have one within the CPU logic chip but as a separate optional chip..

On Micros, CP/M (and hence MS-DOS) got drive letters descending from VM.

“Imitation is the sincerest form of flattery.” Attributed to author and cleric Charles Caleb Colton.

-ahd-


--
Drew Derbyshire

In the beginning was the word, and the word was content-type: text/plain

On 11/17/20 5:15 AM, Rupert Reynolds wrote:

I tried to write a CLIST that processes all DSNs for an HLQ.

No &SYSINDEX(needle,haystack)

No SYSCALL for an internal PROC

I need to install Rexx, or port my compiler :-)

Stone knives and bear skins.

Over on VM/370, the original EXEC is based on the script processor for CTSS, RUNCOM.? That's wonderful historical trivia, not so wonderful when you're trying to get work done!

-ahd-

p.s. There's a reason I hang out on the LCM+L VM/SP system (mostly for XEDIT and REXX).

--
Drew Derbyshire

"Cool! Crossbow! Check out these babies. Goodbye stakes, hello flying
fatality." -- "Buffy the Vampire Slayer"

Hi Folks,

I use in RPF a different approach. All the datasets (TSO libraries) and other datasets are treated the same.
RPF does not use apostrophes in the data set names, so all data sets are fully qualified.

The effect is the same comparing with ISPF and RFE,
RPF has an user's guide in script, PDF or DOC (MSword) format.
The PDF and Script documents are available on my
If you download FILE 415 on cbttape.org, DOC file is available in member $MANUAL@.
Download this member to your PC.

Cheers,
Rob

开云体育

Thanks. brexx/370 was my first thought already, although I was keeping an open mind about alternatives :-)

--

I tried to write a CLIST that processes all DSNs for an HLQ.

No &SYSINDEX(needle,haystack)

No SYSCALL for an internal PROC

I need to install Rexx, or port my compiler :-)

Roops

On 2020-11-16 9:56 PM, marcoxa@... wrote:

So it boils down to "IBM made it up" :)? when it mapped these notions of "department", "project", "tool" ("type") to the 44 characters of DSNAMEs.? Is that right?

So on most (but by no means all) systems, a TSO user's data sets have names that have the user ID as the high-level qualifier.? Also conventionally, this means that some sort of user (meaning non-master) catalog has been chosen as the place where the user's data sets will be cataloged.? That catalog is cataloged in the master catalog and has been given an (additional) alias named the same as the user ID.

If the catalog is a CVOL, (OS catalog) then the first time a data set with the user's HLQ is created, an index pointer equal to the user ID will be created in the primary index chain, but never mind that, because such things were dropped by IBM with Y2K.? (I only mention it because I still use one on MVS 3.8.)

For VSAM and ICF catalogs, data set names form a 44-byte key for direct catalog access.

But never mind that.? A TSO user may have numerous data sets that all have the ID as the HLQ.? Conventionally, the user will also have their ID set as their default data set name prefix.? So if user USERA has a JCL library called USERA.JOBS.CNTL then USERA can refer to this data set as JOBS.CNTL when specifying it in TSO commands.

So, at the user level, you might have various libraries (PDSes) of various types.? Suppose USERA has (under his HLQ):
CLIST
LOCAL.CNTL
PGMS.ASM
PGMS.COB
PGMS.LIST
PGMS.LOAD
PGMS.PLI
PGMS.OBJ
VENDOR.CNTL

Several IBM TSO commands assume default low-level qualifiers for unqualified (unquoted) data set names.

For example, if USERA issued SUB LOCAL(JOB1) them because the data set name was unquoted, the prefix of USERA would be prepended to LOCAL and the suffix of CNTL would be appended to result in the contents of USERA.LOCAL.CNTL(JOB1) being transferred to the internal reader.

And that is why I like my JCL data sets to have an LLQ of CNTL, and not JCL or JCLLIB or whatever else.

Similarly, compiler prompters will assume default LLQs.? The PLI command (the PL/I Optimizing Compiler TSO prompter) assumed an LLQ of PLI.? There are comparable commands that use COB (IIRC) for COBOL and ASM for assembler.? The compiler output will usually be sent to a similarly named data except that the LLQ of OBJ would be used.

The LINK and LOAD commands look for .OBJ data sets.

If in USERA.CLIST member PLILKED contained the following:

PROC 1 PROG
PLI PGMS(&PROG) PRINT
LINK PGMS(&PROG) PLIBASE

and USERA issued
PLILKED MYPROG1
the we might expect the PL/I program in USERA.PGMS.PLI(MYPROG1) to be compiled with the object deck being written to USERA.PGMS.OBJ(MYPROG1) and the compiler listing being written to USERA.PGMS.LIST(MYPROG1), and then the object deck in USERA.PGMS.OBJ(MYPROG1) would be link edited (with SYS1.PLIBASE being an AUTOCALL library) into USERA.PGMS.LOAD.

LINK provides a LOAD operand to specify where the program load module is to be written, and a member name can be specified, but typically I use the NAME option on the *PROCESS? (%PROCESS these days) statement to set the program name.

And not that we have the PLI command available to us any more, anyway.? But LINK and LOAD are part of MVS.

So if the vendor sample JCL library was stored in VENDOR.CNTL and you did not want to alter that (good sysprog practice) then you might have LOCAL.CNTL "ahead" of it in ISPF or RFE option 2.? Select a member for editing, customize it, and submit and save.? You preserve the vendor-supplied copy but also have you customized copy.

Today I noticed that in z/OS 2.4 this part of the panel is labelled as "ISPF library" but I did not want to say that in RFE - nor did I want to say "RFE library".? So, I settled on "TSO library" since both ISPF and RFE are essentially TSO applications.

One uses the "OTHER DATA SET" section when s/he wants to access DSs that have been named using a different scheme.

Or when it has the same scheme, but you consider it more convenient for the panel to "remember" the name already primed.

Apart from that, is there some more documentation about RFE? E.g., in the "OTHER DATA SET" what is the "'DATA' OPERAND"?

As for the RFE package, the REVIEW browser came first (in 1981 by Bill Godfrey).? I started extending it in 1984.? REVIEW can interpret numerous file structures and display the interpreted results.? But sometimes you just want to see the raw data, and to achieve this you add the DATA operand (or D for short, since no other operand begins with D and so by TSO command parsing syntax rules it is unambiguous).? To make this facility of the REVIEW browser user-selectable from option 1 of the REVIEW Front End, I added the DATA OPERAND input field on the panel when in B or BROWSE mode (as opposed to V or VIEW mode).

See the HELP member of REVIEW for all of the operands and subcommands of the REVIEW browser.? Many of the components of REVIEW are set up to access the relevant HELP member via PF1 or HELP - assuming the HELP members have been properly installed.? By "components" I mean the browser, the editor, PDS member list displays, REVOUT, data set list and such rather than menus and entry panels.

Although the mechanics are not currently well documented, all of the TSO commands and component subcommands (that are not part of the menu navigation process) are documented fairly completely (I think) in? the TSO HELP members.

The names of HELP members that come to mind are REVIEW (REV), FSHELP (FSH, HEL), REVOUT, REVPDS, REVLEV, and for z/OS there's also REVUNIX and REVPDSE.

There is a main menu "Easter egg" for users with graphics (loadable symbol) terminals and for non-graphics screens 50 x 132 or larger.

Cheers,
Greg

开云体育

Fish wrote:

[...]

So if you want a really fast Hercules guest, buy as many
of the fastest CPUs as you can afford and as many of the
fastest dasds that you can afford.

And make sure you have PLENTY of RAM on your host too! (So you can give as much as your guest needs for best performance.(*))

(*) Which ultimately depends on your guest's workload and how well its configured (tuned) for performance.(**)

(**) Which is of course completely different from the way one configures/tunes one's real host!

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

mail: fish@...

Dave Wade wrote:

For home use any more than 2 cores adds no extra to
performance. Hercules will use one for CPU emulation
and one for IO and other processing.

That's only true for uniprocessor guest operating systems (i.e. guest operating systems that only support one CPU). For any multiprocessor guest operator system however (such as z/Linux, z/VM or z/OS, etc), having more cores will most definitely guest performance -- in situations where the guest has enough work to keep all of its CPUs busy of course. If the typical workload on the guest is very light however, then having multiple CPUs defined to the guest will probably not help you much.

I suspect that maybe what you were referring to was the fact that having multiple cores on the host will not magically make a given Hercules virtualized guest CPU run any faster. Each defined Hercules guest CPU can only ever run as fast as however fast one real host CPU can run, but not any faster.

Generally, Hercules can emulate one less Mainframe CPU
than you have total cores, the other being used for IO
and other ancillary tasks.

That's not true either, but only because you worded it so poorly. :)

Hercules is able to emulate as many guest CPUs as you want, up to the Hercules host's implementation maximum: 64 on Windows and 128 on Linux, *regardless* of however many real cores you have on your host.

That is to say, even if your real Windows host only has 8 real cores, Hercules can nevertheless still emulate up to 64 mainframe CPUs for your guest.

But given that each mainframe CPU that Hercules emulates can only ever run on one real host core (it can bounce around from one core to another of course, but ultimately it can only ever execute on one of them at a time), it only makes sense to refrain from defining more than approximately 1 or 2 virtual CPUs to your Hercules guest than the number of real host cores you have. For example, it your real host has 8 cores, I personally would not define more than about 6 CPUs to my Hercules guest, thereby leaving 2 real host cores left over for both Hercules miscellaneous work (such as scheduling I/O, etc) as well as for Windows itself to use for its own workload.

But as I said, even if you only have 8 cores on your real host, Hercules is still able to emulate more than that! It's just that it doesn't make sense to do so. It's not efficient.

If you are only running one job, you can only hit one mainframe
CPU, which uses a single thread in Hercules, which hits only one
core on the emulating CPU.

THAT is true, yes.

Specialty CPUs are marketing bullshit. They allow IBM to
sell you performance, but only allow you to use it in a
way that they specify.

And THAT is very *VERY* true!

As far as the OP's question regarding cckd parameters is concerned (ra, raq, rat, wr, ...), I personally have ZERO experience playing with them. I always use the default values. Trying to tweak them to eke out additional I/O performance is likely a waste of time IMHO. The best way IMO to improve I/O performance is to get faster dasd. Again, just like the speed of Hercules's emulated CPUs, Hercules's emulated guest I/O can only ever operate as fast as the host's I/O is able to operate. The faster the host, the faster the Hercules guest.

So if you want a really fast Hercules guest, buy as many of the fastest CPUs as you can afford and as many of the fastest dasds that you can afford.

That's my 2 cents.

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

mail: fish@...