Re: REXX Interpreter immediate commands
Pardon if I answer this twice. I had a crash, right when I hit?send a few minutes ago.
I was only describing the HI immediate command implementation in the original REXX.
Almost all the multiuser, multitasking, and asynchronous event processing is handled in the VM Control Program.? This design allows CMS to be treated as a single user system. There? is one application running. It may synchronously?call other programs. It can use simple? Input/Output operations which are treated as synchronous.
Some events, however, are inherently asynchronous. Timer expirations, communications with other virtual machines, special?asynchronous input/output, etc. CMS interruption?handling is documented in the? VM/370 System Programmer's Guide. In general, CMS applications sign up to be notified of asynchronous events by providing the address of an event handler routine. These handlers can mark events complete by? setting indicators which are polled by mainline code. The mainline routine can also relinquish control by? a WAIT state, so that event handlers POST the completion of events and the mainline code resumes execution.?
The APIs for asynchronous operation are only available to assembler level routines in VM/370.? Later VM systems (more recent than 40 years ago) extended these capabilities to enable client/server application development in CMS. Although VM application vendors (for products like The SAS System, and? the VM:Manager Suite of products) built their own multitasking layers for their products, CMS did not? support true Application Multitasking until about 30 years ago.?
Even 45 years ago,?receiving interrupts, and registering event handlers were fundamental?components of? CMS.
Bob Bolch
On Wed, Apr 15, 2020 at 5:24 PM adriansutherland67 < adrian@...> wrote: Bob ... Noted
Am I right in assuming that the concept of processes receiving signals / interrupts, and of registering signal handlers is just alien to VM/370 and can be ignored?
A
|
Drew Derbyshire wrote: On 4/14/20 11:32 PM, Peter Coghlan wrote:
I wonder could this have been the COBOL compiler abusing MVCL instructions
in situations where they were not the appropriate instructions to use?
Perhaps instructions such as MVCL would be expected to be "hot spots" because
they can deliver a relatively large amount of work for a single instruction?
Or is it that implementations of this instruction were sometimes poorer than
they ought to be and they were really not delivering bang for buck? I was told back in the 1980s that for performance reasons MUSIC moved
4096 bytes of data via a series of MVC commands in place of one MVCL.
My feeling is that something like this would be likely to have remained in place forever more. I had a look through the "current" MUSIC nucleus object deck for 256 byte MVC instructions (X'D2FF'). I found this section of code in the URMON module: BR R14 LTR R4,R4 BZ 2224(R0,R12) MVC 3112(4,R0),16(R0) MVC 4056(4,R0),540(R0) MVC 4060(4,R0),548(R0) MVC 1456(256,R4),3072(R0) MVC 1712(256,R4),3328(R0) MVC 1968(256,R4),3584(R0) MVC 2224(256,R4),3840(R0) MVC 472(1,R4),3524(R12) BR R14 MVC 3072(256,R0),1456(R13) MVC 3328(256,R0),1712(R13) MVC 3584(256,R0),1968(R13) MVC 3840(256,R0),2224(R13) MVC 16(4,R0),3112(R0) MVC 540(4,R0),4056(R0) MVC 548(4,R0),4060(R0) Without doing a bit of work to figure out exactly what is going on, it is not clear to me whether these code sections get called four times in a loop or not but it could be the case. Of course, it's harder to locate MVCL instructions (X'0E') in an object deck but there seem to be a few in there, including this one in URMON: ST R11,144(R0,R13) XC 440(32,R13),440(R13) LA R0,1456(R0,R13) LA R1,1024(R0,R0) SLR R3,R3 MVCL R0,R2 MVI 472(R13),32 L R5,3444(R0,R12) ST R13,620(R0,R0) LR R8,R12 L R12,3644(R0,R12) BALR R14,R12 However, this could have been added later the lifetime of MUSIC. Regards, Peter Coghlan. --
Drew Derbyshire
"All right, Mr. DeMille, I'm ready for my close-up." -- "Sunset Blvd.,"
|
Re: OT, mail issues, was Re: [h390-vm] memset help
On 4/15/20 3:21 PM, adriansutherland67 wrote: Does your email server implement?SPF, DKIM and DMARC? Yes, yes, and yes. Along with other things. -- Grant. . . . unix || die
|
Re: OT, mail issues, was Re: [h390-vm] memset help
I've never seen a commercial spam filter that was worth a damn,
honestly. But that goes for most commercial software.
The big issue with spam is the combination of sleazy people and
clueless people. Over the past fifteen years or so, spam has started to
look more and more like real email, and real email has started to look
more and more like spam. As someone who has managed large mail
installations in the past, I can say that keeping ahead of it is
essentially impossible, and in a large installation requires quite
literally daily tweaks. On my mail server here with about ~110 users,
the tweaks are about every 3-4 days. It's a pain in the ass.
Oh, and the issues I'm having with gmail aren't for messages sent from
groups.io's mail servers, but from mail.neurotica.com.
-Dave
toggle quoted message
Show quoted text
On 4/15/20 5:59 PM, Dave Wade wrote: I don't think I have never seen anything from you marked as "Junk". Some providers don't like groups.io so it might not be you.
I really find most SPAM filters unbelievably bad and I used to manage some very expensive ones.
They allow some utter garbage through whilst often blocking good e-mails.
Why can't they block "PayPal account restricted" messages that have not been anywhere near PayPal.
I can do a much better job than most filters just by looking at from/subject...
I am sure much I get is from having a Taj hotels loyalty card.
As I am sure you know your servers and domains are clean on
Dave
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Dave
McGuire
Sent: 15 April 2020 21:40
To: [email protected]
Subject: OT, mail issues, was Re: [h390-vm] memset help
On 4/15/20 2:07 PM, Peter Coghlan wrote:
(By the way, I replied to your recent "Inquiring minds" email but I
fear you may not have seen my reply as Google tends to route anything
I send these days into their recipients spam folder or otherwise
quarantine it. Apparantly Google regards me as a notorious source of spam or something for some time now.
I also sent emails to other Google mail users both on the this list
not and these also seem to have disappeared into black holes...) I am noticing this to an increasing degree as well. My assumption is that
Google, having spent years pushing "free" email services while making
money on the back end by using the information they mine from it, are now
trying to push yet more people to use gmail accounts.
My mail server predates the very existence of Google as a company by
many years, and has only been use as a spam relay once, a decade ago, for
not quite a day, until I noticed that one of my hundred-or-so users
passwords had been cracked. The only reason I can see for email originating
from my server to be considered spam by Google is that it comes from a non-
gmail server.
This is just my assumption; I have no evidence to suggest that this is why
this is happening, it but it is the only explanation that I've been able to come
up with for this widespread and rapidly growing problem.
This is what happens when people take the lazy or cheap route and get a
"free" email account from a for-profit corporation. Google occasionally does
good things for society, but they are not a charity.
As many have said, and almost nobody actually pays attention to: If you
receive value from a corporation for free, you are the product.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
--
Dave McGuire, AK4HZ
New Kensington, PA
|
Re: OT, mail issues, was Re: [h390-vm] memset help
On 4/15/20 5:21 PM, adriansutherland67 wrote: Does your email server implement?SPF, DKIM and DMARC? Yes, no, and yes. I ran DKIM until about two weeks ago, and I'll be starting it up again soon. -Dave -- Dave McGuire, AK4HZ New Kensington, PA
|
Joe:
Please understand that I was one who worked on millicode and hardware on several machines over the years, as well as on emulators. On the machines I worked on, and as long as the data was aligned, MVCL was by far faster for data lengths over 256-bytes. On another machine, I took the lessons from MVCL into the hardware, and speed up MVC substantially. And, granted, there are some machines in which moving a page is best done using 16 MVC instructions, but others in which MVCL outperforms as no interrupt checks need to be made during the move.
It also depends on the implementation of the instruction pipeline, and when a given machine¡¯s internal architecture inserts checks for interrupt status. For example, on one machine I worked on, we found that it was faster to have the MVCL code itself check for the pending interrupt line that was shared with what one would term as the instruction dispatcher. Thus we were able to stay inside MVCL longer, and take fewer breaks. On certain machines, even further optimizations within the pipe architecture can benefit MVCL over MVC, while on other machines, a fixed set of MVCs optimize better.
This is why I stated that the old claim of $MVCL being faster may or may not hold true in the current series of machines. The claim needs to be revalidated, and, if no longer true, a documentation APAR needs to be filed.
Mark ?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of Joe Monk Sent: Wednesday, April 15, 2020 2:47 PM To: [email protected]Subject: Re: [h390-vm] memset help ? Mark, No doubt ... but MVCL/E are still millicode instructions. MVC is a hardware instruction. ? On Wed, Apr 15, 2020 at 4:28 PM Mark L. Gaubatz via <mgaubatz=[email protected]> wrote: Joe: ? $MVCL was written many, many years ago. At the time, it was faster on certain machines. Need to re-validate this claim. ? Also, at the time the macro was written, the cachelines were shorter. On several machines, MVCL performed additional checks whenever crossing a cacheline. On others, it was at page boundaries. Consequently, on some machines, $MVCL was faster, on others, slower. It entirely depends on the underlying firmware and hardware implementing the two instructions. ? So please remember, some of the ¡°official¡± text when referring to performance is long outdated. ? Mark ? ? ? Even IBM admits that multiple?MVCs are faster than MVCL... "Use $MVCL to generate a MVC (move character) instruction when you need to move more than 256 bytes of storage. Use this macro instruction in high performance areas because multiple MVCs (as created by this macro) are faster than using an MVCL instruction." ? On Wed, Apr 15, 2020 at 1:11 PM Peter Coghlan <groups@...> wrote: Drew Derbyshire wrote:
> On 4/14/20 11:32 PM, Peter Coghlan wrote:
> > I wonder could this have been the COBOL compiler abusing MVCL instructions
> > in situations where they were not the appropriate instructions to use?
> >
> > Perhaps instructions such as MVCL would be expected to be "hot spots" because
> > they can deliver a relatively large amount of work for a single instruction?
> > Or is it that implementations of this instruction were sometimes poorer than
> > they ought to be and they were really not delivering bang for buck?
> I was told back in the 1980s that for performance reasons MUSIC moved
> 4096 bytes of data via a series of MVC commands in place of one MVCL.
>
Drew,
This is very interesting given our recent discussion on the matter.
(By the way, I replied to your recent "Inquiring minds" email but I fear you
may not have seen my reply as Google tends to route anything I send these days
into their recipients spam folder or otherwise quarantine it.? Apparantly
Google regards me as a notorious source of spam or something for some time now.
I also sent emails to other Google mail users both on the this list not and
these also seem to have disappeared into black holes...)
Regards,
Peter Coghlan
> --
> Drew Derbyshire
>
> "All right, Mr. DeMille, I'm ready for my close-up." -- "Sunset Blvd.,"
>
>
|
Question:
¨C?What should be used to move or clear large blocks of data? ¡ì?Answer: ¡ì?There are several ways to move or clear a large block of storage provided in the z/Architecture One MVCL instruction Loops of MVCs to move data Loops of MVC <Len>,<Addr>+1,<Addr> or XC <Len>,<Addr>,<Addr> to pad/clear an area
¡ì?As discussed on page 31 titled ¡°MOVE LONG instructions¡±,?¨C?MVCLisimplementedthroughmillicoderoutines
¨C?Millicodeisafirmwarelayerintheformofverticalmicrocode ??Incurs some overhead in startup, boundary/exception checking, and ending
¨C?MVCLfunctionimplementedusingloopsofMVCsorXCs
¨C?Millicodehasaccesstospecialnear-memoryenginesthatcandopage-alignedmoveandpage-alignedpadding Can be faster than dragging cache lines through the cache hierarchy However, the destination data will NOT be in the local cache ¡ì?As such, the answer is ¡°it depends¡± as there is no one answer to all situations. There are many factors to consider?¨C?Willthetargetbeneededinlocalcachesoon?
??Then moving/padding ¡°locally¡± will be better by using MVCs or XCs?¨C?Isthesourceinlocalcache? ??Then moving/padding ¡°locally¡± may be better by using MVCs, or XCs?¨C?Howmuchdataisbeingprocessed? ??The more data you are required to process, the more you may benefit from using MVCL due to special hardware engines used by millicode ¨C?Experimentationis,therefore,highlyadvised
On Wed, Apr 15, 2020 at 6:00 PM Tony Harminc < tharminc@...> wrote: On Wed, 15 Apr 2020 at 17:47, Joe Monk <joemonk64@...> wrote:
> No doubt ... but MVCL/E are still millicode instructions. MVC is a hardware instruction.
Little is that simple these days...
> MOVE characters (MVC)
> ¨C If <=16 bytes, it is cracked into separate load and store ¦Ìops
> ¨C If > 16 bytes, it is handled by a hardware sequencing logic inside the LSU
> ¨C If the destination address is 1 byte higher than the source address
> (and they overlap), it is special cased into hardware as a 1-byte
> storage padding function (with faster handling)
> ¨C If the destination address is 8 byte higher than the source address
> (and they overlap), it is special cased into hardware as a 8-byte
> storage padding function (with faster handling)
> ¨C If other kinds of address overlaps, it will be forced into millicode
> to be handled a byte at a time
> MOVE LONG
? A special engine is built per CP chip for aligned copying or padding
functions at a page granularity
¨C The page-aligned copying or padding is done ¡°near memory¡±, instead
of through caches, if
? Not executed inside a transaction
? Padding character specified is neither X¡¯B1¡¯ nor X¡¯B8¡¯
? A preceding NIAI instruction does not indicate that the storage data
will be used subsequently
? The operands must not have an access exception
? Length >= 4K bytes
? For moves: source and destination addresses are both 4K-byte aligned
? For padding: destination address is 4K-byte aligned
¨C Otherwise, the move process will operate through the caches (L1, L2¡)
¨C Note that the evaluation is revised every unit-of-op
¨C For padding, even if starting address is not aligned, millicode pads
in cache to the first 4K-byte boundary, then uses ¡°near
memory¡± pad engine for the next aligned 4K-byte pages until the
remaining length is less than 4K bytes. After that,
padding is done in cache again
? Near-Memory engine usage is best when the amount of data involved is
large and the target memory is not to be
immediately consumed in subsequent processes
¨C Since the special engine is shared within a CP chip, contention
among processors is possible
¨C Such contention is handled transparently by millicode and additional
delay may be observed
Tony H.
|
On Wed, 15 Apr 2020 at 17:47, Joe Monk <joemonk64@...> wrote: No doubt ... but MVCL/E are still millicode instructions. MVC is a hardware instruction. Little is that simple these days... MOVE characters (MVC)
¨C If <=16 bytes, it is cracked into separate load and store ¦Ìops
¨C If > 16 bytes, it is handled by a hardware sequencing logic inside the LSU
¨C If the destination address is 1 byte higher than the source address
(and they overlap), it is special cased into hardware as a 1-byte
storage padding function (with faster handling)
¨C If the destination address is 8 byte higher than the source address
(and they overlap), it is special cased into hardware as a 8-byte
storage padding function (with faster handling)
¨C If other kinds of address overlaps, it will be forced into millicode
to be handled a byte at a time MOVE LONG ? A special engine is built per CP chip for aligned copying or padding functions at a page granularity ¨C The page-aligned copying or padding is done ¡°near memory¡±, instead of through caches, if ? Not executed inside a transaction ? Padding character specified is neither X¡¯B1¡¯ nor X¡¯B8¡¯ ? A preceding NIAI instruction does not indicate that the storage data will be used subsequently ? The operands must not have an access exception ? Length >= 4K bytes ? For moves: source and destination addresses are both 4K-byte aligned ? For padding: destination address is 4K-byte aligned ¨C Otherwise, the move process will operate through the caches (L1, L2¡) ¨C Note that the evaluation is revised every unit-of-op ¨C For padding, even if starting address is not aligned, millicode pads in cache to the first 4K-byte boundary, then uses ¡°near memory¡± pad engine for the next aligned 4K-byte pages until the remaining length is less than 4K bytes. After that, padding is done in cache again ? Near-Memory engine usage is best when the amount of data involved is large and the target memory is not to be immediately consumed in subsequent processes ¨C Since the special engine is shared within a CP chip, contention among processors is possible ¨C Such contention is handled transparently by millicode and additional delay may be observed Tony H.
|
Re: OT, mail issues, was Re: [h390-vm] memset help
Does your email server implement?SPF, DKIM and DMARC?
Mine? Yes, no and no. I'm pretty sure I haven't suffered from any instances of spam runs sent out with my domain name forged as the source address although I am not sure I can believe that the spammers are smart enough to have checked for the existance of SPF and decided that this would make it not a worthwhile thing to do. I really only have it so that if this did happen, the recipients would have an opportunity to identify what they are receiving as forged and unauthorised. Regards, Peter Coghlan.
|
Re: OT, mail issues, was Re: [h390-vm] memset help
Dave,
I don't think I have never seen anything from you marked as "Junk". Some providers don't like groups.io so it might not be you.
I really find most SPAM filters unbelievably bad and I used to manage some very expensive ones.
They allow some utter garbage through whilst often blocking good e-mails.
Why can't they block "PayPal account restricted" messages that have not been anywhere near PayPal.
I can do a much better job than most filters just by looking at from/subject...
I am sure much I get is from having a Taj hotels loyalty card.
As I am sure you know your servers and domains are clean on
Dave
toggle quoted message
Show quoted text
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Dave
McGuire
Sent: 15 April 2020 21:40
To: [email protected]
Subject: OT, mail issues, was Re: [h390-vm] memset help
On 4/15/20 2:07 PM, Peter Coghlan wrote:
(By the way, I replied to your recent "Inquiring minds" email but I
fear you may not have seen my reply as Google tends to route anything
I send these days into their recipients spam folder or otherwise
quarantine it. Apparantly Google regards me as a notorious source of spam or something for some time now.
I also sent emails to other Google mail users both on the this list
not and these also seem to have disappeared into black holes...) I am noticing this to an increasing degree as well. My assumption is that
Google, having spent years pushing "free" email services while making
money on the back end by using the information they mine from it, are now
trying to push yet more people to use gmail accounts.
My mail server predates the very existence of Google as a company by
many years, and has only been use as a spam relay once, a decade ago, for
not quite a day, until I noticed that one of my hundred-or-so users
passwords had been cracked. The only reason I can see for email originating
from my server to be considered spam by Google is that it comes from a non-
gmail server.
This is just my assumption; I have no evidence to suggest that this is why
this is happening, it but it is the only explanation that I've been able to come
up with for this widespread and rapidly growing problem.
This is what happens when people take the lazy or cheap route and get a
"free" email account from a for-profit corporation. Google occasionally does
good things for society, but they are not a charity.
As many have said, and almost nobody actually pays attention to: If you
receive value from a corporation for free, you are the product.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
|
Mark,
No doubt ... but MVCL/E are still millicode instructions. MVC is a hardware instruction.
Joe
On Wed, Apr 15, 2020 at 4:28 PM Mark L. Gaubatz via <mgaubatz= [email protected]> wrote: Joe: ? $MVCL was written many, many years ago. At the time, it was faster on certain machines. Need to re-validate this claim. ? Also, at the time the macro was written, the cachelines were shorter. On several machines, MVCL performed additional checks whenever crossing a cacheline. On others, it was at page boundaries. Consequently, on some machines, $MVCL was faster, on others, slower. It entirely depends on the underlying firmware and hardware implementing the two instructions. ? So please remember, some of the ¡°official¡± text when referring to performance is long outdated. ? Mark ? ? ? Even IBM admits that multiple?MVCs are faster than MVCL... "Use $MVCL to generate a MVC (move character) instruction when you need to move more than 256 bytes of storage. Use this macro instruction in high performance areas because multiple MVCs (as created by this macro) are faster than using an MVCL instruction." ? On Wed, Apr 15, 2020 at 1:11 PM Peter Coghlan <groups@...> wrote: Drew Derbyshire wrote:
> On 4/14/20 11:32 PM, Peter Coghlan wrote:
> > I wonder could this have been the COBOL compiler abusing MVCL instructions
> > in situations where they were not the appropriate instructions to use?
> >
> > Perhaps instructions such as MVCL would be expected to be "hot spots" because
> > they can deliver a relatively large amount of work for a single instruction?
> > Or is it that implementations of this instruction were sometimes poorer than
> > they ought to be and they were really not delivering bang for buck?
> I was told back in the 1980s that for performance reasons MUSIC moved
> 4096 bytes of data via a series of MVC commands in place of one MVCL.
>
Drew,
This is very interesting given our recent discussion on the matter.
(By the way, I replied to your recent "Inquiring minds" email but I fear you
may not have seen my reply as Google tends to route anything I send these days
into their recipients spam folder or otherwise quarantine it.? Apparantly
Google regards me as a notorious source of spam or something for some time now.
I also sent emails to other Google mail users both on the this list not and
these also seem to have disappeared into black holes...)
Regards,
Peter Coghlan
> --
> Drew Derbyshire
>
> "All right, Mr. DeMille, I'm ready for my close-up." -- "Sunset Blvd.,"
>
>
|
Joe: ? $MVCL was written many, many years ago. At the time, it was faster on certain machines. Need to re-validate this claim. ? Also, at the time the macro was written, the cachelines were shorter. On several machines, MVCL performed additional checks whenever crossing a cacheline. On others, it was at page boundaries. Consequently, on some machines, $MVCL was faster, on others, slower. It entirely depends on the underlying firmware and hardware implementing the two instructions. ? So please remember, some of the ¡°official¡± text when referring to performance is long outdated. ? Mark ? ?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of Joe Monk Sent: Wednesday, April 15, 2020 11:32 AM To: [email protected]Subject: Re: [h390-vm] memset help ? Even IBM admits that multiple?MVCs are faster than MVCL... "Use $MVCL to generate a MVC (move character) instruction when you need to move more than 256 bytes of storage. Use this macro instruction in high performance areas because multiple MVCs (as created by this macro) are faster than using an MVCL instruction." ? On Wed, Apr 15, 2020 at 1:11 PM Peter Coghlan <groups@...> wrote: Drew Derbyshire wrote:
> On 4/14/20 11:32 PM, Peter Coghlan wrote:
> > I wonder could this have been the COBOL compiler abusing MVCL instructions
> > in situations where they were not the appropriate instructions to use?
> >
> > Perhaps instructions such as MVCL would be expected to be "hot spots" because
> > they can deliver a relatively large amount of work for a single instruction?
> > Or is it that implementations of this instruction were sometimes poorer than
> > they ought to be and they were really not delivering bang for buck?
> I was told back in the 1980s that for performance reasons MUSIC moved
> 4096 bytes of data via a series of MVC commands in place of one MVCL.
>
Drew,
This is very interesting given our recent discussion on the matter.
(By the way, I replied to your recent "Inquiring minds" email but I fear you
may not have seen my reply as Google tends to route anything I send these days
into their recipients spam folder or otherwise quarantine it.? Apparantly
Google regards me as a notorious source of spam or something for some time now.
I also sent emails to other Google mail users both on the this list not and
these also seem to have disappeared into black holes...)
Regards,
Peter Coghlan
> --
> Drew Derbyshire
>
> "All right, Mr. DeMille, I'm ready for my close-up." -- "Sunset Blvd.,"
>
>
|
Re: REXX Interpreter immediate commands
Bob ... Noted
Am I right in assuming that the concept of processes receiving signals / interrupts, and of registering signal handlers is just alien to VM/370 and can be ignored?
A
|
Re: OT, mail issues, was Re: [h390-vm] memset help
Does your email server implement?SPF, DKIM and DMARC?
A
|
Re: GCCLIB - Double Branch on calls to RESLIB library - needed?
On Tue, Apr 14, 2020 at 02:51 PM, Joe Monk wrote:
LA R15,0(R15) would add 0 to the value of R15. I dont?think thats what you want.
Perhaps I mean just L? Anyway I am guessing from silence that the double branch is as good as it gets!
|
OT, mail issues, was Re: [h390-vm] memset help
On 4/15/20 2:07 PM, Peter Coghlan wrote: (By the way, I replied to your recent "Inquiring minds" email but I fear you
may not have seen my reply as Google tends to route anything I send these days
into their recipients spam folder or otherwise quarantine it. Apparantly
Google regards me as a notorious source of spam or something for some time now.
I also sent emails to other Google mail users both on the this list not and
these also seem to have disappeared into black holes...) I am noticing this to an increasing degree as well. My assumption is that Google, having spent years pushing "free" email services while making money on the back end by using the information they mine from it, are now trying to push yet more people to use gmail accounts. My mail server predates the very existence of Google as a company by many years, and has only been use as a spam relay once, a decade ago, for not quite a day, until I noticed that one of my hundred-or-so users passwords had been cracked. The only reason I can see for email originating from my server to be considered spam by Google is that it comes from a non-gmail server. This is just my assumption; I have no evidence to suggest that this is why this is happening, it but it is the only explanation that I've been able to come up with for this widespread and rapidly growing problem. This is what happens when people take the lazy or cheap route and get a "free" email account from a for-profit corporation. Google occasionally does good things for society, but they are not a charity. As many have said, and almost nobody actually pays attention to: If you receive value from a corporation for free, you are the product. -Dave -- Dave McGuire, AK4HZ New Kensington, PA
|
toggle quoted message
Show quoted text
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Harold
Grovesteen
Sent: 15 April 2020 20:15
To: [email protected]
Subject: Re: [h390-vm] memset help
On Wed, 2020-04-15 at 14:25 +0100, Dave Wade wrote:
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Harold
Grovesteen
Sent: 15 April 2020 14:15
To: [email protected]
Subject: Re: [h390-vm] memset help
On Wed, 2020-04-15 at 13:24 +0100, Steven Fosdick wrote:
I did wonder about the possibility of setting up gcc as a
cross-compiler but that doesn't seem trivial to do.
Steve.
Yes. I did accomplish this and it is documented with scripts in the
SATK. It used GNU as as the assembler for stand alone, aka bare
metal, coding on Hercules. After literally years of work on that,
it just did not work well enough and I changed to a new toolset that
is part of the project.
However, the key difference between GCC on VM and other operating
systems supported by Hercules and GCC as used on Linux is the output
format. GCC typically generates ELF object module files. The GCC
on VM generates mainframe object modules. Huge difference and a
fundamental reason this GCC is used with the operating systems that
run on Hercules.
With my pedants' hat on, it actually generates "normal" Assembler that
is assembled by the XF assembler on VM or MVS.
That is why we get "normal" object files which can be loaded with the
VM loader or the OS Linkage Editor.
I have tried feeding the assembler into Assembler G with poor results.
I haven't tried Assembler H...
.... its pretty easy to produce a GCC that compiles 370 code on
Windows/Linux. After all that¡¯s how I built the first GCCCMS.
Getting all the assembler to CMS to compile it was the fun part..
No, doubt.
Yes, the generated assembler is the path to the object. And the object
dictates where the program can run.
BTW, can CMS compile GCC on VM/370? There were issues with that on
MVS. Originally it could on VM/370, but not on SP or later because you lose memory. I don't know how Paul builds it these days, he may use the 380 mods.. There were some modules that needed different optimization, but I can't remember which ones they were. Because CMS is so small you get more usable memory than on MVS. Dave
Harold Grovesteen
Dave
|
On Wed, 2020-04-15 at 14:25 +0100, Dave Wade wrote:
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Harold
Grovesteen
Sent: 15 April 2020 14:15
To: [email protected]
Subject: Re: [h390-vm] memset help
On Wed, 2020-04-15 at 13:24 +0100, Steven Fosdick wrote:
I did wonder about the possibility of setting up gcc as a
cross-compiler but that doesn't seem trivial to do.
Steve.
Yes.??I did accomplish this and it is documented with scripts in
the SATK.??It
used GNU as as the assembler for stand alone, aka bare metal,
coding on
Hercules.??After literally years of work on that, it just did not
work well
enough and I changed to a new toolset that is part of the project.
However, the key difference between GCC on VM and other operating
systems supported by Hercules and GCC as used on Linux is the
output
format.??GCC typically generates ELF object module files.??The GCC
on VM
generates mainframe object modules.??Huge difference and a
fundamental
reason this GCC is used with the operating systems that run on
Hercules.
With my pedants' hat on, it actually generates "normal" Assembler
that is assembled by the XF assembler on VM or MVS.
That is why we get "normal" object files which can be loaded with the
VM loader or the OS Linkage Editor.
I have tried feeding the assembler into Assembler G with poor
results.
I haven't tried Assembler H...
.... its pretty easy to produce a GCC that compiles 370 code on
Windows/Linux. After all that¡¯s how I built the first GCCCMS.
Getting all the assembler to CMS to compile it was the fun part..
No, doubt. Yes, the generated assembler is the path to the object. ?And the object dictates where the program can run. BTW, can CMS compile GCC on VM/370? ?There were issues with that on MVS.
Harold Grovesteen
Dave
|
On Wed, 2020-04-15 at 07:25 -0700, adriansutherland67 wrote: On Wed, Apr 15, 2020 at 08:02 AM, adriansutherland67 wrote:
it takes me about 5 mins to write a single line of S/370 assembler
not counting debugging!
I do indeed loath assembler - especially as I use the "infinite
number of monkeys" method - however I have managed to detect the
stack running out of space. Big day!
A
? That is how we all learned. ?Getting slapped a few times helps with the memory. ?There is no way to learn assembler, like any language, without doing it. When I started, application programs were frequently written in assembler. ?One shop I worked at, had a large CICS system with all applications in assembler. Harold
|
Even IBM admits that multiple?MVCs are faster than MVCL...
" Use $MVCL to generate a MVC (move character) instruction when you need to move more than 256 bytes of storage. Use this macro instruction in high performance areas because multiple MVCs (as created by this macro) are faster than using an MVCL instruction."
Joe
On Wed, Apr 15, 2020 at 1:11 PM Peter Coghlan < groups@...> wrote: Drew Derbyshire wrote:
> On 4/14/20 11:32 PM, Peter Coghlan wrote:
> > I wonder could this have been the COBOL compiler abusing MVCL instructions
> > in situations where they were not the appropriate instructions to use?
> >
> > Perhaps instructions such as MVCL would be expected to be "hot spots" because
> > they can deliver a relatively large amount of work for a single instruction?
> > Or is it that implementations of this instruction were sometimes poorer than
> > they ought to be and they were really not delivering bang for buck?
> I was told back in the 1980s that for performance reasons MUSIC moved
> 4096 bytes of data via a series of MVC commands in place of one MVCL.
>
Drew,
This is very interesting given our recent discussion on the matter.
(By the way, I replied to your recent "Inquiring minds" email but I fear you
may not have seen my reply as Google tends to route anything I send these days
into their recipients spam folder or otherwise quarantine it.? Apparantly
Google regards me as a notorious source of spam or something for some time now.
I also sent emails to other Google mail users both on the this list not and
these also seem to have disappeared into black holes...)
Regards,
Peter Coghlan
> --
> Drew Derbyshire
>
> "All right, Mr. DeMille, I'm ready for my close-up." -- "Sunset Blvd.,"
>
>
|
Dave McGuire