Re: Subpool 0 Usage
Janko, I think that is total BS. Subpool 0 (key 8) is the bread and butter of GETMAIN requests for non-APF authorized code. I have used that subpool for GETMAINs for over 35 years in my code. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Thu, Jul 11, 2024 at 4:04 PM Janko Kalinic wrote: > It was from a 2019 GSE conference presentation. > > On Thu, Jul 11, 2024 at 3:01 PM Binyamin Dissen < > 1773bcccb823-dmarc-requ...@listserv.uga.edu> wrote: > > > On Thu, 11 Jul 2024 14:14:02 -0500 Janko Kalinic < > > the.pds.comm...@gmail.com> > > wrote: > > > > :>I just read that you should NOT use Subpool 0 for anything if possible. > > :>Thoughts? > > > > Where did you read this? > > > > -- > > Binyamin Dissen > > http://www.dissensoftware.com > > > > Director, Dissen Software, Bar & Grill - Israel > > >
Re: BXLE usage assistance
Mark, You are coding a length (the 2) in the 2nd operand of your LH instruction...that 2 is being used by the machine as register 2. LH always loads two bytes. Mike Shaw MVS/QuickRef Support Chisoft On Tue, Jun 4, 2024, 1:38 PM Mark Young wrote: > Thanks for all the replies. See the code sample below. I'm getting stuck > trying to get the length for the next table entry into R8 so the BXLE > instruction loop the correct length. Let me know if I'm on the correct > path, or I'm in never never land. Also, the --->>> <<<--- is > where I think I'm getting stuck. > > TESTBXLE CSECT , > TESTBXLE AMODE 31 > TESTBXLE RMODE ANY > SAVE (14,12),,TESTBXLE*&SYSDATE*&SYSTIME > BALR R12,0 R12 - BASE REGISTER > USING *,R12 ESTABLISH ADDRESSABILITY > STR13,SAVEAREA+4 SAVEAREA > LAR13,SAVEAREAPOINTERS > * > CHKOPTS1 LAR7,TABLE1+4 ADDRESS OF FIRST ELEMENT > LHR8,TABLE1+2 LENGTH OF TABLE ENTRY > LAR9,TABLE1+2 ADDRESS OF BEGINNING OF TABLE > AHR9,TABLE1 CALC ADDR OF END OF TABLE > LOOP1CLC 0(9,R7),=C'F' > BEFOUND ENTRY FOUND = RC=0 > --->>> LHR8,0(2,R7) <<<--- POINT TO LENGTH OF NEXT ENTRY > BXLE R7,R8,LOOP1 LOOPING UNTIL OPT FOUND > B NOTFND ENRTY NOT FOUND ? RC=8 > * > FOUNDL R13,SAVEAREA+4 > RETURN (14,12),RC=0 > * > NOTFND L R13,SAVEAREA+4 > RETURN (14,12),RC=8 > * > PRINT NOGEN > YREGS > SAVEAREA DS18F > TABLE1 DS0F > DCXL2'008F' > DCXL2'000E',CL14'AA' > DCXL2'000F',CL15'BBB' > DCXL2'0011',CL17'C' > DCXL2'000D',CL13'D' > DCXL2'0017',CL23'EEE' > DCXL2'0009',CL9'F' > DCXL2'0013',CL19'GGG' > DCXL2'0019',CL25'H' > DCXL2'0008',CL8'' > END TESTBXLE > > > Thanks, > Mark. >
Re: BXLE usage assistance
Mark, Here is a code fragment where we use BXLE (fixed width font, hope this comes through): R:A 030D84068 USING VERVPR,R10 ESTAB BASE REG 00311E 5840 D0D8001FC 4069 L R4,VPRTADDR Point at exclude stack 003122 4160 003200032 4070 LAR6,VPRLTH Get length of one index entry 003126 5870 D0DC00200 4071 L R7,VPRTLAST Point at exclude stack 00312A 1B764072 SRR7,R6 Back up to last usable entry R:4 04073 USING VPRDSCT,R4 DSECT the first VPR table entry R:1 04074 USING QWRFDSCT,R1 DSECT the current index entry 00312C 4075 CKIDXEXC DS0H 00312C D531 4000 1010 0 00010 4076 CLC VPRVEN(VPRLTH),QWRFVEN Compare all three fields 003132 4780 A06A03142 4077 BECKIDXMAT Yes, we have a match 003136 8746 A0540312C 4078 BXLE R4,R6,CKIDXEXC Check all exclude stack entries 00313A 4079 CKIDXNOM DS0H 00313A 41F0 00044 4080 LAR15,4 Set no match RC 00313E 47F0 A06C03144 4081 B CKIDXXIT Go return to caller 003142 4082 CKIDXMAT DS0H 003142 17FF4083 XRR15,R15 Set match RC 003144 4084 CKIDXXIT DS0H 003144 50FA 000CC 4085 STR15,12(R10) SET RETURN CODE 003148 98EC A0088 4086 LMR14,R12,8(R10) RESTORE REGISTERS 00314C 07FE4087 BRR14 RETURN Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Wed, May 29, 2024 at 3:04 PM Mark < 176dcd91c5b1-dmarc-requ...@listserv.uga.edu> wrote: > Hello, > > I'm writing an exit where I have to scan through an array of variable > length entries in a table where the format is as below (all the entires are > readable characters) > > First 2 bytes = total length of array in hex > then > 2 bytes for length of first entry in hex > First Entry in table > 2 bytes for length of 2nd entry in hex > 2nd entry in table > 2 bytes for length of 3rd entry in hex > 3rd entry in table. > repeats until end of array. > > I'm thinking a BXLE will work, but getting stuck on exactly how to code > it. any help is greatly appriciated. > > Thanks, > Mark. > . >
Re: Instructions by Machine
This _gold_ for ISVs writing code that must execute on many different z models. Thank you Dan! Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Sat, May 11, 2024 at 4:07 PM Dan Greiner wrote: > Back when I was a full-time IBMer, I had a spreadsheet with all > z/Architecture instructions sorted by the machine in which they were > introduced. Unfortunately, this included IBM-confidential instructions, and > I was not able to take it with me when I retired. > > I recently spent a few hours massaging the instruction list in Appendix B3 > of the z/Architecture Principles of Operation, and correlating the facility > codes listed with the machine in which the instruction was introduced. You > can find the results in a spreadsheet on my Google drive: > > > https://docs.google.com/spreadsheets/d/1aU-4ndTXTEf17hCDLiqSqXfFENr39rIV/edit?usp=sharing&ouid=104012833061983447284&rtpof=true&sd=true > > Note, there may be some inaccuracies for instructions that were added by a > mid-life kicker, for which the documentation did not appear until the next > major machine was released. >
Re: Complex immediate fields
Wow. Truly impressive. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Fri, Mar 29, 2024, 7:48 PM Ngan, Robert (DXC Luxoft) wrote: > When I first saw "Complex immediate fields", I thought of this code one of > our emulation macros used to generate: > > CGIJL R01,132-(L'BKwa_Module+1+L'BK_LPAOS+1),BK250 > + CGHI R01,(1-132-(L'BKwa_Module+1+L'BK_LPAOS+1))-((132-(L'X > + BKwa_Module+1+L'BK_LPAOS+1))/256)*256)+256-132-(L'BKX > + wa_Module+1+L'BK_LPAOS+1))-((132-(L'BKwa_Module+1+L'BK_LX > + PAOS+1))/256)*256)+256)/256)*256)/128))*(((132-(L'BKwa_MX > + odule+1+L'BK_LPAOS+1))-((132-(L'BKwa_Module+1+L'BK_LPAOSX > + +1))/256)*256)+256-132-(L'BKwa_Module+1+L'BK_LPAOS+1X > + ))-((132-(L'BKwa_Module+1+L'BK_LPAOS+1))/256)*256)+256)/X > + 256)*256)+132-(L'BKwa_Module+1+L'BK_LPAOS+1))-((132-X > + (L'BKwa_Module+1+L'BK_LPAOS+1))/256)*256)+256-132-(LX > + 'BKwa_Module+1+L'BK_LPAOS+1))-((132-(L'BKwa_Module+1+L'BX > + K_LPAOS+1))/256)*256)+256)/256)*256)/128)*132-(L'BKwX > + a_Module+1+L'BK_LPAOS+1))-((132-(L'BKwa_Module+1+L'BK_LPX > + AOS+1))/256)*256)+256-132-(L'BKwa_Module+1+L'BK_LPAOX > + S+1))-((132-(L'BKwa_Module+1+L'BK_LPAOS+1))/256)*256)+25X > + 6)/256)*256)-256)+((132-(L'BKwa_Module+1+L'BK_LPAOS+1))+X > + 2147483520)*0+((132-(L'BKwa_Module+1+L'BK_LPAOS+1))-2147X > + 483520)*0Emulated z10 CGIJL instruction > + JLBK250 ... > > > Robert Ngan > DXC Luxoft > > -Original Message- > From: IBM Mainframe Assembler List On > Behalf Of Seymour J Metz > Sent: Friday, March 29, 2024 11:57 > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Complex immediate fields > > Back in he Assembler XF era I would code something like > > LAR0,L'DEST > LAR1,DEST > XRR15,R15 > ICM R15,8,=C' ' > MVCL R0,R14 > > On current hardware there is an IILF (LFI) instruction, and I would like > to use it instead of the XR/ICM sequence. I consider > > LFI R15,X'4000' > > to be ugly, and would like to be able to either use an immediate field > combing CL1 and XL3 pieces or to refer to an EQU defining that combination. > Is there any way to do that in HLASM? > > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > >
Re: ISPFHTML and z/OS 3.1
Yves, I installed the CAPTURE CLIST and the ISPFHTML load module on a vanilla z/OS V3R1 system; I get the same S0C1 ABEND. Digging deeper, the ABEND is caused when ISPFHTML branches to a x'184' offset into the TLD, where there is data, not a valid op code. Instead of the code that ISPFHTML expects to branch to, the TLD at x'184' offset contains this: l 9r?+184 x l(64) 0004C19C. 0003ABC8 00039858 00039CA4 0006 5000 000615F8 0004C1BC. 00064FE0 C9E2D7D7 F0F0F140 000C 007CBA68 The PSW is pointing to the X'AB' at x'186' offset into the TLD. I don't see a way around this one. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Tue, Dec 19, 2023 at 1:34 PM Rene BRANDT < 14a2846c6667-dmarc-requ...@listserv.uga.edu> wrote: > Yves, > > Do you have the same display in 2.4? > > René > > > Le mardi 19 décembre 2023 à 17:44:16 UTC+1, Yves Colliard < > yves.colli...@ycos.de> a écrit : > > Bonjour René, > > oui je pense que vous avez raison - you could be right... is it documented? > > 00035000 000183A8 000184A8 000185A8 000186A80B4782C8 0135 E3D3C4F1 > 00035018 *..cy..dy..ey..fy..bHTLD1..&.* > 00035020 00035018 0B495AF0 00035018000429F0 000429D8 000157B0 > 00015810 *..&...Ü0..&0...Q* > 00035040 00034FE8 00015AD8 0001ABD800015000 00016C48 0003D4C0 > *..!Y..ÜQ...Q..&...%...Mä* > 00035060 00035418 00034E70 0004390C 00035AD8 0003DC58 > 0B4AB068 *..+...ÜQ.Ä..* > 00035080 000163F4 000164F4 00035BE000035DE8 00035E80 00040318 > *...4...4..$Ö..)Y..;.* > 000350A0 5000 0400C203 FA00 000D004B > 006D *..&...B_* > 000350C0 0001 000361E8 26C0 003E00A0 003E 0058 > 003D *../Y...ä* > 000350E0 0058 003D 00A0 00010025 26C0 > 00036210 *...ä* > 00035100 0401 0003DCBD > ** > 00035120 > ** > 00035140 060726480044 > 02C0 *. .ä* > 00035160 0B4AB5CB C9E2D9C5 C4C4C5F4 C9E2D9C5 > C4C4C5F4 *.Ä..ISREDDE4ISREDDE4* > 00035180 C9E2D9F2 D4C1C3D9 C9E2D9E9 F0F0F140 > 0001ABC8 *ISR2MACRISRZ001 ...H* > 000351A0 00D49858 00D49CA40006D000 5000 0006E5F8 > 00071FE0 *.Mq..M.u..ü...&...V8...Ö* > 000351C0 C9E2D9E9 F0F0F140 00BCDB70 > 80BDE298 *ISRZ001 ..Sq* > 000351E0 4000 80BDE298 > 00BBAFE8 * .Sq...Y* > 00035200 84B6DAF8 00036108 BAF885E000D8 85DA10D8 > *d..8../8eÖ.Qe..Q* > 00035220 00036B20 00BA9F60 00064768 4000 > C9E2D7C6 *..,- ...ISPF* > 00035240 C8E3D4D3 00BCDB70 4000 FC00 > *HTML ...* > > here the data. Pointing to TLD - something we know... > But even if we can "fix" the "begin"... what about later... > > best regards - salutations > Yves > >
Re: ISPFHTML and z/OS 3.1
Yves, On our z/OS V2R4 system, ISPFHTML does not fail and works as advertised. You pointed out that upon entry, R1 contains the address of a TLD (Terminal Logical Descriptor) which is the ISPF control block associated with each logical screen under ISPF. On my system, ISPFHTML code shortly after entry does a BAL to x'184' into the TLD, where on my system this code fragment resides: 58F09190L R15,X'190(,R9) 07FF BR R15 58E0 9194 L R14,X'194(,R9) 07FE BR R14 00030858 In the TLD Yves displayed from his system, at x'184' offset there is this, instead of the code above: D4C1C3D9 which is c'MACR', not code. The TLD no longer holds code at that offset, but character strings. Doug used to work in ISPF development at IBM. His code is using knowledge he had of the TLD format that us mere mortals don't have. Looks like the TLD may have changed under z/OS V3R1? Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Tue, Dec 19, 2023 at 11:44 AM Yves Colliard wrote: > Bonjour René, > > oui je pense que vous avez raison - you could be right... is it documented? > > 00035000 000183A8 000184A8 000185A8 000186A80B4782C8 0135 E3D3C4F1 > 00035018 *..cy..dy..ey..fy..bHTLD1..&.* > 00035020 00035018 0B495AF0 00035018000429F0 000429D8 000157B0 > 00015810 *..&...Ü0..&0...Q* > 00035040 00034FE8 00015AD8 0001ABD800015000 00016C48 0003D4C0 > *..!Y..ÜQ...Q..&...%...Mä* > 00035060 00035418 00034E70 0004390C 00035AD8 0003DC58 > 0B4AB068 *..+...ÜQ.Ä..* > 00035080 000163F4 000164F4 00035BE000035DE8 00035E80 00040318 > *...4...4..$Ö..)Y..;.* > 000350A0 5000 0400C203 FA00 000D004B > 006D *..&...B_* > 000350C0 0001 000361E8 26C0 003E00A0 003E 0058 > 003D *../Y...ä* > 000350E0 0058 003D 00A0 00010025 26C0 > 00036210 *...ä* > 00035100 0401 0003DCBD > ** > 00035120 > ** > 00035140 060726480044 > 02C0 *. .ä* > 00035160 0B4AB5CB C9E2D9C5 C4C4C5F4 C9E2D9C5 > C4C4C5F4 *.Ä..ISREDDE4ISREDDE4* > 00035180 C9E2D9F2 D4C1C3D9 C9E2D9E9 F0F0F140 > 0001ABC8 *ISR2MACRISRZ001 ...H* > 000351A0 00D49858 00D49CA40006D000 5000 0006E5F8 > 00071FE0 *.Mq..M.u..ü...&...V8...Ö* > 000351C0 C9E2D9E9 F0F0F140 00BCDB70 > 80BDE298 *ISRZ001 ..Sq* > 000351E0 4000 80BDE298 > 00BBAFE8 * .Sq...Y* > 00035200 84B6DAF8 00036108 BAF885E000D8 85DA10D8 > *d..8../8eÖ.Qe..Q* > 00035220 00036B20 00BA9F60 00064768 4000 > C9E2D7C6 *..,- ...ISPF* > 00035240 C8E3D4D3 00BCDB70 4000 FC00 > *HTML ...* > > here the data. Pointing to TLD - something we know... > But even if we can "fix" the "begin"... what about later... > > best regards - salutations > Yves >
Re: ISPFHTML and z/OS 3.1
Yves, Any regs and PSW you can share? The module was last compiled in the year 2000 and is written in PL/X; no source AFAIK. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Mon, Dec 18, 2023 at 11:12 AM Yves Colliard wrote: > Hello! > > since years I'm using ISPFHTML from Doug Nadel - so a nice tool. But now - > using z/OS 3.1 - I got an Abend S0C1... > Do someone know something about: > - is the source of ISPFHTML somewhere? > - what did change in ISPF that could produce this problem... this could be > the bigger issue using z/OS 3.1 > > Many thanks and regards > Yves Colliard >
Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?
We do this with DSORG=PS and RECFM=F now. We load the file with QSAM and keep track of RBNs as we go. At EOF we rewrite index blocks to predetermined locations in the file with EXCP, then at READ time we use EXCP to read blocks and convert RBNs to CCHHRs based on the device geometry as we go. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd On Sat, Nov 11, 2023, 8:58 AM David S. wrote: > To help resolve a question posted to a LinkedIn group I manage: > www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944 > ... I'd like to find out if there's any way to achieve *true* > Skip-Sequential processing with a Fixed Block Sequential File with a fairly > short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)? > For example: Begin sequential processing at record number 100, *without* > having to read the first 99 records. > Note: We already know certain VSAM formats can do this, but the file in > question is a DSORG=PS *Sequential* file, *not* VSAM. This is a rock-solid > requirement and cannot be changed. We also already know how certain > utilities such as SORT and REXX can *mimic* skip-sequential functionality > by *discarding* unwanted records until the specified record number is > reached. This is a likewise rock-solid requirement. Sequential processing > *must* begin at specified starting point and there can be *no* reading of > any records prior to that point. > My gut feeling is it *cannot* be done - at least not with RECFM=FB. It > *might* be possible with RECFM=F, but efficiency would then be so > compromised it would probably outweigh any advantage from *true* > skip-sequential processing. >
Re: Tutorials for z and HLASM?
We have most of the non-privileged HLASM instructions and directives and HLASM JCL documented individually in MVS/QuickRef. A description of each instruction, with an example of how to use it, can be fetched using the mnemonic or the op code, e.g. QW L QW LARL QW USING QW PACK QW LTORG QW EB1C (for RLLG) 'course, the student needs to have access to z/OS :-) Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Thu, Oct 5, 2023 at 9:34 PM Seymour J Metz wrote: > Are there any good online tutorials for unprivileged z/Architecture and > HLASM for programmers with no prior assembler experience? Ideally I'd like > something faster paced than Programming 101, and several of us will be > available as mentors, workload permitting.
Re: IARV64 REQUEST=DISCARDDATA Question
Thank you Peter. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Wed, Sep 27, 2023 at 12:34 PM Peter Relson wrote: > Mike Shaw wrote > > The doc does not say what that memory object's pages contain just after > IARV64 REQUEST=GETSTOR is issued. > > > The "doc" actually does say so. But it's not surprising you didn't notice > it, because it's in the "guide" (and not in a section specifically for > IARV64) rather than in the "reference" for IARV64. > > The macro has "The initial value of storage within a memory object is > binary zero." > The assembler services guide has "IARV64 GETSTOR service creates memory > objects; storage is cleared to zeros". > > We will look into updating the reference's GETSTOR function to have the > same information. > > Peter Relson > z/OS Core Technology Design >
Re: IARV64 REQUEST=DISCARDDATA Question
Thanks Binyamin and Ed. Clear explanations. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Wed, Sep 27, 2023 at 3:23 AM Binyamin Dissen wrote: > As this function can never return partial pages, it will always be zero > upon > first use. > > On Tue, 26 Sep 2023 17:27:30 -0400 Mike Shaw > wrote: > > :>Based on the IARV64 doc in the z/OS Assembler Services Guide and in the > :>z/OS Assembler Services Reference, an IARV64 REQUEST=GETSTOR should be > :>followed by an IARV64 REQUEST=DISCARDDATA,CLEAR=YES in order to be > certain > :>that the obtained memory object contains no residual data. > :> > :>The doc does not say what that memory object's pages contain just after > :>IARV64 REQUEST=GETSTOR is issued. Does anyone on the list know? > :> > :>Mike Shaw > :>MVS/QuickRef Support Group > :>Chicago-Soft, Ltd. > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel >
IARV64 REQUEST=DISCARDDATA Question
Based on the IARV64 doc in the z/OS Assembler Services Guide and in the z/OS Assembler Services Reference, an IARV64 REQUEST=GETSTOR should be followed by an IARV64 REQUEST=DISCARDDATA,CLEAR=YES in order to be certain that the obtained memory object contains no residual data. The doc does not say what that memory object's pages contain just after IARV64 REQUEST=GETSTOR is issued. Does anyone on the list know? Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: ChatGPT "knows" HLASM
bard.google.com is much worse: -- Sure, here is a sample HLASM program that prints the message "Hello, world!" to the console: Code snippet HLASM program to print "Hello, world!" * * * CSECT * Start of main program MAIN: * Print message MVC SYSPRINT,MESSAGE PUT SYSPRINT,(1) * End of main program END MAIN * Message to be printed MESSAGE: DC C'Hello, world!' Then it tries to provide an explanation and makes things even more obscure: This program first defines a section called MAIN. This section contains the main program code. The next statement, MVC SYSPRINT,MESSAGE, copies the message Hello, world! to the memory location SYSPRINT. The next statement, PUT SYSPRINT,(1), prints the contents of SYSPRINT to the console. The last statement, END MAIN, marks the end of the main program. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Assembler theology question
The second method is better; it's shorter (no USINGs). Simpler is better. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Thu, Jun 1, 2023 at 12:24 PM Phil Smith III wrote: > We've all seen (and written!) code like this: > USING PSA,R9 > L R10,PSATOLD Get current TCB > DROP R9 > > USING TCB,R10 > L R9,TCBJSCB Get JSCB > DROP R10 > > I've also seen (and probably written) the equivalent: > L R10,PSATOLD-PSA(,R9)Get current TCB > L R9,TCBJSCB-TCB(,R1) Get JSCB > > I like the latter because it's tighter to read, reduces the USING map, > keeps you out of trouble if you decide to use R9 or R10 for something > global, etc. But I can also see a theological argument that you really > *are* using (USING?) the control block. > > Thoughts? (Yes, I *said* it was theology, so I'm prepared for religious > arguments!) >
Re: Blocking Low core access from Assembler programs
Syama, This may help. It is a ZAD SLIP trap. https://www.ibm.com/docs/en/zos/2.3.0?topic=traps-slip-zero-address-detection-zad Mike Shaw MVS/QuickRef Support Chicago-Soft, Ltd. On Mon, Mar 27, 2023, 6:47 PM syama prasad < 13f87d4b715f-dmarc-requ...@listserv.uga.edu> wrote: > Hi, > Is it possible to force an Assembler program to hit an access error if it > tries to load data from the low core (page starting from address > zero)?Assembler *PROCESS FLAG(PAGE0) " helps to find cases like MVC > TARGET,1But will it be possible to have a run time detection and possibly a > dump if the program tries to do things likeLA R5,1MVC > TARGET,0(R5)Basically, any way to restrict access of an application program > to PSA- first control block? > Regards,Syama >
Re: ASMA500 message question
Fear. Not wanting to try new things...I will try it. Mike On Fri, Nov 18, 2022 at 9:32 AM Seymour J Metz wrote: > What is your objection to GOFF and XOBJECT? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Mike Shaw [quick...@gmail.com] > Sent: Thursday, November 17, 2022 4:03 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: ASMA500 message question > > CATTR use requires GOFF object format, which I don't want to use. > > Mike > > > On Thu, Nov 17, 2022 at 3:31 PM Seymour J Metz wrote: > > > You need a CATTR with the proper alignment. > > > > ____ > > From: IBM Mainframe Assembler List on > > behalf of Mike Shaw > > Sent: Thursday, November 17, 2022 3:20 PM > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Subject: ASMA500 message question > > > > Everyone, > > > > This code fragment: > > > > 1C 4700 071 NOP 0 > > 20 0101 72 PR > > 22 73 DC0LQ > > *** ASMA500W Requested alignment exceeds section alignment * > > 22 74 QUAD@1 DCLQ'0' > > > > causes the *ASMA500W* message to be issued; it's description appears > below: > > > > > > > > > > > > > > > > > > > > > > > > > > * ASMA500W Requested alignment exceeds section alignment > > > > Explanation: The section alignment is lower than that requested on the > > instruction and hence the actual alignment may not be honored. > > > > System Action: The requested alignment is ignored. > > > > Programmer Response: Change the requested alignment to be less than or > > equal to that of the section, or ensure that the desired alignment is > > achieved during program linking and loading. > > * > > * Severity: 4 * > > > > Does anyone know what the 'section' mentioned in the message is? Is it a > > reference to the current control section (CSECT)? > > > > I don't get it...all I want to do is get quadword boundary alignment for > > the QUAD@1 constant. > > > > Mike Shaw > > MVS/QuickRef Support Group > > Chicago-Soft, Ltd. > > >
Re: Subject: ASMA500 message question
On Fri, Nov 18, 2022 at 7:50 AM Peter Relson wrote: > > Why would you not want to use GOFF? I can think of only one module in all > of z/OS that cannot use GOFF. I'll let guesses occur before providing the > answer in a day or two. > > Fear of the unknown! I will try it. Mike S.
Re: ASMA500 message question
That's it Mike, thank you. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Thu, Nov 17, 2022 at 4:33 PM Mike Hochee wrote: > We ran into this several years ago and ended up adjusting SECTALGN across > the board, which we were considering anyway. > > Pasted below is a post from Jonathan Scott about 6mos ago on the subject... > > HTH, > Mike > > >Apr 22, 2022, 1:33:06 PM > >to assembl...@listserv.uga.edu > >Since APAR PH40885 you can simply suppress warning ASMA500W if > >you don't want to be nagged about item alignment exceeding > >SECTALGN, as the alignment warning no longer prevents the > >expected code from being generated. > > >The section alignment for purposes of code generation is now > >always assumed to be as strong as is needed, but the binder > >alignment option is set based on SECTALGN and the warning is > i>ssued if item alignment exceeds the binder section alignment. > > -Original Message- > From: IBM Mainframe Assembler List On > Behalf Of Mike Shaw > Sent: Thursday, November 17, 2022 4:04 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: ASMA500 message question > > Caution! This message was sent from outside your organization. > > CATTR use requires GOFF object format, which I don't want to use. > > Mike > > > On Thu, Nov 17, 2022 at 3:31 PM Seymour J Metz wrote: > > > You need a CATTR with the proper alignment. > > > > > > From: IBM Mainframe Assembler List > > on behalf of Mike Shaw > > Sent: Thursday, November 17, 2022 3:20 PM > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Subject: ASMA500 message question > > > > Everyone, > > > > This code fragment: > > > > 1C 4700 071 NOP 0 > > 20 0101 72 PR > > 22 73 DC0LQ > > *** ASMA500W Requested alignment exceeds section alignment * > > 22 74 QUAD@1 DCLQ'0' > > > > causes the *ASMA500W* message to be issued; it's description appears > below: > > > > > > > > > > > > > > > > > > > > > > > > > > * ASMA500W Requested alignment exceeds section alignment > > > > Explanation: The section alignment is lower than that requested on > > the instruction and hence the actual alignment may not be honored. > > > > System Action: The requested alignment is ignored. > > > > Programmer Response: Change the requested alignment to be less than > > or equal to that of the section, or ensure that the desired alignment > > is achieved during program linking and loading. > >* > > * Severity: 4 * > > > > Does anyone know what the 'section' mentioned in the message is? Is it > > a reference to the current control section (CSECT)? > > > > I don't get it...all I want to do is get quadword boundary alignment > > for the QUAD@1 constant. > > > > Mike Shaw > > MVS/QuickRef Support Group > > Chicago-Soft, Ltd. > > >
Re: ASMA500 message question
CATTR use requires GOFF object format, which I don't want to use. Mike On Thu, Nov 17, 2022 at 3:31 PM Seymour J Metz wrote: > You need a CATTR with the proper alignment. > > > From: IBM Mainframe Assembler List on > behalf of Mike Shaw > Sent: Thursday, November 17, 2022 3:20 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: ASMA500 message question > > Everyone, > > This code fragment: > > 1C 4700 071 NOP 0 > 20 0101 72 PR > 22 73 DC0LQ > *** ASMA500W Requested alignment exceeds section alignment * > 22 74 QUAD@1 DCLQ'0' > > causes the *ASMA500W* message to be issued; it's description appears below: > > > > > > > > > > > > > * ASMA500W Requested alignment exceeds section alignment > > Explanation: The section alignment is lower than that requested on the > instruction and hence the actual alignment may not be honored. > > System Action: The requested alignment is ignored. > > Programmer Response: Change the requested alignment to be less than or > equal to that of the section, or ensure that the desired alignment is > achieved during program linking and loading. >* > * Severity: 4 * > > Does anyone know what the 'section' mentioned in the message is? Is it a > reference to the current control section (CSECT)? > > I don't get it...all I want to do is get quadword boundary alignment for > the QUAD@1 constant. > > Mike Shaw > MVS/QuickRef Support Group > Chicago-Soft, Ltd. >
ASMA500 message question
Everyone, This code fragment: 1C 4700 071 NOP 0 20 0101 72 PR 22 73 DC0LQ *** ASMA500W Requested alignment exceeds section alignment * 22 74 QUAD@1 DCLQ'0' causes the *ASMA500W* message to be issued; it's description appears below: * ASMA500W Requested alignment exceeds section alignment Explanation: The section alignment is lower than that requested on the instruction and hence the actual alignment may not be honored. System Action: The requested alignment is ignored. Programmer Response: Change the requested alignment to be less than or equal to that of the section, or ensure that the desired alignment is achieved during program linking and loading. * * Severity: 4 * Does anyone know what the 'section' mentioned in the message is? Is it a reference to the current control section (CSECT)? I don't get it...all I want to do is get quadword boundary alignment for the QUAD@1 constant. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Removal of transactional execution facility
Maybe Dan Greiner can comment on why IBM went to the trouble to introduce this powerful facility and then pull it? ISVs who implemented code using the transactional execution facility might feel kinda "had" now... Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Wed, Apr 6, 2022 at 4:17 PM Ngan, Robert (DXC Luxoft) < robert.n...@dxc.com> wrote: > In the Statement of general direction in the z16 announcement at: > > > https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/1/897/ENUS122-001/index.html > > It says IBM will remove support for the transactional execution facility, > I guess there's no point in attempting to exploit this now. > > Robert Ngan > DXC Luxoft >
Re: Branch-and-Link nomenclature question
Program linkage instructions? Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Thu, Feb 10, 2022 at 11:04 AM David Cole wrote: > In Assembler there are many machine instructions that are suitable > for calling subroutines: >- They go somewhere, >- But they also set a register that can be used to return to the > next following instruction. > > These instructions include: >- BAL (Branch and link) >- BALR (Branch and link register) >- BAS (Branch and save) >- JAS (jump and save) >- BRAS (Branch relative and save) >- BRASL (Branch relative and save long) >- BASSM (Branch and save and set mode) > > > > My question is this... > What is the collective name for these instructions? > > In a sentence such as "Then you branch and link to a subroutine...", > I tend to say "branch and link", > > but I'm always unhappy about that... >- Yes, "branch and link" is an accurate description of you're doing, >- While "branch and save" is a bit opaque. >- However, the phrase "branch and link" is ambiguous and invites > unnecessary quibbling. > > > So my question is... What would you say? > > TIA, > David Cole > dbc...@gmail.com (personal) > dbc...@colesoft.com (business) > 540-456-6518 (cell) >
Re: Making Encoded Bits Human Readable
Elegant...and now we're down to 24 bytes of machine code! Dan, is RISBGZ one of the instructions added to speed up Java garbage collection? Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Mon, Jan 31, 2022 at 4:08 PM Dan Greiner wrote: > The following code snippet does the trick, leaving the results in general > registers 0 and 1. > > LLC 0,BYTE > RISBGZ 1,0,62,63,-4 > SRL 0,6 > AHI 0,C'1'(or CA'1' for results in ASCII) > AHI 1,C'1' (or CA'1' for results in ASCII) > > (I consider ROTATE THEN INSERT SELECTED BITS to be the sexiest instruction > in the architecture.) >
Re: John Ehrman Assembler Text
Assembler Language Programming for IBM System z Servers Version 2.00; it's a 4 meg PDF. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Thu, Aug 13, 2020 at 8:43 AM FancyDancer wrote: > What are the titles of the manuals? > > Dan >
Re: Convert *signed* EBCDIC to packed decimal
"... or am I going to have to scan for the sign characters myself, remove them, pack the result, and flip the sign if it was negative? You do have to detect and handle leading plus/minus signs in EBCDIC strings yourself. PACK won't do it. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Wed, Jun 3, 2020 at 4:27 PM Doug Wegscheid wrote: > I'm getting reacquanted with s/370 assembler after a 40 years hiatus. > I'm working through some examples from my Kacmar book, and need to convert > from a character string to a packed decimal. PACK almost works, except it > does not handle a leading (or any) plus or minus signed. > Is there a *simple* way to do, or am I going to have to scan for the sign > characters myself, remove them, pack the result, and flip the sign if it > was negative? > Alternatively, is there some accessible prior art out there? >
Re: z/OS HLASM: EQU for statement labels
I agree with Gerhard; I was taught and use labelDS0H for labels instead of EQU. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Mon, Jun 1, 2020 at 4:46 PM Gerhard adam wrote: > > > > > Even though it may not happen often the EQU can point to an odd > address and cause the label to be referenced when it is filled with binary > zeroes (S0C1) > The use of 0H always forces boundary alignment for instructions > > > > Get Outlook for iOS > > > > > > > On Mon, Jun 1, 2020 at 1:43 PM -0700, "Schmitt, Michael" < > michael.schm...@dxc.com> wrote: > > > > > > > > > > > In John R. Ehrman's SHARE presentations on tips for modernizing IBM > z/Architecture assembler programs (such as > https://share.confex.com/share/120/webprogram/Handout/Session12522/modrnasm.pdf), > he says that important advice from experienced assembler programmers is to: > > _Don't_ use EQU for statement-label creation > > Can anyone venture a guess as to the reason for this advice? I've been > coding MVS assembler for 30 years and this is the first I've heard of this > guideline. > > One thing I'm wondering is if the suggestion is to avoid stand alone > statement labels entirely (such as LABEL EQU * or LABEL DS 0H) in favor of > putting the label on the next instruction? Or is there something about EQU > * that makes it a bad alternative to DS 0H? > > __ > Michael Schmitt | DXC.technology > > > DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, > Virginia 22102, USA. > DXC Technology Company -- This message is transmitted to you by or on > behalf of DXC Technology Company or one of its affiliates. It is intended > exclusively for the addressee. The substance of this message, along with > any attachments, may contain proprietary, confidential or privileged > information or information that is otherwise legally exempt from > disclosure. Any unauthorized review, use, disclosure or distribution is > prohibited. If you are not the intended recipient of this message, you are > not authorized to read, print, retain, copy or disseminate any part of this > message. If you have received this message in error, please destroy and > delete all copies and notify the sender by return e-mail. Regardless of > content, this e-mail shall not operate to bind DXC Technology Company or > any of its affiliates to any order or other contract unless pursuant to > explicit written agreement or government initiative expressly permitting > the use of e-mail for such purpose. --. >
Re: Sample code to practice assembler
The resources at this link will provide a good start: http://csc.columbusstate.edu/woolbright/WOOLBRIG.htm Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Thu, May 14, 2020 at 1:40 AM johnnydeep san wrote: > Hi all, > > I'm new bee and learning assembler by own. i'm glad to join this group. If > you guys having any link or doc for practice basic Z/os assembler code. > ,please let me know. > > Regards, > JD >
Re: BASR to AMODE 64
Or maybe a question instead of a musing? Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Fri, Nov 22, 2019, 1:00 AM Keven wrote: > > > > > The paucity of detail makes answering your inquiry a matter of > inductive supposition. Maybe you should post additional information such > as: > Source code?Assembly listing?ABEND code?SysLog? > > Keven > > > > > > > > > > > > > On Thu, Nov 21, 2019 at 9:26 PM -0600, "Joe Reichman" < > reichman...@gmail.com> wrote: > > > > > > > > > > > Hi > > > > I have a amode 64 rmode 31 program I would like to do I/O So I have to have > the DCB below 16mb So I have LOAD a module amode 64 rmode 24 > > > > After loading I turn the 1 bit to the right off now I have a clean half > address when I BASR to it bombs and the PSW has the one bit on > > > > A funny thing under TEST making a breaking point at the basr it doesn't > happen > > > > >
Re: Poll
POPs Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Mon, Sep 16, 2019 at 3:50 PM Phil Smith III wrote: > Principles of Operation-how do you refer to it? (NOT including case-let's > not make this any more complicated than it is already!) > > 1) PofOp > > 2) POP > > 3) POO > > 4) Pops > > 5) other? > > > > Just curious-there are no wrong answers, of course! (Well, I suppose > "IntelR 64 and IA-32 Architectures Software Developer Manuals" is wrong.) > > > > .phsiii > > >
Re: old code failing
The DEVTYPE macro is a much safer and simpler way to check for the presence of a DD. The old TIOT scan method may work and it may not work. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Wed, Jul 24, 2019 at 11:24 AM Richard Kuebbing wrote: > A subroutine written long ago appears to be failing. It looks for a > DDname in the TIOT. Did the format of the TIOT change at some point? If > yes, at what release? > > Does it matter if AMODE is 24 or 31? > > It might have something to do with the fact that the DD is a proc override > instead of straight JCL or in a proc. > > Richard Kuebbing > > NOTICE: This communication is intended only for the person or entity to > whom it is addressed and may contain confidential, proprietary, and/or > privileged material. Unless you are the intended addressee, any review, > reliance, dissemination, distribution, copying or use whatsoever of this > communication is strictly prohibited. If you received this in error, please > reply immediately and delete the material from all computers. Email sent > through the Internet is not secure. Do not use email to send us > confidential information such as credit card numbers, PIN numbers, > passwords, Social Security Numbers, Account numbers, or other important and > confidential information. >
Re: Probably dumb assembler question
On Thu, Jul 11, 2019 at 1:46 AM Jon Perryman wrote: > <...snip> When did freepool become a requirement?<.snip..> QSAM does not free the buffer pool. The user has to issue a FREEPOOL; AFAIK, it has been that way since OS/MVT. You can get away without doing a FREEPOOL until you issue thousands of consecutive OPEN/GET/PUT/CLOSE requests without any FREEPOOLs, then you run out of virtual private storage. I hit this same issue myself a few years ago with a recursive QSAM I/O routine. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Running ISPF's 3.5 utility from a clist
The DSECT for the stats is in ISP.AISPMACS(ISPDSTAT) on my z/OS V2R2 system. They are stored in the SSI field of each directory block, AFAIK. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Fri, Sep 14, 2018 at 11:57 AM Steve Smith wrote: > I am pretty sure there is a DSECT macro provided with ISPF that maps the > ISPF directory entry. It may well be easier (and certainly more efficient) > to just build them yourself. > > sas >
Re: IEATDUMP MF=L Can someone explain this?
We have the list form coded like this: IEATDUMP PLISTVER=MAX,MF=(L,IEATDUMPL) and the execute form coded like this: IEATDUMP DSN=DUMPDSNL,HDR=DUMPTITL, PLISTVER=MAX, MF=(E,IEATDUMPL) Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. >
Re: Last modified timestamp of a module
LISTIDR control statement of AMBLIST utility will do it. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Mon, Feb 19, 2018 at 11:18 AM, Jake Anderson wrote: > Hi > > We do not have a tool to see the modified stamp time stamp of a load > module. > > Is there a way to know ? > > Jake >
Re: Adcon (was: Address of a Literal)
I know adcons are relocatable in the sense that they are resolved to a virtual storage address when the load module is loaded and executed; I was referring to the second reason listed below in the ASMA032E HLASM error message: ASMA032E Relocatable value or unresolved symbol found when absolute value required Explanation: One of the following has occurred: o A relocatable or complex relocatable expression is used where an absolute expression is required. o A DSECT-based expression is used as an operand for an address constant where an expression that resolves into a storage address is required. that's the error you get when you try to use an adcon outside of a DSECT that points to a field mapped inside the USING range of the DSECT. Mike On Sun, Dec 10, 2017 at 2:30 PM, Charles Mills wrote: > Sure they can! You most basic A(label) is typically a reference to a > relocatable expression. > > Adcons can't refer to symbols in DSECTs because they don't have an > address. Where are they? Wherever you want them to be. Wherever their > register points. > > Charles > > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Mike Shaw > Sent: Sunday, December 10, 2017 10:34 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Adcon (was: Address of a Literal) > > Adcons cannot refer to relocatable expressions. >
Re: Adcon (was: Address of a Literal)
Adcons cannot refer to relocatable expressions. On Dec 10, 2017 12:37 PM, "Paul Gilmartin" < 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: On 2017-12-09, at 15:20:59, John Ehrman wrote: > A literal is implicitly a symbolic address and a constant-generation request; nesting those functions in other expressions was considered a bit too much extra work for ASMH, from which HLASM was derived. And there were no strong requests for forms such as A(=X'zzz') during the first six HLASM releases. > I believe there's good reason an A-constant can't refer to an address in a DSECT, yet I find no such restriction documented in the HLASM Language Ref. Have I overlooked a sentence? -- gil
Re: Detection of Compile-Time Self-Modifying Code
As scarce as z/Arch assembler jobs are nowadays, why shoot yourself in the foot doing that? I don't get it either... Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Tue, Oct 10, 2017 at 9:15 AM, Steve Smith wrote: > I have to agree with "retired" on this one. I can't see any way HLASM > could reliably detect this, and there are lots of other ways to do > such things. If I was trying to sneak something in, I'd make it much > harder to find than this. > > This is a strange case. How someone clever enough to code that could > be so stupid as to think it was a good idea is beyond me. Instead of > writing a few lines of code to deal with CC1, he thought it would be > better to wait until a customer reports gibberish output, and he gets > caught? In "The Daily WTF?" tradition, "brillant". > > sas > > On Tue, Oct 10, 2017 at 5:49 AM, retired mainframer > wrote: > > Some issues are easier to deal with by non-technical methods. > Publicizing the paragraph that precedes the code might demonstrate the > desirability of following the rules to all but the most obnoxious. > > >
Re: z14 PoO Available - SIGP description
Two-up PDF files are not really needed any more, are they? We are not really trying to save paper any more...the Pops has always been two-up, but other than tradition, why render it two-up any more? Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Sep 23, 2017 6:27 PM, "Dan Greiner" wrote: One of the unpleasant attributes of the software with which the PoO is rendered (Adobe FrameMaker) is that it occasionally gets its knickers tied in a knot rendering two-column material. This is the case in programming-note 1 on page 10-184. For an instruction description, programming notes usually follow the description of any program exceptions. FrameMaker somehow got it into its head that there was a page-wide text break immediately above the programming notes, thus it began rendering the notes in the left column. PN#1 actually continues immediately to the right, under the list of program exceptions. (This has been a known FM bug for over 10 years; but, as with many software vendors, there's little money to be made in fixing bugs.) Regarding SIGP order code 20 (0x14): As I recall, this is used only by the LPAR hypervisor, and should not have appeared in the external PoO. Since I'm now retired, I don't have access to the internal stuff any more, but I don't believe order code 20 is available to a logical partition or virtual machine. So, don't sweat it.
Re: Save areas (not XPLINK).
Me too. Makes me think of an old girlfriend... Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Mon, Jun 12, 2017 at 10:07 AM, John McKown wrote: > On Mon, Jun 12, 2017 at 8:59 AM, Ed Jaffe > wrote: > > > On 6/12/2017 6:40 AM, Steve Smith wrote: > > > >> Regardless of the meaning of "standard", IBM does provide the IHASAVER > >> macro to assist with those choices. > >> > >> I routinely make save areas 18D (or update from 18F) these days. > >> > > > > I make mine 36D to cover whatever format might be used now or in the > > future... > > > [giggling] I can't read the above without laughing. I'm just a pervert, I > guess. > > > > > > > > > -- > > Edward E Jaffe > > Phoenix Software International, Inc > > 831 Parkview Drive North > > El Segundo, CA 90245 > > http://www.phoenixsoftware.com/ > > > > > > -- > Veni, Vidi, VISA: I came, I saw, I did a little shopping. > > Maranatha! <>< > John McKown >
Re: Finding Dave Bond
OK, now I understand. Dave Bond wrote the old Tachyon Assembler Workbench, a similar emulator for batch problem state z/OS programs... Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Thu, Dec 8, 2016 at 2:41 PM, wrote: > > -Original Message- > > From: IBM Mainframe Assembler List [mailto:ASSEMBLER- > > l...@listserv.uga.edu] On Behalf Of Mike Shaw > > Sent: 08 December 2016 18:54 > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Subject: Re: Finding Dave Bond > > > > Yet another emulator...IBM will not bless this, will they? > > They certainly won't bless it, but if what I have gleaned is correct it > basically performs a similar task to the Z390 product. > > http://www.z390.org/ > > so executing the problem state code and emulating the interfaces and > API's. Of course some of the API's and problem state code may be > protected by Patents or Copyright. Copyright violations can perhaps be > minimized by a clean room approach, and patents perhaps by choosing a > suitable country.. > So as long as they don't sell the code elsewhere then IBM might have to > challenge them in a Swiss court:- > > https://en.wikipedia.org/wiki/Software_patents_under_the_Eur > opean_Patent_Convention > > which might be less in favour of a US corporation... > > .. but of course, I am only musing aloud, and we will have to wait to see > actually happens. I guess if they never land a sale then nothing will > happen... > .. if they I expect things to get interesting... > > > > > > Mike Shaw > > MVS/QuickRef Support Group > > Chicago-Soft, Ltd. > > Dave Wade > > > > > > On Thu, Dec 8, 2016 at 1:50 PM, Rob van der Heij > > wrote: > > > > > On 8 December 2016 at 19:35, Ed Jaffe > > wrote: > > > > > > > He lives in Switzerland and works for L^z Labs -- the latest John > > > > Moores kill-the-mainframe endeavor... > > > > > > > > > > Shaken, not stirred. License to kill the mainframe? > > > >
Re: Finding Dave Bond
Yet another emulator...IBM will not bless this, will they? Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Thu, Dec 8, 2016 at 1:50 PM, Rob van der Heij wrote: > On 8 December 2016 at 19:35, Ed Jaffe wrote: > > > He lives in Switzerland and works for L^z Labs -- the latest John Moores > > kill-the-mainframe endeavor... > > > > Shaken, not stirred. License to kill the mainframe? >
Re: Not Understanding 0C4-03B
Paul, The second LG...why are you loading eight bytes from a location that is decimal 50 bytes into the storage area you just obtained? Your comment says "position past starting address", but that's not what that instruction does. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Sun, Aug 28, 2016 at 5:24 PM, esst...@juno.com wrote: > I would like to convert a Data space to use a Memory Chunk and 64 Bit > Addressing. > Program is invoked in AMODE 31 and RMODE ANY > . > When I try to move some control information to the beginning of the memory > chunk I incur > a 0C4-03B Abend > . > * > SAM64Switch To 64 Bit Mode > LGG1,ORIGIN64Get Starting Address > LGG1,50(,G1) Position Past Starting Address > LAY R2,HDR64 Header Description > LLGTR G2,G2 Ensure G2 has a good address > MVC 00(HDR64#,G1),00(R2) Transfer Header Descripton > SAM31Return To 31 Bit Mode > * > The MVC instruction abends with an 0c4 - 03B > . > . > Can someone on this list explain why I am Abending And explain how to > properly correct it. > What exactly am I doing incorrectly > . > . > . > Here is a snipet of code preceding the move. > . > > * Use z/Architecture Instructions > SYSSTATE AMODE64=YES,ARCHLVL=2 > * > XGR G0,G0 G0 = 0 > IARV64 REQUEST=GETSTOR, >SEGMENTS=SEGMENTS, >GUARDLOC=HIGH, >GUARDSIZE=GRDSIZE, >ORIGIN=ORIGIN64, >COND=YES, >FPROT=NO, >USERTKN=NO_USERTKN, >TTOKEN=NO_TTOKEN, >RETCODE=RETCD64,RSNCODE=RSNCD64, >MF=(E,IARV64L,COMPLETE) > * > > > > STM R15,R0,ZRETCODES Save Return & Reason Code > * > SYSSTATE AMODE64=NO,ARCHLVL=2 > * > BRAS R14,EXAMINE_RESPONSE > > > * > SAM64Switch To 64 Bit Mode > LGG1,ORIGIN64Get Starting Address > LGG1,50(,G1) Get Starting Address > LARL R2,HDR64 Header Description > LAY R2,HDR64 Header Description > LLGTR G2,G2 Ensure G2 has a good address > MVC 00(HDR64#,G1),00(R2) Transfer Header Descripton > SAM31Return To 31 Bit Mode > * > * > DS 0AD .IARV64 Alignment > SEGMENTS DC FD'01' .IARV64 Segments > ORIGIN64 DC AD(0).IARV64 Origin Address > HIGH64 DC AD(0).IARV64 High End Address > DC AD(0).Reserved > > > . > . > Paul D'Angelo > * > * >
Re: CSRSIIDF Question
Thank you Peter. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Sat, Jul 2, 2016 at 9:01 AM, Peter Relson wrote: > >Then is there a reliable method for a non APF authorized program that > does > >not execute continuously to determine whether a capacity on demand > upgrade > >was performed since the last time that same program executed? > > Not that comes to mind. And, in fact, the operating system has no idea > that that has happened either. It knows only that a configuration change > event was identified by the machine (or for whatever other reason it > chooses to refresh the data, and there are some) and the system reacts to > changes that it finds within the data. The ENF signal that I presume you > are alluding to (non-APF authorized programs cannot listen for an ENF > signal) is about the (potential) configuration change event, not about a > capacity on demand upgrade. It is up to the listener to determine if there > is anything of interest that has changed. > > >Because some of the return codes indicate invalid data. > I would say "no they do not; they indicate that the data are not > available". That does not relate to the value in a particular field. > > Peter Relson > z/OS Core Technology Design >
Re: CSRSIIDF Question
Thank you Peter. Then is there a reliable method for a non APF authorized program that does not execute continuously to determine whether a capacity on demand upgrade was performed since the last time that same program executed? Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Jul 1, 2016 8:21 AM, "Peter Relson" wrote: > >Question: is it incorrect to rely on the presence of a timestamp in the > >SI00LASTUPDATETIMESTAMP field as an indication > >that a capacity on demand upgrade has been done? > > In a word, yes. > > There are system reasons why the STSI information might have been > refreshed. I believe that that includes cases where the hardware has > informed z/OS of a configuration change event that was not due to a > customer-initiated capaciy on demand upgrade. > > > Does your program check the return code after calling the CSRSI service? > > I'm not sure why that is relevant to the question that was asked. > > Peter Relson > z/OS Core Technology Design > >
Re: CSRSIIDF Question
Yes. We check for a zero return code. I know it's implied by the comment for that field that any issuance of STSI would update that timestamp. We have only seen one case where it was not done as a result of a COD upgrade. I thought our method for detecting a COD was the right method; maybe it's not. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Thu, Jun 30, 2016 at 1:26 PM, retired mainframer < retired-mainfra...@q.com> wrote: > Since a COD upgrade is "one event" that alters the field, it seems > reasonable to conclude that there are other events that also alter the > field. Your code may be making a false assumption. > > Does your program check the return code after calling the CSRSI service? > > The Knowledge Center (at > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieaa700/CSRSI_Description.htm > ) > identifies conditions under which the field is not valid. Do any of these > conditions apply to your customer? > > > -Original Message- > > From: IBM Mainframe Assembler List [mailto:ASSEMBLER- > > l...@listserv.uga.edu] On Behalf Of Mike Shaw > > Sent: Thursday, June 30, 2016 9:14 AM > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Subject: CSRSIIDF Question > > > > Anyone: > > > > Question about comments in the CSRSIIDF mapping DSECT used to map > > information returned by a call to the CSRSI service. The DSECT has this > field in it: > > > > SI00LASTUPDATETIMESTAMP DS CL8 STCK > > > > With these comments for the field: > > > > "timestamp when system last re-issued STSI to retrieve the most > current > > information. A capacity upgrade on demand event is one event that results > > in this update. The field is 0's if the information has not been > > retrieved since IPL." > > > Our code treats a non-zero value in the above field as an indication > that a capacity on demand upgrade has been performed since the last IPL. A > customer of ours had a non-zero value in the timestamp field, even though > they said they had not performed a capacity on demand upgrade. > > > The comments in the DSECT for the timestamp field make me think we > should not rely on just this field to signal that a capacity on demand > upgrade has occurred. > > > Question: is it incorrect to rely on the presence of a timestamp in the > SI00LASTUPDATETIMESTAMP field as an indication that a capacity on demand > upgrade has been done? >
CSRSIIDF Question
Anyone: Question about comments in the CSRSIIDF mapping DSECT used to map information returned by a call to the CSRSI service. The DSECT has this field in it: SI00LASTUPDATETIMESTAMP DS CL8 STCK With these comments for the field: " timestamp when system last re-issued STSI to retrieve the most current information. A capacity upgrade on demand event is one event that results in this update. The field is 0's if the information has not been retrieved since IPL. " Our code treats a non-zero value in the above field as an indication that a capacity on demand upgrade has been performed since the last IPL. A customer of ours had a non-zero value in the timestamp field, even though they said they had _ not _ performed a capacity on demand upgrade. The comments in the DSECT for the timestamp field make me think we should not rely on just this field to signal that a capacity on demand upgrade has occurred. Question: is it incorrect to rely on the presence of a timestamp in the SI00LASTUPDATETIMESTAMP field as an indication that a capacity on demand upgrade has been done? Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: My assembler text v2.00
John, I trust you will not leave this list when you leave IBM. You have always been the final arbiter of all things related to HLASM, and I know that all here on this list will agree that you should continue to be so. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Apr 13, 2016 7:42 PM, "John Ehrman" wrote: The second edition of my Assembler Language textbook is available for download at http://idcp.marist.edu/enterprisesystemseducation/assemblerlanguageresources-1.html The text is a PDF file (it's big: 1346 pages). The simple conversion and I/O macros decscribed in Appendix B are also available there. I'll be retiring from IBM at the end of May, so if you have any comments or suggestions, please send them to me at johnehrm...@gmail.com . Since the text was created on z/VM using IBM's BookMaster, I doubt I'll be able to create any further versions after retiring. I may, however, be able to provde occasional supplements and errata through the Marist College web site. (I'd like to provide a second text describing the Conditional Assembly and Macro language, but that will depend on time, energy, and need.) I plan to be available for consulting on Assembler Language topics like education, modernization, and simplification. Regards... John - 555 Bailey Ave, San Jose CA 95141 USA +1-408-463-3543 ehr...@us.ibm.com
Re: ASSEMBLER-LIST Digest - 6 Jan 2016 to 8 Jan 2016 (#2016-7)
I used BTAM to read/write from/to channel attached local 3270s many years ago. BTAM interface requests were easy to code and easy to debug. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Tue, Jan 12, 2016 at 2:24 AM, Ed Jaffe wrote: > On 1/11/2016 4:18 PM, John Walker wrote: > >> How does BPAM relate to BTAM? I was looking at this and finding a great >> similarity to old-fashioned PC basic dynamic reads. Can this be used on >> any modern mainframe? >> > > IBM stopped shipping BTAM years ago but, if you've kept the libraries > around, it still works! :-) > > The same might be true for TCAM as well, but alas in my location its > libraries got lost somewhere in the shuffle... :-( > > -- > Edward E Jaffe > Phoenix Software International, Inc > 831 Parkview Drive North > El Segundo, CA 90245 > http://www.phoenixsoftware.com/ >
Re: ASSEMBLER-LIST Digest - 10 Oct 2015 to 15 Oct 2015 (#2015-114)
John,
Contact me off-list; I may have something.
Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.
mike @ mike dot shaw dot name
On Fri, Oct 16, 2015 at 9:21 AM, John Walker <
00c645a0d640-dmarc-requ...@listserv.uga.edu> wrote:
> After the turn of the year, I will be looking for a job. Assembler would
> be fun to work with.
> I have done some fairly complicated assembler coding in the past at
> Caterpillar on the mainframe. I have done one user exit, played with
> dataspaces, code above the 31-bit line. I have not done much with the
> 64-bit stuff, but I wouldn't imagine it would be much of a stretch to look
> up any 64-bit instructions. Anyone needing an Assembler programmer? I do
> Cobol, Rexx, Clist also. I have done one html which submits jobs from my
> pc to the mainframe to update acf2 rules. It utilizes the mainframe's unix
> emulation which is in Rexx code. I had only gotten the proof-of-concept
> running before I found out that I am being forced into early retirement. I
> would prefer to telecommute, but if necessary, I am flexible. Thanks for
> any responses.
>
> On Thu, 10/15/15, ASSEMBLER-LIST automatic digest system <
> lists...@listserv.uga.edu> wrote:
>
> Subject: ASSEMBLER-LIST Digest - 10 Oct 2015 to 15 Oct 2015 (#2015-114)
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Date: Thursday, October 15, 2015, 11:00 PM
>
>
>
>
> ASSEMBLER-LIST Digest - 10 Oct 2015 to 15 Oct 2015
> (#2015-114)
>
> #yiv2341008013 body {
> font-family:Arial, Helvetica,
> sans-serif;font-size:12px;color:#00;}
> #yiv2341008013 td {
> font-family:Arial, Helvetica,
> sans-serif;font-size:12px;color:#00;}
> #yiv2341008013 p {
> font-family:Arial, Helvetica,
> sans-serif;font-size:12px;color:#00;}
> #yiv2341008013 a {
> font-family:Arial, Helvetica,
>
>
> sans-serif;font-size:12px;font-weight:bold;color:#3366CC;text-decoration:none;}
> #yiv2341008013 h2 {
> font-family:Arial, Helvetica,
> sans-serif;font-size:17px;font-weight:bold;color:#CC0033;}
> #yiv2341008013 h3 {
> font-family:Arial, Helvetica,
> sans-serif;font-size:16px;font-weight:bold;color:#3366CC;}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ASSEMBLER-LIST Digest - 10 Oct 2015 to 15 Oct 2015
> (#2015-114)
> Table of contents:
>
> Moves and others (23)
> DSPSERV Question (3)
>
>
> Moves and others
> Re: Moves and others
> (10/15)
> From: Robin Vowels
> Re: Moves and others
> (10/15)
> From: John McKown
>
> Re: Moves and others
> (10/15)
> From: Paul Gilmartin
> Re: Moves and others
> (10/15)
> From: Cali zMan
> Re: Moves and others
> (10/16)
> From: Robin Vowels
> Re: Moves and others
> (10/15)
> From: John McKown
>
> Re: Moves and others
> (10/15)
> From: Paul Gilmartin
> Re: Moves and others
> (10/15)
> From: John McKown
>
> Re: Moves and others
> (10/15)
> From: Paul Gilmartin
> Re: Moves and others
> (10/15)
> From: John McKown
>
> Re: Moves and others
> (10/15)
> From: Paul Gilmartin
> Re: Moves and others
> (10/15)
> From: John McKown
>
> Re: Moves and others
> (10/15)
> From: Gary Weinhold
> Re: Moves and others
> (10/15)
> From: Paul Gilmartin
> Re: Moves and others
> (10/15)
> From: Paul Gilmartin
> Re: Moves and others
> (10/15)
> From: Gary Weinhold
> Re: Moves and others
> (10/15)
> From: Tony Harminc
> Re: Moves and others
> (10/15)
> From: David de Jongh
> Re: Moves and others
> (10/16)
> From: Robin Vowels
> Re: Moves and others
> (10/16)
> From: Robin Vowels
> Re: Moves and others
> (10/15)
> From: Paul Gilmartin
> Re: Moves and others
> (10/16)
> From: Robin Vowels
> Re: Moves and others
> (10/15)
> From: "Robert A. Rosenberg"
>
> DSPSERV Question
> DSPSERV Question
> (10/15)
> From: Scott Ford
> Re: DSPSERV Question
> (10/15)
> From: Gary Weinhold
> Re: DSPSERV Question
> (10/15)
> From: Scott Ford
>
>
>
>
>
>
>
>
>
> Browse the ASSEMBLER-LIST
> online archives.
>
>
>
>
>
>
>
>
>
>
>
>
>
Re: Option to Prevent Data Loss Due to Truncation of Nominal Value
A good idea, but the HLASM should not warn on zero lengths coded in MVCs that are EX targets: MOVIT MVC 0(0,R1),=CL16'' >> Executed << Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: LZRG??? Does this mean that 56-bit addressing is "a thing"?
On Wed, Mar 11, 2015 at 10:49 AM, John McKown wrote: > Given some of the new instructions, such as LGZR, I wish IBM would > publish a manual with a title like: "What were the architects thinking > of? Explanation of the reasons behind the instructions in the z > architecture". > ... > "To make the code compiled by the C/C++ compiler and/or WebSphere / Java code run faster" is the answer to ANY "Why?" question about new instructions, IMHO... Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: John Ehrman Assembler Book
It looks very good. Comprehensive and well organized; a formidable work. I wish I'd had it 35 years ago. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Sun, Feb 8, 2015 at 3:44 PM, Richard A. Lawrence < r.a.lawrence...@ralawrence.us> wrote: > The long awaited John Ehrman Assembler book as available at the > Marist College web site: > > http://idcp.marist.edu/enterprisesystemseducation/Assembler%20Language% > 20Programming%20for%20IBM%20z%20System%20Servers.pdf >
Re: ASSEMBLER-LIST Digest - 24 Mar 2014 to 25 Mar 2014 (#2014-55)
On Wed, Mar 26, 2014 at 1:33 PM, John McKown wrote: > > You dislike arcane languages and you're on the ASSEMBLER-LIST?!? > Even the venerable old ISPF EDIT now supports regular expressions in FIND/CHANGE/EXCLUDE commands as of z/OS V2R1; from the ISPF Edit Macros Reference: "A regular expression in a FIND, CHANGE, or EXCLUDE command allows you to search for a string matching a *regular expression*. ISPF uses the IBM® C regcomp and regexec functions to compile and execute a regular expression specified with a FIND, CHANGE, or EXCLUDE command. These are supported by the C runtime library and the C runtime library must be available." Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Availability of SHA-1 and SHA-256 functions in KIMD/KLMD instructions?
On Tue, Feb 4, 2014 at 1:50 PM, Robert Ngan wrote: > .. > And no, I really don't want to dual path the code with my own > implementation of SHA-1 when I can't use KLMD. > > Robert Ngan > CSC Financial Services Group Robert: I believe if crypto is not there, KLMD is not there. We do this in our code: USING PSA,0 TMFLCFACL2,FLCFCRYA BOHASH_HARDWARE_IN_USE If the bit is off, we do SHA-1 in our own code. If the bit is on, we issue KLMD. -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Carmine Cannatello's book
I started as an Assembler application programmer 37 years ago. No COBOL at all, ever. Mike Shaw MVS/QuickRef Support Chicago-Soft, Ltd On Jan 15, 2014 6:04 PM, "Tony Thigpen" wrote: > Are you saying that all assembler programmers (including those on the > Assembler-List) are only for Systems Programmers? I am sure there are a > lot of assembler application programmers here also. > > Tony Thigpen > > -Original Message - > From: Gord Tomlin > Sent: 01/15/2014 05:53 PM > >> On 2014-01-15 17:17, Tony Thigpen wrote: >> >>> (Most Mainframe assembler programmers did time as a COBOL programmer.) >>> >> >> Interesting assertion. The majority of systems programmers I know did >> not come from an applications programming background. Personally, I've >> only written one COBOL program since university, which means it's the >> only one I wrote without using a keypunch. >> >> -- >> >> Regards, Gord Tomlin >> Action Software International >> (a division of Mazda Computer Corporation) >> Tel: (905) 470-7113, Fax: (905) 470-6507 >> >> >>
Re: Carmine Cannatello's book
Glad you did not say the hundredth person... Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Thu, Jan 2, 2014 at 3:34 PM, John Gilmore wrote: > I going through my technical books I found that I have an extra, > excellent-condition copy of > > Advanced assembler language and MVS interfaces, Wiley 1991. > > The fifth person who sends me his|her mailing address gets it postage free. > > John Gilmore, Ashland, MA 01721 - USA >
Re: 3 job openings for mainframe Assembler/C programmers, dump readers
On Fri, Jul 26, 2013 at 12:59 AM, William H. Blair wrote: > .. and what things > you did (called) in your program then look like in the system trace, et al. > .. > IMO, learning what each possible entry in the system trace table looks like, during normal system operation and during system stress or meltdown situations, goes a LONG way toward understanding what led up to and caused a problem, both for standalone, SVC and SYSUDUMP type dumps...trace table understanding is a very important dump reading skill. -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Baseless problem
On Thu, Apr 11, 2013 at 10:32 AM, Ed Jaffe wrote: > > The oldest assembler I ever used was IFOX00. ISTR, it did not have > support for LOCTR but my memory could be faulty. > > <http://www.phoenixsoftware.com/> You are of course correct; my reference was to eyecatcher placement after the initial instruction in the CSECT, which was a branch around the eyecatcher and its length byte. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Baseless problem
On Thu, Apr 11, 2013 at 8:47 AM, Steve Comstock wrote: > ..Well, Ed's super sharp but I think that technique has been > around a while. > > Amen. I saw it first in code in 1976, with the eyecatcher preceded by a one-byte length field for the eyecatcher. That one byte length is used by the dump formatter to print the eyecatchers when formatting the save area chain. -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: the fine manuals
On Fri, Dec 7, 2012 at 6:04 AM, Rob van der Heij wrote: > On 6 December 2012 17:59, McKown, John > wrote: > > > I despise InfoCenter. Try here: > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves for > BookManager + PDF. I use either > > Gentlemen, we feel your pain! As you know, our product relies heavily on extracting content from IBM z/OS technical documentation, and we have always used BookManager format doc in preference to other forms because of how easy it is to use. Now that BookManager is going the way of the dodo, and Info Center is "the way of the future", we can all suffer together... Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Use of "sequence numbering" in current HLASM source?
On Wed, Nov 7, 2012 at 10:21 AM, McKown, John wrote: > <...snip...> > > So, other than being "non main stream" and even "obsessively weird", is > there any *technical* reason to maintain sequence numbers? > > -- > John McKown > Systems Engineer IV > IT > > John, We use sequence numbers to extract change lines from edited source modules. The developer making the change maintains the sequence numbers on new or on changed lines he adds/changes. When the change is finished, he then uses SUPERC with process option UPDMVS8 and compares the new changed source module to the prior release of that same source module. SUPERC then emits a change file in IEBUPDTE format. Those change files (we call them 'delta' files) identify which lines were changed and how. Multiple such delta files can then be saved and applied later, or backed out if need be. This lets more than one developer work on the same source module at the same time. It ain't CVS, but it works -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Curosity Question
On Thu, Nov 1, 2012 at 6:14 PM, John Gilmore wrote: > If a hashing scheme is working well there is almost no clustering. > Suppose we divide by 17, a prime, i.e., use it, in the jargon, as our > hashing modulus.. Remainders will have one of the 17 values > > 0, 1, 2, . . . , 16. > > <...snip...> > Never hesitate to ask notional gurus such questions. A request for a > further explanation is always in order. > > --jg > Thank you John. Lucid and cogent. -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Model 2827 New Instructions
On Tue, Sep 18, 2012 at 1:23 PM, McKown, John wrote: > Damn, it's 100 years until that Share presentation? Or, by chance, did you > mean 2013? -- > 1000 years John... ;-) Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: ASSEMBLER-LIST Digest - 30 May 2012 to 31 May 2012 (#2012-97)
On Fri, Jun 1, 2012 at 10:16 AM, John Walker wrote: > <...snip...>attitudes which prefer an order of obfuscating complexity > which makes things more difficult than they could have otherwise been. > Amen Brother! Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Messages - Was MVC with 2nd operand length
On Tue, May 22, 2012 at 2:29 PM, McKown, John wrote: > <...snip...>IMO. I.e. a BASH UNIX prompt beats the crap out of line mode > TSO.<...snip...> > Jeepers John, I gotta disagree with you on that one. How is '#' as a prompt any better than 'READY'? As far as messages, there is no way IMHO that a non-numbered set of UNIX or LINUX messages is superior to ANY numbered IBM messages for ease of understanding. Google lets you look up those unnumbered messages on the Internet and try to find some meaning, but without Google non-numbered messages are an abomination. My biggest pet peeve is the explanation that certain unnumbered messages are 'self explanatory'. What a crock... IBM was very smart to assign messages alphanumeric prefixes and to collect them in reference manuals for users to read and understand. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Where to find out about "PER zero-address detection"?
On Wed, Apr 25, 2012 at 11:25 AM, Edward Jaffe wrote: > The description for z/OS msgIEE735I (output of D SLIP= command) > contains: > > | PER-ZAD > | PER zero address detection trap. > > This suggests strongly that you can issue a SLIP SET,ZAD,... command to > capture/track ZAD events on a z/OS system. > One could always try a SLIP SET,... command with ACTION=IGNORE to see if the syntax one has a hunch about is correct. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Assembler programmers wanted
On Mon, Mar 19, 2012 at 12:10 PM, Robert Shimizu wrote: > ... And, truth be told, he wants them to be as young as possible. > > Sincerely, > Bob > > -- > Robert W. Shimizu > Partner > ColeSoft Marketing, Inc > Age discrimination Bob, pure and simple... ;-) -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Program FLIH
On Fri, Feb 24, 2012 at 12:54 PM, Gibney, Dave wrote: > What I don't understand, pardon my "naifness" (split the thread John:), > is the need for such today. > When any of the vendors I named instruct me so, I dutifully APF their > libraries and they often reside in the linklist which we at least do set > AFP via IEASYSxx. > >Why a secret authority changing hook?-- > Dave, Maybe management @ the ISV says "it works, just use it, we can't spend the money rewriting all our apps that use that hook" Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Program FLIH
On Fri, Feb 24, 2012 at 8:43 AM, John Gilmore wrote: > > I believe, however, that this name should be made public. This > information should not be confined to the priesthood > John, The name of the offending ISV can be inferred if you read the text of each post in this thread carefully... -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Program FLIH
On Thu, Feb 23, 2012 at 5:08 PM, Tony Harminc wrote: > ... > > Now what does it *do*...? > > Tony H. > I smell a conspiracy...NSA hooks so "Big Brother" can watch us?...;-) -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: 128-bit arithmetic
On Mon, Jan 9, 2012 at 4:54 PM, Edward Jaffe wrote: > On 1/9/2012 1:40 PM, Steve Comstock wrote: > >> Here's what I'm thinking: >> >>LMG R2,R4,datetimen - put datetime into R2/R3 >> (use 64 bits in each reg) >> and put datetimes into R4/R5 >> (use 64 bits in each reg) >>SLBGR R3,R5 >>SLBGR R2,R4 >> > > You're not supposed to use a logical subtract 'with borrow' on the > low-order > part. You use it only on the high-order part--AFTER doing a logical > subtract > 'without borrow' on the low-order part. > Ed is again correct. This technique can be used to write routines that perform fixed-point arithmetic with arbitrarily long numbers, since you can perform the subtraction four bytes (or eight bytes) at a time, propagating a borrow should one occur. -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: UNICODE fractions
On Mon, Jan 9, 2012 at 9:46 AM, Steve Comstock wrote: > > BTW, thanks for the excellent listings of code pages > on your web site.-- > I echo Steve's comment. The code page listings David created have been very helpful to me on many occasions also. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Mixed Case in Assembler [Was: ASSEMBLER-LIST Digest - 20 Dec 2011 to 21 Dec 2011 (#2011-208)]
On Fri, Dec 30, 2011 at 9:13 AM, Paul Gilmartin wrote: > ... > > BTW, can ISPF be profiled to do case-sensitive searches by > default to spare me a few keystrokes in "f c'String'"? > > -- gil > No. An ISPF Edit macro could be written to do this, but it would have to prompt you for the string to search for, and that's somewhat sloppy also... -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: STIDP Question
Everyone: The issue involving an apparent duplicate CPU serial number which I posted about last week has been resolved. Jim Mulder of IBM z/OS System Test provided valuable information and clarification on this issue, as follows: quote "It looks like the answer is that when running under LPAR (which is always the case for any z/Architecture machine except the old z800 or z900), the STIDP data is not guaranteed to be world-wide unique, because LPAR replaces the plant of manufacture nybble with LPAR zone identification information. If you want an identifier which is world-wide unique, you need to look at the SYSIB 1.1.1 section of the data returned by the STSI instruction. (under z/OS, you can use the CSRSI callable service to obtain this instead of issuing the STSI instruction yourself). The Sequence Code from SYSIB 1.1.1, together with the Machine Type from STIDP, should provide world-wide uniqueness. I expect that a future edition of Principles of Operation will be updated to clarify this state of affairs." --end quote So, for ISVs that maintain data bases of licensed customer CPU serial numbers, it's possible for two different customers with the same IBM processor model type to have identical CPU serial numbers, IF you only consider the rightmost four characters of the CPU serial number when creating that customer's data base entry. If you consider the rightmost FIVE characters of CPU serial number (which you CANNOT do except when the box is executing in non-LPAR (i.e. BASIC) mode), the CPU serial numbers ARE unique within IBM CPU model type. Jim points out above that all current IBM boxes execute z/OS in LPAR mode. I am NOT considering CPU serial numbers in use when z/OS is executing as a z/VM guest. You z/VM guys will have to sort that out. -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: ASM Program to copy a file
On Thu, Dec 8, 2011 at 12:57 PM, Steve Comstock wrote: > ...[ I love this quote, from the PDF version, p. 326 [logical > page number, 348 physical page number]]: > > "It is not the intent of IBM to require extensive education >to use assembly language programming."--... Good one Steve. It may not be IBM's intent, but the fact is things have ended up that way... Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: STIDP Question
Tony: I agree that it is implausible. One customer is in Singapore, the other is in Iowa. If they are using the same service bureau, they haven't told us about it. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Mon, Dec 5, 2011 at 11:06 PM, Tony Harminc wrote: > On 5 December 2011 16:54, Mike Shaw wrote: > > Everyone: > > > > The POPs contains the text below within the description of the STIDP > > instruction: > > > > "When the format bit is zero, the contents of the > CPU-identification-number > > field, in conjunction with the machine-type number, permit unique > > identification of the CPU." > > > > Now, I always thought that the text above was stating that the CPU serial > > number (6 chars, of which the rightmost four are useful) was 'guaranteed' > > to be unique across all CPUs manufactured by IBM for that machine-type > > number. However, I've found a case where two different customers of ours > > both have 2817 machine types and the same CPU serial number. > > > > Is this a nomenclature issue? One customer has a 2817-605, and the other > > has a 2817-704. Both boxes have the same CPU serial number. Is the > > 'machine-type number' mentioned in the POPs text above supposed to refer > to > > the type plus sub-model, or just the type? > > > > I thought I understood this until I found this apparent duplicate CPU > > serial number case. > > This seems implausible... Are you sure your customers are not both > using the same service bureau, and that one doesn't sell time to the > other? > > Tony H. > --
STIDP Question
Everyone: The POPs contains the text below within the description of the STIDP instruction: "When the format bit is zero, the contents of the CPU-identification-number field, in conjunction with the machine-type number, permit unique identification of the CPU." Now, I always thought that the text above was stating that the CPU serial number (6 chars, of which the rightmost four are useful) was 'guaranteed' to be unique across all CPUs manufactured by IBM for that machine-type number. However, I've found a case where two different customers of ours both have 2817 machine types and the same CPU serial number. Is this a nomenclature issue? One customer has a 2817-605, and the other has a 2817-704. Both boxes have the same CPU serial number. Is the 'machine-type number' mentioned in the POPs text above supposed to refer to the type plus sub-model, or just the type? I thought I understood this until I found this apparent duplicate CPU serial number case. -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: newer opcodes
On Thu, Oct 13, 2011 at 8:27 AM, Martin Truebner wrote: > Peter, > > >> simple rule of thumb: > > Talking about simple... would it be too much asking to insert (right > behind the note about operation exception when not installed) the > corresponding bit in STFLEs answer? > > Marty: We started doing this exact thing in MVS/QuickRef's Assembler-oriented data base content. It does save time when you don't have to go hunt down the STFLE bits. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Is the PoOP too big? (was Assembler manuals)
On Tue, Aug 30, 2011 at 11:52 AM, Tony Harminc wrote: > I've wondered for a while - is the .boo data format documented > anywhere? I looked briefly at the z/OS Bookmanager datasets, and > didn't see any mapping macros or the like, but that doesn't rule it > out. > > Tony H. > Tony: The .BOO file format is not documented anywhere outside of IBM. -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Format-1 and Format-8 DSCBs
I've used them with EXCP, for certain types of data sets. -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Thu, Aug 25, 2011 at 2:25 PM, John P Kalinich wrote: > Are these Format-1/8 DSCB fields used by any access method? > | 90(X'5A')| Binary | 1 | DS1KEYL | Key length ( 0 to > 255). > > > +--+--+---+--+- > | 91(X'5B')| Binary | 2 | DS1RKP | Relative key > position. > > Regards, > John K >
Re: HLASM manuals
On Fri, Aug 19, 2011 at 12:20 PM, David Cole wrote: > Better examples > I agree with Dave on this. The examples in the reference are not very good. It's almost like the person who wrote the manual was not really an ALC programmer, but was a doc person... ;-) > -- > Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: How to code TAM instruction
2011/6/6 Martin Trübner > > > And if he can not read POP or the short-ref, he probably should not code > these kind of programs. > > Amen to that, brother! Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: ASM vs HLL (Was: CPU: ASSM vs ENTERPRISE COBOL - SOLVED!)
On Thu, Apr 7, 2011 at 3:20 PM, Edward Jaffe wrote: > > > Is it just me?? > > -- > Edward E Jaffe > Phoenix Software International, Inc > 831 Parkview Drive North > El Segundo, CA 90245 > 310-338-0400 x318 > edja...@phoenixsoftware.com > http://www.phoenixsoftware.com/ > No. -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: QSAM file size
Monika, That information is in the VTOCs on the volumes where the QSAM file resides, but to get it you have to OPEN the VTOCs and read them, or use CVAF to get that information. It's probably more trouble than opening the QSAM file itself and interrogating the DEB built at OPEN time for the file. Multi-volume QSAM data sets require handling each volume separately also... -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Sat, Apr 2, 2011 at 9:24 AM, Monika Amiss wrote: > Hello group, > > I'm wondering if there is a way to get the size of a temporary QSAM-Dataset > programmatically > without opening and seeking to the end of the file. The Program, which > needs the site information > must C (or Assembler) and runs in z/OS-Batch. I played around with fstat() > but did not get my > results. The best approach until now seem to me to use CALL ISPLINK and get > via LMDLIST > the zdlsize the used Tracks of the Dataset. But perhaps somebody has a > better idea, > perhaps I can use RDJFCB or BPXWDYN to get a bit easier to the values. > > Any hint appreciated, with best regards > Monika >
Re: Button Worn by Distinguished Gentleman at SHARE
Ed: Dr. Ehrman is correct. I never thought about it before, but there it is, in the first amendment to the United States Constitution: Amendment 1 Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances. The right to compile is not explicitly mentioned...;-) -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: SYSADATA file quirk
Thank you Adam, I stand corrected. A warning message would have been nice though... -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Mon, Feb 21, 2011 at 2:43 PM, Johanson, Adam wrote: > Mike Shaw wrote: > > If he's not happy 'cause the LRECL is too short, give me an error > message, don't just change things without telling me! > > I don't know if this qualifies as HLASM telling you that it's > changing things, but the Programmer's Guide says that the file attributes > should be what HLASM is changing them to: > > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/asmp1020/10.7?SHELF=ASMSH030&DT=20080714231437#FIGCMATAB1 > > > Adam Johanson > IMS Systems Programming > USAA >
SYSADATA file quirk
Everyone: I have a PDSE defined as RECFM=VB, LRECL=300, BLKSIZE=23440. Several members exist in the data set. If I use HLASM 1.6 to assemble a module and point the SYSADATA DD for that assembly to that PDSE like this in the JCL: //C.SYSADATA DD DISP=SHR,DSN=x(memname) with the ADATA parm specified in the assembly step, after the assembly step executes, the DCB attributes for the file become RECFM=VB, LRECL=32756, BLKSIZE=32760. The LRECL and BLKSIZE are changed by the assembler. Happens every time. Shouldn't the assembler check the DCB attributes for an existing SYSADATA output file, particularly a PDS or PDSE, and use those attributes, rather than CHANGING the DCB attributes without a warning? If he's not happy 'cause the LRECL is too short, give me an error message, don't just change things without telling me! ...or am I asking too much here? -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Baseless vs Based
On Tue, Dec 21, 2010 at 10:01 AM, Paul Gilmartin wrote: > ... I was dismayed at SHARE Denver to hear > an IBM representative boast of the design liberty IBM has > gained by making the program object format non-GUPI. > > -- gil > No doubt, someone @ IBM thinks a GUPI-format program object would slow down compiler development... -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: prize for a good replacement for "baseless"
On Sat, Dec 18, 2010 at 1:32 PM, john gilmore wrote: > In the future "baseless", always an ugly term embodying a dubious pun, > will need explanation. It will be as helpful as a description of a modern > automobile as "crankless". > > To find a better term I have appointed myself to run a contest. The prize > for the best suggested term, the one about which a consensus emerges, is a > book of the winner's choice, its cost not to exceed US$50|£40|€32. > > John Gilmore Ashland, MA 01721-1817 USA > > I think 'base independent' describes it; 'base register independent' if you want a full formal definition. -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Sample code to read a PDS member using BPAM
On Wed, Oct 13, 2010 at 4:33 AM, John Blythe Reid wrote: > > recommend a book on REXX in the z/OS environment ? > This one is old but still relevant and very easy to follow: "REXX in the TSO Environment":by Gabe Gargiulo http://www.amazon.com/Rexx-Tso-Environment-Qed-Mainframe/dp/0471561886/ref=sr_1_1?ie=UTF8&s=books&qid=1287012355&sr=8-1 Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Instruction Set Architecture (Subject: corrected)
On Thu, Sep 9, 2010 at 9:05 AM, Ward, Mike S wrote: > Why make coding in assembler so difficult. People already complain that > it shouldn't be used because it's outdated and incomprehensible. > > Only those who can't or won't comprehend it say that...;-) -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: The new POO (Props / ProP ) is available
Looks like a single bit in the facility bit string is being used to reflect the presence of several of the new facilities; in the past, IBM generally used one bit to indicate the presence of each new facility; bit 45 in the facility bit string says this (page 4-68): "The distinct-operands, fast-BCR-serialization, high-word, interlocked-access, load/store-on-condition, and population-count facilities are installed in the z/Architecture architectural mode." Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: The new POO (Props / ProP ) is available
On Fri, Sep 3, 2010 at 6:47 PM, Steve Comstock wrote: > > http://www-01.ibm.com/support/docview.wss?uid=isg2b9de5f05a9d57819852571c500428f9a > > -- > > Kind regards, > > -Steve Comstock > The Trainer's Friend, Inc.-- > It's early!!! Thanks Steve... Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Efficient Memory List
On Tue, Aug 24, 2010 at 1:40 PM, Patrick Roehl wrote: > > Because of these factors, and the ideas brought out in this discussion, > the bit string idea seems like an excellent fit. > Patrick: If you implement the bit string idea, please let us know how much of an improvement (execution time, CPU time) it provides over your current exit. -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Mainframe Assembler Coding Contest - new problem #22
On Mon, Aug 2, 2010 at 7:08 AM, Tony Thigpen wrote: > It could be very useful for SELECT/SELECTEX processing in TCP/IP. > > Tony Thigpen > > Maybe for speeding up a crypto hashing function? -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: zEnterprise - new PoPS?
Gentlemen, that's too late, IMHO. We should be able to see it NOW...where is the harm in releasing the POPs a few months BEFORE GA of the box it applies to? -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. 2010/7/22 Martin Trübner > John, > > it says "will be available with first shipment" ...IIIR September 2010 > - so a few more weeks for us low level programmers. > > -- > Martin > > Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE > more at http://www.picapcpu.de >
