APAR Identifier ...... II07646 Last Changed ........ 02/07/10 ACIF COMMON PROBLEM INFO APAR Symptom ...... IN INCORROUT Status ........... INTRAN Severity ................... 4 Date Closed ......... Component .......... INFOPALIB Duplicate of ........ Reported Release ......... 001 Fixed Release ............ Component Name PA LIB INFO ITE Special Notice Current Target Date .. Flags SCP ................... Platform ............ Status Detail: Not Available PE PTF List: PTF List: Parent APAR: Child APAR list: ERROR DESCRIPTION: 564806201 HQN2110 R110 569504001 HPRF102 R102 ************************************************************** Section A: CONTROL CARD PROCESSING Section B: HOW ACIF PROCESSES FONTS Section C: UNBOUNDED BOX (3800) FONT PROCESSING Section D: DOCUMENTS WITH PAGE TLE RECORDS Section E: FILE TRANSFER AND AIX Section F: ACIF does not support VSAM datasets Section G: MSGAPK464S after PN67975 Section H: MSGAPK440I RC00 but job step has RC04 ************************************************************** Section A: CONTROL CARD PROCESSING ************************************************************** Control card processing ACIF reads all 80 columns of the control statements. This can sometimes give unexpected results when dataset names are continued and the control statements have line numbers in columns 73-80. ACIF will attempt to use the line number as a dataset name, and will issue MSGAPK451S and MSGAPK417I will contain a numeric value. Remove line numbers from the control statements and rerun, or end each numbered line with a comment indicator ("/*") before the line numbers. ************************************************************** Section B: HOW ACIF PROCESSES FONTS ************************************************************** How ACIF processes fonts. ACIF creates MO:DCA-compliant output files. This means that the font list structured field, Map Coded Font, must be an MCF format 2 (x'D3AB8A'). This structured field does not currently support any means of specifying host-style coded font names (X0....). Therefore, ACIF must read the coded font object to obtain the names of the code page and character set. Therefore, ACIF will always read the font library, EVEN IF you did not request that fonts be saved in the resource object file. PN70849 causes ACIF to generate MCF-2 SFs with coded font names, if the original MCF1 contained a coded font name, or if there were CHARS specified in the parm file. In addition, if RESTYPE=FONT or RESTYPE=ALL is specified, ACIF will save the coded font, codepage, and char. set. ************************************************************** Section C: UNBOUNDED BOX (3800) FONT PROCESSING ************************************************************ Unbounded box (3800) font processing. When ACIF reads a font object (coded font, character set) from a library, it does so by searching for the BOUNDED box version of the font (X0, C0 prefix), regardless of the specifications in the PAGEDEF or document MCF record. This is because ACIF cannot know the device upon which the document might be displayed or printed. Since font libraries frequently contain both bounded and unbounded fonts, ACIF cannot know which is the correct version to use. All printer models except the d/t3800 accept bounded box fonts, so this is the format ACIF will look for. The resulting print file will still print correctly regardless of whether the document contains bounded or unbounded font names because all the PSFs know the destination printer type and use the corresponding fonts. However, if only unbounded-box fonts are present in the libraries defined for FONTLIB and USERLIB, ACIF will be unable to locate a bounded box equivalent and will issue MSGAPK413S and terminate. A workaround is to make copies of the unbounded box CODED fonts and rename them to begin with X0, and to omit the collection of fonts from the RESTYPE parameter (ie., do not specify RESTYPE=ALL or RESTYPE=FONT). This will allow ACIF to find the correct font and build the output page correctly, but will prevent an attempt to access C0 character sets. A simpler method is to use a bounded box font library if it is available. After the application of PN77365, ACIF will collect unbounded box fonts and save them in the resource object dataset or file. HOWEVER, PSF will not print a dataset which contains inline unbounded fonts.(MSGAPS117I for FNP & FNO) A workaround is to use the RESFILE=PDS parameter of ACIF. Then, specify the USERLIB JCL parameter in the print job to point to the PDS that ACIF created. PSF will be able to use unbounded box fonts from a USERLIB. Note that the archiving of unbounded box fonts is NOT recommended. No current or future MO:DCA receiver (printer, viewer, etc.) will support unbounded box fonts. ************************************************************** Section D: DOCUMENTS WITH PAGE TLE RECORDS ************************************************************** Documents with page TLE records. Input datasets that are composed pages (AFPDS) and contain page-level TLEs (TLE records after the AEG) and have no named groups (BNG/ENG), and for which INDEXOBJ=ALL was requested may end with MSGAPK410S or MSGAPK408S. This is because page-level TLE records must be collected in memory until the end of the input document or file. MO:DCA index structures contain the extent (size) of the object being indexed. Indexed object are delimited by named group (or end document-EDT). If no groups are present ACIF will continue to build the index in memory. If the input file is large enough, there will not be enough memory and ACIF will terminate. The ACIF memory manager currently limits the number (but not the size) of memory blocks that can be allocated, so increasing REGION size may not alleviate the problem. A workaround is to place the TLEs outside the page inside of named groups, with one named group per page. This restriction may be relieved in a future release. **************************************************************** Section E: ACIF EXPOSED: FILE TRANSFER AND AIX **************************************************************** Printing "foreign" files using ACIF on AIX is often a confusing matter. This is often because we are unware of the actual composition of the file to be printed, the idiosyncrasies of the file transfer method being used, and ACIF's requirements. ACIF needs to know two things about a file in order to print it: how long is each print record and what kind of carriage control does it have. As simple as this sounds, it is the source of most of the difficulty with ACIF/AIX printing. ACIF processes print records. A record is a sequence of contiguous characters, usually representing a printed line or a MO:DCA (AFPDS) structured field (structured fields are like print commands). Each record has a defined boundary or length. Some files contain information in each record describing the record's length, other files require an external definition of length. The former are called varible-length files, the latter, fixed-length files. Fixed-length files contain records all of the same length. There are no separators or prefixes or other self-identifying information that indicates this length. You must know the record length and tell ACIF using the FILEFORMAT=RECORD,nnn control statement, where nnn represents the length of each record. Variable-length files contain records that identify the length of each and every record in the file. Each record contains either a field that gives the length of the following record or a delimiter giving the boundary of the record. If the record contains a length, that length must be a 16 bit binary number prefixing each record. The length includes the length of the 2 byte length prefix. Files with length prefixes are identified to ACIF using the FILEFORMAT=RECORD control statement. For fixed-length files and varible-length files using length prefixes, MO:DCA structured fields are treated as a special case. All such structured fields are self-identifying and contain their own length. They need not contain a length prefix to be correctly interpreted, but will be correctly processed if there is a length prefix. Instead of a length prefix, varible-length records may use a separator or delimiter to indicate the end of a record. All of the bytes up to, but not including, the delimiter are considered part of the record. For AIX the delimiter is the newline character. The standard newline character is X'0A'. If the file uses EBCDIC encoding, the newline character is X'25'. Files using newlines to indicate record boundaries are designated using the FILEFORMAT=STREAM control statement. ACIF currently attemps to determine if the file is ASCII or EBCDIC encoded. It does this by reading the first six bytes and testing for all ASCII characters (code points from X'00' to x'7F'). If no non-ASCII characters are found, then the file is assumed to use the ASCII newline character, X'0A'. Otherwise the EBCDIC newline, X'25', is used. This implies that input files can "fool" ACIF's interpretation of the line separator either intentionally or by accident. All of the above leads to a set of rules for ACIF's interpretation of how files will be processed. The following are possible combinations: Data Type Newline character all EBCDIC EBCDIC X'25' all EBCDIC ASCII X'0A' (note 1) all ASCII EBCDIC X'25' (note 1) all ASCII ASCII X'0A' Note 1: These combinations are only possible if ACIF has been deceived by prefixing the file with a string that indicates a different code set. For EBCDIC data with ASCII newlines, use X'0320202020200A'. For ASCII data with EBCDIC newlines, use X'03404040404025'. **************************************************************** THE PLAIN TRUTH ABOUT CARRIAGE CONTROLS **************************************************************** In many environments (IBM mainframes, most minicomputers) printable data normally contains a carriage control character that acts like a vertical tab command to position the paper at the start of a new page, a specified line on the page, or to control skipping to the next line. There are two schemes in general use, ANSI carriage control and machine carriage control. ANSI control is the most universal, and consists of a single character prefixing the print line. The standard characters are: space single space line and print 0 double space line and print - triple space line and print + don't space line and print 1 skip to channel 1 (top of form by convention) 2-9 skip to hardware-defined position on page A,B,C (defined by a vertical tab record or FCB) Note that ANSI controls all perform the required spacing before the line is printed. ANSI controls may be encoded in EBCDIC (for ACIF, CCTYPE=A) or ASCII (CCTYPE=Z). Machine carriage controls were originally the actual hardware control commands for IBM printers, and are often used on Burroughs/Unisys systems. Machine controls are literal values, not symbols. They are not represented as characters in any encoding and so cannot be translated. Typical machine carriage controls are: X'09' print line and single space X'11' print line and double space X'19' print line and triple space X'01' print line and don't space X'0B' space one line immediately (don't print) X'89' print then skip to channel 1 (top of form by convention) X'8B' skip to channel 1 immediately (don't print) Note that machine controls print before performing any required spacing. There are many more machine control commands. Carriage controls may be present in a print file or not, but every record in the file must contain a carriage control if controls are to be used. If the file contains carriage controls but CC=NO specified to ACIF, the carriage controls will be treated as printing characters. If no carriage controls are specified the file will be printed as if single spaced. **************************************************************** FILE TRANSFER ODDITIES **************************************************************** There are many possible ways of transferring files from other systems to AIX. Each method results in a different set of possible outputs, not all of which are useable by ACIF. Here are some of the most common: **************************************************************** PHYSICAL MEDIA (eq. tape) - files are normally copied without any transformation. For fixed-length files this is fine. For variable-length files, either the tape's creator or the copy program must prepend the 2-byte binary length. **************************************************************** PC TRANSFER - files may be transferred using an implementation of the most common PC file transfer program (IND$FILE) or from a PC diskette with the transfer done from host to PC. Depending on the host system there are a variety of possible parameters that can affect printing. For fixed-length files binary is the best choice. You must know the record length. For MVS and VM/CMS, binary is the default. For CICS and VSE, specify the BINARY option. For variable-length records containing only printable characters and either ANSI carriage control or no carriage control, use ASCII and CRLF, then specify the INPEXIT=asciinpe control statement to remove the otherwise unprintable carriage return (x'0D') that will be inserted in the file. For VSE some additional file transfer parameters are available. For files with machine carriage control you can specify BINARY,CRLF and CC. This provides an EBCDIC file with correct carriage controls separated by ASCII newlines (and carriage returns, too). You must, however, trick ACIF as in Note 1, above. ************************************************************** FTP - From most systems, FTP works similarly to PC file transfer. Most of the same options are provided. In addition, when executing FTP on an AIX system the extraneous carriage return can be omitted. However, you must test your implementation to be sure how it behaves. Some FTPs use IMAGE as a synonym for BINARY. **************************************************************** Conspicuously absent in the discussion of file transfer was the combination of variable-length files that contain bytes that cannot be translated from their original representation to ASCII. These files may contain machine control characters or mixed linedata and structured fields, or special code points that have no standard mapping. None of the conventional file transfer programs will correctly handle these cases. They either destroy the data in translation, when ASCII is specified, or cannot indicate record lengths, when BINARY is specified. The best solution is either to write a small filter program on the host system that appends the 2-byte records length to each record and transfer the file BINARY, or to NFS-mount the file. NFS mounted files are generally not translated, but NFS prefixes variable-length records with a 2-byte binary record length (check your NFS implementation-special parameters may be necessary). Note that some NFS systems do not supply the binary record length for fixed-length files. Files containing only structured fields (MO:DCA or AFPDS or LIST3820) are treated as a special case by ACIF. You may always transfer such files as binary with no special record separators Because structured fields are self-defining and contain their own length, ACIF will always be able to read them. This is how print resources (FORMDEF, font, page segment, overlay, etc.) are handled, and it will work for print files, too. **************************************************** Section F: Acif does not support VSAM files **************************************************** ACIF supports PDS datasets and SEQ datasets in MVS and only SEQ (SAM or VSAM-managed SAM) datasets in VSE. *************************************************************** Section G: MSGAPK464S after PN67975 *************************************************************** It is documented in the AFP Conversion and Indexing Facility: APG(G544382401) that "Each TRIGGERn parameter comprises three values." A customer had mistakenly specified four (4) values (*,10,10,'trigger value') and did not get an error message when submitting the ACIF job. ACIF effectively ignored the third value and found the 'trigger value' and used it. This was done before apply PN67975. After applying PN67975, which changed the parser to look at all parameter values positionally, the error is flagged by MSGAPK464S because the parser did not find the single quote in the third position. Before PN67975, ACIF looked at the first two trigger fields and searched for the single quote (') to find the TRIGGERn value. ****************************************************** Section H: MSGAPK440I but job step has RC04 ****************************************************** If a resource library parm (PDEFLIB, FDEFLIB, FONTLIB, PSEGLIB, OVLYLIB) is not specified in the ACIF parms, the job will finish with RC00, but one of it's steps will have a RC04. This was introduced with PTF UQ24728. APAR PQ61411 created to prevent this problem. **************************************************************** Acif information is continued in info apar II11984 LOCAL FIX: