LINKMVS vs ATTCHMVS
Robert Zenuk
Recently, we have had a problem with SDSF that was traced back to using SDSF
in batch from a REXX EXEC I wrote.
This was happening under OS/390 V2R8 and remained after we completed our
migration to OS/390 V2R10. The symptoms are S001 RC01, S878 RC10 and U0005
dumps. We have an open PMR with IBM and there is a PTF that will take a
while to make the rounds and end up on all of our systems.
As a work around IBM recommended changing the LINK to an ATTACH. I changed
my REXX code to use ATTCHMVS instead of LINKMVS and everything still works
and the abend did not occur.
This is probably a hole in my knowledge (amoung many), but I don't understand
the difference between the LINKMVS and ATTCHMVS Host Command Environments.
The TSO REXX Reference always refers to them together in the same sentence
and doesn't differentiate or make any recommendations. I suspect these are
REXX implementations of the LINK and ATTACH macros. After reading the
descriptions for ATTACH and LINK in the OS/390 V2R10 MVS Assembler Services
Reference, the only difference I see is that ATTACH creates a new subtask.
From a REXX perspective, when would you want to use LINKMVS vs ATTCHMVS? Are
there any performance implications of either decision?
Almost all of my uses tend to be once per EXEC. Would I make a different
decision if I was using this inside a loop?
If there is a good description in the IBM manuals of LINK and ATTACH
somewhere that I have missed, please pass on the reference.
Thanks in Advance,
Robert Zenuk
robz...@aol.com
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
Jeremy C B Nicoll
> I have been using LINKMVS to invoke programs from REXX. It works well.
> Recently, we have had a problem with SDSF that was traced back to using
> SDSF in batch from a REXX EXEC I wrote.
> This was happening under OS/390 V2R8 and remained after we completed
> our migration to OS/390 V2R10. The symptoms are S001 RC01, S878 RC10
> and U0005 dumps. We have an open PMR with IBM and there is a PTF that
> will take a while to make the rounds and end up on all of our systems.
S878 in SDSF can be caused by having excessively large parameter datasets
(ie too many ISFGRP definitions etc).
> As a work around IBM recommended changing the LINK to an ATTACH. I
> changed my REXX code to use ATTCHMVS instead of LINKMVS and everything
> still works and the abend did not occur.
When you getmain storage for something it is possible to determine
characteristics of the virtual storage concerned, including whowhat owns
it. If SDSF getmains store asking that it be owned at a task level
perhaps there's not enough of that left unless SDSF is running under its
own TCB.
LINKMVS & ATTCHMVS do relate directly to the LINK & ATTACH macros. One
reason for using ATTCHMVS is that the task & sub-task control block
structure (ie TCB chain) for the address space looks more like that of a
normal batch jcl job-step task - that is ATTCHMVS for 'yourprog' has a
TCB structure quite like EXEC PGM=yourprog whereas LINKing to yourprog
from something else doesn't give yourprog a TCB of its own. That can
affect things like APF authorisation, and SAF/RACF authorisation.
--
Jeremy C B Nicoll - my opinions are my own.
OneHandClapping
overhead than link since you are creating a new dispatchable unit of
work. attach does have the benefit that non-shared storage subpools are
automatically freed by the os at termination.... apparently what sdsf is
not doing for you.
Robert Zenuk wrote:
> <snip>
>
> From a REXX perspective, when would you want to use LINKMVS vs ATTCHMVS? Are
> there any performance implications of either decision?
>
<snip>