David, Yes, we have used Metal C. It is very cool, although it does have limitations. What we frequently do instead is to write a routine in assembler with XPLINK linkage (since our C++ code is XPLINK), and then with some very careful programming we can set up its save/workarea on the XPLINK stack.
Mixing assembler system macro calls into Metal-C code is a little tricky, and because of all of the things that you have to worry about it usually isn't worth it. Dropping a few machine instructions into Metal-C code however is really cool and not too hard. What I would really like to do is to use Metal C with XPLINK linkage. I think that it can be done with the right user-written prolog/epilog macros, but it doesn't appear to be ideal because of the "system linkage" assumptions made by Metal C. The motivation for this would be to use Metal-C in XPLINK environments where you just want to drop some fancy z-arch instructions into the generated code. Maybe someone more familiar with Metal-C can enlighten me on this. Kirk Wolf Dovetailed Technologies On Fri, Oct 10, 2008 at 9:52 AM, David Crayford <[EMAIL PROTECTED]> wrote: > Kirk Wolf wrote: >> >> If you used LRECL=1, then you did have a record boundary of 1, so it >> was doing fwrite() with a length of 1. >> This is because todsn() always uses QSAM. >> As it turns out, even with a rational DCB, the C library is more >> expensive than direct QSAM macros. >> For this reason, it is likely that a future version of Co:Z will >> bypass the C library for QSAM I/O. > > Kirk, have you checked out metal C? I can tell you this - in my experiments > the code generated actually results in faster code then my hand crafted > assembler. I'm very impressed by it. The compiler is pipeline aware and > produces very fast code. If you want to drop down to using QSAM macros I > would recommend it for a QSAM I/O library... It does bind you up to a z/OS > 1.9 system though. > > I've noticed that stdio is always less efficient then other languages for > QSAM. This seems to be caused by double buffering due to the semantics of > the stdio library functions. It moves data into the user supplied buffer > with fread() but keeps it's own buffer so is doing two moves. I've reverse > engineered most of the FILE fcb control block for the M4 port and will > commit it to sourceforge soon. > >> On Fri, Oct 10, 2008 at 8:42 AM, John McKown <[EMAIL PROTECTED]> wrote: >>> >>> On Fri, 10 Oct 2008 21:16:53 +0800, David Crayford <[EMAIL PROTECTED]> >>> wrote: >>> >>>> CELHVnnn is an XPLINK condition handler. For example CELHV003 is the >>>> XPLINK runtime environment. Im not familiar with CELHV002 but it could >>>> be that the SSL hashes are a CPU hog. If you sending a file that's in a >>>> zFS or HFS cached it may not I/O bound... >>> >>> I got some advice on another forum about this. The output is a "byte >>> stream" >>> with no record boundries, pe se. In my job, I had >>> DCB=(RECFM=FB,LRECL=1,BLKSIZE=0). I changed that to >>> DCB=(RECFM=U,BLKSIZE=27998). The CPU usage on the exact same job went >>> from >>> 45.82 minutes to 1.33 minutes. Curiously, the elapsed time actually went >>> up >>> somewhat. Probably due to increased usage on the system during the second >>> test. >>> >>> -- >>> John >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO >>> Search the archives at http://bama.ua.edu/archives/ibm-main.html >>> >>> >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO >> Search the archives at http://bama.ua.edu/archives/ibm-main.html >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
