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
|
