So I have another problem.
I have changed my code to use the method suggested by John - THANK YOU - it
works great.
But if the member does not exist, I get 013-18
10.40.39 JOB25080 IEC141I 013-18,IGG0191B,XXFSHIGH,MQ,CNTLI,6066,TSUPBG, 907
907 CICST.MQDEF.Q.MQMQ.CNTL.STAGE(CSVXXFS1)
907 ERROR DESCRIPTION: IEC141I
907 An OPEN macro instruction was issued for a partitioned data
set. The
907 DSNAME parameter specified a member that could not be found.
907 END ERROR DESCRIPTION: IEC141I
This may seem like a novice question, but I usually don’t work in batch, so
excuse me please.
Is there a way I can "trap" the error at OPEN time? If so, I can bypass doing
the INPUT coding and go directly to the OUTPUT processing.
Regards – Grant.
201496 (Internal phone)
+44 (0)2076501496 (External phone)
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Steve Thompson
Sent: Friday, November 11, 2016 3:52 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Question on using DYNALLOC
I like this, particularly because of the explanation that goes with it as to
why you want to do things this way.
But, might I suggest that you do the member name in lower case?
That way, you can see it, and I think ISPF will allow you to view/edit it if
you need to while fixing a problem if your JOB fails for any reason.
Regards,
Steve Thompson
On 11/11/2016 07:58 AM, John McKown wrote:
> On Fri, Nov 11, 2016 at 6:33 AM, Ward Able, Grant <gwarda...@dtcc.com>
> wrote:
>
>> Ah rats! Looks like I am going to have to use a new member name every
>> time. Thanks Paul.
>> Now to code up a member name lookup piece of code......
>>
>
> I think the following will work.
>
> Allocate the DSN(MEMBER) with a DISP=OLD (for integrity) or SHR (if
> it's a PDSE or you're a gambler). Now, do an OPEN on _two_ different
> DCBs for the DD. First OPEN a DCB for _input_. Then OPEN a second DCB
> for _output_. When you OPEN a member of a PDS for _output_, the access
> method always positions to write at the end of the PDS, into "unused"
> space. You can now read records from the INPUT DCB and write them
> immediately to the OUTPUT DCB. At EOF on the input DCB, close the
> input DCB. Continue writing the new information to the output DCB.
> Finally, close the output DCB. This will do a STOW to actually update
> the PDS directory so that the member name now points to the new
> version of the member. Until the output DCB is closed, the PDS
> directory continues to point to the old member. But remember that an
> ABEND will do a close and _will_ update the directory so you _could_ loose
> the original member contents.
>
> What I'd suggest doing is similar to what you indicated, use a new
> member name. Being a weird-o. Remember that all member names are
> exactly 8 characters in length! The ones that look shorter are
> actually padded on the right with blanks. Also, remember that all byte
> combinations, with the exception of 8X'FF' are valid as a member name,
> though the non-printables can't be used in JCL or TSO ALLOCATE or
> BPXWDYN. So, weird person that I am, I would use SVC 99 (which I am
> fairly sure will accept non-printables as a member name) as you do
> above but make the member name be equal to the original member name,
> with the last character being X'00'. Now copy the original contents to
> the new member. Eventually you will close both the input & output DCBs
> successfully. Now, allocate the same DSN, but without a member name.
> Open a BPAM DCB on this, rather than the "normal" QSAM / BSAM you
> would for a member. Use a STOW delete function to delete the original
> member name. Lastly use a STOW rename to change the "weird" member
> name to the original member name. I, personally, feels that this is
> the safest way to "update" a member of a PDS without coming up with a "new"
> name all of the time.
>
> Of course, my method is a bit on the paranoid side. But, remember,
> just because you're paranoid doesn't mean that they aren't out to get
> you. Bugs, that is. And, it was just a weird idea (from a grand master).
>
>
>
>>
>>
>>
>> Regards – Grant.
>>
>> 201496 (Internal phone)
>> +44 (0)2076501496 (External phone)
>>
>>
>
DTCC DISCLAIMER: This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error, please notify us
immediately and delete the email and any attachments from your system. The
recipient should check this email and any attachments for the presence of
viruses. The company accepts no liability for any damage caused by any virus
transmitted by this email.
