Sorry, missed this. I recently sat on a bacon-slicer, so I'm getting a little behind with everything...
I suspect, but don't know, that the only recent updates to the "manual" have been to add the word PDSE. SYSUT1 members containing data which looks like the data "label" that is generated are unproblematic for IEBPTPCH. It's just data. Then processing the output is a different potential issue. You may have noted that 73-80 are blank, which can aid in identification of those generated against those members which have "line numbers", but not those which are already blank. However, since I use it for COBOL programs and for JCL (the first being no possible problem, the second only a problem if someone has "data" which happens to match the format, possible, but not happened yet) I've not encountered a problem. To get stuff then into a PDS, you basically changed the MEMBER card to an IEBUPDTE command. I've only ever done it with "add" and only ever to a separate PDS, either an "empty" PDS or one guaranteed not to have conflict of members, but it would be possible to try to get more exciting with it and use some of the other IEBUPDTE options. Having seen "damaged" PDSs and members with unintended updates, I just like to be very careful and systematic. Call me the Tortoise of screwi... updating PDSs. Tortoises also do backups. And use IEBCOPY to return, updated, data from whence it came. I have found it extremely useful for program sources and JCL. There is something about * and ** being used as markers, but I've never seen them and never bothered/needed to check why not. Maybe it's on the print output (which I don't use)? I don't know if "library services" existed when I started using this, but if they did, I didn't know about them, and just jumped with the first thing I found that did what I needed. Perhaps I should "modernise" the approach, but I've just not found a need. Yet. On Wednesday, 15 June 2016 02:59:40 UTC+2, Paul Gilmartin wrote: > On Tue, 14 Jun 2016 18:03:02 -0500, wrote: > > >I'm not sure why you'd think it may have problems punching/printing PDS > >members that happen to contain JCL which happens to contain IEBPTPCH > >commands. It's all just data to IEBPTPCH. > > > OK. I tried it. Members appear to be separated by lines of the form "MEMBER > NAME %%%%%%%%". > (Is this documented?) What happens if such a line appears in SYSUT1? I got: > > MEMBER NAME AAAWTF control line > Line before data line > MEMBER NAME FOOBAR data line (but how does it know?) > Line after data line > > >It is documented, you could consider giving it a whirl with something else > >and lettings us know. > > > Wherein I find gems such as: > > Both the output data set and the message data set can be written to the > system output device if it is a printer. > > What does that mean? If it's not a printer, can only one of them be written > to it? > > If the member card entry is not used, the entire data cell will be > printed. > > How long has it been since IBM marketed a data cell? (I'll submit an RCF on > that.) > > How does one restore a PDS from IEBPTPCH output? It's probably somewhere. > I haven't found it. > > (Is this good old IBM documentation or sloppy new IBM documentation?) > > -- 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
