FSDB[SDF] (1M) HP-UX Series SOO Only

FSDB[SDF] (1M)

BUGS

If fsdb changes a field that is duplicated in an in-memory OS data structure, the change may be undone by the OS. Forcing a reboot while still in fsdb sometimes circumnavigates this problem.

Changes to inodes 0 and 1 always fall into this category.

Hewlett-Packard Company - 2 - Version B.1, October 1986

FWTMP(lM) HP-UX FWTMP(lM)

NAME

fwtmp, wtmpfix - manipulate connect accOlmting records SYNOPSIS enable editing, via ed(l), bad records or general purpose maintenance of the file.

The argument -ic is used to denote that input is in ASCII form, and output is to be written in place of files to indicate the standard input. If time/date corrections are not performed, acctconl will fault when it encounters certain date-change records.

Each time the date is set, a pair of date change records are written to /usr / adm/wtmp. The first record is the old date denoted by the string old time placed in the line field and the flag OLD_TIME placed in the type field of the <utmp.h> structure. The second record specifies the new date and is denoted by the string new time placed in the line field and the flag

acct(1M), acctcms(IM)' acctcom(I), acctcon(IM), acctmerg(IM), acctprc{IM), acctsh{IM)' ed{I), runacct{IM), acct(2), acct(4), utmp(4).

DIAGNOSTICS

Wtmpfix generates these diagnostics:

Cannot make temporary: xxx failed to make temp file Input truncated at offset: xxx missing half of date pair New date expected at offset: xxx missing half of date pair Cannot read from temp: xxx some error reading

Bad file at offset: xxx uL.Jine entry not digit, alpha, nor" I" or "{" (first character only checked) Out of core: malloc fails. (Saves table of date changes)

No dtab: software error (not seen yet)

Hewlett-Packard Company - 1 - Version B.I, October 1986

FWTMP(lM) HP-UX FWTMP(lM)

BUGS

Fwtmp generates no errors, even on garbage input.

Hewlett-Packard Company - 2 - Version B.l, October 1986

GETTY(lM) HP-UX GETTY(lM) adapt the system to the speed and type of terminal being used.

Line is the name of a tty line in / dev to which getty is to attach itself. Getty uses this string as login message should look like, what the initial tty settings are, and what speed to try next should the user indicate that the speed is inappropriate (by typing a <break> character). The default speed is 300 baud. The optional third argument, type, is a character string describing to getty what type of terminal is connected to the line in question. Getty understands the following types:

none fourth argument, linedisc, is a character string describing which line discipline to use in communi-cating with the terminal. Again the hooks for line disciplines ar~ available in the operating sys-tem but there is only one presently available, the default line discipline, LDISCO.

When given no optional arguments, getty sets the speed of the interface to 300 baud, specifies that raw mode is to be used (awaken on every character), that echo is to be suppressed, either parity allowed, new-line characters will be converted to carriage return-line feed, and tab expansion per-formed on the standard output. It types the login message before reading the user's name a char-acter at a time. If a null character (or framing error) is received, it is assumed to be the result of the user pushing the "break" key. This will cause getty to attempt the next speed in the series.

The series that getty tries is determined by what it finds in /ete/gettydefs.

The user's name is terminated by a new-line or carriage-return character. The latter results in the system being set to treat carriage returns appropriately (see ioctl(2)).

The user's name is scanned to see if it contains any lower-case alphabetic characters; if not, and if the name is non-empty, the system is told to map any future upper-case characters into the corresponding lower-case characters.

In addition to the typical UNIX operating system's erase and kill characters (# and @), getty also understands \b and ·U. If the user uses a \b as an erase, or 'U as a kill character, getty sets the standard erase character and/or kill character to match.

Hewlett-Packard Company - 1 - Version B.1, October 1986

GETTY(lM) HP-UX GETTY(lM)

FILES

Getty also underst"ands the "standard" ESS2 protocols for erasing, killing and aborting a line, and terminating a line. If getty sees the ESS erase character, _, or kill character, $, or abort charac-ter, &, or the ESS line terminators, / or !, it arranges for this set of characters to be used for these functions.

Finally, login is called with the user's name as an argument. Additional arguments may be typed after the login name. These are passed to login, which will place them in the environment (see login{l)).

A check option is provided. When getty is invoked with the -c option and file, it scans the file as if it were scanning /etc/gettydefs and prints out the results to the standard output. If there are any unrecognized modes or improperly constructed entries, it reports these. If the entries are correct, it prints out the values of the various flags. See ioctl(2} to interpret the values. Note that some values are added to the flags automatically.

jetcjgettydefs jetcjissue SEE ALSO BUGS

ct(l}, init(lM}, login(l}, ioctl(2}, gettydefs(4}, inittab(4}, termio(7}.

While getty does understand simple single character quoting conventions, it is not possible to quote the special control characters that getty uses to determine when the end of the line has been reached, which protocol is being used, and what the erase character is. Therefore it is not possible to login via getty and type a #, @, /, !, _, backspace, 'U, 'D, or & as part of your login name or arguments. They will always be interpreted as having their special meaning as described above.

Hewlett-Packard Company - 2 - Version B.l, October 1986

GETX25 (1M)

NAME

getx25 - get x25 line SYNOPSIS

/etc/getx25 line speed pad-type DESCRIPTION

HP-UX GETX25 (1M)

Getx25 is very similar to getty in function, but is used only for incoming lines that are connected to an X.25 PAD. It performs special functions such as setting up an initial PAD configuration. It also logs the number of the caller in /usr/spool/uucp/X25LOG. The third parameter is the name of the PAD being used. HP2334A is the only one supported at this time. A typical invokation would be:

/etc/getx25 x25.1 2 HP2334A SEE ALSO

getty(1M), login(1), uucp(1) AUTHOR

Getx25 was developed by HP.

Hewlett-Packard Company - 1 - Version B.1, October 1986

HPUXBOOT(IM) HPUXBOOT (1M) Series 800 Only

NAME

hpux - HP-UX bootstrap and installation utility SYNOPSIS

hpux [boot] [-fnumber] [-istring] [-r] [devicefile]

hpux copy devicefile devicefile hpux -v

The command sequences for all operations are presented under SYNOPSIS above. They may be either entered interactively to isl or present in an isl autoexecute file. The first sequence performs

Hpux boot and copy operations accept devicefile specifications, which have the following format:

manager(x.y .z;n,s } filename

They are called devicefiles because they are composed of a device name part and a file name part.

In the device part, manager(x.y.z;n,s), manager is the name of an HP 9000 Series 800 I/O System manager (i.e. device driver), for example discO. x.y.z is the physical hardware path to the device, identifying bus converters, slot numbers, and hardware addresses. (Bus converters are not currently supported.) N is the minor number which controls manager dependent functionality. S is the file skip count. For tapeO and tapel devices, this parameter describes how many files must be skipped (from the beginning of the tape) before the desired file can be accessed. It has a default value of 0, and is completely ignored for other devices. The file name part, filename, is a standard HP-UX path name. In a devicefile specification, the only required component is the hardware path. All other components are optional. Some hpux operations have defaults for par-ticular components. A devicefile specification containing a device part only specifies a raw device.

A devicefile specification containing a file name implies that the associated device part names a device containing an HP-UX file system. The named file resides in that file system. For example, the typical boot devicefile specification is discO(8.0.0;0}hp-ux.

Managers

Currently, hpux supports the discO, tapeO, and tapel managers. DiscO manages all CS-80 discs including cartridge tape devices. TapeO manages the HP 7970 tape drives and tapel manages the HP 7974 and HP 7978 tape drives.

Hardware Paths

The hardware path in a devicefile specification is an arbitrary length string of numbers separated by periods. (Commas are also acceptable.) Each number identifies a hardware component. A single number is the shortest path specification. Currently, path specifications typically contain three components. In x.y.z above, x would be the MID-BUS slot number, y would be the CIO slot number, and z would be the HP IB address.

Hewlett-Packard Company - 1 - December 1986

HPUXBOOT (1M) HPUXBOOT (1M) Series 800 Only

Minor Numbers

The minor number, n, in a devicefile specification controls driver dependent functionality. The manual pages for the individual drivers describe their specific minor number encodings.

Currently, minor numbers for all device drivers adhere to a standard encoding scheme that places optional hardware addresses in bit,s 24 through 31. The logical unit number resides in bits 16 through 23. Driver specific options are found in bits 9 through 15 and the transparent mode (diagnostic bit) flag is bit 8. Hpux manages its own logical units and consequently ignores any logical unit specification that maybe specified in a devicefile. The minor number formats for discO, tapeO, and tape! are summarized below:

discO D = Disable immediate reporting mode B = Berkeley style the optional devicefile. It then transfers control to the loaded image.

The default devicefile for boot is discO(8.0.0;0}hp-ux. Please note that the default hardware path component is variable, and is derived from the Primary Boot Path maintained by pdc (1M) or interactively given to pdc. For more details, consult the appropriate HP 9000 Series 800 architec-ture document. Any missing components in a specified devicefile are supplied from the default above, For example, a devicefile of vmunix.new would actually yield discO(8.0.0;0}vmunix.new

Hewlett-Packard Company - 2 - December 1986