Re: Format PDS unloaded on an CD
On Mon, Apr 19, 2021 at 7:23 AM Joe Monk wrote: > > So, now you know what you have. An ISPF panel library, that was > unloaded via IEBCOPY, then IND$FILE to a PC without specifying CRLF then > back to the mainframe. > > Joe > Well, since this is going to be a text only, FB 80 PDS(e) file, open with a text editor such as NOTEPAD, NOTEPAD++, WORD, etc.. Save as to a new name as plain text with TXT suffix so you don't lose the original file. Copy this job to the top down to the ./ ADD command. https://www.ibm.com/docs/en/zos/2.4.0?topic=examples-example-1-place-two-procedures-in-sys1proclib#u1438 Select and delete a block of non- text data, hope you see a text name to put in a line with ./ ADD NAME=, use AA001 if you don't find the name. G through the text and insert line splits as needed. Some lines need leading blanks. When you get to the next block of non-text, you highlight and delete the non text, and put in the ./ ADD NAME= with the name or AA002 if not found. Repeat to the end of the file. Put in the ./ ENDUP card and save final results. Upload to to MVS / z/OS with ASCII CFLF. FB 80 3120. Create PDS with FB 80 and twice the space of the upload with directory space, put name in JCL. Copy in a site specific jobcard to the top and run to create a PDS with the names you saved or AA001-AA999. You will have to review to figure out the member names if you didn't find it in the PDS unload text. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a vertical split in ISPF?
Thanks for the mention, and while I think it's possible, my own opinion (sorry) is that partitions should be left as historical artifacts. Sooner or later though, I bet someone will add that support to an open-source emulator. Maybe someone here - someone who can work with C code and can understand the partition chapter in the 3270 data stream manual (I could not). Original Message Subject: Re: Is there a vertical split in ISPF? From: "PINION, RICHARD W." Date: Mon, April 19, 2021 11:21 am To: IBM-MAIN@LISTSERV.UA.EDU I wonder if it would be possible for Tom Brennen to add support for a 3290 device? I wonder if ISPF SPLITV, 3290, and TN3270E are even a possibility, as the 3290/3x74 combination was a SNA thing??? I have no idea, as I can't even spell VTAM, SNA, or TN3270E. -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Cole Sent: Monday, April 19, 2021 2:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there a vertical split in ISPF? [External Email. Exercise caution when clicking links or opening attachments.] PCOMM would have to support the "3290" terminal type. I don't use PCOMM, so I don't actually know if it does or not, but I would be amazed if it did. Anyway, as someone else noted, SPLITV is supported in ISPF only for "3290" types, so the answer to your question would be No. It can't be done. Dave Cole At 4/18/2021 12:10 AM, kekronbekron wrote: >Would you mind showing us an example of how to set this up with pcomm, >for example? > >- KB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- 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: Print a SYSMDUMP
FWIW
Pre-IPCS, there was a TSO batch program to format SYSMDUMPs. I can't
remember precisely, but perhaps it was called something like AMSPRDMP or
similar.
With IPCS, there are lots of pre-written IPCS REXX execs available
somewhere (if memory serves, they begin with BLS*) and they can be
invoked to do most of the standard SYSMDUMP analyses.
I preferred to write my own REXX execs to do that - and I would
recommend that IPCS users likewise write their own execs.
Here is an example of some IPCS REXX (in this case for a CICS dump). HTH.
/*-REXX--*/
/* IPCS CLIST TO EXTRACT THE ADDRESSES OF A CICS REGION'S SYSTEM */
/* TCA'S (STCA), FROM AN SVC DUMP, THEN REPEATEDLY FOR EACH STCA, */
/* INVOKE %ONLCZDWE PASSING THE STCA AS ARGUMENT. */
/* */
/* INVOKES %ONLCZDWE */
/* ¯ */
/* INPUT: NONE: IS INVOKED AS A COMMAND, FROM WITHIN IPCS, AND */
/* ¯¯ IT THEN ANALYSES THE DUMP CURRENTLY ALLOCATED */
/* */
/* OUTPUT: ADDRESS OF ACTIVE + SUSPENDED TASKS' SYSTEM TCA'S */
/* ¯¯¯ FOR EACH SYSTEM TCA, OUTPUTS: */
/* - TRANSID */
/* - ASSOCIATED PROGRAM ID */
/* - USERID */
/* - TERMID */
/* - DISPATCH CONTROL INDICATOR STATUS */
/* - TASK NUMBER */
/* - DEFERRED WORK ELEMENT LIST */
/* - QUEUE ELEMENT LIST */
/* */
/* */
/* 06/01/95 CORRECTION TO ACTIVE/SUSPENDED TASK CHAINING */
/* 26/08/94 CHRIS PONCELET */
/*---*/
ADDRESS IPCS
PSA_ADDRESS = ''
"EVALUATE" PSA_ADDRESS||. ,
"POSITION("X2D(224)") LENGTH(4) REXX(STORAGE(OLD_ASCB_ADDRESS))"
"EVALUATE" OLD_ASCB_ADDRESS||. ,
"POSITION("X2D(6C)") LENGTH(4) REXX(STORAGE(OLD_ASXB_ADDRESS))"
"EVALUATE" OLD_ASXB_ADDRESS||. ,
"POSITION("X2D(4)") LENGTH(4) REXX(STORAGE(TCB_CHAIN_START_ADDRESS))"
"EVALUATE" OLD_ASXB_ADDRESS||. ,
"POSITION("X2D(8)") LENGTH(4) REXX(STORAGE(TCB_CHAIN_STOP_ADDRESS))"
FIND_CICS_TCB:
FOUND = 'NO'
STOP = 'NO'
TCB_CHAIN_NEXT_ADDRESS = TCB_CHAIN_START_ADDRESS
X_E0 = C2X('E0'X)
X_00 = C2X('00'X)
X_40 = C2X('40'X)
X_60 = C2X('60'X)
X_80 = C2X('80'X)
X_C0 = C2X('C0'X)
DFHSIP = C2X('DFHSIP ')
/* FOR EACH TCB, SEARCH FOR ALL RB'S */
DO WHILE (FOUND = 'NO') & (STOP = 'NO')
IF TCB_CHAIN_NEXT_ADDRESS = TCB_CHAIN_STOP_ADDRESS THEN ,
STOP = 'YEAH'
"EVALUATE" TCB_CHAIN_NEXT_ADDRESS||. ,
"POSITION(0) LENGTH(4) REXX(STORAGE(RB_ADDRESS))"
/* FOR EACH RB: FIND PRB, IF ANY, AND CHECK WHETHER ASSOCIATED */
/* PROGRAM IS DFHSIP */
PRB_ADDRESS = 0
IRB_ADDRESS = 0
TIRB_ADDRESS = 0
SIRB_ADDRESS = 0
SVRB_ADDRESS = 0
DO K = 0 TO 999 WHILE (RB_ADDRESS ¬= TCB_CHAIN_NEXT_ADDRESS)
LINK_ADDRESS.K = RB_ADDRESS
"EVALUATE" RB_ADDRESS||. ,
"POSITION("X2D(0A)") LENGTH(1) REXX(STORAGE(RBSTAB1))"
RB_TYPE_VAL = C2X(BITAND(X2C(X_E0),X2C(RBSTAB1)))
SELECT;
WHEN RB_TYPE_VAL = X_00 THEN DO /* PRB */
LINK_RB.K = 'PRB'
"EVALUATE" RB_ADDRESS||. ,
"POSITION("X2D(0C)") LENGTH(4) REXX(STORAGE(CDE_ADDRESS))"
"EVALUATE" CDE_ADDRESS||. ,
"POSITION("X2D(08)") LENGTH(8) REXX(STORAGE(PROGRAM_NAME))"
IF PROGRAM_NAME = DFHSIP THEN FOUND = 'YEAH'
END
WHEN RB_TYPE_VAL = X_40 THEN , /* IRB */
LINK_RB.K = 'IRB'
WHEN RB_TYPE_VAL = X_60 THEN , /* TIRB */
LINK_RB.K = 'TIRB'
WHEN RB_TYPE_VAL = X_80 THEN , /* SIRB */
LINK_RB.K = 'SIRB'
WHEN RB_TYPE_VAL = X_C0 THEN , /* SVRB */
LINK_RB.K = 'SVRB'
OTHERWISE DO
LINK_RB.K = 'EH??'
SAY 'UNKNOWN RB AT ADDRESS =' RB_ADDRESS
SAY 'RBSTAB1 VALUE = 'RBSTAB1
SAY 'PLEASE CHECK THIS!'
SAY ' '
SAY 'EXECUTION OF IPCS CLIST %ONLCZTAS IS NOW BEING ABANDONED.'
CALL EXIT
END
END /* SELECT */
"EVALUATE" RB_ADDRESS||. ,
"POSITION("X2D(1D)") LENGTH(3) REXX(STORAGE(RB_ADDRESS))"
RB_ADDRESS = '00'||RB_ADDRESS
END /* DO K = 0 TO 999 WHILE RB_ADDRESS [= TCB_CHAIN_NEXT_ADDRESS */
RB_INDEX = K - 1
Re: Print a SYSMDUMP
Here is a video from SHARE Providence 2017. https://www.youtube.com/watch?v=GhI7ntAjVWU On 4/19/2021 7:56 AM, Ed Jaffe wrote: On 4/18/2021 10:39 PM, Seymour J Metz wrote: I'm pretty sure that Jerry Ng covered IPCS at SHARE. I don't have links for his diagnostic presentations. And after Jerry Ng retired, Evan Haruta took over and gave many such presentations. John Shebey has done this from a z/OS UNIX perspective and we have had LE-specific IPCS sessions from a host of different IBMers and others. I still remember the great pitch Don Poitras from SAS (who frequents this list) gave on the subject... The pièce de résistance was a special Sunday, eight-hour z/OS Debugging Academy with Patty Little and John Shebey. It was so successful, it ran two conferences in a row to a packed house! (I still have the T-Shirt!) 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: Is there a vertical split in ISPF?
The number of logical terminals depended on the geometry, e.g., you could have 4 24x80 sessions, 2 27x132 session, 1 62x160 session. It still ate up 4 addresses. I never wanted to run it as anything but 62x160, but several places had them chopped up into 4 for consoles. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Wendell Lovewell [01e9c0ee0673-dmarc-requ...@listserv.ua.edu] Sent: Monday, April 19, 2021 10:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there a vertical split in ISPF? You configured the 3174 controller to use 4 of it's ports to support 4 different LUs on the same coax, and it had to be in DFT mode. Then I think the 4 LU's were configurable to whatever screen size you wanted, but you might have had to give up some of the 3290's memory to get the 160 by ? screen size. My ears were younger back then & I could rest my eyes and listen for the high-pitched sound that meant the screen was being refreshed again (back in the days of "seconds" response time). My older boss didn't really believe me the time he caught me at it! -- 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: Is there a vertical split in ISPF?
It's certainly possible to enhance it to support explicit partitions. Whether he is willing to do so, and in what time frame, is best addressed directly to him. A more interesting question is what ISPF will do with screen format PART if the session supports explicit partitions and the screen is larger than 62x160. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of PINION, RICHARD W. [rpin...@firsthorizon.com] Sent: Monday, April 19, 2021 2:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there a vertical split in ISPF? I wonder if it would be possible for Tom Brennen to add support for a 3290 device? I wonder if ISPF SPLITV, 3290, and TN3270E are even a possibility, as the 3290/3x74 combination was a SNA thing??? I have no idea, as I can't even spell VTAM, SNA, or TN3270E. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM Earnings are excellent!
IBM Earnings were announced 30 minutes ago. Stellar performance and the stock is up $3 after hours and over 20% in the last 3 weeks. I guess their obit was premature. Cloud was up 4% to 5.44 billion. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "Wrong" Size Allocation with AVGREC? (problem closed)
> Will keep poking away at this and let you know what I find.
I'm satisfied the discrepancies I saw must have been due to something peculiar
to using DFSORT for the copy process as I could not recreate the problem
[output larger than input copying one file to another using (1) AVGREC and (2)
RLSE on SPACE parm] using a method other than DFSORT.
Thanks everyone for your guidance! I'm especially grateful to Andrew Rowley
for his insight, ignoring the literal meaning of AVGREC ("average record size")
and simply using it as a way to specify multiples of "K" or "M". His example:
> //DD1 DD DISP=(NEW,CATLG),
> // DSN=ANDREWR.TEST.DATASET,
> // SPACE=(2,(3,4)),AVGREC=M,
> // LRECL=80,RECFM=FB,DSORG=PS,BLKSIZE=27920,
> // UNIT=SYSDA
>
> ISPF 3.4 dataset information shows:
>
> Organization . . . : PS
> Record format . . . : FB
> Record length . . . : 80
> Block size . . . . : 27920
> 1st extent megabytes: 6 [ note primary = 6M ( 2 x 3 = 6) ]
> Secondary megabytes : 8[ note secondary = 8M ( 2 x 4 = 8) ]
Such usage makes the AVGREC method SO much easier to understand!
=> "AVGREC={M|K},SPACE=(x,(y,z))" where "x" = units of M or K, "y" = Primary
multiplier and "z" = Secondary multiplier.
If only IBM had used some term other than "AVGREC" [e.g.
"BASE=M,SPACE=(2,(3,4)"?] or even let {M|K} be a suffix [e.g.
"SPACE=(2M,(3,4))"] SO much confusion could have been avoided as to how it
actually works! Now that I understand it this way, the explanation given in
the IBM manuals seems positively Ptolemaic:
http://ibm.com/docs/en/zos/2.2.0?topic=requirements-average-record-length
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Format PDS unloaded on an CD
El lun, 19 abr 2021 a las 7:40, Hilario Garcia () escribi=C3=B3: > I have done multiple tests with different utilities (XMIT, FTP, IND $ > FILE, AMATERSE) and I have not been able to download them in a valid > format. Not surprising as it's been mangled -- the begining is chopped off plus possibly other damage. > Attached I send in hexadecimal format the beginning of one of the PDS > (loaded as FB, lrecl 80) and it seems that at the beginning of the > file is the directory of a PDS partitioned file. If the file is loaded > as FB and 80 bytes long, you can see the code in EBCDIC format. The > original file is in format binary and I have loaded it in binary. Yes, it appears to be (mostly) an iebcopy unload of a pds: IEBCOPY unload record 1: xid found at 1 (1) dsorg 0200 blksize 18b0 lrecl 0050 recfm 90 devtyp 3030200f refd6b00de end of iebcopy record 1 36 (input offset 2d) extent 0 at 3d The way iebcopy unload outputs a PDS is by dumping: - the device type - DEB information including the disk addresess for each extent - the raw DASD directory blocks - the raw DASD blocks for each member pointed to by each directory entry Each block dumped by iebcopy will be proceeded by the count field from that block. These 8 bytes contain CCHHRKDD: CC - disk cylinder address HH - disk head address R - record number on track K - key length (0 if no key) DD - data length These are all combined into the iebcopy VBS output file. Since this PDS was RECFM F and text all the printable characters are probably there ... somewhere. Which belong to which member is not as easy to figure out. Possibly it might take matching the CCHHR from the dumped data blocks to the TTR in the directory entry. There might be something to the order (member name order? TTR order?). There is/was documentation on the iebcopy unload format in some IBM manual. Possibly utilities or utilites logic? PS: Until you posted some of the hex data there was not much anyone could do to help you. > ._¢.&°..Ø"8.."8Vs...ê.,.ú...Ø..#...±.Ø..»ØHì4à® > 0C60001B0590087F3320007F2200EA0025060D0008006300F0008080088C5F4A > 0ADF208000F8000F00F8710F52002200020B0E0010B790001000F000F0004B088440001F > > -- > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a vertical split in ISPF?
I wonder if it would be possible for Tom Brennen to add support for a 3290 device? I wonder if ISPF SPLITV, 3290, and TN3270E are even a possibility, as the 3290/3x74 combination was a SNA thing??? I have no idea, as I can't even spell VTAM, SNA, or TN3270E. -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Cole Sent: Monday, April 19, 2021 2:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there a vertical split in ISPF? [External Email. Exercise caution when clicking links or opening attachments.] PCOMM would have to support the "3290" terminal type. I don't use PCOMM, so I don't actually know if it does or not, but I would be amazed if it did. Anyway, as someone else noted, SPLITV is supported in ISPF only for "3290" types, so the answer to your question would be No. It can't be done. Dave Cole At 4/18/2021 12:10 AM, kekronbekron wrote: >Would you mind showing us an example of how to set this up with pcomm, >for example? > >- KB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a vertical split in ISPF?
PCOMM would have to support the "3290" terminal type. I don't use PCOMM, so I don't actually know if it does or not, but I would be amazed if it did. Anyway, as someone else noted, SPLITV is supported in ISPF only for "3290" types, so the answer to your question would be No. It can't be done. Dave Cole At 4/18/2021 12:10 AM, kekronbekron wrote: Would you mind showing us an example of how to set this up with pcomm, for example? - KB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Format PDS unloaded on an CD
On Mon, 19 Apr 2021 11:06:52 -0500, Joe Monk wrote: > >So, you have a format problem. The format is IEBCOPY unload to a >sequential file on DASD. BUT that was then run thru IND$FILE TWICE, without >specifying the CRLF option to insert CRLFs on the PC to denote record ends. >So, you have a PC file there with no end-of-record markers. Once you can >re-create those, there is high probability you can reverse the process to >get it back to a straight sequential file and re-run it thru IEBCOPY. > That's likely to fail. Any incidental occurrence of 0x0D0A in data or metadata will be misinterpreted as a record boundary. IEBCOPY PDSU are RECFM=VBS. I have successfully moved an IEBCOPY PDSU to desktop and back by overriding to RECFM=U and transferring in binary, both ways. Then, with Rexx I used the BDW images to reconstruct the block boundaries in the PDSU. (A successful experiment; I no longer have access to the code.) SMP/E uses such a scheme to represent unloaded PDSU in SMPNTS. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Format PDS unloaded on an CD
For breaking down the records into the format they should have, maybe this IBM Docs link can help: https://www.ibm.com/docs/en/zos/2.2.0?topic=format-introduction That documentation describes the record formats for IEBCOPY unload datasets. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Monday, April 19, 2021 12:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Format PDS unloaded on an CD The problem is that he is missing the EOR indicators. The file he has is an IEBCOPY PDS UNLOAD to sequential file, but when the IND$FILE transfer to the PC was done, it was done without the usual CRLF option to maintain EOR. He is going to have to analyze the file and find a record break. Then we maybe write a rexx or something to read the file and split the records out. Joe On Mon, Apr 19, 2021 at 11:32 AM Chris Hoelscher wrote: > Try it a different way? > Download different files from the mainframe to a windows environment > using different protocols Look at the downloaded files to see if they > look at all similar in format to YOUR files That might help you work > backwards -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Format PDS unloaded on an CD
On Mon, 19 Apr 2021 13:26:42 +0200, Hilario Garcia wrote: >Hello, > >I had tested multiple combinations: > >RECFM LREL BLKSIZE >FB 80 0 >VB 256 6233 >FB 1024 0 >VS 32736 32740 >FB 803120 >.. Too other combinations of different values > >In my opinion the files appear like a PDS unloaded with control blocks and >directory at the firsts records. > >I will appreciate any suggestion. > "Records" mean little on your desktop system. For diagnosis, dump in hex the first few hundred bytes, either on desktop or on z after FTP BINARY RECFM=VB. Or both. The results should be identical. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Format PDS unloaded on an CD
Hello Joe, Thank you very much for your information. I understand that I have a format problem because apparently the files were downloaded through IND $ FILE without the CRLF option. How can I recreate them? The originals no longer exist in DASD. Can you detail how I could solve it? Thank you very much in advance. Kind Regards Hilario El lun, 19 abr 2021 a las 18:07, Joe Monk () escribió: > Hilario, > > So, you have a format problem. The format is IEBCOPY unload to a > sequential file on DASD. BUT that was then run thru IND$FILE TWICE, without > specifying the CRLF option to insert CRLFs on the PC to denote record ends. > So, you have a PC file there with no end-of-record markers. Once you can > re-create those, there is high probability you can reverse the process to > get it back to a straight sequential file and re-run it thru IEBCOPY. > > Joe > > On Mon, Apr 19, 2021 at 10:49 AM Hilario Garcia wrote: > > > Hello Joe, > > > > The files were downloaded from a Z / OS in 2007. I don't know how and > with > > what format. You are correct. > > > > Would you recommend me to take any other action to solve the problem? > > > > Thank you very much in advance. > > > > Kind Regards > > > > Hilario > > > > El lun, 19 abr 2021 a las 14:23, Joe Monk () > > escribió: > > > > > OK ... maybe now we're getting somewhere... > > > > > > I think we are having a case of deja vu here. Going back thru the > > archives > > > I found where the exact same dataset was created in 2007: > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > > > Behalf Of David Day > > > Sent: Thursday, May 24, 2007 5:34 PM > > > To: ibm-m...@bama.ua.edu > > > Subject: IEBCOPY Unloaded dataset to PC and back again...not > successful > > > > > > I used IEBCOPY to create a sequentail backup of an ISPF panel > > > library. I then used IND$FILE to transfer the dataset to my PC. > > Thought > > > I'd test the backup out by transferring back to the mainframe, and got > > the > > > following when I tried to use IEBCOPY to load the members back. > > > > > > STEP1COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT > > > IEB1128I *** COPYR1 (1ST PDSU PHYSICAL RECORD) > > >009400 1810 180C0100 00CA6D0F 02001810 | _ | > > >009410 0010 00509000 1810 3030200F 7FF8 | 8| > > >009420 0020 0D0C000F E5A2 2250 0002006B |Vs,| > > >009430 0030 008F 0080 0F000B08 A912 |z | > > >009440 0040 7F00 80807FF8 8800 0012 | 8 h | > > >009450 0050 6A78 1810 0200 9440 | | m | > > >009460 0060 6AA8 0C0067E8 6AA0 8800 | |y Y | h | > > >009470 00700002 3F000900 || > > >009480 0080 0612 20007FF8| 8| > > >009490 0090 || > > > IEB120I SYSUT1 VALIDATION ERROR > > > IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64 > > > BYTES LONG - ACTUAL VALUE IS X'001810' > > > > > > The IND$FILE for the GET or PUT operation did not specify CRLF as a > > > parameter. Can someone tell me what I did wrong, or if there is a > > > 'better' way to backup PDS data on a PC. Thanks. > > > > > > --Dave Day > > > > > > > > > So, now you know what you have. An ISPF panel library, that was > > > unloaded via IEBCOPY, then IND$FILE to a PC without specifying CRLF > > then > > > back to the mainframe. > > > > > > Joe > > > > > > > > > On Mon, Apr 19, 2021 at 4:04 AM Hilario Garcia > > wrote: > > > > > > > Hello, > > > > > > > > Thank you very much for your answer. I had already tried the solution > > you > > > > recommended and it gave me the following problem: > > > > > > > > IEBCOPY COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED > STATEMENT > > > > > > > > IEB1128I *** COPYR1 (1ST PDSU PHYSICAL RECORD) > > > > > > > > 0094A0 FFF8 7FE4 7FE0 |"U "\ > | > > > > > > > > 0094B0 0008 00CA6D0F 020018B0 00509000 00807FF8 | _ & > "8| > > > > > > > > 0094C0 0018 3030200F 7FF8 2721000F E5A2 | "8Vs > | > > > > > > > > 0094D0 0028 2252 0002006B 00DE 0080 | , > | > > > > > > > > 0094E0 0038 01000B07 6930 7F00 80807FF8 |" > "8| > > > > > > > > 0094F0 0048 8800 0011F000 6540 7FE4 | h 0 > "U| > > > > > > > > 009500 0058 0200 94E8 6570 0C14 | mY > | > > > > > > > > 009510 0068 6568 8800 | h > | > > > > > > > > 009520 0078 16000400 0611F000 20007FF8 | 0 > "8| > > > > > > > > 009530 0088 || > > > > > > > > 009540 0098 || > > > > > > > > IEB120I SYSUT1 VALIDATION ERROR > > > > > > > > IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64 > > > BYTES > > > > LONG > > > > IEB1030I DDNAME SYSUT1 REFERS TO PDSU DATA SET ON VOLUME SS > NAMED > > > > IBMUSER. > > > > IEB1030I DDNAME SYSUT2 REFERS TO PDS DATA SET ON
Re: IBM Encryption Facility for OpenPGP
On 4/19/21 5:26 AM, Beesley, Paul wrote: Thanks Lloyd, I wondered about that, but not sure how to get it to convert it to ASCII. Try the other way around. The "dd" command on Linux can convert ASCII to EBCDIC. Check the manual page for syntax. (Sorry, I don't remember and would have to look it up.) Try converting the (test) password from ASCII to EBCDIC and seeing if that will allow the decryption. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Format PDS unloaded on an CD
Hilario, So, you have a format problem. The format is IEBCOPY unload to a sequential file on DASD. BUT that was then run thru IND$FILE TWICE, without specifying the CRLF option to insert CRLFs on the PC to denote record ends. So, you have a PC file there with no end-of-record markers. Once you can re-create those, there is high probability you can reverse the process to get it back to a straight sequential file and re-run it thru IEBCOPY. Joe On Mon, Apr 19, 2021 at 10:49 AM Hilario Garcia wrote: > Hello Joe, > > The files were downloaded from a Z / OS in 2007. I don't know how and with > what format. You are correct. > > Would you recommend me to take any other action to solve the problem? > > Thank you very much in advance. > > Kind Regards > > Hilario > > El lun, 19 abr 2021 a las 14:23, Joe Monk () > escribió: > > > OK ... maybe now we're getting somewhere... > > > > I think we are having a case of deja vu here. Going back thru the > archives > > I found where the exact same dataset was created in 2007: > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > > Behalf Of David Day > > Sent: Thursday, May 24, 2007 5:34 PM > > To: ibm-m...@bama.ua.edu > > Subject: IEBCOPY Unloaded dataset to PC and back again...not successful > > > > I used IEBCOPY to create a sequentail backup of an ISPF panel > > library. I then used IND$FILE to transfer the dataset to my PC. > Thought > > I'd test the backup out by transferring back to the mainframe, and got > the > > following when I tried to use IEBCOPY to load the members back. > > > > STEP1COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT > > IEB1128I *** COPYR1 (1ST PDSU PHYSICAL RECORD) > >009400 1810 180C0100 00CA6D0F 02001810 | _ | > >009410 0010 00509000 1810 3030200F 7FF8 | 8| > >009420 0020 0D0C000F E5A2 2250 0002006B |Vs,| > >009430 0030 008F 0080 0F000B08 A912 |z | > >009440 0040 7F00 80807FF8 8800 0012 | 8 h | > >009450 0050 6A78 1810 0200 9440 | | m | > >009460 0060 6AA8 0C0067E8 6AA0 8800 | |y Y | h | > >009470 00700002 3F000900 || > >009480 0080 0612 20007FF8| 8| > >009490 0090 || > > IEB120I SYSUT1 VALIDATION ERROR > > IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64 > > BYTES LONG - ACTUAL VALUE IS X'001810' > > > > The IND$FILE for the GET or PUT operation did not specify CRLF as a > > parameter. Can someone tell me what I did wrong, or if there is a > > 'better' way to backup PDS data on a PC. Thanks. > > > > --Dave Day > > > > > > So, now you know what you have. An ISPF panel library, that was > > unloaded via IEBCOPY, then IND$FILE to a PC without specifying CRLF > then > > back to the mainframe. > > > > Joe > > > > > > On Mon, Apr 19, 2021 at 4:04 AM Hilario Garcia > wrote: > > > > > Hello, > > > > > > Thank you very much for your answer. I had already tried the solution > you > > > recommended and it gave me the following problem: > > > > > > IEBCOPY COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT > > > > > > IEB1128I *** COPYR1 (1ST PDSU PHYSICAL RECORD) > > > > > > 0094A0 FFF8 7FE4 7FE0 |"U "\ | > > > > > > 0094B0 0008 00CA6D0F 020018B0 00509000 00807FF8 | _ &"8| > > > > > > 0094C0 0018 3030200F 7FF8 2721000F E5A2 | "8Vs | > > > > > > 0094D0 0028 2252 0002006B 00DE 0080 | ,| > > > > > > 0094E0 0038 01000B07 6930 7F00 80807FF8 |" "8| > > > > > > 0094F0 0048 8800 0011F000 6540 7FE4 | h 0 "U| > > > > > > 009500 0058 0200 94E8 6570 0C14 | mY| > > > > > > 009510 0068 6568 8800 | h | > > > > > > 009520 0078 16000400 0611F000 20007FF8 | 0 "8| > > > > > > 009530 0088 || > > > > > > 009540 0098 || > > > > > > IEB120I SYSUT1 VALIDATION ERROR > > > > > > IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64 > > BYTES > > > LONG > > > IEB1030I DDNAME SYSUT1 REFERS TO PDSU DATA SET ON VOLUME SS NAMED > > > IBMUSER. > > > IEB1030I DDNAME SYSUT2 REFERS TO PDS DATA SET ON VOLUME SS NAMED > > > IBMUSER. > > > IEB166I NO MEMBERS LOADED TO DATA SET REFERENCED BY SYSUT2 > > > > > > IEB151I JOB HAS TERMINATED WITH ERROR(S) > > > > > > IEB147I END OF JOB - 8 WAS HIGHEST SEVERITY CODE > > > > > > > > > Do you recommend any other possible solution. > > > > > > Thank you very much in advance. > > > > > > Kind Regards > > > > > > Hilario > > > > > > El lun, 19 abr 2021 a las 10:29, Styles, Andy (ITS zPlatform Services) > (< > > > 00d68f765d25-dmarc-requ...@listserv.ua.edu>) escribió: > > > > > > > Classification: Public > > > > > > > > I wonder if these are IEBCOPY unload format - that is,
Re: Format PDS unloaded on an CD
Is the pds a fixed length text file? If not, first copy it to a fixed length unblocked text file on the mainframe and then download with ftp. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Hilario Garcia Sent: Monday, April 19, 2021 11:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Format PDS unloaded on an CD Hello, I have tried to upload the files through both the native FTP protocol and through FILEZILLA. The problem is the same as the format of the file received is not correct. Would you recommend me to take any other action to solve the problem? Thank you very much in advance. Kind Regards Hilario El lun, 19 abr 2021 a las 14:37, Barkow, Eileen (< 02bc504b1642-dmarc-requ...@listserv.ua.edu>) escribió: > Another way to copy a PDS to the pc is with ftp. > cd to a pc directory and run a command line ftp program initiated > from the pc and issue commands: (I use MOVE IT FREELY): > cd 'MAINFRAME.PDS' > ftp ftp parmsHOST NAME PORT > mget(*) > > Each member will be downloaded to the pc directory. > > Eileen Barkow ebar...@doitt.nyc.gov > CICS systems > Desk: 718-403-8649 > Cell: 917-436-0508 > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Joe Monk > Sent: Monday, April 19, 2021 8:23 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Format PDS unloaded on an CD > > OK ... maybe now we're getting somewhere... > > I think we are having a case of deja vu here. Going back thru the > archives I found where the exact same dataset was created in 2007: > > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of David Day > Sent: Thursday, May 24, 2007 5:34 PM > To: ibm-m...@bama.ua.edu > Subject: IEBCOPY Unloaded dataset to PC and back again...not > successful > > I used IEBCOPY to create a sequentail backup of an ISPF panel library. > I then used IND$FILE to transfer the dataset to my PC. Thought I'd > test the backup out by transferring back to the mainframe, and got the > following when I tried to use IEBCOPY to load the members back. > > STEP1COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT IEB1128I *** > COPYR1 (1ST PDSU PHYSICAL RECORD) >009400 1810 180C0100 00CA6D0F 02001810 | _ | >009410 0010 00509000 1810 3030200F 7FF8 | 8| >009420 0020 0D0C000F E5A2 2250 0002006B |Vs,| >009430 0030 008F 0080 0F000B08 A912 |z | >009440 0040 7F00 80807FF8 8800 0012 | 8 h | >009450 0050 6A78 1810 0200 9440 | | m | >009460 0060 6AA8 0C0067E8 6AA0 8800 | |y Y | h | >009470 00700002 3F000900 || >009480 0080 0612 20007FF8| 8| >009490 0090 || > IEB120I SYSUT1 VALIDATION ERROR > IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64 > BYTES LONG - ACTUAL VALUE IS X'001810' > > The IND$FILE for the GET or PUT operation did not specify CRLF as a > parameter. Can someone tell me what I did wrong, or if there is a > 'better' way to backup PDS data on a PC. Thanks. > > --Dave Day > > > So, now you know what you have. An ISPF panel library, that was > unloaded via IEBCOPY, then IND$FILE to a PC without specifying CRLF > then back to the mainframe. > > Joe > > > On Mon, Apr 19, 2021 at 4:04 AM Hilario Garcia wrote: > > > Hello, > > > > Thank you very much for your answer. I had already tried the > > solution you recommended and it gave me the following problem: > > > > IEBCOPY COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT > > > > IEB1128I *** COPYR1 (1ST PDSU PHYSICAL RECORD) > > > > 0094A0 FFF8 7FE4 7FE0 |"U "\ | > > > > 0094B0 0008 00CA6D0F 020018B0 00509000 00807FF8 | _ &"8| > > > > 0094C0 0018 3030200F 7FF8 2721000F E5A2 | "8Vs | > > > > 0094D0 0028 2252 0002006B 00DE 0080 | ,| > > > > 0094E0 0038 01000B07 6930 7F00 80807FF8 |" "8| > > > > 0094F0 0048 8800 0011F000 6540 7FE4 | h 0 "U| > > > > 009500 0058 0200 94E8 6570 0C14 | mY| > > > > 009510 0068 6568 8800 | h | > > > > 009520 0078 16000400 0611F000 20007FF8 | 0 "8| > > > > 009530 0088 || > > > > 009540 0098 || > > > > IEB120I SYSUT1 VALIDATION ERROR > > > > IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT > > 64 BYTES LONG > > IEB1030I DDNAME SYSUT1 REFERS TO PDSU DATA SET ON VOLUME SS NAMED > > IBMUSER. > > IEB1030I DDNAME SYSUT2 REFERS TO PDS DATA SET ON VOLUME SS NAMED > > IBMUSER. > > IEB166I NO MEMBERS LOADED TO DATA SET REFERENCED BY SYSUT2 > > > > IEB151I JOB HAS TERMINATED WITH ERROR(S) > > > > IEB147I END OF JOB - 8 WAS HIGHEST SEVERITY CODE > > > > > > Do you recommend any other possible solution. > > > >
Re: Format PDS unloaded on an CD
Hello Joe, The files were downloaded from a Z / OS in 2007. I don't know how and with what format. You are correct. Would you recommend me to take any other action to solve the problem? Thank you very much in advance. Kind Regards Hilario El lun, 19 abr 2021 a las 14:23, Joe Monk () escribió: > OK ... maybe now we're getting somewhere... > > I think we are having a case of deja vu here. Going back thru the archives > I found where the exact same dataset was created in 2007: > > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of David Day > Sent: Thursday, May 24, 2007 5:34 PM > To: ibm-m...@bama.ua.edu > Subject: IEBCOPY Unloaded dataset to PC and back again...not successful > > I used IEBCOPY to create a sequentail backup of an ISPF panel > library. I then used IND$FILE to transfer the dataset to my PC. Thought > I'd test the backup out by transferring back to the mainframe, and got the > following when I tried to use IEBCOPY to load the members back. > > STEP1COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT > IEB1128I *** COPYR1 (1ST PDSU PHYSICAL RECORD) >009400 1810 180C0100 00CA6D0F 02001810 | _ | >009410 0010 00509000 1810 3030200F 7FF8 | 8| >009420 0020 0D0C000F E5A2 2250 0002006B |Vs,| >009430 0030 008F 0080 0F000B08 A912 |z | >009440 0040 7F00 80807FF8 8800 0012 | 8 h | >009450 0050 6A78 1810 0200 9440 | | m | >009460 0060 6AA8 0C0067E8 6AA0 8800 | |y Y | h | >009470 00700002 3F000900 || >009480 0080 0612 20007FF8| 8| >009490 0090 || > IEB120I SYSUT1 VALIDATION ERROR > IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64 > BYTES LONG - ACTUAL VALUE IS X'001810' > > The IND$FILE for the GET or PUT operation did not specify CRLF as a > parameter. Can someone tell me what I did wrong, or if there is a > 'better' way to backup PDS data on a PC. Thanks. > > --Dave Day > > > So, now you know what you have. An ISPF panel library, that was > unloaded via IEBCOPY, then IND$FILE to a PC without specifying CRLF then > back to the mainframe. > > Joe > > > On Mon, Apr 19, 2021 at 4:04 AM Hilario Garcia wrote: > > > Hello, > > > > Thank you very much for your answer. I had already tried the solution you > > recommended and it gave me the following problem: > > > > IEBCOPY COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT > > > > IEB1128I *** COPYR1 (1ST PDSU PHYSICAL RECORD) > > > > 0094A0 FFF8 7FE4 7FE0 |"U "\ | > > > > 0094B0 0008 00CA6D0F 020018B0 00509000 00807FF8 | _ &"8| > > > > 0094C0 0018 3030200F 7FF8 2721000F E5A2 | "8Vs | > > > > 0094D0 0028 2252 0002006B 00DE 0080 | ,| > > > > 0094E0 0038 01000B07 6930 7F00 80807FF8 |" "8| > > > > 0094F0 0048 8800 0011F000 6540 7FE4 | h 0 "U| > > > > 009500 0058 0200 94E8 6570 0C14 | mY| > > > > 009510 0068 6568 8800 | h | > > > > 009520 0078 16000400 0611F000 20007FF8 | 0 "8| > > > > 009530 0088 || > > > > 009540 0098 || > > > > IEB120I SYSUT1 VALIDATION ERROR > > > > IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64 > BYTES > > LONG > > IEB1030I DDNAME SYSUT1 REFERS TO PDSU DATA SET ON VOLUME SS NAMED > > IBMUSER. > > IEB1030I DDNAME SYSUT2 REFERS TO PDS DATA SET ON VOLUME SS NAMED > > IBMUSER. > > IEB166I NO MEMBERS LOADED TO DATA SET REFERENCED BY SYSUT2 > > > > IEB151I JOB HAS TERMINATED WITH ERROR(S) > > > > IEB147I END OF JOB - 8 WAS HIGHEST SEVERITY CODE > > > > > > Do you recommend any other possible solution. > > > > Thank you very much in advance. > > > > Kind Regards > > > > Hilario > > > > El lun, 19 abr 2021 a las 10:29, Styles, Andy (ITS zPlatform Services) (< > > 00d68f765d25-dmarc-requ...@listserv.ua.edu>) escribió: > > > > > Classification: Public > > > > > > I wonder if these are IEBCOPY unload format - that is, IEBCOPY from a > PDS > > > to a PS. It's been years since I had to deal with those, probably > since > > I > > > installed products directly from a vendor tape (one of those round > things > > > with the write-protect ring). > > > > > > IEBCOPY seems to create unload format dasd datasets (here, at least) as > > > > > > Organization . . . : PS > > > Record format . . . : VS > > > Record length . . . : 32736 > > > Block size . . . . : 32740 > > > > > > Worth uploading one of those files as binary and then using an IEBCOPY > PS > > > to PDS to reload it? > > > > > > Andy Styles > > > z/Series System Programmer > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List On > Behalf > > > Of Hilario Garcia > > > Sent: 19 April 2021 06:42 > > >
Re: Format PDS unloaded on an CD
Hello, I have tried to upload the files through both the native FTP protocol and through FILEZILLA. The problem is the same as the format of the file received is not correct. Would you recommend me to take any other action to solve the problem? Thank you very much in advance. Kind Regards Hilario El lun, 19 abr 2021 a las 14:37, Barkow, Eileen (< 02bc504b1642-dmarc-requ...@listserv.ua.edu>) escribió: > Another way to copy a PDS to the pc is with ftp. > cd to a pc directory and run a command line ftp program initiated from > the pc and issue commands: (I use MOVE IT FREELY): > cd 'MAINFRAME.PDS' > ftp ftp parmsHOST NAME PORT > mget(*) > > Each member will be downloaded to the pc directory. > > Eileen Barkow ebar...@doitt.nyc.gov > CICS systems > Desk: 718-403-8649 > Cell: 917-436-0508 > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Joe Monk > Sent: Monday, April 19, 2021 8:23 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Format PDS unloaded on an CD > > OK ... maybe now we're getting somewhere... > > I think we are having a case of deja vu here. Going back thru the > archives I found where the exact same dataset was created in 2007: > > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf > Of David Day > Sent: Thursday, May 24, 2007 5:34 PM > To: ibm-m...@bama.ua.edu > Subject: IEBCOPY Unloaded dataset to PC and back again...not successful > > I used IEBCOPY to create a sequentail backup of an ISPF panel library. > I then used IND$FILE to transfer the dataset to my PC. Thought I'd test > the backup out by transferring back to the mainframe, and got the > following when I tried to use IEBCOPY to load the members back. > > STEP1COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT IEB1128I *** > COPYR1 (1ST PDSU PHYSICAL RECORD) >009400 1810 180C0100 00CA6D0F 02001810 | _ | >009410 0010 00509000 1810 3030200F 7FF8 | 8| >009420 0020 0D0C000F E5A2 2250 0002006B |Vs,| >009430 0030 008F 0080 0F000B08 A912 |z | >009440 0040 7F00 80807FF8 8800 0012 | 8 h | >009450 0050 6A78 1810 0200 9440 | | m | >009460 0060 6AA8 0C0067E8 6AA0 8800 | |y Y | h | >009470 00700002 3F000900 || >009480 0080 0612 20007FF8| 8| >009490 0090 || > IEB120I SYSUT1 VALIDATION ERROR > IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64 > BYTES LONG - ACTUAL VALUE IS X'001810' > > The IND$FILE for the GET or PUT operation did not specify CRLF as a > parameter. Can someone tell me what I did wrong, or if there is a > 'better' way to backup PDS data on a PC. Thanks. > > --Dave Day > > > So, now you know what you have. An ISPF panel library, that was > unloaded via IEBCOPY, then IND$FILE to a PC without specifying CRLF then > back to the mainframe. > > Joe > > > On Mon, Apr 19, 2021 at 4:04 AM Hilario Garcia wrote: > > > Hello, > > > > Thank you very much for your answer. I had already tried the solution > > you recommended and it gave me the following problem: > > > > IEBCOPY COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT > > > > IEB1128I *** COPYR1 (1ST PDSU PHYSICAL RECORD) > > > > 0094A0 FFF8 7FE4 7FE0 |"U "\ | > > > > 0094B0 0008 00CA6D0F 020018B0 00509000 00807FF8 | _ &"8| > > > > 0094C0 0018 3030200F 7FF8 2721000F E5A2 | "8Vs | > > > > 0094D0 0028 2252 0002006B 00DE 0080 | ,| > > > > 0094E0 0038 01000B07 6930 7F00 80807FF8 |" "8| > > > > 0094F0 0048 8800 0011F000 6540 7FE4 | h 0 "U| > > > > 009500 0058 0200 94E8 6570 0C14 | mY| > > > > 009510 0068 6568 8800 | h | > > > > 009520 0078 16000400 0611F000 20007FF8 | 0 "8| > > > > 009530 0088 || > > > > 009540 0098 || > > > > IEB120I SYSUT1 VALIDATION ERROR > > > > IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64 > > BYTES LONG > > IEB1030I DDNAME SYSUT1 REFERS TO PDSU DATA SET ON VOLUME SS NAMED > > IBMUSER. > > IEB1030I DDNAME SYSUT2 REFERS TO PDS DATA SET ON VOLUME SS NAMED > > IBMUSER. > > IEB166I NO MEMBERS LOADED TO DATA SET REFERENCED BY SYSUT2 > > > > IEB151I JOB HAS TERMINATED WITH ERROR(S) > > > > IEB147I END OF JOB - 8 WAS HIGHEST SEVERITY CODE > > > > > > Do you recommend any other possible solution. > > > > Thank you very much in advance. > > > > Kind Regards > > > > Hilario > > > > El lun, 19 abr 2021 a las 10:29, Styles, Andy (ITS zPlatform Services) > > (< > > 00d68f765d25-dmarc-requ...@listserv.ua.edu>) escribió: > > > > > Classification: Public > > > > > > I wonder if these are IEBCOPY unload format - that is, IEBCOPY from > > > a PDS to a PS. It's been
Re: Print a SYSMDUMP
On 4/19/2021 5:38 AM, Michael Babcock wrote: And if I remember correctly you can look at ACTIVE control blocks/memory using IPCS. You can do this in any debugger (e.g., TSO TEST) or with your own hand-written memory program. (There are several on the CBT tape.) Looking at memory you are authorized to look at is not an exposure... -- 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: Print a SYSMDUMP
On 4/18/2021 10:39 PM, Seymour J Metz wrote: I'm pretty sure that Jerry Ng covered IPCS at SHARE. I don't have links for his diagnostic presentations. And after Jerry Ng retired, Evan Haruta took over and gave many such presentations. John Shebey has done this from a z/OS UNIX perspective and we have had LE-specific IPCS sessions from a host of different IBMers and others. I still remember the great pitch Don Poitras from SAS (who frequents this list) gave on the subject... The pièce de résistance was a special Sunday, eight-hour z/OS Debugging Academy with Patty Little and John Shebey. It was so successful, it ran two conferences in a row to a packed house! (I still have the T-Shirt!) -- 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: [External] Re: Is there a vertical split in ISPF?
Yup, that's how I remember it as well. It had a single coax cable running to it, but you couldn't use the next 3 coax ports in the 3x74 controller. I remember the noise it made when it refreshed the screen as well. It seemed to me back at that time that there was an audible click for every character being repainted. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Wendell Lovewell Sent: Monday, April 19, 2021 9:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Is there a vertical split in ISPF? You configured the 3174 controller to use 4 of it's ports to support 4 different LUs on the same coax, and it had to be in DFT mode. Then I think the 4 LU's were configurable to whatever screen size you wanted, but you might have had to give up some of the 3290's memory to get the 160 by ? screen size. My ears were younger back then & I could rest my eyes and listen for the high-pitched sound that meant the screen was being refreshed again (back in the days of "seconds" response time). My older boss didn't really believe me the time he caught me at it! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a vertical split in ISPF?
You configured the 3174 controller to use 4 of it's ports to support 4 different LUs on the same coax, and it had to be in DFT mode. Then I think the 4 LU's were configurable to whatever screen size you wanted, but you might have had to give up some of the 3290's memory to get the 160 by ? screen size. My ears were younger back then & I could rest my eyes and listen for the high-pitched sound that meant the screen was being refreshed again (back in the days of "seconds" response time). My older boss didn't really believe me the time he caught me at it! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Print a SYSMDUMP
>And if I remember correctly you can look at ACTIVE control blocks/memory >using IPCS. Yes, you can. No problem for common storage because that is visible to every address space. active can also be used to peek into other address spaces and their data spaces. I hope everybody has protected that function! Here my group is the only one that can use it and I am the only one who knows how :-) Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Print a SYSMDUMP
And if I remember correctly you can look at ACTIVE control blocks/memory using IPCS. On Mon, Apr 19, 2021 at 7:25 AM Peter Relson wrote: > > >What is the 21st-Century rationale for not allowing everyone to use IPCS? > Mostly ignorance, I would guess. > > > One "practical" consideration could be "not being willing to properly > protect dump data sets". > If that's the case, restricting IPCS makes it harder (but far from > impossible) for "Jane Programmer" to be able to look at data captured in a > dump that they should not be able to see. This would be very important for > SVC Dump data sets. Probably not important for transaction dumps (I just > don't remember their rules). Definitely not important for sysmdumps. > > 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 > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Format PDS unloaded on an CD
Another way to copy a PDS to the pc is with ftp. cd to a pc directory and run a command line ftp program initiated from the pc and issue commands: (I use MOVE IT FREELY): cd 'MAINFRAME.PDS' ftp ftp parmsHOST NAME PORT mget(*) Each member will be downloaded to the pc directory. Eileen Barkow ebar...@doitt.nyc.gov CICS systems Desk: 718-403-8649 Cell: 917-436-0508 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Monday, April 19, 2021 8:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Format PDS unloaded on an CD OK ... maybe now we're getting somewhere... I think we are having a case of deja vu here. Going back thru the archives I found where the exact same dataset was created in 2007: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Day Sent: Thursday, May 24, 2007 5:34 PM To: ibm-m...@bama.ua.edu Subject: IEBCOPY Unloaded dataset to PC and back again...not successful I used IEBCOPY to create a sequentail backup of an ISPF panel library. I then used IND$FILE to transfer the dataset to my PC. Thought I'd test the backup out by transferring back to the mainframe, and got the following when I tried to use IEBCOPY to load the members back. STEP1COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT IEB1128I *** COPYR1 (1ST PDSU PHYSICAL RECORD) 009400 1810 180C0100 00CA6D0F 02001810 | _ | 009410 0010 00509000 1810 3030200F 7FF8 | 8| 009420 0020 0D0C000F E5A2 2250 0002006B |Vs,| 009430 0030 008F 0080 0F000B08 A912 |z | 009440 0040 7F00 80807FF8 8800 0012 | 8 h | 009450 0050 6A78 1810 0200 9440 | | m | 009460 0060 6AA8 0C0067E8 6AA0 8800 | |y Y | h | 009470 00700002 3F000900 || 009480 0080 0612 20007FF8| 8| 009490 0090 || IEB120I SYSUT1 VALIDATION ERROR IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64 BYTES LONG - ACTUAL VALUE IS X'001810' The IND$FILE for the GET or PUT operation did not specify CRLF as a parameter. Can someone tell me what I did wrong, or if there is a 'better' way to backup PDS data on a PC. Thanks. --Dave Day So, now you know what you have. An ISPF panel library, that was unloaded via IEBCOPY, then IND$FILE to a PC without specifying CRLF then back to the mainframe. Joe On Mon, Apr 19, 2021 at 4:04 AM Hilario Garcia wrote: > Hello, > > Thank you very much for your answer. I had already tried the solution > you recommended and it gave me the following problem: > > IEBCOPY COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT > > IEB1128I *** COPYR1 (1ST PDSU PHYSICAL RECORD) > > 0094A0 FFF8 7FE4 7FE0 |"U "\ | > > 0094B0 0008 00CA6D0F 020018B0 00509000 00807FF8 | _ &"8| > > 0094C0 0018 3030200F 7FF8 2721000F E5A2 | "8Vs | > > 0094D0 0028 2252 0002006B 00DE 0080 | ,| > > 0094E0 0038 01000B07 6930 7F00 80807FF8 |" "8| > > 0094F0 0048 8800 0011F000 6540 7FE4 | h 0 "U| > > 009500 0058 0200 94E8 6570 0C14 | mY| > > 009510 0068 6568 8800 | h | > > 009520 0078 16000400 0611F000 20007FF8 | 0 "8| > > 009530 0088 || > > 009540 0098 || > > IEB120I SYSUT1 VALIDATION ERROR > > IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64 > BYTES LONG > IEB1030I DDNAME SYSUT1 REFERS TO PDSU DATA SET ON VOLUME SS NAMED > IBMUSER. > IEB1030I DDNAME SYSUT2 REFERS TO PDS DATA SET ON VOLUME SS NAMED > IBMUSER. > IEB166I NO MEMBERS LOADED TO DATA SET REFERENCED BY SYSUT2 > > IEB151I JOB HAS TERMINATED WITH ERROR(S) > > IEB147I END OF JOB - 8 WAS HIGHEST SEVERITY CODE > > > Do you recommend any other possible solution. > > Thank you very much in advance. > > Kind Regards > > Hilario > > El lun, 19 abr 2021 a las 10:29, Styles, Andy (ITS zPlatform Services) > (< > 00d68f765d25-dmarc-requ...@listserv.ua.edu>) escribió: > > > Classification: Public > > > > I wonder if these are IEBCOPY unload format - that is, IEBCOPY from > > a PDS to a PS. It's been years since I had to deal with those, > > probably since > I > > installed products directly from a vendor tape (one of those round > > things with the write-protect ring). > > > > IEBCOPY seems to create unload format dasd datasets (here, at least) > > as > > > > Organization . . . : PS > > Record format . . . : VS > > Record length . . . : 32736 > > Block size . . . . : 32740 > > > > Worth uploading one of those files as binary and then using an > > IEBCOPY PS to PDS to reload it? > > > > Andy Styles > > z/Series System Programmer > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Hilario Garcia
Re: Print a SYSMDUMP
>What is the 21st-Century rationale for not allowing everyone to use IPCS? Mostly ignorance, I would guess. One "practical" consideration could be "not being willing to properly protect dump data sets". If that's the case, restricting IPCS makes it harder (but far from impossible) for "Jane Programmer" to be able to look at data captured in a dump that they should not be able to see. This would be very important for SVC Dump data sets. Probably not important for transaction dumps (I just don't remember their rules). Definitely not important for sysmdumps. 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: Format PDS unloaded on an CD
OK ... maybe now we're getting somewhere... I think we are having a case of deja vu here. Going back thru the archives I found where the exact same dataset was created in 2007: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Day Sent: Thursday, May 24, 2007 5:34 PM To: ibm-m...@bama.ua.edu Subject: IEBCOPY Unloaded dataset to PC and back again...not successful I used IEBCOPY to create a sequentail backup of an ISPF panel library. I then used IND$FILE to transfer the dataset to my PC. Thought I'd test the backup out by transferring back to the mainframe, and got the following when I tried to use IEBCOPY to load the members back. STEP1COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT IEB1128I *** COPYR1 (1ST PDSU PHYSICAL RECORD) 009400 1810 180C0100 00CA6D0F 02001810 | _ | 009410 0010 00509000 1810 3030200F 7FF8 | 8| 009420 0020 0D0C000F E5A2 2250 0002006B |Vs,| 009430 0030 008F 0080 0F000B08 A912 |z | 009440 0040 7F00 80807FF8 8800 0012 | 8 h | 009450 0050 6A78 1810 0200 9440 | | m | 009460 0060 6AA8 0C0067E8 6AA0 8800 | |y Y | h | 009470 00700002 3F000900 || 009480 0080 0612 20007FF8| 8| 009490 0090 || IEB120I SYSUT1 VALIDATION ERROR IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64 BYTES LONG - ACTUAL VALUE IS X'001810' The IND$FILE for the GET or PUT operation did not specify CRLF as a parameter. Can someone tell me what I did wrong, or if there is a 'better' way to backup PDS data on a PC. Thanks. --Dave Day So, now you know what you have. An ISPF panel library, that was unloaded via IEBCOPY, then IND$FILE to a PC without specifying CRLF then back to the mainframe. Joe On Mon, Apr 19, 2021 at 4:04 AM Hilario Garcia wrote: > Hello, > > Thank you very much for your answer. I had already tried the solution you > recommended and it gave me the following problem: > > IEBCOPY COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT > > IEB1128I *** COPYR1 (1ST PDSU PHYSICAL RECORD) > > 0094A0 FFF8 7FE4 7FE0 |"U "\ | > > 0094B0 0008 00CA6D0F 020018B0 00509000 00807FF8 | _ &"8| > > 0094C0 0018 3030200F 7FF8 2721000F E5A2 | "8Vs | > > 0094D0 0028 2252 0002006B 00DE 0080 | ,| > > 0094E0 0038 01000B07 6930 7F00 80807FF8 |" "8| > > 0094F0 0048 8800 0011F000 6540 7FE4 | h 0 "U| > > 009500 0058 0200 94E8 6570 0C14 | mY| > > 009510 0068 6568 8800 | h | > > 009520 0078 16000400 0611F000 20007FF8 | 0 "8| > > 009530 0088 || > > 009540 0098 || > > IEB120I SYSUT1 VALIDATION ERROR > > IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64 BYTES > LONG > IEB1030I DDNAME SYSUT1 REFERS TO PDSU DATA SET ON VOLUME SS NAMED > IBMUSER. > IEB1030I DDNAME SYSUT2 REFERS TO PDS DATA SET ON VOLUME SS NAMED > IBMUSER. > IEB166I NO MEMBERS LOADED TO DATA SET REFERENCED BY SYSUT2 > > IEB151I JOB HAS TERMINATED WITH ERROR(S) > > IEB147I END OF JOB - 8 WAS HIGHEST SEVERITY CODE > > > Do you recommend any other possible solution. > > Thank you very much in advance. > > Kind Regards > > Hilario > > El lun, 19 abr 2021 a las 10:29, Styles, Andy (ITS zPlatform Services) (< > 00d68f765d25-dmarc-requ...@listserv.ua.edu>) escribió: > > > Classification: Public > > > > I wonder if these are IEBCOPY unload format - that is, IEBCOPY from a PDS > > to a PS. It's been years since I had to deal with those, probably since > I > > installed products directly from a vendor tape (one of those round things > > with the write-protect ring). > > > > IEBCOPY seems to create unload format dasd datasets (here, at least) as > > > > Organization . . . : PS > > Record format . . . : VS > > Record length . . . : 32736 > > Block size . . . . : 32740 > > > > Worth uploading one of those files as binary and then using an IEBCOPY PS > > to PDS to reload it? > > > > Andy Styles > > z/Series System Programmer > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf > > Of Hilario Garcia > > Sent: 19 April 2021 06:42 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Fwd: Format PDS unloaded on an CD > > > > -- This email has reached the Bank via an external source -- > > > > > > -- Forwarded message - > > De: Hilario Garcia > > Date: lun, 19 abr 2021 a las 7:40 > > Subject: Format PDS unloaded on an CD > > To: > > > > > > Hello, > > > > Thank you very much for your contributions. > > I have done multiple tests with different utilities (XMIT, FTP, IND $ > FILE, > > AMATERSE) and I have not been able to download them in a valid format. > > Attached I send in
Re: IBM Encryption Facility for OpenPGP
Classification: Confidential Last I heard, IBM ECF was compatible w/PGP (Pretty Good Privacy) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Beesley, Paul Sent: Monday, April 19, 2021 5:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBM Encryption Facility for OpenPGP [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Hi Does anyone use IBM Encryption Facility for OpenPGP (FMID HCF7740), specifically to encrypt files on z/OS and decrypt them on Windows or Linux? I can successfully encrypt a file using a PassPhrase (not keys) and can decrypt it on another mainframe system. However, if I send the encrypted file to another platform I cannot decrypt it. It detects that I've used a passphrase, and AES_256, but will not accept the PassPhrase. This is what I get on Windows: C:\Users\xxx\Downloads>gpg -o D2021109.TEST3.TXT --decrypt D2021109.TEST3.ENC gpg: AES256.CFB encrypted session key gpg: encrypted with 1 passphrase gpg: decryption failed: Bad session key On Linux it's similar but the message is gpg: decryption failed: no secret key Any help welcome. I do have a PMR open with IBM, but every little helps... Paul Atos is a trading name used by the Atos group. The trading entity is registered in England and Wales: Atos IT Services UK Limited (registered number 01245534). The registered office is located at: Second Floor, MidCity Place, 71 High Holborn, London, WC1V 6EA. The VAT No. is: GB232327983. This e-mail and the documents attached are confidential and intended solely for the addressee and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Format PDS unloaded on an CD
Hello, I had tested multiple combinations: RECFM LREL BLKSIZE FB 80 0 VB 256 6233 FB 1024 0 VS 32736 32740 FB 803120 .. Too other combinations of different values In my opinion the files appear like a PDS unloaded with control blocks and directory at the firsts records. I will appreciate any suggestion. Thanks in advance. Kind regards. Hilario El lun, 19 abr 2021 a las 13:10, Andy Styles () escribió: > What was the format (recfm, blksize, lrecl, dsorg) of the zOS dataset that > you uploaded the CD copy to? > > Andy. > > > On Mon, 19 Apr 2021, 10:04 Hilario Garcia, wrote: > > > Hello, > > > > Thank you very much for your answer. I had already tried the solution you > > recommended and it gave me the following problem: > > > > IEBCOPY COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT > > > > IEB1128I *** COPYR1 (1ST PDSU PHYSICAL RECORD) > > > > 0094A0 FFF8 7FE4 7FE0 |"U "\ | > > > > 0094B0 0008 00CA6D0F 020018B0 00509000 00807FF8 | _ &"8| > > > > 0094C0 0018 3030200F 7FF8 2721000F E5A2 | "8Vs | > > > > 0094D0 0028 2252 0002006B 00DE 0080 | ,| > > > > 0094E0 0038 01000B07 6930 7F00 80807FF8 |" "8| > > > > 0094F0 0048 8800 0011F000 6540 7FE4 | h 0 "U| > > > > 009500 0058 0200 94E8 6570 0C14 | mY| > > > > 009510 0068 6568 8800 | h | > > > > 009520 0078 16000400 0611F000 20007FF8 | 0 "8| > > > > 009530 0088 || > > > > 009540 0098 || > > > > IEB120I SYSUT1 VALIDATION ERROR > > > > IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64 > BYTES > > LONG > > IEB1030I DDNAME SYSUT1 REFERS TO PDSU DATA SET ON VOLUME SS NAMED > > IBMUSER. > > IEB1030I DDNAME SYSUT2 REFERS TO PDS DATA SET ON VOLUME SS NAMED > > IBMUSER. > > IEB166I NO MEMBERS LOADED TO DATA SET REFERENCED BY SYSUT2 > > > > IEB151I JOB HAS TERMINATED WITH ERROR(S) > > > > IEB147I END OF JOB - 8 WAS HIGHEST SEVERITY CODE > > > > > > Do you recommend any other possible solution. > > > > Thank you very much in advance. > > > > Kind Regards > > > > Hilario > > > > El lun, 19 abr 2021 a las 10:29, Styles, Andy (ITS zPlatform Services) (< > > 00d68f765d25-dmarc-requ...@listserv.ua.edu>) escribió: > > > > > Classification: Public > > > > > > I wonder if these are IEBCOPY unload format - that is, IEBCOPY from a > PDS > > > to a PS. It's been years since I had to deal with those, probably > since > > I > > > installed products directly from a vendor tape (one of those round > things > > > with the write-protect ring). > > > > > > IEBCOPY seems to create unload format dasd datasets (here, at least) as > > > > > > Organization . . . : PS > > > Record format . . . : VS > > > Record length . . . : 32736 > > > Block size . . . . : 32740 > > > > > > Worth uploading one of those files as binary and then using an IEBCOPY > PS > > > to PDS to reload it? > > > > > > Andy Styles > > > z/Series System Programmer > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List On > Behalf > > > Of Hilario Garcia > > > Sent: 19 April 2021 06:42 > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Fwd: Format PDS unloaded on an CD > > > > > > -- This email has reached the Bank via an external source -- > > > > > > > > > -- Forwarded message - > > > De: Hilario Garcia > > > Date: lun, 19 abr 2021 a las 7:40 > > > Subject: Format PDS unloaded on an CD > > > To: > > > > > > > > > Hello, > > > > > > Thank you very much for your contributions. > > > I have done multiple tests with different utilities (XMIT, FTP, IND $ > > FILE, > > > AMATERSE) and I have not been able to download them in a valid format. > > > Attached I send in hexadecimal format the beginning of one of the PDS > > > (loaded as FB, lrecl = 80) and it seems that at the beginning of the > file > > > is the directory of a PDS partitioned file. If the file is loaded as FB > > and > > > 80 bytes long, you can see the code in EBCDIC format. The original file > > is > > > in format binary and I have loaded it in binary. > > > > > > I would appreciate your help in this regard. > > > > > > Thank you very much in advance. > > > > > > Kind Regards > > > > > > Hilario > > > > > > > > > > > > -- > > > 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
Re: IBM Encryption Facility for OpenPGP
Thanks Lloyd, I wondered about that, but not sure how to get it to convert it to ASCII. Best Regards Paul -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lloyd Fuller Sent: 19 April 2021 11:59 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM Encryption Facility for OpenPGP Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe. The issue is probably EBCDIC vs ASCII for the pass-phrase. Lloyd Sent from AT Yahoo Mail for iPad On Monday, April 19, 2021, 6:52 AM, Beesley, Paul wrote: Hi Does anyone use IBM Encryption Facility for OpenPGP (FMID HCF7740), specifically to encrypt files on z/OS and decrypt them on Windows or Linux? I can successfully encrypt a file using a PassPhrase (not keys) and can decrypt it on another mainframe system. However, if I send the encrypted file to another platform I cannot decrypt it. It detects that I've used a passphrase, and AES_256, but will not accept the PassPhrase. This is what I get on Windows: C:\Users\xxx\Downloads>gpg -o D2021109.TEST3.TXT --decrypt D2021109.TEST3.ENC gpg: AES256.CFB encrypted session key gpg: encrypted with 1 passphrase gpg: decryption failed: Bad session key On Linux it's similar but the message is gpg: decryption failed: no secret key Any help welcome. I do have a PMR open with IBM, but every little helps... Paul Atos is a trading name used by the Atos group. The trading entity is registered in England and Wales: Atos IT Services UK Limited (registered number 01245534). The registered office is located at: Second Floor, MidCity Place, 71 High Holborn, London, WC1V 6EA. The VAT No. is: GB232327983. This e-mail and the documents attached are confidential and intended solely for the addressee and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email. -- 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 Atos is a trading name used by the Atos group. The trading entity is registered in England and Wales: Atos IT Services UK Limited (registered number 01245534). The registered office is located at: Second Floor, MidCity Place, 71 High Holborn, London, WC1V 6EA. The VAT No. is: GB232327983. This e-mail and the documents attached are confidential and intended solely for the addressee and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Format PDS unloaded on an CD
What was the format (recfm, blksize, lrecl, dsorg) of the zOS dataset that you uploaded the CD copy to? Andy. On Mon, 19 Apr 2021, 10:04 Hilario Garcia, wrote: > Hello, > > Thank you very much for your answer. I had already tried the solution you > recommended and it gave me the following problem: > > IEBCOPY COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT > > IEB1128I *** COPYR1 (1ST PDSU PHYSICAL RECORD) > > 0094A0 FFF8 7FE4 7FE0 |"U "\ | > > 0094B0 0008 00CA6D0F 020018B0 00509000 00807FF8 | _ &"8| > > 0094C0 0018 3030200F 7FF8 2721000F E5A2 | "8Vs | > > 0094D0 0028 2252 0002006B 00DE 0080 | ,| > > 0094E0 0038 01000B07 6930 7F00 80807FF8 |" "8| > > 0094F0 0048 8800 0011F000 6540 7FE4 | h 0 "U| > > 009500 0058 0200 94E8 6570 0C14 | mY| > > 009510 0068 6568 8800 | h | > > 009520 0078 16000400 0611F000 20007FF8 | 0 "8| > > 009530 0088 || > > 009540 0098 || > > IEB120I SYSUT1 VALIDATION ERROR > > IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64 BYTES > LONG > IEB1030I DDNAME SYSUT1 REFERS TO PDSU DATA SET ON VOLUME SS NAMED > IBMUSER. > IEB1030I DDNAME SYSUT2 REFERS TO PDS DATA SET ON VOLUME SS NAMED > IBMUSER. > IEB166I NO MEMBERS LOADED TO DATA SET REFERENCED BY SYSUT2 > > IEB151I JOB HAS TERMINATED WITH ERROR(S) > > IEB147I END OF JOB - 8 WAS HIGHEST SEVERITY CODE > > > Do you recommend any other possible solution. > > Thank you very much in advance. > > Kind Regards > > Hilario > > El lun, 19 abr 2021 a las 10:29, Styles, Andy (ITS zPlatform Services) (< > 00d68f765d25-dmarc-requ...@listserv.ua.edu>) escribió: > > > Classification: Public > > > > I wonder if these are IEBCOPY unload format - that is, IEBCOPY from a PDS > > to a PS. It's been years since I had to deal with those, probably since > I > > installed products directly from a vendor tape (one of those round things > > with the write-protect ring). > > > > IEBCOPY seems to create unload format dasd datasets (here, at least) as > > > > Organization . . . : PS > > Record format . . . : VS > > Record length . . . : 32736 > > Block size . . . . : 32740 > > > > Worth uploading one of those files as binary and then using an IEBCOPY PS > > to PDS to reload it? > > > > Andy Styles > > z/Series System Programmer > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf > > Of Hilario Garcia > > Sent: 19 April 2021 06:42 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Fwd: Format PDS unloaded on an CD > > > > -- This email has reached the Bank via an external source -- > > > > > > -- Forwarded message - > > De: Hilario Garcia > > Date: lun, 19 abr 2021 a las 7:40 > > Subject: Format PDS unloaded on an CD > > To: > > > > > > Hello, > > > > Thank you very much for your contributions. > > I have done multiple tests with different utilities (XMIT, FTP, IND $ > FILE, > > AMATERSE) and I have not been able to download them in a valid format. > > Attached I send in hexadecimal format the beginning of one of the PDS > > (loaded as FB, lrecl = 80) and it seems that at the beginning of the file > > is the directory of a PDS partitioned file. If the file is loaded as FB > and > > 80 bytes long, you can see the code in EBCDIC format. The original file > is > > in format binary and I have loaded it in binary. > > > > I would appreciate your help in this regard. > > > > Thank you very much in advance. > > > > Kind Regards > > > > Hilario > > > > > > > > -- > > 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 > > Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 > 1YZ. > > Registered in Scotland no. SC95000. Telephone: 0131 225 4555. > > > > Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. > > Registered in England and Wales no. 2065. Telephone 0207626 1500. > > > > Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. > > Registered in Scotland no. SC327000. Telephone: 03457 801 801. > > > > Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, > > London EC2V 7HN. Registered in England and Wales no. 10399850. > > > > Scottish Widows Schroder Personal Wealth Limited. Registered Office: 25 > > Gresham Street, London EC2V 7HN. Registered in England and Wales no. > > 11722983. > > >
Re: IBM Encryption Facility for OpenPGP
The issue is probably EBCDIC vs ASCII for the pass-phrase. Lloyd Sent from AT Yahoo Mail for iPad On Monday, April 19, 2021, 6:52 AM, Beesley, Paul wrote: Hi Does anyone use IBM Encryption Facility for OpenPGP (FMID HCF7740), specifically to encrypt files on z/OS and decrypt them on Windows or Linux? I can successfully encrypt a file using a PassPhrase (not keys) and can decrypt it on another mainframe system. However, if I send the encrypted file to another platform I cannot decrypt it. It detects that I've used a passphrase, and AES_256, but will not accept the PassPhrase. This is what I get on Windows: C:\Users\xxx\Downloads>gpg -o D2021109.TEST3.TXT --decrypt D2021109.TEST3.ENC gpg: AES256.CFB encrypted session key gpg: encrypted with 1 passphrase gpg: decryption failed: Bad session key On Linux it's similar but the message is gpg: decryption failed: no secret key Any help welcome. I do have a PMR open with IBM, but every little helps... Paul Atos is a trading name used by the Atos group. The trading entity is registered in England and Wales: Atos IT Services UK Limited (registered number 01245534). The registered office is located at: Second Floor, MidCity Place, 71 High Holborn, London, WC1V 6EA. The VAT No. is: GB232327983. This e-mail and the documents attached are confidential and intended solely for the addressee and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email. -- 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
IBM Encryption Facility for OpenPGP
Hi Does anyone use IBM Encryption Facility for OpenPGP (FMID HCF7740), specifically to encrypt files on z/OS and decrypt them on Windows or Linux? I can successfully encrypt a file using a PassPhrase (not keys) and can decrypt it on another mainframe system. However, if I send the encrypted file to another platform I cannot decrypt it. It detects that I've used a passphrase, and AES_256, but will not accept the PassPhrase. This is what I get on Windows: C:\Users\xxx\Downloads>gpg -o D2021109.TEST3.TXT --decrypt D2021109.TEST3.ENC gpg: AES256.CFB encrypted session key gpg: encrypted with 1 passphrase gpg: decryption failed: Bad session key On Linux it's similar but the message is gpg: decryption failed: no secret key Any help welcome. I do have a PMR open with IBM, but every little helps... Paul Atos is a trading name used by the Atos group. The trading entity is registered in England and Wales: Atos IT Services UK Limited (registered number 01245534). The registered office is located at: Second Floor, MidCity Place, 71 High Holborn, London, WC1V 6EA. The VAT No. is: GB232327983. This e-mail and the documents attached are confidential and intended solely for the addressee and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Format PDS unloaded on an CD
Hello, It could have been first downloaded to a cartridge and then copied to a CD. The problem is that I do not have the original files but only this copy in CD and the person who made it is gone. Anyway, if they were downloaded to a cartridge, I understand that the most logical thing is that it will be done with IEBCOPY, but It seems that something is not right. When doing FTP from the CD to the Z / OS in FB format and 80 bytes the content can be seen but with control blocks. Thank you for your comments. Any additional ideas that can help me download them? Thank you very much in advance. Kind Regards Hilario El lun, 19 abr 2021 a las 11:11, Peter Sylvester () escribió: > Hm, Doesn't this looks like an unloaded PDS via IEBCOPY? Was it unloaded > initially to a tape? And > then copied to the CD? > > /PS > > On 19/04/2021 07:42, Hilario Garcia wrote: > > -- Forwarded message - > > De: Hilario Garcia > > Date: lun, 19 abr 2021 a las 7:40 > > Subject: Format PDS unloaded on an CD > > To: > > > > > > Hello, > > > > Thank you very much for your contributions. > > I have done multiple tests with different utilities (XMIT, FTP, IND $ > FILE, > > AMATERSE) and I have not been able to download them in a valid format. > > Attached I send in hexadecimal format the beginning of one of the PDS > > (loaded as FB, lrecl = 80) and it seems that at the beginning of the file > > is the directory of a > > PDS partitioned file. If the file is loaded as FB and 80 bytes long, you > > can see the code in EBCDIC format. The original file is in format > > binary and I have loaded it in binary. > > > > I would appreciate your help in this regard. > > > > Thank you very much in advance. > > > > Kind Regards > > > > Hilario > > > > > > > > -- > > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Format PDS unloaded on an CD
Hm, Doesn't this looks like an unloaded PDS via IEBCOPY? Was it unloaded initially to a tape? And then copied to the CD? /PS On 19/04/2021 07:42, Hilario Garcia wrote: -- Forwarded message - De: Hilario Garcia Date: lun, 19 abr 2021 a las 7:40 Subject: Format PDS unloaded on an CD To: Hello, Thank you very much for your contributions. I have done multiple tests with different utilities (XMIT, FTP, IND $ FILE, AMATERSE) and I have not been able to download them in a valid format. Attached I send in hexadecimal format the beginning of one of the PDS (loaded as FB, lrecl = 80) and it seems that at the beginning of the file is the directory of a PDS partitioned file. If the file is loaded as FB and 80 bytes long, you can see the code in EBCDIC format. The original file is in format binary and I have loaded it in binary. I would appreciate your help in this regard. Thank you very much in advance. Kind Regards Hilario -- 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: Format PDS unloaded on an CD
Hello, Thank you very much for your answer. I had already tried the solution you recommended and it gave me the following problem: IEBCOPY COPY INDD=SYSUT1,OUTDD=SYSUT2 GENERATED STATEMENT IEB1128I *** COPYR1 (1ST PDSU PHYSICAL RECORD) 0094A0 FFF8 7FE4 7FE0 |"U "\ | 0094B0 0008 00CA6D0F 020018B0 00509000 00807FF8 | _ &"8| 0094C0 0018 3030200F 7FF8 2721000F E5A2 | "8Vs | 0094D0 0028 2252 0002006B 00DE 0080 | ,| 0094E0 0038 01000B07 6930 7F00 80807FF8 |" "8| 0094F0 0048 8800 0011F000 6540 7FE4 | h 0 "U| 009500 0058 0200 94E8 6570 0C14 | mY| 009510 0068 6568 8800 | h | 009520 0078 16000400 0611F000 20007FF8 | 0 "8| 009530 0088 || 009540 0098 || IEB120I SYSUT1 VALIDATION ERROR IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64 BYTES LONG IEB1030I DDNAME SYSUT1 REFERS TO PDSU DATA SET ON VOLUME SS NAMED IBMUSER. IEB1030I DDNAME SYSUT2 REFERS TO PDS DATA SET ON VOLUME SS NAMED IBMUSER. IEB166I NO MEMBERS LOADED TO DATA SET REFERENCED BY SYSUT2 IEB151I JOB HAS TERMINATED WITH ERROR(S) IEB147I END OF JOB - 8 WAS HIGHEST SEVERITY CODE Do you recommend any other possible solution. Thank you very much in advance. Kind Regards Hilario El lun, 19 abr 2021 a las 10:29, Styles, Andy (ITS zPlatform Services) (< 00d68f765d25-dmarc-requ...@listserv.ua.edu>) escribió: > Classification: Public > > I wonder if these are IEBCOPY unload format - that is, IEBCOPY from a PDS > to a PS. It's been years since I had to deal with those, probably since I > installed products directly from a vendor tape (one of those round things > with the write-protect ring). > > IEBCOPY seems to create unload format dasd datasets (here, at least) as > > Organization . . . : PS > Record format . . . : VS > Record length . . . : 32736 > Block size . . . . : 32740 > > Worth uploading one of those files as binary and then using an IEBCOPY PS > to PDS to reload it? > > Andy Styles > z/Series System Programmer > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Hilario Garcia > Sent: 19 April 2021 06:42 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Fwd: Format PDS unloaded on an CD > > -- This email has reached the Bank via an external source -- > > > -- Forwarded message - > De: Hilario Garcia > Date: lun, 19 abr 2021 a las 7:40 > Subject: Format PDS unloaded on an CD > To: > > > Hello, > > Thank you very much for your contributions. > I have done multiple tests with different utilities (XMIT, FTP, IND $ FILE, > AMATERSE) and I have not been able to download them in a valid format. > Attached I send in hexadecimal format the beginning of one of the PDS > (loaded as FB, lrecl = 80) and it seems that at the beginning of the file > is the directory of a PDS partitioned file. If the file is loaded as FB and > 80 bytes long, you can see the code in EBCDIC format. The original file is > in format binary and I have loaded it in binary. > > I would appreciate your help in this regard. > > Thank you very much in advance. > > Kind Regards > > Hilario > > > > -- > 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 > Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. > Registered in Scotland no. SC95000. Telephone: 0131 225 4555. > > Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. > Registered in England and Wales no. 2065. Telephone 0207626 1500. > > Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. > Registered in Scotland no. SC327000. Telephone: 03457 801 801. > > Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, > London EC2V 7HN. Registered in England and Wales no. 10399850. > > Scottish Widows Schroder Personal Wealth Limited. Registered Office: 25 > Gresham Street, London EC2V 7HN. Registered in England and Wales no. > 11722983. > > Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets > plc are authorised by the Prudential Regulation Authority and regulated by > the Financial Conduct Authority and Prudential Regulation Authority. > > Scottish Widows Schroder Personal Wealth Limited is authorised and > regulated by the Financial Conduct Authority. > > Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned >
Re: Format PDS unloaded on an CD
Classification: Public I wonder if these are IEBCOPY unload format - that is, IEBCOPY from a PDS to a PS. It's been years since I had to deal with those, probably since I installed products directly from a vendor tape (one of those round things with the write-protect ring). IEBCOPY seems to create unload format dasd datasets (here, at least) as Organization . . . : PS Record format . . . : VS Record length . . . : 32736 Block size . . . . : 32740 Worth uploading one of those files as binary and then using an IEBCOPY PS to PDS to reload it? Andy Styles z/Series System Programmer -Original Message- From: IBM Mainframe Discussion List On Behalf Of Hilario Garcia Sent: 19 April 2021 06:42 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Fwd: Format PDS unloaded on an CD -- This email has reached the Bank via an external source -- -- Forwarded message - De: Hilario Garcia Date: lun, 19 abr 2021 a las 7:40 Subject: Format PDS unloaded on an CD To: Hello, Thank you very much for your contributions. I have done multiple tests with different utilities (XMIT, FTP, IND $ FILE, AMATERSE) and I have not been able to download them in a valid format. Attached I send in hexadecimal format the beginning of one of the PDS (loaded as FB, lrecl = 80) and it seems that at the beginning of the file is the directory of a PDS partitioned file. If the file is loaded as FB and 80 bytes long, you can see the code in EBCDIC format. The original file is in format binary and I have loaded it in binary. I would appreciate your help in this regard. Thank you very much in advance. Kind Regards Hilario -- 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 Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Scottish Widows Schroder Personal Wealth Limited. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 11722983. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Scottish Widows Schroder Personal Wealth Limited is authorised and regulated by the Financial Conduct Authority. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für Finanzdienstleistungsaufsicht. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Format of PDF collections?
> Perhaps more practical to make new indices. I see that recoll will eventually be included in ArcaOS. Thanks. > GIYF All that it is missing is a good search engine, a good e-mail client and a good news client, -- 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] Sent: Sunday, April 18, 2021 11:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Format of PDF collections? On Mon, 19 Apr 2021 01:26:50 +, Seymour J Metz wrote: >Yes, the index for the catalog of documents, consisting of the idx and psx >files, not the component of a PDF file also called catalog. > >Do you know of any FOSS software that supports the document catalog? I was >assuming that I would have to track down the formats and do it on the QT (My >Linux desktop is KDE). > Perhaps more practical to make new indices. GIYF LINUX INDEX PDF Also, https://secure-web.cisco.com/12jKtA0QueIL-RZSYge-yLmxDit5aLpDGLJuIBtiTDbIV7A1G9nyxPzfLYZccp5lxUfTOWQKkLZS2-0IqI8Eaiu1uSekyWR4jWBxpPlYZkqTe3E6nvA6C-fpKtEMOD9vcbM1Ruy6IdPWIKCX0giLP_UCdH-386YfXrWRtrHoHQNSwEQm-7s4poCBivvdY2ItpR1s24m-5CBmottgZ0WUK2j4fsU7kAtXkEwXGClvAcI3jog_LVZub8Uoz3s5P7kPvHCKctkit0Zz255DGCIw1ETmbjN__VHB0-vT2j_uVuhf825RD9-41bxzuaK2CsJeEsl0utApQZjI8Zg8y-0E7KZFXlaTasOB6PwG7RfXsh0Bd0w82i4SfoPhkNE4ZXepr0j47tcoeYCN5IVe5TRs_5UnYn4tNhOKoqyNK0HMjnbVBE7Rvd6G8zcVW_ul3D4gE/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FRecoll -- 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
