Re: IEH/IEB/... names?
Well, I don't have an OS/360 Utilities manual, but there is a Utilities PLM on bitsavers.org, and it says in the IEBCOPY section: Input to the IEBCOPY program must be a partitioned data set. The data set must reside on a direct access device and be contained within one physical volume. The input records can be U, F, or V format. If F or V format, they can be blocked or unblocked. Keys, relative track address pointers (TTRNs) within the directory, and note lists are permitted. The output of the IEBCOPY program is also a partitioned data set. It must reside on a direct access device and be contained within one physical volume. That certainly reinforces my memory of pre-SVS IEBCOPY. Tony H. -Original Message- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Mon 24 October, 2005 12:27 To: VMESA-L@LISTSERV.UARK.EDU Subject: Re: IEH/IEB/... names? Are you sure about that? IIRC, we used IEBCOPY to both compress and unload PDSes in the pre-SVS (O/S 360 Releases 15-21) days. It did require DD statements to actually specify the dataset, not the generic DDs used by IEHMOVE. Regards, Richard Schuh -Original Message- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] Behalf Of Tony Harminc Sent: Monday, October 24, 2005 9:10 AM To: VMESA-L@LISTSERV.UARK.EDU Subject: Re: IEH/IEB/... names? Pre-SVS IEBCOPY didn't have the PDS unload feature that is probably what most of us think of as the raison d'etre of IEBCOPY these days.
Re: IEH/IEB/... names?
Jay Maynard [EMAIL PROTECTED] writes: On 2005-10-21, Joe Morris [EMAIL PROTECTED] wrote: IEBCOPY - is a data-set utility used to copy one or more (PDSes) or merge (PDSes) As distributed it wouldn't work under OS/360. I made a small tweak to it (details of which I don't recall but IIRC it involved an appendage) and it ran quite happily for several years on OS/360. I'll have to look at the Hercules OS/360 package, which includes a copy of IEBCOPY for OS/360...wonder if it's your work. My tweak was to retrofit the SVS version of IEBCOPY back to OS/360. There always was an IEBCOPY in OS/360, but it required a DD card for every data set involved. The SVS version of the utility gave you most of the file-copy features of IEHMOVE without the infestation of bugs. My notes from the tweak stayed with my PPOE. I don't recall if I ever put it on the Michmods (SHARE) tape, but I'm getting a vague recollection that the SVS version had an SIO appendage...and the tweak was disabling it (the appendage probably was required to control page presence in SVS, an issue that OS/360 didn't have to worry about). Or maybe it was something else; it *has* been a few years. IEHIOSUP - is a system utility used to update TTR entries in the transfer control tables of the supervisor call library (SVC lib). IEHSISUP must be used after: the SVC lib is moved. The OPEN, CLOSE, TCLOSE, EOV,... other modules are changed or replaced in the SVC lib. Worse than that: you had to remember to rerun it whenever you replaced *any* SVC load. The initial starter MFT system build for Hercules ran into a chicken-and-egg problem: How do you run IEHIOSUP to set up the TTRs if you don't have a system to run it on? Roger Bowler wound up writing a utility that does the update, by finding SYS1.SVCLIB and processing the PDS directory - and parsing the AWSCKD image to get there. Back in ye olde days a new installation was bootstrapped using the dump/restore starter system you ordered from PID. Once the installation got a locally-configured build it in turn could be used to initialize the next system build's SVCLIB. Joe Morris
Re: IEH/IEB/... names?
On 2005-10-21, Joe Morris [EMAIL PROTECTED] wrote: IEBCOPY - is a data-set utility used to copy one or more (PDSes) or merge (PDSes) As distributed it wouldn't work under OS/360. I made a small tweak to it (details of which I don't recall but IIRC it involved an appendage) and it ran quite happily for several years on OS/360. I'll have to look at the Hercules OS/360 package, which includes a copy of IEBCOPY for OS/360...wonder if it's your work. IEBDG- is a data-set utility to generate test data. Note. Mostly various ripple paterns. DG := Data Generator. Rather convoluted control cards; I don't recall hearing of common use of any but the most basic functions. I think I've seen it used once. It was unusual enough that I was surprised to see it. Fuzzy memory tells me it was in HASP setup, but that's likely to be wrong. IEBUPDAT - is a dsu to incorporate IBM and user-generated source language modifications into a symbolic library -- a PDS of 80-byte records, such as SYS1.PROCLIB ... IBUPDTE - is a dsu to incorporate IBM and user-generated source language modifications into a sequential or PDS. These two served much the same purpose. UPDAT was more primative, but seemed to be more popular. I never used IEBUPDAT, and didn't even know it existed until this post. I'd always wondered ablut the slightly strange naming of IEBUPDTE. IEHIOSUP - is a system utility used to update TTR entries in the transfer control tables of the supervisor call library (SVC lib). IEHSISUP must be used after: the SVC lib is moved. The OPEN, CLOSE, TCLOSE, EOV,... other modules are changed or replaced in the SVC lib. Worse than that: you had to remember to rerun it whenever you replaced *any* SVC load. The initial starter MFT system build for Hercules ran into a chicken-and-egg problem: How do you run IEHIOSUP to set up the TTRs if you don't have a system to run it on? Roger Bowler wound up writing a utility that does the update, by finding SYS1.SVCLIB and processing the PDS directory - and parsing the AWSCKD image to get there. -- Jay Maynard, K5ZC http://www.conmicro.cx http://www.tronguy.net (Yes, that's me!) http://jmaynard.livejournal.com
Re: IEH/IEB/... names?
| Rostyslaw J. Lewyckyj wrote: | Joe Morris wrote: | Rostyslaw J. Lewyckyj wrote: | [EMAIL PROTECTED] wrote: | Perhaps you know the answer: | long ago I used IBM mainframes. | Utilities started with IEH, IEB, etc. | What were the rules for those prefixes? | | | I don't know the specific rules for classifying the utilities | onto IEH vs IEB groups. However I noticed that the IEH routines | were meant for system programmers, vs IEB which were renerally | data management routines meant for the general customer/user. | [remainder snipped] | Correct; IEHfoo would typically be a utility to maintain the | OS (IEHPROGM, IEHMOVE, etc), while IEBbar would do something | likely to be part of a production job. There were also some | system utilities classified as Service Aids, originally distributed | informally through CE channels but later incorporated into OS/360 | (at release 18?) with IMx prefixes. | [remainder snipped] | You mean like IMASPZAP . | IBM ref GC28-6586-13 Utilities manual is rather late in the game. | It's 1972 vintage for rel 21. and it documents the following | programs: IBCSASDI, IBCDMPRS, IBCRCVRP, ICAPRTBL, IEBCOMPR, | IEBCOPY, IEBDG, IEBEDIT, IEBGENER, IEBISAM, IEBPTPCH, IEBTCRIN, | IEBUPDAT, IEBUPDTE, IEHATLAS, IEHDASDR, IEHINIT, IEHIOSUP, | IEHLIST, IEHMOVE, IEHPROGM, IFHSTATR | Sorry I didn't keep an older version of the manual, nor | of the System programmers guide, and utilities manual(s) Boy, does that ever bring back the nostalgia. Could you give a one-line description of each of the above utilities? Some of them, I never heard of, and I thought I used them all. Gerard S.
Re: IEH/IEB/... names?
Z manuals were supposed to be IBM internal use only, but IBMers would often obtain copies for their customers. there was unclassified internal use only confidential confidential - restricted registered confidential all the Z I saw were confidential and customer might have to sign something to get a copy. i wrote a few science center reports http://www.garlic.com/~lynn/subtopic.html#545tech on things like page mapped filesystem support http://www.garlic.com/~lynn/subtopic.html#mmap that got Z'ed. there were also Y document prefix ... that were frequently program logic manuals. ... registered confidential had all copies numbered and had to be kept in double locked cabinets. site security had list of all registered confidential documents and would peridically perform audits as to them still being in your possession. at one point, i had collected a file cabinet drawer full of the 811 documents (for 11/78) that were registered condidential (various 370-xa hardware, software and architecture documents). when we started doing the online phone book ... the paper copies were typically stamped internal use only. early on, various plant site people from around the world would refer us to their site security people before giving up machine readable copy. the site security people would insist that machine readable versions of the phone book had to be classified at confidential (at a minimum) ... and the idea that we would be collecting machine readable copies from all the sites ... appeared to boggle their mind. after some amount of effort, we got a couple major sites to relent (san jose, pok, etc) and let us have the machine readable as purely internal use only. after that, we would deal with local site security people by referring them to other sites that had already relented. then there was the case of the cern tso/cms bakeoff share report (circa 1974?), the internal corporate copies got stamped confidential - restricted, available on a need-to-know basis only (only appropriately authorized employees were allowed to see the tso/cms comparison done by cern). misc. past posts mentioned online phonebook work: http://www.garlic.com/~lynn/2000b.html#92 Question regarding authentication implementation http://www.garlic.com/~lynn/2000g.html#14 IBM's mess (was: Re: What the hell is an MSX?) http://www.garlic.com/~lynn/2000g.html#35 does CA need the proof of acceptance of key binding ? http://www.garlic.com/~lynn/2001j.html#29 Title Inflation http://www.garlic.com/~lynn/2001j.html#30 Title Inflation http://www.garlic.com/~lynn/2002e.html#33 Mainframers: Take back the light (spotlight, that is) http://www.garlic.com/~lynn/2002m.html#19 A new e-commerce security proposal http://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning) http://www.garlic.com/~lynn/2003p.html#20 Dumb anti-MITM hacks / CAPTCHA application http://www.garlic.com/~lynn/2004c.html#0 A POX on you, Dennis Ritchie!!! http://www.garlic.com/~lynn/2004l.html#32 Shipwrecks http://www.garlic.com/~lynn/2004p.html#13 Mainframe Virus http://www.garlic.com/~lynn/2005c.html#38 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005c.html#43 History of performance counters http://www.garlic.com/~lynn/2005s.html#3 Flat Query misc. past references to corporate security classifications http://www.garlic.com/~lynn/98.html#28 Drive letters http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline? http://www.garlic.com/~lynn/2001l.html#20 mainframe question http://www.garlic.com/~lynn/2001n.html#37 Hercules etc. IBM not just missing a great opportunity... http://www.garlic.com/~lynn/2001n.html#79 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?) http://www.garlic.com/~lynn/2002d.html#8 Security Proportional to Risk (was: IBM Mainframe at home) http://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home) http://www.garlic.com/~lynn/2002g.html#67 Coulda, Woulda, Shoudda moments? http://www.garlic.com/~lynn/2002h.html#14 Why did OSI fail compared with TCP-IP? http://www.garlic.com/~lynn/2002h.html#51 Why did OSI fail compared with TCP-IP? http://www.garlic.com/~lynn/2002j.html#64 vm marketing (cross post) http://www.garlic.com/~lynn/2002n.html#37 VR vs. Portable Computing http://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary http://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422? http://www.garlic.com/~lynn/2003c.html#69 OT: One for the historians - 360/91 http://www.garlic.com/~lynn/2003k.html#13 What is timesharing, anyway? http://www.garlic.com/~lynn/2003m.html#56 model 91/CRJE and IKJLEW http://www.garlic.com/~lynn/2003o.html#16 When nerds were nerds http://www.garlic.com/~lynn/2003o.html#21 TSO alternative http://www.garlic.com/~lynn/2004c.html#10 XDS Sigma vs IBM 370 was Re: I/O Selectric on eBay: How to use? http://www.garlic.com/~lynn/2004n.html#17 RISCs too close to hardware?
Re: IEH/IEB/... names?
Rostyslaw J. Lewyckyj [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: Perhaps you know the answer: long ago I used IBM mainframes. Utilities started with IEH, IEB, etc. What were the rules for those prefixes? I don't know the specific rules for classifying the utilities onto IEH vs IEB groups. However I noticed that the IEH routines were meant for system programmers, vs IEB which were renerally data management routines meant for the general customer/user. [remainder snipped] Correct; IEHfoo would typically be a utility to maintain the OS (IEHPROGM, IEHMOVE, etc), while IEBbar would do something likely to be part of a production job. There were also some system utilities classified as Service Aids, originally distributed informally through CE channels but later incorporated into OS/360 (at release 18?) with IMx prefixes. (There was also the late, and quite unlamented, IHGUAP -- was there *anyone* who ever used it?) Another distinction (not true in all cases) was that the IEH utilities played games with the JFCB (Job File Control Block, which contained information from a DD card). Where one normally had to have a DD card in a job step's JCL for every data set manipulated in the step, the IEH utilities usually required only a DD card pointing to each volume (normally, disk drive) that would be involved in the job step: when the utility needed to access a data set it would locate an appropriate JFCB, read it into memory, modify the data to make it refer to the desired data set, and then use OPENJ to open the data set as if the DD card had pointed to the data set. Joe Morris
Re: IEH/IEB/... names?
On 2005-10-18, Joe Morris [EMAIL PROTECTED] wrote: (There was also the late, and quite unlamented, IHGUAP -- was there *anyone* who ever used it?) I'd never even heard of it, but there it is in the SYS1.UT506 distribution library...what was it, a precursor to SMP? -- Jay Maynard, K5ZC http://www.conmicro.cx http://www.tronguy.net (Yes, that's me!) http://jmaynard.livejournal.com
