Re: Name those boxes
The phone is a Western Electric model 500 https://en.m.wikipedia.org/wiki/Model_500_telephone On Tue, Aug 18, 2020 at 12:32 AM Seymour J Metz wrote: > There is no 2741 in the picture. The typewriter is part of the 1415. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > > > From: IBM Mainframe Discussion List on behalf > of Phil Smith III > > Sent: Monday, August 17, 2020 10:07 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Name those boxes > > > > > https://secure-web.cisco.com/1wkescQogaCLX8ueoKv8kHzmBmghk3VYI8ArOTGMD8PbFT_AcfhqD2o0A9G3F6datv8ROLRHa2cqqkRALje2QbH79Tb0ldDn-Bpko56xBrZAMvTDM77nB1aUT1_X-Ru-H_gCDWXboEvJvGp66tNPt5DDOHVeuo1TfitH8KsbfeKGNtnmtA_ov9bBcb9djDmfmvbTy2ZB7T5mnmCDXwWQ6VMrvHIoXe2X0Ph4ZZJBs1gTIgtxKCAlxfiH6MktaiIATzElHIMReMi-izExYjyGfpqy80hU5EpKSeeAOpYZNhq9Q9gpR_mjikzaNse7d0BW8gS4RxFMoAnR5d-pIAvOE2IoImQGSivF4Poj_lHUTXICPU2riiI5VjMehFThb0X751iX66GpSN3G9EHDSbzmKiPPOdZ8yFiYBMYJdiaN3wEDSfECSo_AnEhSS5nRkYw3OrD2JgYwlVrogAz1nVpBbDw/https%3A%2F%2Fi.redd.it%2Fkd2ebwoovbh51.jpg > > > > > > > > Best guess so far: 1415, console etc. for 1410. For extra credit, identify > small box on desk, too (not the phone or the 2741). > > > > > > -- > > 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 > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSORT and SS search
If they were supported then he wouldn't need the RFE. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Sri h Kolusu Sent: Monday, August 17, 2020 6:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFSORT and SS search > This could be done thorough an RFE to JCL and no change to SORT, > such as (suppose this worked): > > // SET X01=X'01',X05=X'05' > //* Then: > //SYSINDD *,SYMBOLS=JCLONLY > OPTION COPY > INCLUDE COND=(1,500,SS,EQ,'&X01.1&X05.ABCDE') > Gil, Hex values aren't supported for set statement. You would get IEFC629I INCORRECT USE OF APOSTROPHE ON THE SET STATEMENT error. If you want to pass hex values then you need to edit the SET statement by turning on HEX mode and override the hex values. Something like this // EXPORT SYMLIST=* // SET X01=' ',X05=' ' 6644ECE44EFF77076EFF7707 110025300701ED1DB705ED5D //* //STEP0100 EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTIN DD * ABC 1 ABCDEG 1 BBCDE //SORTOUT DD SYSOUT=* //SYSINDD *,SYMBOLS=JCLONLY OPTION COPY INCLUDE COND=(1,80,SS,EQ,C'&X01.1&X05.ABCDE') /* 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: Name those boxes
There is no 2741 in the picture. The typewriter is part of the 1415. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Phil Smith III Sent: Monday, August 17, 2020 10:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Name those boxes https://secure-web.cisco.com/1wkescQogaCLX8ueoKv8kHzmBmghk3VYI8ArOTGMD8PbFT_AcfhqD2o0A9G3F6datv8ROLRHa2cqqkRALje2QbH79Tb0ldDn-Bpko56xBrZAMvTDM77nB1aUT1_X-Ru-H_gCDWXboEvJvGp66tNPt5DDOHVeuo1TfitH8KsbfeKGNtnmtA_ov9bBcb9djDmfmvbTy2ZB7T5mnmCDXwWQ6VMrvHIoXe2X0Ph4ZZJBs1gTIgtxKCAlxfiH6MktaiIATzElHIMReMi-izExYjyGfpqy80hU5EpKSeeAOpYZNhq9Q9gpR_mjikzaNse7d0BW8gS4RxFMoAnR5d-pIAvOE2IoImQGSivF4Poj_lHUTXICPU2riiI5VjMehFThb0X751iX66GpSN3G9EHDSbzmKiPPOdZ8yFiYBMYJdiaN3wEDSfECSo_AnEhSS5nRkYw3OrD2JgYwlVrogAz1nVpBbDw/https%3A%2F%2Fi.redd.it%2Fkd2ebwoovbh51.jpg Best guess so far: 1415, console etc. for 1410. For extra credit, identify small box on desk, too (not the phone or the 2741). -- 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: Name those boxes
I think that is the console switch unit. And yes, very likely a 1415. -- Will On Mon, Aug 17, 2020 at 10:08 PM Phil Smith III wrote: > > https://i.redd.it/kd2ebwoovbh51.jpg > > > > Best guess so far: 1415, console etc. for 1410. For extra credit, identify > small box on desk, too (not the phone or the 2741). > > > -- > 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
Name those boxes
https://i.redd.it/kd2ebwoovbh51.jpg Best guess so far: 1415, console etc. for 1410. For extra credit, identify small box on desk, too (not the phone or the 2741). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSORT and SS search
On Mon, 17 Aug 2020 15:34:56 -0700, Sri h Kolusu wrote: >> This could be done thorough an RFE to JCL and no change to SORT, >> such as (suppose this worked): >> >> // SET X01=X'01',X05=X'05' >> //* Then: >> //SYSINDD *,SYMBOLS=JCLONLY >> OPTION COPY >> INCLUDE COND=(1,500,SS,EQ,'&X01.1&X05.ABCDE') > >Hex values aren't supported for set statement. You would get IEFC629I >INCORRECT USE OF APOSTROPHE ON THE SET STATEMENT error. > My key word was "RFE". And since the construct is now prohibited, introducing it as an enhancement would cause no breakage of current art. >If you want to pass hex values then you need to edit the SET statement by >turning on HEX mode and override the hex values. > Many programmers prefer desktop editors that have no HEX mode. I have often chosen to embed JCL as here-documents in shell scripts which write to INTRDR so I can use the power of shell facilities. As I conjectured, enhancements to SORT are granted more readily than enhancements to JCL. Regular expressions meet the need. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSORT and SS search
> This could be done thorough an RFE to JCL and no change to SORT, > such as (suppose this worked): > > // SET X01=X'01',X05=X'05' > //* Then: > //SYSINDD *,SYMBOLS=JCLONLY > OPTION COPY > INCLUDE COND=(1,500,SS,EQ,'&X01.1&X05.ABCDE') > Gil, Hex values aren't supported for set statement. You would get IEFC629I INCORRECT USE OF APOSTROPHE ON THE SET STATEMENT error. If you want to pass hex values then you need to edit the SET statement by turning on HEX mode and override the hex values. Something like this // EXPORT SYMLIST=* // SET X01=' ',X05=' ' 6644ECE44EFF77076EFF7707 110025300701ED1DB705ED5D //* //STEP0100 EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTIN DD * ABC 1 ABCDEG 1 BBCDE //SORTOUT DD SYSOUT=* //SYSINDD *,SYMBOLS=JCLONLY OPTION COPY INCLUDE COND=(1,80,SS,EQ,C'&X01.1&X05.ABCDE') /* 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: DFSORT and SS search
On Mon, 17 Aug 2020 13:43:31 -0500, Elardus Engelbrecht wrote: > >Not a trick question. This is more for my users who are too lazy or dumb to >use a mix of hex and characters... ;-) > >>Something like this >>//SYSINDD * >> OPTION COPY >> INCLUDE COND=(1,500,SS,EQ,X'01F105C1C2C3C4C5') > >Many thanks. I eventualy used that X'???' format. I don't mind to do all the >char to hex conversion myself. There is actually a REXX function just for >that. Or I can just enter all fields in Char in a dataset and then use HEX >DATA for a copy/paste into DFSORT/ICETOOL JCL. > This could be done thorough an RFE to JCL and no change to SORT, such as (suppose this worked): // SET X01=X'01',X05=X'05' //* Then: //SYSINDD *,SYMBOLS=JCLONLY OPTION COPY INCLUDE COND=(1,500,SS,EQ,'&X01.1&X05.ABCDE') But an RFE to JCL seems less likely to succeed than an RFE to SORT even though it would be far more useful. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
What is the SDATA option to include above the bar storage for a particular job?
What is the SDATA option to include above the bar storage for a particular job? It should be obvious, but I am missing it. -- Binyamin Dissen 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSORT and SS search
> That absolutely works, but it's less intuitively legible than (e.g. in Rexx): > say '01'x || '1' || '05'x || 'ABCDE' > (I've wished for similar facility in JCL. Gil, DFSORT V2R4 Supports Regular Expressions. You can use the following to get the desired results. //SYSINDD * OPTION COPY INCLUDE COND=(1,500,SS,REH,C'(.*\X011\X05ABCDE)') /* >>This is more for my users who are too lazy or dumb to use a mix of hex and characters... ;-) I initially wondered if that is possible using mixed formats ala REXX, Elardus, If you have DFSORT V2R4 then you can use Regular Expressions as shown above with the mix of HEX and EBCDIC characters. 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: DFSORT and SS search
Paul Gilmartin wrote: >Welcome back. I've missed you since February. Many thanks. Was busy with projects which kept me too busy and somewhat sidetracked ... I also missed being on the discussion lists where I can get advice and give assistance where I can.. >That absolutely works, but it's less intuitively legible than (e.g. in Rexx): >say '01'x || '1' || '05'x || 'ABCDE' >(I've wished for similar facility in JCL.) I agreed. If a parameter can contains mixed format(s), it would be very helpful. Same as for output where I want to print out things in numeric, hex, char, hex, etc. all in one row from input. Something like IDCAMS PRINT ... DUMP where one half is hex and other half is char. >What if there's a 30-character key containing only one nonprintable character? Ouch ... in COBOL, you get a S0Cx abend. Hard to find that record out of a few millions records. Been There and Got The T-Shirt. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSORT and SS search
Sri h Kolusu wrote: >Unless this is a trick question, isn't it simple to have the entire search >string in HEX since all the fields are next to each other? Not a trick question. This is more for my users who are too lazy or dumb to use a mix of hex and characters... ;-) >Something like this >//SYSINDD * > OPTION COPY > INCLUDE COND=(1,500,SS,EQ,X'01F105C1C2C3C4C5') Many thanks. I eventualy used that X'???' format. I don't mind to do all the char to hex conversion myself. There is actually a REXX function just for that. Or I can just enter all fields in Char in a dataset and then use HEX DATA for a copy/paste into DFSORT/ICETOOL JCL. I initially wondered if that is possible using mixed formats ala REXX, but then I remembered OPTION VLSCMP which included short records too where OPTION VLSHRT totally sidetracked me. Eventually I finally got all my results. Many thanks! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSORT and SS search
On Mon, 17 Aug 2020 08:00:39 -0700, Sri h Kolusu wrote: >>>I want to search for four terms: X'01' and C'1' and X'05' and C'ABCDE'. >All these 4 terms are next to each other. > >Elardus, > Welcome back. I've missed you since February. > >Unless this is a trick question, isn't it simple to have the entire search >string in HEX since all the fields are next to each other? > >Something like this > >//SYSINDD * > OPTION COPY > INCLUDE COND=(1,500,SS,EQ,X'01F105C1C2C3C4C5') >/* That absolutely works, but it's less intuitively legible than (e.g. in Rexx): say '01'x || '1' || '05'x || 'ABCDE' (I've wished for similar facility in JCL.) What if there's a 30-character key containing only one nonprintable character? "Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy." -- AlanPerlis But, I know, Ob: camel's nose. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z13s to z15 Mainframe
On 8/17/2020 6:28 AM, Charles MacNiven wrote: Hi, anyone aware of a migration path from z13s to z15 (T01 or T02). There is no MES Upgrade from z13s to z15-T02 (as there is from z13s to z14-ZR1). However, there is a "Migration Offering" (MO) which effectively results in a trade-in of your z13s as part of the z15-T02 purchase. I seriously doubt anyone with a z13s will upgrade to a z15-T01 unless they've experienced hardware resource limits on the z13s. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z13s to z15 Mainframe
Hello, We have been involved in a number of these Mitch -Original Message- From: Charles MacNiven <0325e5af57fe-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Mon, Aug 17, 2020 8:28 am Subject: z13s to z15 Mainframe Hi, anyone aware of a migration path from z13s to z15 (T01 or T02). Many thanks, Charles. -- 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: Reminder: Don't "Forget" Your CFRMPOL Keywords
On 8/17/2020 4:59 AM, Bill Neiman wrote: I'm a bit confused by this. CFRMPOL is only relevant when you IPL with a CFRM couple data set (CDS) that has never been used before, so there was no previously-activated policy. It's normally not necessary to update the CFRMPOL statement when you update your CFRM policy, unless you're changing *which* policy you're using. Even then, it only matters if you come up with a new CFRM CDS. The CFRM CDS records which policy was last used, and that's the policy that will be used if you are forced to perform a sysplex-wide IPL. There must be more to this story. Take a look at software case TS004055963 and hardware PMH 59261,227,000 (and several other related PMHs automatically opened since). We came up with new CFRM data sets using the CFRM policy specified in CFRMPOL. While up, we switched CFRM policies but did not update CFRMPOL in COUPLExx as we should have (and as my reminder admonishes others to do). We then experienced a CPC failure in the early AM on 8/15 that took down all LPARs and internal coupling facilities. When coming up after the "crash," all of our structures were at the old sizes. Turned out we were running the policy specified in CFRMPOL and not the policy we had switched to prior to the crash. That's when I started this "reminder" thread. I took my own advice and corrected CFRMPOL to reflect our current policy. Good thing I did because we had a second second crash of the same type at 9PM that same day. Coming back up after that crash, all structure size are as expected. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z13s to z15 Mainframe
There isn't a 'valid' upgrade path from a z13s to z15 T01 or T02 (BTW: there isn't one from z15 T01 to T02 either!!). However, there may be 'other' options. Remember, an 'upgrade' normally means keeping the same serial number. This may be necessary for legal/financial reasons. Other options (if available, migration offering i.e. z13s to z14 ZR1 to z15 T01) may be possible. Best talk to your IBM or BP salesperson. Regards Parwez Hamid From: IBM Mainframe Discussion List on behalf of Charles MacNiven <0325e5af57fe-dmarc-requ...@listserv.ua.edu> Sent: 17 August 2020 14:28 To: IBM-MAIN@LISTSERV.UA.EDU Subject: z13s to z15 Mainframe Hi, anyone aware of a migration path from z13s to z15 (T01 or T02). Many thanks, Charles. -- 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: DFSORT and SS search
>>I want to search for four terms: X'01' and C'1' and X'05' and C'ABCDE'. All these 4 terms are next to each other. Elardus, Unless this is a trick question, isn't it simple to have the entire search string in HEX since all the fields are next to each other? Something like this //SYSINDD * OPTION COPY INCLUDE COND=(1,500,SS,EQ,X'01F105C1C2C3C4C5') /* 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: z13s to z15 Mainframe
W dniu 17.08.2020 o 15:28, Charles MacNiven pisze: Hi, anyone aware of a migration path from z13s to z15 (T01 or T02). Technically it is possible. "Migration path" is a trick to do "upgrade" instead of "replacement". It has meaning from tax, legal, accounting point of view. I saw such migration: the only element "carried forward" were empty "airflow" cards. And serial number. Note: sometimes more elements are carried forward. That cause significant change in technical process: an outage is required. You cannot have both machines (new and old) side by side, both working. Of course, when buying z15 you can negotiate buy back of your z13s. And in this case you may negotiate time of coexistence both machines on the floor which makes the migration easier and safer. My €0.02 -- 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
DFSORT and SS search
Good day to all DFSORT gurus,
Ok, I was not into these discussion lists for a time, was busy with 1001 other
things..
Question: Is it possible to use SS ('Substring Search') where I search for
variety of formats, like this one:
With input (sitting "anywhere" in a record):
3---
1 ABCDE
0F0CCDDC
11581797
... I want to use SS to search for above input:
+1+2+3+
1,500,SS,EQ,X' 'C'1'X' 'C'ABCDE'
F6FFF6EE6CD6E707C7F7E707C7C7
1B500B22B58B7D1D3D1D7D5D3D12345D
I want to search for four terms: X'01' and C'1' and X'05' and C'ABCDE'. All
these 4 terms are next to each other.
You Assembler gurus should immediately see that I want search 4 terms where the
term 1 and term 3 are having the lengths of term 2 and term 4.
I have a source file where I am having different such sets of 4 terms, like
term 2 is 3 characters long and term 4 is say 3 characters long, but I need to
select only these records where term 2 is 1 character long and term 4 is 5
characters long.
Is it possible with DFSORT (and ICETOOL)?
This is easy to program, but dataset is large (define "large" ;-D ) and I want
to have one single pass with several SS statements.
Many thanks in advance.
Groete / Greetings
Elardus Engelbrecht
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z13s to z15 Mainframe
We are in the process of that upgrade also, the frames are different, RACK mounted, and no HMC is required, HMA, is a virtual HMC, depends on your requirements and current configuration, there's a lot of new functions and features for encryption and FICON channels. software, I'm 2.3 moving to 2.4 so the normal migration requirements, check FIXCAT's or for old school PSB bucket or both :) not much else I can think of off hand. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z13s to z15 Mainframe
Charles, We have this same upgrade in the works. But, the z13s and z15 frames are different sizes, so it is not possible to upgrade the z13s to z15. It will have to be a replacement. Does that help, Thanks, Jerry -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles MacNiven Sent: Monday, August 17, 2020 9:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z13s to z15 Mainframe This message was sent from an external source outside of Western & Southern's network. Do not click links or open attachments unless you recognize the sender and know the contents are safe. Hi, anyone aware of a migration path from z13s to z15 (T01 or T02). Many thanks, Charles. -- 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: Rexx detail, or things I dont do often enough
Gil asked. " What does that have to do with Rexx?" The link to REXX is simply that CLIST language was around long before REXX was thought of. The OP said he had a "vague memory" of doing this, so I simply wondered if he had remembered doing in in CLIST language rather than REXX. My memory of CLIST language is pretty vague too. But there is also a DATA PROMPTENDDATA sequence which can be used. I was not suggesting that the OP use CLIST (despite one or two advantages against REXX). I was merely trying to assist with the "vague memory". Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: 15 August 2020 01:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Rexx detail, or things I dont do often enough On Fri, 14 Aug 2020 23:29:21 +, Dymoke-Bradshaw, Lennie wrote: >There is a DATA ENDDATA pair that can be used in TSO CLIST processing. > What does that have to do with Rexx? The CLIST Ref. says: commands | subcommands The data to be ignored and passed to TSO/E for execution. I don't believe this meets the OP's need. -- gil -- 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
z13s to z15 Mainframe
Hi, anyone aware of a migration path from z13s to z15 (T01 or T02). Many thanks, Charles. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Modules in JPA of a TSO Address Space
a program to do load of some modules I would assume they remain in the private address space, Are you trying to ask something subtle? In what other address space could they possibly be in? As with any load, it will go into the private storage of the issuing address space unless GLOBAL=YES is specified or the module is already in LPA. Or is "remain" the key to your question? A module will remain loaded until it is deleted or the loading task terminates. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reminder: Don't "Forget" Your CFRMPOL Keywords
I'm a bit confused by this. CFRMPOL is only relevant when you IPL with a CFRM couple data set (CDS) that has never been used before, so there was no previously-activated policy. It's normally not necessary to update the CFRMPOL statement when you update your CFRM policy, unless you're changing *which* policy you're using. Even then, it only matters if you come up with a new CFRM CDS. The CFRM CDS records which policy was last used, and that's the policy that will be used if you are forced to perform a sysplex-wide IPL. There must be more to this story. A friendly reminder to update your COUPLExx CFRMPOL keywords _any and every time_ you update your sysplex CFRM policy. If you experience a total coupling facility failure (which seems impossible, but yeah) then you will be effectively performing a sysplex "cold" start on the next IPL. If you neglected to update CFRMPOL, then you will fall back to the wrong policy and that's just the beginning of your troubles... Bill Neiman Parallel Sysplex Development IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ClefOS signing key
Thanks! I don't wish to ignore the signatures :-). On Mon, Aug 17, 2020, 08:14 At: Http://Doodle.Com/Poll/E5In4Utu77Dspg42 < ne...@sinenomine.net> wrote: > No, the ClefOS packages are signed with the key that gets installed with > the distro: /etc/pki/rpm-gpg/RPM-GPG-KEY-ClefOS-7 which is in the > centos-release RPM. > > -BEGIN PGP PUBLIC KEY BLOCK- > Version: GnuPG v1 > > mQINBFYG0eIBEACinswhGSisjaTeN6jfYcSsuYWrkNnSUyueC90xAtsTVxABu/+A > BsK8tCqlAX4W8mlYJzhvaRNhe2zUcIz09MKjIRkrj8ZBmFScRIEDtQF44QZN7Q9Q > /S1zYwbAtjshlq7x2GvNlzs7mHwoKgKuShO+VtMoFlOgBD0NwqxddEHZM7fB+XyY > 7SrRaJUj6CCiWvKRJmRyY2Z3S3lZnfoRd6gtJau4yIyuUJiPTsN0R6luGOfLveFN > OIaFS7MpXwm0Xew7prZEI9dUyUMrluyX1MYpxB9fZcBpfJrT5CInWrWBplHm0SKG > DCgzhsCWBLXjqwSV2x9kw42QfyVqsuBP1uH9GRbD/sohLkdCxor8TZDAzQeEswqt > 2mJ9JTYzEMPsex5Ey/vApE1q7Ua2EhISI68VjVQk/9VhUwjyfCgHNZ8oM+OPaTKY > 0n3UlDIsOnkaIGuKxVb3QQ4u0MPBBMkIjk7+R/mQVRH5U7TAp6Oa6urfLBu4tZQG > R0VS8jNKbpPlwrN1XwXJWdL6t3ASjLP69sag+84m+YqBO12Ye+5Pv4u2ZEapKvz0 > 8v7QcJRJHk6PCIX437WliJ6Bs+1icurG8EOTqO5prt9jjZVdljPYQ04LaOErBYCx > bDtdtymuEQ+B8jnf31cG2w40elK4uM1F+tn9A93G5MYYykegy/1sIMAokwARAQAB > tDhDbGVmT1MgNyAoQ2xlZk9TIDcgU2lnbmluZyBLZXkpIDxjbGVmb3M3QHNpbmVu > b21pbmUubmV0PokCPgQTAQIAKAUCVgbR4gIbAwUJEswDAAYLCQgHAwIGFQgCCQoL > BBYCAwECHgECF4AACgkQrmrvqNy7TQlC5xAAoQXsYC6sn20VhGDQuVyDui+4Wp+2 > cLj1Ji6YUn1OQrbVM4wp2ewp1ekfKPL2bMBIn9KqRqrx1CplwYi7VfUI3B4/eBA+ > k4Mn+DvQXnv4syQr+cEhgzbh4a9H/a5CxNif+19kJfdDc1G4gizYGX/XoQ6+3kpH > i7ktWA5N1i9hCF3GCgBeAw0D+nSo2QuQ6PKDnSgr6wi0AvmAg956/ps9RL16NgFC > Q88t3Ann5Go5sry6XKOftoKGdxMZ3BKR7/t5/A5/ceHT33AX7BqAgNsd02Xb0VzO > 76H3Pq8NLcbKSs/ZJPAxzCGHp2AXd4nHP62Ks0Ks1HIleHBFrrKbZUwC9qD9p40m > /NwRwmbpElyZBDjW1uH1MpmcIungh3kheA/wOK0ElMLAZrW6efFag9e/3wp+owOh > OqrHzAu0WCwuwHuz368XMwsxHYSVol986T00I5T/t7TDDdBq/5RkzMHx2FEhzpwu > BDMkxnkCqHAps9z29DmEhOZw6uwd/DeGUOhG4l/Wen2E7PkP9/TR4W+AdcB4PqYW > gophBu4nwp8k0X9a0HZodG6swCkfEnZaC8BHIzm2vp+/5IUcmaxp8hrSp2jDrtYk > EofgeHuhHbujq4usaS3BDaguSPbXDe6ou7Mx/EmwWIzF3QSSPzFPTv47+ZDGL+wE > CCpa9qe1zeQtGK+5Ag0EVgbR4gEQANAheLsFQ3v+XV+As/RW71liAav1v8w4x25j > nCoNF4GUmmyKPnrNny7mTPfmg3MHPoPDRgU+brIr6Xsm4e63G7I+asdFKkSlKXd4 > +uyH8aaTIIyKPODQk7RH6YPCIxDH1hNcQxVWCJaJiB5fo/VXLh9e8OQ1XXhu4dsp > dyrNimpzA6JuMRVWBm1Vf4u6WSJ1uFZyRkOKkqgc7zJLwYcsASbKXgjA23hxMPHM > O3bZkOO7BWPsMVr9rD5XlO2uSU8xfGAozt9qVIfVOCZ87A6GJOONqdENYXwyTDDa > hiW9LsoYuxO5zbnvCOXfqjCqOJUH7I+2TCKWBZFwtKdMTZ0g8oVi/SMAuTz/dyA5 > 7dJsayGFLQknemNGFIzmCZqVzfbvwwRIHUkOZwRSFamVl8rkpd94OyEj/T29sXtx > ycxWV+nUgsLaIMstoEABj6zVBnoapNQWLdjLYejdqCmUNGUzDSn5GpaGkU49KMQ4 > aEfGZVSTxncqWdnG7d362CvpcZxkiXGe9ZRtJeXacNeNqgiyz1ugdFSgaN95bAN0 > JXKWuvGDVaDnBjdBauJOHtdppFbZRXNxBKMGsYZkuGpKetjS8rvQUiSxTn6A0HDQ > o2EBUPuc8Yql+3AiRWaEQ4WCPitx1FSTw/ZVQD6BByAjSfWCyKsPs922SSTNW6su > rbVOsE//ABEBAAGJAiUEGAECAA8FAlYG0eICGwwFCRLMAwAACgkQrmrvqNy7TQl9 > hxAAjFHPH3FCNkLLCc/EQmjZ6DTEIQqvOukmpZnHPatZuo0iiKzBxHE0M0OQiKCQ > hUuaPyw1FuopjozJ2MoxHZPBRAvC3kbqNhzW+zSYYA7uks2TLAI3noLlfwN/byGA > oWBO5S3g4dAU+LaemqiD6rwLBNM3GLFuPc3HcBVcEmj76GIrCXtDwK8+yA3SXnhy > gey+aWF4YWnZ9VT3eh/SGGPaD3N+V0dLpH45HznGuNCg8eqqDY8p1UIv8Vs3wZ5s > VxG1q+7vV5iZSNiLRQ0LNp4TpREOVDhZEwxB5zn6g1fWJONd6cgyeQoxAN77ytMe > s5ro0lgTKhIa6HcSi5EghPltmDwYJo+mNc1Ka66zxxDw91otmV+2raf0zV9VSO2m > 6ZmCr+tK0IHJso4M9pzr9JM/+GRzxvJ6tNw8yB42EoSKwrDvOqAlp3ZlSO30xqLl > MvhT9Ug8maRwjrM/nJ7zC+x+SRvzmxs2bwfDN78bdA2Yo4HGqVaaRgAv+TthlIbr > 6QKXqK0jxvEq7t9LMPtCYyS14oxRPiqLwewKIzoJqDFcmgkVkZSK6D4ygJ0k20w2 > +UZkb1/+KkFwbKWbyzpeQogBhy35sQDShmBeImf1qHy7Q2cyBIyPCItQKLih5FE1 > yanqGMb6br06pUcy8Plbe5iXxOONRGsNEl/TLpls4VEMUOc= > =R3bB > -END PGP PUBLIC KEY BLOCK- > > You can always use the yum --nogpgcheck option to ignore signatures. > > Neale > > -- > 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: (yet another) problem with zcx container
I hear what you say, Brian - perhaps I should be a little less trusting. Nevertheless, the book goes on to cover installation of 'Cadvisor' and 'Prometheus', too, both of which are required for grafana to do its job. (and I'm having similar difficulty with Cadvisor, too.) Regards Sean On Fri, 14 Aug 2020 at 12:15, David Crayford wrote: > I doubt it would be in production if it wasn't ready :) > > On 2020-08-14 4:32 PM, Brian Westerman wrote: > > I hate to say this but I can't help myself, but what makes you think > they actually got it to work? :) > > > > But seriously, the redbooks are written sometimes before the final > processes are set in place, so sometimes they tell you what "should be" > instead of what "is be". > > > > From what you are saying, your way should certainly work, but it's hard > to debug without the entire process to look at and implement myself. > > > > Brian > > > > -- > > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
