RCF: z/OS Version 2 Release 4 MVS JCL Reference, SA23-1385-40

z/OS Version 2 Release 4 MVS JCL Reference, SA23-1385-40 The example on pages 94-95 of z/OS Version 2 Release 4 MVS JCL Reference, SA23-1385-40, is unclear. I might guess that the Converter makes the RECFM V or VB when it sees two lines of differing length, but nowhere can I find a statement

Re: TSO Pipes (and BatchPipes)

On 4/22/20 9:56 AM, Lionel B Dyck wrote: it is actually old enough to drink: It's not that long until MVS itself is old enough to collect social security ... -- Jack J. Woehr # Science is more than a body of knowledge. It's a way of www.well.com/~jax # thinking, a way of skeptically

Re: Here we go again;

I worked at Pru in the early 70's. From the last I heard in the mid-80's, I believe Pru-Cobol is long since defunct. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Billy Ashton Sent: Wednesday, April 22, 2020 11:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Here

Re: IBM z ISA assembler & emulator.

Assist? https://twitter.com/ddiamond/status/1252643918375727105?s=20 Its included in Turnkey 3 and 4-, I believe. On Wed, Apr 22, 2020 at 10:54 AM John McKown wrote: > > Does anyone know if there is anything like this (below) for the z ISA? It > is a basic assembler, no macros, where you code

Re: JES2 SPOOLDEF TGSIZE recommendation sought

Am I understanding this correctly? BUFSIZE is 3992 at your sites, so a TGSIZE of 30 says that JES2 will build each track group big enough to hold 30 buffers of 3992 bytes or 119760 bytes. How many 3390 tracks are required to hold this? I just checked ours, and we're set at a TGSIZE of 33

Re: Here we go again;

As others have suggested, many companies do still have SSNs stored as packed decimal. So sure, a namespace expansion is possible, but it's a bigger change than one might think, however it's done. I've even seen at least one company who stored them as binary! I sure hope someone got a big bonus

zOSMF

Well I ended up with 2 problems I had to copy over the Liberty zFS to my LPAR And I had to pull a zOSMF zFS down from IBM I mounted them both and low and behold ANG1 and AVR1 came up Still fighting a HTTPS problem but I am miles further. Thank you all for your kind assistance

Re: Here we go again

We had well over 20 years of warning on Y2K; management preferred to ignore it. Apres moi le deluge (the balloon won't go up before I retire.) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List

Re: Here we go again;

Guys, Hadn’t heard of that, Microfocus Cobol yes for sure, some of the other through the ages. Scott On Wed, Apr 22, 2020 at 12:27 PM Allan Staller wrote: > I worked at Pru in the early 70's. > From the last I heard in the mid-80's, I believe Pru-Cobol is long since > defunct. > >

Re: Here we go again;

The notion of “savings” was marketing nonsense.  The DASD was paid for regardless of whether it held a production database or someone’s golf handicap. It cost the same whether it was empty or full.  The notion of “saving” was nonsense and even under the best of

Re: ESTBYTES Quandary

TIL. Thanks. 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 Wednesday, April 22, 2020 11:13 AM, Joe Monk wrote: > JES2 limits do not apply to STCs. > >

TSO Pipes (and BatchPipes)

I don't have access to TSO Pipes other than what is included with BatchPipes but it seems that it is a tad dated - it is actually old enough to drink: BPW00086I BatchPipes/MVS BatchPipeWorks, 5655-065/SCPSP 1.0109 (Version.Release/Mod) - Generated 12 Oct 1996 at 13:59:00 If someone has the

Re: TSO Pipes (and BatchPipes)

If there are any z/VMers subscribed, it would be interesting to also compare the PIPE Q output under CMS. Thanks. OREXXMan JCL is the buggy whip of 21st century computing. Stabilize it. Put Pipelines in the z/OS base. Would you rather process data in move mode or locate mode? IBM has been

Re: Three years ago, IBM ordered staff to work in central hubs. Now its new CEO ponders mid-pandemic: Is there a better way of doing things? • The Register

And yet...the POK build floor is empty. Somebody is cookin' the books. On Tue, Apr 21, 2020 at 8:03 AM Mark Regan wrote: > From the article: > > "Systems revenue saw $1.4bn in revenue, up 3 per cent thanks to the IBM Z > mainframe line." > >

Re: Here we go again;

Phil, My father was a FE for Unisys and said new boss is like a broom , “new broom makes a clean sweep”, new boss re-arranges “their” way... Scott On Wed, Apr 22, 2020 at 12:12 PM Phil Smith III wrote: > As others have suggested, many companies do still have SSNs stored as > packed decimal.

Re: Here we go again;

I also remember some years ago that Prudential had their own version of COBOL that allowed them to pack character (maybe just alpha?) fields, so they could probably add an alpha to the SSN numbering scheme without issue. I don't know if they still use it, and really hurt my brain trying to

Re: TSO Pipes (and BatchPipes)

Ray - thank you - so the CMS Pipes is 20 years newer than the TSO Pipes (at least the BatchPipes version). Lionel B. Dyck < Website: https://www.lbdsoftware.com "Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are." -

Re: Here we go again;

In the 80's a byte of DASD savings could be thousands of dollars. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Phil Smith III > Sent: Wednesday, April 22, 2020 9:12 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Here we go again; > > As others have

Re: Here we go again;

It was also the physical size of the dataset. On 2020-04-22 12:55, Gibney, Dave wrote: In the 80's a byte of DASD savings could be thousands of dollars. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Phil Smith III Sent: Wednesday, April 22, 2020 9:12 AM To:

Re: Here we go again

On Wed, 22 Apr 2020 13:43:03 +0800, Timothy Sipples wrote: >The Social Security Administration could easily give 20 years of advance >warning before expanding their number space if they wish. They've got >several options before that far distant future, such as: > >1. Allowing capital letters

z/OS 2.3 systems show OPI=YES

I'm working an audit issue which has been identified as a system exposure. I have in a shared parmlib IEASYS00 member OPI=NO, my IPLPARMS are set as 220100M1, but the D IPLINFO shows SYSTEM IPLED AT 23.20.28 ON 04/01/2020 RELEASE z/OS 02.03.00LICENSE = z/OS

Re: Here we go again

On Wed, 22 Apr 2020 10:34:34 -0500, Tom Marchant wrote: >On Wed, 22 Apr 2020 13:43:03 +0800, Timothy Sipples wrote: > >>The Social Security Administration could easily give 20 years of advance > Something similar should have been done for Y2K to avoid the last-minute scramble. >>warning before

Re: z/OS 2.3 systems show OPI=YES

My Zelden IPLINFO shows OPI=YES and set by IEASYSD0. Do a D PARMLIB and ensure you are pulling the correct IEASYS00 member and have coded OPI=NO. My D IPLINFO shows the same as yours with respect to (OP) being shown and we don’t prompt either (M1 coded in Load parm). On Wed, Apr 22, 2020 at

Re: TSO Pipes (and BatchPipes)

On CMS I get FPLINX086I CMS Pipelines, 5741-A07 1.0112 (Version.Release/Mod) - Generated 8 Sep 2016 at 15:22:22 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Hobart Spitz Sent: 22 April 2020 17:04 To: IBM-MAIN@LISTSERV.UA.EDU

Re: Here we go again

It's nowhere near as bad as Y2K. Y2K potentially affected just about everything. Everything with a date calculation. Everything that accepted or printed a date. Far fewer programs process SSN's. Anecdotally, from personal experience, I cannot tell you how many programs I have written that

Re: Here we go again

On Wed, 22 Apr 2020 16:29:32 +, Seymour J Metz wrote: >We had well over 20 years of warning on Y2K; management preferred to ignore >it. Apres moi le deluge (the balloon won't go up before I retire.) > Sicut erat in principio, et nunc, et semper, et in saecula saeculorum. As I recall a

Re: Here we go again;

We were small, even then. Bu, it was in the programmers interest to avoid x#7 abends. And, for a time, I had authority o make the required JCL changes for SPACE and BLKSIZE myself. Mos programmers would approve the change if they didn't need to do it themselves. On of the Adabas files I

Re: Here we go again;

I think Mr Morris is right. I'm reminded of an update I had to handle during the '80s. Volvo had bought White Motors, and I went to work for Volvo-White Truck (now Volvo Truck North America) in 1982. As some of you know, those tractor rigs cost about as much as a house, and some time in the

Re: Here we go again;

*Lennie Dymoke-Bradshaw lenni...@rsmpartners.com via ua.edu * *9:19 AM (2 hours ago)* *to IBM-MAIN* *How did you delete the files if you were not allowed to logon? *Asked.. You were in the LOGON PROCEDURE. It ran a CLIST that

Re: RCF: z/OS Version 2 Release 4 MVS JCL Reference, SA23-1385-40

For z/OS doc updates, please send to mhvr...@us.ibm.com. 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

Re: Here we go again;

Maybe at your shop people were more on the ball, or you had the authority to force them to listen, but in the shops I know of every man had his own fiefdom and did things his way. It's not the techies who call the shots, with few exceptions. -- Shmuel (Seymour J.) Metz

Re: Here we go again;

Presumably he used his trusty 129 terminal. Did you say 024? La, la, la, I can't hear you! If you know what it is, that's one thing, but if you've used one, ... -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion

Re: Here we go again

When I joined Mitre Corporation in 1971, my first TIAA-CREF end-of-year retirement statement predicted benefits I'd receive starting February 1, 2012. I suspect they'd been calculating/storing/displaying 21st century dates long before they needed one for me. Banks, insurance companies,

Re: Here we go again

The truly "fun" part about Y2K was that IBM solved the problem in the early 60s with just 6 digits. CFO-64 was a life insurance application they wrote in Autocoder that was my first encounter with what EDS-ers called "mo-year" code. Dates were stored as a 4 digit number of months since some

Re: Here we go again;

Never attribute to a lapse of memory what can be explained by never having known. No, it doesn't matter how many times you tried to tell them. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List

Re: Here we go again;

Something like this: DO I = 1 TO 5000 WRITER ENTER DATASET NAME ==> READ IF = ' ' THEN EXIT ELSE DELETE END ( breaks the CLIST with a IKJ56545I message produced. On Thu, Apr 23, 2020 at 11:55 AM Wayne Bickerdike wrote: > > *Lennie Dymoke-Bradshaw lenni...@rsmpartners.com > via >

Re: [External] Re: Here we go again;

X37 abends have nothing to do with block sizes Furthermore the role of secondary space allocations was so bad among programmers that many installations installed a vendor product called STOPX37 because it was easier then actual planning and calculating space.

Re: Here we go again;

[Default] On 22 Apr 2020 14:55:28 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >There is no on saving on forms, printer lines, punched cards, data entry >screens or data entry key strokes. You input two digits, store four digits and >print two digits. While on output

Re: Here we go again;

How did you delete the files if you were not allowed to logon? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd   Web:  www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of

Re: [External] Re: Here we go again;

I agree that it lead to problems. They were not insurmountable, just required some routine care. This started with an argument that the extra bytes required for dates were insignificant compared to BLKSIZE waste, In my experience, both would have been significant, had we not routinely paid

Re: Question on dynamic concatenation

I would guess the DSAB, but I'd have to chase through the data areas to be sure. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tony Harminc [t...@harminc.net] Sent:

Re: Here we go again;

On Thu, 23 Apr 2020 12:07:13 +1000, Wayne Bickerdike wrote: >Something like this: > >DO I = 1 TO 5000 >WRITER ENTER DATASET NAME ==> >READ >IF = ' ' THEN EXIT >ELSE DELETE >END > >( breaks the CLIST with a IKJ56545I message produced. > Ah! The invention of code injection. I prefer Rexx's

Re: [External] Re: Here we go again;

Yes, in the OS/360 era and the early MVS days the Link Editor imposed a restriction on *SYSLIN*, but that doesn't explain the hard wired block sizes for things other than object decks. Nor does it justify leaving the procedures that way after the restriction was lifted. If nobody cares about

Re: [External] Re: Here we go again;

Kilobytes? Not unless you started on a 305 or 650. Even on the 650 it was 6,000,000 digits. The disks on the 1401 and 7000 series were somewhat larger, even before the 1301, and the 2311 larger still. Only the 1130 was close to the 650's mere megabyte. -- Shmuel (Seymour J.) Metz

Re: [External] Re: Here we go again;

So you agree that poor Blocksizes give rise to poor disk usage? As to space allocations, I’m sorry but for as many problems as you’re describing the staff couldn’t have been that serious.   If management was as serious as being claimed there would have been no problem.  Yet

Re: Here we go again;

A slowly varying window. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Clark Morris [cfmt...@uniserve.com] Sent: Wednesday, April 22, 2020 11:08 PM To:

Re: [External] Re: Here we go again;

Full volumes due to excessive space wasted due to crap blksizes had everything to do with x37 abends. I am sorry that your experience included so many incompetent programmers. Mine did care, and my management cared more. Before SDB, it was a periodic take for me to review and clean DASD, fix

Re: IARST64 problem

The example as posted would not even assemble with default assembly options, so this is a bit confusing. I refer to the lower case operands such as "yes" for sysstate amode64=yes. Maybe there's use of some assembly COMPAT option? There are also possibilities that the switch from amode 31 to

Re: RCF: z/OS Version 2 Release 4 MVS JCL Reference, SA23-1385-40

I did; the copy to the list was an FYI, since the question was raised here. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Peter Relson [rel...@us.ibm.com] Sent:

RFE Vote for IBM Fault Analyzer.

Hi everybody, we opened a RFE to address a lack in IBM FA. Cobol Special register are not addressable in the DUMP. I understand that only people using IBM FA would be interested, anyway I invite you to vote. http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=141860 Thanks a lot

Re: Here we go again;

EXIT leaves the CLIST. IF () THEN EXIT DO WHILE 1 = 1 -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]

Re: IARST64 problem

Hello Pierre, I think that on line 170100 la r03,dsa_word You meant to use a L not a LA. Ciao, -- Raphael Dal Pos / z/OS Support Generali Shared Services S.c.a.r.l. GSS\CIN-MF

Re: IPCS - RUNARRAY EXEC problem

It's hard to diagnose something like that without seeing the actual output. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Binyamin Dissen [bdis...@dissensoftware.com]

JES2 SPOOLDEF TGSIZE recommendation sought

For years, we have run with 3390-3 spool volumes and a TGSIZE=24. I am not sure when or why the default became 30 and why it was not changed in my shop. Probably the wisdom of it is not broke, do not fix it. Okay, so much for history. Shortly, there will be a push to go to all higher capacity

Re: Here we go again

Expanding the SSN or changing it to alpha-numeric would be another Y2K. While the private sector might get it done, there is no way that the government sector could get it done in 20 years with all the red-tape they have to go though. Tony Thigpen Timothy Sipples wrote on 4/22/20 1:43 AM:

Re: JES2 SPOOLDEF TGSIZE recommendation sought

It would be helpful if you could post the output of a $DSPOOLDEF command. We run with mod-54's with no issues. Just make sure you code LARGEDS=ALLOWED $SPOOLDEF SPOOLDEF BUFSIZE=3992,DSNAME=SYS1.HASPACE,DSNMASK=,

Re: IPCS - RUNARRAY EXEC problem

The automatic LIST X is working, thus the command is valid. The EXEC is not working properly. On Tue, 21 Apr 2020 20:39:03 + Seymour J Metz wrote: :>Did you run it without the ADDRESS keyword? :> :> :>-- :>Shmuel (Seymour J.) Metz :>http://mason.gmu.edu/~smetz3 :>

Re: IBM z ISA assembler & emulator.

Hi John, z390 Portable Mainframe Assembler and Emulator http://z390.org/ VisibleZ can help you visualize exactly what the mainframe is doing as an assembler program executes http://csc.columbusstate.edu/woolbright/vzHomepage.htm Both are similar and provide excellent learning environments and

Re: JES2 SPOOLDEF TGSIZE recommendation sought

I was actually working on a local site problem that required reading up on this very topic a week or so ago. On a 3390 formatted track JES2 there are 12 buffers(with BUFSIZE=3992). So your TGSIZE of 24 meant that JES2 would allocate 2 tracks at a time. Changing TGSIZE to 30 will actually result

IBM z ISA assembler & emulator.

Does anyone know if there is anything like this (below) for the z ISA? It is a basic assembler, no macros, where you code MIPS assembler into a text file, then load it into the emulator. The code is compiled. You are then in a "debugger" in which you can run the code, or single step. It's quite

Re: JES2 SPOOLDEF TGSIZE recommendation sought [EXTERNAL]

In two of our JES2 environments we use MOD-27s and in one other we use MOD-54s. All three environments use TGSIZE=36. I don't recall when it changed to TGSIZE=36, but it has been that way for years. We have not seen any issues with either size volumes. As Dave mentioned don't forget to set

Re: JES2 SPOOLDEF TGSIZE recommendation sought

Yea, just getting my coffee too... Looks like TGSIZE is easy enough to make larger, no so much to make smallerI guess if you are going to change, then make the change before you add the new volumes. Once formatted, it doesn't change? TGSIZE=nnn|30 Specifies the number (1-255) of JES2

Re: S0C4 in IARV64 GETSTOR storage (was ...IAVR64...)

>The address was valid Wanna bet? "Valid" includes "obtained successfully and not released yet" and "OK to reference in your PSW key". One or the other is not the case. AGAIN, where is your evidence? Peter Relson z/OS Core Technology Design

Re: JES2 SPOOLDEF TGSIZE recommendation sought

Dave, At your request! I should have provided it before...now where is that 2nd cup of coffee? Bob SPOOLDEF BUFSIZE=3992,DSNAME=SYS1.HASPACE,DSNMASK=, FENCE=(ACTIVE=NO,VOLUMES=1),GCRATE=NORMAL,

Re: S0C4 in IARV64 GETSTOR storage (was ...IAVR64...)

Apologies late last nite the high order bit Was on did a Load address on the base register to turn it off Thanks On Apr 22, 2020, at 7:38 AM, Peter Relson wrote: > >  >> >> The address was valid > > Wanna bet? > > "Valid" includes "obtained successfully and not released yet" and "OK to

ESTBYTES Quandary

We've been trying to enforce limits on how much spool space a single job can use before it's canceled. We don't have any automation products, nor JES2 exits. The method that we're trying to use is ESYBYTES with OPT=1. On one system we've set it to this value, $HASP845 ESTBYTE

Re: UPDTE - CBT tape 496

Caveat - I don't do windoze. If you send me the Rexx and HLASM code I'll take a look at it. Are you using OOREXX or Regina? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on

Re: JES2 SPOOLDEF TGSIZE recommendation sought [EXTERNAL]

W dniu 22.04.2020 o 13:04, Feller, Paul pisze: In two of our JES2 environments we use MOD-27s and in one other we use MOD-54s. All three environments use TGSIZE=36. I don't recall when it changed to TGSIZE=36, but it has been that way for years. We have not seen any issues with either size

UPDTE - CBT tape 496

I've been using this for quite a while to upload data from Windows to z/OS, merging in one case nearly 2,000 files into the required IEBUPDTE format, making the transfer rather a lot easier. It always worked, uploading the data to a VB/259/27998 dataset, but until now, Windows filenames have

Re: UPDTE - CBT tape 496

On 2020-04-22 14:06, Robert Prins wrote: I've been using this for quite a while to upload data from Windows to z/OS, merging in one case nearly 2,000 files into the required IEBUPDTE format, making the transfer rather a lot easier. It always worked, uploading the data to a VB/259/27998

Re: ESTBYTES Quandary

JES2 limits do not apply to STCs. https://groups.google.com/forum/#!msg/bit.listserv.ibm-main/1YPjynrHqBo/EN7BpmG6AQAJ Joe On Wed, Apr 22, 2020 at 7:58 AM Mark Jacobs < 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > We've been trying to enforce limits on how much spool space a single

Re: UPDTE - CBT tape 496

On 2020-04-22 11:06 PM, Robert Prins wrote: UPDTE still works, but for whatever reason, membernames in the resulting PDS are screwed up with what seem to be (part of) the initial RDW and in case the filename on windows was only 2 characters, the first two characters of the next record. The

Re: Here we go again

On Apr 22, 2020, at 11:40 AM, Charles Mills wrote: > > It's nowhere near as bad as Y2K. Y2K potentially affected just about > everything. Everything with a date calculation. Everything that accepted or > printed a date. > That’s an important point. Dates are often used in calculations. SSNs

Re: Question on dynamic concatenation

Dynamic deconcatenation logically disconnects the members of a dynamically concatenated group. You identify the concatenated group to be deconcatenated by specifying the ddname of the group. When a concatenated group is dynamically deconcatenated, the ddnames that were associated with the data

Re: Question on dynamic concatenation

It's the answer to your question: the manual is correct but fails to connect the dots. The dynamic concatenation *does* remove the association of the other ddnames, but it does not delete the record that there had previously been such an association, so when you deconcatenate it is able to

Re: Here we go again;

We purchased less DASD > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gerhard adam > Sent: Wednesday, April 22, 2020 10:06 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Here we go again; > > > > > > The notion of “savings” was marketing nonsense.  

Re: ESTBYTES Quandary

I would open a DEFECT case with IBM L2 JES2. It should terminate any job (not STC) that exceeds your requirements. I had an issue with an STC was getting a S722 abend but it was not exceeding the limits hard coded in JES2. IBM has published a fix for STCs getting S722 abends. This might be

Re: Here we go again;

Faulty logic there. A byte here and byte there and pretty soon you have to buy ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly full you have to pay for another. Charles -Original Message- From: IBM Mainframe Discussion List

Re: Here we go again

Yeah, I have to side with Mr Metz on this one. I remember thinking, back in the '80s and early '90s, "I'm a terrible procrastinator. But you don't get to be the CEO of a big corporation like , or the head of IT, by not allocating your time wisely. I'm sure they have this under control and will

Re: Here we go again

True, but as an amusing side note there were Y2K bugs that were not worth fixing, like displaying the year as 100 instead of 00. Unfortunately, most were not like that. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe

Re: IBM z ISA assembler & emulator.

Sorry, you replied to Mike Schwab, not John. On Wed, Apr 22, 2020 at 11:16 AM Knutson, Samuel wrote: > > Hi John, > > z390 Portable Mainframe Assembler and Emulator > http://z390.org/ > > VisibleZ can help you visualize exactly what the mainframe is doing as an > assembler program executes >

Question on dynamic concatenation

I could solve this by experimentation but it would take a bunch of work. I am hoping someone here knows the answer. Under dynamic concatenation (https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r 4.ieaa800/concat.htm) it says "The name associated with the concatenated

Re: Question on dynamic concatenation

Is that supposed to be an answer to my questions or is it intended to be a related FYI? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Wednesday, April 22, 2020 11:22 AM To: IBM-MAIN@LISTSERV.UA.EDU

Re: Here we go again;

>I sure hope someone got a big bonus for saving that byte... Oy. Did not mean to cause a firestorm over this. Sure, it can add up; but a big database back then was what, 10M rows? So saving one byte was 10MB, not nothing, but still only 5% of a 3330. At some point, the cost of folks' time

Re: Here we go again;

There also seems to be a lapse in memory regarding the reference cards provided by IBM for the various model DASD is where one could look up the record size and view the table for the recommended Blocksize. In addition these cards also provided the detailed

Re: Memory-Lane Monday: System Zzzzz | Computerworld Shark Tank

This happened to me many years ago. I got a call early (8am? Early for me at the time, I was like 22!) about a technical problem with something I'd written. We discussed it, I proposed a workaround, they tried it, it worked. Then my colleague asked, "When will you be in to fix it right?"

Re: Here we go again;

We had constraints at IBM when I worked there in 1978. The TSO logon procedure checked your personal space allocation. If you had more then 150 tracks allocated you had to delete some files to log on. At the time we were limited to 30 minutes a session to allow other programmers to get some "time

Re: Linkage editor question: renaming duplicate entry points

Thanks to all who replied; CHANGE was indeed what I needed! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [External] Re: Here we go again;

Because just like anything else, they occasionally forgot. We had a product (from CA maybe) that would check for bad block sizes that got run on a scheduled basis to find the problems and when it did, I got to get them corrected. -Original Message- From: IBM Mainframe Discussion List

Re: [External] Re: Here we go again;

Not sure what "several models of 3380" has to do with me. We had 3380-D drives and the room was full of them so we didn't have room to add more. Once we did start replacing them, we went to the 9343 subsystem and bought lots of floor space back. Also, my comment was for my pre-3380 days when

Re: Here we go again;

[Default] On 22 Apr 2020 12:44:41 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >My first computer had a 2,000 word drum, a 60 word core memory, a 600,000 word >disk drive and two tape drives. I may have been a tad more constrained than >you were when you started. I

Re: Question on dynamic concatenation

On Wed, 22 Apr 2020 at 14:33, Seymour J Metz wrote: > > It's the answer to your question: the manual is correct but fails to connect > the dots. The dynamic concatenation *does* remove the > association of the other ddnames, but it does not delete the record that > there had previously been

Re: Here we go again

> Sicut erat in principio, et nunc, et semper, et in saecula saeculorum. Plus ça change, plus c'esl la même chose is shorter. But, yes, I can't quarrel with your cynicism. > [It did. But Boss prevailed.] Why am I not surprised? But that's the sort of thing for which it's wise to maintain

Re: [External] Re: Here we go again;

This stuff has circled back, from where we tried to save on dads bytes, program bytes ( remember Assembler half words ) and other techniques to save storage. Now the same situation is occurring on AWS.. Scott On Wed, Apr 22, 2020 at 3:20 PM Gerhard adam wrote: > > > > > ... and so goes

Re: [External] Re: Here we go again;

Conceding that to be your experience, in the 80's and early 90's, I routinely did these tasks. I was also writing Y2K compliant COBOL code. I wanted to use packed decimal in the Adabas file. Our DBA did the calculation. The byte saved by using binary fullwords (a 1 byte savings) translated

Re: [External] Re: Here we go again;

Sorry, we'll have to agree to disagree. It wasn't mythology at my places of business. When I was in application development, disk and other resource efficiency was of paramount concern and when I moved into systems programming I got to be the one going to the developers and making sure they

Re: [External] Re: Here we go again;

Well, I used a DCB exit to select a block size if none was provided. OTOH, I kept seeing IBM procedures with 3200 long after that was too small. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List

Re: [External] Re: Here we go again;

Sorry, but “several models of 3380”? If  3380k held almost 2GB per module and you saved one byte per record, then you saved the one byte over 2 billion records to save just one 3380K’s worth of data.  Forgive me for being skeptical Get Outlook

Re: [External] Re: Here we go again;

Because, one programmer produces JCL and shares it with his/her colleagues for the next 50 years. Have you ever worked in a real company? On 2020-04-22 15:41, Gerhard adam wrote: Why did you have to go to the programmers to make sure they were using proper block sizes if

Re: Three years ago, IBM ordered staff to work in central hubs. Now its new CEO ponders mid-pandemic: Is there a better way of doing things? • The Register

On Wed, 22 Apr 2020 12:07:58 -0400, zMan wrote: >And yet...the POK build floor is empty. Somebody is cookin' the books. > If the build floor is truly empty will they be able to get new hardware shipped in time for customers hoping for replacements to allow migrating off z/OS 2.2 before EOS

  1   2   >