Can I get APAR detail info without leaving IBM platform?

Answer

To get APAR information, I believe you already know that you can use the web services like the
IBM Servicelink :
https://www-304.ibm.com/ibmlink/servicelink/servicelink.wss?lc=en&cc=US

or the IBM support portal :
http://www.ibm.com/support

to search and get APAR information, but I assume your question is more about getting APAR information without using internet and a browser.

To avoid looking up each APAR separately in ServiceLink or IBM.COM, what you could do is view/browse them directly from the SMPPTS associated with the global zone/CSI, If they (the PTFs) have already been received.
In the PTF coverletter there will be a short description of the APAR.

You can also use the LIST MCS command to get a description too.

As an example, for apar OA40952 (ptf UA72867),

SET BDY(GLOBAL).
LIST MCS(UA72867).

You will get the following:

UA72867 M.C.S. ENTRIES = ++ PTF (UA72867) /*

//UA72867 JOB 5752-72867,SCIXL,MSGLEVEL=(1,1),CLASS=A */
++ VER (Z038)
FMID(HBB7790)
PRE (UA71893)
SUP (IA40952,HA40952,GA40952,AA40952)
/*
PROBLEM DESCRIPTION(S):
OA40952 -
****************************************************************
* USERS AFFECTED: Users who are running in a Parallel Sysplex *
* environment making use of coupling facility *
* lock or serialized list structures for *
* sysplex-scope serialization functions. *
****************************************************************
* PROBLEM DESCRIPTION: Very active XES signaling environments *
* such as those caused when a high volume *
* of XES lock contention exists that is *
* suddenly dropped can result in high CPU *
* usage for connector and XCF address *
* spaces. Much of the high CPU usage is *
* due to XES signal processing running *
* very long ordered queues of control *
* blocks for the signals (while holding *
* the local lock). This can contribute *
* towards local lock contention, XES *
* signal processing running slower, and *
* additional XES signals being resent *
* attempting to maintain initiative for *
* signal delivery. Due to program *
* errors, the XES signals resent may be *
* for signals already received or for *
* newer signals which can prevent the *
* timely processing and removal of *
* control blocks for signals and *
* contribute towards longer queues. *
* *
* SYSPLEXDS *
****************************************************************
* RECOMMENDATION: PTFs should be applied to all systems *
* in the sysplex via rolling ipl. *
****************************************************************
Since all XES signals are currently sent unordered, XES
maintains an ordered queue of signals received and does not
process newer signals before the older ones. As the queue gets
longer, more processing time while holding the local lock is
needed to add new signals and remove signals ready to be
processed. This contributes towards higher CPU usage and local
lock contention.

Timer driven resend logic that runs for all connectors (once per
second) to the structure is too aggressive. Resend logic that
scans queues of signals already sent may send up to 15 signals
per timer interval. Timer driven "send again" logic that scans
queues of signals already received and asks for the resending of
any where gaps are observed may ask for up to 15 ranges of
signals to be resent again per timer interval. This contributes
towards higher CPU usage, local lock contention and unnecessary
XCF message traffic.

While trying to maintain initiative for signal delivery,
other connectors to the structure may incorrectly resend newer
signals before older ones. This is due to the search that looks
for signals to resend looking at the newer signals first. This
can contribute to high CPU usage and local lock contention and
unnecessary XCF message traffic.

When receiving new signals (vs. resent signals), the ordered
queue of signals is scanned from the oldest to the newest signal
while looking for the proper insertion point. As the ordered
queue gets longer, this can contribute to high CPU usage and
local lock contention.

IPL:

****************************************************************
* FUNCTION AFFECTED: 5752SCIXL (OA40952)
*
* CROSS SYS EXT STOR
*
****************************************************************
* DESCRIPTION : IPL with CLPA
*
****************************************************************
* TIMING : Post-APPLY *
****************************************************************

In order for this PTF to be fully effective, an IPL with CLPA
is required.
MULTSYS:
****************************************************************
* FUNCTION AFFECTED: BCP (OA40952) *
* XES *
****************************************************************
* DESCRIPTION : Multi System Application *
****************************************************************
* TIMING : Exploitation *
****************************************************************
This PTF will not be fully effective on the system for which it
is being applied until the PTF(s) for this APAR are applied to
all systems in the sysplex. An IPL is required to activate this
fix on each system of the SYSPLEX, however, a rolling IPL is
sufficient to accomplish the activation.
.....