Re: REXX: ADDRESS ISPEXEC failing with rc = -3
On Fri, 30 Oct 2020 20:34:42 -0400, Tom Conley wrote: >On 10/30/2020 7:13 PM, lloyd christensen wrote: >> Thanks, took that plus hours of cursing and trying different stuff. Finally >> got a different IKJEFTxx member and it worked. Lots of problems with it >> wanting to allocate the same profile I was logged on with, and aggravation >> with allocation issues for the profile and ISPFILE. Eventually got it though. >> Is Lloyd posting on BITNET where many of us can't see his questions, but only your replies? >If you don't care about saving anything in the profile, allocate a temp >PDS dataset with a small allocation for ISPPROF. Same for any other >output files you don't care about saving. > +1 I do that regularly, not only to avoid ENQ conflicts but also in code for general consumption where I want to control the environment and not have it muddled by individual users' idiosyncratic profiles. Likewise, any libraries specific to interactive operation such as panels can be omitted, DUMMY, or DISP=(NEW,DELETE) in batch operations. Unless the OP is heavily invested in ISPF craft this seems like something that might be done more simply in pure Rexx with an IRXJCL step, shedding the burden of ISPF and all its libraries. Of course, I'd do such a chore in a POSIX shell script invoked by BPXBATCH, AOPBATCH, BPXWUNIX, or COZBATCH. Rexx has no instream data sets of its own (but JCL SYSINs might suffice.) Shell here-documents provide a combination of symbol substitution and command substitution not available with SYSIN DD DATA,SYMBOLS=... I truly miss command substitution in JCL. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX: ADDRESS ISPEXEC failing with rc = -3
On 10/30/2020 7:13 PM, lloyd christensen wrote: Thanks, took that plus hours of cursing and trying different stuff. Finally got a different IKJEFTxx member and it worked. Lots of problems with it wanting to allocate the same profile I was logged on with, and aggravation with allocation issues for the profile and ISPFILE. Eventually got it though. Thanks all! Lloyd, If you don't care about saving anything in the profile, allocate a temp PDS dataset with a small allocation for ISPPROF. Same for any other output files you don't care about saving. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM-RLS and DFSMStvs basic questions
Radoslaw, He is asking about shareoption (4 x) not (x 4) aka cross-region sharing, not cross-system sharing. In VSE, Shareoption(4) allows vsam file sharing among partitions (similar to a z/os address space). VSE manages that automatically, for the user. Joe On Fri, Oct 30, 2020 at 6:22 PM R.S. wrote: > W dniu 30.10.2020 o 23:51, Tony Thigpen pisze: > > All, > > > > I have a z/VSE client that believes it is time to move to z/OS. But, > > they have one big concern. They have a lot of ShareOption=4 VSAM files. > > > > For those that don't know it, ShareOption=4 files on z/VSE "work out > > of the box" without any need for the application program to perform > > any enqueue or dequeue. z/VSE automatically performs those functions, > > unlike z/OS where the application has to handle the enqueue process. > > > > In their case, they use shareoption=4 so that they can update VSAM > > files from batch Cobol programs while at the same time CICS Cobol > > programs are also updating the files. They don't want to have to > > change their programs. > > > > From my initial research, it appears that this same function can be > > reproduced on z/OS using DFHSMStvs. (And, it looks like VSAM-RLS is > > also required to support DFHSMStvs.) > > > > Are we going down the right path? > > IMHO no. > > Some remarks: > 1. Any migration will require some work to do. Sometimes little less > effort give you much worse results. > 2. SHR (x 4) means cross-system sharing. Why it is cross-system? Why > don't you consolidate it into one system? What are the reasons? > 3. VSAM RLS is almost free - that means it is not licensed, but it > require Coupling Facility - even in single system configuration. Such > kind of Parallel Sysplex. Even when you want to have single CPC, you > still need CPU engine for CF, that is ICF processor. It is approx. 250k$ > (for big machine). And some memory. However tvs is not necessary. Note: > tvs is paid, because there are ISV options. And there are some IBM > add-ons like CICSVR, etc. > 4. Let's go back to point 1 - maybe it is good time to move from VSAM to > Db2? Note, there is special software product which allow VSAM > application to work with Db2 with minimal changes. And of course you > would have a lot of Db2 advantages over VSAM, and any new development > could directly interface with Db2, not Db2 under cover of VSAM. Of > course neither the product, nor Db2 is free, but... > > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, > www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2020 r. wynosi 169.401.468 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you have > printed out or saved). > This message may contain legally protected information, which may be used > exclusively by the addressee.Please be reminded that anyone who > disseminates (copies, distributes) this message or takes any similar > action, violates the law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169.401.468 as at 1 January 2020. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM-RLS and DFSMStvs basic questions
W dniu 30.10.2020 o 23:51, Tony Thigpen pisze: All, I have a z/VSE client that believes it is time to move to z/OS. But, they have one big concern. They have a lot of ShareOption=4 VSAM files. For those that don't know it, ShareOption=4 files on z/VSE "work out of the box" without any need for the application program to perform any enqueue or dequeue. z/VSE automatically performs those functions, unlike z/OS where the application has to handle the enqueue process. In their case, they use shareoption=4 so that they can update VSAM files from batch Cobol programs while at the same time CICS Cobol programs are also updating the files. They don't want to have to change their programs. From my initial research, it appears that this same function can be reproduced on z/OS using DFHSMStvs. (And, it looks like VSAM-RLS is also required to support DFHSMStvs.) Are we going down the right path? IMHO no. Some remarks: 1. Any migration will require some work to do. Sometimes little less effort give you much worse results. 2. SHR (x 4) means cross-system sharing. Why it is cross-system? Why don't you consolidate it into one system? What are the reasons? 3. VSAM RLS is almost free - that means it is not licensed, but it require Coupling Facility - even in single system configuration. Such kind of Parallel Sysplex. Even when you want to have single CPC, you still need CPU engine for CF, that is ICF processor. It is approx. 250k$ (for big machine). And some memory. However tvs is not necessary. Note: tvs is paid, because there are ISV options. And there are some IBM add-ons like CICSVR, etc. 4. Let's go back to point 1 - maybe it is good time to move from VSAM to Db2? Note, there is special software product which allow VSAM application to work with Db2 with minimal changes. And of course you would have a lot of Db2 advantages over VSAM, and any new development could directly interface with Db2, not Db2 under cover of VSAM. Of course neither the product, nor Db2 is free, but... -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM-RLS and DFSMStvs basic questions
"In their case, they use shareoption=4 so that they can update VSAM files from batch Cobol programs while at the same time CICS Cobol programs are also updating the files. They don't want to have to change their programs." How do you plan to make that happen since in usually z/os CICS journals the changes to VSAM files and can back out updates? What happens if a record gets updated by CICS and then gets updated by a batch program to a different value, and then CICS backs out its original change? Joe On Fri, Oct 30, 2020 at 5:51 PM Tony Thigpen wrote: > All, > > I have a z/VSE client that believes it is time to move to z/OS. But, > they have one big concern. They have a lot of ShareOption=4 VSAM files. > > For those that don't know it, ShareOption=4 files on z/VSE "work out of > the box" without any need for the application program to perform any > enqueue or dequeue. z/VSE automatically performs those functions, unlike > z/OS where the application has to handle the enqueue process. > > In their case, they use shareoption=4 so that they can update VSAM files > from batch Cobol programs while at the same time CICS Cobol programs are > also updating the files. They don't want to have to change their programs. > > From my initial research, it appears that this same function can be > reproduced on z/OS using DFHSMStvs. (And, it looks like VSAM-RLS is also > required to support DFHSMStvs.) > > Are we going down the right path? > > > Tony Thigpen > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM-RLS and DFSMStvs basic questions
I believe you're on the right path. VSAM RLS requires a coupling facility for its lock and cache structures, and DFSMStvs is a priced feature of z/OS too. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Friday, October 30th, 2020 at 6:51 PM, Tony Thigpen wrote: > All, > > I have a z/VSE client that believes it is time to move to z/OS. But, > > they have one big concern. They have a lot of ShareOption=4 VSAM files. > > For those that don't know it, ShareOption=4 files on z/VSE "work out of > > the box" without any need for the application program to perform any > > enqueue or dequeue. z/VSE automatically performs those functions, unlike > > z/OS where the application has to handle the enqueue process. > > In their case, they use shareoption=4 so that they can update VSAM files > > from batch Cobol programs while at the same time CICS Cobol programs are > > also updating the files. They don't want to have to change their programs. > > From my initial research, it appears that this same function can be > > reproduced on z/OS using DFHSMStvs. (And, it looks like VSAM-RLS is also > > required to support DFHSMStvs.) > > Are we going down the right path? > > Tony Thigpen > > - > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM-RLS and DFSMStvs basic questions
Another option: https://ftpdocs.broadcom.com/cadocs/d0/d93e.pdf On Fri, 30 Oct 2020 at 22:51, Tony Thigpen wrote: > All, > > I have a z/VSE client that believes it is time to move to z/OS. But, > they have one big concern. They have a lot of ShareOption=4 VSAM files. > > For those that don't know it, ShareOption=4 files on z/VSE "work out of > the box" without any need for the application program to perform any > enqueue or dequeue. z/VSE automatically performs those functions, unlike > z/OS where the application has to handle the enqueue process. > > In their case, they use shareoption=4 so that they can update VSAM files > from batch Cobol programs while at the same time CICS Cobol programs are > also updating the files. They don't want to have to change their programs. > > From my initial research, it appears that this same function can be > reproduced on z/OS using DFHSMStvs. (And, it looks like VSAM-RLS is also > required to support DFHSMStvs.) > > Are we going down the right path? > > > Tony Thigpen > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
VSAM-RLS and DFSMStvs basic questions
All, I have a z/VSE client that believes it is time to move to z/OS. But, they have one big concern. They have a lot of ShareOption=4 VSAM files. For those that don't know it, ShareOption=4 files on z/VSE "work out of the box" without any need for the application program to perform any enqueue or dequeue. z/VSE automatically performs those functions, unlike z/OS where the application has to handle the enqueue process. In their case, they use shareoption=4 so that they can update VSAM files from batch Cobol programs while at the same time CICS Cobol programs are also updating the files. They don't want to have to change their programs. From my initial research, it appears that this same function can be reproduced on z/OS using DFHSMStvs. (And, it looks like VSAM-RLS is also required to support DFHSMStvs.) Are we going down the right path? Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UNIX fork() performance (was: SMF to capture ... )
On 30/10/2020 11:10 pm, Kirk Wolf wrote: In the SDSF PS display for the COZBATCH example, all the PIDS ran in the same AS except for the one you asked about: ANDREWRB STC03080 RUNNING ANDREWR 1R 16843329 1684334979 004F /bin/sh /home/andrewr/breakit.sh the parent of this is process: ANDREWRB JOB03101 WAITING FOR CHILDANDREWR 1W 16843349 5039778051 0033 /bin/sh /home/andrewr/breakit.sh Both of these are what you see when you run a shell script file with /bin/sh. I'm not sure what breakit.sh does, but these two are what you would see if the /bin/sh shell forked itself without doing an exec. This is what the shell would do for cases like using a builtin in a pipe. breakit.sh is described in the write up I linked previously. @wizardofzos found what looked like a bug in the shell and posted a script to trigger it. I tried to reproduce it but could not, however the script produced some interesting SMF data. I assumed the first link in the pipe would run in the same address space, with the subsequent link in other address spaces. Cut is the final command so I was surprised that it ran in the original address space. I guess it makes as much sense - maybe more - that the last piped command runs in the original address space, not the first. I didn't see the 2 breakit.sh PS entries when running under BPXBATCH - only COZBATCH. Maybe it is fast enough that I was unable to catch it. Andrew Rowley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX: ADDRESS ISPEXEC failing with rc = -3
I don't know you well enough to bare with you I will, however, bear with you immediately > I'm new to REXX and hadn't written CLIST in 20+ years. Bare with me, please: > The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. Humana Inc. and its subsidiaries comply with applicable Federal civil rights laws and do not discriminate on the basis of race, color, national origin, ancestry, age, disability, sex, marital status, gender, sexual orientation, gender identity, or religion. Humana Inc. and its subsidiaries do not exclude people or treat them differently because of race, color, national origin, ancestry, age, disability, sex, marital status, gender, sexual orientation, gender identity, or religion. English: ATTENTION: If you do not speak English, language assistance services, free of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711). Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711). 繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助 服務。請致電 1‐877‐320‐1235 (TTY: 711)。 Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711). Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711). 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX: ADDRESS ISPEXEC failing with rc = -3
On 10/30/2020 12:04 PM, lcwri...@gmail.com wrote:
I'm new to REXX and hadn't written CLIST in 20+ years. Bare with me, please:
I am trying to have REXX run in batch. The intent of the exec is to invoke
dialog manager, in particular ISPSLIB, to build JCL with multiple steps doing
IEBDG with varying record counts. It will resubmit itself over and over...the
goal is to do I/O to every volume in a group of 29.
The failure is in the ADDRESS ISPEXEC.
REXX Code:
/* REXX */
/* BLDIEBDG will build JCL for IEBDG jobs with the workloads to */
/* vary based on time of day. The devices within the 2nd */
/* EXCTG will have greater I/O rates than the volumes */
/* in the other EXCTG groups. */
/* */
/* Variables passed are:*/
/* BTCH: a batch-id or in this case a shift number*/
/* HOWMANYE: how many records to create on 'EVEN' address */
/* HOWMANYO: how many records to create on 'ODD' addresses*/
/* Note: all devices in the 2nd EXCTG get the HOWMANYE records so */
/* that in reports we see more activity on that EXCTG */
/* */
/* Allocate dialog manager libraries*/
ADDRESS ISPEXEC "LIBDEF ISPSLIB DATASET ID('GPSE.URMETRCS.SKEL')"
say "LIBDEF ISPSLIB rc= " rc
/* */
ThisHour = time(h)
If ThisHour >= 0 and ThisHour <= 5 then BTCH = 0
If ThisHour >= 6 and ThisHour <= 18 then BTCH = 1
If ThisHour >= 19 and ThisHour <= 23 then BTCH = 2
If BTCH = 0 then do
HOWMANYE = 50/* 500K records written */
HOWMANYO = 10/* 100K records written */
end
If BTCH = 1 then do
HOWMANYE = 5 /* 50K records written */
HOWMANYO = 1 /* 10K records written */
end
If BTCH = 2 then do
HOWMANYE = 75000 /* 75K records written */
HOWMANYO = 25000 /* 25K records written */
end
/* --- */
/* Process skeleton and output JCL */
/* --- */
address ISPEXEC
"FTOPEN"
"FTINCL SKELIBDG"
"FTCLOSE NAME(BLDIEBDG)"
address TSO
free f(ISPFILE)
submit 'GPSE.URMETRCS.JCL(BLDIEBDG)'
SYSTSPRT output:
READY
%BLDIEBDG
16 *-* ADDRESS ISPEXEC "LIBDEF ISPSLIB DATASET ID('GPSE.URMETRCS.SKEL')"
+++ RC(-3) +++
LIBDEF ISPSLIB rc= -3
40 *-* "FTOPEN"
+++ RC(-3) +++
41 *-* "FTINCL SKELIBDG"
+++ RC(-3) +++
42 *-* "FTCLOSE NAME(BLDIEBDG)"
+++ RC(-3) +++
44 +++ free f(ISPFILE)
IRX0043I Error running BLDIEBDG, line 44: Routine not found
READY
END
JCL:
I have JCL with every dataset in every ISPF related DD that exists in my TSO
session. That's a lot so I won't copy it all here:
//BLDIEBDG JOB MSGCLASS=X
//*
//BUILDIT EXEC PGM=IKJEFT01
//SYSEXEC DD DISP=SHR,DSN=GPSE.URMETRCS.REXX
// DD DISP=SHR,DSN=AOP.SAOPEXEC
... and more in the concatenation
//ISPILIB DD DISP=SHR,DSN=ISP.SISPSAMP
//ISPLLIB DD DISP=SHR,DSN=SYS1.DFQLLIB
- - - - - - - - - - - - - - - - 1 Line(s
//ISPMLIB DD DISP=SHR,DSN=ISP.SISPMENU
- - - - - - - - - - - - - - - - 10 Line(s
//ISPPLIB DD DISP=SHR,DSN=AOP.SAOPPENU
- - - - - - - - - - - - - - - - 18 Line(s
//ISPPROF DD DISP=SHR,DSN=GPSE.URMETRCS.ISPF.ISPPROF
//ISPSLIB DD DISP=SHR,DSN=GPSE.URMETRCS.SKEL
- - - - - - - - - - - - - - - - 9 Line(s
//ISPTABL DD DISP=SHR,DSN=GPSE.URMETRCS.ISPF.ISPPROF
//ISPTLIB DD DISP=SHR,DSN=GPSE.URMETRCS.ISPF.ISPPROF
JCL looks OK, you need to use ISPSTART to invoke your Rexx exec. That
will establish the ISPF environment.
Regards,
Tom Conley
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another DFSORT Question
Cameron. I sent you an offline email with a generic solution which covers all the issues that I raised. Let me know if you have any questions. Thanks Kolusu DFSORT Development IBM Corporation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another DFSORT Question
Hello Sri, Argh!! Yes too many assumptions... 1) True. Not thinking of DSN on a separate line. 2) True. Step names can be single characters. 3) A temporary Dataset still has a Dataset Name, or a Dataset Name reference, right? 4) I did not know DMBATCH could have SYSIN2. 5) True. This was my attempt at ignoring any sequence numbers that might be in 73-80. The reason for this exercise is that in some situations, the DMNETMAP and DMMSGFIL DataSet Names need to be modified. The Dataset Names need to have a newer value when certain conditions are met in the NDM control statements. I first tried scanning all of our Control Statement libraries and found over 80,000 possibilities. Then I thought I could check the JCL and PROCS, and grab a list with all the JCL/PROC Member Names and their associated DMNETMAP, DMMSGFIL, and SYSIN dataset names. Then from this list I could ignore the JOBs where the Dataset Names have already been updated. This gives me a much smaller list. Several hundred items. Then I will need to check each of the associated SYSIN members manually to determine if any changes may be required. Anyway, thanks for taking some time to explain this. On Thu, Oct 29, 2020 at 7:53 PM Sri h Kolusu wrote: > > The control statements below work fine. They do what I wanted. > > Today my question is if these SORT Control statements can be optimized? > > This is not urgent. > > > Cameron, > > Your job definitely can be optimized. But I want to make a observation > that you might be skipping some results. > > You are assuming that the ddnames DMNETMAP and DMSGFIL have the dataset > name on the same line. > > 1. ) For example if your input has the following Input, you will NOT pick > the DSN names > > > > //DMNETMAP DD DISP=SHR, > //DSN=$HLQ.NETMAP > //DMPUBLIB DD DISP=SHR, > // DD DSN=$HLQ.PROCESL > //DMMSGFIL DD DISP=OLD, > //DSN=$HLQ.MSG4 > > > 2.) Similarly the stepnames can any where from 1 byte to 8 bytes, however > your picking bytes from 4 thru 8 . Assume the following input > > //S1 EXEC PGM=DMBATCH,REGION=1024K,PARM=(YYSLYNN) . > > > > 3.) What happens if SYSIN cards are generated from previous step as a temp > dataset and passed over to DMBATCH step? > > ex: > > https://www.ibm.com/support/pages/how-submit-instream-process-jcl-using-dgadbatc-dmbatch > > Check how & is generated. > > How do you plan to handle the & contents? > > > 4.) Also the program DMBATCH can have SYSIN2 also, do you plan to extract > the information? > > > 5.) Technically SYSIN can be a PDS with member name. So the maximum length > of PDS+Member = 54 bytes ( 44 Dsn name+ 8 byte member name + 2 byte for > opening and closing parenthesis). However your control cards don't seem to > be handling them. > > Let me know the answers to be above questions and I will show you the > optimized control cards. > > > Thanks, > Kolusu > DFSORT Development > IBM Corporation > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UNIX fork() performance (was: SMF to capture ... )
Andrew, In the SDSF PS display for the COZBATCH example, all the PIDS ran in the same AS except for the one you asked about: ANDREWRB STC03080 RUNNING ANDREWR 1R 16843329 1684334979 004F /bin/sh /home/andrewr/breakit.sh the parent of this is process: ANDREWRB JOB03101 WAITING FOR CHILDANDREWR 1W 16843349 5039778051 0033 /bin/sh /home/andrewr/breakit.sh Both of these are what you see when you run a shell script file with /bin/sh. I'm not sure what breakit.sh does, but these two are what you would see if the /bin/sh shell forked itself without doing an exec. This is what the shell would do for cases like using a builtin in a pipe. If you aren't pretty familiar with what the fork() and exec() system calls in UNIX actually do, you might want to look at it. It's really wacky, and I think that a good understanding is probably helpful here. On Thu, Oct 29, 2020 at 9:40 PM Andrew Rowley wrote: > On 30/10/2020 2:32 am, Kirk Wolf wrote: > > Your performance work in this area is very interesting to me. I would > love > > to hear more if you ever write up your findings, even informally. > > I have been looking at SMF data and trying to build a picture of the > work that was running from the SMF records. I have written up some of > what I have found here: > > https://www.blackhillsoftware.com/news/2019/08/27/comparing-bash-and-bin-sh-on-z-os/ > and here: > > https://www.blackhillsoftware.com/news/2019/06/20/understanding-z-os-unix-work-with-easysmf/ > > When a job runs unix work much of the work can appear in SMF records for > the unix tasks, not the original job. > > E.g. for the script I was testing, running under bash only 0.02s of CPU > time appears in the SMF record for the job. But there are SMF records > for about 9000 unix tasks which add up to about 66s of CPU. > > Under /bin/sh, the job CPU time appears the same at 0.02s, but with the > records from the unix work it is about 4.7s. Either way, you miss most > of the work if you just look at the job records. > > Interestingly, I tried running the script under COZBATCH and it broke > the logic to associate the unix tasks with the main job. I will have to > look into that. COZBATCH did run steps in a separate address space and > generated about the same number of SMF records, but it looked different > to BPXBATCH with _BPX_SHAREAS. > > I don't really understand what I see in the SDSF PS display. The same > script, run under COZBATCH and BPXBATCH with _BPX_SHAREAS (sorry about > the wrap): > > JOBNAME JobIDStatus OwnerState PID PPID > ASID ASIDX Command > ANDREWRB JOB03101 FILE SYS KERNEL WAIT ANDREWR 1F 66115 16843349 > 51 0033 cut -c1 > ANDREWRB STC03080 RUNNING ANDREWR 1R 16843329 > 1684334979 004F /bin/sh /home/andrewr/breakit.sh > ANDREWRB JOB03101 WAITING FOR CHILDANDREWR 1W 16843349 > 5039778051 0033 /bin/sh /home/andrewr/breakit.sh > ANDREWRB JOB03101 WAITING FOR CHILDANDREWR 1W 50397780 > 6717512251 0033 /bin/sh > ANDREWRB JOB03101 FILE SYS KERNEL WAIT ANDREWR 1F 67175122 > 151 0033 COZBATCH > > > JOBNAME JobIDStatus OwnerState PID PPID > ASID ASIDX Command > ANDREWRE STC03080 RUNNING ANDREWR 1R 33620729 > 5039738879 004F setfacl -m u:IBMUSER:rwx broken/24793 > ANDREWRE STC03080 WAITING FOR CHILDANDREWR 1W 50397388 > 8395221279 004F /bin/sh /home/andrewr/breakit.sh > ANDREWRE JOB03106 FILE SYS KERNEL WAIT ANDREWR 1F 83952212 > 151 0033 BPXBATCH > > What is the extra "/bin/sh /home/andrewr/breakit.sh" command in the > separate address space under COZBATCH? > > Under COZBATCH, PS consistently showed the cut command which is part of > the pipe. Under BPXBATCH, the only command which seemed to show up was > setfacl. Presumably that is because that was the command where most of > the time was spent. > > -- > Andrew Rowley > Black Hill Software > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
