This forum needs some action 
Author Message
 This forum needs some action

My Dad always told me "do something even if it's wrong".  So ...

This forum appears to be DIE'ng.

Someone tell some stories of L vs. LA snafus please.

Talk about 'old' issues: 24 vs. 31 bit addressing, practical experience
with I/O related issues.  I went thru' some hell with that.

If you have experience with data spaces please talk about them.
Explain the practicalities of AR's.

Give me a practical example of the use of SUSPEND / REUSME.

Give me a 2 liner (I'll make it easy).  One MACRO and one instructon
that brings a machine to it's knees.

Well, enough ranting for now.

Guy

Sent via Deja.com http://www.*-*-*.com/
Before you buy.



Sat, 24 May 2003 13:23:09 GMT  
 This forum needs some action
<snip>

Quote:
> Give me a 2 liner (I'll make it easy).  One MACRO and one instructon
> that brings a machine to it's knees.

> Well, enough ranting for now.

> Guy

> Sent via Deja.com http://www.deja.com/
> Before you buy.

Let me see, how about issuing the following instruction where R1
points to ASCBID of the #1 ASCB (I'm assuming KEY0 set in PSW):

    MVI  0(R1),C'a'            Change Eyecatcher to lower case
      .
      .
      .

System loads a wait state as I recall, right about the time your
TCB/RB/SRB terminates.

--
Steve Thompson
OSP LLC
330/335-9907 office
330/334-2097 fax

Remove "_" in email address to contact me -- anti-spam measures
in use



Sat, 24 May 2003 03:00:00 GMT  
 This forum needs some action
"one instructon
that brings a machine to it's knees."

    J    *

or if you better like

    BRC  15,*

you rigth there is a low action here :-)

Brian


Quote:
> My Dad always told me "do something even if it's wrong".  So ...

> This forum appears to be DIE'ng.

> Someone tell some stories of L vs. LA snafus please.

> Talk about 'old' issues: 24 vs. 31 bit addressing, practical experience
> with I/O related issues.  I went thru' some hell with that.

> If you have experience with data spaces please talk about them.
> Explain the practicalities of AR's.

> Give me a practical example of the use of SUSPEND / REUSME.

> Give me a 2 liner (I'll make it easy).  One MACRO and one instructon
> that brings a machine to it's knees.

> Well, enough ranting for now.

> Guy

> Sent via Deja.com http://www.deja.com/
> Before you buy.



Sat, 24 May 2003 03:00:00 GMT  
 This forum needs some action
quantity seems to be your main focus as I believe quality should be the main
focus
I'm happy with this forum because the members are very qualified doesn't
matter
if there are so much traffic.

Please note there is big other forum for questions about assembler and this
is called
IBM-Main.

At this time we should talk about 64 vs 31 bit addressing.

As I'm the (so called) supervisior for the ShowMvs-development I can tell
you
the next version (called 627) will be OS/390 R10 friendly. I plan to release
this
within the next two weeks. Unfortunally there is a bug on one side I'll have
to fix
and time is limited.

Roland



Quote:
> My Dad always told me "do something even if it's wrong".  So ...

> This forum appears to be DIE'ng.

> Someone tell some stories of L vs. LA snafus please.

> Talk about 'old' issues: 24 vs. 31 bit addressing, practical experience
> with I/O related issues.  I went thru' some hell with that.

> If you have experience with data spaces please talk about them.
> Explain the practicalities of AR's.

> Give me a practical example of the use of SUSPEND / REUSME.

> Give me a 2 liner (I'll make it easy).  One MACRO and one instructon
> that brings a machine to it's knees.

> Well, enough ranting for now.

> Guy

> Sent via Deja.com http://www.deja.com/
> Before you buy.



Sun, 25 May 2003 07:23:21 GMT  
 This forum needs some action

Quote:

> My Dad always told me "do something even if it's wrong".  So ...

> This forum appears to be DIE'ng.

> If you have experience with data spaces please talk about them.
> Explain the practicalities of AR's.

> Give me a 2 liner (I'll make it easy).  One MACRO and one instructon
> that brings a machine to it's knees.

Well, this didn't exactly bring the machine to its knees ... just an
initiator.

I had created a dataspace that was around 300MB in size.  I tried to
initialise the whole thing with a single MVCL (in 31-bit amode, of course).
The job locked up.  I couldn't cancel it.  Operations couldn't cancel it.
Our systems programmers couldn't cancel it.  In the end they just left it
sitting there until the next IPL.

I never did managed to definitely work out what caused the lock-up.
My best guess was that the system was reluctant to page out parts of
the dataspace in the middle of an instruction, and thus was quietly
waiting for more physical storage to be added.

Breaking the initialisation up into a number of smaller MVCLs solved
the problem, anyway...

Cheers,
Allen



Tue, 27 May 2003 04:50:45 GMT  
 This forum needs some action

Quote:

>I had created a dataspace that was around 300MB in size.  I tried to
>initialise the whole thing with a single MVCL (in 31-bit amode, of course).
>The job locked up.  I couldn't cancel it.  Operations couldn't cancel it.
>Our systems programmers couldn't cancel it.  In the end they just left it
>sitting there until the next IPL.

>I never did managed to definitely work out what caused the lock-up.
>My best guess was that the system was reluctant to page out parts of
>the dataspace in the middle of an instruction, and thus was quietly
>waiting for more physical storage to be added.

>Breaking the initialisation up into a number of smaller MVCLs solved
>the problem, anyway...

>Cheers,
>Allen

I hope you realise that MVCL isn't really long in 31-bit mode -- it can
move at most 16M-1 since it has a 24-bit length field, even in 31-bit mode.
You need MVCLE for this (in a loop), or you could use one of the programming
tricks that lets you use MVCL in a loop without using extra registers (four
is bad enough for one instruction!).

Btw, page faults "in the middle" of MVCL are not the issue, since MVCL is
interruptible.  The hardware breaks the move into little pieces anyway.
What may have happened is that some software monitoring mechanism got
confused by seeing no apparent change in the PSW for a looong time (from
the perspective of a running program), even though registers did change.

Michel.



Tue, 27 May 2003 10:00:06 GMT  
 This forum needs some action

Quote:

>when you mentioned it.  Silly me.  Of course, I may have misremembered what
>I was trying to do (it was a few years ago), or may have made the same
error
>back then too. :)

IIRC you were trying to initialise an LDS. The problem may have been that
the VS system would not page out any of your pages until you had done a
commit, and you could not do the commit because you had not finished the
MVCL.

HTH.

    John Homes

Quote:

>Cheers,
>Allen



Fri, 30 May 2003 03:43:27 GMT  
 This forum needs some action

Quote:

>I am curious, though, about the "program tricks" you mention.  Care to
>elaborate?  The first such trick that springs to mind might be to use the
>the top byte of the first-operand length register for a counter in some
>fiddly way, but I'm not totally sure (without a bit of mucking around)
>that this would work.

Here it is:

*
*     A padding MVCL can easily be turned into a loop, without
*     requiring the extra-long instructions, provided the source
*     length is short (e.g. pure padding).   MH, April 1987
*
*        R0 = target addr
*        R1 = length (unrestricted, but non-zero
*                     if CC is to be set right)
*        R2 = source addr, if sourcel > 0
*        R3 = AL1(pad),AL3(sourcel)   sourcel < 16M; may be 0
*
*     Size of MVCL replacement: 20 bytes
*
*     Note: the first MVCL will detect destructive overlap (which
*           is possible only when sourcel > 0).  If this must be
*           checked, insert  'BO   *+22' after the first MVCL and
*           replace '*-16' with '*-20' on the 'BNH' at the end.
*
         MVCL  0,2            Do as much as possible
         SL    1,=X'00800000' Ready for another 8M
         BL    *+6            Skip if done (clear R1 with AL)
         MVCL  0,2            Fill next 8M
         AL    1,=X'00800000' Restore length
         BNH   *-16           Loop back unless done (to first MVCL)
*
*     We even get CC=2 as expected by a padding MVCL.  (This
*     would be wrong if the initial target length were 0.)
*

The 8M-at-a-clip MVCL loop can also be used when source and target
have the same length, as in:

*
*     A non-padding MVCL can easily be turned into a loop, without
*     requiring the extra-long instructions, provided the source
*     length equals the target length, and it is already known
*     that there is no destructive overlap.  MH, April 1987
*
*
*     Size of MVCL replacement: 26 bytes
*
*        R0 = target addr
*        R1 = length (unrestricted)
*        R2 = source addr
*        R3 = R1
*
*        R0 <= R2   or   R0 >= R2+R3
*
         MVCL  0,2            Do as much as possible
         L     3,=X'00800000' Ready for another 8M
         SLR   1,3            Twiddle target length
         BL    *+10           Skip if done (clear R1 with ALR)
         MVCL  0,2            Copy next 8M
         L     3,=X'00800000' Ready for missing 8M
         ALR   1,3            Restore length
         BNH   *-20           Loop back unless done (to first MVCL)
         SR    3,3            Clear remaining source length, set CC=0

If destructive overlap needs to be checked first, it can be
done thus, before the MVCL code above:

*
*     Check for destructive overlap before attempting an
*     equal-length move (with unrestricted length).  The
*     addresses must be clean, and the operands must not
*     wrap at 2G.  (MH, Sept 1990)
*
*     Size: 12 bytes (in addition to the 26-byte MVCL code)
*
*        R0 = target addr
*        R1 = length (unrestricted)
*        R2 = source addr
*        R3 = R1
*
         LR    3,2            Compute...
         SLR   3,0            ...offset
         ALR   3,1            Check for overlap
         LR    3,1            (Meanwhile recover source length)
         BO    *+30           Skip MVCL code if so (CC=3)

These methods use the same four registers as the simple MVCL being replaced,
except that they also require local addressability for the branches and the
literal (so technically one extra register is required -- but it is usually
available anyway).  The main drawback is extra code size when there are many
instances -- this might blow local addressability.  Performance is not an
issue -- even when the length is short the start-up overhead of MVCL will
probably exceed the cost of the two branches (one taken, one not).

On modern hardware you might not have local addressability because the code
uses jumps instead of branches -- but then you could also use MVCLE directly.

Btw, dealing with CLCL is much harder.  Luckily there tend to be fewer of
those.  I used to deal with these by performing a length check, and to trap
on an unimplemented instruction (basically, CLCLE before it existed) which
would then be emulated by the operating system.  The length check was to
avoid the cost of the trap -- logically it wasn't required.  I actually
handled MVCL the same way (I had MVCEL an CLCEL macros -- I almost guessed
the mnemonic and format that was eventually defined, and I still think the
EL suffix is more logical -- Extra Long -- than LE (Long Extended)), because
this allowed me to replace instances bindly.  The 8M-at-a-clip loops require
understanding the purpose of the MVCL being replaced, to pick the right one.
Also, the case of both lengths extra long but unequal is not handled at all
with my loops.  I did use the loops in a few places in the kernel, however.

Michel.



Sat, 31 May 2003 00:58:41 GMT  
 This forum needs some action

Use  DSPSERV RELEASE  rather than MVCL (or serveral MVCL's)  as recommended
in the OS/390 MVS Assembler Services Guide.


Quote:


> >I had created a dataspace that was around 300MB in size.  I tried to
> >initialise the whole thing with a single MVCL (in 31-bit amode, of
course).
> >The job locked up.  I couldn't cancel it.  Operations couldn't cancel it.
> >Our systems programmers couldn't cancel it.  In the end they just left it
> >sitting there until the next IPL.

> >I never did managed to definitely work out what caused the lock-up.
> >My best guess was that the system was reluctant to page out parts of
> >the dataspace in the middle of an instruction, and thus was quietly
> >waiting for more physical storage to be added.

> >Breaking the initialisation up into a number of smaller MVCLs solved
> >the problem, anyway...

> >Cheers,
> >Allen



Thu, 07 Aug 2003 04:35:08 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Forum ITALIANO - ITALIAN Forum

2. New forum for HLA at the win32asm forum.

3. Forum Moderator needed

4. The need for a moderated forum.

5. Middleweight Threaded Forum App'n Needed

6. Need Email groups and forum code for Tcl site

7. How can I include in my VI actions like "Undo last action/redo last action"?

8. On deferred actions

9. Deferred actions: 'SW ViewActionQueue.pac'

10. Menus cause arbitrary delay of deferred actions?

11. Taking an action based on closing a window

 

 
Powered by phpBB® Forum Software