On Sat, 9 Aug 2025 20:41:53 -0500, Paul Gilmartin <[email protected]> wrote:
>On Thu, 7 Aug 2025 08:35:07 -0400, Joseph Reichman wrote: >>If you run a windows app using visual studio debugger you will see all code >>run in 64 bits >Good example of courageous design. Look forward, not back. ROTFLOL! Microsoft was driven by $$$, not ingenuity, not courage nor looking forward. MS Edge still runs 32-bit (see 'program files (x86)') on Windows 11. I assume VSCODE DEBUG 64-bit can't debug 32-bit apps such as MS Edge. > For over a half century it has been >true that (almost) IBM languages used a uniform call >interface, ROTFLOL! Motivated reasoning. Just because you ignore similar 64-bit issues in Unix doesn't mean they don't exist. Ever hear of GCC -m32? The majority of Unix software is application which is far easier to make 64-bit compliant. LE handles parms for IBM languages except HLASM. As for HLASM, there has never been a single uniform parmlist interface. Many are hidden in macros (e.g. IKJPARSE). A few chose to ignore R1 and pass registers set by the caller. Some don't bother with the parmlist termination bit. >Is IBM in a quandary? It is not a quandary. Parmlist is the least of an HLASM developer's 64-bit worries. IBM gave us the choice to ignore 64-bit or use the tools and methods to handle 64-bit. For most sysprogs it's a trivial choice because they are dealing with single standalone programs. For product developers, IBM lets us decide the best solution for our situation. >that generated by the CALL macro and the initiator >used the same interface so any program used as a job b step >could equally be called as a subroutine. All these years and still stuck in the Unix mindset. Explain to us how database calls from a shell script are interchangeable with the calls from programs. >PLIST8=YES for support of data in any location, and PLIST8=NO for support >of programs using the traditional interface. The choice >can not be made statically as there is no way to discern >ANODE of a subroutine at translation time. The CALL macro is only 1 method of calling programs and it conveniently builds a simple standardized parmlist. >Suddenly there are two interfaces which must be supported: Two? There are several interfaces. It is up to us to decide which and how we will support. > The BPX1-BPX4- replication is a desperate accommodation. This is not desperation. This is a simple method of efficiently documenting AMODE 64. If this causes you so much stress, then hide them behind a few macro lines. >Dynamically, the decision can be made during execution by examining >the AMODE of the called program object. The initiator >*could* do that. You make the false assumption that AMODE tells you the program loads 64 bit parm addresses. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
