I once wrote a program with many subroutines that all used the same DCB to print out debugging messages. I wrapped each PUT inside an exclusive ENQ and a DEQ for some arbitrary resource name so that the characters being printed on each line would not be shuffled with the previous or overlaid by the subsequent PUT because of timing considerations. Each place where I built a print line had to conform to the RECFM, LRECL, control character, etc., standards as defined in the DCB. It worked, but I was not using SNAP with this SYSOUT DCB.
If all of your messages are built in conformance with the SNAP DCB's parameters and you do the WRITEs and CHECKs somewhere that you know cannot possible execute simultaneously with the SNAP function, then it should work. Your output DCB has an address in it of a BSAM module that takes your single logical record and puts it into the correct position within a larger block of data. This module doesn't care where the WRITE request came from or where the input logical record is, as long as all the 24-bit and 31-bit addressing considerations are handled properly and as long as all the users of the DCB are in the same address space and enabled, unlocked, and in task mode (unless SNAP now supports system linkage, which I don't remember). The output of the SNAP is a sequential file with big blocks, small logical records in each block, each record has the same type of control character and same type of length attribute (fixed or variable), and is later read back in using standard BSAM or QSAM input processes and then printed, telecommunicated somewhere, or displayed on a terminal. The only thing special about a SNAP process is that you invoke an SVC that saves you the trouble of formatting all the many print lines it takes to display possibly large amounts of consecutive bytes of virtual storage. Each print line generated by the SNAP function is built in accordance with the DCB's specifications and passed to the BSAM module with the appropriate WRITE/CHECK macro, just as your informational messages are. Bill Fairchild, Senior Software Engineer ASG Software Solutions ----- Original Message ----- From: "Chuck Hardee" <[email protected]> To: [email protected] Sent: Saturday, July 12, 2014 5:51:38 PM Subject: Questions on SNAP/SNAPX usage Does anyone know if one can issue WRITE or PUT requests against the DCB that has been opened and being used by SNAP or SNAPX requests? According to the manual, the SNAP DCB is defined as MACRF=(W) and is variable length LRECL=121. What I want to do is write 0 to n "explanation" lines prior to the SNAPs of one or more blocks of memory. I already have the SNAP working and have no problems issuing requests for 1 or more storage areas with an associated "header" line. Now I want to write additional lines preceding the snaps. Thanks, Chuck Charles (Chuck) Hardee Senior Systems Engineer/Database Administration CCG Information Technology Thermo Fisher Scientific 300 Industry Drive Pittsburgh, PA 15275 Direct: 724-517-2633 FAX: 412-490-9230 [email protected] ---------------------------------------------------------------------- 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
