[H390-MVS] JCL query

[William D ASM [e-mail] [H390-MVS]]

Hi - been installing Wally's ISPF last week and somehow while attempting
to add it to TSOAPPLS menu, I stupidly sent the assembly link target of
TSOMENU to SYS2.CMDPROC instead of SYS2,CMDLIB - senior moment I guess.
Anyway upshot of that was the proc lib was changed to recfm U.
Curiously, at least to me, it continued to work - I could log in and out
of TSO quite happily. Problem became apparent when I tried to copy
another proc to sys2.cmdproc and got an incompatible DCB error. I didn't
want to restore from the host backup because I had done and learned
quite a lot of JCl since the backup. Luckily I  managed to recover from
a tape backup and all is now well. ISPF added to the menu and seems to
be working OK. Will spend some time with it later and let Wally have my
opinions ;-)

In the meantime though, I tried to find a fix for the recfm problem via
Google and generally help was pessimistic though one soul suggest
IEBGENER - I tried that and that completely hosed the proclib.   Now I
had a copy of the cmdproc called SYS3.CMDPROC - deleted sys2.c... and
tried to rename sys3.c to sys2.c... via JCL (because now I can't login
to TSO) but had no success. Suggested IEBGENER job finished with RC 0
but did nothing, I could not get IEHPROGM to accept any commands and
learned afterwards that is a bad idea for cataloged datasets anyway, and
finally IDCAMS which actually renamed the catalog entry and wiped the
dataset. General consensus was that the TSO rename command would have
done the job but since I couldn't login to TSO that was not an option. I
understand one can run TSO in batch so that could have been a way out
but I have never tried that route. I will sometime soon.

Question - is it possible to use a utility in batch to rename a dataset
or is that something is not possible in MVS 3.8.

Apologies for the sorry tale but appreciate any pointers.

Best regards

Bill

[pricgren [e-mail] [H390-MVS]]

Post by William D ASM ***@yahoo.com [H390-MVS]
assembly link target of
TSOMENU to SYS2.CMDPROC instead of SYS2,CMDLIB

To address some of the points you raised...

To rename a data set you can use the
ALTER oldname NEWNAME(newname)
syntax either under TSO or as an IDCAMS command.

TSO's RENAME command only works for cataloged non-VSAM data sets, AFAIK,
which would have covered your scenario, of course.  I guess the point is
that ALTER works for VSAM as well.

I think it "continued to work" because the JFCB would have been primed
with the correct RECFM, but that's just a theory.

All you had to do - apart from deleting the unwanted program member -
was to correct the DCB attributes.

The PDS command is a fave for that, or you could have just run an
IEBCOPY job to copy a member from a library with compatible DCB
attributes and hard-coded the RECFM on the output DD.  This would update
the RECFM in the VTOC.

PDS data-set-name FIX RECFM(FB)
would probably do it.  I don't think the syntax requires a blank between
the F and the B like ALLOC/ATTRIB but you could look it up or try it.

The PDS command can do the same for sequential data sets as well.

This problem can be avoided on modern systems for a couple of decades
now by using PDSEs.  A PDSE is made to be either a data PDSE or a
program PDSE when the first member is loaded, and cannot be changed. 
The program binder will not write into a data PDSE, and only the program
binder can write into a program PDSE.  The program binder forces program
PDSEs to have RECFM=U, but you can have data PDSEs with RECFM=U.

Cheers,
Greg

[Bert Lindeman [e-mail] [H390-MVS]]

Bill,

In addition to what Greg wrote.
Just an example of overwriting the DCB of an existing dataset:
Formatting will be awfull but it's not much.
And it's on a copy just to be sure.
My complete testjob includes the copy / overwrite with wrong DCB and
finally overwrite with FB.
Be sure to verify at least the blocksize before using this.

//*
//* create copy to play with
//*
//SAVECOPY EXEC PGM=IEBCOPY
//SYSPRINT DD SYSOUT=*
//DATASET DD DISP=SHR,DSN=SYS2.CMDPROC
//SAVE DD DISP=(,CATLG),DSN=SYS2.CMDPROC.SAVE,
// UNIT=SYSALLDA,SPACE=(TRK,(15,15,15))
//SYSIN DD *
COPY I=DATASET,O=SAVE,LIST=NO
//*
//* overwrite with WRONG dcb
//*
// EXEC PGM=IEBGENER,COND=(0,NE)
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DUMMY,SPACE=(TRK,0),
// DCB=(LRECL=80,RECFM=VBA,BLKSIZE=19040)
//SYSUT2 DD DISP=SHR,DSN=SYS2.CMDPROC.SAVE(@@@DEL@@),
// DCB=(LRECL=80,RECFM=VBA,BLKSIZE=19040)
//* DCB=(LRECL=80,RECFM=FB,BLKSIZE=19040,DSORG=PO)
//SYSIN DD *
//*
//* overwrite wrong dcb back to recfm=fb
//*
// EXEC PGM=IEBGENER,COND=(0,NE)
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DUMMY,SPACE=(TRK,0),
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=19040)
//SYSUT2 DD DISP=SHR,DSN=SYS2.CMDPROC.SAVE(@@@DEL@@),
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=19040)
//* DCB=(LRECL=80,RECFM=FB,BLKSIZE=19040,DSORG=PO)
//SYSIN DD *

Maybe it helps ;-)

Bert

Post by pricgren ***@yahoo.com [H390-MVS]
The PDS command is a fave for that, or you could have just run an
IEBCOPY job to copy a member from a library with compatible DCB
attributes and hard-coded the RECFM on the output DD.  This would update
the RECFM in the VTOC.

---
Deze e-mail is gecontroleerd op virussen door AVG.
http://www.avg.com

[William D ASM [e-mail] [H390-MVS]]

Post by Bert Lindeman ***@gmail.com [H390-MVS]
Bill,
In addition to what Greg wrote.
Formatting will be awfull but it's not much.
And it's on a copy just to be sure.
My complete testjob includes the copy / overwrite with wrong DCB and
finally overwrite with FB.
Be sure to verify at least the blocksize before using this.
//*
//* create copy to play with
//*
//SAVECOPY EXEC PGM=IEBCOPY
//SYSPRINT DD SYSOUT=*
//DATASET DD DISP=SHR,DSN=SYS2.CMDPROC
//SAVE DD DISP=(,CATLG),DSN=SYS2.CMDPROC.SAVE,
// UNIT=SYSALLDA,SPACE=(TRK,(15,15,15))
//SYSIN DD *
COPY I=DATASET,O=SAVE,LIST=NO
//*
//* overwrite with WRONG dcb
//*
// EXEC PGM=IEBGENER,COND=(0,NE)
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DUMMY,SPACE=(TRK,0),
// DCB=(LRECL=80,RECFM=VBA,BLKSIZE=19040)
// DCB=(LRECL=80,RECFM=VBA,BLKSIZE=19040)
//* DCB=(LRECL=80,RECFM=FB,BLKSIZE=19040,DSORG=PO)
//SYSIN DD *
//*
//* overwrite wrong dcb back to recfm=fb
//*
// EXEC PGM=IEBGENER,COND=(0,NE)
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DUMMY,SPACE=(TRK,0),
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=19040)
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=19040)
//* DCB=(LRECL=80,RECFM=FB,BLKSIZE=19040,DSORG=PO)
//SYSIN DD *
Maybe it helps ;-)

Bert


Hey Bert - many thanks for taking the trouble. You used RECFM=VBA here -
I saw a number of examples of converting VB or VBA back which worked
apparently but my CMDPROC was RECFM=U - none of those tactics worked for
me. However, thanks again - will try your sample later and let you know
the result.

Best

Bill

Post by Bert Lindeman ***@gmail.com [H390-MVS]
------------------------------------------------------------------------
------------------------------------------------------------------------
Reply via web post
<https://groups.yahoo.com/neo/groups/H390-MVS/conversations/messages/18486;_ylc=X3oDMTJxdDJuNTY2BF9TAzk3MzU5NzE0BGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BG1zZ0lkAzE4NDg2BHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTUzOTg0ODg3NA--?act=reply&messageNum=18486>
• Reply to sender
• Reply to group
• Start a New Topic
<https://groups.yahoo.com/neo/groups/H390-MVS/conversations/newtopic;_ylc=X3oDMTJlM3RldHJ1BF9TAzk3MzU5NzE0BGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTUzOTg0ODg3NA-->
• Messages in this topic
<https://groups.yahoo.com/neo/groups/H390-MVS/conversations/topics/18484;_ylc=X3oDMTM2cXJjcjUxBF9TAzk3MzU5NzE0BGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BG1zZ0lkAzE4NDg2BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTUzOTg0ODg3NAR0cGNJZAMxODQ4NA-->
(3)
------------------------------------------------------------------------
Have you tried the highest rated email app? <https://yho.com/1wwmgg>
With 4.5 stars in iTunes, the Yahoo Mail app is the highest rated
email app on the market. What are you waiting for? Now you can access
all your inboxes (Gmail, Outlook, AOL and more) in one place. Never
delete an email again with 1000GB of free cloud storage.
------------------------------------------------------------------------
Visit Your Group
<https://groups.yahoo.com/neo/groups/H390-MVS/info;_ylc=X3oDMTJlczI3dDBxBF9TAzk3MzU5NzE0BGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTUzOTg0ODg3NA-->
Yahoo! Groups
<https://groups.yahoo.com/neo;_ylc=X3oDMTJkY3VwaHVqBF9TAzk3MzU5NzE0BGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxNTM5ODQ4ODc0>
• Privacy
<https://info.yahoo.com/privacy/us/yahoo/groups/details.html> •
Unsubscribe
Terms of Use <https://info.yahoo.com/legal/us/yahoo/utos/terms/>
SPONSORED LINKS
.

[William D ASM [e-mail] [H390-MVS]]

Post by pricgren ***@yahoo.com [H390-MVS]

Post by William D ASM ***@yahoo.com [H390-MVS]
assembly link target of
TSOMENU to SYS2.CMDPROC instead of SYS2,CMDLIB

To address some of the points you raised...
To rename a data set you can use the
ALTER oldname NEWNAME(newname)
syntax either under TSO or as an IDCAMS command.

Ahh - thanks Greg - I was given REPRO INFILE(OLD) OUTFILE(NEW) which
destroyed the file.

         Need to study IDCAMS a bit it seems.

Post by pricgren ***@yahoo.com [H390-MVS]
TSO's RENAME command only works for cataloged non-VSAM data sets, AFAIK,
which would have covered your scenario, of course.  I guess the point is
that ALTER works for VSAM as well.
I think it "continued to work" because the JFCB would have been primed
with the correct RECFM, but that's just a theory.
All you had to do - apart from deleting the unwanted program member -
was to correct the DCB attributes.
The PDS command is a fave for that, or you could have just run an
IEBCOPY job to copy a member from a library with compatible DCB
attributes and hard-coded the RECFM on the output DD. This would update
the RECFM in the VTOC.
PDS data-set-name FIX RECFM(FB)
would probably do it.  I don't think the syntax requires a blank between
the F and the B like ALLOC/ATTRIB but you could look it up or try it.

Will do a bit later and let you know.

Post by pricgren ***@yahoo.com [H390-MVS]
The PDS command can do the same for sequential data sets as well.
This problem can be avoided on modern systems for a couple of decades
now by using PDSEs.  A PDSE is made to be either a data PDSE or a
program PDSE when the first member is loaded, and cannot be changed.
The program binder will not write into a data PDSE, and only the program
binder can write into a program PDSE.  The program binder forces program
PDSEs to have RECFM=U, but you can have data PDSEs with RECFM=U.
Cheers,
Greg

Many thanks for the response - it has been a while since I did anything
with the system - so am quite enjoying getting back up to speed (sort
of) and discovering all the things that I thought I knew actually were
forgotten <VBG>

Best Regards

Bill

[Charles Bailey [e-mail] [H390-MVS]]

I think you could just write a little piece of assembler code to open
the dataset for output and then close it again without writing
anything. Hard-code the correct RECFM in the DCB statement. If I
remember correctly from my MVS days, that will update the RECFM field in
the VTOC.

Charles Bailey

[William D ASM [e-mail] [H390-MVS]]

Post by Charles Bailey ***@comcast.net [H390-MVS]
I think you could just write a little piece of assembler code to open
the dataset for output and then close it again without writing
anything. Hard-code the correct RECFM in the DCB statement. If I
remember correctly from my MVS days, that will update the RECFM field in
the VTOC.
Charles Bailey
------------------------------------------------------------------------
------------------------------------------------------------------------

Thanks - thats a thought - i will give it a try.

Best

Bill

[Binyamin Dissen [e-mail] [H390-MVS]]

That will probably wipe the dataset. You would need UPDAT or EXTEND.

On Fri, 19 Oct 2018 06:39:26 +0200 "William D ASM ***@yahoo.com
[H390-MVS]" <H390-***@yahoogroups.com> wrote:

:>On 2018/10/19 03:37, Charles Bailey ***@comcast.net
:>[H390-MVS] wrote:
:>>
:>> I think you could just write a little piece of assembler code to open
:>> the dataset for output and then close it again without writing
:>> anything. Hard-code the correct RECFM in the DCB statement. If I
:>> remember correctly from my MVS days, that will update the RECFM field in
:>> the VTOC.
:>>
:>> Charles Bailey
:>>
:>>
:>> ------------------------------------------------------------------------
:>> Posted by: Charles Bailey <***@comcast.net>
:>> ------------------------------------------------------------------------
:>>
:>>
:>>
:>>
:>>
:>>
:>>
:>>
:>>
:>>
:>Thanks - thats a thought - i will give it a try.
:>
:>Best
:>
:>Bill

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

[William D ASM [e-mail] [H390-MVS]]

Post by Binyamin Dissen ***@dissensoftware.com [H390-MVS]
That will probably wipe the dataset. You would need UPDAT or EXTEND.

Can you expand a bit on that? I can't find either parm in any jcl,macro
or assembler reference that I have.

While I'm on that, can anyone point me to a copy of an MVS 3.8 usable
version of the "Z/OS DFSMS Macro Instructions for Datasets" - that one
seems to be not entirely relevant for legacy MVS.

Thanks

Bill

[[e-mail] [H390-MVS]]

Post by William D ASM ***@yahoo.com [H390-MVS]

Post by Binyamin Dissen ***@dissensoftware.com [H390-MVS]
That will probably wipe the dataset. You would need UPDAT or EXTEND.

Can you expand a bit on that? I can't find either
parm in any jcl,macro or assembler reference that I have.

Gerhard added UPDAT to mvssupa.asm so
there is sample code for that:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/mvssupa.asm

OPEN (BSAMDCB,UPDAT),MF=L QSAM, BSAM, DASD
OPEN (BSAMDCB,EXTEND),MF=L QSAM, BSAM, DASD, TAPE

BFN. Paul.

[William D ASM [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]

Post by William D ASM ***@yahoo.com [H390-MVS]

Post by Binyamin Dissen ***@dissensoftware.com [H390-MVS]
That will probably wipe the dataset. You would need UPDAT or EXTEND.

Can you expand a bit on that? I can't find either
parm in any jcl,macro or assembler reference that I have.

Gerhard added UPDAT to mvssupa.asm so
https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/mvssupa.asm
OPEN (BSAMDCB,UPDAT),MF=L QSAM, BSAM, DASD
OPEN (BSAMDCB,EXTEND),MF=L QSAM, BSAM, DASD, TAPE
BFN. Paul.

Thanks Paul - I can try that but this problem is with a BPAM dataset -
does this also apply?

    Anyway FYI I have tried a quick asm pgm without to just open and
close but it does nothing at all         except S0C1 :-) Happiness is
the learning curve is easing off a bit thanks to you all.

Best

Bill

[Gerhard Postpischil [e-mail] [H390-MVS]]

Post by William D ASM ***@yahoo.com [H390-MVS]
Thanks Paul - I can try that but this problem is with a BPAM dataset -
does this also apply?

I've had this problem a few times (mostly getting the block size wrong),
and there are two "easy" ways of handling this:

JCL: use IEBUPDTE to add a PDS member with the correct DCB information
on the SYSUT2 DD card. I've never tried it for a sequential data set,
but IEBGENER with a DISP=MOD might do it.

An easier way, once you've installed it, is to use the DSCB program to
ZAP the format 1 DSCB parameters you need to change. If you have the
optional source volumes that came with the tk3/tk4- distributions, it's
in CBTCOV.FILE065(dscb). There may be other versions around, but I
haven't tried any of them.

Post by William D ASM ***@yahoo.com [H390-MVS]
    Anyway FYI I have tried a quick asm pgm without to just open and
close but it does nothing at all         except S0C1 :-) Happiness is
the learning curve is easing off a bit thanks to you all.

To get a change, the WRITE bit in the DCB needs to be on, and a valid
last write address to prevent clobbering good data.

A third way to handle this would be with a custom program - open an
input DCB with RECFM=U,BLKSIZE=32760, READ each block, use WRITE to copy
to a new data set with the correct DCB parameters.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
https://www.avg.com

[William D ASM [e-mail] [H390-MVS]]

Post by Gerhard Postpischil ***@charter.net [H390-MVS]

Post by William D ASM ***@yahoo.com [H390-MVS]
Thanks Paul - I can try that but this problem is with a BPAM dataset -
does this also apply?

I've had this problem a few times (mostly getting the block size wrong),
JCL: use IEBUPDTE to add a PDS member with the correct DCB information
on the SYSUT2 DD card. I've never tried it for a sequential data set,
but IEBGENER with a DISP=MOD might do it.
An easier way, once you've installed it, is to use the DSCB program to
ZAP the format 1 DSCB parameters you need to change. If you have the
optional source volumes that came with the tk3/tk4- distributions, it's
in CBTCOV.FILE065(dscb). There may be other versions around, but I
haven't tried any of them.

Post by William D ASM ***@yahoo.com [H390-MVS]
    Anyway FYI I have tried a quick asm pgm without to just open and
close but it does nothing at all         except S0C1 :-) Happiness is
the learning curve is easing off a bit thanks to you all.

To get a change, the WRITE bit in the DCB needs to be on, and a valid
last write address to prevent clobbering good data.
A third way to handle this would be with a custom program - open an
input DCB with RECFM=U,BLKSIZE=32760, READ each block, use WRITE to copy
to a new data set with the correct DCB parameters.

Thanks - I will try the above suggestions but the last may be a bit
beyond my ASM capabilities. However, it would be a good exercise for me.
Now to find some good file handling tutorials ;-)

Best

Bill

Post by Gerhard Postpischil ***@charter.net [H390-MVS]
Gerhard Postpischil
Bradford, VT
---

[Gerhard Postpischil [e-mail] [H390-MVS]]

Post by William D ASM ***@yahoo.com [H390-MVS]
Can you expand a bit on that? I can't find either parm in any jcl,macro
or assembler reference that I have.
While I'm on that, can anyone point me to a copy of an MVS 3.8 usable
version of the "Z/OS DFSMS Macro Instructions for Datasets" - that one
seems to be not entirely relevant for legacy MVS.

At some point IBM keeps changing and rearranging the names of the
manuals. Perhaps you will be able to find "Using Datasets". It combines
macro and programming information (for MVS or XA - I can't remember) and
is close to what you need. Let me know if you need the full title or the
manual number.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
https://www.avg.com



------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/H390-MVS/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/H390-MVS/join
(Yahoo! ID required)

<*> To change settings via email:
H390-MVS-***@yahoogroups.com
H390-MVS-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
H390-MVS-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Laddie Hanus [e-mail] [H390-MVS]]

Its on bitsavers at
http://www.bitsavers.org/pdf/ibm/370/OS_VS2/Release_3.8_1978/GC26-3873-0_OS_VS2_MVS_Data_Management_Macro_Instructions_Rel_3.8_Mar79.pdf

Laddie

Post by Gerhard Postpischil ***@charter.net [H390-MVS]

Post by William D ASM ***@yahoo.com [H390-MVS]
Can you expand a bit on that? I can't find either parm in any jcl,macro
or assembler reference that I have.
While I'm on that, can anyone point me to a copy of an MVS 3.8 usable
version of the "Z/OS DFSMS Macro Instructions for Datasets" - that one
seems to be not entirely relevant for legacy MVS.

At some point IBM keeps changing and rearranging the names of the
manuals. Perhaps you will be able to find "Using Datasets". It combines
macro and programming information (for MVS or XA - I can't remember) and
is close to what you need. Let me know if you need the full title or the
manual number.
Gerhard Postpischil
Bradford, VT
---
This email has been checked for viruses by AVG.
https://www.avg.com
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/H390-MVS/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/H390-MVS/join
(Yahoo! ID required)

<*> To change settings via email:
H390-MVS-***@yahoogroups.com
H390-MVS-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
H390-MVS-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[William D ASM [e-mail] [H390-MVS]]

Post by Laddie Hanus ***@yahoo.com [H390-MVS]
Its on bitsavers at
http://www.bitsavers.org/pdf/ibm/370/OS_VS2/Release_3.8_1978/GC26-3873-0_OS_VS2_MVS_Data_Management_Macro_Instructions_Rel_3.8_Mar79.pdf
Laddie

Thanks Laddie - got it.


------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/H390-MVS/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/H390-MVS/join
(Yahoo! ID required)

<*> To change settings via email:
H390-MVS-***@yahoogroups.com
H390-MVS-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
H390-MVS-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Charles Bailey [e-mail] [H390-MVS]]

Since it's a PDS I don't think so.

:> That will probably wipe the dataset. You would need UPDAT or EXTEND.

On Fri, 19 Oct 2018 06:39:26 +0200 "William D ASM ***@yahoo.com
[H390-MVS]" <H390-***@yahoogroups.com> wrote:

:>On 2018/10/19 03:37, Charles Bailey ***@comcast.net
:>[H390-MVS] wrote:
:>>
:>> I think you could just write a little piece of assembler code to open
:>> the dataset for output and then close it again without writing
:>> anything. Hard-code the correct RECFM in the DCB statement. If I
:>> remember correctly from my MVS days, that will update the RECFM field in
:>> the VTOC.
:>>
:>> Charles Bailey
:>>
:>>
:>> ----------------------------------------------------------
:>> Posted by: Charles Bailey <***@comcast.net>
:>> ----------------------------------------------------------
:>>
:>
:>Bill

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

[Charles Bailey [e-mail] [H390-MVS]]

:> That will probably wipe the dataset. You would need UPDAT or EXTEND.

UPDAT or EXTEND are not needed when writing to a PDS using BPAM. BPAM
always writes to the end of a dataset. You open it for output, issue a
few WRITE macros, then issue a STOW to update the directory. The member
name gets put into the directory in the correct sort-by-name order. If
you STOW a member name that already exists then the directory entry is
updated to point to the new location for the member and the space
previously occupied by the member now becomes wasted space in the middle
of the dataset. That's why PDS's need to be compressed once in a while
to recover wasted space.

I'm not in a position to try it right now, but I think something like
the following should work:

DCB1 DCB DDNAME=DD1,DSORG=PO,MACRF=W,RECFM=FB
OPEN (DCB1,OUTPUT)
CLOSE (DCB1,)


Charles Bailey

[William D ASM [e-mail] [H390-MVS]]

Post by Charles Bailey ***@comcast.net [H390-MVS]
:> That will probably wipe the dataset. You would need UPDAT or EXTEND.
UPDAT or EXTEND are not needed when writing to a PDS using BPAM. BPAM
always writes to the end of a dataset. You open it for output, issue a
few WRITE macros, then issue a STOW to update the directory. The member
name gets put into the directory in the correct sort-by-name order. If
you STOW a member name that already exists then the directory entry is
updated to point to the new location for the member and the space
previously occupied by the member now becomes wasted space in the middle
of the dataset. That's why PDS's need to be compressed once in a while
to recover wasted space.
I'm not in a position to try it right now, but I think something like
DCB1 DCB DDNAME=DD1,DSORG=PO,MACRF=W,RECFM=FB
OPEN (DCB1,OUTPUT)
CLOSE (DCB1,)
Charles Bailey

Wow - that worked thanks - silly me I had MACRF=R in the first try.
Still does a S0C1 but I will worry that through later......

Best

Bill

[Robert Garrett [e-mail] [H390-MVS]]

Wish I'd seen this sooner, you probably have it all recovered by now.

All the "wrong" link did was to write a member with bad formatting to the PDS and also update the DCB information in the VTOC for the PDS to have incorrect information. It did not damage any of the exiting members.

To recover, all you would have had to do would be to:
1) Delete the 'bad' member.
2) Run any sort of batch job to write a new member to the PDS with the 'correct' DCB information explicitly coded on the DD statement. A simple IEBGENER could have done it.

//ZAMMA JOB .....
//FIXIT EXEC PGM=IEBGENER
//SYSIN DD DUMMY
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD ...some input...
//SYSUT2 DD DISP=SHR, DSN=SYS2.CMDPROC(FIXITUP),DCB=(RECFM=...,LRECL=..., BLKSIZE=) (whatever is 'correct') for the PDS

Because you explicitly specified DCB information on the input DD, two things will happen: 1) this information will override/supercede the (now) incorrect DCB information in the VTOC 2) When the new member is closed, the DCB information in the VTOC will be UPDATED with the values from the DD statement.

Easy peasy...

Rob

-----Original Message-----
From: H390-***@yahoogroups.com <H390-***@yahoogroups.com>
Sent: Thursday, October 18, 2018 12:11 AM
To: H390-***@yahoogroups.com
Subject: [H390-MVS] JCL query

Hi - been installing Wally's ISPF last week and somehow while attempting to add it to TSOAPPLS menu, I stupidly sent the assembly link target of TSOMENU to SYS2.CMDPROC instead of SYS2,CMDLIB - senior moment I guess.
Anyway upshot of that was the proc lib was changed to recfm U.
Curiously, at least to me, it continued to work - I could log in and out of TSO quite happily. Problem became apparent when I tried to copy another proc to sys2.cmdproc and got an incompatible DCB error. I didn't want to restore from the host backup because I had done and learned quite a lot of JCl since the backup. Luckily I  managed to recover from a tape backup and all is now well. ISPF added to the menu and seems to be working OK. Will spend some time with it later and let Wally have my opinions ;-)

In the meantime though, I tried to find a fix for the recfm problem via Google and generally help was pessimistic though one soul suggest IEBGENER - I tried that and that completely hosed the proclib.   Now I had a copy of the cmdproc called SYS3.CMDPROC - deleted sys2.c... and tried to rename sys3.c to sys2.c... via JCL (because now I can't login to TSO) but had no success. Suggested IEBGENER job finished with RC 0 but did nothing, I could not get IEHPROGM to accept any commands and learned afterwards that is a bad idea for cataloged datasets anyway, and finally IDCAMS which actually renamed the catalog entry and wiped the dataset. General consensus was that the TSO rename command would have done the job but since I couldn't login to TSO that was not an option. I understand one can run TSO in batch so that could have been a way out but I have never tried that route. I will sometime soon.

Question - is it possible to use a utility in batch to rename a dataset or is that something is not possible in MVS 3.8.

Apologies for the sorry tale but appreciate any pointers.

Best regards

Bill



------------------------------------
Posted by: William D ASM <***@yahoo.com>
------------------------------------


------------------------------------

Yahoo Groups Links

[William D ASM [e-mail] [H390-MVS]]

Post by Robert Garrett ***@garrettfamily.us [H390-MVS]
Wish I'd seen this sooner, you probably have it all recovered by now.
All the "wrong" link did was to write a member with bad formatting to
the PDS and also update the DCB information in the VTOC for the PDS to
have incorrect information. It did not damage any of the exiting members.
1) Delete the 'bad' member.
2) Run any sort of batch job to write a new member to the PDS with the
'correct' DCB information explicitly coded on the DD statement. A
simple IEBGENER could have done it.
//ZAMMA JOB .....
//FIXIT EXEC PGM=IEBGENER
//SYSIN DD DUMMY
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD ...some input...
//SYSUT2 DD DISP=SHR,
DSN=SYS2.CMDPROC(FIXITUP),DCB=(RECFM=...,LRECL=..., BLKSIZE=)
(whatever is 'correct') for the PDS
Because you explicitly specified DCB information on the input DD, two
things will happen: 1) this information will override/supercede the
(now) incorrect DCB information in the VTOC 2) When the new member is
closed, the DCB information in the VTOC will be UPDATED with the
values from the DD statement.
Easy peasy...
Rob

Thanks Rob - yes problem sorted - I used a short asm program to just
open and close the PDS with the correct DCB and that sorts the problem
out. I tried various versions of IEBGENER jobs but couldn't get anywhere
with it. However, I have kept some backups of the problem files for
future reference so could try your job on them - but later. ATM am busy
attempting to rescue my sister-in-law's Windows PC (AGAIN).

Best

Bill