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.
User-written prolog/epilog is definately the way to go. It shouldn't be
too tricky. It's possible to pass in a work area for the stack and
scratch the storage obtain for optimal performance. Use a parameter list
structure and have one entry point with function codes with a switch
statement. Just do what you would do with normal XPLINK assembler code
in the prolog.
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
----------------------------------------------------------------------
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
