RC 70 in an SFS related environment can be many many things...
As mentioned, do use COMMAND and *not* the CMS stage except in servers
to execute commands sent by end-users (as long as I'm not retired, the
public here expects me to react on this).
Using COMMAND also makes that you don't get error messages nor command
response headers. To get the headers and the error message back,
prefix the CMS commands by CMDCALL.
QUERY LIMITS (and some other SFS commands) are "atomic", that is they
refuse to work when, there is uncommited work, I guess the the insert
of >> stages caused some extra commits... I'd store the intermediate
results in a STEM and wreite the stems to a CMS file in a second PIPE.
Hence:
'PIPE (end \)',
'\ command CMDCALL QUERY LIMITS ALL',
'| VAR EMSG1',
'| drop 1',
'| spec /CMDCALL LISTDIR/ 1 w1 nw /./ n',
'| STEM LsDirCmd.',
'| command',
'| STEM LsDirRes.', '| pick w1 ¬== /Fm/',
'| spec /CMDCALL QUERY AUTH/ 1 w2 nw',
'| STEM QauthCmd.',
'| command',
'| STEM QauthRes.',
...
'| sort',
...
'PIPE (end \) STEM LsDirCmd. |> LSDIR CMDS A',
'\STEM LsDirRes.|> LSDIR RES A', ......
And, to end, here the blabla I saved in a REXX MODEL file to handle
the SFS workunit problems:
/* PIPE STATE fn ft dirid ! ... leaves workunit open if the file
! is found. This then results in:
! DMSQRQ1157E Work unit already active when atomic request...
! Solution: commit the workunit. Example
! 'PIPE LITERAL T T .!STATE ISODATE!CONS'
! call csl 'DMSCOMM RETC REAS'; say retc reas
! 'CMDCALL QUERY LIMITS *' /* Would fail without DMSCOMM*/
*/
/* Similar, when a file is open and a workunit is active, some
! cmds give: DMSQRQ1157E Work unit already active when atomic..
! Solution: get a new workunit. Example
! call csl 'DMSGETWU RETC REAS WID1' /* Get a workunit */
! call csl 'DMSPUSWU RETC REAS WID1' /* Start using it */
! 'CMDCALL QUERY LIMITS *'
! call csl 'DMSPOPWU RETC REAS' /* Use prev Wunit */
! call csl 'DMSRETWU RETC REAS WID1' /* Delete new Wunit */
*/
2009/4/7 Glenn Knickerbocker <[email protected]>:
> "Schuh, Richard" wrote:
>> This Pipe was failing with an immediate RC=70.
>
> That's got to be from one of your CMS commands, not Pipelines. RC 70
> from Pipelines (PIPE AHELP 70) is:
>
> 70E Incorrect OS record descriptor word X'<hex>'
>
> Not something you're likely to be running into in the output of CMS
> commands. RC 70 from many CMS commands (HELP CMS RETCODES) is:
>
> 70 File sharing conflict. This includes locking conflicts and
> failures caused by uncommitted changes.
>
> Maybe writing the intermediate output or delaying the record is breaking
> up some conflict of timing in your other output from the pipeline. Any
> chance you have two >> stages trying to write to the same SFS file at
> the same time?
>
> ¬R
>
--
Kris Buelens,
IBM Belgium, VM customer support
