You can't accurately predict risks when you make wild guesses about the use case. Certainly my use case does not require a nonstandard calling sequence.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Jon Perryman <[email protected]> Sent: Tuesday, June 17, 2025 2:58 PM To: [email protected] <[email protected]> Subject: Re: Is there an equivalent of an S-con for a long displacement? External Message: Use Caution On Sun, 15 Jun 2025 12:11:21 +0300, Binyamin Dissen <[email protected]> wrote: >What SCON risks? By using LOCTR you can have data adjacent to the code in the >source There are risks that aren't being mentioned and I'm telling others there are simpler & less risky solutions available that they should use instead of SCON. I won't list all the risks. LOCTR is a possible solution to 1 risk. Lesser experienced staff expect R0 & R1 to be the only parm registers. Do you think they won't get confused when they see additional parms passed in non-standard registers using SCON that must be parsed to determine the register and locate it in the save area and then add in the displacement. are the standard method to pass parms. SCON's are optimized for machine instructions (not software). There are viable, simple and well understood alternatives to avoid the use SCON which require you parse the SCON, calculate the offset into the savearea and add it to the displacement to get the address. >And your suggestion of simply doing an EX on the LAY, the requires that the B >(and possibly its associated AR) are unchanged. The service routine does not >know which registers are available. You mention AR which is another risk. You said you access the register through the savearea but there is no mention how you retain the AR value. As for my suggestion of "EX on the LAY" was to point out SCON's are optimized for use in machine instructions. I don't think you are building a machine instruction to EXecuted but instead, inefficiently parsing the SCON. Why not use it through an instruction? >The advantage is a R/O pre-built parameter list with both data and metadata , >i.e., type of data, length of data, etc. where the code to invoke the routine >(besides moving the register save instructions to the calling routine rather >than the called routine) is passing the pointer to the metadata list. This points out another risk which is the number of registers available for a concept built on passing parms through registers (e.g. you have 2 registers available but need a third). It's common to have R/O pre-built parms with metadata using existing methods ( e.g. IKJPARSE, DYNALLOC and more). I'm not trying to stop you from using SCON's as parms but instead warning others there can be unforeseeable consequences unless you have completely thought this through. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
