Tony, You're observation is correct. I have a note in my intrinsics manual where I observed this behavior before. Bits 31 and 15 are the type indicators. John Zoltak North American Mfg Co -----Original Message----- From: Tony Furnivall [mailto:[log in to unmask]] Sent: Monday, January 18, 1999 4:45 PM To: [log in to unmask] Subject: [HP3000-L] FFILEINFO I'm calling FFILEINFO, tying to get the Spoofle number (Device File ID) for a spool-file that I have opened. The values I get back from items 38 & 78 seem to be not consistent with ech other, nor with the actual spoolfile that results! I know it's me, not the intrinsic, but does anyone have any (constructive) ideas? The relevant portions of code include: SELECT SPOOL-FILE ASSIGN "SPTESTR,UR,,LP(CCTL)" etc. 01 SPOOFLE16 PIC S9(4) COMP. 01 SPOOFLE32 PIC S9(9) COMP. OPEN OUTPUT SPOOL-FILE. CALL INTRINSIC "FFILEINFO" USING \SPOOL-FILE\ 38 SPOOFLE16 78 SPOOFLE32. Condition code comes back 0 (=CCE), but I get the following values, on 3 consecutive runs: SPOOFLE16 SPOOFLE32 Actual Spoolfile 901/$01C2 -2318/$FFFFF6F2 450 903/$01C3 -2317/$FFFFF6F3 451 905/$01C4 -2316/$FFFFF6F4 452 Now, if I read the manual properly, I'd expect that the 901 value would be a negative number: | 38 | U16 | Spoolfile device file number: | | | Bits (1:15) = Device file number | | | Bit (0:1) = 1 Output spoolfile | | | Bit (0:1) = 0 Input spoolfile But I observe that 901=2*450+1, 903 is 2*451+1, etc, implying that bit 15 rather than bit 0 is indicating the type of spoolfile. Likewise, when I observe the 32 bit numbers going up, I expect a match with a 32 bit value, but 450 is $1C2, and setting bit 0, I'd expect to be looking at a value $800001C2, which is -2147483198 (+/- a few for manual conversion!) | 78 | U32 | Spoolfile device file number: | | | Bits (1:31) = Device file number | | | Bit (0:1) = 1 Output spoolfile | | | Bit (0:1) = 0 Input spoolfile I can't make head nor tail of this, and would appreciate any insight into my ignorance..... Tony